linux-kernel - Re: e100 PCI bridge problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m3ejj6vjio.fsf@maximus.localdomain>
Date:	Tue, 17 Jul 2007 22:54:07 +0200
From:	Krzysztof Halasa <khc@...waw.pl>
To:	William Montgomery <william@...nicus.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: e100 PCI bridge problem

William Montgomery <william@...nicus.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/