16:09 jbara: Hello
16:09 jbara: karolherbst: sorry for reporting this late
16:10 jbara: I should note that I only tried wayland for this
16:11 jbara: After applying the patch , I was only able to start a graphical session when the computer boots up with the HDMI plugged in
16:11 karolherbst: mhh yeah... so powering on the GPU at runtime is still broken, or even broken even more with that applied
16:13 jbara: well , I tried exporting the variable you mentioned and it did nothing
16:13 jbara: and I should note that after applying the patch , starting the graphical session on my normal monitor (using amdgpu) just hangs and stops receiving input
16:13 jbara: BUT
16:13 karolherbst: yeah.. so the GPU probably is inaccisible and you might also see the same errors as before in dmesg or something?
16:14 jbara: I'll be honest with you , i didn't check dmesg (I was busy and just rebooted with another kernel)
16:14 jbara: I will send the output of dmesg for both cases of the bootup
16:14 jbara: just to let you know , hotpug works if the boot happens with the HDMI plugged in
16:15 karolherbst: yeah.. don't worry then. I suspect nobody has a fix for it ready anyway, and asking vendors for docs was always unsuccessful in the past :/
16:15 jbara: (so removing the hdmi and plugging it again works perfectly=
16:15 karolherbst: mhhh
16:15 jbara: )
16:15 karolherbst: did you wait long enough between replugging it?
16:15 karolherbst: like 10 seconds or so?
16:15 jbara: I waited way longer .. don't worry
16:15 karolherbst: ahh, okay
16:15 karolherbst: that's interesting though
16:16 karolherbst: sadly I don't have access to hardware being broken so I wasn't able to do any investigations on the matter
16:16 karolherbst: might have to poke OEMs a bit harder to get samples
16:16 jbara: will sharing dmesg output help ?
16:17 karolherbst: not with fixing it
16:17 karolherbst: but it helps getting an idea on what's happening
16:17 karolherbst: I've debugged this with intel + nvidia a few years ago and it was just the same mess
16:18 karolherbst: need to do some poking at the hardware to get a better understanding on how the firmware/hardware interactions are
16:18 karolherbst: sadly almost all of that is implemented in the UEFI/ACPI firmware
16:19 jbara: which is closed source
16:19 jbara: :'(
16:19 karolherbst: well.. you can extract the bytecode
16:19 karolherbst: and decompile it and everything
16:19 karolherbst: but it's still super hard to read
16:19 karolherbst: but every system having different versions/implementations makes things more annoying
16:20 jbara: I never got a clear answer about whether decompiling is legal or not
16:20 karolherbst: what I really need is the proper technical spec from nvidia telling me what to do :D
16:20 karolherbst: it's okay as long as you don't share your insights :D
16:20 jbara: they'll probably never share anything
16:20 jbara: anw
16:20 karolherbst: but yeah.. kind of a grey area
16:20 jbara: here's my working dmesg http://0x0.st/o4t-.log
16:21 karolherbst: heh.. stalls
16:21 karolherbst: but yeah.. looks okay
16:21 jbara: the one with hotplug working and everything exactly how we want it (when I boot with the hdmi plugged)
16:21 jbara: and i'll give you the other one in just a sec
16:21 karolherbst: it could be that there is something we have to do when booting the machine up...
16:21 jbara: what does stalls mean ?
16:21 jbara: lmao
16:21 jbara: figuring that out wouldn't be easy , i assume
16:22 karolherbst: jbara: I meant those "rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 9-... } 7 jiffies s: 21 root: 0x200/." errors
16:22 jbara: I saw those , but didn't get what they mean
16:22 jbara: I should've looked it up
16:22 karolherbst: yeah.. not quite sure either..
16:22 karolherbst: also the stack seems to be random
16:23 karolherbst: or maybe it's indeed something with nouveau and udevd polls stuff
16:29 jbara: hey , back after a reboot
16:29 jbara: or two
16:30 jbara: http://0x0.st/o4tm.log
16:30 jbara: this is the boot dmesg
16:30 jbara: when it's not working
16:31 karolherbst: heh.. there is nothing...
16:31 jbara: after saving dmesg I executed `dmesg -w > log & sway` to keep dmesg saving stuff to the log for as long as I can
16:31 karolherbst: what's a "DRI_PRIME=1 glxinfo" reporting?
16:32 jbara: one sec ,
16:33 jbara: I want to mention that sway doesn't start .. everything stops receving input (as I mentioned earlier) and pressing the shutdown button starts a loong fifo PBDMA0 list of errors
16:33 jbara: the dmesg log that I set to keep saving until shutdown is 80MB log
16:34 karolherbst: ahh yeah....
16:34 jbara: no need to share that right ?
16:34 karolherbst: so the GPU probably doesn't respond and everything is going downhill
16:34 karolherbst: yeah...
16:34 karolherbst: if the system crashes, it crashes
16:38 jbara: just finished emerging mesa-progs , and I wasn't able to execute glxinfo because it was unable to open display
16:39 jbara: and I can't start a display because everything will stop reveiving output (excempt the shutodwn button which will get me to the error loop so I'll have to force shutdown anyway)
16:40 jbara: I assume the problem should be ignored for now
16:41 jbara: (until I learn to be a better dev and try to solve my problems on my own :p)
16:41 jbara: thank you karolherbst