Comment 14 for bug 741825

On 2011-05-16 15:50, Takashi Iwai wrote:
> At Mon, 16 May 2011 15:42:51 +0200,
> David Henningsson wrote:
>>
>> Okay, home again and ready to test the latest stuff on the Lenovo x100e.
>
> Good to hear you back well.

:-) Nice to meet you!

>> This was with today's snapshot of sound-2.6, which includes commits
>> 447ee6a7 and d507cd66, and with Andiry's disable-64-bit DMA patch [1] on
>> top of that.
>
> The 64bit fix would make sense only when you have a RAM over 4GB,
> I suppose. But, still worth to try...
>
>> With PulseAudio installed, it happens almost every time.
>>
>> I have also reproduced the issue without PulseAudio, although only once.
>> What I did then was the following:
>>
>> 1) Write some garbage in the beginning of /etc/pulse/default.pa to
>> prevent PulseAudio to start up.
>>
>> 2) Started:
>> arecord -Dplughw:0 -f cd test.wav
>>
>> 3) With that stream running, opened a second terminal window and started:
>> speaker-test -Dplughw:0 -c 2 -t sine
>>
>> Now both applications crashed and the interrupts on the hda_intel line
>> went up with ~400000 interrupts. Error message from arecord:
>>
>> arecord: pcm_read:1692: read error: Input/output error
>>
>> Error message from speaker-test:
>> Write error: -5,Input/output error
>> xrun_recovery failed: -5,Input/output error
>> Transfer failed: Operation not permitted
>
> I tested this procedure on a test machine here with AMD Hudson,
> but can't reproduce the issue. You could get this only once?

I have managed to get it two more times now:
arecord crashes with the same error, interrupts up between 300000 and
400000, however this time speaker-test has kept working and there has
not been any "switching to polling mode" in dmesg.

I had to keep speaker-test running for a random while (so it can
repeatedly start and stop streams) before it happened.

But at least this rules out PulseAudio as the root cause of the
problems, although it seems more easily to trigger with PulseAudio.

>> There is also a dmesg message: "hda-intel: azx_get_response timeout,
>> switching to polling mode: last cmd=0x010f0600", but I'm 100% sure it
>> came from the exact point when these applications crashed.
>
> Switching to polling mode itself isn't that critical. It can happen
> in many other platforms. But of course it'd make sense that it happen
> with the bug -- it's about the interrupts, after all.
>
>
> Takashi
>
>> I tried to reproduce the same thing, but it only happened once.
>>
>> --
>> David Henningsson, Canonical Ltd.
>> http://launchpad.net/~diwic
>>
>> [1]
>> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/741825/+attachment/2123974/+files/snd_test.patch
>>
>

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic