05:45 derSteFfi: Hey, I'm seeing kernel warnings and a non-funtioning nouveau driver on a GP108. dmesg reports 'nouveau 0000:01:00.0: timeout' followed by a stack trace every time the card should be activated (boot, resume, DRI_PRIME=1 glxinfo). It's a secondary GPU on a ThinkPad, I did not use it until now, but spare time in homeoffice... How may I proceed to
05:45 derSteFfi: diagnose the problem? I scraped through the mailing list archive but nothing cought my eye.
06:12 airlied: derSteFfi: https://patchwork.freedesktop.org/series/68109/ might help
06:12 airlied: not sure if it's the same thing
06:40 derSteFfi: airlied: Yeah, I read that on the list. I don't think because I never get the mentionend kernel log message ('Refused to change power state, currently in D3'). Will try nonetheless.
06:49 derSteFfi: airlied: did not help -.-
12:01 mmenzyns: had anyone had problems with the freenode server now?
12:04 diogenes_: not me
14:33 cosurgi: me neither
20:34 RSpliet: karolherbst: https://bugzilla.kernel.org/show_bug.cgi?id=207043
20:35 karolherbst: \o/
20:35 karolherbst: thx
20:36 RSpliet: Fingers crossed it won't get kicked back to you saying "you should not expose HDA on this GPU in the first place"
21:27 Conmanx360: So it's an HDA device without any codecs? That's a really weird situation...
21:35 RSpliet: Conmanx360: yep. I suspect the HDA device is inside the GPU, and the OEM gets to pick a codec as a separate chip?
21:35 RSpliet: Obviously theOEM didn't bother picking a codec, because... the GPU doesn't have any outputs. At all
21:36 Conmanx360: There's the HDA bus and then it connects individually to each codec, so it must have a bus without any codecs. It's not connected to HDMI even?
21:36 RSpliet: There is no HDMI
21:37 RSpliet: There's also no displayport. Or DVI. Or VGA... there's *no* outputs. The GPU can only render into a buffer, and have the Intel IGP scan it out and bring it to a display
21:38 Conmanx360: Hm. Weird. I've had laptops where HDMI was an option, and even without having the port present, there's still an HDMI audio device
21:39 HdkR: This one it isn't an option :)
21:40 Conmanx360: Hm? Looking up the Asus K501UB shows 1 x HDMI in the specifications, but I guess that could be connected to the iGPU
21:40 RSpliet: It is indeed
21:41 Conmanx360: Ah, duh, that's in the dmesg log
21:42 Conmanx360: I've done a little messing around with HDA, but I've never heard of a bus with no codecs. Seems pretty weird.
21:43 RSpliet: From a vendor POV it kind of makes sense if the GPU carries the HDA bus but the OEM picks the codec.
21:43 RSpliet: If an OEM wants to waste money, they'd omit the codec. NVIDIA isn't going to design a new chip for that :-)
21:43 Conmanx360: I've seen stuff like that, but usually in that case, you use the HDA bus on the CPU
21:44 RSpliet: the whole point of the NVIDIA GPU having a HDA bus is routing it over any connectors connected to the GPU
21:44 RSpliet: again, it was the OEMs choice not to add a connector
21:45 RSpliet: But NVIDIA isn't going to make two different types of chips (one with, one without HDA bus), because that's a waste of money
21:45 Conmanx360: Right, right. Makes sense.
21:45 Conmanx360: You've probably already checked, but is there any sort of bios options?
21:46 RSpliet: Well, if you want to look at options to disable the HDA bus rather than have snd_hda_intel choke on it, the first place to look is the VBIOS
21:48 Conmanx360: Yeah, sounds like you guys have got it figured out. I've done some work on linux HDA drivers, but it was mainly at the codec level, not the bus. Either way, it's an interesting issue :)
21:48 RSpliet: There's two ways of looking at the issue. One is "snd_hda_intel shouldn't fail to do runpm on a bus without codecs", which I suspect is either a bug or a lack of feature :-P But should be fairly trivial to overcome for someone knowledgable on HDA
21:49 RSpliet: The other way is "should nouveau unconditionally enable HDA, or are there ways for the OEM to say 'actually, don't bother'"
21:49 Conmanx360: I feel like there's a value somewhere that gives out that info, I'd have to look at the HD Audio spec manual
21:50 RSpliet: I'd expect that if such information is encoded at all, it would be in NVIDIA's VBIOS.
21:50 RSpliet: Which is sparsely documented
21:52 RSpliet: That being said, there is also something to say for the thought of "if nouveau detects zero output ports, just disable HDA".
21:53 RSpliet: But at this point, we are talking design decisions (or a blame game if you play it wrong), and I'm not the one to take those :-)
21:54 Conmanx360: Yeah, wonder if there's something in the VBIOS to just hide the HDA controller/bus outright
21:55 Conmanx360: I think the reason that the HDA driver doesn't just auto-unload is because codecs support hot plugging
21:55 Conmanx360: So there's a possibility that even if one isn't present at startup, it could be afterwards. I think that's normally used in stuff like laptop docking.
21:56 RSpliet: Conmanx360: the question isn't why the driver doesn't unload, but why it refuses to honour the auto runpm in this case and just drop the bus into D3
22:00 RSpliet: I'm fine with the driver binding to the HDA device if it does as it's told by runpm :-)
22:02 Conmanx360: Yeah, it's obviously beyond my knowledge of the whole HDA system. What a weird situation. Trying to dig into the code to see what it does after the 'no codecs found!' message
22:12 karolherbst: Conmanx360: probably not setting required func pointers for it ;)
22:20 karolherbst: RSpliet: what laptop is that btw?
22:25 Conmanx360: Bug report says Asus K501UB
22:25 karolherbst: ahh, it does
22:43 RSpliet: most details I forgot must be present in the dmesg somewhere too :-)
22:44 RSpliet: including bold statements like "DMAR: [Firmware Bug]: Your BIOS is broken; bad RMRR [0x0000000078800000-0x000000007affffff]"
22:44 RSpliet: (also trivially true. All BIOS is broken)
22:50 Conmanx360: It looks like if no codecs are found it should error out, wonder where the hangup is then. Maybe azx_is_pm_ready
22:51 Conmanx360: if hda->init_failed is set, azx_is_pm_ready fails, and azx_suspend never does snd_power_change_state
22:53 Conmanx360: Well, all power management stuff is disabled if hda->init_failed is set, but wonder why it never actually just unloads then.
22:54 Conmanx360: Or maybe that's only related to codecs, and not the main bus
22:54 RSpliet: unbinds you mean? it stays loaded because there's a second intel HDA device in there
22:55 Conmanx360: Yeah, unbinds
22:55 RSpliet: anyway, azx_first_init fails. And that sets hda->init_failed to 1
22:55 karolherbst: probing can fail
22:55 karolherbst: there is even an error code which doesn't produce errors
22:56 karolherbst: -ENODEV
22:56 RSpliet: what's the value of ENODEV? 0?
22:56 RSpliet: No, 19
22:56 karolherbst: yeah
22:56 karolherbst: but the kernel code checks this value
22:56 karolherbst: if probe fails with that -> no error message in dmesg
22:57 RSpliet: Which is exactly what the codec check returns
22:57 RSpliet: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/pci/hda/hda_intel.c?h=v5.5.13#n2005
22:57 karolherbst: but it binds
22:57 karolherbst: so the probe doesn't fail
22:57 RSpliet: yep
22:58 Conmanx360: The 'no codecs found!' message is followed by returning -ENODEV
22:58 RSpliet: Yes... that is what I said ;-)
22:58 Conmanx360: I wasn't sure if saying 'the probe doesn't fail' meant that wasn't being returned
22:58 Conmanx360: My bad :)
22:58 RSpliet: But it causes azx_probe_continue to jump into the error path