Bug 501781

Summary: X crashes when lid is closed or power state changes
Product: [Fedora] Fedora Reporter: Greg Dolph <gdolph-c>
Component: xorg-x11-drv-nvAssignee: Ben Skeggs <bskeggs>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 10CC: mcepl, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-26 11:56:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
xorg.conf
none
xorg log file
none
dmesg
none
xorg.conf none

Description Greg Dolph 2009-05-20 17:10:59 UTC
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 14:14:34 UTC
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 14:28:42 UTC
Created attachment 344967 [details]
xorg log file

Comment 3 Greg Dolph 2009-05-21 14:30:16 UTC
Created attachment 344968 [details]
dmesg

Comment 4 Greg Dolph 2009-05-21 14:31:26 UTC
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-24 00:02:38 UTC
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 11:42:25 UTC
(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 11:56:17 UTC
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 12:28:20 UTC
(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 20:35:31 UTC
(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 16:39:30 UTC
*** Bug 486118 has been marked as a duplicate of this bug. ***