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 2.6.18-1.2849.fc6xen $ 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. How reproducible: 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 than later. 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 by yumex. 4. Reboot into new Xen kernel, and login. 5. Be presented with "some application has crashed and please report the bug" dialog. Actual results: See provided (attached?) crash / bug report. Expected results: Not to have the crash report. Additional info: 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? Thanks.
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. H/W info: Athlon 64 X2 5000+ on a MSI K9N Platinum SKT AM2 M/B, using an XFX NVidia 7600GS.
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 Installed Packages kmod-nvidia.i686 1.0.9742-1.2.6.18_1.28 installed kmod-nvidia-xen.i686 1.0.9742-1.2.6.18_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 re-produce. 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 something.
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 2.6.18-1.2849.fc6xen either. 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 /var/log/messages) 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 that.