This story begins in February with my 386DX40, UltraStor 14F, Quantum Pro-80S,
and SlackWare 1.0.2 (or somemthing, kernel 99pl14, I think). Something
happened after running continously for several months that caused Linux to
report errors for any kind of SCSI access. The UltraStor BIOS had no trouble
reformatting the drive. DOS had no trouble with the drive. Linux had trouble
but didn't in the past. Unrelated events caused this machine to stay turned
off until a couple of weeks ago.
A couple of weeks ago, the UltraStor, Quantum, and a Tandberg TDC-3660 were
placed in a 486DX33. Using Slackware 1.0.8 and the SCSINET disk, the contents
of the tape were (un)tar'ed into ext2 partition on my IDE drive. This took
several attempts. Then Linux was installed from one partition to separate
root and /usr partitions. Attempts to use the SCSI drive during installation
met with disaster.
After installation, use of the UltraStor would sometimes hang the system (no
panic, just nothing.) Other times it would fill /usr/adm/messages with "SCSI
Error 27070000" and more about 2nd half of retries.
Finally after trying every combination in the UltraStor book of DMA, bus
bus speed, IRQ, etc. (actually I only tried the ones I knew were not in
conflict with something else) the card solved my problems, it died outright.
Linux doesn't know the card exists, DOS ditto, DOS debug reports the card's
BIOS is full of FF's, usually. Sometimes the UltraStor BIOS splash screen
appears after a reboot. And I'm certian its jumpers are valid. This could
explain the problem in February and system hangs.
Out goes the UltraStor, in goes an ancient (1987 or 1988) Adaptec 1540B.
Fine from DOS, same old SCSI Error 27070000. But now I know this error happens
whenever a WRITE occurs. Like during mke2fs. But for some reason not during
fdisk. Linux fdisk works fine, no errors. Can mount an MS-DOS partition and
read it all day long, but writes fill /usr/adm/messages....
The 3 disk drives used all work fine with this hardware under DOS, and also
work fine on my Macintoshs. I don't think the problem is bad drive hardware.
I'm at wits end. Before the UltraStor died, I put it back in the 386, SCSI
Error 27070000 with a Seagate 125N (remember 20M 3.5" drives?) and two
different 105M Quantums (of different models). Same result with the Adaptec
in the 386. The 386 boots slow enough for me to read Linux's progress report:
the scsi card is found and identified correctly, then the devices attacted
are listed correctly, then a message "reseting SCSI for 2nd half of retries.."
or some such. When drives are listed later, /dev/sda is listed.
The 486 uses a Symphony chipset, the 386 uses OPTi. I've tried disabling every
special MB BIOS feature except CPU cache. I've tried every kernel I've found
at sunsite:/pub/Linux/Incoming the past few weeks (1.1.19 thru 1.1.24) using
-m486, limit to 16M RAM, UltraStor, Adaptec, and Lance drivers. No sound.
And one final hint: recently I bought 4 genuine NE2100's (new) for $39 each,
the above 386 and 486 are now networked, but I had to hard code IRQ 5 into
the Lance driver because it wasn't autodetecting (was able to recompile on one
machine quicker than I could figure out LILO on the other). I'm certian nothing
else is on IRQ5. Then I put one of the NE2100's in a 486 at work, strapped
identically to the ones at home (IRQ5, DMA5, IO at 0x360) and Linux can
detect that one! The work 486 uses an ETEQ chipset and has the cheapest VGA
card I could find at the time. The other 2 machines have MGA video.
So what do you suggest now? Just what is SCSI Error 27070000? How would I
trace (to/thru) the section of the kernel originating this problem? What
additional information do I need to provide? (I've read the FAQ's and HOWTO's)
73, David Kelly, N4HHE