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: <469D1093.9070801@intel.com>
Date:	Tue, 17 Jul 2007 11:55:15 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	William Montgomery <william@...nicus.com>
CC:	Krzysztof Halasa <khc@...waw.pl>, linux-kernel@...r.kernel.org
Subject: Re: e100 PCI bridge problem

William Montgomery wrote:
> Krzysztof Halasa wrote:
> 
>> William Montgomery <william@...nicus.com> 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 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/