From: "Edward S. Marshall" <esm@logic.net>
To: linux-kernel@vger.kernel.org
Subject: PCI Problems [was Re: NIC lockup in 2.4.17 (SMP/APIC/Intel 82557)]
Date: 01 Feb 2002 11:52:06 -0600 [thread overview]
Message-ID: <1012585929.1843.45.camel@localhost.localdomain> (raw)
In-Reply-To: <3C5984C9.20104@candelatech.com>
In-Reply-To: <Pine.LNX.4.44.0201311741430.5601-100000@flubber.jvb.tudelft.nl> <3C5984C9.20104@candelatech.com>
On Thu, 2002-01-31 at 11:54, Ben Greear wrote:
> The only lockup problems I have run into are connecting some eepro nics to
> a 10bt hub, and using (cheap arsed, it appears) PCI riser cards. I have
> heard of some SMP related issues, but nothing concrete, and I don't
> have any SMP systems personally. You could try the e100, but I have
> no idea if it will be better or worse for your particular problem.
I was running into the same problems here; SMP system w/PCI riser card
(HP NetServer LPr), connected to a 10/100 switch. I'd get
"wait_for_command_timeout" errors all the time under moderate network
load. Switching to the e100 driver didn't help in the slightest.
Eventually, I'd experience a complete system lockup.
Replacing the card with a 3c59x-based card put the machine back in
service (I've completely written eepro100s off as a viable cards now),
although I still saw occasional PCI-related issues. Specifically:
Jan 23 10:11:37 x kernel: Uhhuh. NMI received. Dazed and confused, but
trying to continue
Jan 23 10:11:37 x kernel: eth0: Host error, FIFO diagnostic register
0000.
Jan 23 10:11:37 x kernel: eth0: PCI bus error, bus status 80000020
Jan 23 10:11:37 x kernel: You probably have a hardware problem with your
RAM chips
Jan 23 10:11:37 x kernel: eth0: Host error, FIFO diagnostic register
0000.
Jan 23 10:11:37 x kernel: eth0: PCI bus error, bus status 80000020
The last two messages will repeat indefinitely, usually with a hit to
the dist for each pair of log entries (resulting in a very distinctive
drive grinding). Memory problems don't seem to be the issue; with a
fairly extensive run of memtest86, everything came back clean.
Taking a few minutes to try and rectify the situation, I started
shutting down services and manually unloading modules to see what was
causing the problem. Unloading usbcore did the trick:
Jan 26 18:41:24 x kernel: eth0: Host error, FIFO diagnostic register
0000.
Jan 26 18:41:24 x kernel: eth0: PCI bus error, bus status 80000020
Jan 26 18:41:24 x kernel: eth0: Too much work in interrupt, status e003.
Jan 26 18:41:24 x kernel: usb.c: USB disconnect on device 1
Jan 26 18:41:24 x kernel: USB bus 1 deregistered
I've rebooted the machine since then, but have always unloaded usb-uhci
and usbcore after booting. The issue hasn't cropped up again, although
it happened every couple of days previously.
The kernel in question is Red Hat's kernel-smp-2.4.9-21 build.
--
Edward S. Marshall <esm@logic.net>
http://esm.logic.net/
-------------------------------------------------------------------------------
[ Felix qui potuit rerum cognoscere causas.
]
next prev parent reply other threads:[~2002-02-01 17:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-22 8:51 NIC lockup in 2.4.17 (SMP/APIC/Intel 82557) Robbert Kouprie
2002-01-22 14:53 ` James Bourne
2002-01-30 19:29 ` Robbert Kouprie
2002-01-30 21:06 ` Stephan von Krawczynski
2002-01-31 0:27 ` Robbert Kouprie
2002-01-31 12:35 ` Stephan von Krawczynski
2002-01-31 16:32 ` Ben Greear
2002-01-31 16:52 ` Robbert Kouprie
2002-01-31 17:54 ` Ben Greear
2002-01-31 19:17 ` Robbert Kouprie
2002-02-01 17:52 ` Edward S. Marshall [this message]
2002-02-01 18:16 ` PCI Problems [was Re: NIC lockup in 2.4.17 (SMP/APIC/Intel 82557)] nick
2002-02-01 19:44 ` Ken Brownfield
2002-02-01 23:54 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1012585929.1843.45.camel@localhost.localdomain \
--to=esm@logic.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.