[3005] in linux-scsi channel archive
Re: SCSI and SMP not getting along.
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Sun Dec 28 16:10:27 1997
Date: Sun, 28 Dec 1997 13:05:13 -0800
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: bpavane@liii.com
CC: linux-smp@vger.rutgers.edu, linux-scsi@vger.rutgers.edu
In-reply-to: <Pine.LNX.3.96.971227234256.2714A-100000@bpisles.liii.com>
(message from Brian Pavane on Sat, 27 Dec 1997 23:48:30 -0500 (EST))
Date: Sat, 27 Dec 1997 23:48:30 -0500 (EST)
From: Brian Pavane <bpavane@liii.com>
I just put together a dual P166MMX linux box. I know I didn't need the
MMX, but it's all I could get my hands on. I put a BusLogic BT-958 SCSI
card in the machine, with a Micropolis 4743WS hanging off of it. However,
whenever I have my kernel compiled for SMP, I get poor, if not horrid
results from the machine. With all the 2.0.3x kernel's I was unable to
correctly boot my machine, due to the fact that upon booting it would not
be able to locate my scsi drive (sda). I then attempted to compile
2.1.76, which successfully booted in SMP mode. However, upon doing
something that would cause heavy disk usage (untar'ing a kernel source)
the machine totally locked up. I have also had the SCSI card re-intialize
serveral times. Here is some information from /proc, any and all help is
much appreciated. The motherboard I'm using is a Tyan IV D.
I'd start first by building a uniprocessor kernel and get that to operate
reliably. Micrpolis drives have often been problematic, and I suspect the
4743WS is no different. Last summer I tested a borrowed Tomahawk and it could
not even run a few minutes of my usual torture tests without requiring a power
cycle to recover. Very bad. Micropolis had promised the folks at Mylex a
firmware update to correct the problems, but I don't think they ever received
one.
Your best bet is to start by disabling tagged queuing by booting with the
kernel command line "BusLogic=TQ:Disable" (be sure to compile the driver into
your kernel). I'd also suggest you not attempt enabling Ultra speed until the
system is stable running at normal Fast speed. You might also want to update
your BT-958 firmware to 5.06J (available from my Linux web page at
http://www.dandelion.com/Linux/), but I rather doubt that will help.
Date: Sun, 28 Dec 1997 14:44:52 -0500 (EST)
From: Brian Pavane <bpavane@liii.com>
I compiled the machine without smp, and then ran things that would tax the
scsi card/drive. Such things as untar'ing kernel sources, doing ls -laR's
of the entire drive, moving files accross partitions, to name a few.
During this I got the following data printed to my console.
scsi0: Aborting CCB #10979 to Target 0
SCSI host 0 abort (pid 10956) timed out - resetting
.
.
.
scsi0: Resetting BusLogic BT-958 due to Target 0
scsi0: *** BusLogic BT-958 Initialized Successfully ***
scsi0: Tagged Queuing now active for Target 0
The above looks like a SCSI bus hang or a device hang. Since tagged queuing
was again enabled, that means the device must have been accepting commands
again.
When I compile 2.0.32 with SMP, I get the following error upon bootup, when
it does the Partition Check.
VFS: Cannot open root device 08:01
Kenel panic: VFS: Unalbe to mount root fs on 08:01
Did the kernel recognize the SCSI host adapter in this case?
Leonard
