Bug 13177

Created attachment 12445 [details]
Output from lspci

Created attachment 12446 [details]
xorg.conf from ThinkPad

Created attachment 12447 [details]
Xorg.0.log after normal boot

Created attachment 12448 [details]
Xorg.0.log with error messages

Fengming, are you able to reproduce this?

Soenke, does this also happen on VT switch after playing a video?  I.e. can you Ctl-Alt-F1 to a text console, then Alt-F7 to get back to X and see the crash?  Or is it only suspend/resume?

Jesse, you're right, it is switching to vt that causes the crash. 
Sorry I did not realise that before.
Anything more I can do to help?

Regards,

Soenke

(In reply to comment #6)
> Soenke, does this also happen on VT switch after playing a video?  I.e. can you
> Ctl-Alt-F1 to a text console, then Alt-F7 to get back to X and see the crash? 
> Or is it only suspend/resume?
> 

Thanks for checking.  I think our QA team has an X40.  Fengming or Nian, can you reproduce this one?

I test this problem on lab 855gm.VT switch without playing media has no problem.But VT switch with playing media or suspend to ram or disk with playing media can cause same error that as s.huels described:X crashes. This also causes the suspend process to hang and I end up with a graphical login but no text consoles. Rebooting is required to get
the machine back to its normal state.
System Environments:
Toshiba ThinkPad X40 1.4GHz, 512MB RAM
i855GM integrated graphics
Fedora kernel 2.6.22
libDrm: 2.3.0
Mesa: 7.0.2Xf86-video-intel: 2.1.99(2.2 pre-release)
Xserver: 1.4

Created attachment 12471 [details]
xorg log file

btw, Jesse, the 855GM QA have is Toshiba Sattelite M20, not Thinkpad X40.

Fengming or Soenke, can you follow the instructions at http://www.x.org/wiki/Development/Documentation/ServerDebugging and try to get a good backtrace from when the crash occurs?  After attaching to the server with gdb, I'd recommend setting a breakpoint in i830_accel.c:I830WaitLpRing before the line where it calls 'FatalError("lockup")'.

VT switch without playing media has no problem.But VT switch with playing media or suspend to ram or disk with playing media can cause error.I think the essential reason of all these phenomenons is LeaveVT's problem.I got backtrace messages as following:

(gdb) bt
#0  0xffffe410 in ?? ()
#1  0xbf927c4c in ?? ()
#2  0x00000006 in ?? ()
#3  0x00000d3b in ?? ()
#4  0x00678159 in raise () from /lib/libc.so.6
#5  0x006796e3 in abort () from /lib/libc.so.6
#6  0x081b8561 in FatalError (f=0x0) at log.c:554
#7  0xb7d0d137 in I830WaitLpRing (pScrn=0x8213470, n=131064,
    timeout_millis=2000) at i830_accel.c:150
#8  0xb7d0d292 in I830Sync (pScrn=0x8213470) at i830_accel.c:201
#9  0xb7d1f1f5 in I830StopVideo (pScrn=0x8213470, data=0x8226dec, shutdown=1)
    at i830_video.c:1012
#10 0xb7d24c56 in i830_crtc_dpms_video (crtc=0x8216468, on=0)
    at i830_video.c:2841
#11 0xb7d11a17 in i830_crtc_dpms (crtc=0x8216468, mode=3) at i830_display.c:714
#12 0xb7d1517e in RestoreHWState (pScrn=0x8213470) at i830_driver.c:2012
#13 0xb7d1825a in I830LeaveVT (scrnIndex=0, flags=0) at i830_driver.c:3004
#14 0x080de639 in xf86XVLeaveVT (index=0, flags=0) at xf86xv.c:1278
#15 0xb7da9a2f in glxDRILeaveVT (index=0, flags=0) at glxdri.c:993
#16 0x080a1c16 in AbortDDX () at xf86Init.c:1102
#17 0x081b8258 in AbortServer () at log.c:406
#18 0x081b8554 in FatalError (f=0x0) at log.c:552
#19 0xb7d0d137 in I830WaitLpRing (pScrn=0x8213470, n=131064,
    timeout_millis=2000) at i830_accel.c:150
