|
Bugzilla – Full Text Bug Listing |
| Summary: | Regression: Suspend to disk freezes on HP 6715b after kernel update | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Matthias Hopf <mhopf> |
| Component: | Kernel | Assignee: | Pavel Machek <pavel> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | openSUSE 10.3 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Matthias Hopf
2008-03-20 13:00:17 UTC
The 'container' module wasn't unloadable in 2.6.22.5-31.0, so I renamed it. I unloaded as many modules as possible, on both kernels, finally stripped down to: Module Size Used by sd_mod 31104 6 usbcore 123372 1 ext3 131848 4 mbcache 12292 1 ext3 jbd 68148 1 ext3 ahci 29188 5 libata 136776 1 ahci scsi_mod 140376 2 sd_mod,libata Same behavior as before. I have no freaking clue what else to do here. (In reply to comment #0 from Matthias Hopf) > I also tried the kernel method with echo disk >/sys/power/state, same effect, > there the last few lines state: > > Stopping tasks ... done > Shrinking memory... done (0 pages freed) > Freed 0 kbyte in 0.02 seconds (0.00 MB/s) > Suspending console(s) > <blinking cursor> ...now _if_ we were able to dynamically disable the console suspend code, _then_ you would probably see where it hangs. People had already written code to do that, you know... ;-) try no_console_suspend on kernel commandline. You should be able to get the old kernel somewhere, no? At the very least, you could pull kernel cvs, and do bisect there. sysrq-p might be useful. As might be nosmp test. As I wrote that sysrq works I forgot to mention that I don't see any output of it :-P I'll try no_console_suspend. 0% change with no_console_suspend. Building 20071109 (the closest kernel I could find to the last known working). First attempt failed due to not enough free space. I'm out of ideas except one. I tried the following kernels: 2.6.22.5-31, 2.6.22.12-0.1, 2.6.22.9-0.4, 2.6.22.17-0.1 All fail. 2.6.18.8-0.9 (from 10.2) doesn't boot any more. I don't know how this could ever work, and I'm almost assuming that I've been dreaming. I also cannot bisect ATM, because I don't have a single working version. I'm thinking whether this could be something else than kernel related, but I've been trying to suspend in runlevel 1 with no graphics involved, and the suspend package didn't have an update. The last thing I'll try is reinstalling 10.3 on a different partition. Then testing before and after software updates. A freshly installed 10.3 shows the same symptoms. But an updated 10.2 (kernel 2.6.18.8-0.9) suspends perfectly, both kernel space and user space level. With 10.3 I also tried noapic nmi_watchdog=0. No effect. I don't know whether I can bisect this (assuming that the effect on unpatched kernels is the same), as I cannot test the two kernels in the same installation system, and cross-platform testing might proof difficult. But I'll try. (In reply to comment #3 from Pavel Machek) > You should be able to get the old kernel somewhere, no? At the very least, you > could pull kernel cvs, and do bisect there. I hope you mean git? Kernel should be the only place what matters w.r.t. suspend-to-disk... at least if you use "echo disk > /sys/power/state" method. Useful options for 10.3 include "nohz=off highres=off"... If you want to proceed with bisect, verify problem is present vanilla 2.6.22, and absent in vanilla 2.6.18... (And you may to verify 2.6.25-rc7, too, perhaps it is fixed there? :-). Upstream 2.6.22 works fine. At least kernel-based suspend. Just verified with 2.6.22.17-0.1-vanilla. Both methods work fine. Stupid me, should have thought about that. Is there a standard approach for bisecting kernel patches in our kernel packages? I tried to build packages with only part of the patches applied, but that proved to be nontrivial. After some fiddeling with the specfile this works now. Matthias, i see similar things on my hp2510p (see bug 372676) with current STABLE / Factory x86_64: it works with kernel-vanilla, but not with kernel-default. Our kernel from stable (2.6.25-rc8.git7.13) seems to work fine. Pavel, if you don't think this will be fixed for 10.3, close this as WONTFIX. Remove Needinfo It should work in opensuse11, and it would be quite a lot of work to find out why it broke in 10.3... Agreed. As the new kernel works apparently w/o any regressions on 10.3, I'm happy as well :) |