There appears to be a severe bug or bugs in the Adaptec AHA-1742A EISA
driver for Solaris 2.1x86. In the following I shall describe problems,
that has been encountered so far.
1. There is a magneto-optical SCSI drive connected to
SCSI-target-1. Whenever this particular device is
referenced, the following error messages will appear on the
console four times in a rapid sequence:
Error for command 'mode sense', Error Level: Fatal
Requested Block: -1, Error Block: -1
Sense Key: Illegal Request
Vendor 'RICOH ': ASC = 0x24 (invalid cdb), ASCQ =
0x0, FRU = 0x0
After this, the drive appears to work normally, e.g.
mounting the drive will produce four of the above error
messages and then the mounted drive works.... almost.
The message itself makes no sense - what block -1? Drives
start their block numbering from 0, how come does the driver
request a block -1???
2. The SCSI-driver causes a kernel panic, if the disk is not
sliced with 4096 sectors reserved for alternate sectors.
First I tried to slice the MO-disk as follows (contents of
the device stanza listed):
* /dev/rdsk/c0t1d0p0 default partition map
* 512 bytes/sector
* 32 sectors/track
* 64 tracks/cylinder
* 278 cylinders
* 278 accessible cylinders
* Note: 1024 kbytes/cylinder
* 1: unmountable
* 10: read-only
* Partition Tag Flag First Sector Sector Count
0 2 00 2048 0
2 0 00 0 569344
6 8 00 2048 565248
9 9 01 567296 2048
Note especially the last line. That means, I reserved only
one cylinder for alternate sector mapping - one megabyte is
more than enough for such a purpose. However, Solaris wants
to allocate two cylinders for that purpose by default, i.e.
4096 sectors. Problem:
Whenever the disk with the above slicing is written onto or
read from, a kernel panic will result. The panic messages
vary, once it was segmentation fault, once illegal trap some
other time something else, but still memory oriented. Once
tar informed a segmentation fault and then sched told the
same and then there was a kernel panic.
3. I resliced the drive with the 4096 sectors for bad sector
mapping, and the problem went away - almost. Such a disk is
usable, if you write only small amounts of data onto it.
Whenever more than 5..10 megabytes is dumped onto the disk,
the kernel panics with some kind of a memory oriented
message (trap, segmentation fault, etc.). This problem can
be brought about with 100 % certainty by detarring a tape or
tarfile onto the MO-disk.
4. Whenever one attempts to read large amounts of data from any hard
disk, the kernel panics with a memory-oriented message. For instance, I
tried to read the table of contents from a 240 megabyte tarfile using
"tar tfv tarfile.tar". After reading some tens of MB the system panics
I would appreciate, if someone could tell how to work around
these problems. A patch would be nice...