Regressions: MSI vs HDA-Intel

Regressions: MSI vs HDA-Intel

[Torsten Kaiser]

I have two systems that use the alsa hda-intel driver, both show
regressions in relation to MSI.

System 1: Athlon(tm) X2 BE-2400 with an AMD RS690/SB600 chipset
00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel
HDA) [1002:4383]
(Mainboard is a MSI MS-7368)

After upgrading from 2.6.31 to 2.6.33 I get a delay during bootup:
[    1.155925] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
low) -> IRQ 16
[    1.159143] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input2
[    1.232595] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
[    1.252677] hda_codec: ALC888: BIOS auto-probing.
[    1.259226] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
low) -> IRQ 19
[    1.260293] HDA Intel 0000:01:05.2: irq 27 for MSI/MSI-X
[    1.314712] input: GenPS/2 Genius Mouse as
/devices/platform/i8042/serio1/input/input3
[    4.322508] hda-intel: azx_get_response timeout, switching to
polling mode: last cmd=0x000f0000
[    5.332508] hda-intel: No response from codec, disabling MSI: last
cmd=0x000f0000
[    6.342508] hda-intel: Codec #0 probe error; disabling it...
[    7.392508] hda_intel: azx_get_response timeout, switching to
single_cmd mode: last cmd=0x000f0000
[    7.430464] ALSA device list:
[    7.431549]   #0: HDA ATI SB at 0xfe7f4000 irq 16
[    7.432656]   #1: HDA ATI HDMI at 0xfe9e8000 irq 27

2.6.34-rc2 does not boot on this system, something related to the new
bootmem allocator, so I can't say if this might already be fixed for
2.6.34.

Should the system be blacklisted like the two Asus Athlon X2 boards,
or is this some other bug?


System 2: Opteron(tm) 2218 with an nVidia MCP55 chipset
00:06.1 Audio device [0403]: nVidia Corporation MCP55 High Definition
Audio [10de:0371] (rev a2)
(Mainboard is an ASUS KFN5-D SLI)

Commit 80c43ed724797627d8f86855248c497a6161a214 disabled MSI for this
system, but the MSI mode was working fine for all 2.6.33 versions I
used.

Should the generic blacklist disable MSI for all Athlon X2 instead of
all nNvidia chipsets?


If you need more information, please ask, I will try to provide
anything you need.

Thanks, Torsten

Re: Regressions: MSI vs HDA-Intel

[Takashi Iwai]

At Fri, 26 Mar 2010 18:25:22 +0100,
Torsten Kaiser wrote:
> 
> I have two systems that use the alsa hda-intel driver, both show
> regressions in relation to MSI.
> 
> System 1: Athlon(tm) X2 BE-2400 with an AMD RS690/SB600 chipset
> 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel
> HDA) [1002:4383]
> (Mainboard is a MSI MS-7368)
> 
> After upgrading from 2.6.31 to 2.6.33 I get a delay during bootup:
> [    1.155925] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
> low) -> IRQ 16
> [    1.159143] input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input2
> [    1.232595] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
> [    1.252677] hda_codec: ALC888: BIOS auto-probing.
> [    1.259226] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
> low) -> IRQ 19
> [    1.260293] HDA Intel 0000:01:05.2: irq 27 for MSI/MSI-X
> [    1.314712] input: GenPS/2 Genius Mouse as
> /devices/platform/i8042/serio1/input/input3
> [    4.322508] hda-intel: azx_get_response timeout, switching to
> polling mode: last cmd=0x000f0000
> [    5.332508] hda-intel: No response from codec, disabling MSI: last
> cmd=0x000f0000
> [    6.342508] hda-intel: Codec #0 probe error; disabling it...
> [    7.392508] hda_intel: azx_get_response timeout, switching to
> single_cmd mode: last cmd=0x000f0000
> [    7.430464] ALSA device list:
> [    7.431549]   #0: HDA ATI SB at 0xfe7f4000 irq 16
> [    7.432656]   #1: HDA ATI HDMI at 0xfe9e8000 irq 27
> 
> 2.6.34-rc2 does not boot on this system, something related to the new
> bootmem allocator, so I can't say if this might already be fixed for
> 2.6.34.
> 
> Should the system be blacklisted like the two Asus Athlon X2 boards,
> or is this some other bug?

If it happens on 2.6.33 and enable_msi=0 solves the issue, then yes,
we should put them on the blacklist.

> System 2: Opteron(tm) 2218 with an nVidia MCP55 chipset
> 00:06.1 Audio device [0403]: nVidia Corporation MCP55 High Definition
> Audio [10de:0371] (rev a2)
> (Mainboard is an ASUS KFN5-D SLI)
> 
> Commit 80c43ed724797627d8f86855248c497a6161a214 disabled MSI for this
> system, but the MSI mode was working fine for all 2.6.33 versions I
> used.
> 
> Should the generic blacklist disable MSI for all Athlon X2 instead of
> all nNvidia chipsets?

