17:59rootkea: Hello, I'm using Debian 12 with Nvidia GK208M GeForce GT 740M GPU. I already have firmware-misc-nonfree installed and lspci also shows the Nvidia GPU. But the driver is failing to load. dmesg throws this error: "failed to load nouveau/nv108_fuc084d". How do I fix this?
18:00rootkea: Here's my lspci and relevant dmesg log: http://paste.debian.net/1284385/
18:01Lyude: emersion: btw, I am planning on enabling atomic by default in the near future hopefully
18:02karolherbst: Lyude: btw.. we should do this before doing so: https://gitlab.freedesktop.org/karolherbst/nouveau/-/commit/8ad0190520652e199c6f9706d9401e3314b4c3db
18:02karolherbst: probably....
18:03karolherbst: I think...
18:03karolherbst: something along those lines at least
18:03Lyude: karolherbst: send it on the ml! and yeah I'm probably going to be doing a good bit of testing before we flip the swithc
18:04Lyude: Honestly I don't expect things to go too wrong - I've been leaving nouveau.atomic=1 set on a few of my machines for a while now and haven't seen any issues
18:04karolherbst: yeah..
18:04karolherbst: it's just...
18:04karolherbst: it doesn't prevent setting bad modes
18:04karolherbst: that's all
18:04Lyude: karolherbst: being on legacy you mean?
18:04karolherbst: both
18:04karolherbst: we don't validate userspace modes at all
18:05karolherbst: so userspace can give us any mode and we just eat it
18:05karolherbst: and then things break obviously
18:05Lyude: oh hm. and the connector check there isn't enough I assume?
18:05karolherbst: yeah soo.. the fun thing about the connector check is, it's only called on modes send to userspace
18:06karolherbst: hence why I've wrote the patch above
18:06karolherbst: it still breaks X horribly because sometimes it tries to start with a broken mode, but...
18:06Lyude: o-o, that is very surprising to me? I'm pretty sure we use connector checks for a couple of things-ooooooh wait this is mode_valid
18:06karolherbst: .... yeah ....
18:06Lyude: that explains things
18:06karolherbst: anyway....
18:06karolherbst: we need this check in atomic_check
18:06karolherbst: or something else
18:06karolherbst: but HDMI is stupid
18:07karolherbst: sooo.. I've tried doing mode_valid on the encoder, but...
18:07karolherbst: TMDS can be duallink on DVI
18:07karolherbst: it's all annoynig
18:07karolherbst: anyway... my patch fixing some stuff I was running into
18:07Lyude: oh btw - you need to do if (IS_ERR(crtc_state)) for that, since there isn't a guarantee we can grab the mode
18:07karolherbst: soo.. fun fact
18:07karolherbst: ahhh
18:07karolherbst: okay
18:08karolherbst: anyway... on my GPU here the max is 165 MHz and modesetting DDX decided to add (besides the perfectly fine FHD@60 150MHz mode) another FHD@60 mode being 356 MHz :D
18:08karolherbst: double scaned or whatever it's called
18:09karolherbst: so obviously that breaks things if X uses that as the default mode...
18:09Lyude: eesh, that's really weird. I wonder why it thinks that's a good idea
18:10karolherbst: no clue :)
18:10karolherbst: at least is able to detect that moving to that mode is invalid
18:10karolherbst: just... it ignores any errors when it's the default one it chooses to start with
18:11karolherbst: at least it works with the nouveau ddx...
18:12Lyude: oh btw - looking into the DP issue today, going to write up a hacky fix and then see how much work my idea with passing the drm_dp_aux bus through nvkm works. anyway-I assume it actually at least checks the mode correctly with that check in place (and atomic enabled?)
18:12karolherbst: but yeah.. will fix up that patch and send it out
18:12karolherbst: uhhhhh
18:12karolherbst: yeah, for dp it _should_ work
18:12karolherbst: I know it doesn't when you use HDMI over DP :D
18:12karolherbst: but that case is super weird
18:13karolherbst: I think...
18:13karolherbst: anyway... with my patch it gets validated properly against the mode
18:13karolherbst: but it also fixes if you don't have atomic enabled, so it's a win in either case
18:15karolherbst: Lyude: ohh btw.. it might be modesetting adding those modes, because it only saw FHD on a 4K display...... :D so maybe that's just the reason on why it's happening
18:16Lyude: well, I think I'm nearing the end of some of my RH work so I'm probably going to be going back to focusing getting universal planes working 100% (as in, wndw ownership too) and then enable atomic
18:16karolherbst: nice
18:16karolherbst: I wished we had the hardware to fix DP1.3 bugs :')
18:16karolherbst: there are some users complaining about that being broken
18:17Lyude: i don't know which bug you're talking about but it's probably a safe bet I have some hardware for it
18:18karolherbst: the one you know: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211
18:18karolherbst: and...
18:19karolherbst: huh.. where is the other
18:19karolherbst: Lyude: https://gitlab.freedesktop.org/drm/nouveau/-/issues/208
18:20karolherbst: I tried it with my HDMI to DP connector, but.. uhhh.. that's a weird one and I run into some other bugs with that.. like invalid modes :)
18:20Lyude: gotcha, I'll try to take a look today and see what needs to happen
18:20karolherbst: I only have a 4K@60 DP display
18:20Lyude: karolherbst: btw, I think we are at the time of year we're trying to spend the hw budget on stuff
18:20Lyude: so you probably can get some more hardware if you ask
18:20karolherbst: sadly, it's kinda my fault users run into this more often, because... of my fix with lowering the bpc :')
18:20karolherbst: I already asked
18:21karolherbst: so some users even had perfectly working setups at 30hz, but that fix enabled 60hz (because it's still within the limits), but that hits some DP bugs :(
18:47Lyude: ok - hack is done hopefully, let's try the actual fix now :)