Red Hat Bugzilla – Bug 218559
Window manager had issues when rebooting into a new Xen kernel?
Last modified: 2007-11-30 17:11:50 EST
Description of problem: Unsure. (Bug being reported and hopefully re-allocated
internally.) I think the problem is to do with Window Navigation Applets dying
unexpectedly when booting into a Xen kernel for the first time.
Version-Release number of selected component (if applicable):
$ uname -r
$ Xorg -version
X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: Linux 2.6.9-34.ELsmp i686 Red Hat, Inc.
Current Operating System: Linux <hostname> 2.6.18-1.2849.fc6xen #1 SMP Fri Nov
10 13:56:52 EST 2006 i686
Build Date: 15 November 2006
Build ID: xorg-x11-server 1.1.1-47.1.fc6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
# Unsure what other version information to provide.
Unsure if it is. I have just booted into a Xen kernel for the first time, and
was presented with this bug report. I thought I would post it sooner, rather
Steps to Reproduce:
1. Run with a 2.6.18-1.2849.fc6-i686 kernel fine for a few weeks.
2. Decide that you want to experiment with Xen and VMs.
3. Update to a 2.6.18-1.2849.fc6xen kernel and include any *xen* packages listed
4. Reboot into new Xen kernel, and login.
5. Be presented with "some application has crashed and please report the bug"
See provided (attached?) crash / bug report.
Not to have the crash report.
If more information is requested, I'll be more than happy to provide.
Note that the hostname has been removed from the information provided.
Created attachment 142906 [details]
The bug report of the crash.
We really need to know if/how reproducible this is, and whether there were any
kernel errors logged at the time. Also, what graphics adapter are you using?
Created attachment 143005 [details]
2.5 hour window of /var/log/messages
I'm unsure how much of /var/log/messages you would like here, but I extracted
from the morning reboot into the fresh new kernel, to the early-afternoon.
It appears to be mostly filled with issues from / with beagled.
Athlon 64 X2 5000+ on a MSI K9N Platinum SKT AM2 M/B, using an XFX NVidia
Using nvidia's own drivers? And is it reproducible?
The NVidia drivers are from the livna repo, which were updated at the same time
the new kernel was:
[root@localhost ~]# yum list *nvidia*
Loading "installonlyn" plugin
Setting up repositories
Reading repository metadata in from local files
kmod-nvidia.i686 1.0.9742-126.96.36.199_1.28 installed
kmod-nvidia-xen.i686 1.0.9742-188.8.131.52_1.28 installed
xorg-x11-drv-nvidia.i386 1.0.9742-3.lvn6 installed
I'll reboot now to determine reproducability.
Please remove the binary NVIDIA kernel modules & binary Xorg driver, and attempt
to reproduce this problem with the open source NV graphics drivers. If it can't
be reproduced with the open source drivers, you will have to file a bug report
with NVIDIA directly. We cannot debug binary NVIDIA driver problems since we
don't have their source.
I've rebooted with the current config (unchanged) and have been unable to
I'd be happy to use the open source NVidia driver if the MESA OpenGL had better
performance. I can get 6-10x better performance with the NVidia binary drivers.
Will now try rebooting to non-Xen kernel and back again to see if that triggered
I'm not askking you to use open source drivers long term. I merely need it
reproduced with the open source drivers so that we're able to debug the problem
& thus determine whether its a bug in Xen (which we can help with), or a bug in
binary NVIDIA drivers (which we can't help with).
So, can you reproduce this with open source drivers ?
Problem hasn't been reproduced going from 2.6.18-1.2849.fc6, to
I wasn't sure if this was a Xen problem, or a problem with what ever S/W caused
the fault (I wasn't able to determine what program, so it was filed under here).
I'm reluctant to tinker with swapping nv and NVidia drivers as it may take a
while to re-set up my multi-monitor setup. Also, as the bug doesn't appear to be
reproducable (maybe something has been permanently changed now?), by changing
kernels and compiled versions of NVidia drivers (Xen / non-Xen), I'm unsure if
changing back to the nv driver (which hasn't been used since the install
process) will prove anything.
OK, I'll leave this closed as INSUFFICIENTDATA for now, since it's not
reproducible and we haven't got any data about whether the open-source driver
fails. Please feel free to reopen if you are able to find any usable
diagnostics without the NVidia driver.
Created attachment 143367 [details]
Another bug report created
A reboot after almost five days of uptime has generated the following bug
report on login (see attached).
This make early references to beagle being the culprit. This would make sense
when compared to the number of entries shown in attachment id: 143005 (log of
Perhaps this should be re-assigned, or is this only a Xen-kernel problem? (This
wasn't seen in the "normal" kernels.)
The large number of beagle entries in the logs is entirely separate and is well
understood --- mono is simply doing something which is legal, but tricky and
highly inefficient on xen kernels, so it gets logged.
The underlying problem seems to be the nvidia driver being incompatible with
Xen, and without nvidia source, there's simply nothing we can do to debug or fix