00:16fltrz: aha, I assume you couldn't read the final message as my screen froze?
00:18fltrz: so I had left min on when we unbind'ed the nvidia gpu, and then restarted and auto'd the audio device.... then I remembered min was still running with an open renderD128 context
00:19fltrz: it was exactly the moment I closed it that the screen froze, couldn't switch to the root tty either, cursor nor moving... so... I want to try that again, but this time without starting min at all
01:48owenh: Hi, how can I contribute updates to the wiki? Can I get developer access to <https://gitlab.freedesktop.org/nouveau/wiki> so I can open a pull request there? I asked on the mailing list on 2022-08-05 but didn't get any reply: <https://lists.freedesktop.org/archives/nouveau/2022-August/040616.html>. Thanks
05:15anholt: wat. I've replaced the board, the network cable, and the poe extractor, and still runner #1 periodically gets transmit queue timeouts. https://gitlab.freedesktop.org/anholt/mesa/-/jobs/28031302
11:08fltrz: karolherbst: am I perhaps supposed to install Bumblebee? Y/N even if N their documentation says theres a relevant requisite BIOS/UEFI option, so I'll look at that now
11:37RSpliet: fltrz: No, bumblebee and other instances of that is old tech and not supposed to be used anymore. Kernel+Mesa should support multi-GPU with a thing called "Prime"
11:43fltrz: RSpliet: thanks, I assume the same holds for bbswitch etc?
11:43karolherbst: yeah, don't use this stuff anymore
11:44fltrz: RSpliet: karolherbst said you might have had a possibly similar issue with some audio component preventing PRIME from working properly?
11:45fltrz: not sure how to find it in which mailing list
11:46karolherbst: fltrz: "[PATCH v2] ALSA: hda: Continue to probe when codec probe fails"
11:46fltrz: oh I should mention that when the kernel gets updated I get a few WARNINGS on missing firmwares one of which is about xhci_... or so
11:47karolherbst: it's a full thread
11:47karolherbst: but I don't actually know if it got fixed for real or not
11:50fltrz: vgaswitcheroo is also dated or part of PRIME?
11:53fltrz: lsmod | grep snd returns http://ix.io/49WH
11:53fltrz: btw I do have sound
11:55fltrz: is this an ordering issue where delaying one driver until another finished initializing would fix things?
11:56fltrz: i really regret not recording when the change took place
11:56fltrz: (change being laptop being generally hot instead of cold)
12:16fltrz: karolherbst: is it possible I need to add the right ASUS / Realtek related quirk(s) from https://docs.kernel.org/sound/hd-audio/models.html or is that at a much later stage?
12:16karolherbst: fltrz: no, the audio driver is just buggy :P
12:17karolherbst: though they might fix it via quirks
12:34fltrz: I'm not sure what the sequence of events is
12:36karolherbst: doesn't matter with the audio driver anyway. They have this weirdo late init thing going on, where they successfully load the driver for a sound device, but might fail later in an async manner messing things up. And that "messing things up" case doens't deal with the runpm bits properly afaik.
12:36karolherbst: It's simply a known bug they didn't fix yet
12:37fltrz: what is runpm?
12:38karolherbst: runtime power management
12:39fltrz: is there a way to retrieve the firmware warnings from during kernel build?
12:41fltrz: could they be relevant, I guess I can reinstall the kernel
12:42karolherbst: it's not really a kernel thing, but mostly initramfs I suspect
12:46fltrz: if dmesg stream was gathered systematically, I guess ML could detect (at least retroactively) sudden changes that don't immediately affect user (no more suspending discrete gpu), and from there the code change identified
12:47karolherbst: or well.. just use the latest linux-firmware package
12:47fltrz: I think arch does that, I meant more like if it was a regression
12:47karolherbst: no, it's not
12:48fltrz: ive been seeing the same firmware warning messages for a long while during kernel build
12:49fltrz: core/linux-firmware 20220815.8413c63-1 [installed]
12:52karolherbst: fltrz: but what firmware is missing specifically? Anyway, what you are hitting is simply a bug in the sound driver, there is really no point in digging deeper, because that's all there is to it
12:52fltrz: ls /sys/class/sound/* gives http://ix.io/49WU
12:53fltrz: karolherbst: I wish I recollected, the one I remember most is the xhci one because it sounded so fundamental, especially the first time I saw it
12:53karolherbst: xhci is just usb
13:01fltrz: just reinstalled linux-hardened, heres the warnings: http://ix.io/49WW
13:01fltrz: I notice alc94xx
13:02fltrz: thats an audio chi
13:02fltrz: not sure if its actually missing lol
13:02karolherbst: sure, but if it would be relevant it would have complained already
13:03fltrz: I actually wonder what audio chip I have
13:06fltrz: I'm picturing 2 drivers telling each other to go first
13:20fltrz: so which information do I need to gather, and what should I write and where should I submit this bug? I never submitted a bug with the linux kernel before
13:22karolherbst: fltrz: two options: 1. against your distribution or 2. upstream. But the latter should only be done if you compiled it yourself
13:22karolherbst: could just file an arch bug and attach your dmesg and maybe also lspci -vv
13:23karolherbst: and then they either forward it or not...
13:23karolherbst: dunno, I usually always file upstream bugs
13:23karolherbst: and this is an upstream issue afaik unless there are weirdo patches to the arch kernel
13:29fltrz: so the bug is in which driver according to us?
13:35fltrz: I should show them this output of dmesg | grep snd ? http://ix.io/49X7
13:37fltrz: which is the pathway it affects discrete gpu or nouveau ? 1) something sound is on same bus and bus can not power down 2) nouveau can not power down because audio functionality cant be handed over or something? 3) other?
13:38karolherbst: no, full dmesg
13:39karolherbst: and the bug is, that snd_intel_hda doesn't runtime suspend the audio device preventing the GPU and the bridge controller to power off
13:39karolherbst: *audio device on the GPU (01:00.1)
15:24anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18497 finally
15:29karolherbst: it's 32 bit?
15:29karolherbst: (wondering about that CONFIG_DRM_MSM=n thing)
16:07anholt: karolherbst: yeah
16:07anholt: tk1 was a 32-bit processor
16:47HdkR: You wouldn't want a farm of 64-bit TK1 boards anyway.Those Nexus 9 tablets as CI sounds terrible :P
18:50karolherbst: wiring up tk1 for nvk will be "fun", because that probably requires us to handle modifiers
18:50karolherbst: let's see when we'll get to that
21:48phomes: karolherbst: zink on nvk fails due to 5 missing extensions
21:48phomes: maintenance1, imageless_framebuffer, descriptor_update_template, timeline_semaphore, create_renderpass2
21:50phomes: I marked them as supported just to see if it would run without the implementation with just glxinfo. It fails on timeline semaphore. I don't see even binary semaphore in nvk yet, so that seems like a big first extension to tackle
21:51phomes: I think I will go for descriptor_update_template as a first
21:55karolherbst: uhh.. yeah, timeline semaphore will be some work
22:18karolherbst: could somebody check if clicking "Edit" leads one to a gitlab page where you are told to fork or something? https://nouveau.freedesktop.org/
22:19karolherbst: for me it leads straight to editing inside the main repo, that's why I am wondering
23:03KitsuWhooa: karolherbst: after logging in it took me to https://gitlab.freedesktop.org/nouveau/wiki/-/blob/master/sources/index.mdwn
23:04KitsuWhooa: Clicking open in web ide I get "You can’t edit files directly in this project. Fork this project and submit a merge request with your changes."
23:04karolherbst: okay, that's good to know
23:04karolherbst: I guess once you have a fork it opens an editor inside your fork?
23:04karolherbst: (and prompts to create a branch or something)
23:05KitsuWhooa: judging by the url, if I click on "fork" it will do that, yeah
23:05karolherbst: I meant clicking the edit link after forking
23:05karolherbst: I was under the impression I tested this once. I was just curious because we had a user requesting direct access to the wiki repo
23:05KitsuWhooa: It took me straight to the web ide in my own fork
23:05karolherbst: but I guess they simply didn't see the link
23:05karolherbst: okay, cool
23:06KitsuWhooa: when I clicked the "fork" button after clicking edit in web ide in the main repo
23:07KitsuWhooa: Clicking edit with already having a fork, I get the editor directly with " GitLab will create a branch in your fork and start a merge request. "
23:07karolherbst: okay, cool
23:07karolherbst: thanks for checking!
23:07KitsuWhooa: so basically: no fork: It just shows you the source with the edit in web ide button
23:08KitsuWhooa: already having a fork: directly get the editor
23:08KitsuWhooa: in your own fork/branch