Mark Lord wrote: > Chuck Ebbert wrote: >> Mark Lord wrote: >>> I'll patch it locally on my own machines, but what about the tens >>> of thousands of other Seagate notebook drive owners out there? >>> >> >> This is a problem with Seagate specifically, spinning back up >> on receipt of some command after spindown? > > No, they just seem to be affected worse by it than some other brands. > The bug is that libata/SCSI now spin-down the drive before the distro's > scripts are done with it, so it spins down, and then gets spun up again > by the distro, and then spun down again by the distro. > > And along the way, one/both of the two causes a full mechanism "park", > which is hard on things if abused (like this). > > Or at least that's what I recall for it. Tejun? This really isn't a regression. It's been always like that with libata. libata doesn't make devices go into standby mode and shutdown(8) does it for libata. The problem here is that libata does issue SYNCHRONIZE_CACHE on shutdown. So, the sequence of event is... 1. shutdown(8) issues SYNCHRONIZE_CACHE followed by STANDBY_NOW 2. kernel shutdown starts 3. libata shutdown issues SYNCHRONIZE_CACHE 4. power goes off Some drives seem to spin up at step #3 even when its cache is clean and power goes off right after the disk finishes the command. So, it's really bad when it happens - spin down, spin up followed by immediate power off. SCSI part of the fix is queued in scsi-misc-2.6 tree and libata-dev part is acked and waiting to be merged, so the fix will be available in 2.6.22. However, it's disabled by default to remain compatible with the current behavior and requires userland change to fully fix the problem. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
