Bug 524242
| Summary: | Xorg segfault with intel graphics driver on 915G | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Doug Kelly <djk7wb> | ||||||||||
| Component: | xorg-x11-drv-i810 | Assignee: | Adam Jackson <ajax> | ||||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | desktop-bugs <desktop-bugs> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | low | ||||||||||||
| Version: | 5.4 | Keywords: | Triaged | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | i386 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | card_915G | ||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2010-07-23 16:54:37 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 361663 [details]
gdb backtrace
Created attachment 361664 [details]
xorg.conf from affected machine
Created attachment 361665 [details]
lspci -vvv output
Actually looks to be a duplicate of #521350, so close this one if desired. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Backtrace: 0: /usr/bin/Xorg(xf86SigHandler+0x81) [0x80cedc1] 1: [0x3ac420] 2: /usr/lib/xorg/modules/libi2c.so(xf86I2CFindDev+0x29) [0x1f43b9] 3: /usr/lib/xorg/modules/libddc.so [0x1ebe75] 4: /usr/lib/xorg/modules/libddc.so(xf86DoEEDID+0x102) [0x1ec122] 5: /usr/bin/Xorg(xf86OutputGetEDID+0x40) [0x80f6230] 6: /usr/lib/xorg/modules/drivers/intel_drv.so(i830_ddc_get_modes+0x2c) [0x369a1c] 7: /usr/bin/Xorg(xf86ProbeOutputModes+0x28e) [0x80f71de] 8: /usr/bin/Xorg(xf86InitialConfiguration+0x14a) [0x80f89fa] 9: /usr/lib/xorg/modules/drivers/intel_drv.so [0x35fbc0] 10: /usr/bin/Xorg(InitOutput+0x9c5) [0x80a3eb5] 11: /usr/bin/Xorg(main+0x276) [0x8070546] 12: /lib/libc.so.6(__libc_start_main+0xdc) [0xb00e9c] 13: /usr/bin/Xorg(FontFileCompleteXLFD+0x1fd) [0x806fa51] Fatal server error: Caught signal 11. Server aborting (In reply to comment #4) > Actually looks to be a duplicate of #521350, so close this one if desired. Yes, I think you are right. Closing as a duplicate. *** This bug has been marked as a duplicate of bug 521350 *** |
Created attachment 361662 [details] Xorg.log with ModeDebug on on an affected system Description of problem: On certain older Intel integrated graphics chipsets, I have a problem which causes the X server to segfault and leave the display in an unusable state until a reboot. This only happens with the "intel" driver, and is not happening with the i810 driver. The system I'm testing on is a Dell OptiPlex GX280, which seems to report from the driver that there is a 915G chipset. I've attached a full output from lspci, so that should give a more accurate picture. I've also seen the issue with the older GX260. Newer hardware has a different problem that I believe is unrelated. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.1.1-48.67.el5 xorg-x11-drv-i810-1.6.5-9.25.el5 How reproducible: 100% on affected hardware Steps to Reproduce: 1. Configure xorg.conf to use the "intel" graphics driver (the default being selected for this chipset). 2. Start X 3. Reconfiguring to use "i810" and restarting X works (you can hear the system beep from GDM), but the display is still in an unusable/blank state. Actual results: X segfaults, results in the display being left in an unusable state (can't switch VTs, responsive to network--so I can reboot it remotely). Expected results: X server should start and not segfault. Additional info: This issue occurred immediately after our update to RHEL5.4, and all associated packages. However, before that point, updates had not been run for a significant amount of time (roughly three or four months). I've specifically set this to i386 as I have not attempted to reproduce the issue on x86_64. Only a few GX280s have the ability to run 64-bit code at all--if I can find one that will, I'll try it.