All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: "Xu, Andiry" <Andiry.Xu@amd.com>
Cc: Takashi Iwai <tiwai@suse.de>,
	alsa-devel@alsa-project.org, 741825@bugs.launchpad.net
Subject: Re: HDA record fails with FIFO error
Date: Thu, 07 Apr 2011 16:30:00 +0200	[thread overview]
Message-ID: <4D9DCA68.40302@canonical.com> (raw)
In-Reply-To: <s5h7hb6pe20.wl%tiwai@suse.de>

On 2011-04-07 12:10, Takashi Iwai wrote:
> At Thu, 7 Apr 2011 16:54:50 +0800,
> Xu, Andiry wrote:
>>
>> Hi Takashi,
>>
>> Currently I encountered an HD audio issue reported by customer on a
>> Lenovo x100e system. Sometimes, but not always, when starting a
>> recording stream through the HDA controller, the controller generates a
>> large amount of interrupts (~40 000 interrupts per second). After this
>> has happened, jack sense (i e unsolicited events from the codec) stops
>> working until the next system reboot.

This seems more reproducible now than it was a while ago, now it seems 
to happen more often than not.

>> SD0STS returns a FIFO error (0x28) in interrupt handler. The interrupt
>> service routine acknowledges this error but does not do anything to
>> counteract the root cause to the problem, so it appears again and again.
>> Restarting the stream does not seem to help. Enable MSI or not does not
>> help either.
>>
>> The issue occurs on 2.6.35 and 2.6.38-rc8+, have not tried latest kernel
>> yet but I think it's also there. FIFO error indicates FIFO overrun
>> occurring while the RUN bit is set, but the driver simply acknowledge
>> and clear the error. I wonder what the root cause and the right
>> treatment are in this case. Any suggestions?

Brainstorming:
1) We could try adding udelays at random places.
2) There are a few workarounds for different chips already in 
hda_intel.c, maybe try applying them here as well.

Does that make sense to either of you?

> FIFO_ERR is actually never handled, so basically we can ignore.
> Simply disabling it like below works around your problem?
>
> Of course, a proper handling of FIFO error would be better, but
> this may need more code rewrites.

This does not fix the error in question, it removes the interrupts all 
right, but neither recording nor jack sense starts to work.

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

  reply	other threads:[~2011-04-07 14:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-07  8:54 HDA record fails with FIFO error Xu, Andiry
2011-04-07 10:10 ` Takashi Iwai
2011-04-07 14:30   ` David Henningsson [this message]
2011-04-07 14:42     ` Takashi Iwai
2011-04-11 13:33     ` David Henningsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D9DCA68.40302@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=741825@bugs.launchpad.net \
    --cc=Andiry.Xu@amd.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.