#1017: "rx FIFO overrun" prevents traffic from flowing
------------------------------------+---------------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: defect | Status: new
Priority: critical | Milestone:
Component: madwifi: driver | Version: trunk
Resolution: | Keywords:
Patch_attached: 0 |
------------------------------------+---------------------------------------
Comment (by [EMAIL PROTECTED]):
Just so you know, the comment from AK is absolutely correct.
I did some reading in Intel specs - the NMI in this case is triggered by a
PCI SERR condition (low-level error signalling). This can also be seen in
lspci -vv:
Before the NMI:
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and
945GT Express Memory Controller Hub (rev 03)
Subsystem: Lenovo Unknown device 2015
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
After the NMI:
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and
945GT Express Memory Controller Hub (rev 03)
Subsystem: Lenovo Unknown device 2015
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ >SERR+ <PERR-
Note the change of the SERR on the Status: line. I'm not sure if it's my
BIOS that clears up the reason, but reading the low level chipset doesn't
reveal the reason for the NMI to me. Clearing the status bit is possible
but doesn't help. For me, a suspend/resume cycle is the only thing that
helps (short of rebooting). Unloading the driver isn't sufficient.
Furthermore, diff -U 100 lspci.freshboot.txt lspci.afternmi.txt shows that
a PCI Master Abort occured (Status: <MAbort+). I'm not the PCI (Express)
guru so I don't know what causes that, nor if it is somehow recoverable.
The system is a Lenovo T60p, AR5418, kernel 2.6.23-gentoo-r1.
Oh, and in case you wonder what's happening. The "rx FIFO overrun;
resetting" happens because the card doesn't get an IRQ through (or just
doesn't generate one) after it receives (a) frame(s). You can watch
/proc/interrupts (after you make sure you don't send anything and remove
all drivers that share the interrupt).
--
Ticket URL: <http://madwifi.org/ticket/1017#comment:103>
madwifi.org <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Madwifi-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-tickets
