Krzysztof Halasa wrote:
William Montgomery <william@xxxxxxxxxxxx> writes: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 am using a PCI analyzer and it shows the bus in an idle state afterI'd try to check with other machine using "secondary" bus slot.
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?
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 have posted the lspci -vv listing below...
A broken motherboard may be hard to diagnose, unfortunately.Here is the lspci -vv on the machine with lockups (edited for brevity):
Can you post something like "lspci -vv" taken on both machines?
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+