05:16airlied[d]: skeggsb9778[d]: trying your 00.03-module branch, nvkm loads but nouveau doesn't
05:17skeggsb9778[d]: from modprobe, or initramfs?
05:17skeggsb9778[d]: i don't believe i tried the latter
05:19airlied[d]: just from a boot
05:19skeggsb9778[d]: yeah, ignore the question, it was dumb
05:27skeggsb9778[d]: the MODULE_DEVICE_TABLE got lost in a rebase somewhere, but it's still not loading here either
05:43airlied[d]: when I added that it seemed to load
05:44airlied[d]: though machine isn't stable
05:44skeggsb9778[d]: that's probably not the module change - would you be able to find where that breaks by any chance? 🙂
05:45skeggsb9778[d]: even just ioctl removal, or auxdev
05:47airlied[d]: https://paste.centos.org/view/raw/b22de332
05:47airlied[d]: backlight oops
05:58skeggsb9778[d]: oh, hmm
06:02asdqueerfromeu[d]: airlied[d]: I'm not sure where I can find it though (skeggsb is gone both from GitHub and FDO GitLab)
06:03airlied[d]: bskeggs/nouveau on gl
06:12skeggsb9778[d]: airlied[d]: gsp backlight is just broken from the beginning 😛
06:16skeggsb9778[d]: airlied[d]: https://bpa.st/HAUA
06:18skeggsb9778[d]: that applies even before those series', but can't guarantee what else might go wrong now - those paths were disconnected before
06:19skeggsb9778[d]: probably at worst, just RM not liking the ctrl call
06:22airlied[d]: wierd no oops before I don't think
06:23skeggsb9778[d]: no, the "ioctl" would've silently failed with -EINVAL
06:24airlied[d]: ouch
06:27airlied[d]: loads, doesn't oops, gdm fails to come up though a few wndw errors
06:27airlied[d]: nouveau 0000:01:00.0: swiotlb buffer is full when gdm fails
06:27airlied[d]: might be something misconfigures around dma masks
06:29skeggsb9778[d]: hah
06:30skeggsb9778[d]: yeah, i know why
06:31skeggsb9778[d]: https://gitlab.freedesktop.org/bskeggs/nouveau/-/commit/f8f2d994b21696d623001e6800b939e3de81c1a7
06:32skeggsb9778[d]: this was added late, and means the check done in nvkm_device_pci_probe() falls back to 32-bit
06:32skeggsb9778[d]: thanks for pointing that out, i'll fix it before a v2 of the auxdev series
06:32skeggsb9778[d]: why doesn't this fail for me?
06:34airlied[d]: you got iommu turned on?
06:35skeggsb9778[d]: i see a whole bunch of iommu messages in dmesg, so i'd say yes?
06:35airlied[d]: boots to gdm if I turn on the iommy
06:37skeggsb9778[d]:makes note to test without iommu sometimes
06:42airlied[d]: might be good to get the bl fix just out on it's own so we can backport it
06:43airlied[d]: btw I still see pm runtime delays on device open which makes sense, I wonder if we can move those down to the nvif layer or if locking will mess it up
06:45skeggsb9778[d]: yeah i will, i wrote it against the cleanup series branch to make sure it wouldn't conflict
06:47skeggsb9778[d]: ideally there wouldn't be any/much nvif interactions after allocating channels etc
06:47skeggsb9778[d]: that's not the case today because of mmu, but, that doesn't belong where it is anyway
07:03skeggsb9778[d]: could probably push the init done in open() to the first channel alloc, maybe
07:06airlied[d]: I need to work out what nvk needs to do in enumerate devices andd see where that might hit hw or gsp
07:06skeggsb9778[d]: it's all mmu stuff actually.. that problem will go away if i just move it to drm
07:09skeggsb9778[d]: airlied[d]: we could definitely cache whatever is needed there too
07:09airlied[d]: I think it might create a channel but not actually need to, have to check that
07:09airlied[d]: yes I think we could cache it in the frontend driver and avoid waking up the backend it might work out
07:11skeggsb9778[d]: it might have to create a channel to figure out classes
07:12airlied[d]: yeah so we'd need new uapi to avoid that maybe
07:12skeggsb9778[d]: yeah. it wasn't (cleanly) possible before
07:12skeggsb9778[d]: the remove-ioctl series fixes that up, but doesn't add uapi
07:13skeggsb9778[d]: someone could if it's wanted/needed before nova
07:13skeggsb9778[d]: (the runlist/engine/class mappings are returned up-front when allocating a device now)
15:08tiredchiku[d]: 555 driver out of beta: https://www.nvidia.com/download/driverResults.aspx/228214/en-us/
15:51gfxstrand[d]: airlied[d]: skeggsb9778[d] Do we have a kernel story for multiple firmware versions yet? Blackwell is right around the corner and those are going to need a GSP bump.
16:01redsheep[d]: Is ada planned to be the last new generation supported on the current kmd?
16:07notthatclippy[d]: tiredchiku[d]: Hold your horses on that a little bit will you :D
16:07notthatclippy[d]: Although as far as gsp.bin is concerned, you can consider it stable
16:09tiredchiku[d]: tiredchiku[d]: oh I just post driver updates here, casually 😅
16:11notthatclippy[d]: I'm kidding, we just snafu'd on the versions so openrm github is a bit ahead of the nvidia.com version and until we sort that out you're likely to have some Dwarf Fortress kind of Fun if you mix and match
16:11tiredchiku[d]: I know some people here swap between NVK and nvprop, for various reasons, from time to time
16:11tiredchiku[d]: myself included
20:29skeggsb9778[d]: gfxstrand[d]: i did quickly hack-up r550 support a few weeks back to see what it'd look like, but i also completely ruined r535 support in the process 😉 i'll look at it again, but after i've landed more of the current queue of patches and figured out how to (more) cleanly integrate both
20:29gfxstrand[d]: That's fair
20:29gfxstrand[d]: As long as it's on your mind and you think we have a path, that's good enough for me.
20:30gfxstrand[d]: I just want some notion that when I buy a 5090 in a couple months, I'll be able to boot it. 🙂
20:44anarsoul: hey folks, is it a known issue of steam causing "gsp: mmu fault queued" and crashing on nouveau or nvk+zink?
20:45anarsoul: I can't find anything similar in gitlab issues
20:46redsheep[d]: Mmu faults with steam? No, I've tested that a pretty good amount and that hasn't been happening for me. How new is your mesa?
20:46airlied: also new kernel
20:47airlied: esp if your gpu sleeps
20:48redsheep[d]: gfxstrand[d]: I'm surprised how many of us are crazy enough to be considering that by the number of sames lol
20:48redsheep[d]: Hopefully it isn't $3000
20:50anarsoul: redsheep[d]: 24.1.2 from arch repos
20:50anarsoul: airlied: 6.9.6
20:51gfxstrand[d]: redsheep[d]: I need a big GPU. All my Turing+ cards are *60s
20:51snektron[d]: H100
20:52anarsoul: running steam with DRI_PRIME=1 results in https://gist.github.com/anarsoul/c210572d579bed81d0f42619bfc71f5a
20:52redsheep[d]: gfxstrand[d]: Yeah I think of the 4 of us you're definitely the most legitimately in need of one to probe the limits of the driver
20:54redsheep[d]: anarsoul: If you're on arch maybe try vulkan-nouveau-git and the lib32 variant for bleeding edge nvk
20:54redsheep[d]: I haven't been testing the releases at all
20:55redsheep[d]: And I think I'm one of the only frequent users of NVK+zink, for better or worse
20:58tiredchiku[d]: I've also had trouble with steam
20:58tiredchiku[d]: both with and without Zink
20:59tiredchiku[d]: had to edit the desktop file to make it not prefer the discrete GPU (I have a laptop) and that helped, but I know that's not an option for everyone
21:00redsheep[d]: Hmm could an mmu fault be related to prime? That seems weird
21:01tiredchiku[d]: I don't remember seeing an mmu fault, however
21:01anarsoul: tiredchiku[d]: laptop user here as well
21:04redsheep[d]: I'm also using the gfxstrand/nvk 6.8.7 kernel which has a load of patches for nouveau. Not sure how many have made it into 6.10
21:05tiredchiku[d]: redsheep[d]: that kernel is 4 patches on top of plain 6.8.7, of which 2 made it in as of 6.10-rc3
21:05redsheep[d]: Which ones still aren't in?
21:05tiredchiku[d]: I wrote a new pkgbuild that includes the remaining packages on top of the current -rc
21:06tiredchiku[d]: redsheep[d]: I haven't checked in 2 weeks, I'll let you know in ~8 hours?
21:07tiredchiku[d]: tiredchiku[d]: https://gitlab.com/Sid127/linux-gfxstrand
21:07tiredchiku[d]: I have to update it for rc6
21:08tiredchiku[d]: or is it rc5
21:08tiredchiku[d]: idk
21:09anarsoul: do I understand correctly that nvk doesn't get much testing with prime?
21:10tiredchiku[d]: I would disagree
21:13gfxstrand[d]: Prime should be fine
21:15redsheep[d]: I'd expect there are more prime users than not
21:17airlied: anarsoul: okay don't think 6.9.6 has the fix in it
21:18airlied: you can boot with nouveau.runpm=0 and see if it goes away
21:18anarsoul: let me try that
21:21anarsoul: airlied: unfortunately it didn't help
21:22anarsoul: the option did take effect, GPU doesn't sleep now
21:27asdqueerfromeu[d]: skeggsb9778[d]: Does it have DP audio working?
21:33skeggsb9778[d]: i think that should already work? (unless it's MST, which nouveau's never added support for so far)
21:34skeggsb9778[d]: but i did test SST audio before initial posting and it worked for me then
21:43mohamexiety[d]: think rhed0x ran into it not working, but not sure what type that was
21:47rhed0x[d]: huh
21:47rhed0x[d]: what are you talking about?
21:49asdqueerfromeu[d]: skeggsb9778[d]: I don't think I'm using MST and it isn't working (the audio device shows up but with no actual sound)
21:49asdqueerfromeu[d]: I'm actually using a USB-C port with DisplayPort alt mode (or maybe HDMI alt mode?) that's connected to a hub with an HDMI port to get the video signal (but there's no audio/video issues without GSP)
21:49asdqueerfromeu[d]: rhed0x[d]: Audio being broken with GSP
22:02skeggsb9778[d]: oh, interesting - if it's not MST then i'd expect it to work, but i'll re-test that here shortly
22:19redsheep[d]: I'm testing in the most basic config possible, non prime, no adapter of any kind, just straight full size dp to dp on a monitor with speakers and I get the same result here on Ada
22:19redsheep[d]: Audio device populates, but there's no output
22:20airlied[d]: I think I did a quick test a few weeks back and confirmed, looked at code, couldn't spot anything obviously missing
22:21skeggsb9778[d]: i've just been playing musical chairs with cables, about to test now on ampere
22:22redsheep[d]: airlied[d]: Oh? I must be misremembering, I thought somebody had said it was not expected to work. I thought this was another waiting for Nova situation
22:22skeggsb9778[d]: i don't expect audio would require any drastic changes to fix if it's needed
22:27redsheep[d]: Laptops with DP alt mode from the dgpu would certainly benefit. Not nearly so relevant for desktop
22:35skeggsb9778[d]: it's working for me on ga104
22:35skeggsb9778[d]: direct DP connection to display
22:35skeggsb9778[d]: (after i re-built pipewire with the right USE flags :P)
22:36airlied[d]: I can't remember if I was on turing or ampere when I tried
22:36asdqueerfromeu[d]: skeggsb9778[d]: I'm on TU117
22:42redsheep[d]: skeggsb9778[d]: Rebuilt pipewire? What did you have to change?
22:42redsheep[d]: It is not working on ad102
22:45skeggsb9778[d]: i was missing sound-server, and some config - gnome was only showing me a dummy device despite showing up in /proc/asound
22:45skeggsb9778[d]: i've only half setup my dev system still
22:46redsheep[d]: Oh okay, so not something I would be having if I have otherwise working pipewire
22:46skeggsb9778[d]: no indeed
22:50redsheep[d]: Dodo are you using a recent kernel? Maybe the situation has changed, I will try Sid's branch based on 6.10
23:09skeggsb9778[d]: i'm not sure it's working on my ad104
23:10skeggsb9778[d]: the mode is super unstable and snowy in general (the cable i'm using is half busted), but audio doesn't work. i need to find another cable, i just swapped the good one to another machine
23:11redsheep[d]: Can you lower refresh rate to get the pixel clock down and stabilize?
23:11skeggsb9778[d]: oh, probably 😛
23:11skeggsb9778[d]: good idea
23:15skeggsb9778[d]: yeah, it's working on this gpu too
23:16redsheep[d]: Oh weird. Has that code been touched in the last few months? I probably tested 3 months ago
23:16redsheep[d]: I'm working on setting up another kernel to recheck my machine
23:19skeggsb9778[d]: the branch i'm using touches the interfaces basically everywhere. but, i did test ampere before all that too, and it worked. i don't *think* the code has otherwise been touched
23:19redsheep[d]: Hmm. Is that one of your branches in gitlab? I could try one of those
23:20skeggsb9778[d]: i don't expect it'll help, but yeah, the 00.02-auxdev branch is what i'm running on the ad104
23:21skeggsb9778[d]: i also have an ad104 laptop, which i'll get around to testing again at some point too - hopefully it'll fail 😛
23:23redsheep[d]: Ok to start with a sanity check I am able to get dp audio out of it with latest openrm on 6.9.6
23:24redsheep[d]: Stupid AMD memory issue makes it so my computer takes 90 seconds to clear bios so kernel testing is super slow going
23:26skeggsb9778[d]: yeah, both my personal desktop system, and dev box have that issue too
23:27skeggsb9778[d]: *really* annoying, and makes it hard to get into bios settings sometimes 😛
23:27skeggsb9778[d]: i could bump up the POST delay a bit, but it already takes forever
23:32redsheep[d]: If it is actually the very same issue turn off xmp/docp/expo if the reboot times are more of a pain than the performance loss
23:33skeggsb9778[d]: that actually may be worth doing on the dev box, which gets reboots *often*
23:38redsheep[d]: Wow surprisingly entirely vanilla 6.9.6 is actually doing an nvk+zink session quite well
23:38redsheep[d]: And does not have working dp audio