#20 0xb7d0d292 in I830Sync (pScrn=0x8213470) at i830_accel.c:201
#21 0xb7d1f1f5 in I830StopVideo (pScrn=0x8213470, data=0x8226dec, shutdown=1)
    at i830_video.c:1012
#22 0xb7d24c56 in i830_crtc_dpms_video (crtc=0x8216468, on=0)
    at i830_video.c:2841
#23 0xb7d11a17 in i830_crtc_dpms (crtc=0x8216468, mode=3) at i830_display.c:714
#24 0xb7d1517e in RestoreHWState (pScrn=0x8213470) at i830_driver.c:2012
#25 0xb7d1825a in I830LeaveVT (scrnIndex=0, flags=0) at i830_driver.c:3004
#26 0x080de639 in xf86XVLeaveVT (index=0, flags=0) at xf86xv.c:1278
#27 0xb7da9a2f in glxDRILeaveVT (index=0, flags=0) at glxdri.c:993
#28 0x080d0dda in xf86Wakeup (blockData=0x0, err=1, pReadmask=0x8202b40)
    at xf86Events.c:878
#29 0x0808b7f2 in WakeupHandler (result=1, pReadmask=0x8202b40)
    at dixutils.c:475
#30 0x081aaa6f in WaitForSomething (pClientsReady=0xbf9284b0) at WaitFor.c:238
#31 0x080872d3 in Dispatch () at dispatch.c:425
#32 0x0806e2d0 in main (argc=2, argv=0xbf9289e4, envp=0x0) at main.c:452

Created attachment 12515 [details] [review]
Fix for overlay off routine

This is really a shot in the dark, Zhenyu can you take a look at this?

It looks like the overlay off routine isn't enabling pipe A if needed, which may be causing the lockups.  However, it calls i830WaitSync twice, so I'd have expected the ring to hang there instead, so this probably isn't the fix we're looking for...

Keith, could you review the patch?

Tested without luck, same backtrace.
Just a comment, it seems to me that this patch tries to enable the pipe A when using Xv. This would be useless in my particular case where I'm applying patch #23 in bug https://bugs.freedesktop.org/show_bug.cgi?id=11432. Where it causes pipe A enabling all the time emulating a monitor connected to that pipe.

Thanks.

*** Bug 12356 has been marked as a duplicate of this bug. ***

Also no luck with this patch here, the problem persists. So far, I did not get a decent backtrace (still getting used to gdb), but the messages in Xorg.0.log are still the same.

(In reply to comment #14)
> Created an attachment (id=12515) [details]
> Fix for overlay off routine
> 
> This is really a shot in the dark, Zhenyu can you take a look at this?
> 
> It looks like the overlay off routine isn't enabling pipe A if needed, which
> may be causing the lockups.  However, it calls i830WaitSync twice, so I'd have
> expected the ring to hang there instead, so this probably isn't the fix we're
> looking for...
> 

Created attachment 12549 [details]
Leave ring running for RestoreHWState

Keith pointed out that we explicitly stop the ring before doing I830StopVideo, which is bad.  This patch may help (I think it's safe, but I'm not 100% sure).

Please test this out and let me know.

WFM, thank you very much. 

Created attachment 12550 [details]
Updated ring patch

Here's an updated version that should be safer, it also removes a superfluous hide cursors call and does a little cleanup.  Please test.

Sweet, I'll push then.  Thanks a lot for your patience.

Also works. Note that, while testing I stumbled again over Bug 13108. But VT    switch after/while XV seems OK so far.

Works for me as well. Only now some other git commit seems to have broken xbacklight, but that is a different story...
Thanks for the quick fix!

Regards,

Soenke

Uh-oh, backlight problems?  Can you send a mail to jbarnes@virtuousgeek.org describing what you're seeing?

Glad this bug is fixed though.

Thanks,
Jesse

This is great guys, it's also working here. I've been chasing this bug for quite a long time(little after 2.1.1 release).

Thanks all for the effort.