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