Red Hat Bugzilla – Bug 620827
[IGDNG_D] Hard crash intel driver with Clarkdale video chip
Last modified: 2012-04-17 17:32:51 EDT
Description of problem:
New Dell Optiplex 980 systems with Intel HD graphics (Clarkdale chip) will crash the computer. Computer crashes hard; only power-off/power-on will bring it back to a usable state.
Version-Release number of selected component (if applicable):
How to reproduce/How reproducible:
Start prefdm/gdm and x-server on one of the affected computers. Wait 24 hours, or perhaps start start certain X applications (I tried Firefox, glxgears, xeyes, maybe an xterm/gnome-terminal or two) until the crash occurs.
The computers affected by this issue will crash within 24 hours, often less-often than that.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please add drm.debug=0x04 to the kernel command line, restart computer, wait until crash happens, and then attach
* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command (cannot you access computer at least via ssh?), and
* system log (/var/log/messages)
to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 440453 [details]
messages log after crash
Created attachment 440454 [details]
xorg.conf file from affected system
Created attachment 440455 [details]
X-server log file for X-server generated after crash and reboot
Created attachment 440456 [details]
X-server log file from X-server running at the time of the crash (rotated out after reboot/restart)
Created attachment 440457 [details]
dmesg output before crash
Created attachment 440458 [details]
dmesg output after crash (not sure if drm.debug flag is set here or not)
I can confirm the problem on a different platform (Intel DQ57TM motherboard with Core i5 CPU, 16GB RAM) and it happens within 10 - 60 minutes the way I am using the system - if I do a lot of switching between tty1 and display0 or display1, and startx and stop the X win system a lot, the system will ultimately hard lock.
My xorg.conf is using the driver "intel" as the Device. I saw a note somewhere (CentOS I think) about adding option DDC false, this did nothing.
It always happens right at the point X is loaded and the display changes from text mode tty to graphics mode display. The result is a black screen, the monitor goes into vesa power save mode, and no errors in the log files. On my system you cannot hard reset (reset sw) only hard power off to restart.
Also, I occasionally see on the tty that owns startx the following errors when switching from tty to X windows graphics:
(EE) intel(0): I830 Dma Resume Failed
OK, can I ask both of you to try to reproduce the bug with NO xorg.conf at all? You shouldn't have to have one in order to get intel driver, which is what of both you get.
(In reply to comment #10)
> OK, can I ask both of you to try to reproduce the bug with NO xorg.conf at all?
> You shouldn't have to have one in order to get intel driver, which is what of
> both you get.
The X-server runs with the i810 driver instead. Seems to be a stable display, but undesirable because:
- i810 driver doesn't handle widescreen resolutions very well without throbbing the video hardware first
- no GLX hardware acceleration without the "intel" driver
Are you sure you're running i810? I was surprised because I tried to change the device from "intel" to "i810" and that crashed the box immediately when the driver tried to load (I do have a widescreen monitor definition, tho, so maybe that was it).
Sorry all, but I had to wipe my RHEL 5 in favor of Fedora 13 which is much more stable on this platform, so I can't go back and do any debugging now. I may try to unplug my raid drives and use an external hdd just to test it again if you need the extra set of eyes.
(In reply to comment #12)
> Are you sure you're running i810? I was surprised because I tried to change the
> device from "intel" to "i810" and that crashed the box immediately when the
> driver tried to load (I do have a widescreen monitor definition, tho, so maybe
> that was it).
Yes, I got i810 with no xorg.conf file in place. It hasn't crashed yet, but that's not to say it won't.
(In reply to comment #11)
> The X-server runs with the i810 driver instead. Seems to be a stable display,
> but undesirable because:
Still, these logs could be interesting. Also navigating through your xorg.conf, could you try just a minimal xorg.conf
(that's it, other parts of xorg.conf should be autogenerated)?
In reply to comment #13)
> (In reply to comment #12)
> > Are you sure you're running i810? I was surprised because I tried to change the
> > device from "intel" to "i810" and that crashed the box immediately when the
> > driver tried to load (I do have a widescreen monitor definition, tho, so maybe
> > that was it).
> Yes, I got i810 with no xorg.conf file in place. It hasn't crashed yet, but
> that's not to say it won't.
John, my system also tries to default to i810 without a xorg.conf file, BUT it fails to load and winds up loading the VESA driver. I also eventually get the hard freeze with VESA.
(In reply to comment #14)
> could you try just a minimal xorg.conf
> Section "Device"
> Driver "intel"
> (that's it, other parts of xorg.conf should be autogenerated)?
I tried this, and I still get the hard lockup with the most minimal of xorg.conf - the intel driver shows that it detected the chipset:
(--) intel(0): Chipset: "IGDNG_D"
Is there any progress at RedHat on this issue?
I can say that Fedora 13 definitely does not exhibit this problem. Is there any way I can adapt the X11 drivers from 13 while you guys work this through?
Sorry asking once again, is there any progress at RedHat on this issue?
I see the same issue running RHEL5.5 on motherboards with Intel i3-350 using the Intel integrated HD Graphics - or will this only be supported by RHEL6?
I've seen this issue on two DQ57TM Mainboards with core i5 CPU. The machine is stable in console mode but when a user starts a graphic session, the machine hangs at a random interval (less than one hour). Even adding an extra graphic interface doesn't fix it.
I experienced this bug on a Dell Optiplex 980. The hard crashes went away after adding a PCIe video card.
Hello RedHat guys, is there any progress at RedHat on this issue or will it never be solved in RHEL5.5?
The Release Notes for RHEL 5.8 mention updates to processors with IronLake integrated graphics.
I tested our Optiplex 980 with EL5.8 and did not encounter any crashes. However, Xorg was unable to load a dri library so it fell back to software rendering.
No further hardware enablement updates are planned for RHEL5's X stack. If this issue is still present in RHEL6, please update the affected product field and reopen this bug.