[Bug 810133] New: System hangs when laptop lid is closed
https://bugzilla.novell.com/show_bug.cgi?id=810133 https://bugzilla.novell.com/show_bug.cgi?id=810133#c0 Summary: System hangs when laptop lid is closed Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: i686 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: devmail@hispeed.ch QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0 Running a fresh install of openSUSE 12.3, closing the laptop lid causes the machine to freeze (see section on actual results below). This happens even if I boot to runlevel 3 and close the lid when the login prompt appears, hence I think it's a low-level problem, not something caused by the desktop environment. Invoking pm-suspend on the command line causes the computer to fall asleep normally. I can then close the lid safely. When the lid is reopened, the computer wakes up and is fully functional. Similarly, invoking sleep manually using the Kicker menu also works well. So does configuring the power button to make the computer sleep and pressing it. The only way that doesn't work is to close the lid. Reproducible: Always Steps to Reproduce: 1. Boot into openSUSE 12.3. 2. Close the laptop lid. Actual Results: Screen backlight is not switched off when the lid is closed. If the lid is reopened, the computer remains frozen. The screen is blank (black), except for the mouse pointer, which doesn't move in response to using the trackpad. Keyboard is not responsive at all. Remote login sessions to the machine stop responding. The only way out of the hung state is to switch off the machine by holding down the power button. Expected Results: Laptop enters the sleep state, like when executing the pm-suspend command. This is a regression from 12.2. All other power-management related functionality that I can think of, such as hibernation, display brightness adjustment, etc., works flawlessly. The computer is a Dell Latitude D505. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=810133
https://bugzilla.novell.com/show_bug.cgi?id=810133#c1
--- Comment #1 from Olav Reinert
https://bugzilla.novell.com/show_bug.cgi?id=810133
https://bugzilla.novell.com/show_bug.cgi?id=810133#c3
Frederic Crozat
https://bugzilla.novell.com/show_bug.cgi?id=810133
https://bugzilla.novell.com/show_bug.cgi?id=810133#c
FeiXiang Zhang
https://bugzilla.novell.com/show_bug.cgi?id=810133
https://bugzilla.novell.com/show_bug.cgi?id=810133#c4
Wojtek Dziewięcki
https://bugzilla.novell.com/show_bug.cgi?id=810133
https://bugzilla.novell.com/show_bug.cgi?id=810133#c5
Olav Reinert
https://bugzilla.novell.com/show_bug.cgi?id=810133
https://bugzilla.novell.com/show_bug.cgi?id=810133#c6
--- Comment #6 from Olav Reinert
https://bugzilla.novell.com/show_bug.cgi?id=810133
https://bugzilla.novell.com/show_bug.cgi?id=810133#c
Wojtek Dziewięcki
https://bugzilla.novell.com/show_bug.cgi?id=810133
https://bugzilla.novell.com/show_bug.cgi?id=810133#c7
--- Comment #7 from Olav Reinert
https://bugzilla.novell.com/show_bug.cgi?id=810133
https://bugzilla.novell.com/show_bug.cgi?id=810133#c8
Wojtek Dziewięcki
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c22
Takashi Iwai
(In reply to Takashi Iwai from comment #14)
Instead of pm-suspend, could you try "systemctl suspend"? If this works, the code path via systemd should be OK.
"systemctl suspend" works fine. (Tested within GNOME desktop on Tumbleweed 20150612)
Furthermore, after suspending that way, and resuming, then closing the lid also works (similar to the behaviour described in comment #7). At least once, sometimes more - after a few successful suspend+resumes by lid close+open it crashes the same way as always.
It's still strange, though, that logind.conf doesn't give any behavior change. At least, the behavior with lid switch on Linux console (not X) should be managed by systemd-logind.
To be sure, could you check whether this is really properly tested, e.g. by changing it to "poweroff". Then now it should go to poweroff instead of suspend.
I edited logind.conf and set "HandleLidSwitch=poweroff", and rebooted straight to multi-user (runlevel 3) instead of the GNOME desktop. Upon closing the lid, the machine crashed the usual way.
Hm, so the event doesn't look handled at all by systemd.
After rebooting the same way, I retested "systemctl suspend", and it works. Then, after closing the lid, the computer powered off.
OK, then let's check how the lid event is dealt at all. Try to boot with nomodeset boot option. Then unload i915 module and unload button module. Now the kernel lid switch handling gets removed. At this state, try to close the lid. Does it happen anything? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c23
Olav Reinert
OK, then let's check how the lid event is dealt at all.
Try to boot with nomodeset boot option. Then unload i915 module and unload button module. Now the kernel lid switch handling gets removed.
At this state, try to close the lid. Does it happen anything?
When booting to runlevel 3, and after "rmmod i915 button", as instructed, the only visible effect of pressing the lid button is to switch off the display backlight, and it remains off after releasing the lid button. After that, pressing and releasing the lid button again has no effect, it seems. Also, the computer doesn't suspend, nor crash - pressing Ctrl+Alt+Del causes a normal reboot. The display only lights up again when the BIOS restarts the machine, showing the Dell logo. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c24
Takashi Iwai
(In reply to Takashi Iwai from comment #22)
OK, then let's check how the lid event is dealt at all.
Try to boot with nomodeset boot option. Then unload i915 module and unload button module. Now the kernel lid switch handling gets removed.
At this state, try to close the lid. Does it happen anything?
When booting to runlevel 3, and after "rmmod i915 button", as instructed, the only visible effect of pressing the lid button is to switch off the display backlight, and it remains off after releasing the lid button. After that, pressing and releasing the lid button again has no effect, it seems. Also, the computer doesn't suspend, nor crash - pressing Ctrl+Alt+Del causes a normal reboot. The display only lights up again when the BIOS restarts the machine, showing the Dell logo.
The light off behavior must be from BIOS, as now the kernel has no control at all. And, now try to rmmod only i915 module but keeping button module (and don't forget to boot with nomodeset option), and check the lid behavior again. Is it same behavior like the previous test? Or system reacts for the action you defined? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c25
Olav Reinert
The light off behavior must be from BIOS, as now the kernel has no control at all.
Agreed. I just mention it for info.
And, now try to rmmod only i915 module but keeping button module (and don't forget to boot with nomodeset option), and check the lid behavior again. Is it same behavior like the previous test? Or system reacts for the action you defined?
In this case, the system reacts according to the action defined in logind.conf. Multiple sleep/resume cycles works reliably. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c26
Takashi Iwai
And, now try to rmmod only i915 module but keeping button module (and don't forget to boot with nomodeset option), and check the lid behavior again. Is it same behavior like the previous test? Or system reacts for the action you defined?
In this case, the system reacts according to the action defined in logind.conf. Multiple sleep/resume cycles works reliably.
OK, then the problem is likely i915 driver. It locks up at some point, either suspend, resume or DPMS on/off. But, still it's strange that systemd setup didn't change the behavior. It should be irrelevant with i915 module itself. So, please double-check the following: - Boot with nomodeset option, keep i915 module but inactive. Does this follow lognd.conf setup? - Booth without nomodeset option, and check logind.conf setup again. At next, speaking of the hang: we need to catch up the point whether the hang happens. If it's an i915 driver problem, it's often just a GPU hang and the kernel itself is alive. If so, in many cases, you can still reach to the machine remotely via ssh, for example. Please check it, and get the kernel messages if possible. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c27
--- Comment #27 from Takashi Iwai
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c28
--- Comment #28 from Olav Reinert
OK, then the problem is likely i915 driver. It locks up at some point, either suspend, resume or DPMS on/off.
I agree it seems to be the i915 driver. However, to clarify, crashes have only occurred to me on lid close, not open. Whenever the machine has managed to enter suspended state (instead of crashing), it has always resumed correctly. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c29
Olav Reinert
So, please double-check the following: - Boot with nomodeset option, keep i915 module but inactive. Does this follow lognd.conf setup?
Booting with nomodeset into runlevel 3, the state of i915 is as follows: # lsmod|grep i915 i915 1040384 0 i2c_algo_bit 16384 1 i915 drm_kms_helper 114688 1 i915 drm 319488 2 i915,drm_kms_helper button 16384 1 i915 video 20480 1 i915 # I guess the "0" at the end of the line for i915 is what you mean by inactive? I ssh into the machine to watch the log, and when the lid is closed, I see the following messages (or variations thereof): Jul 02 18:57:17 linux-yu7r.site systemd-logind[789]: Lid closed. Jul 02 18:57:20 linux-yu7r.site systemd-logind[789]: Powering Off... Jul 02 18:57:20 linux-yu7r.site systemd-logind[789]: System is powering down. Connection to deller closed by remote host. Connection to deller closed. The system actually powers down correctly, according to my logind.conf settings. I've tested it several times, it's repeatable.
- Booth without nomodeset option, and check logind.conf setup again.
In this case, the i915 module is active, I think: # lsmod|grep i915 i915 1040384 1 i2c_algo_bit 16384 1 i915 drm_kms_helper 114688 1 i915 drm 319488 3 i915,drm_kms_helper button 16384 1 i915 video 20480 1 i915 # When I close the lid, the machine crashes immediately, and the ssh connection dies. This is repeatable.
From the same starting point, if instead of closing the lid I press the special "suspend" key, which I have also configured to poweroff in logind.conf, the machine shuts down normally:
Jul 02 19:16:00 linux-yu7r.site systemd-logind[791]: Suspend key pressed. Jul 02 19:16:00 linux-yu7r.site systemd-logind[791]: Powering Off... Jul 02 19:16:00 linux-yu7r.site systemd-logind[791]: System is powering down. Jul 02 19:16:00 linux-yu7r.site systemd[1]: Deactivating swap /dev/disk/by-uuid/5ca2e637-1083-4d22-a7cf-0c936f13285d... Jul 02 19:16:00 linux-yu7r.site systemd[1847]: Reached target Shutdown. Jul 02 19:16:00 linux-yu7r.site systemd[1847]: Starting Shutdown. Jul 02 19:16:00 linux-yu7r.site systemd[1847]: Stopped target Default. Jul 02 19:16:00 linux-yu7r.site systemd[1847]: Stopping Default. Jul 02 19:16:00 linux-yu7r.site systemd[1847]: Stopped target Basic System. Jul 02 19:16:00 linux-yu7r.site systemd[1847]: Stopping Basic System. Jul 02 19:16:00 linux-yu7r.site systemd[1847]: Stopped target Timers. Jul 02 19:16:00 linux-yu7r.site systemd[1847]: Stopping Timers. Jul 02 19:16:00 linux-yu7r.site systemd[1847]: Stopped target Sockets. Connection to deller closed by remote host. Connection to deller closed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c30
Takashi Iwai
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c31
--- Comment #31 from Olav Reinert
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c32
Olav Reinert
- Install the latest upstream kernel (4.1.x) from OBS Kernel:stable repo, and test with this kernel.
I'm unable to install the latest kernel from that repository - see attaced log of console output. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c33
--- Comment #33 from Olav Reinert
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c34
Takashi Iwai
(In reply to Takashi Iwai from comment #30)
- Install the latest upstream kernel (4.1.x) from OBS Kernel:stable repo, and test with this kernel.
I'm unable to install the latest kernel from that repository - see attaced log of console output.
You installed a wrong kernel package. kernel-xxx-base is the kernel package containing the minimal number of modules that are needed only for VM. Install kernel-default.rpm instead. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c35
Olav Reinert
(In reply to Olav Reinert from comment #32)
(In reply to Takashi Iwai from comment #30)
- Install the latest upstream kernel (4.1.x) from OBS Kernel:stable repo, and test with this kernel.
I'm unable to install the latest kernel from that repository - see attaced log of console output.
You installed a wrong kernel package. kernel-xxx-base is the kernel package containing the minimal number of modules that are needed only for VM. Install kernel-default.rpm instead.
Installing kernel-default from OBS Kernel:stable produced the same error as before, but it still results in a bootable system...?... Anyway, kernel 4.1.1 also crashes when I close the lid, just like before. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c46
--- Comment #46 from Olav Reinert
You likely need a bit more memory to assign. Try 128M, for example. I needed even more on my machine. Then check the output of "systemctl status kdump". If the status is OK (successfully loaded), then kdump should be able to be triggered in general.
You're right about the memory - assigning 256M makes the kdump service start successfully, as I have verified by "systemctl status kdump". Other than the memory setting, the default settings selected by "yast2 kdump" are used. Nevertheless, when I crash the kernel with "echo c >/proc/sysrq-trigger", it doesn't produce a kernel dump. All I see is the standard stack trace, register dump, etc. I have tested this on both Tumbleweed 20151124 and a fully updated 13.2, with exactly the same behaviour in both cases. No dump ever appears in /var/crash. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c47
--- Comment #47 from Takashi Iwai
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c48
--- Comment #48 from Olav Reinert
http://bugzilla.novell.com/show_bug.cgi?id=810133
http://bugzilla.novell.com/show_bug.cgi?id=810133#c49
--- Comment #49 from Olav Reinert
participants (1)
-
bugzilla_noreply@novell.com