Bug 190461 - Random crashes when using X
Random crashes when using X
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel-xen (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
Virtualization Bugs
:
: 183341 (view as bug list)
Depends On:
Blocks: 179629
  Show dependency treegraph
 
Reported: 2006-05-02 12:44 EDT by Markus Armbruster
Modified: 2009-12-14 15:37 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-26 18:06:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Console output of ten reboots into runlevel 5, 9 ok, 1 crash (196.26 KB, application/octet-stream)
2006-05-02 12:44 EDT, Markus Armbruster
no flags Details
Diff between successful non-rhgb boot to runlevel 5 (first one in attachment 128496) and same with rhgb (4.70 KB, text/x-patch)
2006-05-02 12:50 EDT, Markus Armbruster
no flags Details
Diff between successful and unsuccessful rhgb boot to runlevel 5 (6.61 KB, text/x-patch)
2006-05-02 12:53 EDT, Markus Armbruster
no flags Details
Diff between successful non-Xen (kernel-2.6.16-1.2096_FC5) and Xen (kernel-xen0-2.6.16-1.2096_FC5) boot, note funny PCI bridge setup differences (18.83 KB, text/plain)
2006-05-02 12:58 EDT, Markus Armbruster
no flags Details

  None (edit)
Description Markus Armbruster 2006-05-02 12:44:33 EDT
Description of problem:
I experience kernel crashes when using X with Xen, whether I start X through
rhgb, runlevel 5 or startx in runlevel 3.

Version-Release number of selected component (if applicable):
kernel-xen0-2.6.16-1.2150_FC6

How reproducible:
About half the time with rhgb.
Maybe one in ten times without rhgb booting to runlevel 5.
Likewise when running startx in runlevel 3.
System is known to be stable without Xen, as well as with Xen and without X,
even under load.

Steps to Reproduce:
1. Boot with rhgb
-or-
1. Boot without rhgb to runlevel 5
-or-
1. Boot without rhgb to runlevel 3, run startx with .xinitrc containing just
`xterm'.
2. Move pointer into xterm, type C-d to exit the shell running in the xterm,
thus shutting down X.

Actual results:
Machine crashes at unpredictable time after rhgb started X and before graphical
login appears.  Both hangs and spontaneous reboots happen.  Machine crashes on
shutdown from runlevel 5, possibly while shutting down X.  Maschine crashes
during X startup and shutdown from startx.  Machine crashes while idling after
startx terminated.

Expected results:
Machine doesn't crash.

Additional info:
Dell Latitude D610, Intel Corporation Mobile 915GM/GMS/910GML Express Graphics
Controller
kernel-xen0-2.6.16-1.2096_FC5 appears to have the same problem.
memtest86+ is happy (2 full passes, ~2 hours).

Grub stanza:
title Fedora Core (2.6.16-1.2096_FC5xen0)
        root (hd0,1)
        kernel /xen.gz-2.6.16-1.2096_FC5 com1=38400,8n1 sync_console
        module /vmlinuz-2.6.16-1.2096_FC5xen0 ro root=/dev/VolGroup00/LogVol00 \
console=ttyS0 console=tty pnpacpi=off rhgb
        module /initrd-2.6.16-1.2096_FC5xen0.img
        savedefault

Could well be related to Bugzilla Bug 190028 – Display messed up.
Comment 1 Markus Armbruster 2006-05-02 12:44:33 EDT
Created attachment 128496 [details]
Console output of ten reboots into runlevel 5, 9 ok, 1 crash
Comment 2 Markus Armbruster 2006-05-02 12:50:52 EDT
Created attachment 128497 [details]
Diff between successful non-rhgb boot to runlevel 5 (first one in attachment 128496 [details]) and same with rhgb
Comment 3 Markus Armbruster 2006-05-02 12:53:31 EDT
Created attachment 128498 [details]
Diff between successful and unsuccessful rhgb boot to runlevel 5
Comment 4 Markus Armbruster 2006-05-02 12:58:43 EDT
Created attachment 128499 [details]
Diff between successful non-Xen (kernel-2.6.16-1.2096_FC5) and Xen (kernel-xen0-2.6.16-1.2096_FC5) boot, note funny PCI bridge setup differences
Comment 5 Adam Jackson 2006-06-26 17:20:36 EDT
*** Bug 183341 has been marked as a duplicate of this bug. ***
Comment 6 Rik van Riel 2006-10-06 17:15:17 EDT
Markus, are you still seeing this?

My x86-64 with Radeon is well behaved now...
Comment 7 Markus Armbruster 2006-10-09 09:40:45 EDT
Machine is now running plain FC-5.  Quick test: while true; do telinit 5; sleep
10; telinit 2; sleep 10; done

kernel-xen0-2.6.17-1.2187_FC5 crashes after a few iterations, looks random
kernel-2.6.17-1.2187_FC5 didn't crash
my development kernel based on
http://hg.et.redhat.com/kernel/linux-2.6-xen-fedora didn't crash

Do you want me to try other kernels?  Do you need more information about the
crashes I see now?
Comment 8 Daniel Malmgren 2006-10-10 07:22:59 EDT
I don't know if this is relevant, and I also don't really know how to provide
any good information on it, but I see something similar on my FC devel laptop. I
can boot xen kernel up just fine in console mode. Everything works. When I start
X I get to the gdm login, but if I try to login the machine crashes so fast and
so hard that I've got no possibility to get any useful debug information.

Using the normal (non xen) kernel works just fine.
Comment 9 Daniel Malmgren 2006-10-11 04:19:01 EDT
Since I've discovered that my crashes are not even a tiny bit random (in fact
there seems to be some kind of trouble with xen/compiz), I've opened a new
report (#210277) for it. 
Comment 10 Adam Jackson 2007-05-03 14:55:38 EDT
Any change on this?
Comment 11 Markus Armbruster 2007-05-16 14:34:56 EDT
I retried switching between run levels 3 and 5 in a loop (with somewhat random
delays).  More than forty iterations, no problems.  kernel-xen-2.6.20-1.2948.fc6

I guess the bug has been fixed upstream (supporting evidence in comment#7), and
the fix has made it into FC-6.
Comment 12 Red Hat Bugzilla 2007-07-24 21:31:20 EDT
change QA contact
Comment 13 Chris Lalancette 2008-02-26 18:06:58 EST
OK, looks like this has been resolved (and this bug is very old).  Closing it out.

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