[2014] in linux-scsi channel archive
Re: Scsi removable disk patch
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Sun Jun 15 16:50:56 1997
Date: Sun, 15 Jun 1997 13:48:18 -0700
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: dormouse@farsrobt.demon.co.uk
CC: linux-scsi@vger.rutgers.edu, linux-kernel@vger.rutgers.edu
In-reply-to: <199706141156.MAA18628@farsrobt.demon.co.uk> (message from
Richard Waltham on Sat, 14 Jun 1997 12:56:34 +0100 (BST))
From: Richard Waltham <dormouse@farsrobt.demon.co.uk>
Date: Sat, 14 Jun 1997 12:56:34 +0100 (BST)
The behaviour of the scsi code with removable drives that automatically
spindown has been getting to me so I set out to fix it.
Problem was if the drive had spun down. Executing a command on that drive
would fail first time round, even though the drive would eventually spin up,
and the command would then have to be repeated, annoying and unnecessary.
eg e2fsck /dev/sdb3. First time it would fail saying it couldn't read the
partition table. Repeating the command and it executed OK.
After much digging through various bits of code, (I know a bit more about
the block device drivers than a couple of weeks ago:)) seems the root of the
problem is in sd.c - check_scsidisk_media_change() - called while opening the
device. This was always reporting not ready even for a drive with a
cartridge.
This does a test unit ready and fails if the drive is not ready for ANY
reason - and this will happen if the disk has no cartridge installed OR it
has spundown. Changing the test unit ready to a Start/Stop command fixes it.
With no cartridge installed it still fails, correctly, but now with a
cartridge installed it spins up and either reports disk changed if it has
been changed or executes normally if the cartridge hasn't been changed.
eg the Start/Stop command reports NOT READY with no cartridge, UNIT
ATTENTION if the cartridge has changed (or has been ejected and reinserted),
or GOOD STATUS if the cartridge has not changed.
This patch has been tested using kernel 2.0.29, ncr53c8xx 2.3 scsi driver,
with iomega jaz 1GB and Fujitsu 2512a MO drives. I have also tried it with
2.1.42 where the code affected is currently the same.
Patch is against 2.0.29 but also applies to 2.1.42 OK. Would be a useful
addition to 2.0.31:)
Excellent idea!
Leonard
