Bug 13775

Summary:	[GM965] OpenGL programs hang after rebooting machine w/o full shutdown
Product:	Mesa	Reporter:	Richard Goedeken <SirRichard>
Component:	Drivers/DRI/i965	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED NOTABUG	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	xorg.conf Xorg.0.log gl-crash-tv.txt

Description Richard Goedeken 2007-12-21 18:13:10 UTC

- System: AOpen MiniPC MP965-DR
 - CPU/RAM: Core 2 duo T7500, 2GB ram
 - OS: Fedora 8
 - X server: xorg 1.4.99.1-0.10.fc9
 - intel_drv.so: built from 12/18 git: f69b48fe24ef9..
 - mesa/drm drivers: built from 12/21 git: f8830a1bf788..
 - system outputs: VGA, TMDS-1, LVDS, TV
 - TV: 32" Sony WEGA, NTSC 480i only

This bug causes opengl programs to hang with 100% cpu usage, and also prevent any interaction with the X desktop or programs.  To reproduce this bug, I did the following:

1. Boot MiniPC in TV-only configuration with 800x600 resolution
2. Run glxgears (or other opengl program)
   - runs without problem
3. Use xrandr to change resolution to 1024x768
4. Run glxgears again
   - program locks up after drawing blank black client area, sometimes before drawing title bar and frame

The system may be restored to functionality by connecting remotely by SSH and killing the opengl program.  However, after this crash/deadlock occurs once, the opengl program will hang every time it's started, even after switching back to 800x600.  The only way to restore normal operation is to shut down and restart the machine.

I am submitting this bug to both the xorg/Driver/intel and DRI/DRM_Modules projects as I'm not sure in which driver the problem lies.

Comment 1 Richard Goedeken 2007-12-21 18:14:54 UTC

Created attachment 13302 [details]
xorg.conf

Comment 2 Richard Goedeken 2007-12-21 18:15:20 UTC

Created attachment 13305 [details]
Xorg.0.log

Comment 3 Richard Goedeken 2007-12-21 18:15:44 UTC

Created attachment 13307 [details]
gl-crash-tv.txt

Comment 4 Richard Goedeken 2007-12-30 11:19:33 UTC

After further testing I have found that this bug is not dependent upon the TV
output (I duplicated it in VGA-only configuration), or even the resolution
switching.  It only happens when I restart the MiniPC without doing a full
shutdown.  Here are the results of 9 tests that I ran this afternoon:

Initial conditions: running in TV-only mode at 800x600.

Test 1: machine shutdown.  restarted VGA-only at default 1024x768. 
        - glxinfo ok - glxgears ok, even after using xrandr to switch resolution
Test 2: changed default VGA res to 800x600. Restarted w/o shutdown.  
        - glxinfo ok - glxgears crashed immediately
Test 3: restarted w/o shutdown.
        - glxinfo ok - glxgears crashed immediately
Test 4: restarted w/o shutdown.
        - glxinfo ok - glxgears crashed immediately
Test 5: machine shutdown and restarted.
        - glxinfo ok - glxgears ok, even with res switching
Test 6: machine shutdown and restarted.
        - glxinfo ok - glxgears ok, even with res switching
Test 7: restarted w/o shutdown.
        - glxinfo ok - glxgears crashed immediately
Test 8: changed default VGA res to 1024x768, restarted w/o shutdown.
        - glxinfo ok - glxgears crashed immediately
Test 9: machine shutdown and restarted.
        - glxinfo ok - glxgears ok, even with res switching

Comment 5 Richard Goedeken 2008-01-31 08:45:50 UTC

This actually belongs under the Mesa product, in the DRI/i965 component.

Comment 6 Gordon Jin 2008-01-31 18:19:09 UTC

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

Comment 7 Richard Goedeken 2008-03-08 12:46:48 UTC

I just re-ran the tests for this bug and could not reproduce it.  So either it
was fixed in the last 2 months or it was a configuration problem on my local
system.  Marked as NOTABUG.

Comment 8 Adam Jackson 2009-08-24 12:28:56 UTC

Mass version move, cvs -> git

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.