Bug 6264
| Summary: | hdd spindown during suspend / resume | ||
|---|---|---|---|
| Product: | SCSI Drivers | Reporter: | Cyrill Helg (linux) |
| Component: | Other | Assignee: | 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 | ||
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? 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! 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. 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. That's sufficient, thanks. Pavel, Rafael: over to you ;) Searching "which sata patch does it" would certainly be useful. Also, could you please post your .config? I'm bot 100% sure,but it looks like this is solved in 2.6.16-git6... Created attachment 7832 [details]
Kernel Config -git6
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? I will try it out as soon as an updated beyond patchset from Tiger is out. 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! 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. 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 Is problem still present in vanilla 2.6.17-rc4? If so, please reopen. No the problem does not exist anymore. Thanks! |
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