William Montgomery wrote:
Krzysztof Halasa wrote:
William Montgomery <[email protected]> writes:
I am using a PCI analyzer and it shows the bus in an idle state after
the lockup. The PCI transactions just prior to the lockup show a
couple of interrupts from the card which appear to be handled
correctly. Anything I should be looking for in particular?
I'd try to check with other machine using "secondary" bus slot.
BTW: Are you able to analyze the "primary" bus transactions while
using the card in "secondary" bus? Perhaps there is something
wrong in front of the motherboard bridge?
I am able to analyze the primary bus while the using the card in the
secondary and I see a very interesting thing on lockup - the primary
side appears to be stuck on a read access to the memory mapped control
regs of the LAN chip (82559) in what appears to be infinite target
retries to the same address. Unfortunately I havent been able to
capture what occurs just prior to this happening. This is quite
different from what I capture on the secondary side; which is an idle bus
I have posted the lspci -vv listing below...
A broken motherboard may be hard to diagnose, unfortunately.
Can you post something like "lspci -vv" taken on both machines?
Here is the lspci -vv on the machine with lockups (edited for brevity):
00:00.0 Host bridge: Intel Corp. 82845G/GL[Brookdale-G]/GE/PE DRAM
Controller/Ho
Subsystem: Intel Corp. 82845G/GL[Brookdale-G]/GE/PE DRAM
Controller/Host
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort-
Latency: 0
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=64M]
Capabilities: [e4] #09 [1105]
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to PCI
Bridge (rev 82) (prog-if 00 [Normal decode])
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+
PERR+ set... not good - this certainly will cause major issues
Auke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]