Well, it's not clear yet.  I don't bet that non-athlon would have
any problem.  So I keep it still disabled for Nvidia controllers.
You can put it in the whitelist instead.


thanks,

Takashi

Re: Regressions: MSI vs HDA-Intel

[Torsten Kaiser]

On Fri, Mar 26, 2010 at 6:31 PM, Takashi Iwai <tiwai@suse.de> wrote:
> At Fri, 26 Mar 2010 18:25:22 +0100,
> Torsten Kaiser wrote:
>>
>> I have two systems that use the alsa hda-intel driver, both show
>> regressions in relation to MSI.
>>
>> System 1: Athlon(tm) X2 BE-2400 with an AMD RS690/SB600 chipset
>> 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel
>> HDA) [1002:4383]
>> (Mainboard is a MSI MS-7368)
>>
>> After upgrading from 2.6.31 to 2.6.33 I get a delay during bootup:
>> [    1.155925] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
>> low) -> IRQ 16
>> [    1.159143] input: AT Translated Set 2 keyboard as
>> /devices/platform/i8042/serio0/input/input2
>> [    1.232595] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
>> [    1.252677] hda_codec: ALC888: BIOS auto-probing.
>> [    1.259226] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
>> low) -> IRQ 19
>> [    1.260293] HDA Intel 0000:01:05.2: irq 27 for MSI/MSI-X
>> [    1.314712] input: GenPS/2 Genius Mouse as
>> /devices/platform/i8042/serio1/input/input3
>> [    4.322508] hda-intel: azx_get_response timeout, switching to
>> polling mode: last cmd=0x000f0000
>> [    5.332508] hda-intel: No response from codec, disabling MSI: last
>> cmd=0x000f0000
>> [    6.342508] hda-intel: Codec #0 probe error; disabling it...
>> [    7.392508] hda_intel: azx_get_response timeout, switching to
>> single_cmd mode: last cmd=0x000f0000
>> [    7.430464] ALSA device list:
>> [    7.431549]   #0: HDA ATI SB at 0xfe7f4000 irq 16
>> [    7.432656]   #1: HDA ATI HDMI at 0xfe9e8000 irq 27
>>
>> 2.6.34-rc2 does not boot on this system, something related to the new
>> bootmem allocator, so I can't say if this might already be fixed for
>> 2.6.34.
>>
>> Should the system be blacklisted like the two Asus Athlon X2 boards,
>> or is this some other bug?
>
> If it happens on 2.6.33 and enable_msi=0 solves the issue, then yes,
> we should put them on the blacklist.

Surprisingly this did not fix the delay. After all the trouble I had
with MSI on the other system, I was sure it was related to the fact,
that 2.6.33 tried to use MSI.
2.6.33 with snd_hda_intel.enable_msi=0:
[    1.155712] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
low) -> IRQ 16
[    1.158852] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/in
put/input2
[    1.232597] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
[    1.252679] hda_codec: ALC888: BIOS auto-probing.
[    1.259206] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
low) -> IRQ 19
[    1.314745] input: GenPS/2 Genius Mouse as
/devices/platform/i8042/serio1/input/input3
[    4.322508] hda-intel: azx_get_response timeout, switching to
polling mode: last cmd=0x000f0000
[    5.332508] hda-intel: Codec #0 probe error; disabling it...
[    6.382508] hda_intel: azx_get_response timeout, switching to
single_cmd mode: last cmd=0x000f0000
[    6.420470] ALSA device list:
[    6.421545]   #0: HDA ATI SB at 0xfe7f4000 irq 16
[    6.422628]   #1: HDA ATI HDMI at 0xfe9e8000 irq 19

... if I had read these messages, instead of just copy&pasting them, I
could have noted, that the delay is from codec *0*, but MSI gets
enabled for codec *1*.
Info about the HDMI output:
01:05.2 Audio device [0403]: ATI Technologies Inc Radeon X1200 Series
Audio Controller [1002:7919]

But that is a clear bug in the alsa code: After codec 0 (the
integrated audio from the SB600) does not responds, it disables the
MSI support for codec 1 (part of the intregrated graphic chipset).
(I don't know if the HDMI audio support is working or not, as I do not
have an HDMI display I could attach there.)

2.6.31 was working without the delay:
[    0.930754] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
low) -> IRQ 16
[    0.946676] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input2
[    1.031402] hda_codec: Unknown model for ALC888, trying auto-probe
from BIOS...
[    1.035263] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
low) -> IRQ 19
[    1.090754] input: GenPS/2 Genius Mouse as
/devices/platform/i8042/serio1/input/input3
[    1.102573] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
[    1.112916] ALSA device list:
[    1.112974]   #0: HDA ATI SB at 0xfe7f4000 irq 16
[    1.113033]   #1: HDA ATI HDMI at 0xfe9e8000 irq 19


