Re: [REGRESSION][BISECTED] HDA controller MMIO unreadable on Intel 5-series PCH (Ibex Peak) since v6.16

Hello back,

-CC: alsa-devel

Sorry, I was busy for a time and accidentaly sent prev msg in HTML.

I'll give dev init trace to Lukas a little bit later once I find a
time to instrument it with printk.

The issue seems to be quite interesting.

Best regards!
-- 
Filippe Duke
System Engineer

GREENNET



-----Original Message-----
From: Thorsten Leemhuis <[email protected]>
To: Lukas Wunner <[email protected]>, [email protected]
<[email protected]>
Cc: Filippe Duke <[email protected]>, [email protected]
<[email protected]>, [email protected]
<[email protected]>, [email protected]
<[email protected]>, [email protected]
<[email protected]>, [email protected] <[email protected]>
Subject: Re: [REGRESSION][BISECTED] HDA controller MMIO unreadable on
Intel 5-series PCH (Ibex Peak) since v6.16
Date: 06/16/2026 10:12:53 AM

On 6/1/26 09:34, Lukas Wunner wrote:
> On Sun, May 31, 2026 at 09:22:52PM +0000, Filippe Duke wrote:
> > A working LTS kernel version tells completely different story.
> 
> Right:
> 
>  00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset
> [...]
> -       Interrupts: pin B disabled, MSI(X) routed to IRQ 34
> +       Interrupts: pin B disabled, MSI(X) routed to IRQ 28
> [...]
> -               Address: 0000000000000000  Data: 0000
> +               Address: 00000000fee00000  Data: 0022
> 
> That's the only difference.  Seems plausible that it causes
> communication failure with the HDA controller.
> 
> The offending commit

Reminder, that was 4d4c10f763d780 ("PCI: Explicitly put devices into D0
when initializing") [v6.16-rc1] from Mario.

This thread stalled and Isee no patch submissions referring to that
change, which makes me wonder:

Is anybody still looking into this, or did this fell through the cracks?

Side note, for completeness: Josh Perry recently reported problems with
a  RTL8168h/8111h NICs due to the same change:
https://lore.kernel.org/netdev/[email protected]/

Ciao, Thorsten

> causes current_state to be PCI_D0 instead of
> PCI_UNKNOWN at boot time enumeration and this results in different
> code paths being taken.
> 
> I note that current_state is queried in three places in
> drivers/pci/msi/msi.c, so I'd start by instrumenting them with
> printk()'s to see why the behavior is different.
> 
> E.g. __pci_write_msi_msg() bails out if current_state is not PCI_D0.
> Perhaps it used to do that on a working kernel and now it doesn't.