Bug 448141 - Xorg gets sig 11 at boot time, possibly related to intel_master_drv.so
Xorg gets sig 11 at boot time, possibly related to intel_master_drv.so
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
9
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
http://lunkwill.dartmouth.edu/trin/
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-23 14:27 EDT by wstearns
Modified: 2018-04-11 04:19 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-09 15:52:03 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)
/var/log/Xorg.0.log (22.77 KB, text/plain)
2008-05-23 15:59 EDT, Matěj Cepl
no flags Details
Xorg log file after applying Fedora 9 patches (14.28 KB, text/plain)
2008-06-09 14:28 EDT, wstearns
no flags Details

  None (edit)
Description wstearns 2008-05-23 14:27:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080416 Fedora/2.0.0.14-1.fc7 Firefox/2.0.0.14

Description of problem:
This is a fresh install of Fedora Core 9 on a Dell Optiplex 755.  Graphical installation went fine, and boot time graphical mode shows fine too.  When it comes time to switch into xorg, xorg crashes before displaying a desktop, catching sig 11.  At that point monitor immediately reports system has gone into sleep mode (true whether analog or digital input selected).

sysreport, Xorg logs, dmesg, lspci, lspc -v, and uname -a can be found at the above URL, http://lunkwill.dartmouth.edu/trin/


Fatal server error:
lockup

(II) UnloadModule: "mouse"
(II) UnloadModule: "kbd"
(II) Macintosh mouse button emulation: Close
(II) UnloadModule: "evdev"
(II) Dell Dell USB Mouse: Close
(II) UnloadModule: "evdev"
(II) AIGLX: Suspending AIGLX clients for VT switch

Backtrace:
0: /usr/bin/Xorg(xf86SigHandler+0x65) [0x479fe5]
1: /lib64/libc.so.6 [0x7f059f2c72a0]
2: /usr/lib64/xorg/modules/drivers//intel_master_drv.so [0x7f059d6bef78]
3: /usr/lib64/xorg/modules/drivers//intel_master_drv.so [0x7f059d6c1d05]
4: /usr/lib64/xorg/modules/drivers//intel_master_drv.so [0x7f059d6c39c0]
5: /usr/bin/Xorg(AbortDDX+0x8d) [0x460acd]
6: /usr/bin/Xorg(AbortServer+0x18) [0x4f6048]
7: /usr/bin/Xorg(FatalError+0xd5) [0x4f6715]
8: /usr/lib64/xorg/modules/drivers//intel_master_drv.so(I830WaitLpRing+0x1c1) [0x7f059d6b9e51]
9: /usr/lib64/xorg/modules/drivers//intel_master_drv.so(I830Sync+0x1b3) [0x7f059d6ba223]
10: /usr/lib64/xorg/modules//libexa.so(exaWaitSync+0x8c) [0x7f059c76536c]
11: /usr/lib64/xorg/modules//libexa.so(ExaDoPrepareAccess+0xa5) [0x7f059c766935]
12: /usr/lib64/xorg/modules//libexa.so [0x7f059c767c68]
13: /usr/lib64/xorg/modules//libexa.so [0x7f059c767d62]
14: /usr/bin/Xorg [0x532078]
15: /usr/bin/Xorg(ProcPutImage+0x157) [0x443357]
16: /usr/bin/Xorg(Dispatch+0x364) [0x446394]
17: /usr/bin/Xorg(main+0x45d) [0x42c87d]
18: /lib64/libc.so.6(__libc_start_main+0xfa) [0x7f059f2b332a]
19: /usr/bin/Xorg(FontFileCompleteXLFD+0x279) [0x42bc59]
        
FatalError re-entered, aborting
Caught signal 11.  Server aborting


Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.x86_64

How reproducible:
Always


Steps to Reproduce:
1. Immediate crash as soon as system tries to go into runlevel 5.
2.
3.

Actual Results:
Sig 11 reported in Xorg.0.log, http://lunkwill.dartmouth.edu/trin/Xorg.0.log

Expected Results:
No crash.

Additional info:
Video card has cable-split DVI and vga outputs, both connected to a Dell W3000 monitor.
Comment 1 Matěj Cepl 2008-05-23 15:59:37 EDT
Created attachment 306544 [details]
/var/log/Xorg.0.log
Comment 2 Emmanuel Thomé 2008-05-27 19:36:38 EDT
Similar stuff here. Dell GX755 as well. I've seen a segv at some point as well,
however it's rather the first X server (for graphical boot) which leaves the
hardware in a bizarre state when it terminates. Later attempts to start again an
X server lead to segv sometimes.

The machines are in production use, so I can't give you more info ; my priority
was to get the machines back up and running. I'll give a try with the live CD
tomorrow, I noticed it did crash just the same way.

In the meantime, downgrading to F8 packages for the xorg server stuff did the trick.

Regards,

E.
Comment 3 wstearns 2008-06-09 14:26:16 EDT
After upgrading Fedora 9 packages, the Xorg.0.log file has new content.  I'll
attach a new file in the next note, but in short, the last three different lines
are:

+(WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
+(WW) intel(0): PRB0_HEAD (0x00011234) and PRB0_TAIL (0x00011ec8) indicate ring
buffer not flushed
+(WW) intel(0): Existing errors found in hardware state.

The offer of remote access to this system and a network camera watching the
screen is still good; please see your email if you're interested.
Comment 4 wstearns 2008-06-09 14:28:09 EDT
Created attachment 308740 [details]
Xorg log file after applying Fedora 9 patches
Comment 5 wstearns 2008-06-09 15:52:03 EDT
I disabled graphical boot (removed " rhgb quiet" from each of the kernel stanzas
in /boot/grub/grub.conf .  With this change, the system comes completely up into
an Xorg login.  This works after both a complete power off and a reboot.

At the moment, this appears to be resolved.  I don't need a graphical boot for
this system.

Is there a chance that the graphical boot is not returning the video card to a
pristine state before X takes over?

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