Re: e100 PCI bridge problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux