Re: e100 PCI bridge problem

[Krzysztof Halasa <khc@pm.waw.pl>]

William Montgomery <william@opinicus.com> 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

Seems like bridge problem, doesn't it?
I wonder if the infinite retry is the same register every time?
Could it be a deadlock generated by/in the bridge? I'd look at
the bridge specs and maybe updates, perhaps they have some hints.

> 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to
> PCI Bridge (rev 82) (prog-if 00 [Normal decode])
>        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR+
                           ^^^^^^
>        Bus: primary=00, secondary=01, subordinate=03, sec-latency=32

I wonder why PERR is set and which device on bus #0 or #1 causes it?

> 01:0c.0 PCI bridge: Pericom Semiconductor: Unknown device 8150 (rev
> 02) (prog-if 00 [Normal decode])
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B-
>        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
>>TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>        Bus: primary=01, secondary=02, subordinate=03, sec-latency=32

It seems PERR on bus #0 isn't generated by this bridge, at least
it doesn't signal that in its status. Who knows, it may be unrelated.


Have you tried to perform the same tests on the other machine?
-- 
Krzysztof Halasa