Red Hat Bugzilla – Bug 486118
Toshiba M9 Laptop crashes when lid is closed on Fedora 10
Last modified: 2009-06-10 12:39:30 EDT
Description of problem: Toshiba Tecra M9 PTM91E crashes when laptop lid is closed. This happens with every kernel version installed so far. I have set power management to do nothing when the lid is closed but this does not fix it. Shutting down acpid does nothing. When the lid is closed the system becomes completely non-responsive; control-alt-f[2..8] doesn't work, neither does control-alt-esc or control-alt-del. The only solution is to shut down and restart using the power button. Version-Release number of selected component (if applicable): this has happened on Fedora 10 kernels: 2.6.27.7-134.fc10.x86_64, 2.6.27.9-159.fc10.x86_64, 2.6.27.12-170.2.5.fc10.x86_64 How reproducible: every time. Sometimes the screen blanks, sometimes the pointer remains on a black screen, sometimes the background is still visible, but in each case it's just as dead. Steps to Reproduce: 1. close lid 2. open lid with trepidation 3. cry Actual results: Expected results: Additional info:
This has been assigned to the wrong component, ACPI does not support ACPI suspending, only displays information about ACPI devices. If you are running Gnome this should be assigned to gnome-power-manager, if running KDE it should be assigned to guidance-power-manager.
Have you tried using http://people.freedesktop.org/~hughsient/quirk/ ?
(In reply to comment #2) > Have you tried using http://people.freedesktop.org/~hughsient/quirk/ ? I ran quirk-checker.sh and it said I have no quirks. This crash happens even if I set power manager to do nothing when the lid is closed. I can hibernate to disk fine which is enough for me. S3 standby can wait, I'd rather fix the lid closing problem first.
This is a problem with the nvidia driver and is fixed by changing the cursor to software mode: in /etc/X11/xorg.conf Section "Device" add: Options "HWCursor" "false" This bug is being worked on as part of 501781 so this one should be closed as the problem is not part of gnome-power-manager *** This bug has been marked as a duplicate of bug 501781 ***