>> System 2: Opteron(tm) 2218 with an nVidia MCP55 chipset
>> 00:06.1 Audio device [0403]: nVidia Corporation MCP55 High Definition
>> Audio [10de:0371] (rev a2)
>> (Mainboard is an ASUS KFN5-D SLI)
>>
>> Commit 80c43ed724797627d8f86855248c497a6161a214 disabled MSI for this
>> system, but the MSI mode was working fine for all 2.6.33 versions I
>> used.
>>
>> Should the generic blacklist disable MSI for all Athlon X2 instead of
>> all nNvidia chipsets?
>
> Well, it's not clear yet.  I don't bet that non-athlon would have
> any problem.  So I keep it still disabled for Nvidia controllers.
> You can put it in the whitelist instead.

OK, just wanted to let you know, that there are MCP55 out there that
do work with MSI. :-)

Thanks, Torsten

Re: Regressions: MSI vs HDA-Intel

[Takashi Iwai]

At Fri, 26 Mar 2010 18:59:17 +0100,
Torsten Kaiser wrote:
> 
> On Fri, Mar 26, 2010 at 6:31 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > At Fri, 26 Mar 2010 18:25:22 +0100,
> > Torsten Kaiser wrote:
> >>
> >> I have two systems that use the alsa hda-intel driver, both show
> >> regressions in relation to MSI.
> >>
> >> System 1: Athlon(tm) X2 BE-2400 with an AMD RS690/SB600 chipset
> >> 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel
> >> HDA) [1002:4383]
> >> (Mainboard is a MSI MS-7368)
> >>
> >> After upgrading from 2.6.31 to 2.6.33 I get a delay during bootup:
> >> [    1.155925] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
> >> low) -> IRQ 16
> >> [    1.159143] input: AT Translated Set 2 keyboard as
> >> /devices/platform/i8042/serio0/input/input2
> >> [    1.232595] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
> >> [    1.252677] hda_codec: ALC888: BIOS auto-probing.
> >> [    1.259226] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
> >> low) -> IRQ 19
> >> [    1.260293] HDA Intel 0000:01:05.2: irq 27 for MSI/MSI-X
> >> [    1.314712] input: GenPS/2 Genius Mouse as
> >> /devices/platform/i8042/serio1/input/input3
> >> [    4.322508] hda-intel: azx_get_response timeout, switching to
> >> polling mode: last cmd=0x000f0000
> >> [    5.332508] hda-intel: No response from codec, disabling MSI: last
> >> cmd=0x000f0000
> >> [    6.342508] hda-intel: Codec #0 probe error; disabling it...
> >> [    7.392508] hda_intel: azx_get_response timeout, switching to
> >> single_cmd mode: last cmd=0x000f0000
> >> [    7.430464] ALSA device list:
> >> [    7.431549]   #0: HDA ATI SB at 0xfe7f4000 irq 16
> >> [    7.432656]   #1: HDA ATI HDMI at 0xfe9e8000 irq 27
> >>
> >> 2.6.34-rc2 does not boot on this system, something related to the new
> >> bootmem allocator, so I can't say if this might already be fixed for
> >> 2.6.34.
> >>
> >> Should the system be blacklisted like the two Asus Athlon X2 boards,
> >> or is this some other bug?
> >
> > If it happens on 2.6.33 and enable_msi=0 solves the issue, then yes,
> > we should put them on the blacklist.
> 
> Surprisingly this did not fix the delay. After all the trouble I had
> with MSI on the other system, I was sure it was related to the fact,
> that 2.6.33 tried to use MSI.
> 2.6.33 with snd_hda_intel.enable_msi=0:
> [    1.155712] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
> low) -> IRQ 16
> [    1.158852] input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/in
> put/input2
> [    1.232597] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
> [    1.252679] hda_codec: ALC888: BIOS auto-probing.
> [    1.259206] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
> low) -> IRQ 19
> [    1.314745] input: GenPS/2 Genius Mouse as
> /devices/platform/i8042/serio1/input/input3
> [    4.322508] hda-intel: azx_get_response timeout, switching to
> polling mode: last cmd=0x000f0000
> [    5.332508] hda-intel: Codec #0 probe error; disabling it...
> [    6.382508] hda_intel: azx_get_response timeout, switching to
> single_cmd mode: last cmd=0x000f0000
> [    6.420470] ALSA device list:
> [    6.421545]   #0: HDA ATI SB at 0xfe7f4000 irq 16
> [    6.422628]   #1: HDA ATI HDMI at 0xfe9e8000 irq 19
> 
> ... if I had read these messages, instead of just copy&pasting them, I
> could have noted, that the delay is from codec *0*, but MSI gets
> enabled for codec *1*.
> Info about the HDMI output:
> 01:05.2 Audio device [0403]: ATI Technologies Inc Radeon X1200 Series
> Audio Controller [1002:7919]
> 
> But that is a clear bug in the alsa code: After codec 0 (the
> integrated audio from the SB600) does not responds, it disables the
> MSI support for codec 1 (part of the intregrated graphic chipset).
> (I don't know if the HDMI audio support is working or not, as I do not
> have an HDMI display I could attach there.)

