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

[Torsten Kaiser]

On Fri, Mar 26, 2010 at 9:27 PM, Takashi Iwai <tiwai at 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 at 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