02:33 mangix: oh boy more crashes
03:28 AndrewR: 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:29 rhyskidd: mangix: which card, and is the crash the same as a previously reported one?
03:51 mangix: rhyskidd: what crash?
09:21 karolherbst: okay, I think I need this unk1 byte in the CSTEP table for properly parsing the cstates for each pstate
09:24 karolherbst: there are even "broken" vbios with things like this: "0: pstate 0 index 1", this should have been pstate 7
09:25 karolherbst: okay, I think I got it now
12:14 karolherbst: funny, nvidia doesn't go eblow 575MHz on pstate a/7 allthough they could, wondering why that is
12:14 karolherbst: *a/f
12:15 pmoreau: Some more patches to review? I am in the mood this afternoon.
12:15 pmoreau: karolherbst: Do you prefer having your clk/subdev reviewed separately from your latest series?
12:15 karolherbst: pmoreau: you could review my patches :p
12:16 karolherbst: mhh
12:16 pmoreau: Going to :-)
12:16 karolherbst: I prefer the mesa series though
12:16 karolherbst: the gallium precise one would be perfect
12:16 karolherbst: ohhh
12:16 karolherbst: got merged
12:17 pmoreau: I did review part of that one IIRC
12:17 karolherbst: imirkin: thanks
12:17 karolherbst: pmoreau: yeah, I didn't noticed they got merge this night
12:17 karolherbst: so yeah, the clk update ones are good
12:17 karolherbst: pmoreau: well the latest
12:17 pmoreau: Ok
12:17 karolherbst: the 7 first patches are the clk update series
12:17 pmoreau: Yep, I realised that
12:19 karolherbst: oh my, I think it needs to be land everything at once or so in the end :/
12:22 karolherbst: mhhh
12:22 karolherbst: I think I lost some patches
12:27 karolherbst: okay, it was only one, and luckily I posted the hash here
12:27 karolherbst: 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:33 pmoreau: Okay
12:39 pmoreau: karolherbst: What was that dstate you are removing?
12:39 karolherbst: display
12:41 pmoreau: Care to elaborate a bit? :-D `nvkm_clk_dstate()` used to upclock/downclock if the refresh rate of the screen changed? oO
12:42 karolherbst: well it wasn't used at all
12:42 pmoreau: Sure, but what was it supposed to do?
12:42 karolherbst: but skeggsb had the idea that something could specify which pstate to use according to the needs of the display engine
12:42 karolherbst: like to drive all displays at those resoltuions and refresh rates, we need at least pstate a
12:42 karolherbst: or something
12:43 pmoreau: Ah, ok
12:43 pmoreau: Thanks for the explanation
12:43 karolherbst: 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:44 karolherbst: but how all those
12:45 karolherbst: *state functions were written, they weren't really helpful, because tstate and dstate could race against each other and switch pstates alternating
12:46 karolherbst: 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:47 karolherbst: this is important for dynamic reclocking
12:48 karolherbst: 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:50 pmoreau: I see
13:01 pmoreau: 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:01 pmoreau: Or is it that pstate will contain a pointer to the expected cstate, and cstate a pointer to the current cstate?
13:02 karolherbst: mhh I think the messages might be a bit outdated
13:02 karolherbst: but in the end I wanted to have a pointer to the current pstate and the current cstate
17:57 luv: hi so I think I have fount the ioctl on /dev/nvidiactl I was looking for
17:57 luv: ioctl(13, _IOC(_IOC_READ|_IOC_WRITE, 0x46, 0x2a, 0x20), 0x7ffe3bb28240) = 0
17:58 luv: 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:58 luv: confused
17:59 mwk: luv: nvidia likes to use pointers in ioctl params
17:59 mwk: so the struct passed by ioctl is just a small part of what's really read by the kernel
17:59 mwk: it contains a pointer to a bigger struct
17:59 luv: i see
18:01 luv: is there a way to retreive the structs? :)
18:01 mwk: well
18:01 mwk: obviously read them the same way the krnel does..
18:01 mwk: some disassembly required
18:02 luv: radare2 on nvidia_drv maybe ?
18:02 mwk: nah
18:03 mwk: just look for pointers in the data described by ioctl and follow them
18:04 luv: thanks, i'm doing that now
18:04 imirkin: which is basically what valgrind-mmt normally does
18:04 imirkin: and then you can use demmt to decode the binary outputs
18:05 luv: somehow valgrind-mmt didn't work for me ... i got an empty log after running demmt
18:06 luv: executed as valgrind .... /.../xinit /.../xlogo
18:06 imirkin: right, that won't help
18:06 imirkin: xlogo just talks to the X server
18:06 imirkin: not what you're interested in
18:07 imirkin: valgrind-mmt will monitor communications of a process with /dev/nvidia*
18:07 luv: which is the X server in this case
18:07 imirkin: right.
18:07 imirkin: so ... logically ...
18:09 luv: run valgrind ... /usr/lib/xorg/Xorg ? :)
18:09 imirkin: bingo
18:11 imirkin: unfortunately demmt has fallen into a bit of disrepair
18:12 imirkin: but worst case, you can always use mmt2dedma to get a more textual representation
18:15 luv: will do, just have to weld something up first :P
18:35 luv: yup, this works
18:35 luv: thanks!
18:36 luv: https://pastebin.com/kpQ8iUgG ... nice
18:40 imirkin: so ... use the -m option :)
18:40 imirkin: like i said - mild disrepair
18:48 rhyskidd: mupuf / mwk: Any chance for a review & merge? https://github.com/envytools/envytools/pull/99
18:54 mupuf: rhyskidd: sorry, i'm abroad for the weekend :) Remind me on monday :)
18:55 rhyskidd: mupuf: OK
19:12 luv: i have problems using either actually :( .... i suppose for gtx1060 i would do "nv50" ?
19:12 luv: nve0?
19:13 karolherbst: actually it is nv136
19:14 imirkin: probably -m 136 or -m nv136
19:14 luv: dedma fails with can't grow to 0x4aac000 ... ok will try nv136
19:17 luv: 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:17 luv: i don't mind following manually
19:26 luv: 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:03 marvin42: 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:04 imirkin: what gpu, what kernel? pastebin dmesg.
20:05 marvin42: 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:07 imirkin: it'll be easiest to just ssh in and fix things up
20:07 marvin42: imirkin, https://pastebin.com/UuMZD3Nm
20:07 luv: i would chrot and use "apt" to fix revert your changes
20:07 luv: chroot
20:07 marvin42: how do I ssh in? I'm new to Linux
20:07 imirkin: marvin42: i see no mention of nouveau
20:07 imirkin: that means that it's somehow disabled
20:08 imirkin: you're going to be best off asking a distro-specific chan for support
20:08 imirkin: people here don't know the ins and outs of every distro
20:08 marvin42: imirkin, that's because I've used dmesg on this live session
20:08 imirkin: ah ok
20:08 marvin42: imirkin, I can't access the instalation where nouveau is active
20:09 marvin42: imirkin, thanks, I'm going to ask for help at #lubuntu
20:09 luv: mount /dev/sdXA /mnt; chroot /mnt /bin/bash; apt remove ... ; apt install ... ; rm /etc/X11/xorg.conf
20:10 imirkin: luv: i think he's looking for a little more detailed help :)
20:10 marvin42: thanks luv! I'll give it a try
20:10 luv: :)
20:12 marvin42: 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:13 luv: xserver-xorg-video-nvidia ?
20:13 rhyskidd: in rnndb, is setting an array's length equal to 1 a special code to make the array open-ended?
20:14 marvin42: luv, sudo: "unable to resolve host lubuntu: Connection refused"
20:14 rhyskidd: I'm noticing the I2C_SLAVE array smashes over all later register addresses, even if I clearly define a reg32 offset
20:14 imirkin: rhyskidd: no...
20:15 imirkin: is it inside a group that's reused?
20:15 rhyskidd: to fix this, I can add the <reg32> *before* the I2C_SLAVE <array> in the XML file, but that feels hacky
20:16 rhyskidd: it is inside singular use of: <group name="g84_therm">
20:16 rhyskidd: this is in pm/ptherm.xml
20:18 rhyskidd: this is what I'm having to do: https://hastebin.com/vajidamixu.xml
20:19 rhyskidd: but it would make more sense after the I2C_SLAVE array. Sadly that's not working ...
20:20 imirkin: in these situations i tend to RTFS
20:20 imirkin: or ask mwk
20:20 rhyskidd: demmio just reports the register location as I2C_SLAVE+398
20:42 mwk: rhyskidd: length equal to 0 makes it open-ended FWIW
20:42 rhyskidd: yeh, that was my conclusion too from the code. thks
20:42 rhyskidd: so I'm going to want to work out the max length (at least until next known reg32) and constrain
20:42 rhyskidd: otherwise it's going to clobber over everything afterwards
20:43 mwk: but umm
20:43 mwk: what address are you having troble with?
20:43 mwk: and what card?
20:43 rhyskidd: GP107
20:43 mwk: I2C_SLAVE seems well-sized to me
20:43 rhyskidd: and 0x020798
20:43 mwk: and 20798 should, by all right, be inside I2C_SLAVE space
20:44 rhyskidd: should be MMIO32 R 0x020798 0x0000006d PTHERM.USE_A => UNK6D
20:44 mwk: I don't see USE_A anywhere in rnndb
20:45 rhyskidd: not yet ... :)
20:45 mwk: well then
20:45 mwk: add it inside I2C_SLAVE space
20:45 mwk: unless you have good reason to believe I2C_SLAVE space no longer works like on earlier carda
20:46 rhyskidd: ok, I'll fold the new regs inside I2C_SLAVE in the absence of other good reasons
22:37 luv: 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:37 luv: i'm trying to figure out what cid, handle and mthd is
22:37 mwk: luv: cid is context id
22:38 mwk: everything that opens /dev/nvidia* needs to create a context first
22:38 mwk: and the cid is assigned by the kernel driver
22:38 mwk: it's more or less a client id
22:38 mwk: handles are used to identify objects
22:39 mwk: whenever you create any kind of object, it needs a handle
22:39 mwk: usually the client specifies the handle, but IIRC there are a couple ioctls where the kernel gives a handle instead
22:42 mwk: and mthd is an identifier of some operation that you can do on an object
22:42 mwk: which are not to be confused with hardwre or software mthds submitted through the PFIFO, these are an entirely separate kind of being
22:44 luv: thanks!
22:48 luv: 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:48 luv: the 32 bytes after 0x7ffe3bb28240 seem to correspond to nvrm_ioctl_call struct
22:48 mwk: clock offset?
22:48 luv: I tried to use valgrind-mmt and radare2 to guess the structs but didn't get anywhere :(
22:49 luv: 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:32 karolherbst: luv: that's not a new thing
23:32 karolherbst: there are several things to adjust the clocks if those coolbits are set
23:32 luv: yup, agreed
23:33 luv: i just haved used nvidia in a while :)
23:33 karolherbst: there is also a volt offset somewhere
23:33 karolherbst: but I think pascal oc is a bit different that those fields
23:34 luv: well, pascal oc works for me if i have X running
23:34 luv: 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:35 luv: s/open /program /:)