It's no bug.  The driver has only one flag to use MSI or not.
So it disable MSI for both.  It's on the same board, after all,
so better to take a safer option.


> 2.6.31 was working without the delay:
> [    0.930754] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
> low) -> IRQ 16
> [    0.946676] input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input2
> [    1.031402] hda_codec: Unknown model for ALC888, trying auto-probe
> from BIOS...
> [    1.035263] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
> low) -> IRQ 19
> [    1.090754] input: GenPS/2 Genius Mouse as
> /devices/platform/i8042/serio1/input/input3
> [    1.102573] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
> [    1.112916] ALSA device list:
> [    1.112974]   #0: HDA ATI SB at 0xfe7f4000 irq 16
> [    1.113033]   #1: HDA ATI HDMI at 0xfe9e8000 irq 19
> 
> 
> >> System 2: Opteron(tm) 2218 with an nVidia MCP55 chipset
> >> 00:06.1 Audio device [0403]: nVidia Corporation MCP55 High Definition
> >> Audio [10de:0371] (rev a2)
> >> (Mainboard is an ASUS KFN5-D SLI)
> >>
> >> Commit 80c43ed724797627d8f86855248c497a6161a214 disabled MSI for this
> >> system, but the MSI mode was working fine for all 2.6.33 versions I
> >> used.
> >>
> >> Should the generic blacklist disable MSI for all Athlon X2 instead of
> >> all nNvidia chipsets?
> >
> > Well, it's not clear yet.  I don't bet that non-athlon would have
> > any problem.  So I keep it still disabled for Nvidia controllers.
> > You can put it in the whitelist instead.
> 
> OK, just wanted to let you know, that there are MCP55 out there that
> do work with MSI. :-)

That's fine.  There must be some other positive boards .
But I don't want to give more and more bug reports just because
of buggy MSI support.  That's enough in a single version number :)
The gain by MSI isn't so much in most cases.


Takashi

Re: Regressions: MSI vs HDA-Intel

[Torsten Kaiser]

On Fri, Mar 26, 2010 at 9:27 PM, Takashi Iwai <tiwai@suse.de> wrote:
> At Fri, 26 Mar 2010 18:59:17 +0100,
> Torsten Kaiser wrote:
>>
>> On Fri, Mar 26, 2010 at 6:31 PM, Takashi Iwai <tiwai@suse.de> wrote:
>> > At Fri, 26 Mar 2010 18:25:22 +0100,
>> > Torsten Kaiser wrote:
>> >>
>> >> I have two systems that use the alsa hda-intel driver, both show
>> >> regressions in relation to MSI.
>> >>
>> >> System 1: Athlon(tm) X2 BE-2400 with an AMD RS690/SB600 chipset
>> >> 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel
>> >> HDA) [1002:4383]
>> >> (Mainboard is a MSI MS-7368)
>> >>
>> >> After upgrading from 2.6.31 to 2.6.33 I get a delay during bootup:
>> >> [    1.155925] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
>> >> low) -> IRQ 16
>> >> [    1.159143] input: AT Translated Set 2 keyboard as
>> >> /devices/platform/i8042/serio0/input/input2
>> >> [    1.232595] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
>> >> [    1.252677] hda_codec: ALC888: BIOS auto-probing.
>> >> [    1.259226] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
>> >> low) -> IRQ 19
>> >> [    1.260293] HDA Intel 0000:01:05.2: irq 27 for MSI/MSI-X
>> >> [    1.314712] input: GenPS/2 Genius Mouse as
>> >> /devices/platform/i8042/serio1/input/input3
>> >> [    4.322508] hda-intel: azx_get_response timeout, switching to
>> >> polling mode: last cmd=0x000f0000
>> >> [    5.332508] hda-intel: No response from codec, disabling MSI: last
>> >> cmd=0x000f0000
>> >> [    6.342508] hda-intel: Codec #0 probe error; disabling it...
>> >> [    7.392508] hda_intel: azx_get_response timeout, switching to
>> >> single_cmd mode: last cmd=0x000f0000
>> >> [    7.430464] ALSA device list:
>> >> [    7.431549]   #0: HDA ATI SB at 0xfe7f4000 irq 16
>> >> [    7.432656]   #1: HDA ATI HDMI at 0xfe9e8000 irq 27
>> >>
>> >> 2.6.34-rc2 does not boot on this system, something related to the new
>> >> bootmem allocator, so I can't say if this might already be fixed for
>> >> 2.6.34.
>> >>
>> >> Should the system be blacklisted like the two Asus Athlon X2 boards,
>> >> or is this some other bug?
>> >
>> > If it happens on 2.6.33 and enable_msi=0 solves the issue, then yes,
>> > we should put them on the blacklist.
>>
>> Surprisingly this did not fix the delay. After all the trouble I had
>> with MSI on the other system, I was sure it was related to the fact,
>> that 2.6.33 tried to use MSI.
>> 2.6.33 with snd_hda_intel.enable_msi=0:
>> [    1.155712] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
>> low) -> IRQ 16
>> [    1.158852] input: AT Translated Set 2 keyboard as
>> /devices/platform/i8042/serio0/in
>> put/input2
>> [    1.232597] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
>> [    1.252679] hda_codec: ALC888: BIOS auto-probing.
>> [    1.259206] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
>> low) -> IRQ 19
>> [    1.314745] input: GenPS/2 Genius Mouse as
>> /devices/platform/i8042/serio1/input/input3
>> [    4.322508] hda-intel: azx_get_response timeout, switching to
>> polling mode: last cmd=0x000f0000
>> [    5.332508] hda-intel: Codec #0 probe error; disabling it...
>> [    6.382508] hda_intel: azx_get_response timeout, switching to
>> single_cmd mode: last cmd=0x000f0000
>> [    6.420470] ALSA device list:
>> [    6.421545]   #0: HDA ATI SB at 0xfe7f4000 irq 16
>> [    6.422628]   #1: HDA ATI HDMI at 0xfe9e8000 irq 19
>>
>> ... if I had read these messages, instead of just copy&pasting them, I
>> could have noted, that the delay is from codec *0*, but MSI gets
>> enabled for codec *1*.
>> Info about the HDMI output:
>> 01:05.2 Audio device [0403]: ATI Technologies Inc Radeon X1200 Series
>> Audio Controller [1002:7919]
>>
>> But that is a clear bug in the alsa code: After codec 0 (the
>> integrated audio from the SB600) does not responds, it disables the
>> MSI support for codec 1 (part of the intregrated graphic chipset).
>> (I don't know if the HDMI audio support is working or not, as I do not
>> have an HDMI display I could attach there.)
>
> It's no bug.  The driver has only one flag to use MSI or not.
> So it disable MSI for both.  It's on the same board, after all,
> so better to take a safer option.

