From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936802AbXGQUyY (ORCPT ); Tue, 17 Jul 2007 16:54:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757433AbXGQUyM (ORCPT ); Tue, 17 Jul 2007 16:54:12 -0400 Received: from khc.piap.pl ([195.187.100.11]:53241 "EHLO khc.piap.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760006AbXGQUyL (ORCPT ); Tue, 17 Jul 2007 16:54:11 -0400 To: William Montgomery Cc: linux-kernel@vger.kernel.org Subject: Re: e100 PCI bridge problem References: <4697B85B.4040902@opinicus.com> <46995998.70706@opinicus.com> <469D0A81.3000001@opinicus.com> From: Krzysztof Halasa Date: Tue, 17 Jul 2007 22:54:07 +0200 In-Reply-To: <469D0A81.3000001@opinicus.com> (William Montgomery's message of "Tue, 17 Jul 2007 14:29:21 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org William Montgomery 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- > SERR- 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- > SERR- 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