Red Hat Bugzilla – Bug 159960
i915 DRM module fails after an ACPI suspend/resume cycle
Last modified: 2015-01-04 17:20:07 EST
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:
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
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.
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:
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.
This bug has been squashed by the Ubuntu folks:
It looks like the problem requires a fix of both the drm modules and the X server.
I've unbroken things on Fedora by installing these snapshots of the xorg drivers
This fixes the X server half of the problem, but the DRM modules included in
those packages cause a crash on suspend.
This can be fixed by patching the Fedora-supplied i915 drm module with the
i915drm-sync-ver patch from Ubuntu's kernel. (All this patch does is increment
the minor version number of the drm module from 1 to 2). After this, suspend
and resume seem to work as expected. If the patch is NOT applied to the kernel
module, then I get the same failure as before.
Ugly, but it at least proves that dri CAN survive a suspend-resume cycle ...
even on Fedora.
Is this already in the upstream 2.6.12 kernel?
Oops, that should be the
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
Is it possible to get a patch against the (vanilla) 2.6.12 kernel? I'm not on
redhat, though I experience exact the same problem and couldn't find much about
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.