Bug 9275 - Suspend to RAM resume hangs on a tickless (NO_HZ) kernel
Suspend to RAM resume hangs on a tickless (NO_HZ) kernel
Status: CLOSED CODE_FIX
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend
All Linux
: P1 normal
Assigned To: Rafael J. Wysocki
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2007-11-01 14:43 UTC by Almonas Petrasevicius
Modified: 2008-04-28 15:52 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.23
Tree: Mainline
Regression: ---


Attachments
Config with NO_HZ set (63.79 KB, text/plain)
2007-11-14 15:45 UTC, Almonas Petrasevicius
Details
Kernel log w/o no_hz option (suspends and resumes just fine) (82.13 KB, text/plain)
2007-11-14 15:47 UTC, Almonas Petrasevicius
Details
Kernel log with no_hz option (suspends but not resumes) (101.38 KB, application/octet-stream)
2007-11-14 15:48 UTC, Almonas Petrasevicius
Details
Kernel log with no_hz and hpet=disable boot option (74.16 KB, application/octet-stream)
2007-11-18 09:51 UTC, Almonas Petrasevicius
Details
Kernel log with no_hz and compiled without hpet support (irq balancing too, but I think it is irrelevant) (99.63 KB, text/plain)
2007-11-18 09:53 UTC, Almonas Petrasevicius
Details
Ubuntu kernel 2.6.22-14 log with no_hz and hpet=disable boot option (53.38 KB, text/plain)
2007-11-18 11:17 UTC, Almonas Petrasevicius
Details
Kernel v2.6.24rc3 log with no_hz and hpet (39.38 KB, text/plain)
2007-11-26 07:48 UTC, Almonas Petrasevicius
Details
Kernel v2.6.24rc3 log with no_hz and hpet (39.38 KB, text/plain)
2007-11-26 07:52 UTC, Almonas Petrasevicius
Details
kernel log - NO_HZ enabled (65.07 KB, text/plain)
2008-04-28 15:50 UTC, Matej Dubovy
Details
kernel log for suspend/resume with hpet=disable (65.93 KB, text/plain)
2008-04-28 15:52 UTC, Matej Dubovy
Details

Description Almonas Petrasevicius 2007-11-01 14:43:54 UTC
Most recent kernel where this bug did not occur:
unknown

Distribution:
Ubuntu 7.10

Hardware Environment:
HP nc6320 T2400 945GM

Problem Description:
notebook hangs on resume after suspend to RAM with tickless (NO_HZ) kernel. This happens both with stock ubuntu 7.10 kernel 2.6.22-14 and with a self compiled vanilla 2.6.23 kernel. It looks like the kernel hangs in a pretty early stage of resume, fan does not even spin down after initial power on spin-up, there is no HDD activity, network interface is dead.

Otherwise, notebook resumes just fine with exactly the same kernel configuration w/o NO_HZ config option.
Comment 1 Thomas Gleixner 2007-11-13 06:34:14 UTC
Can you trick the box into booting when you hit keys on the keyboard or is it completely dead ?

Can you please provide your .config and a bootlog of 2.6.23 ?

Thanks,
      tglx
Comment 2 Almonas Petrasevicius 2007-11-14 15:45:39 UTC
Created attachment 13550 [details]
Config with NO_HZ set
Comment 3 Almonas Petrasevicius 2007-11-14 15:47:40 UTC
Created attachment 13551 [details]
Kernel log w/o no_hz option (suspends and resumes just fine)
Comment 4 Almonas Petrasevicius 2007-11-14 15:48:35 UTC
Created attachment 13552 [details]
Kernel log with no_hz option (suspends but not resumes)
Comment 5 Almonas Petrasevicius 2007-11-14 16:04:59 UTC
The box is completely dead, key presses don't do anything.

I have attached two kernel logs: one without NO_HZ and another compiled with exactly the same parameters, just with NO_HZ option defined.

As far as I can see, the NO_HZ kernel does not even suspend properly, the log ends at
"Nov 15 00:02:49 notebook kernel: [12863.511592] PM: Preparing system for mem sleep"
and that's all. But the notebook still enters the STR.
The following line (kernel 2.6.22-14) comes already after power cycle. 

The second log shows successful suspends with kernel 2.6.23 without no_hz option. 
Comment 6 Thomas Gleixner 2007-11-14 16:37:59 UTC
Almonas,

thanks for providing the data.

Can you please add "hpet=disable" to the kernel command line

Thanks,

     tglx
Comment 7 Almonas Petrasevicius 2007-11-15 22:24:05 UTC
Yes, this definitely helps.
Without HPET timer notebook suspends and resumes just fine, even with NO_HZ option.
Is it something already known, or I could somehow help further debugging?
Comment 8 Thomas Gleixner 2007-11-16 15:10:15 UTC
Can you please provide the dmesg output of a boot with hpet=disable on the command line ?

