[2363] in linux-scsi channel archive
Re: BusLogic 958 and Fujistu 2949 drives...
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Thu Aug 28 02:03:01 1997
Date: Wed, 27 Aug 1997 22:59:33 -0700
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: msimons@saic1.com
CC: linux-scsi@vger.rutgers.edu
In-reply-to: <199708271824.OAA08371@aura.saic1.com> (message from Mike Simons
on Wed, 27 Aug 1997 14:24:09 -0400 (EDT))
From: Mike Simons <msimons@saic1.com>
Date: Wed, 27 Aug 1997 14:24:09 -0400 (EDT)
I'm looking for pointers to fix what appears to be a SCSI kernel
driver problem with either the BusLogic driver, the ext2fs driver,
or the SCSI sub-system. It is possible a problem with the drives
themselves and I'll start asking Fujitsu tech support about that...
First the hardware:
Pentium 166 Mhz
On a noname motherboard with the 430VX chipset. *1
64 Megs of EDO memory
BusLogic 968, with most recent BIOS.
Fujitsu 2949UW drives...
OS:
Kernel 2.0.30 nothing special...
Description:
When the controller limits transfer speed at 10Mhz the drives perform
fine. For everything...
When the boot partition is set at 10Mhz and the non-critical drives
are set to 20Mhz, it boots up fine. Sequential reading and writing to the
drives is performing fine (dd style access)... but when any attempt to
make a filesystem, mkswap, mount a previously made partition, etc...
generates a bazillion scsi error messages... and I am certain the
actually write operations do not complete but given time the read
operations do. No kernel crashes, but the system is unusable.
dd style access is actually far slower than through the file system.
I have tried swapping cables... I am sure the cables are rated for
Ultra. It appeared at 1st to be hardware problems... but I can't
explain why the read/write operations succeed for *sequential* but fail
for non-sequential access.
Most likely there are bugs in the Fujitsu disk drive firmware. If the system
is stable at 10.0MHz, then the problem is almost certainly hardware, and it's
far more likely to be the disk drive than the host adapter. The kernel and
driver know nothing about the synchronous transfer rate, other than to report
it.
... this is what the error codes look like:
Aug 22 10:33:18 myth kernel: SCSI disk error : \
host 0 channel 0 id 0 lun 0 return code = 18000002
Aug 22 10:33:18 myth kernel: \
extra data not valid Current error sd08:01: sense key Aborted Command
Aug 22 10:33:18 myth kernel: scsidisk I/O error: dev 08:01, sector 297174
Aug 22 10:33:18 myth kernel: SCSI disk error : \
host 0 channel 0 id 0 lun 0 return code = 18000002
This is what the SCSI spec says about "Aborted Command":
| Bh | ABORTED COMMAND. Indicates that the target aborted the command. |
| | The initiator may be able to recover by trying the command again. |
Most likely the disk firmware is broken. I don't see how the driver, host
adapter, or kernel could cause this.
I have partitioned each of the drives so that can perform read/write
tests to any of the three drives during the evenings without losing data.
If someone would like to see more of these I can provide the output
of a single mke2fs call... a few thousand lines ;)
Any suggestions?
Call Fujitsu.
--
Thanks,
Mike Simons
Science Applications International Corporation
msimons@saic1.com 703-925-5674
*1: I _had_ the BusLogic card in a SuperMicro P55T2S 430HX motherboard,
but Jo, at BusLogic's tech support said that there are some
incompatibilities between SuperMicro and BusLogic (blame SuperMicro
of course ;). There were random lockups inside the SCSI BIOS even
with the newest version of the BIOS. The Linux system seemed as
stable... as it is now (we did the upgrade to try to solve the
problem described above).
I would put it back in that motherboard to test things out further
... but switching motherboards fixed something. =)
My plan is to test the card in an ASUS board and purchase another board
if it works fine... for now it is stuck in this VX board.
Supermicro is notorious for not bothering to test with BusLogic even though
they were given cards to test with. They OEM Adaptec, so they have little
impetus to care about BusLogic until customers complain. I tried a P6SNE early
on only to find that it didn't even assign PCI resources to the BusLogic cards.
I avoid Supermicro now; I've had too much aggravation from them.
Leonard
