[Suspend2-devel] Re: [ltp] [PATCH] 2.6.17: Unload disks heads before powering down

[Nigel Cunningham]

Hi.

On Tue, 2006-09-26 at 16:25 +0300, Shem Multinymous wrote:
> Hi,
> 
> I'm adding suspend2-devel to the CC, since this issue probably affects
> all suspend2+libata users.
> 
> On 9/26/06, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> > On Tue, 26 Sep 2006, Shem Multinymous wrote:
> > > On my box with ata_piix, the kernel is *spinning down* the
> > > disks during shutddown.
> 
> Ah, found it: drivers/ata/libata-eh.c/ata_eh_suspend() does
> 
> 	if (dev->class == ATA_DEV_ATA && !(action & ATA_EH_PM_FREEZE)) {
> 		...
> 		/* spin down */
> 		err_mask = ata_do_simple_cmd(dev, ATA_CMD_STANDBYNOW1);
> 
> 
> > The EH suspend subroutine does a STANDBY IMMEDIATE command, and that flushes
> > caches and spins down the disk, which IS the right thing to do on a system
> > shutdown, but quite less so for a system reset.
> 
> Any real drawback to doing an UNLOAD IMMEDIATE instead of STANDBY IMMEDIATE?
> 
> 
> > Now, teaching the kernel how to differentiate a "regular" scsi bus shutdown,
> > from a "will reboot/kexec" scsi bus shutdown is something I have absolutely
> > NO CLUE on how to go about doing properly.
> 
> Neither do I.
> 
> 
> > > Any idea where that comes from, and how it relates to the SuSE head
> > > unload patch?
> 
> 
> > If you shutdown the scsi bus, the unload patch will spin down the disk.
> 
> I'm getting a spindown on reboot (i.e., shutdown) even without the SuSE patch.
> 
> 
> > And if you suspend the scsi bus, the regular kernel code will
> > spin down the disk as well (at least it should).  And if you
> > are going to use the disk to write a image there, what the
> > hell are you doing suspending or shutting it down?
> 
> My understandin is that Suspend2 suspends all devices, scsi bus
> included, in order to get a consistent snapshot; it then resumes the
> necessary devices in order to write the snapshot to disk. Currently
> this causes a disk spin-down and spin-up, which is bad for the disk
> and bad for suspend time.

Suspend2 makes the same driver calls (or should if it doesn't). I'd
expect that any issue like this with Suspend2 would also apply to
swsusp. If that's not true, please let me know and I'll fix that.

> > I suspect the "so don't do it" finale for this thought is only
> > possible with 2.6.18,
> 
> What changed here in 2.6.18?
> I've tested with vanilla 2.6.18, with 2.6.17.4+suspend2-2.2.7.1 and
> with 2.6.17.13+suspend2-2.2.7.6.
> 
> 
> > Suspend2 2.2.8 + kernel 2.6.18 is corrupting the page cache here, do *not*
> > use it if you value your data.
> 
> Does it?! During suspend, you mean? I was just about to test that...

Works fine for me, but I have had some reports of that. I've only tested
amd64 so far, and am just about to see if I can reproduce it on x86. I
suspect there's some change in the vanilla kernel, because I haven't
touched anything between 2.2.7.6 and 2.2.8 that would cause this.

Regards,

Nigel