It's a bug, because the failing codec 0 never used MSI at all. So
disabling it will not help.

The first log (without the MSI disable option) showed:
codec 0 was using IRQ 16
codec 1 was using IRQ 19, but got switched to MSI-IRQ 27
then the 5 sec pause followed, because codec 0 failed.
switching off MSI for codec 1 seemed to work, because I only see
hda_intel on IRQ 16 and 19 in /proc/interrupts.
But the device list still showed "#1: HDA ATI HDMI at 0xfe9e8000 irq
27" after the "No response from codec, disabling MSI" message!

The second log showed the same sequence:
codec 0 using IRQ 16, codec 1 using 19, but this time without the switch to 27
the 5 sec pause and the failing of codec 0 still append, because the
ALC888 never used MSI.

So I think there are two bugs:
One (the regression) that the ALC888 codec is no longer initialized
correctly, and so causing the delay during the boot.
And two that the fallback in azx_rirb_get_response() tries to disable
the never enabled MSI.
... Umm. The code disagrees with my description of bug two: It already
does check for an per chip msi flag.

I will try to add more debug to see what codec emits what errors, and
post again, with that information.

Thanks, Torsten

Re: Regressions: MSI vs HDA-Intel

[Takashi Iwai]

At Fri, 26 Mar 2010 22:07:53 +0100,
Torsten Kaiser wrote:
> 
> On Fri, Mar 26, 2010 at 9:27 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > At Fri, 26 Mar 2010 18:59:17 +0100,
> > Torsten Kaiser wrote:
> >>
> >> On Fri, Mar 26, 2010 at 6:31 PM, Takashi Iwai <tiwai@suse.de> wrote:
> >> > At Fri, 26 Mar 2010 18:25:22 +0100,
> >> > Torsten Kaiser wrote:
> >> >>
> >> >> I have two systems that use the alsa hda-intel driver, both show
> >> >> regressions in relation to MSI.
> >> >>
> >> >> System 1: Athlon(tm) X2 BE-2400 with an AMD RS690/SB600 chipset
> >> >> 00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel
> >> >> HDA) [1002:4383]
> >> >> (Mainboard is a MSI MS-7368)
> >> >>
> >> >> After upgrading from 2.6.31 to 2.6.33 I get a delay during bootup:
> >> >> [    1.155925] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
> >> >> low) -> IRQ 16
> >> >> [    1.159143] input: AT Translated Set 2 keyboard as
> >> >> /devices/platform/i8042/serio0/input/input2
> >> >> [    1.232595] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
> >> >> [    1.252677] hda_codec: ALC888: BIOS auto-probing.
> >> >> [    1.259226] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
> >> >> low) -> IRQ 19
> >> >> [    1.260293] HDA Intel 0000:01:05.2: irq 27 for MSI/MSI-X
> >> >> [    1.314712] input: GenPS/2 Genius Mouse as
> >> >> /devices/platform/i8042/serio1/input/input3
> >> >> [    4.322508] hda-intel: azx_get_response timeout, switching to
> >> >> polling mode: last cmd=0x000f0000
> >> >> [    5.332508] hda-intel: No response from codec, disabling MSI: last
> >> >> cmd=0x000f0000
> >> >> [    6.342508] hda-intel: Codec #0 probe error; disabling it...
> >> >> [    7.392508] hda_intel: azx_get_response timeout, switching to
> >> >> single_cmd mode: last cmd=0x000f0000
> >> >> [    7.430464] ALSA device list:
> >> >> [    7.431549]   #0: HDA ATI SB at 0xfe7f4000 irq 16
> >> >> [    7.432656]   #1: HDA ATI HDMI at 0xfe9e8000 irq 27
> >> >>
> >> >> 2.6.34-rc2 does not boot on this system, something related to the new
> >> >> bootmem allocator, so I can't say if this might already be fixed for
> >> >> 2.6.34.
> >> >>
> >> >> Should the system be blacklisted like the two Asus Athlon X2 boards,
> >> >> or is this some other bug?
> >> >
> >> > If it happens on 2.6.33 and enable_msi=0 solves the issue, then yes,
> >> > we should put them on the blacklist.
> >>
> >> Surprisingly this did not fix the delay. After all the trouble I had
> >> with MSI on the other system, I was sure it was related to the fact,
> >> that 2.6.33 tried to use MSI.
> >> 2.6.33 with snd_hda_intel.enable_msi=0:
> >> [    1.155712] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
> >> low) -> IRQ 16
> >> [    1.158852] input: AT Translated Set 2 keyboard as
> >> /devices/platform/i8042/serio0/in
> >> put/input2
> >> [    1.232597] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
> >> [    1.252679] hda_codec: ALC888: BIOS auto-probing.
> >> [    1.259206] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
> >> low) -> IRQ 19
> >> [    1.314745] input: GenPS/2 Genius Mouse as
> >> /devices/platform/i8042/serio1/input/input3
> >> [    4.322508] hda-intel: azx_get_response timeout, switching to
> >> polling mode: last cmd=0x000f0000
> >> [    5.332508] hda-intel: Codec #0 probe error; disabling it...
> >> [    6.382508] hda_intel: azx_get_response timeout, switching to
> >> single_cmd mode: last cmd=0x000f0000
> >> [    6.420470] ALSA device list:
> >> [    6.421545]   #0: HDA ATI SB at 0xfe7f4000 irq 16
> >> [    6.422628]   #1: HDA ATI HDMI at 0xfe9e8000 irq 19
> >>
> >> ... if I had read these messages, instead of just copy&pasting them, I
> >> could have noted, that the delay is from codec *0*, but MSI gets
> >> enabled for codec *1*.
> >> Info about the HDMI output:
> >> 01:05.2 Audio device [0403]: ATI Technologies Inc Radeon X1200 Series
> >> Audio Controller [1002:7919]
> >>
> >> But that is a clear bug in the alsa code: After codec 0 (the
> >> integrated audio from the SB600) does not responds, it disables the
> >> MSI support for codec 1 (part of the intregrated graphic chipset).
> >> (I don't know if the HDMI audio support is working or not, as I do not
> >> have an HDMI display I could attach there.)
> >
> > It's no bug.  The driver has only one flag to use MSI or not.
> > So it disable MSI for both.  It's on the same board, after all,
> > so better to take a safer option.
> 
> It's a bug, because the failing codec 0 never used MSI at all. So
> disabling it will not help.
> 
> The first log (without the MSI disable option) showed:
> codec 0 was using IRQ 16
> codec 1 was using IRQ 19, but got switched to MSI-IRQ 27
> then the 5 sec pause followed, because codec 0 failed.
> switching off MSI for codec 1 seemed to work, because I only see
> hda_intel on IRQ 16 and 19 in /proc/interrupts.
> But the device list still showed "#1: HDA ATI HDMI at 0xfe9e8000 irq
> 27" after the "No response from codec, disabling MSI" message!

