Date: Sat, 28 Dec 1996 13:18:43 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@FreeBSD.org, msmith@atrad.adelaide.edu.au Subject: Re: cvs commit: src/sys/scsi cd.c Message-ID: <199612280248.NAA00474@genesis.atrad.adelaide.edu.au> In-Reply-To: <199612271602.RAA13776@uriah.heep.sax.de> from J Wunsch at "Dec 27, 96 05:02:46 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
J Wunsch stands accused of saying: > As Michael Smith wrote: > > > The "unit is not spinning" status should probably be an error/status > > return to the generic SCSI layer in the "ideal world". > > Why? I was visualising it as a soft error : SCSI: driver: Do <this> can't, it's not spinning oops, start it ok, started Do <this> ok This obviates the need to explicitly perform the start command; any command (that requires the disk to be spinning) to a disk that is not spinning will cause the error handler to start it and retry the command(s) - this then covers the case where a disk is powered down for whatever reason while it's open. > No. For example, i've added extra code to the od driver to > (optionally) take the drive down if it's idle. I know that other > people have also been requesting this for fixed disks, e.g. in cases > where they use it as an archive disk which is only rarely used and > generates enough noise so you don't wanna have it running all the > time. Actually, the guy requesting this even thought of a timeout- > controlled spindown, while my code only uses device open/close events. A lot of SCSI disks don't seem to accept STOP UNIT. (I tried that here out of interest; none of the disks I could safely unmount accepted it; admittedly that's mostly CDC and Seagate disks.) > There are no other activities on that particular drive at device open > time either, provided you catch multiple open's with a driver-internal > flag. Things are more complicated for a timeout-controlled spindown, > but even then, you can still arrange for that target not seeing > multiple commands. That's not the issue I was confronting; I was more worried about other things (perhaps not aware of the need to spin a disk up) that might give up before the disk is ready. The avoid-multiple-commands would seem to be fairly straightforward; a flag on the command that indicates that all commands before it must be complete before it is queued, and that until it is complete no other commands can be queued. > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612280248.NAA00474>