* HDA record fails with FIFO error
@ 2011-04-07 8:54 Xu, Andiry
2011-04-07 10:10 ` Takashi Iwai
0 siblings, 1 reply; 5+ messages in thread
From: Xu, Andiry @ 2011-04-07 8:54 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]
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.
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?
Thanks & Best regards,
Andiry
[-- Attachment #2: PciMultimedia.txt --]
[-- Type: text/plain, Size: 567 bytes --]
00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383]
Subsystem: Lenovo Device [17aa:21b2]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 32 bytes
Interrupt: pin ? routed to IRQ 16
Region 0: Memory at d0600000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
[-- Attachment #3: Card0.Amixer.values.txt --]
[-- Type: text/plain, Size: 1032 bytes --]
Simple mixer control 'Master',0
Capabilities: pvolume pswitch pswitch-joined penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 74
Mono:
Front Left: Playback 72 [97%] [-2.00dB] [on]
Front Right: Playback 72 [97%] [-2.00dB] [on]
Simple mixer control 'PCM',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 255
Mono:
Front Left: Playback 255 [100%] [0.00dB]
Front Right: Playback 255 [100%] [0.00dB]
Simple mixer control 'Beep',0
Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
Playback channels: Mono
Limits: Playback 0 - 7
Mono: Playback 0 [0%] [-28.00dB] [on]
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch penum
Capture channels: Front Left - Front Right
Limits: Capture 0 - 80
Front Left: Capture 72 [90%] [-2.00dB] [on]
Front Right: Capture 72 [90%] [-2.00dB] [on]
Simple mixer control 'Analog Mic Boost',0
Capabilities: cenum
Items: '0dB' '10dB' '20dB' '30dB' '40dB'
Item0: '20dB'
[-- Attachment #4: Card0.Codecs.codec.0.txt --]
[-- Type: text/plain, Size: 8354 bytes --]
Codec: Conexant CX20582 (Pebble)
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x14f15066
Subsystem Id: 0x17aa21b2
Revision Id: 0x100301
No Modem Function Group found
Default PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
GPIO: io=4, o=0, i=0, unsolicited=1, wake=0
IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
Node 0x10 [Audio Output] wcaps 0xc1d: Stereo Amp-Out R/L
Control: name="Master Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Device: name="CONEXANT Analog", type="Audio", device=0
Amp-Out caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1
Amp-Out vals: [0x48 0x48]
Converter: stream=5, channel=0
PCM:
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Node 0x11 [Audio Output] wcaps 0xc1d: Stereo Amp-Out R/L
Amp-Out caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1
Amp-Out vals: [0x3c 0x3c]
Converter: stream=0, channel=0
PCM:
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Node 0x12 [Audio Output] wcaps 0x611: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category: 0x0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Node 0x13 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
Control: name="Beep Playback Volume", index=0, device=0
ControlAmp: chs=1, dir=Out, idx=0, ofs=0
Control: name="Beep Playback Switch", index=0, device=0
ControlAmp: chs=1, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x07, nsteps=0x07, stepsize=0x0f, mute=0
Amp-Out vals: [0x00]
Node 0x14 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L
Device: name="CONEXANT Analog", type="Audio", device=0
Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=1
Amp-In vals: [0x48 0x48] [0x80 0x80] [0x48 0x48] [0x80 0x80]
Converter: stream=1, channel=0
SDI-Select: 0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 4
0x17 0x18 0x23* 0x24
Node 0x15 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L
Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=1
Amp-In vals: [0x4a 0x4a] [0x4a 0x4a] [0x4a 0x4a] [0x4a 0x4a]
Converter: stream=0, channel=0
SDI-Select: 0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 4
0x17* 0x18 0x23 0x24
Node 0x16 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L
Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=1
Amp-In vals: [0x4a 0x4a] [0x4a 0x4a] [0x4a 0x4a] [0x4a 0x4a]
Converter: stream=0, channel=0
SDI-Select: 0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 4
0x17* 0x18 0x23 0x24
Node 0x17 [Audio Selector] wcaps 0x30050d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
Amp-Out vals: [0x02 0x02]
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 4
0x1a 0x1b* 0x1d 0x1e
Node 0x18 [Audio Selector] wcaps 0x30050d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 4
0x1a* 0x1b 0x1d 0x1e
Node 0x19 [Pin Complex] wcaps 0x400581: Stereo
Pincap 0x0000001c: OUT HP Detect
Pin Default 0x032110f0: [Jack] HP Out at Ext Left
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Unsolicited: tag=37, enabled=1
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 2
0x10* 0x11
Node 0x1a [Pin Complex] wcaps 0x400481: Stereo
Pincap 0x00001324: IN Detect
Vref caps: HIZ 50 80
Pin Default 0x400001f0: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=00, enabled=0
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Node 0x1b [Pin Complex] wcaps 0x400581: Stereo
Pincap 0x00011334: IN OUT EAPD Detect
Vref caps: HIZ 50 80
EAPD 0x2: EAPD
Pin Default 0x03a110f0: [Jack] Mic at Ext Left
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00: VREF_HIZ
Unsolicited: tag=38, enabled=1
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 2
0x10* 0x11
Node 0x1c [Pin Complex] wcaps 0x400581: Stereo
Pincap 0x00000014: OUT Detect
Pin Default 0x400001f0: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x00:
Unsolicited: tag=00, enabled=0
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 2
0x10* 0x11
Node 0x1d [Pin Complex] wcaps 0x400581: Stereo
Pincap 0x00010034: IN OUT EAPD Detect
EAPD 0x2: EAPD
Pin Default 0x400001f0: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN
Unsolicited: tag=00, enabled=0
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 2
0x10* 0x11
Node 0x1e [Pin Complex] wcaps 0x400481: Stereo
Pincap 0x00000024: IN Detect
Pin Default 0x400001f0: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN
Unsolicited: tag=00, enabled=0
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Node 0x1f [Pin Complex] wcaps 0x400501: Stereo
Pincap 0x00000010: OUT
Pin Default 0x921701f0: [Fixed] Speaker at Int Front
Conn = Analog, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 2
0x10* 0x11
Node 0x20 [Pin Complex] wcaps 0x400781: Stereo Digital
Pincap 0x00000010: OUT
Pin Default 0x400001f0: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Unsolicited: tag=00, enabled=0
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 1
0x12
Node 0x21 [Audio Output] wcaps 0x611: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category: 0x0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Node 0x22 [Pin Complex] wcaps 0x400781: Stereo Digital
Pincap 0x00000010: OUT
Pin Default 0x400001f0: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Unsolicited: tag=00, enabled=0
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 1
0x21
Node 0x23 [Pin Complex] wcaps 0x40040b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x04, stepsize=0x2f, mute=0
Amp-In vals: [0x02 0x02]
Pincap 0x00000020: IN
Pin Default 0x95a601f0: [Fixed] Mic at Int Top
Conn = Digital, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Node 0x24 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In
Amp-In caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1
Amp-In vals: [0x00 0x00] [0x00 0x00]
Power states: D0 D1 D2 D3 D3cold
Power: setting=D0, actual=D0
Connection: 2
0x10 0x11
Node 0x25 [Vendor Defined Widget] wcaps 0xf00000: Mono
[-- Attachment #5: interrupts.txt --]
[-- Type: text/plain, Size: 1201 bytes --]
CPU0
0: 4304 IO-APIC-edge timer
1: 125 IO-APIC-edge i8042
7: 1 IO-APIC-edge
8: 1 IO-APIC-edge rtc0
9: 669 IO-APIC-fasteoi acpi
12: 6508 IO-APIC-edge i8042
16: 487299 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, hda_intel
17: 0 IO-APIC-fasteoi ehci_hcd:usb1
18: 1730 IO-APIC-fasteoi ohci_hcd:usb5, radeon
19: 392 IO-APIC-fasteoi ehci_hcd:usb2
22: 5439 IO-APIC-fasteoi ahci
40: 0 PCI-MSI-edge PCIe PME
41: 0 PCI-MSI-edge PCIe PME
42: 61 PCI-MSI-edge eth0
NMI: 0 Non-maskable interrupts
LOC: 10271 Local timer interrupts
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
IWI: 0 IRQ work interrupts
RES: 0 Rescheduling interrupts
CAL: 0 Function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
THR: 0 Threshold APIC interrupts
MCE: 0 Machine check exceptions
MCP: 1 Machine check polls
ERR: 1
MIS: 0
[-- Attachment #6: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: HDA record fails with FIFO error
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
0 siblings, 1 reply; 5+ messages in thread
From: Takashi Iwai @ 2011-04-07 10:10 UTC (permalink / raw)
To: Xu, Andiry; +Cc: alsa-devel
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.
>
> 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?
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.
thanks,
Takashi
---
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 70a9d32..a88baf4 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -285,7 +285,7 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO1, SDO2, SDO3 };
#define SD_INT_DESC_ERR 0x10 /* descriptor error interrupt */
#define SD_INT_FIFO_ERR 0x08 /* FIFO error interrupt */
#define SD_INT_COMPLETE 0x04 /* completion interrupt */
-#define SD_INT_MASK (SD_INT_DESC_ERR|SD_INT_FIFO_ERR|\
+#define SD_INT_MASK (SD_INT_DESC_ERR|/*SD_INT_FIFO_ERR|*/ \
SD_INT_COMPLETE)
/* SD_STS */
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: HDA record fails with FIFO error
2011-04-07 10:10 ` Takashi Iwai
@ 2011-04-07 14:30 ` David Henningsson
2011-04-07 14:42 ` Takashi Iwai
2011-04-11 13:33 ` David Henningsson
0 siblings, 2 replies; 5+ messages in thread
From: David Henningsson @ 2011-04-07 14:30 UTC (permalink / raw)
To: Xu, Andiry; +Cc: Takashi Iwai, alsa-devel, 741825
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HDA record fails with FIFO error
2011-04-07 14:30 ` David Henningsson
@ 2011-04-07 14:42 ` Takashi Iwai
2011-04-11 13:33 ` David Henningsson
1 sibling, 0 replies; 5+ messages in thread
From: Takashi Iwai @ 2011-04-07 14:42 UTC (permalink / raw)
To: David Henningsson; +Cc: alsa-devel, Xu, Andiry, 741825
At Thu, 07 Apr 2011 16:30:00 +0200,
David Henningsson wrote:
>
> 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?
Hm, I don't think this would make any difference. For the DMA engine,
it doesn't matter whether there is some delays in the code or not.
It's set up for the free-wheel run. The driver just reads the current
position, but changes anything else than the buffer contents.
(And FIFO XRUN is irrelevant with the buffer contents.)
> > 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.
Well, the unanswered question is why this interrupt is generated.
We don't know whether this interrupt is really correctly generated.
It might be wrongly triggered by some condition. If so, masking and
ignoring the false error is the right fix, I guess.
Takashi
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HDA record fails with FIFO error
2011-04-07 14:30 ` David Henningsson
2011-04-07 14:42 ` Takashi Iwai
@ 2011-04-11 13:33 ` David Henningsson
1 sibling, 0 replies; 5+ messages in thread
From: David Henningsson @ 2011-04-11 13:33 UTC (permalink / raw)
To: Xu, Andiry; +Cc: Takashi Iwai, alsa-devel, 741825
On 2011-04-07 16:30, David Henningsson wrote:
> 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.
Hi Andiry,
I'm still trying to get a grip of what the error could be. Having
re-enabled the FIFO interrupt again and some debug printk's the first
time the FIFO error happens, I notice that it happens after a while,
where "a while" ranges from 100 ms to 4 s or so. CBL is 65536 and LPIB
seems to be a reasonable value (a value below 65536, approximately
corresponding to the time the stream has been running). BDL entries look
correct.
Can it be something else than a chipset bug in this case? I'm trying to
rule out every possible driver problem I can think of.
Btw - how can a recording FIFO overrun in the first place? I mean, if we
have two BDLE buffers with 32768 bytes in each (assume bl_pos_adj=0 for
this example), the FIFO should just write to the first, then the second,
then the first again, and so on, without having overrun errors.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-04-11 13:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2011-04-07 14:42 ` Takashi Iwai
2011-04-11 13:33 ` David Henningsson
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.