This is no driver behavior bug.  The point is that this string
(chip->longname) was set at the time before disabling MSI.  The driver
can switch back at any time, but the string remains as is.  One reason
is that this field is exposed to the user-space as a sort of
identifier, thus it's not always wise to change it dynamically during
operation.  Yeah, it's confusing, but this is a trade-off.

> The second log showed the same sequence:
> codec 0 using IRQ 16, codec 1 using 19, but this time without the switch to 27
> the 5 sec pause and the failing of codec 0 still append, because the
> ALC888 never used MSI.
> 
> So I think there are two bugs:
> One (the regression) that the ALC888 codec is no longer initialized
> correctly, and so causing the delay during the boot.

This seems irrelevant with the MSI.

> And two that the fallback in azx_rirb_get_response() tries to disable
> the never enabled MSI.

And this is the designed behavior.  We've never trusted MSI from
experiences.  So, prepared to go away from it at any moment :)


Takashi

> ... Umm. The code disagrees with my description of bug two: It already
> does check for an per chip msi flag.
> 
> I will try to add more debug to see what codec emits what errors, and
> post again, with that information.
> 
> Thanks, Torsten
> 

Re: Regressions: MSI vs HDA-Intel

[Torsten Kaiser]

On Fri, Mar 26, 2010 at 10:22 PM, Takashi Iwai <tiwai@suse.de> wrote:
> At Fri, 26 Mar 2010 22:07:53 +0100,
> Torsten Kaiser wrote:
>>
>> On Fri, Mar 26, 2010 at 9:27 PM, Takashi Iwai <tiwai@suse.de> wrote:
>> > At Fri, 26 Mar 2010 18:59:17 +0100,
>> > Torsten Kaiser wrote:
>> >> Surprisingly this did not fix the delay. After all the trouble I had
>> >> with MSI on the other system, I was sure it was related to the fact,
>> >> that 2.6.33 tried to use MSI.
>> >> 2.6.33 with snd_hda_intel.enable_msi=0:
>> >> [    1.155712] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level,
>> >> low) -> IRQ 16
>> >> [    1.158852] input: AT Translated Set 2 keyboard as
>> >> /devices/platform/i8042/serio0/in
>> >> put/input2
>> >> [    1.232597] firewire_core: created device fw0: GUID 00dc10000129c48f, S400
>> >> [    1.252679] hda_codec: ALC888: BIOS auto-probing.
>> >> [    1.259206] HDA Intel 0000:01:05.2: PCI INT B -> GSI 19 (level,
>> >> low) -> IRQ 19
>> >> [    1.314745] input: GenPS/2 Genius Mouse as
>> >> /devices/platform/i8042/serio1/input/input3
>> >> [    4.322508] hda-intel: azx_get_response timeout, switching to
>> >> polling mode: last cmd=0x000f0000
>> >> [    5.332508] hda-intel: Codec #0 probe error; disabling it...
>> >> [    6.382508] hda_intel: azx_get_response timeout, switching to
>> >> single_cmd mode: last cmd=0x000f0000
>> >> [    6.420470] ALSA device list:
>> >> [    6.421545]   #0: HDA ATI SB at 0xfe7f4000 irq 16
>> >> [    6.422628]   #1: HDA ATI HDMI at 0xfe9e8000 irq 19
>> >>
>> >> ... if I had read these messages, instead of just copy&pasting them, I
>> >> could have noted, that the delay is from codec *0*, but MSI gets
>> >> enabled for codec *1*.
>> >> Info about the HDMI output:
>> >> 01:05.2 Audio device [0403]: ATI Technologies Inc Radeon X1200 Series
>> >> Audio Controller [1002:7919]
>> >>
>> >> But that is a clear bug in the alsa code: After codec 0 (the
>> >> integrated audio from the SB600) does not responds, it disables the
>> >> MSI support for codec 1 (part of the intregrated graphic chipset).
>> >> (I don't know if the HDMI audio support is working or not, as I do not
>> >> have an HDMI display I could attach there.)
>> >
>> > It's no bug.  The driver has only one flag to use MSI or not.
>> > So it disable MSI for both.  It's on the same board, after all,
>> > so better to take a safer option.
>>
>> It's a bug, because the failing codec 0 never used MSI at all. So
>> disabling it will not help.
>>
>> The first log (without the MSI disable option) showed:
>> codec 0 was using IRQ 16
>> codec 1 was using IRQ 19, but got switched to MSI-IRQ 27
>> then the 5 sec pause followed, because codec 0 failed.
>> switching off MSI for codec 1 seemed to work, because I only see
>> hda_intel on IRQ 16 and 19 in /proc/interrupts.
>> But the device list still showed "#1: HDA ATI HDMI at 0xfe9e8000 irq
>> 27" after the "No response from codec, disabling MSI" message!
>
> This is no driver behavior bug.  The point is that this string
> (chip->longname) was set at the time before disabling MSI.  The driver
> can switch back at any time, but the string remains as is.  One reason
> is that this field is exposed to the user-space as a sort of
> identifier, thus it's not always wise to change it dynamically during
> operation.  Yeah, it's confusing, but this is a trade-off.

