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

[Nigel Cunningham]

On Wed, 2006-09-27 at 22:39 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 27 Sep 2006, Nigel Cunningham wrote:
> > > > 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.
> 
> It is so easy, it made me cry in happiness:
> 	#include <linux/kernel.h>
> 
> 	if (system_state == SYSTEM_RESTART) {
> 		/* it is a reboot */
> 	}
> 
> > > 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.
> 
> No drivers seem to check system_state for SYSTEM_SUSPEND_DISK.  Looks like
> something that needs a fix.

My understanding, which may be wrong, is that drivers shouldn't be
looking at system_state. They should be passed a parameter telling them
what to do, and should listen to it. I think the problem is that
kernel_restart_prepare is calling device_shutdown at all. It should be
calling some sort of device function to ensure data is flushed, but I'm
not sure device_shutdown is the right function.

> The fix I need for scsi_bus_shutdown is MUCH easier, since SYSTEM_RESTART is
> always a reason to NOT spin down.  For SYSTEM_SUSPEND_DISK, I don't know (I
> didn't study the kernel/power/disk.c code).
> 
> > > > 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
> 
> I had also silent corruption that ended up with ext3 doing very bad things
> and hanging (no in-disk filesystem corruption though) even with
> suspend-to-RAM (S3) in 2.6.17+suspend2.  So it may be older than 2.2.7,
> and/or the mainline change that broke it might have been from 2.6.16 to
> 2.6.17.
> 
> At least now the kernel is screaming blood murder, so it is not silent
> anymore.

With 2.6.17? I've seen issues with 2.6.18 reported, but not .17. Perhaps
there is a particular driver that causing you problems there.

Regards,

Nigel