Thanks,

    tglx
Comment 9 Almonas Petrasevicius 2007-11-18 09:51:47 UTC
Created attachment 13599 [details]
Kernel log with no_hz and hpet=disable boot option
Comment 10 Almonas Petrasevicius 2007-11-18 09:53:03 UTC
Created attachment 13600 [details]
Kernel log with no_hz and compiled without hpet support (irq balancing too, but I think it is irrelevant)
Comment 11 Almonas Petrasevicius 2007-11-18 10:02:36 UTC
The second log has actually two suspend-resume cycles.
On the last cycle (where the log ends) notebook resumed, but did not switched back to the graphical mode. Changing VT's did not help, the console #7 remained in text mode. Which I have never seen with an earlier kernel versions. It could be just a random failure, I am unable to reproduce it anymore.
Comment 12 Almonas Petrasevicius 2007-11-18 11:17:43 UTC
Created attachment 13602 [details]
Ubuntu kernel 2.6.22-14 log with no_hz and hpet=disable boot option

I have also tried the "stock" Ubuntu kernel v2.6.22-14 with an hpet=disable boot option.
Unlike the self compiled "vanilla" kernel v2.6.23 this kernel does not resume even with an hpet=disable. The log ends here, but I think it is just missing the last lines. It seems like syslog buffers are not properly sync'ed before suspending.
Comment 13 Thomas Gleixner 2007-11-18 12:46:19 UTC
Hmm, strange. Does 2.6.24-rc3 show the same problem ?
Comment 14 Almonas Petrasevicius 2007-11-20 10:03:58 UTC
No, the 2.6.24-rc3 suspends and resumes just fine (with no_hz and without hpet compiled in).
Comment 15 Thomas Gleixner 2007-11-20 14:38:51 UTC
What happens when you add hpet ?
Comment 16 Almonas Petrasevicius 2007-11-26 07:48:55 UTC
Created attachment 13760 [details]
Kernel v2.6.24rc3 log with no_hz and hpet

2.6.24-rc3 suspends and resumes just fine even with both no_hz and hpet enabled.
Comment 17 Almonas Petrasevicius 2007-11-26 07:52:20 UTC
Created attachment 13761 [details]
Kernel v2.6.24rc3 log with no_hz and hpet

2.6.24-rc3 suspends and resumes just fine even with both no_hz and hpet enabled.
Comment 18 Sergey Smirnov 2007-11-26 23:03:33 UTC
2.6.24-rc3 on ARM doesn't resume with hpet=disable and no_hz=disable.
Comment 19 Rafael J. Wysocki 2007-11-27 07:06:32 UTC
(In reply to comment #18)
> 2.6.24-rc3 on ARM doesn't resume with hpet=disable and no_hz=disable.

Can you open a separate bug for that, please?
Comment 20 Sergey Smirnov 2007-11-27 23:59:38 UTC
>> 2.6.24-rc3 on ARM doesn't resume with hpet=disable and no_hz=disable.

>Can you open a separate bug for that, please?

Sorry. PDA with 2.6.24-rc3 or 2.6.23 hangs only if it charge while suspend.
I've open bug #9394.
Comment 21 Rafael J. Wysocki 2007-12-12 16:25:05 UTC
Well, since Almonas has confirmed that 2.6.24-rc3 suspends and resumes correctly, I think we can consider the problem as resolved.

I'm closing this bug, please reopen if necessary.
Comment 22 Matej Dubovy 2008-04-28 15:47:43 UTC
Hello,
the same problem still occur on laptop HP nx6310, T1300 (single CPU), 945GM, bios version F.0D
Notebook hangs on resume even with new vanilla kernel 2.6.25.

With NO_HZ =off option it resumes fine.

In fact, with enabled NO_HZ option, it does not fully hang on, but after approx 5 min, it resumes and continue to working.
Also, when I tried to force unload acpi module 'processor' (& thermal & acpi_cpufreq) before suspend, it resumes fine. (but functionality of thermal module loaded after resume not work).

When I used hpet=disable option it resumes after approx 30-60 min.

Could you please reopen this bug or I have to open another one?
Comment 23 Matej Dubovy 2008-04-28 15:50:31 UTC
Created attachment 15962 [details]
kernel log - NO_HZ enabled
Comment 24 Matej Dubovy 2008-04-28 15:52:01 UTC
Created attachment 15963 [details]
kernel log for suspend/resume with hpet=disable

Note You need to log in before you can comment on or make changes to this bug.