Bug 6264

Summary: hdd spindown during suspend / resume
Product: SCSI Drivers Reporter: Cyrill Helg (linux)
Component: OtherAssignee: scsi_drivers-other
Status: CLOSED INVALID    
Severity: low CC: akpm, axboe, pavel, rjwysocki
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.16 Subsystem:
Regression: --- Bisected commit-id:
Attachments: Kernel Config -git6

Description Cyrill Helg 2006-03-21 06:56:38 UTC
Most recent kernel where this bug did not occur: 2.6.15.[1]
Distribution: gentoo
Hardware Environment:
00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev
03) (prog-if 80 [Master])
        Subsystem: IBM Unknown device 056a
        Flags: bus master, 66MHz, medium devsel, latency 0
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at 18c0 [size=16]
        Capabilities: [70] Power Management version 2

Steps to reproduce:

Call a suspend and listen to the harddrive ;)

A bad side effect of the spindown at nearly the end of the suspend process is
that it takes just time.

I found out the problem with using suspend2 patched sources, but then also tried
with vanilla kernel and the problem is also there. Nigel thinks that it could
have to do with this git merge. I'm not sure.
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9b847548663ef1039dd49f0eb4463d001e596bc3
Comment 1 Andrew Morton 2006-03-21 14:49:04 UTC
It's unclear what actual "bug" you're reporting.  What behaviour do you
think is wrong?  What is the kernel doing that you think it shouldn't be
doing?


Comment 2 Cyrill Helg 2006-03-21 15:00:15 UTC
In my (and others reporting same problem on suspend2 mailing list) opinion the
hd should not spindown while saving the caches to disk because a) it delays the
whole suspending process and b) it just makes no sense and is probably also not
good for the harddrive...

Another point is that this didn't happen with older kernels, so why is it necessary?

Thanks for your effort!
Comment 3 Andrew Morton 2006-03-21 16:15:17 UTC
I'm still trying to work out what the bug is.

It appears that the hard disk is spinning down at some stage in the suspend-to-disk
process.  Is that correct?

If so, at which stage is it spinning down and at what stage does it spin back
up?

Please try to describe the problem more clearly.

Comment 4 Cyrill Helg 2006-03-21 16:29:08 UTC
I'm sorry for the first chaotic description and I'll try the best.

Yes you're right the hdd spins down during suspend process and also when
resuming. (after poweroff->on)

It's not easy to say when this happens. With suspend 2 it's right after "saving
caches" and before "Writing kernel & process data". 
And then spindown is the same as when the hdd goes into suspend mode i.e. for
powersaving, but it wakes up immediately after it's turned out. So it goes down
and up again and the last bits of suspending data gets written and then system
turns off.

Resuming: There it happens when the kernel recognizes that there is a resume
image available. So it dectects, spins down und up and reads the caches...

What options could I turn on to report that problem more clearly? Or shall I try
to revert some sata related patches, because one of them caused that problem.
Comment 5 Andrew Morton 2006-03-21 17:05:55 UTC
That's sufficient, thanks.

Pavel, Rafael: over to you ;)
Comment 6 Pavel Machek 2006-03-22 00:43:44 UTC
Searching "which sata patch does it" would certainly be useful.
Comment 7 Rafael J. Wysocki 2006-04-10 05:42:44 UTC
Also, could you please post your .config?
Comment 8 Cyrill Helg 2006-04-10 08:08:20 UTC
I'm bot 100% sure,but it looks like this is solved in 2.6.16-git6...
Comment 9 Cyrill Helg 2006-04-10 08:09:16 UTC
Created attachment 7832 [details]
Kernel Config -git6
Comment 10 Rafael J. Wysocki 2006-04-10 10:02:41 UTC
Thanks for the config.  It looks like the problem may be related to the PIIX 
driver indeed.

If you think it might have been fixed early after 2.6.16, could you please test 
2.6.17-rc1 or a recent -git?
Comment 11 Cyrill Helg 2006-04-10 12:58:21 UTC
I will try it out as soon as an updated beyond patchset from Tiger is out. 
Comment 12 Cyrill Helg 2006-04-13 00:57:47 UTC
As far as I can say this is fixed in: currently 2.6.16.4 + the pata patch from
alan ( http://zeniv.linux.org.uk/~alan/IDE/patch-2.6.16-ide1.gz )

Thanks!
Comment 13 Cyrill Helg 2006-05-01 22:56:29 UTC
Interestingly the bug seems to be here again on kernel 2.6.11 or .12. I'm not
sure because I'm using the beyond sources patchset from here:
http://iphitus.loudas.com/beyond.html

The upgrade from 2.6.16-beyond2 to beyond3 brings the problem back.
Comment 14 Anonymous Emailer 2006-05-02 02:37:02 UTC
Reply-To: pavel@ucw.cz


> Interestingly the bug seems to be here again on kernel 2.6.11 or .12. I'm not
> sure because I'm using the beyond sources patchset from here:
> http://iphitus.loudas.com/beyond.html
> 
> The upgrade from 2.6.16-beyond2 to beyond3 brings the problem back.

-beyond2  contains so many changes it is not funny, including suspend2
support. Try again with vanilla.
								Pavel
Comment 15 Pavel Machek 2006-05-19 03:00:41 UTC
Is problem still present in vanilla 2.6.17-rc4? If so, please reopen.
Comment 16 Cyrill Helg 2006-07-20 11:51:32 UTC
No the problem does not exist anymore. Thanks!