Laptop going into kernel panic when it sleeps.

Hi,
I am having a strange problem with an Asus s200e and opensuse 13.1 64bit.
Sometimes when I resume the laptop from sleep on battery power I get a screen full of text and it says kernal panic watchdog detected hard lockup on cpu1.
The only thing I can do is hold the power button till it turns off.
Please help.
Thanks in advance.:frowning:

Anybody there?

I have a similar issue with a Lenovo P580 and was going to post when I saw yours, so I’m lurking in hopes you get a response.

It could a problem with the nouveau driver.

Can you please post the results of:

cat /proc/cpuinfo

Interesting formation about the kernel’s hard lockups and soft lockups pulled from the kernelnewbies website’s email archive.

**What are the Differences between CPU Hard-lockup and Soft-lockup
**
When the watchdog is enabled, there is a HW timer that counts down. If the HW timer reaches 0, then it asserts (triggers an NMI or processor RESET).
Normally, the watchdog has something like a 30 second timeout, and there is a watchdog thread which runs with a low real-time priority.
So that places it at a higher priority than all of the normal threads.

The watchdog normally kicks (resets) the timer once per second. When the timer reaches zero, then the hardlockup has considered to occur.
On some architectures, this will cause an NMI (non-maskable interrupt) to fire.
On architectures which don’t support NMI, a reset will occur (in the reset case you get no reporting of hard lockup - the processor just reboots).

**If the watchdog timer interrupt is running, but the watchdog thread is not running for some period of time, then this is considered a soft lockup.
Because the watchdog timer interrupt is running, we know that interrupts are enabled.

The fact that the watchdog thread is not running means either that context switching has been disabled, or some interrupt or higher priority
real-time thread is consuming 100% of the CPU.
**
One common reason for hard-lockup is to disable interrupts and not reenable them.
One common reason for soft lockup is when interrupts fire continuously (typically happens when writing a new drive and you forgot to deal with a particular interrupt source).

:~ # cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
stepping        : 9
microcode       : 0x19
cpu MHz         : 1856.000
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 5786.97
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
stepping        : 9
microcode       : 0x19
cpu MHz         : 1711.000
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 5786.97
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
stepping        : 9
microcode       : 0x19
cpu MHz         : 1653.000
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 5786.97
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
stepping        : 9
microcode       : 0x19
cpu MHz         : 1885.000
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips        : 5786.97
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

In my case the panic occurs whenever the lid is closed with settings for either “sleep” or “hibernate”, with line power & with battery.

Here is a screenshot taken upon opening the lid.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Pentium(R) CPU 987 @ 1.50GHz
stepping        : 7
microcode       : 0x28
cpu MHz         : 1140.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm
bogomips        : 2993.06
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Pentium(R) CPU 987 @ 1.50GHz
stepping        : 7
microcode       : 0x28
cpu MHz         : 1140.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 1                                                                                                                                                     
cpu cores       : 2                                                                                                                                                     
apicid          : 2                                                                                                                                                     
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dtherm
bogomips        : 2993.06
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

On 2013-12-24 19:46, Romanator wrote:
>
> Interesting formation about the kernel’s hard lockups and soft lockups
> pulled from the ‘kernelnewbies’ (http://tinyurl.com/mkyrchh) website’s
> email archive.
>
> *What are the Differences between CPU Hard-lockup and Soft-lockup
> *

Interesting feature.

There is also a hardware watchdog, implemented on a PCI card or some other hardware chip. When that
hardware is activated, a process has to do something to the card every while. After a certain time
of no activity from the cpu, the chip or card pulls the hardware reset line of the motherboard,
forcing a real hardware reboot. No messages, unless the watchdog keeps a log of its own.

It is used on standalone or remote computers, where keeping the machine running is vital.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))

I’ve always been fascinated how the kernel interrupts interact with the hardware. The kernelnewbies website has a lot of info.

@ozzyofpi

Please check Configure Desktop:
System Settings -> Power Management -> Energy Saving->check the tabs “On AC Power”, “On Battery”, “On Low Battery” for the following settings:

    • “Button events handling” checked
    • “When laptop lid closed” -> “Sleep”

Also, for “Input Devices” try changing the keyboard to Asus laptop.

Can you replicate this every time or more than once in a row.? If you can I would submit a bug report with Bugzilla.
Check .xsession-errors for more info.

@capris

I would submit a kernel bug report as it could be an issue with the drm/kms driver with Bugzilla so that the team can resolve this with an update.
Your screenshot should be uploaded to Bugzilla with your bug report.

Looks like this problem is with the 3.11 and possibly the 3.12 kernels.

Follow Up

What are the settings in /etc/systemd/logind.conf ?

Information pulled from the man logind.conf

HandlePowerKey=, HandleSuspendKey=, HandleHibernateKey=, HandleLidSwitch=

Controls whether logind shall handle the system power and sleep keys and the lid switch to trigger actions such as system power-off or suspend. Can be one of “ignore”,
“poweroff”, “reboot”, “halt”, “kexec”, “suspend”, “hibernate”, “hybrid-sleep” and “lock”.

If “ignore”, logind will never handle these keys. If “lock”, all running sessions will be screen-locked; otherwise, the specified action will be taken in the respective event.
Only input devices with the “power-switch” udev tag will be watched for key/lid switch events.
HandlePowerKey= defaults to “poweroff”
HandleSuspendKey= and HandleLidSwitch= default to “suspend”
HandleHibernateKey= defaults to “hibernate”

Note that these are the default settings in the file logind.conf:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# See logind.conf(5) for details

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min

Do you mean to change the power settings or just check what they are.
I dont really know how to submit a bugzilla report as I’m a bit of a noob.
I can’t replicate it every time.
Thanks.

Yes. I would check the settings to see if you are using the settings that I’ve provided in the previous comment.
If you can’t replicate it every time than we will try to resolve this with some alternate settings.

Yeah, I do have those settings.

I have a somewhat similar experience with an Acer Aspire I bought a week, or so, ago. Auto-sleep activation on lid close, or with in-activity, worked fine until yesterday when mine also began to freeze, now it will not revoke from sleep. I haven’t really investigated anything yet but the thing I changed before this happened was to install the proprietary ATI driver for the GPU, so I rather presumed it had something to do with that, I don’t know. But I at least suspect that the ATI driver (proprietary) still has some issues left, I noted a couple of other things which seemed to occur with its installation: scrambled screen at the boot-up sequence, possible random hangs with the desktop (KDE menu), video playback etc; having only had this laptop for a week, though, I can’t really be sure of too much yet.

I will deinstall the proprietary driver and go back to the open-source one and see how that turns out. By the way, the open-source driver, whatever was used r200/300?, worked very well as long as I used it, though I expect it won’t with some more demanding games or similar …

openSUSE 13.1, KDE 4.11.3, Acer Aspire E1-572G, Intel i5, AMD Radeon HD 8750M.

Here are the setting in /etc/systemd/logind.conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# See logind.conf(5) for details

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min

Okay. You and I are using the default settings. The default setting for the lid close is for the laptop to use the “suspend” mode.

I would try a updating your kernel from 3.11x to kernel 3.12x. Add the repository below to Yast. Update your kernel-desktop, kernel source, kernel-devel and kernel-sys.

Index of /repositories/Kernel:/stable/standard

After updating the kernel, restart your laptop and test out the newer kernel.

Just updated. Preliminary test indicates problem solved.

:~> uname -a
Linux p580.cutbeach 3.12.6-1.g080d0df-desktop #1 SMP PREEMPT Tue Dec 24 10:38:59 UTC 2013 (080d0df) x86_64 x86_64 x86_64 GNU/Linux