00:25 karolherbst: pqatsi: don't use bumblebee with nouveau
00:25 karolherbst: you can use prime offloading with a lower perf overhead
00:25 karolherbst: just DRI_PRIME=1 $command
00:26 karolherbst: pqatsi: but you do seem to run into other issues
18:28 Lyude: karolherbst: trying out the rpm patches now, https://paste.fedoraproject.org/paste/Lt8ldKCGpQUy5Ygq1yHw~Q I don't think this is related to said patches though but wondering if you've seen this already?
18:28 Lyude: GP104
18:34 karolherbst: Lyude: wait..
18:35 karolherbst: Lyude: https://github.com/karolherbst/nouveau/commit/c7e74b6254620e2d90d2702ac1d06a08d6edb46f
18:37 Lyude: karolherbst: ahh, alright, will tr in one moment
18:38 karolherbst: cool :)
18:38 karolherbst: Lyude: the issue is, that after runpm suceeds, secboot might fail again :/
18:38 karolherbst: really annoying
18:38 Lyude: karolherbst: I thought that was the bug we've been trying to fix all this time?
18:39 karolherbst: uhm... no
18:39 karolherbst: runpm fails
18:39 karolherbst: Lyude: I mean, there are mulitple bugs involved here
18:39 karolherbst: 1. secboot failing
18:40 karolherbst: 2. after runpm GPU can't wake up
18:40 karolherbst: 3. after succesful runpm secboot might fail
18:40 karolherbst: allthough the last issue I only saw on GPUs which required above workaround
18:41 Lyude: if that's the case I bet it's just a matter of figuring out how to get that workaround into the resume process
18:41 Lyude: erm, in such a way that it actually works I mean
18:41 Lyude: karolherbst: do we know what those two register writes actually do?
18:43 karolherbst: PMC.ENABLE
18:43 karolherbst: I think I turn the PMU or GR engine off and on
18:43 karolherbst: would have to check which bit
18:43 karolherbst: applying that workaround before suspending help in like 20% of the cycles :/
18:44 karolherbst: Lyude: anyway, not failing runpm already helps in itself, as stuff like lspci works without issues
18:44 Lyude: true, but we should try giving another shot at getting the second part working
18:44 karolherbst: and I guess if the GPU is only used for connected displays it might work as well?
18:45 karolherbst: Lyude: anyway, would be cool if you could verify that at least both things improve the situation. My secboot workaround fixing initial secboot and the runpm patches fixing runpm
18:47 Lyude: karolherbst: sure thing, I think i'm going to give a shot at playing around with this workaround as well
18:47 Lyude: very sick of having this issue on my mind
18:52 Lyude: karolherbst: yeah, that workaround doesn't seem to work on this P72
18:52 Lyude: the on/off again one
18:53 Lyude: karolherbst: I just finished updating the bios on the HP machine that I've got with a pascal GPU, so I'll try that one next
18:55 karolherbst: :/
19:00 Lyude: karolherbst: wait, when was the last time you updated that workaround?
19:00 Lyude: erm, refactored it
19:04 Lyude: karolherbst: actually-if you have a machine that workaround works with, can you read mmio reg 0x200 and tell me what the value is pre-nouveau loading?
19:23 karolherbst: Lyude: 0x40002020
19:23 Lyude: figured it'd be something like that
19:24 Lyude: karolherbst: the workaround doesn't work because pgraph isn't powered on at the point that you run that, but I'm guessing what's started before nouveau is loaded depend on the laptop manufacturer
19:24 karolherbst: mhhhh
19:24 Lyude: for this laptop, at least
19:24 karolherbst: interesting
19:24 karolherbst: maybe turn it on/off/on then? :D
19:24 karolherbst: but I am sure there is a better solution for that
19:24 karolherbst: it's just that this is secure boot related and super annoying to debug :/
19:27 Lyude: hm, it doesn't seem like pgraph is enabled on your gpu either
19:27 Lyude: although it might just be that it's on at the point that code gets run, hm.
19:29 Lyude: karolherbst: jfyi as well, 0x40002121 is what I see on the P72
19:29 karolherbst: yeah.. I think at that point several engines are enabled
19:29 Lyude: karolherbst: mind getting a read of that register before your workaround and letting me know what the value is?
19:30 Lyude: (also, any idea what GPCCS stands for?)
19:33 karolherbst: Lyude: 0x5c6cf1e1
19:33 karolherbst: Lyude: CS: context switching afaik
19:34 karolherbst: GPC is essentially the SM, more or less. More like also what's around it
19:34 karolherbst: with the frontend context and whatnot
19:51 Lyude: karolherbst:did you see my last message before the network died?
19:52 karolherbst: nope
19:52 Lyude: karolherbst:the firmware is initialized on bootup on this P72
19:52 Lyude: it's posted, even
19:53 Lyude: which might explain some things
19:53 Lyude: as well: it seems that we get to load the HS blob, it's just the final falcon reset that fails
19:54 karolherbst: ohh, I forcePost when loading nouveau
19:54 Lyude: karolherbst: either way, i think it's failing specifically on the GPCCS falcon
19:54 karolherbst: yeah...
19:54 karolherbst: it stops booting
19:54 Lyude: no-it stops resetting!
19:54 karolherbst: that's the mmio read fault
19:54 Lyude: i get no mmio fault btw
19:55 karolherbst: the falcon just stops and vanishes
19:55 karolherbst: ohhh
19:55 karolherbst: interesting
19:55 Lyude: karolherbst: mind loading nouveau with no force post and your 0x200 workaround removed, and debug=secboot=debug then see where in the secboot process it stops?
19:56 Lyude: i bet it's somewhere different
20:00 karolherbst: Lyude: mhh... maybe that force posting was causing an issue all along :/
20:00 Lyude: yeah, force posting usually isn't a good idea
20:00 karolherbst: ahh, now it fails
20:00 karolherbst: Lyude: ohh btw, I have a patch to make those timeouts 0.2s long :D
20:00 karolherbst: that eases debugging a lot
20:01 karolherbst: Lyude: https://gist.githubusercontent.com/karolherbst/41fd33da41ba0d4c59545939037eed10/raw/ece9c6bac932e85ea69d3dba996b72cddda77f1f/gistfile1.txt
20:02 Lyude: karolherbst: mind reading the value of 0x200 right before nouveau starts doing your workaround?
20:02 Lyude: the 0x200 & ~0x1000 & 0x1000 one I mean
20:03 karolherbst: 0x5c6cf1e1 :p
20:03 Lyude: interesting, same one as on here
22:40 Lyude: holy shit
22:41 Lyude: karolherbst: your patches fix runtime PM on this HP laptop
22:41 Lyude: nfi what is going on with the P72
22:41 karolherbst: cool :)
22:41 Lyude: but this is very very very very good omg
22:41 Lyude: finally some hope!!!!
22:41 karolherbst: well
22:41 karolherbst: for a wild guess, that's good enough :D
22:41 karolherbst: well
22:41 karolherbst: more or less wild
22:41 karolherbst: debugging devinit just takes time :
22:41 karolherbst: /
22:44 Lyude: karolherbst: gonna go through and review these, we should get these in asap
22:44 Lyude: airlied: ^ :)
22:44 karolherbst: hey :D we don't even know if those might break on other laptops :D
22:44 Lyude: i'll test it on other laptops
22:45 Lyude: and either way even if it did, we should figure out how to get this working for laptops that it doesn't break because this is a huge step in the right direction
22:45 Lyude: *how to just get this working for laptops it doesn't break and not other ones
22:45 Lyude: honestly though I doubt it will
22:46 karolherbst: yeah... I mean this code is enabled for kepler since a long time
22:46 karolherbst: for the reclocking path I mean
22:46 karolherbst: so it's a bit tested at least
22:46 karolherbst: but.. no idea about newer gens
22:46 karolherbst: but looking at mmiotraces, nothing seem to have changed in that regard anyhow
22:49 Lyude: oh actually it's a bit late so I might wait until tommorrow to review these patches but I definitely will
22:49 Lyude: *definitely will review them tommorw