Bug 620827 - [IGDNG_D] Hard crash intel driver with Clarkdale video chip
[IGDNG_D] Hard crash intel driver with Clarkdale video chip
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drv-i810 (Show other bugs)
5.5
All Linux
low Severity high
: rc
: ---
Assigned To: Adam Jackson
desktop-bugs@redhat.com
: Triaged
Depends On:
Blocks: 726826
  Show dependency treegraph
 
Reported: 2010-08-03 11:20 EDT by John Perkins
Modified: 2012-04-17 17:32 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-17 17:32:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
messages log after crash (48.66 KB, text/plain)
2010-08-23 14:47 EDT, John Perkins
no flags Details
xorg.conf file from affected system (60.93 KB, text/plain)
2010-08-23 14:48 EDT, John Perkins
no flags Details
X-server log file for X-server generated after crash and reboot (27.31 KB, text/plain)
2010-08-23 14:48 EDT, John Perkins
no flags Details
X-server log file from X-server running at the time of the crash (rotated out after reboot/restart) (24.22 KB, text/plain)
2010-08-23 14:49 EDT, John Perkins
no flags Details
dmesg output before crash (72.02 KB, text/plain)
2010-08-23 14:49 EDT, John Perkins
no flags Details
dmesg output after crash (not sure if drm.debug flag is set here or not) (22.24 KB, text/plain)
2010-08-23 14:50 EDT, John Perkins
no flags Details

  None (edit)
Description John Perkins 2010-08-03 11:20:23 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): 
xorg-x11-drv-i810-1.6.5-9.36.el5.x86_64


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.
Comment 1 Matěj Cepl 2010-08-20 14:08:44 EDT
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.
Comment 2 John Perkins 2010-08-23 14:47:23 EDT
Created attachment 440453 [details]
messages log after crash
Comment 3 John Perkins 2010-08-23 14:48:05 EDT
Created attachment 440454 [details]
xorg.conf file from affected system
Comment 4 John Perkins 2010-08-23 14:48:45 EDT
Created attachment 440455 [details]
X-server log file for X-server generated after crash and reboot
Comment 5 John Perkins 2010-08-23 14:49:22 EDT
Created attachment 440456 [details]
X-server log file from X-server running at the time of the crash (rotated out after reboot/restart)
Comment 6 John Perkins 2010-08-23 14:49:50 EDT
Created attachment 440457 [details]
dmesg output before crash
Comment 7 John Perkins 2010-08-23 14:50:26 EDT
Created attachment 440458 [details]
dmesg output after crash (not sure if drm.debug flag is set here or not)
Comment 8 Glen 2010-08-23 15:54:30 EDT
Gentlemen:

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.

-- glen
Comment 9 Glen 2010-08-23 17:39:35 EDT
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
Comment 10 Matěj Cepl 2010-08-26 13:40:46 EDT
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.

Thank you
Comment 11 John Perkins 2010-08-26 17:22:23 EDT
(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
Comment 12 Glen 2010-08-26 17:56:55 EDT
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.
Comment 13 John Perkins 2010-08-26 18:02:27 EDT
(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.
Comment 14 Matěj Cepl 2010-08-31 07:11:16 EDT
(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

Section "Device"
        Driver          "intel"
EndSection

(that's it, other parts of xorg.conf should be autogenerated)?
Comment 15 Glen 2010-10-06 15:37:19 EDT
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"
> EndSection
> 
> (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?

--glen
Comment 16 Rainer S. 2010-11-29 09:12:33 EST
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?

--Rainer
Comment 17 Rosco 2010-12-06 06:53:23 EST
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.
Comment 18 Aram Agajanian 2010-12-06 11:11:15 EST
I experienced this bug on a Dell Optiplex 980.  The hard crashes went away after adding a PCIe video card.
Comment 19 Rainer S. 2010-12-07 01:33:43 EST
Hello RedHat guys, is there any progress at RedHat on this issue or will it never be solved in RHEL5.5?
Comment 22 Aram Agajanian 2012-03-28 14:37:51 EDT
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.
Comment 24 Adam Jackson 2012-04-17 17:32:51 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.