Hi lists!
Any plans about kernel-xen package? Current 2.6.20 versions seem to crash and/or freeze (in dom0) for many people, making them completely unusable.
kernel-xen-2.6.18/19 packages seem to run fine on same hw.
One of the bugs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234008
Thanks!
-- Pasi
Funny, the current 2.6.20 fc5 kernel-xen actually *fixed* my problems that were introduced about 3 revisions ago....
On Tue, 10 Apr 2007, Pasi Kärkkäinen wrote:
Hi lists!
Any plans about kernel-xen package? Current 2.6.20 versions seem to crash and/or freeze (in dom0) for many people, making them completely unusable.
kernel-xen-2.6.18/19 packages seem to run fine on same hw.
One of the bugs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234008
Thanks!
-- Pasi
-- Fedora-xen mailing list Fedora-xen@redhat.com https://www.redhat.com/mailman/listinfo/fedora-xen
On Tue, Apr 10, 2007, Ben wrote:
Funny, the current 2.6.20 fc5 kernel-xen actually *fixed* my problems that were introduced about 3 revisions ago....
Is anyone running 2.6.19-1.2911.6.5.fc6 Xen? I'm going to give this a try and see how stable things become (read: can I bring up a domU or copy some data over the network without oopsing..)
Adrian
On Wed, Apr 11, 2007 at 08:31:55AM +0800, Adrian Chadd wrote:
On Tue, Apr 10, 2007, Ben wrote:
Funny, the current 2.6.20 fc5 kernel-xen actually *fixed* my problems that were introduced about 3 revisions ago....
Is anyone running 2.6.19-1.2911.6.5.fc6 Xen? I'm going to give this a try and see how stable things become (read: can I bring up a domU or copy some data over the network without oopsing..)
I've run 2.6.19 and it is definitely alot more stable than the 2.6.20 build of the Xen kernels. You should be able to use it quite successfully.
Regards, Dan.
Adrian Chadd wrote:
On Tue, Apr 10, 2007, Ben wrote:
Funny, the current 2.6.20 fc5 kernel-xen actually *fixed* my problems that were introduced about 3 revisions ago....
Is anyone running 2.6.19-1.2911.6.5.fc6 Xen? I'm going to give this a try and see how stable things become (read: can I bring up a domU or copy some data over the network without oopsing..)
2.6.19-xx works fine for me. I had dom0 freeze with 2.6.20 xen kernels. I reverted back to 2.6.19 and things seem to be more stable and work nicely.
- Shashin.
Adrian
-- Fedora-xen mailing list Fedora-xen@redhat.com https://www.redhat.com/mailman/listinfo/fedora-xen
On Wed, Apr 11, 2007, Shashin Shinde wrote:
2.6.19-xx works fine for me. I had dom0 freeze with 2.6.20 xen kernels. I reverted back to 2.6.19 and things seem to be more stable and work nicely.
It seems to be passing my initial burn-in tests fine; save for the 100% CPU /bin/nash process.
adrian
Adrian Chadd wrote:
On Wed, Apr 11, 2007, Shashin Shinde wrote:
2.6.19-xx works fine for me. I had dom0 freeze with 2.6.20 xen kernels. I reverted back to 2.6.19 and things seem to be more stable and work nicely.
It seems to be passing my initial burn-in tests fine; save for the 100% CPU /bin/nash process.
Perhaps you could run that debian system outsize of xen?
On Wed, Apr 11, 2007, John Summerfield wrote:
Adrian Chadd wrote:
On Wed, Apr 11, 2007, Shashin Shinde wrote:
2.6.19-xx works fine for me. I had dom0 freeze with 2.6.20 xen kernels. I reverted back to 2.6.19 and things seem to be more stable and work nicely.
It seems to be passing my initial burn-in tests fine; save for the 100% CPU /bin/nash process.
Perhaps you could run that debian system outsize of xen?
.. kinda defeats the purpose of running multiple virtual Linux servers inside Xen, eh? :)
Adrian
On Wed, 11 Apr 2007, Adrian Chadd wrote:
2.6.19-xx works fine for me. I had dom0 freeze with 2.6.20 xen kernels. I reverted back to 2.6.19 and things seem to be more stable and work nicely.
It seems to be passing my initial burn-in tests fine; save for the 100% CPU /bin/nash process.
Perhaps you could run that debian system outsize of xen?
.. kinda defeats the purpose of running multiple virtual Linux servers inside Xen, eh? :)
For older OS'es, you run into this 100% nash/hotplug issue. As a work around i use a "killall" in the rc.sysvinit script. I'm not sure what the real bug is, but I guess nash/hotplug are making some invalid assumptions about the capability of the kernel, and it should just abort instead of getting into this infinite loop.
Since the fix is easy, I never delved into what it is actually doing. If there is an interest in fixing this bug, I could investigate.
Paul
On Wed, Apr 11, 2007, Paul Wouters wrote:
For older OS'es, you run into this 100% nash/hotplug issue. As a work around i use a "killall" in the rc.sysvinit script. I'm not sure what the real bug is, but I guess nash/hotplug are making some invalid assumptions about the capability of the kernel, and it should just abort instead of getting into this infinite loop.
Since the fix is easy, I never delved into what it is actually doing. If there is an interest in fixing this bug, I could investigate.
Weirdly its with a fresh debootstrap'ed Debian etch (so not "old") Linux install under FC6; etch under FC5 with an older FC5 2.6.18 kernel doesn't trigger the nash CPU loop.
I'm running the Debian etch domU with the FC6 Xen kernel (and am putting the modules into the domU manually so things like xennet and iptables work for me) with the 2.6.19-1.2911.6.5.fc6xen kernel and a rebuild mkinitrd (ie, with xenblk.)
I'd be interested in finding out more about what its actually doing if only to understand things a little more.
Adrian
On Thu, 12 Apr 2007, Adrian Chadd wrote:
On Wed, Apr 11, 2007, Paul Wouters wrote:
For older OS'es, you run into this 100% nash/hotplug issue. As a work around i use a "killall" in the rc.sysvinit script. I'm not sure what the real bug is, but I guess nash/hotplug are making some invalid assumptions about the capability of the kernel, and it should just abort instead of getting into this infinite loop.
Since the fix is easy, I never delved into what it is actually doing. If there is an interest in fixing this bug, I could investigate.
Weirdly its with a fresh debootstrap'ed Debian etch (so not "old") Linux install under FC6; etch under FC5 with an older FC5 2.6.18 kernel doesn't trigger the nash CPU loop.
Maybe Debian is still using hotplug instead of udev? Try apt-get install udev
Paul
On Wed, Apr 11, 2007, Paul Wouters wrote:
Weirdly its with a fresh debootstrap'ed Debian etch (so not "old") Linux install under FC6; etch under FC5 with an older FC5 2.6.18 kernel doesn't trigger the nash CPU loop.
Maybe Debian is still using hotplug instead of udev? Try apt-get install udev
Already thought about that (and I've been bitten by the lack of udev in default installs of earlier Debians):
test-1:~# dpkg -l | grep udev ii udev 0.105-4 /dev/ and hotplug management daemon test-1:~# dpkg -l | grep hotplug ii udev 0.105-4 /dev/ and hotplug management daemon test-1:~# mount /dev/sda1 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
Adrian
On 4/11/07, Shashin Shinde sshinde@redhat.com wrote:
2.6.19-xx works fine for me. I had dom0 freeze with 2.6.20 xen kernels. I reverted back to 2.6.19 and things seem to be more stable and work nicely.
Same case with me, 2.6.20-xx kernel-xen freezes on both dom0 and demU, on other choice but to fallback to 2.6.19-xx.
Thanks. Askar
Hi!
2.6.20 also keeps crashing dom0 and domU here. Went back to 2.6.19, now it works again.
chris
-
Adrian Chadd -
Asrai khn -
Ben -
Christian Reiter -
Daniel P. Berrange -
John Summerfield -
Pasi Kärkkäinen -
Paul Wouters -
Shashin Shinde