Ah, ok. I understand this trade-off.

>> The second log showed the same sequence:
>> codec 0 using IRQ 16, codec 1 using 19, but this time without the switch to 27
>> the 5 sec pause and the failing of codec 0 still append, because the
>> ALC888 never used MSI.
>>
>> So I think there are two bugs:
>> One (the regression) that the ALC888 codec is no longer initialized
>> correctly, and so causing the delay during the boot.
>
> This seems irrelevant with the MSI.

What I wrote was bogus.
I confused the listing of #0 and #1 from the "ALSA device list" with
the message about "Codec #0"

After adding more debug output into hda_intel.c, I could see that the
initialisation of the SB600/ALC888 and the ATIHDMI "cards" are not
done in parallel (Like the messages from the input subsystem and the
firewire core that can be seen between the alsa messages), but serial.
So all the messages about the failing codec and MSI belong to
0000:01:05.2, the HDMI output.

But this is rather confusing: Alsa "card" #0, the SB600/ALC888, only
has one codec #3 and "card" #1 has a codec #0.

So the ALC888 (that never tries MSI) works perfect in 2.6.31 and 2.6.33.
The ATIHDMI has a regession that the initialisation in 2.6.33 needs ~6
seconds, while 2.6.31 only needed 0.08 seconds.
(Compared to the total time of 1.4 seconds that 2.6.31 needed until
"Freeing unused kernel memory" that is rather significant)

