Andrew Morton wrote: > > Begin forwarded message: > > Date: Sat, 03 Jun 2006 21:47:48 +0200 > From: Ruben Faelens <parasietje@xxxxxxxxx> > To: LKML <linux-kernel@xxxxxxxxxxxxxxx> > Subject: SCSI device not spinning up on rw > > > I have a SCSI disk, which I want to spin down when the system is not in > use. I do this by using sdparm, scsi-spin or sg-utils. These tools all > spin down the SCSI drive by using an IOCTL. > > Problem is that the kernel doesn't spin the drive back up. When a > process requests data from the disk (a simple ls), the kernel responds > with an I/O error. After some of these errors, reiserfs marks the drive > read-only. > > This bug is also described here: > http://bugzilla.kernel.org/show_bug.cgi?id=6627 > > This bug was solved by scsi-idle (http://lost-habit.com/scsi.html) in > 2.4 kernels, but the patch hasn't been ported to 2.6. It's also a dirty > hack, by someone who knows little of the internals of the SCSI system. > > I read the LKML-archives, and they turned up some old posts in 09-2005 > about this subject, where somebody says implementing this in SCSI could > get messy. > > However, it seems to me that all it takes is a call to sd_spinup_disk() > in sd.c. When I add this in sd_init_command, the kernel crashes when > confronted with a SCSI disk. Then again, I'm no kernel hacker, this is > the first time I even read the source... > > Could someone more experienced than me look into this? IMHO this should > be doable, because the spinup-on-read/write has been implemented in SATA > and IDE I/O subsystems. Then again, I read SATA and IDE disks handle > this for themselves. > > So if someone would enlighten me, that would be great! > > As a side note: maybe it's my disk that's having these problems? It's an > old SCSI disk in a HP 712/80 from 1994. Manual spinup does work however... Ruben, IMO the sd driver should spin up drives if need be. Perhaps the sd driver could have a parameter to control this. Note that spinning up can take up to 30 seconds so some timeouts might go off upstream. However this has been happening silently for a long time in the ATA disk world. A timeout (e.g. using 'hdparm -S <n>') spins down the disk and the next data transfer command to that disk spins it back up again with an attendant delay for read commands. The SCSI power management model uses the START STOP UNIT SCSI command. Apart from the fact that the sd driver actually has to do something when a "not ready, initializing command required" error occurs, the same thing would be happening as far as the higher layers are concerned (i.e. reads are delayed). To see how silly the current situation is consider a SATA disk behind a SAT layer **. If I use the "front door" and stop the disk with a START STOP UNIT SCSI command then SAT will put the SATA disk into standby mode. Active intervention is needed by the sd driver to spin it up but sd doesn't play. Now if I use the "back door" and send a STANDBY ATA command via the ATA PASS THROUGH SCSI command then the SATA disk goes into standby mode (spins down). However the first data transfer command will spin up the disk without the sd driver doing anything. I have a page summarizing power management in SCSI and ATA: http://sg.torque.net/sg/power.html ** I'm using the sat-r08.pdf draft as a reference here, not what libata's SATL does today. Doug Gilbert - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
