[378] in linux-net channel archive
Re: Linux 1.2.8 sudden death - SMC the cause?
daemon@ATHENA.MIT.EDU (Marek Michalkiewicz)
Fri May 26 17:21:22 1995
From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
To: linux-net@vger.rutgers.edu
Date: Fri, 26 May 1995 21:29:54 +0200 (MET DST)
In-Reply-To: <hpa.2fc4d1ae.Swedes.have.more.fun@asgard.yggdrasil.com> from "H. Peter Anvin" at May 25, 95 06:53:13 pm
H. Peter Anvin:
> The SMC Ultra has a separate driver, and the WD 80x3 driver should not
> be used with it. This is almost certainly your problem. I suspect
> your kernel has the WD 80x3 driver compiled in, but not the SMC Ultra
> one. You need a kernel with the SMC Ultra driver compiled in.
Maybe the WD 80x3 driver shouldn't detect the SMC Ultra? IMHO it is
a bug if it does...
I had a lockup today with a WD8003-old. No users were logged in at that
time (I know because I had top running on one VC, I disabled the screen
saver, and the VC with top was active at the time of the lockup).
There was one possibly relevant message in /var/adm/debug:
eth0: Tx timed out, IRQ conflict? TSR=0x0, ISR=0x80, t=3099.
(this was logged just before the lockup)
and here are messages logged during few hours after a reboot:
eth0: Tx timed out, IRQ conflict? TSR=0x40, ISR=0x80, t=276.
eth0: Tx timed out, IRQ conflict? TSR=0x40, ISR=0x80, t=251.
eth0: Tx timed out, IRQ conflict? TSR=0x40, ISR=0x80, t=23.
eth0: Tx timed out, cable problem? TSR=0x80, ISR=0x0, t=302.
(without a crash)
There are no IRQ conflicts in this machine as far as I know: it is
a 386 with an IDE hard disk.
eth0: WD80x3 at 0x380, 00 00 C0 90 12 94 assigning address 0xd0000
WD8003-old, IRQ 5, shared memory at 0xd0000-0xd1fff.
wd.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)
This is 1.2.8 with the latest fixes. Another machine running the same
kernel has a SMC 8013 card and has lockups too (not very often, usually
every few days). Unfortunately I have no other cards to try.
Is it possible for a 8390-based shared memory card to cause a bus hang?
Or maybe this is some other kernel problem? These lockups are not new
with 1.2.8 - I've seen them with late 1.1.x kernels too. Looks like
the new kernels are less stable than the early 1.1.x :-(.
Regards,
Marek