I can't say if the HDMI output in 2.6.31 worked, because I have no
devices that I could attach there to test this.

Torsten

>> And two that the fallback in azx_rirb_get_response() tries to disable
>> the never enabled MSI.
>
> And this is the designed behavior.  We've never trusted MSI from
> experiences.  So, prepared to go away from it at any moment :)
>
>
> Takashi
>
>> ... Umm. The code disagrees with my description of bug two: It already
>> does check for an per chip msi flag.
>>
>> I will try to add more debug to see what codec emits what errors, and
>> post again, with that information.
>>
>> Thanks, Torsten
>>
>

Re: [alsa-devel] Regressions: MSI vs HDA-Intel

[Clemens Ladisch]

Torsten Kaiser wrote:
> So all the messages about the failing codec and MSI belong to
> 0000:01:05.2, the HDMI output.

MSI seems to be broken on all(?) Radeon IGPs; see
<http://lkml.org/lkml/2010/3/30/290>.

Torsten, what is the output of "lspci -nn" on your first system?


Regards,
Clemens

Re: [alsa-devel] Regressions: MSI vs HDA-Intel

[Torsten Kaiser]

On Thu, Apr 1, 2010 at 9:26 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> Torsten Kaiser wrote:
>> So all the messages about the failing codec and MSI belong to
>> 0000:01:05.2, the HDMI output.
>
> MSI seems to be broken on all(?) Radeon IGPs; see
> <http://lkml.org/lkml/2010/3/30/290>.

If you refer to "PCI quirk: RS780/RS880: work around missing MSI
initialization", the system only has a RS690.
And as far as I know, MSI works for the graphics part:
~ # grep radeon /proc/interrupts
 25:          1        909   PCI-MSI-edge      radeon

(I'm only using fbcon, no Xserver running)

> Torsten, what is the output of "lspci -nn" on your first system?

00:00.0 Host bridge [0600]: ATI Technologies Inc RS690 Host Bridge [1002:7910]
00:01.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI
Bridge (Internal gfx) [1002:7912]
00:07.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI
Bridge (PCI Express Port 3) [1002:7917]
00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5
SATA [1002:4380]
00:13.0 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI0)
[1002:4387]
00:13.1 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI1)
[1002:4388]
00:13.2 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI2)
[1002:4389]
00:13.3 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI3)
[1002:438a]
00:13.4 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI4)
[1002:438b]
00:13.5 USB Controller [0c03]: ATI Technologies Inc SB600 USB
Controller (EHCI) [1002:4386]
00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller
[1002:4385] (rev 14)
00:14.1 IDE interface [0101]: ATI Technologies Inc SB600 IDE [1002:438c]
00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel
HDA) [1002:4383]
00:14.3 ISA bridge [0601]: ATI Technologies Inc SB600 PCI to LPC
Bridge [1002:438d]
00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI
Bridge [1002:4384]
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control [1022:1103]
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS690
[Radeon X1200 Series] [1002:791e]
01:05.2 Audio device [0403]: ATI Technologies Inc Radeon X1200 Series
Audio Controller [1002:7919]
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev
01)
03:03.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL-8029(AS) [10ec:8029]
03:05.0 Ethernet controller [0200]: MYSON Technology Inc SURECOM
EP-320X-S 100/10M Ethernet PCI Adapter [1516:0803]
03:06.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8
[Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev c0)

But please note: The only problem is the 6 second delay during HDMI
audio initialization. And that was not fixed by
snd_hda_intel.enable_msi=0.
As I don't have any hardware to attach to the HDMI port, I probably
can't help you debugging this further then "the delay is gone".

Thanks, Torsten