Bug 501781 - X crashes when lid is closed or power state changes
X crashes when lid is closed or power state changes
Status: CLOSED DUPLICATE of bug 484738
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nv (Show other bugs)
10
x86_64 Linux
low Severity urgent
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
:
: 486118 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-20 13:10 EDT by Greg Dolph
Modified: 2009-06-10 12:39 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-26 07:56:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xorg.conf (633 bytes, text/plain)
2009-05-21 10:14 EDT, Greg Dolph
no flags Details
xorg log file (98.87 KB, text/plain)
2009-05-21 10:28 EDT, Greg Dolph
no flags Details
dmesg (36.18 KB, text/plain)
2009-05-21 10:30 EDT, Greg Dolph
no flags Details
xorg.conf (611 bytes, text/plain)
2009-05-21 10:31 EDT, Greg Dolph
no flags Details

  None (edit)
Description Greg Dolph 2009-05-20 13:10:59 EDT
escription of problem:
Toshiba Tecra M9 PTM91E crashes when laptop lid is closed or the power state
changes. This happens with every kernel version installed so far, and all
upgrades. 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
or I plug or unplug the external power the system becomes completely
non-responsive; control-alt-f[1..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, 2.6.27.21-170.2.56.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, plug or unplug external power

Actual results:


Expected results:


Additional info:

I've set gnome power manager to do nothing when the lid is closed, and I've set it so that the backlight is the same no matter the power state, but neither of these help
Comment 1 Greg Dolph 2009-05-21 10:14:34 EDT
Created attachment 344965 [details]
xorg.conf

as requested. I have tried running with no xorg.conf file but it made no difference.
Comment 2 Greg Dolph 2009-05-21 10:28:42 EDT
Created attachment 344967 [details]
xorg log file
Comment 3 Greg Dolph 2009-05-21 10:30:16 EDT
Created attachment 344968 [details]
dmesg
Comment 4 Greg Dolph 2009-05-21 10:31:26 EDT
Created attachment 344969 [details]
xorg.conf

I have run without an xorg.conf file and it still crashes
Comment 5 Matěj Cepl 2009-05-23 20:02:38 EDT
Yeah, lovely:

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e7c96]
1: /usr/bin/Xorg(mieqEnqueue+0x291) [0x4c87d1]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc4) [0x4914c4]
3: /usr/bin/Xorg(xf86PostMotionEvent+0xa9) [0x491699]
4: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7ff0f56d8472]
5: /usr/bin/Xorg [0x47a795]
6: /usr/bin/Xorg [0x46b337]
7: /lib64/libc.so.6 [0x3f51e32f90]
8: /usr/lib64/xorg/modules/drivers//nv_drv.so(G80DispCommand+0x50) [0x7ff0ff5cdcc0]
9: /usr/lib64/xorg/modules/drivers//nv_drv.so [0x7ff0ff5ce38d]
10: /usr/bin/Xorg(xf86_hide_cursors+0x7f) [0x4a4f5f]
11: /usr/bin/Xorg(xf86SetCursor+0x15b) [0x4ad0fb]
12: /usr/bin/Xorg [0x4ac616]
13: /usr/bin/Xorg(miPointerUpdateSprite+0x190) [0x4d1420]
14: /usr/bin/Xorg [0x4d14e2]
15: /usr/bin/Xorg [0x4fc698]
16: /usr/bin/Xorg [0x51ce4f]
17: /usr/bin/Xorg [0x44da4f]
18: /usr/bin/Xorg [0x4534d0]
19: /usr/bin/Xorg(MapWindow+0x182) [0x4321c2]
20: /usr/bin/Xorg(ProcMapWindow+0x46) [0x4460c6]
21: /usr/bin/Xorg(Dispatch+0x364) [0x446904]
22: /usr/bin/Xorg(main+0x45d) [0x42cd4d]
23: /lib64/libc.so.6(__libc_start_main+0xe6) [0x3f51e1e576]
24: /usr/bin/Xorg [0x42c129]
Comment 6 Greg Dolph 2009-05-26 07:42:25 EDT
(In reply to comment #5)
> Yeah, lovely:
> 
> Backtrace:
> 0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e7c96]
> 1: /usr/bin/Xorg(mieqEnqueue+0x291) [0x4c87d1]
> 2: /usr/bin/Xorg(xf86PostMotionEventP+0xc4) [0x4914c4]
> 3: /usr/bin/Xorg(xf86PostMotionEvent+0xa9) [0x491699]

I'm afraid I don't understand the significance. Is this useful or do you need more output?
Comment 7 Ben Skeggs 2009-05-26 07:56:17 EDT
Marking as duplicate of #484738, adding Option "HWCursor" "false" should work around the issue in the meantime.

*** This bug has been marked as a duplicate of bug 484738 ***
Comment 8 Greg Dolph 2009-05-26 08:28:20 EDT
(In reply to comment #7)
> Marking as duplicate of #484738, adding Option "HWCursor" "false" should work
> around the issue in the meantime.
> 
> *** This bug has been marked as a duplicate of 484738 ***  

Outstanding! Works like a charm. I was worries switching to SWCursor would cause mouse lag but I can't tell the difference. 

So I take it this is an NV driver bug. Any ideas when a fix is due? 

Thanks again for the fix!
Comment 9 Matěj Cepl 2009-05-26 16:35:31 EDT
(In reply to comment #6)
> I'm afraid I don't understand the significance. Is this useful or do you need
> more output?  

No, that's just one RH guy talking to another one. Just to show what kind of breakage is going on.
Comment 10 Greg Dolph 2009-06-10 12:39:30 EDT
*** Bug 486118 has been marked as a duplicate of this bug. ***

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