Bug 159960

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1

Description of problem:
Using the kernel boot parameter
"acpi_sleep=s3_bios" allows my notebook to suspend and resume with ACPI, but 
DRI doesn't survive properly and if any 3D application is run after a resume I get wither:

* An X server hang that requires shutting down the machine (the machine is
still running and responds to acpi events, so I can shut down the
machine).  This happens with armagetron or celestia.

* The application draws its first frame, freezes a few seconds, then
crashes without taking the X server with it.  (the GL screensavers,
glxgears do this).  When this happens, I get an error message in the
console after the app crashes:

$ glxgears
intelWaitIrq: drmI830IrqWait: -16

The kernel also complains.  dmesg gives a message like:

[drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 0 emitted: 7

... for every attempt to run a GL application.


Version-Release number of selected component (if applicable):
kernel-2.6.11-1.14_FC3 through kernel-2.6.11-1.27_FC3 , xorg-x11-6.8.2-1.FC3.13 through xorg-x11-6.8.2-1.FC3.34

How reproducible:
Always

Steps to Reproduce:
1.Log into a gnome session
2.run glxgears to verify that DRI's working
3.suspend using ACPI
4.On resume, run glxgears again
  

Actual Results:  glxgears crashes, kernel complains about i915_wait_irq is busy


Expected Results:  glxgears and other GL applications operates normally.

Additional info:

THe system in question is a JVC (Asus) MiniNote MP-XV841.  The video chipset is reported as Intel 82852/855GM.

I'm not sure whether this bug is best filed against the kernel or xorg-x11, but it's the kernel that spits out the error message. :)  Please move the bug somewhere else if it's more appropriate there.

This bug is very similar to the one reported in this URL:

http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg21138.html

THe workaround described there works (just not very well), and the DRM module will actually work again if X is restarted, but that ruins the whole point of suspending the machine in the first place.