02:33mangix: oh boy more crashes
03:28AndrewR: https://github.com/negge/jpeg_gpu - this one actually works on my NV92 - or at least it displays some good image (while loading 16Mpix image - 4928x3264 resulted in just 4fps frame rate :} )
03:29rhyskidd: mangix: which card, and is the crash the same as a previously reported one?
03:51mangix: rhyskidd: what crash?
09:21karolherbst: okay, I think I need this unk1 byte in the CSTEP table for properly parsing the cstates for each pstate
09:24karolherbst: there are even "broken" vbios with things like this: "0: pstate 0 index 1", this should have been pstate 7
09:25karolherbst: okay, I think I got it now
12:14karolherbst: funny, nvidia doesn't go eblow 575MHz on pstate a/7 allthough they could, wondering why that is
12:15pmoreau: Some more patches to review? I am in the mood this afternoon.
12:15pmoreau: karolherbst: Do you prefer having your clk/subdev reviewed separately from your latest series?
12:15karolherbst: pmoreau: you could review my patches :p
12:16pmoreau: Going to :-)
12:16karolherbst: I prefer the mesa series though
12:16karolherbst: the gallium precise one would be perfect
12:16karolherbst: got merged
12:17pmoreau: I did review part of that one IIRC
12:17karolherbst: imirkin: thanks
12:17karolherbst: pmoreau: yeah, I didn't noticed they got merge this night
12:17karolherbst: so yeah, the clk update ones are good
12:17karolherbst: pmoreau: well the latest
12:17karolherbst: the 7 first patches are the clk update series
12:17pmoreau: Yep, I realised that
12:19karolherbst: oh my, I think it needs to be land everything at once or so in the end :/
12:22karolherbst: I think I lost some patches
12:27karolherbst: okay, it was only one, and luckily I posted the hash here
12:27karolherbst: pmoreau: the thermal reclocking trigger requires a patch like this otherwise it would trigger a full reclock every time: https://github.com/karolherbst/nouveau/commit/bedd27e6796676d2d5990dfdd57e85a54836f76c
12:39pmoreau: karolherbst: What was that dstate you are removing?
12:41pmoreau: Care to elaborate a bit? :-D `nvkm_clk_dstate()` used to upclock/downclock if the refresh rate of the screen changed? oO
12:42karolherbst: well it wasn't used at all
12:42pmoreau: Sure, but what was it supposed to do?
12:42karolherbst: but skeggsb had the idea that something could specify which pstate to use according to the needs of the display engine
12:42karolherbst: like to drive all displays at those resoltuions and refresh rates, we need at least pstate a
12:42karolherbst: or something
12:43pmoreau: Ah, ok
12:43pmoreau: Thanks for the explanation
12:43karolherbst: with PMU counters this isn't a problem, but with GPUs before that? There might be a static lookup table or something more dynamic, no clue
12:44karolherbst: but how all those
12:45karolherbst: *state functions were written, they weren't really helpful, because tstate and dstate could race against each other and switch pstates alternating
12:46karolherbst: in the end we would need something like nvidia is doing. They have a table which has entries limiting what cstates can be set currently. This works from both sides and entries are enabled/disable according the situation
12:47karolherbst: this is important for dynamic reclocking
12:48karolherbst: like on my system there is an entry "battery" which limits the available states for dyn reclocking to pstate max a and cstate max 810MHz
12:50pmoreau: I see
13:01pmoreau: karolherbst: For patch 3, I am not sure to understand how adding a pointer to pstate in nvkm_clk is going to help with accessing cstate, when in the following patch you add a pointer to cstate in nvkm_clk.
13:01pmoreau: Or is it that pstate will contain a pointer to the expected cstate, and cstate a pointer to the current cstate?
13:02karolherbst: mhh I think the messages might be a bit outdated
13:02karolherbst: but in the end I wanted to have a pointer to the current pstate and the current cstate
17:57luv: hi so I think I have fount the ioctl on /dev/nvidiactl I was looking for
17:57luv: ioctl(13, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe3bb28240) = 0
17:58luv: but I'm kinda confuse here ... because the size should be 0x20 (ie 32 bytes) ... am i right? .... but I can see "the data" that should be passed using this ioctl are on 0x7ffe3bb28240+0x80 ... ?
17:59mwk: luv: nvidia likes to use pointers in ioctl params
17:59mwk: so the struct passed by ioctl is just a small part of what's really read by the kernel
17:59mwk: it contains a pointer to a bigger struct
17:59luv: i see
18:01luv: is there a way to retreive the structs? :)
18:01mwk: obviously read them the same way the krnel does..
18:01mwk: some disassembly required
18:02luv: radare2 on nvidia_drv maybe ?
18:03mwk: just look for pointers in the data described by ioctl and follow them
18:04luv: thanks, i'm doing that now
18:04imirkin: which is basically what valgrind-mmt normally does
18:04imirkin: and then you can use demmt to decode the binary outputs
18:05luv: somehow valgrind-mmt didn't work for me ... i got an empty log after running demmt
18:06luv: executed as valgrind .... /.../xinit /.../xlogo
18:06imirkin: right, that won't help
18:06imirkin: xlogo just talks to the X server
18:06imirkin: not what you're interested in
18:07imirkin: valgrind-mmt will monitor communications of a process with /dev/nvidia*
18:07luv: which is the X server in this case
18:07imirkin: so ... logically ...
18:09luv: run valgrind ... /usr/lib/xorg/Xorg ? :)
18:11imirkin: unfortunately demmt has fallen into a bit of disrepair
18:12imirkin: but worst case, you can always use mmt2dedma to get a more textual representation
18:15luv: will do, just have to weld something up first :P
18:35luv: yup, this works
18:36luv: https://pastebin.com/kpQ8iUgG ... nice
18:40imirkin: so ... use the -m option :)
18:40imirkin: like i said - mild disrepair
18:48rhyskidd: mupuf / mwk: Any chance for a review & merge? https://github.com/envytools/envytools/pull/99
18:54mupuf: rhyskidd: sorry, i'm abroad for the weekend :) Remind me on monday :)
18:55rhyskidd: mupuf: OK
19:12luv: i have problems using either actually :( .... i suppose for gtx1060 i would do "nv50" ?
19:13karolherbst: actually it is nv136
19:14imirkin: probably -m 136 or -m nv136
19:14luv: dedma fails with can't grow to 0x4aac000 ... ok will try nv136
19:17luv: anyway, it looks like demmt knows the structs use by the nvidia driver https://github.com/envytools/envytools/blob/master/demmt/nvrm_ioctl.h#L84
19:17luv: i don't mind following manually
19:26luv: if i manually inspect the memory, the 32bytes do match struct nvrm_ioctl_call - so that's fine ... and ok ... no i follow the pointer (and size) ... is it possible to determine if that is a known structure somehow (based on mthd or cid maybe)?
20:03marvin42: Greetings, I was using NVidea's proprietary driver until now but I decided to give the Nouveau driver a chance. After applying the Noveau driver I rebooted but the resolution was very low. Henceforth, I did "apt get install xserver-xorg-video-noveau". It installed all necessary packages. * Then I rebooted and, at the time that the login screen should appear, the screen stays blank, with the cursor on the top left of the screen.
20:04imirkin: what gpu, what kernel? pastebin dmesg.
20:05marvin42: appearing and disappearing. * I've tried hitting the Shift key to get the GRUB menu but it doesn't show up. I've tried pressing Shift + Alt + F1 (or 1) to try and get to the command line but no luck. I'm able to access the HD using a Live CD. What can I do to revert the NVidia driver settings to the configuration that worked? I'm using LXDE on Lubuntu 17.04
20:07imirkin: it'll be easiest to just ssh in and fix things up
20:07marvin42: imirkin, https://pastebin.com/UuMZD3Nm
20:07luv: i would chrot and use "apt" to fix revert your changes
20:07marvin42: how do I ssh in? I'm new to Linux
20:07imirkin: marvin42: i see no mention of nouveau
20:07imirkin: that means that it's somehow disabled
20:08imirkin: you're going to be best off asking a distro-specific chan for support
20:08imirkin: people here don't know the ins and outs of every distro
20:08marvin42: imirkin, that's because I've used dmesg on this live session
20:08imirkin: ah ok
20:08marvin42: imirkin, I can't access the instalation where nouveau is active
20:09marvin42: imirkin, thanks, I'm going to ask for help at #lubuntu
20:09luv: mount /dev/sdXA /mnt; chroot /mnt /bin/bash; apt remove ... ; apt install ... ; rm /etc/X11/xorg.conf
20:10imirkin: luv: i think he's looking for a little more detailed help :)
20:10marvin42: thanks luv! I'll give it a try
20:12marvin42: luv, I'm guessing that I have to remove the xserver-xorg-video-noveau package with apt. But I'm not sure about what package I have to install next.
20:13luv: xserver-xorg-video-nvidia ?
20:13rhyskidd: in rnndb, is setting an array's length equal to 1 a special code to make the array open-ended?
20:14marvin42: luv, sudo: "unable to resolve host lubuntu: Connection refused"
20:14rhyskidd: I'm noticing the I2C_SLAVE array smashes over all later register addresses, even if I clearly define a reg32 offset
20:14imirkin: rhyskidd: no...
20:15imirkin: is it inside a group that's reused?
20:15rhyskidd: to fix this, I can add the <reg32> *before* the I2C_SLAVE <array> in the XML file, but that feels hacky
20:16rhyskidd: it is inside singular use of: <group name="g84_therm">
20:16rhyskidd: this is in pm/ptherm.xml
20:18rhyskidd: this is what I'm having to do: https://hastebin.com/vajidamixu.xml
20:19rhyskidd: but it would make more sense after the I2C_SLAVE array. Sadly that's not working ...
20:20imirkin: in these situations i tend to RTFS
20:20imirkin: or ask mwk
20:20rhyskidd: demmio just reports the register location as I2C_SLAVE+398
20:42mwk: rhyskidd: length equal to 0 makes it open-ended FWIW
20:42rhyskidd: yeh, that was my conclusion too from the code. thks
20:42rhyskidd: so I'm going to want to work out the max length (at least until next known reg32) and constrain
20:42rhyskidd: otherwise it's going to clobber over everything afterwards
20:43mwk: but umm
20:43mwk: what address are you having troble with?
20:43mwk: and what card?
20:43mwk: I2C_SLAVE seems well-sized to me
20:43rhyskidd: and 0x020798
20:43mwk: and 20798 should, by all right, be inside I2C_SLAVE space
20:44rhyskidd: should be MMIO32 R 0x020798 0x0000006d PTHERM.USE_A => UNK6D
20:44mwk: I don't see USE_A anywhere in rnndb
20:45rhyskidd: not yet ... :)
20:45mwk: well then
20:45mwk: add it inside I2C_SLAVE space
20:45mwk: unless you have good reason to believe I2C_SLAVE space no longer works like on earlier carda
20:46rhyskidd: ok, I'll fold the new regs inside I2C_SLAVE in the absence of other good reasons
22:37luv: can i find docs for nvrm_ioctl_call as defined here https://github.com/envytools/envytools/blob/master/demmt/nvrm_ioctl.h#L84 somewhere?
22:37luv: i'm trying to figure out what cid, handle and mthd is
22:37mwk: luv: cid is context id
22:38mwk: everything that opens /dev/nvidia* needs to create a context first
22:38mwk: and the cid is assigned by the kernel driver
22:38mwk: it's more or less a client id
22:38mwk: handles are used to identify objects
22:39mwk: whenever you create any kind of object, it needs a handle
22:39mwk: usually the client specifies the handle, but IIRC there are a couple ioctls where the kernel gives a handle instead
22:42mwk: and mthd is an identifier of some operation that you can do on an object
22:42mwk: which are not to be confused with hardwre or software mthds submitted through the PFIFO, these are an entirely separate kind of being
22:48luv: is this documented somewhere (so I don't have to bother you guys with so many questions) ? I'm trying to set a clock offset on a pascal gpu without X. I straced the X and got ioctl(13, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe3bb28240) = 0, I have a look at the after 0x7ffe3bb28240 and I can see that at the address +0x80 there is a 32bit integer that corresponds to the offset I change (it changes according to the offset I change via the nvidia's X tool)
22:48luv: the 32 bytes after 0x7ffe3bb28240 seem to correspond to nvrm_ioctl_call struct
22:48mwk: clock offset?
22:48luv: I tried to use valgrind-mmt and radare2 to guess the structs but didn't get anywhere :(
22:49luv: yup in NVCtrl.h in nvidia-settings it's called NV_CTRL_GPU_NVCLOCK_OFFSET ... i think it's how pascal oc is done
23:32karolherbst: luv: that's not a new thing
23:32karolherbst: there are several things to adjust the clocks if those coolbits are set
23:32luv: yup, agreed
23:33luv: i just haved used nvidia in a while :)
23:33karolherbst: there is also a volt offset somewhere
23:33karolherbst: but I think pascal oc is a bit different that those fields
23:34luv: well, pascal oc works for me if i have X running
23:34luv: just wanna go headless so im reverse engineering X<->kernel communication and writing a small open-source open to do the ioctl calls that nvidia_drv.so does now
23:35luv: s/open /program /:)