Re: [Fedora-xen] mdadm fails to start raid in pv fc16 DomU on old host
Hi Konrad, Thanks for the heads up. My main motivation for just plugging the FC15 kernel into the FC14 machine(s) is that 3 of the hosts live in remote geographies. It's likely they'll probz live the rest of their lives as FC14 machines. The graphics adaptor is: 05:05.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) Thanks again. V On Thu, 29 Mar 2012 10:51:14 AM Konrad Rzeszutek Wilk wrote: > On Thu, Mar 29, 2012 at 01:38:38PM +1100, Virgil wrote: > > Hi Konrad, > > > > Firstly, thanks for the reply. > > > > What I've ended up doing is blindly forcing the FC15 kernel in. > > > > Linux rich.wwrich.xxx 2.6.42.9-2.fc15.x86_64 #1 SMP Mon Mar 5 20:55:32 > > UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > > > > This has worked and resolved by issue as the host is advertising flush > > diskcache. > > > > [1.051933] blkfront: xvda: flush diskcache: enabled > > [1.252959] xvda: xvda1 xvda2 > > [1.297201] blkfront: xvdb: flush diskcache: enabled > > [1.303110] xvdb: xvdb1 xvdb2 > > [1.565645] md: bind > > [1.668360] md: bind > > [1.691897] md: raid1 personality registered for level 1 > > [1.696683] bio: create slab at 1 > > [1.700177] md/raid1:md127: active with 2 out of 2 mirrors > > [1.701113] md127: detected capacity change from 0 to 7516180480 > > [1.974317] EXT4-fs (md127): mounted filesystem with ordered data > > mode. Opts: (null) [2.065875] dracut: Checking ext4: > > /dev/disk/by-label/rootfs > > [2.067090] dracut: issuing e2fsck -a /dev/disk/by-label/rootfs > > [2.147305] dracut: rootfs: clean, 42918/454272 files, 417708/1835005 > > blocks [2.149062] dracut: Remounting /dev/disk/by-label/rootfs with > > -o ro [2.182952] EXT4-fs (md127): mounted filesystem with ordered > > data mode. Opts: (null) [2.195483] dracut: Mounted root filesystem > > /dev/md127 > > [2.340884] dracut: Switching root > > > > As a side issue, I also recompiled Xen 4.1.2 on fc14 and installed it. > > Everything worked *except* libvirtd. No domU's listed. So I recompiled > > FC15's libvirtd too. No go. > I think the F16 has them fixed. > > > I just backed out. Only the FC15 kernel is left. All running well now. > > > > Oh and also the kernel works great on bare metal except, when under Xen, > > the graphics went nuts. Added nomodeset to overcomes this. > > Which graphics is this? Linux 3.3 has some new fixes for this so if you use > F17, the issue should disappear. > > > The last thing I might try is to recompile the FC15 kernel on an FC14 > > host to make it easy to install via rpm (assuming it can compile). > > > > On Mon, 26 Mar 2012 01:17:49 PM Konrad Rzeszutek Wilk wrote: > > > On Mon, Mar 19, 2012 at 01:35:19PM +1100, Virgil wrote: > > > > I'm having a problem with mdraid running in a DomU. The issue is > > > > that > > > > mdraid declares one leg of the raid to have failed (when there's > > > > actually nothing wrong). > > > > > > > > DomU is fc16 - 3.2.2-1.fc16.x86_64 > > > > Dom0 is fc14 - 2.6.32.26-174.2.xendom0.fc12.x86_64 > > > > > > > > The same DomU running on Dom0 fc16 - 3.2.7-1.fc16.x86_64 runs > > > > perfectly. > > > > > > > > This appears to be a known issue, however the resolution (which > > > > seems to be to disable barriers on the fly) doesn't seem to > > > > work in this case.> > > > > hm, that is true - it wouldn't as the workarounds are for > > > filesystems. > > > > > > But perhaps - is there a way to turn barriers of in the raid system? > > > > > > > My question is: Is it possible to pass a parameter to the > > > > blkfront > > > > driver to ask it not to enable barrier during initialization? or > > > > is > > > > there another work around? > > > > > > Not that I know of. You could back-port the proper fix to 2.6.32 > > > (or just "Fix" the older 2.6.32 to not advetise feature-barrier). > > > > > > > [1.033058] blkfront: xvda: barrier: enabled > > > > [1.099153] xvda: xvda1 xvda2 > > > > [1.102871] blkfront: xvdb: barrier: enabled > > > > [1.130876] xvdb: xvdb1 xvdb2 > > > > [1.292692] md: bind > > > > [1.413416] md: bind > > > > [1.419411] md: raid1 personality registered for level 1 > > > > [1.419836] bio:
Re: [Fedora-xen] mdadm fails to start raid in pv fc16 DomU on old host
Hi Konrad, Firstly, thanks for the reply. What I've ended up doing is blindly forcing the FC15 kernel in. Linux rich.wwrich.xxx 2.6.42.9-2.fc15.x86_64 #1 SMP Mon Mar 5 20:55:32 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux This has worked and resolved by issue as the host is advertising flush diskcache. [1.051933] blkfront: xvda: flush diskcache: enabled [1.252959] xvda: xvda1 xvda2 [1.297201] blkfront: xvdb: flush diskcache: enabled [1.303110] xvdb: xvdb1 xvdb2 [1.565645] md: bind [1.668360] md: bind [1.691897] md: raid1 personality registered for level 1 [1.696683] bio: create slab at 1 [1.700177] md/raid1:md127: active with 2 out of 2 mirrors [1.701113] md127: detected capacity change from 0 to 7516180480 [1.974317] EXT4-fs (md127): mounted filesystem with ordered data mode. Opts: (null) [2.065875] dracut: Checking ext4: /dev/disk/by-label/rootfs [2.067090] dracut: issuing e2fsck -a /dev/disk/by-label/rootfs [2.147305] dracut: rootfs: clean, 42918/454272 files, 417708/1835005 blocks [2.149062] dracut: Remounting /dev/disk/by-label/rootfs with -o ro [2.182952] EXT4-fs (md127): mounted filesystem with ordered data mode. Opts: (null) [2.195483] dracut: Mounted root filesystem /dev/md127 [2.340884] dracut: Switching root As a side issue, I also recompiled Xen 4.1.2 on fc14 and installed it. Everything worked *except* libvirtd. No domU's listed. So I recompiled FC15's libvirtd too. No go. I just backed out. Only the FC15 kernel is left. All running well now. Oh and also the kernel works great on bare metal except, when under Xen, the graphics went nuts. Added nomodeset to overcomes this. The last thing I might try is to recompile the FC15 kernel on an FC14 host to make it easy to install via rpm (assuming it can compile). On Mon, 26 Mar 2012 01:17:49 PM Konrad Rzeszutek Wilk wrote: > On Mon, Mar 19, 2012 at 01:35:19PM +1100, Virgil wrote: > > I'm having a problem with mdraid running in a DomU. The issue is that > > mdraid declares one leg of the raid to have failed (when there's > > actually nothing wrong). > > > > DomU is fc16 - 3.2.2-1.fc16.x86_64 > > Dom0 is fc14 - 2.6.32.26-174.2.xendom0.fc12.x86_64 > > > > The same DomU running on Dom0 fc16 - 3.2.7-1.fc16.x86_64 runs perfectly. > > > > This appears to be a known issue, however the resolution (which seems to > > be to disable barriers on the fly) doesn't seem to work in this case. > > hm, that is true - it wouldn't as the workarounds are for filesystems. > > But perhaps - is there a way to turn barriers of in the raid system? > > > My question is: Is it possible to pass a parameter to the blkfront > > driver to ask it not to enable barrier during initialization? or is > > there another work around? > > Not that I know of. You could back-port the proper fix to 2.6.32 > (or just "Fix" the older 2.6.32 to not advetise feature-barrier). > > > [1.033058] blkfront: xvda: barrier: enabled > > [1.099153] xvda: xvda1 xvda2 > > [1.102871] blkfront: xvdb: barrier: enabled > > [1.130876] xvdb: xvdb1 xvdb2 > > [1.292692] md: bind > > [1.413416] md: bind > > [1.419411] md: raid1 personality registered for level 1 > > [1.419836] bio: create slab at 1 > > [1.419953] md/raid1:md127: active with 2 out of 2 mirrors > > [1.419992] md127: detected capacity change from 0 to 7516180480 > > [1.424562] md127: unknown partition table > > [1.547284] EXT4-fs (md127): barriers disabled > > [1.553107] EXT4-fs (md127): mounted filesystem with ordered data > > mode. Opts: (null) > > [1.669483] dracut: Checking ext4: /dev/disk/by-label/rootfs > > [1.669592] dracut: issuing e2fsck -a /dev/disk/by-label/rootfs > > [1.690595] blkfront: barrier: empty write xvdb op failed > > [1.690611] blkfront: xvdb: barrier or flush: disabled > > [1.690628] end_request: I/O error, dev xvdb, sector 14682096 > > [1.690638] end_request: I/O error, dev xvdb, sector 14682096 > > [1.690646] md: super_written gets error=-5, uptodate=0 > > [1.690655] md/raid1:md127: Disk failure on xvdb1, disabling device. > > [1.690657] md/raid1:md127: Operation continuing on 1 devices. > > [1.690677] blkfront: barrier: empty write xvda op failed > > [1.690684] blkfront: xvda: barrier or flush: disabled > > [1.690696] end_request: I/O error, dev xvda, sector 14682096 > > [1.690705] end_request: I/O error, dev xvda, sector 14682096 > > [1.690713] md: super_written gets error=-5, uptodate=0 > > [1.692991] RAID1 conf printout: > > [1.692997] --- wd:1 rd:2 > > [1.69300
[Fedora-xen] mdadm fails to start raid in pv fc16 DomU on old host
I'm having a problem with mdraid running in a DomU. The issue is that mdraid declares one leg of the raid to have failed (when there's actually nothing wrong). DomU is fc16 - 3.2.2-1.fc16.x86_64 Dom0 is fc14 - 2.6.32.26-174.2.xendom0.fc12.x86_64 The same DomU running on Dom0 fc16 - 3.2.7-1.fc16.x86_64 runs perfectly. This appears to be a known issue, however the resolution (which seems to be to disable barriers on the fly) doesn't seem to work in this case. My question is: Is it possible to pass a parameter to the blkfront driver to ask it not to enable barrier during initialization? or is there another work around? [1.033058] blkfront: xvda: barrier: enabled [1.099153] xvda: xvda1 xvda2 [1.102871] blkfront: xvdb: barrier: enabled [1.130876] xvdb: xvdb1 xvdb2 [1.292692] md: bind [1.413416] md: bind [1.419411] md: raid1 personality registered for level 1 [1.419836] bio: create slab at 1 [1.419953] md/raid1:md127: active with 2 out of 2 mirrors [1.419992] md127: detected capacity change from 0 to 7516180480 [1.424562] md127: unknown partition table [1.547284] EXT4-fs (md127): barriers disabled [1.553107] EXT4-fs (md127): mounted filesystem with ordered data mode. Opts: (null) [1.669483] dracut: Checking ext4: /dev/disk/by-label/rootfs [1.669592] dracut: issuing e2fsck -a /dev/disk/by-label/rootfs [1.690595] blkfront: barrier: empty write xvdb op failed [1.690611] blkfront: xvdb: barrier or flush: disabled [1.690628] end_request: I/O error, dev xvdb, sector 14682096 [1.690638] end_request: I/O error, dev xvdb, sector 14682096 [1.690646] md: super_written gets error=-5, uptodate=0 [1.690655] md/raid1:md127: Disk failure on xvdb1, disabling device. [1.690657] md/raid1:md127: Operation continuing on 1 devices. [1.690677] blkfront: barrier: empty write xvda op failed [1.690684] blkfront: xvda: barrier or flush: disabled [1.690696] end_request: I/O error, dev xvda, sector 14682096 [1.690705] end_request: I/O error, dev xvda, sector 14682096 [1.690713] md: super_written gets error=-5, uptodate=0 [1.692991] RAID1 conf printout: [1.692997] --- wd:1 rd:2 [1.693002] disk 0, wo:0, o:1, dev:xvda1 [1.693006] disk 1, wo:1, o:0, dev:xvdb1 [1.693010] RAID1 conf printout: [1.693013] --- wd:1 rd:2 [1.693016] disk 0, wo:0, o:1, dev:xvda1 [1.702896] dracut: rootfs: clean, 25635/454272 files, 293967/1835005 blocks [1.703682] dracut: Remounting /dev/disk/by-label/rootfs with -o ro [1.773347] EXT4-fs (md127): barriers disabled [1.774552] EXT4-fs (md127): mounted filesystem with ordered data mode. Opts: (null) [1.797159] dracut: Mounted root filesystem /dev/md127 [1.937620] dracut: Switching root -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] DomU nat router fails when DomUs on same host
Hi List, I have a strange issue someone, hopefully, can advise me on. I have two external connections into a host: em1 is behind a firewall machine which is connected to an internet backbone link, while em2 is an adsl all-u- can-eat deal with a cheap router. Both are bridged. So there's pem1 and pem2 which are connected to the em1 and em2 bridges respectively. There is a domU router which nats (and is connected to both bridges). Some domU servers (a variety of fc6 to fc16 32 and 64) default route to the domU router and go out the all-u-can-eat link. The issue is, I recent upgraded the host from Fedora8 to Fedora16, and now the domU machines that once happily used the all-u-can-eat link, no longer can. However, in an act of desperation, I moved one of the domUs to a backup machine. Nothing else changed. Bingo. That domU works. All resources are still on the original machine (i.e. the DB servers, the router, etc. etc.). It seems that the router does't seem to nat domUs on the same host. You move the domU off with comms going via em1 to another host and it works. Iptraf tracing seems to indicate that the TCP connection is setup. The first packet goes off and is acked. Then everything stops and eventually the tcp connection closes on the router, but the domU and the remote computer think the link is still up (at least that's what I think is happening). The domU's send queue ends up with lots of data in it according to 'netstat -ant' Only nat'd tcp connections are effected. Connections to machines on the same bridge work fine. Does this sound familiar to anyone? Thanks in advance Virgil -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] fedora 16 with xen balloning.
AAAhhhh Noun: BALLOON! Verb: BALLOONING! V On Fri, 30 Sep 2011 08:56:28 AM Konrad Rzeszutek Wilk wrote: > On Wed, Sep 28, 2011 at 08:03:37PM -0300, Itamar Reis Peixoto wrote: > > On Wed, Sep 28, 2011 at 7:59 PM, Konrad Rzeszutek Wilk > > > > wrote: > > > On Wed, Sep 28, 2011 at 06:33:52PM -0300, Itamar Reis Peixoto wrote: > > >> On Wed, Sep 28, 2011 at 6:18 PM, Konrad Rzeszutek Wilk > > >> > > >> wrote: > > >> > Ok, did 'xl list' show a new value? What does this command give > > >> > you: > > >> > > > >> > find /sys -name target_kb | xargs cat > > >> > > >> [root@localhost ~]# find /sys -name target_kb | xargs cat > > >> 3670016 > > > > > > Ok, so 3.6GB at start. > > > > > >> while (true) > > >> do > > >> xl list | grep Domain-0 > > >> done > > >> > > >> I am able to see the numbers going down, and after some time > > >> stop.(freeze) > > > > > > And ... how low? > > > > last message I was able to see is at 2260 > > So I did the same test on my 4GB box and found out that 'xm mem-set 0 1024' > xend helpfully () decreased the memory to 214MB. Which will > definitly cause head-ache for programs. > > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.32 dom0 kernel
Just did: rpm -Uvh --oldpackage * The upgrade deleted all previous kernels (/lib/modules and all) on the F14 test box. It got the grub.conf wrong (we're booting off raid). Manually fixed the grub.conf and life goes on. Cheers V. On Fri, 25 Mar 2011 07:57:05 AM M A Young wrote: > I have built a new 2.6.32 kernel, based on my Fedora 12 kernels, but with > updates to the latest 2.6.32 kernel patch (2.6.32.34 with the extra patch > to make it equivalent to 2.6.32.35) and latest xen next-2.6.32 patch. It > was built on Fedora 13. It is available (temporarily) from koji at > http://koji.fedoraproject.org/koji/taskinfo?taskID=2940510 and from my > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ > > Michael Young > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.32.x dom0 kernel
Feb 23rd here in Australia. The system is still running flawlessly since turning off all power saving in the BIOS. Looks like the power saving stuff in the BIOS for AMD processors could be the issue with the clocksource. Cheers V On Fri, 24 Dec 2010 02:10:54 pm Virgil wrote: > Just a quick pre-xmas report: > > Since turning off all power saving in the BIOS, everything has worked > flawlessly (now that I've emailed this I'm sure the entire system will > blow up). > > So far so good. > > Cheers and merry Xmas > V. > > On Wed, 15 Dec 2010 01:56:31 pm Virgil wrote: > > Hi Pasi, > > > > I gave up on the idea of using jiffies as the clocksource. > > > > I was unable to get ntpd to lock onto any time sources with clocksource > > set to jiffies. The jitter and offsets just went crazy. > > > > I'm now turning off all power saving in the bios and reverting to the > > default clocksource. I read that the xen time source attempts to do > > "stuff" if it reckons some ticks went missing. Apparently a cause of > > missing TSC ticks can be going to sleep on some CPUs who knows. > > Something to do with the max_cstate. > > > > Cheers > > V > > > > On Tue, 14 Dec 2010 06:07:57 am Pasi Kärkkäinen wrote: > > > On Mon, Dec 13, 2010 at 11:30:35AM +1100, Virgil wrote: > > > > Found this in /var/log/messages as the last thing prior to death. > > > > > > > > Clocksource tsc unstable > > > > > > > > Did some Googling and found some people changed the dom0 clocksource. > > > > > > > > Added clocksource=jiffies to the kernel commandline. > > > > > > I believe jiffies is not a very good clocksource.. > > > > > > -- Pasi > > > > > > > Will see if it does anything. > > > > > > > > V > > > > > > > > On Wed, 17 Nov 2010 12:00:01 pm Virgil wrote: > > > > > Host crashed. Running HVM fc14-32. > > > > > > > > > > Skipping 86000 seconds. > > > > > Skipping 86000 seconds. > > > > > Skipping 86000 seconds. > > > > > Skipping 86000 seconds. > > > > > Skipping 86000 seconds. > > > > > Skipping 86000 seconds. > > > > > Skipping 86000 seconds. > > > > > ... > > > > > ... > > > > > ... > > > > > ... > > > > > Kaboom > > > > > > > > > > Cheers > > > > > V > > > > > > > > > > On Mon, 8 Nov 2010 07:43:36 am M A Young wrote: > > > > > > I have built another 2.6.32.x based kernel > > > > > > (2.6.32.25-172.xendom0.fc12) at > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and > > > > > > the repository > > > > > > http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ . This > > > > > > updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may > > > > > > not actually change anything), and uses a later version of > > > > > > xen/stable-2.6.3.32.x which adds a couple of xen fixes. > > > > > > > > > > > > Michael Young > > > > > > > > > > > > -- > > > > > > xen mailing list > > > > > > xen@lists.fedoraproject.org > > > > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > > > > > > > -- > > > > > xen mailing list > > > > > xen@lists.fedoraproject.org > > > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > > > > > -- > > > > xen mailing list > > > > xen@lists.fedoraproject.org > > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > -- > > xen mailing list > > xen@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/xen > > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.32.x dom0 kernel
Just a quick pre-xmas report: Since turning off all power saving in the BIOS, everything has worked flawlessly (now that I've emailed this I'm sure the entire system will blow up). So far so good. Cheers and merry Xmas V. On Wed, 15 Dec 2010 01:56:31 pm Virgil wrote: > Hi Pasi, > > I gave up on the idea of using jiffies as the clocksource. > > I was unable to get ntpd to lock onto any time sources with clocksource set > to jiffies. The jitter and offsets just went crazy. > > I'm now turning off all power saving in the bios and reverting to the > default clocksource. I read that the xen time source attempts to do > "stuff" if it reckons some ticks went missing. Apparently a cause of > missing TSC ticks can be going to sleep on some CPUs who knows. > Something to do with the max_cstate. > > Cheers > V > > On Tue, 14 Dec 2010 06:07:57 am Pasi Kärkkäinen wrote: > > On Mon, Dec 13, 2010 at 11:30:35AM +1100, Virgil wrote: > > > Found this in /var/log/messages as the last thing prior to death. > > > > > > Clocksource tsc unstable > > > > > > Did some Googling and found some people changed the dom0 clocksource. > > > > > > Added clocksource=jiffies to the kernel commandline. > > > > I believe jiffies is not a very good clocksource.. > > > > -- Pasi > > > > > Will see if it does anything. > > > > > > V > > > > > > On Wed, 17 Nov 2010 12:00:01 pm Virgil wrote: > > > > Host crashed. Running HVM fc14-32. > > > > > > > > Skipping 86000 seconds. > > > > Skipping 86000 seconds. > > > > Skipping 86000 seconds. > > > > Skipping 86000 seconds. > > > > Skipping 86000 seconds. > > > > Skipping 86000 seconds. > > > > Skipping 86000 seconds. > > > > ... > > > > ... > > > > ... > > > > ... > > > > Kaboom > > > > > > > > Cheers > > > > V > > > > > > > > On Mon, 8 Nov 2010 07:43:36 am M A Young wrote: > > > > > I have built another 2.6.32.x based kernel > > > > > (2.6.32.25-172.xendom0.fc12) at > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the > > > > > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ > > > > > . This updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which > > > > > may not actually change anything), and uses a later version of > > > > > xen/stable-2.6.3.32.x which adds a couple of xen fixes. > > > > > > > > > > Michael Young > > > > > > > > > > -- > > > > > xen mailing list > > > > > xen@lists.fedoraproject.org > > > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > > > > > -- > > > > xen mailing list > > > > xen@lists.fedoraproject.org > > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > > > -- > > > xen mailing list > > > xen@lists.fedoraproject.org > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.32.x dom0 kernel
Hi Pasi, I gave up on the idea of using jiffies as the clocksource. I was unable to get ntpd to lock onto any time sources with clocksource set to jiffies. The jitter and offsets just went crazy. I'm now turning off all power saving in the bios and reverting to the default clocksource. I read that the xen time source attempts to do "stuff" if it reckons some ticks went missing. Apparently a cause of missing TSC ticks can be going to sleep on some CPUs who knows. Something to do with the max_cstate. Cheers V On Tue, 14 Dec 2010 06:07:57 am Pasi Kärkkäinen wrote: > On Mon, Dec 13, 2010 at 11:30:35AM +1100, Virgil wrote: > > Found this in /var/log/messages as the last thing prior to death. > > > > Clocksource tsc unstable > > > > Did some Googling and found some people changed the dom0 clocksource. > > > > Added clocksource=jiffies to the kernel commandline. > > I believe jiffies is not a very good clocksource.. > > -- Pasi > > > Will see if it does anything. > > > > V > > > > On Wed, 17 Nov 2010 12:00:01 pm Virgil wrote: > > > Host crashed. Running HVM fc14-32. > > > > > > Skipping 86000 seconds. > > > Skipping 86000 seconds. > > > Skipping 86000 seconds. > > > Skipping 86000 seconds. > > > Skipping 86000 seconds. > > > Skipping 86000 seconds. > > > Skipping 86000 seconds. > > > ... > > > ... > > > ... > > > ... > > > Kaboom > > > > > > Cheers > > > V > > > > > > On Mon, 8 Nov 2010 07:43:36 am M A Young wrote: > > > > I have built another 2.6.32.x based kernel > > > > (2.6.32.25-172.xendom0.fc12) at > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the > > > > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ . > > > > This updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may > > > > not actually change anything), and uses a later version of > > > > xen/stable-2.6.3.32.x which adds a couple of xen fixes. > > > > > > > > Michael Young > > > > > > > > -- > > > > xen mailing list > > > > xen@lists.fedoraproject.org > > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > > > -- > > > xen mailing list > > > xen@lists.fedoraproject.org > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > -- > > xen mailing list > > xen@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.32.x dom0 kernel
Found this in /var/log/messages as the last thing prior to death. Clocksource tsc unstable Did some Googling and found some people changed the dom0 clocksource. Added clocksource=jiffies to the kernel commandline. Will see if it does anything. V On Wed, 17 Nov 2010 12:00:01 pm Virgil wrote: > Host crashed. Running HVM fc14-32. > > Skipping 86000 seconds. > Skipping 86000 seconds. > Skipping 86000 seconds. > Skipping 86000 seconds. > Skipping 86000 seconds. > Skipping 86000 seconds. > Skipping 86000 seconds. > ... > ... > ... > ... > Kaboom > > Cheers > V > > On Mon, 8 Nov 2010 07:43:36 am M A Young wrote: > > I have built another 2.6.32.x based kernel (2.6.32.25-172.xendom0.fc12) > > at http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the > > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ . > > This updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may not > > actually change anything), and uses a later version of > > xen/stable-2.6.3.32.x which adds a couple of xen fixes. > > > > Michael Young > > > > -- > > xen mailing list > > xen@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/xen > > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.32.x dom0 kernel
Host crashed. Running HVM fc14-32. Skipping 86000 seconds. Skipping 86000 seconds. Skipping 86000 seconds. Skipping 86000 seconds. Skipping 86000 seconds. Skipping 86000 seconds. Skipping 86000 seconds. ... ... ... ... Kaboom Cheers V On Mon, 8 Nov 2010 07:43:36 am M A Young wrote: > I have built another 2.6.32.x based kernel (2.6.32.25-172.xendom0.fc12) at > http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ . This > updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may not actually > change anything), and uses a later version of xen/stable-2.6.3.32.x which > adds a couple of xen fixes. > > Michael Young > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] 2.6.32.x dom0 kernel
(Xen) Platform timer appears to have unexpectedly wrapped 10 or more times Kaboom! Zz. 2.6.32.25-172.xendom0.fc12 FC14 everything else. Cheers V On Mon, 8 Nov 2010 07:43:36 am M A Young wrote: > I have built another 2.6.32.x based kernel (2.6.32.25-172.xendom0.fc12) at > http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ . This > updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may not actually > change anything), and uses a later version of xen/stable-2.6.3.32.x which > adds a couple of xen fixes. > > Michael Young > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] another xen kernel
kernel-2.6.32.25-171.rc1.xendom0.fc12 RTC went mad. 1 sec = 1mS Top was showing hours whizzing past in minutes. Windows VM went crazy doing stuff. FC13 VM went crazy too doing all sorts of things really quickly. Bizzare effect. Went back to -168 kernel. Alls well again. Cheers V96 On Sun, 24 Oct 2010 03:50:40 am M A Young wrote: > On Fri, 22 Oct 2010, Itamar Reis Peixoto wrote: > > On Fri, Oct 22, 2010 at 7:27 PM, M A Young wrote: > >> There is a new xen kernel (2.6.32.23-170.1.xendom0.fc12) available to > >> download at http://koji.fedoraproject.org/koji/taskinfo?taskID=2547470 > >> and at the repository > >> http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ > >> > >> It contains some patches added added to xen/stable-2.6.32.x since the > >> last build, including an event channels fix. > >> > >>Michael Young > > > > take a look > > > > https://bugzilla.redhat.com/show_bug.cgi?id=645252#c2 > > Try xen kernel-2.6.32.25-171.rc1.xendom0.fc12 instead at > http://koji.fedoraproject.org/koji/taskinfo?taskID=2550132 or at the > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ which > has a fix for that and another security hole. > > Michael Young -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] another xen build
xen-4.0.1-6.fc12 (recompiled under FC12) likewise seems to resolve all issues here. Fingers crossed, so far so good. Cheers V On Sun, 17 Oct 2010 10:32:12 pm Pasi Kärkkäinen wrote: > On Thu, Oct 14, 2010 at 04:32:20PM +0100, M A Young wrote: > > On Wed, 13 Oct 2010, M A Young wrote: > > > On Wed, 13 Oct 2010, fcxen user wrote: > > >> How can we increase the karma? I can add some... > > > > > > You can vote on xen-4.0.1-5.fc14 at > > > https://admin.fedoraproject.org/updates/xen-4.0.1-5.fc14 > > > though you may need to be logged in for your vote to count. > > > > xen-4.0.1-5.fc14 got enough karma and made it into the F14 release and I > > have now submitted xen-4.0.1-6.fc14 for updates-testing. > > > > Please test it (it is available from > > http://koji.fedoraproject.org/koji/buildinfo?buildID=200238 and will be > > in updates-testing soon) and consider reporting your results at > > https://admin.fedoraproject.org/updates/xen-4.0.1-6.fc14 > > as it may still be possible to get it into the F14 release. > > 4.0.1-6.fc14 works for me! > > -- Pasi > > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] xen and dom0 kernel builds
Further to the previous email regarding diskio stats: It appears the ksysguardd is no longer able to gather stats either. I'm suspecting a bug in the kernel and not libvirtd. Cheers V On Sat, 25 Sep 2010 08:02:00 am M A Young wrote: > I have built a new kernel (kernel-2.6.32.21-168.xendom0.fc12) at > http://koji.fedoraproject.org/koji/taskinfo?taskID=2477887 or at the > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ > It includes fixes for the recent x86_64 local root exploit. > > There are also some new builds of xen. The Fedora packages > xen-4.0.1-3.fc15 and xen-4.0.1-3.fc14 available via > http://koji.fedoraproject.org/koji/packageinfo?packageID=7 have some IRQ > fixes that solve a problem I was having with a keyboard and mouse and the > patch that disables xsave which was causing problems with HVM (both these > are from 4.0.2-rc1-pre). It also creates a symbolic link for qemu-dm from > the place it was in 3.4.x to where it is in 4.0.x for compatibility. > > I also have a temporary test build xen-4.0.1-1.fc13.1 for Fedora 13 at > http://koji.fedoraproject.org/koji/taskinfo?taskID=2478501 . This is > slightly misnamed as it is actually of 4.0.2-rc1-pre and includes the > fixes above. Note that he build system will delete those RPMs > automatically after a week or so. > > Michael Young > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] xen and dom0 kernel builds
Quick question: Should the libvirt stuff be updated? Sep 27 10:47:41 seanl64 libvirtd: 10:47:41.234: error : statsErrorFunc:60 : internal error read_bd_stats: Failed to read any block statistics libvirt-client-0.8.2-1.fc12.x86_64 libvirt-python-0.8.2-1.fc12.x86_64 libvirt-0.8.2-1.fc12.x86_64 xen-runtime-4.0.1-1.fc12.1.x86_64 xen-devel-4.0.1-1.fc12.1.x86_64 xen-libs-4.0.1-1.fc12.1.x86_64 xen-debuginfo-4.0.1-1.fc12.1.x86_64 xen-4.0.1-1.fc12.1.x86_64 xen-doc-4.0.1-1.fc12.1.x86_64 xen-hypervisor-4.0.1-1.fc12.1.x86_64 Linux seanl64.xx.xx.xx 2.6.32.21-168.xendom0.fc12.x86_64 #1 SMP Mon Sep 20 19:32:37 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Cheers Virgil On Sat, 25 Sep 2010 08:02:00 am M A Young wrote: > I have built a new kernel (kernel-2.6.32.21-168.xendom0.fc12) at > http://koji.fedoraproject.org/koji/taskinfo?taskID=2477887 or at the > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ > It includes fixes for the recent x86_64 local root exploit. > > There are also some new builds of xen. The Fedora packages > xen-4.0.1-3.fc15 and xen-4.0.1-3.fc14 available via > http://koji.fedoraproject.org/koji/packageinfo?packageID=7 have some IRQ > fixes that solve a problem I was having with a keyboard and mouse and the > patch that disables xsave which was causing problems with HVM (both these > are from 4.0.2-rc1-pre). It also creates a symbolic link for qemu-dm from > the place it was in 3.4.x to where it is in 4.0.x for compatibility. > > I also have a temporary test build xen-4.0.1-1.fc13.1 for Fedora 13 at > http://koji.fedoraproject.org/koji/taskinfo?taskID=2478501 . This is > slightly misnamed as it is actually of 4.0.2-rc1-pre and includes the > fixes above. Note that he build system will delete those RPMs > automatically after a week or so. > > Michael Young > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] xen 4.0.1-rc6
FYI Stability with: Linux seanl64. 2.6.32.17-157.xendom0.fc12.x86_64 #1 SMP Sat Aug 7 15:26:59 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux kernel-devel-2.6.32.17-157.xendom0.fc12.x86_64 kernel-2.6.32.17-157.xendom0.fc12.x86_64 kernel-firmware-2.6.32.17-157.xendom0.fc12.noarch kernel-headers-2.6.32.17-157.xendom0.fc12.x86_64 xen-4.0.1-0.1.rc5.fc12.x86_64 xen-doc-4.0.1-0.1.rc5.fc12.x86_64 xen-hypervisor-4.0.1-0.1.rc5.fc12.x86_64 xen-devel-4.0.1-0.1.rc5.fc12.x86_64 xen-libs-4.0.1-0.1.rc5.fc12.x86_64 xen-debuginfo-4.0.1-0.1.rc5.fc12.x86_64 xen-runtime-4.0.1-0.1.rc5.fc12.x86_64 All stable. WinXP issue went away. System has been running for: 11:02:38 up 6 days, 23:08, 2 users, load average: 0.10, 0.40, 0.68 with various HV and PV machines. Loading up xen 4.0.1-rc6 now. Cheers V On Sat, 14 Aug 2010 05:47:22 am M A Young wrote: > If anyone wants to test xen 4.0.1-rc6 I have done a build for F13 at > http://koji.fedoraproject.org/koji/taskinfo?taskID=2400559 > > Michael Young > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] xen 4.0.1-rc4
Host lockup.
Hi Guys, disaster after starting a WindowsXP Pro HVM. Came back this morning to
find a dead host.
Here's the output from the XEN serial port relating to the 3 domU's running. 2
are running Fedora 12 and 13. These had been running for 4 days prior to
starting the WinXP machine.
(XEN) HVM24: Press F12 for boot menu.
(XEN) HVM24:
(XEN) HVM24: Booting from Hard Disk...
(XEN) HVM24: Booting from :7c00
(XEN) HVM24: int13_harddisk: function 15, unmapped device for ELDL=81
(XEN) HVM24: *** int 15h function AX=e980, BX=0066 not yet supported!
(XEN) stdvga.c:151:d24 leaving stdvga
(XEN) common.c:3680:d0 tracking VRAM f - f0240
(XEN) rtc.c:296: HVM RTC: dom 20 skipping 1683627048 seconds
(XEN) rtc.c:296: HVM RTC: dom 24 skipping 1683627051 seconds
(XEN) rtc.c:296: HVM RTC: dom 23 skipping 1683627051 seconds
Versions of stuff:
Linux seanl64.xx.com.au 2.6.32.16-1.2.108.xendom0.fc12.x86_64 #1 SMP Mon
Jul 12 21:40:43 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
__ __
\ \/ /___ _ __
\ // _ \ '_ \
/ \ __/ | | |
/_/\_\___|_| |_|
_ ____ _ _ _ ___ __ _ __ _
| || | / _ \ / | _ __ ___| || | / _ \ / | _ __ ___| || | / _| ___/ |
| || |_| | | || |__| '__/ __| || |_ __| | | || | | '__/ __| || |_ | |_ / __| |
|__ _| |_| || |__| | | (__|__ _|__| |_| || |_| | | (__|__ _|| _| (__| |
|_|(_)___(_)_| |_| \___| |_| \___(_)_(_)_| \___| |_|(_)_| \___|_|
|___ \
__) |
/ __/
|_|
(XEN) Xen version 4.0.1-rc4 (root@) (gcc version 4.4.3 20100127 (Red Hat
4.4.3-4) (GCC) ) Mon Jul 19 17:01:55 EST 2010
Cheers
V
On Tue, 20 Jul 2010 08:39:52 pm Pasi Kärkkäinen wrote:
> On Mon, Jul 19, 2010 at 10:43:37AM +0100, M A Young wrote:
> > On Mon, 19 Jul 2010, Pasi Kärkkäinen wrote:
> >> On Fri, Jul 16, 2010 at 09:12:25PM +0100, M A Young wrote:
> >>> If anyone wants to test xen 4.0.1-rc4, there are RPMs at
> >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=2324778 compiled for
> >>> Fedora 13
> >>
> >> Great, thanks!
> >>
> >> I was going to build them myself, but even better when you did it :)
> >> I'll test soon.
> >
> > Note that scratch builds on koji like that one have a limited lifespan,
> > and are deleted after something like 2 weeks so don't leave it too long
> > before downloading the rpms.
>
> Yep.
>
> Btw it might be a good idea to add something like the attached patch..
> xen-gntdev is required nowadays for pvfb, I think, and for blktap2 too.
>
> -- Pasi
--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] xen 3.4.3 SRPM / console problem
Host lockup OS is: Linux seanl64.xx.com 2.6.32.14-1.2.107.xendom0.fc12.x86_64 #1 SMP Wed Jun 16 19:26:35 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux xen-4.0.1-0.1.rc3.fc12.x86_64 livelock appears to be related to the network driver interrupt (source: from scanning the news groups). The network LED is flashing continuously, but the system is locked up from the console. We cannot SSH into the box anymore. Could this be related to interrupt priorities (don't know the hardware ins and outs of that). We have a serial captcha of the XEN output!! Here is the suspicious piece: (XEN) MCE: MSR 417 is not MCA MSR (XEN) traps.c:2854: GPF (): 82c4801ae806 -> 82c4801f7cb3 (XEN) vlapic.c:702:d13 Local APIC Write to read-only register 0x30 (XEN) vlapic.c:702:d13 Local APIC Write to read-only register 0x20 (XEN) vlapic.c:702:d13 Local APIC Write to read-only register 0x20 (XEN) irq.c:243: Dom13 PCI link 0 changed 5 -> 0 (XEN) irq.c:243: Dom13 PCI link 1 changed 10 -> 0 (XEN) irq.c:243: Dom13 PCI link 2 changed 11 -> 0 (XEN) irq.c:243: Dom13 PCI link 3 changed 5 -> 0 (XEN) rtc.c:296: HVM RTC: dom 2 skipping 1683748570 seconds (XEN) rtc.c:296: HVM RTC: dom 13 skipping 1683749071 seconds (XEN) rtc.c:296: HVM RTC: dom 2 skipping 86402 seconds (XEN) rtc.c:296: HVM RTC: dom 13 skipping 91586 seconds (XEN) rtc.c:296: HVM RTC: dom 2 skipping 86408 seconds (XEN) rtc.c:296: HVM RTC: dom 13 skipping 92211 seconds (XEN) rtc.c:296: HVM RTC: dom 13 skipping 86456 seconds (XEN) rtc.c:296: HVM RTC: dom 2 skipping 94532 seconds (XEN) rtc.c:296: HVM RTC: dom 2 skipping 86402 seconds (XEN) rtc.c:296: HVM RTC: dom 13 skipping 94742 seconds Note the "skipping 1683748570 seconds" which is more than 53 years. But we haven't had the computer switched on for that long :-) Cheers V On Thu, 1 Jul 2010 09:25:48 am Virgil wrote: > Update: > > Completely stable with 7 VMs. Hasn't missed a beat for several days now. > > Will now run the pings again in 2 of 64PV from the virtual consoles (no > graphics - and disconnected) and see if the host clock tick dies again. > > Cheers > V > > On Thu, 24 Jun 2010 03:17:51 pm Virgil wrote: > > Quick update: > > > > Added 3 more VMs. Total of 7 now on this "desktop" computer. > > > > 3x32PCFC6 > > 1x32HVFC12 > > 1x32HVwinXP-pro > > 2x64PVFC12 > > > > Host is maxed out now. > > > > Everything going well when the pings are not running in the 64PVFC12 > > machines. > > > > Will leave it going for another couple of days. > > > > Cheers > > V > > > > p.s. FYI Samba4-Alpha12 Active Directory controller is working well on > > 64PVFC12. > > > > On Wed, 23 Jun 2010 05:18:56 pm Virgil wrote: > > > On Wed, 23 Jun 2010 03:30:52 pm Pasi Kärkkäinen wrote: > > > > On Wed, Jun 23, 2010 at 11:11:58AM +1000, Virgil wrote: > > > > > Hi Pasi, > > > > > > > > > > Had a hiccup overnite: > > > > > > > > > > The host became unresponsive in a weird way. The time stopped > > > > > incrementing. > > > > > > > > > > Turns out the clock stopped ticking (which I put down to the > > > > > interrupts being disconnected). > > > > > > > > > > Anyway I decided I'd reset the time using 'time -s 10:41:30'. > > > > > > > > > > Kaboom, or actually deathly silence. The machine fully stopped dead > > > > > in its tracks. > > > > > > > > > > Just prior to this I connected to the console of one of the 64PV > > > > > machines which was just running a ping from yesterday. Anyway, > > > > > 60,000 or so lines of pings went to the console zipping up the > > > > > screen. Then it was dead. I did a CTRL-C and eventually it > > > > > returned to the prompt. > > > > > > > > > > So I looked at the other 64PV machine, which was also pining, and > > > > > identical situation. > > > > > > > > > > So I reckon, there's some kind of buffer overflow going on when > > > > > you're not "xm console MACHINE" connected. Once you pass 60,000 > > > > > lines of text this buffer overflow causes the RTC to hangup > > > > > somehow. > > > > > > > > Do you have xenconsoled running? > > > > > > > > I've noticed PV guests that print a lot to the console will stall if > > > > xenconsoled is not running.. xenconsoled needs to clear the guest > > > > console buffer.. > > &
Re: [Fedora-xen] xen 3.4.3 SRPM / console problem
Update: Completely stable with 7 VMs. Hasn't missed a beat for several days now. Will now run the pings again in 2 of 64PV from the virtual consoles (no graphics - and disconnected) and see if the host clock tick dies again. Cheers V On Thu, 24 Jun 2010 03:17:51 pm Virgil wrote: > Quick update: > > Added 3 more VMs. Total of 7 now on this "desktop" computer. > > 3x32PCFC6 > 1x32HVFC12 > 1x32HVwinXP-pro > 2x64PVFC12 > > Host is maxed out now. > > Everything going well when the pings are not running in the 64PVFC12 > machines. > > Will leave it going for another couple of days. > > Cheers > V > > p.s. FYI Samba4-Alpha12 Active Directory controller is working well on > 64PVFC12. > > On Wed, 23 Jun 2010 05:18:56 pm Virgil wrote: > > On Wed, 23 Jun 2010 03:30:52 pm Pasi Kärkkäinen wrote: > > > On Wed, Jun 23, 2010 at 11:11:58AM +1000, Virgil wrote: > > > > Hi Pasi, > > > > > > > > Had a hiccup overnite: > > > > > > > > The host became unresponsive in a weird way. The time stopped > > > > incrementing. > > > > > > > > Turns out the clock stopped ticking (which I put down to the > > > > interrupts being disconnected). > > > > > > > > Anyway I decided I'd reset the time using 'time -s 10:41:30'. > > > > > > > > Kaboom, or actually deathly silence. The machine fully stopped dead > > > > in its tracks. > > > > > > > > Just prior to this I connected to the console of one of the 64PV > > > > machines which was just running a ping from yesterday. Anyway, 60,000 > > > > or so lines of pings went to the console zipping up the screen. Then > > > > it was dead. I did a CTRL-C and eventually it returned to the prompt. > > > > > > > > So I looked at the other 64PV machine, which was also pining, and > > > > identical situation. > > > > > > > > So I reckon, there's some kind of buffer overflow going on when > > > > you're not "xm console MACHINE" connected. Once you pass 60,000 > > > > lines of text this buffer overflow causes the RTC to hangup somehow. > > > > > > Do you have xenconsoled running? > > > > > > I've noticed PV guests that print a lot to the console will stall if > > > xenconsoled is not running.. xenconsoled needs to clear the guest > > > console buffer.. > > > > > > -- Pasi > > > > Seems to be now. Pretty sure it was then too. > > > > udev-post 0:off 1:on2:on3:on4:on5:on6:off > > wpa_supplicant 0:off 1:off 2:off 3:off 4:off 5:off 6:off > > xenconsoled 0:off 1:off 2:off 3:on4:on5:on6:off > > xend0:off 1:off 2:off 3:on4:on5:on6:off > > xendomains 0:off 1:off 2:off 3:on4:on5:on6:off > > xenstored 0:off 1:off 2:off 3:on4:on5:on6:off > > ypbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off > > [r...@seanl64 ~]# ps -ef | grep xenconso > > root 1508 1 0 10:19 ?00:00:00 /usr/sbin/xenconsoled > > --log=none --log-dir=/var/log/xen/console root 7815 7732 0 17:07 > > pts/5 00:00:00 grep xenconso > > > > Cheers > > V > > > > > > I pressed the reset button, but this time the 2 64PV machines are not > > > > logged in. I'll just let it go and see if it keeps going. > > > > > > > > Cheers > > > > V > > > > > > > > On Tue, 22 Jun 2010 04:29:06 pm Pasi Kärkkäinen wrote: > > > > > On Tue, Jun 22, 2010 at 12:03:53PM +1000, Virgil wrote: > > > > > > Hi Pasi, > > > > > > > > > > > > On Mon, 21 Jun 2010 08:57:55 pm Pasi Kärkkäinen wrote: > > > > > > > On Mon, Jun 21, 2010 at 01:56:36PM +0300, Pasi Kärkkäinen wrote: > > > > > > > > On Mon, Jun 21, 2010 at 02:28:15PM +1000, Virgil wrote: > > > > > > > > > Another quick update > > > > > > > > > > > > > > > > > > xen-4.0.1-0.1.rc3.fc13.src.rpm just compiled this under > > > > > > > > > fc12. > > > > > > > > > > > > > > > > > > Identical results with this too (i.e. it's probably in the > > > > > > > > > kernel). > > > > > > > > > >
Re: [Fedora-xen] xen 3.4.3 SRPM / console problem
Quick update: Added 3 more VMs. Total of 7 now on this "desktop" computer. 3x32PCFC6 1x32HVFC12 1x32HVwinXP-pro 2x64PVFC12 Host is maxed out now. Everything going well when the pings are not running in the 64PVFC12 machines. Will leave it going for another couple of days. Cheers V p.s. FYI Samba4-Alpha12 Active Directory controller is working well on 64PVFC12. On Wed, 23 Jun 2010 05:18:56 pm Virgil wrote: > On Wed, 23 Jun 2010 03:30:52 pm Pasi Kärkkäinen wrote: > > On Wed, Jun 23, 2010 at 11:11:58AM +1000, Virgil wrote: > > > Hi Pasi, > > > > > > Had a hiccup overnite: > > > > > > The host became unresponsive in a weird way. The time stopped > > > incrementing. > > > > > > Turns out the clock stopped ticking (which I put down to the interrupts > > > being disconnected). > > > > > > Anyway I decided I'd reset the time using 'time -s 10:41:30'. > > > > > > Kaboom, or actually deathly silence. The machine fully stopped dead in > > > its tracks. > > > > > > Just prior to this I connected to the console of one of the 64PV > > > machines which was just running a ping from yesterday. Anyway, 60,000 > > > or so lines of pings went to the console zipping up the screen. Then > > > it was dead. I did a CTRL-C and eventually it returned to the prompt. > > > > > > So I looked at the other 64PV machine, which was also pining, and > > > identical situation. > > > > > > So I reckon, there's some kind of buffer overflow going on when you're > > > not "xm console MACHINE" connected. Once you pass 60,000 lines of text > > > this buffer overflow causes the RTC to hangup somehow. > > > > Do you have xenconsoled running? > > > > I've noticed PV guests that print a lot to the console will stall if > > xenconsoled is not running.. xenconsoled needs to clear the guest console > > buffer.. > > > > -- Pasi > > Seems to be now. Pretty sure it was then too. > > udev-post 0:off 1:on2:on3:on4:on5:on6:off > wpa_supplicant 0:off 1:off 2:off 3:off 4:off 5:off 6:off > xenconsoled 0:off 1:off 2:off 3:on4:on5:on6:off > xend0:off 1:off 2:off 3:on4:on5:on6:off > xendomains 0:off 1:off 2:off 3:on4:on5:on6:off > xenstored 0:off 1:off 2:off 3:on4:on5:on6:off > ypbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off > [r...@seanl64 ~]# ps -ef | grep xenconso > root 1508 1 0 10:19 ?00:00:00 /usr/sbin/xenconsoled > --log=none --log-dir=/var/log/xen/console root 7815 7732 0 17:07 > pts/500:00:00 grep xenconso > > Cheers > V > > > > I pressed the reset button, but this time the 2 64PV machines are not > > > logged in. I'll just let it go and see if it keeps going. > > > > > > Cheers > > > V > > > > > > On Tue, 22 Jun 2010 04:29:06 pm Pasi Kärkkäinen wrote: > > > > On Tue, Jun 22, 2010 at 12:03:53PM +1000, Virgil wrote: > > > > > Hi Pasi, > > > > > > > > > > On Mon, 21 Jun 2010 08:57:55 pm Pasi Kärkkäinen wrote: > > > > > > On Mon, Jun 21, 2010 at 01:56:36PM +0300, Pasi Kärkkäinen wrote: > > > > > > > On Mon, Jun 21, 2010 at 02:28:15PM +1000, Virgil wrote: > > > > > > > > Another quick update > > > > > > > > > > > > > > > > xen-4.0.1-0.1.rc3.fc13.src.rpm just compiled this under fc12. > > > > > > > > > > > > > > > > Identical results with this too (i.e. it's probably in the > > > > > > > > kernel). > > > > > > > > > > > > > > > > I have a (silly) idea for the serial console. The wiki page > > > > > > > > recommends using a phone camera to capture the screen > > > > > > > > > > > > > > > > Well my idea is to add an n-millisecond delay every time the > > > > > > > > output stream in Xen sees a \n. This would delay the screen > > > > > > > > updates enough for the camera to see them. The n should be > > > > > > > > configurable on the kernel boot command line. It's set to 0 > > > > > > > > right now. > > > > > > > > > > > > > > Yeah, we really need to get
Re: [Fedora-xen] xen 3.4.3 SRPM / console problem
On Wed, 23 Jun 2010 03:30:52 pm Pasi Kärkkäinen wrote: > On Wed, Jun 23, 2010 at 11:11:58AM +1000, Virgil wrote: > > Hi Pasi, > > > > Had a hiccup overnite: > > > > The host became unresponsive in a weird way. The time stopped > > incrementing. > > > > Turns out the clock stopped ticking (which I put down to the interrupts > > being disconnected). > > > > Anyway I decided I'd reset the time using 'time -s 10:41:30'. > > > > Kaboom, or actually deathly silence. The machine fully stopped dead in > > its tracks. > > > > Just prior to this I connected to the console of one of the 64PV machines > > which was just running a ping from yesterday. Anyway, 60,000 or so lines > > of pings went to the console zipping up the screen. Then it was dead. I > > did a CTRL-C and eventually it returned to the prompt. > > > > So I looked at the other 64PV machine, which was also pining, and > > identical situation. > > > > So I reckon, there's some kind of buffer overflow going on when you're > > not "xm console MACHINE" connected. Once you pass 60,000 lines of text > > this buffer overflow causes the RTC to hangup somehow. > > Do you have xenconsoled running? > > I've noticed PV guests that print a lot to the console will stall if > xenconsoled is not running.. xenconsoled needs to clear the guest console > buffer.. > > -- Pasi Seems to be now. Pretty sure it was then too. udev-post 0:off 1:on2:on3:on4:on5:on6:off wpa_supplicant 0:off 1:off 2:off 3:off 4:off 5:off 6:off xenconsoled 0:off 1:off 2:off 3:on4:on5:on6:off xend0:off 1:off 2:off 3:on4:on5:on6:off xendomains 0:off 1:off 2:off 3:on4:on5:on6:off xenstored 0:off 1:off 2:off 3:on4:on5:on6:off ypbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off [r...@seanl64 ~]# ps -ef | grep xenconso root 1508 1 0 10:19 ?00:00:00 /usr/sbin/xenconsoled --log=none --log-dir=/var/log/xen/console root 7815 7732 0 17:07 pts/500:00:00 grep xenconso Cheers V > > > I pressed the reset button, but this time the 2 64PV machines are not > > logged in. I'll just let it go and see if it keeps going. > > > > Cheers > > V > > > > On Tue, 22 Jun 2010 04:29:06 pm Pasi Kärkkäinen wrote: > > > On Tue, Jun 22, 2010 at 12:03:53PM +1000, Virgil wrote: > > > > Hi Pasi, > > > > > > > > On Mon, 21 Jun 2010 08:57:55 pm Pasi Kärkkäinen wrote: > > > > > On Mon, Jun 21, 2010 at 01:56:36PM +0300, Pasi Kärkkäinen wrote: > > > > > > On Mon, Jun 21, 2010 at 02:28:15PM +1000, Virgil wrote: > > > > > > > Another quick update > > > > > > > > > > > > > > xen-4.0.1-0.1.rc3.fc13.src.rpm just compiled this under fc12. > > > > > > > > > > > > > > Identical results with this too (i.e. it's probably in the > > > > > > > kernel). > > > > > > > > > > > > > > I have a (silly) idea for the serial console. The wiki page > > > > > > > recommends using a phone camera to capture the screen > > > > > > > > > > > > > > Well my idea is to add an n-millisecond delay every time the > > > > > > > output stream in Xen sees a \n. This would delay the screen > > > > > > > updates enough for the camera to see them. The n should be > > > > > > > configurable on the kernel boot command line. It's set to 0 > > > > > > > right now. > > > > > > > > > > > > Yeah, we really need to get a log somehow to troubleshoot your > > > > > > problem. > > > > > > > > > > > > Serial console log would be the best: > > > > > > http://wiki.xensource.com/xenwiki/XenSerialConsole > > > > > > > > > > Btw are you running the latest kernel: > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2254110 > > > > > > > > > > Or are you running custom/self compiled kernel? > > > > > > > > Everything is working with: > > > > xen-4.0.1-0.1.rc3 compiled from source on fc12 machine and > > > > 2.6.32.14-1.2.107.xendom0.fc12.x86_64 from the myoung repo. > > > > > > > > All fixed. > > > > >
Re: [Fedora-xen] xen 3.4.3 SRPM
Hi Pasi, Had a hiccup overnite: The host became unresponsive in a weird way. The time stopped incrementing. Turns out the clock stopped ticking (which I put down to the interrupts being disconnected). Anyway I decided I'd reset the time using 'time -s 10:41:30'. Kaboom, or actually deathly silence. The machine fully stopped dead in its tracks. Just prior to this I connected to the console of one of the 64PV machines which was just running a ping from yesterday. Anyway, 60,000 or so lines of pings went to the console zipping up the screen. Then it was dead. I did a CTRL-C and eventually it returned to the prompt. So I looked at the other 64PV machine, which was also pining, and identical situation. So I reckon, there's some kind of buffer overflow going on when you're not "xm console MACHINE" connected. Once you pass 60,000 lines of text this buffer overflow causes the RTC to hangup somehow. I pressed the reset button, but this time the 2 64PV machines are not logged in. I'll just let it go and see if it keeps going. Cheers V On Tue, 22 Jun 2010 04:29:06 pm Pasi Kärkkäinen wrote: > On Tue, Jun 22, 2010 at 12:03:53PM +1000, Virgil wrote: > > Hi Pasi, > > > > On Mon, 21 Jun 2010 08:57:55 pm Pasi Kärkkäinen wrote: > > > On Mon, Jun 21, 2010 at 01:56:36PM +0300, Pasi Kärkkäinen wrote: > > > > On Mon, Jun 21, 2010 at 02:28:15PM +1000, Virgil wrote: > > > > > Another quick update > > > > > > > > > > xen-4.0.1-0.1.rc3.fc13.src.rpm just compiled this under fc12. > > > > > > > > > > Identical results with this too (i.e. it's probably in the kernel). > > > > > > > > > > I have a (silly) idea for the serial console. The wiki page > > > > > recommends using a phone camera to capture the screen > > > > > > > > > > Well my idea is to add an n-millisecond delay every time the output > > > > > stream in Xen sees a \n. This would delay the screen updates enough > > > > > for the camera to see them. The n should be configurable on the > > > > > kernel boot command line. It's set to 0 right now. > > > > > > > > Yeah, we really need to get a log somehow to troubleshoot your > > > > problem. > > > > > > > > Serial console log would be the best: > > > > http://wiki.xensource.com/xenwiki/XenSerialConsole > > > > > > Btw are you running the latest kernel: > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2254110 > > > > > > Or are you running custom/self compiled kernel? > > > > Everything is working with: > > xen-4.0.1-0.1.rc3 compiled from source on fc12 machine and > > 2.6.32.14-1.2.107.xendom0.fc12.x86_64 from the myoung repo. > > > > All fixed. > > Good to hear it works! > > > We also now have a "null modem" cable to another old computer with a COM > > port. Turns out I was the only old man that could remember what a null > > modem cable is. The young guy said "wtf"? Also turns out I'm the only > > one who knows what minicom is and what 8N1 means :-) > > Hehe.. yeah I guess young people don't get to play with serial consoles > nowadays, until they're doing networking stuff.. > > So I guess most SOL devices in servers go unused.. :) > > -- Pasi > > > All VMs are now running concurrently. > > > > Very happy again. Thanks. > > V > > > > > -- Pasi > > > > > > > > Cheers > > > > > V > > > > > > > > > > On Mon, 21 Jun 2010 12:10:17 pm Virgil wrote: > > > > > > Just a quick update: > > > > > > > > > > > > Just tried xen-4.0.0-2. Recompile from source on fc12.x86_64. > > > > > > > > > > > > identical behaviour. > > > > > > > > > > > > Cheers > > > > > > V > > > > > > > > > > > > On Fri, 18 Jun 2010 03:17:19 pm Virgil wrote: > > > > > > > On Sat, 29 May 2010 11:26:50 pm M A Young wrote: > > > > > > > > If anyone wants to test xen 3.4.3, I have put up a source RPM > > > > > > > > at > > > > > > > > http://myoung.fedorapeople.org/dom0/src/xen-3.4.3-0.91.fc13. > > > > > > > > src.r pm > > > > > > > > > > > > > > > > Michael Young > > > > > > > > > >
Re: [Fedora-xen] xen 3.4.3 SRPM
Hi Pasi, On Mon, 21 Jun 2010 08:57:55 pm Pasi Kärkkäinen wrote: > On Mon, Jun 21, 2010 at 01:56:36PM +0300, Pasi Kärkkäinen wrote: > > On Mon, Jun 21, 2010 at 02:28:15PM +1000, Virgil wrote: > > > Another quick update > > > > > > xen-4.0.1-0.1.rc3.fc13.src.rpm just compiled this under fc12. > > > > > > Identical results with this too (i.e. it's probably in the kernel). > > > > > > I have a (silly) idea for the serial console. The wiki page recommends > > > using a phone camera to capture the screen > > > > > > Well my idea is to add an n-millisecond delay every time the output > > > stream in Xen sees a \n. This would delay the screen updates enough > > > for the camera to see them. The n should be configurable on the kernel > > > boot command line. It's set to 0 right now. > > > > Yeah, we really need to get a log somehow to troubleshoot your problem. > > > > Serial console log would be the best: > > http://wiki.xensource.com/xenwiki/XenSerialConsole > > Btw are you running the latest kernel: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2254110 > > Or are you running custom/self compiled kernel? > Everything is working with: xen-4.0.1-0.1.rc3 compiled from source on fc12 machine and 2.6.32.14-1.2.107.xendom0.fc12.x86_64 from the myoung repo. All fixed. We also now have a "null modem" cable to another old computer with a COM port. Turns out I was the only old man that could remember what a null modem cable is. The young guy said "wtf"? Also turns out I'm the only one who knows what minicom is and what 8N1 means :-) All VMs are now running concurrently. Very happy again. Thanks. V > -- Pasi > > > > Cheers > > > V > > > > > > On Mon, 21 Jun 2010 12:10:17 pm Virgil wrote: > > > > Just a quick update: > > > > > > > > Just tried xen-4.0.0-2. Recompile from source on fc12.x86_64. > > > > > > > > identical behaviour. > > > > > > > > Cheers > > > > V > > > > > > > > On Fri, 18 Jun 2010 03:17:19 pm Virgil wrote: > > > > > On Sat, 29 May 2010 11:26:50 pm M A Young wrote: > > > > > > If anyone wants to test xen 3.4.3, I have put up a source RPM at > > > > > > http://myoung.fedorapeople.org/dom0/src/xen-3.4.3-0.91.fc13.src.r > > > > > > pm > > > > > > > > > > > > Michael Young > > > > > > > > > > > > -- > > > > > > xen mailing list > > > > > > xen@lists.fedoraproject.org > > > > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > > > > > > > Hi list, > > > > > > > > > > Host crashing on 64FC12 kernel -105 dom0 when 2 PV64 machines are > > > > > run. > > > > > > > > > > I can run HV32WinXP and HV32FC12 and 1 PV64FC12 all at the same > > > > > time. > > > > > > > > > > However, when any combination involves 2 PV64FC12 (kernel version > > > > > doesn't matter) the host crashes. > > > > > > > > > > Running on the -97 dom0 everything works in all combos. > > > > > > > > > > Using Xen 3.4.3. > > > > > > > > > > Turning off the virt network cards in the PV64FC12 machines makes > > > > > things go (obviously not much use though). > > > > > > > > > > Tried disabling IPV6, firewall stuff etc. etc. > > > > > > > > > > Sometimes it would fire up and go but whichever machine is started > > > > > second gets really long ping times like it's not receiving unless > > > > > it sends something (if that makes sense). Sooner or later the host > > > > > crashes. > > > > > > > > > > Strangely a PV64FC12 and a PV64FC10 machine coexist happily. It's > > > > > only when a second PV64FC12 machine starts up. > > > > > > > > > > V > > > > > -- > > > > > xen mailing list > > > > > xen@lists.fedoraproject.org > > > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > > > > > -- > > > > xen mailing list > > > > xen@lists.fedoraproject.org > > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > > > -- > > > xen mailing list > > > xen@lists.fedoraproject.org > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > -- > > xen mailing list > > xen@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] xen 3.4.3 SRPM
Another quick update xen-4.0.1-0.1.rc3.fc13.src.rpm just compiled this under fc12. Identical results with this too (i.e. it's probably in the kernel). I have a (silly) idea for the serial console. The wiki page recommends using a phone camera to capture the screen Well my idea is to add an n-millisecond delay every time the output stream in Xen sees a \n. This would delay the screen updates enough for the camera to see them. The n should be configurable on the kernel boot command line. It's set to 0 right now. Cheers V On Mon, 21 Jun 2010 12:10:17 pm Virgil wrote: > Just a quick update: > > Just tried xen-4.0.0-2. Recompile from source on fc12.x86_64. > > identical behaviour. > > Cheers > V > > On Fri, 18 Jun 2010 03:17:19 pm Virgil wrote: > > On Sat, 29 May 2010 11:26:50 pm M A Young wrote: > > > If anyone wants to test xen 3.4.3, I have put up a source RPM at > > > http://myoung.fedorapeople.org/dom0/src/xen-3.4.3-0.91.fc13.src.rpm > > > > > > Michael Young > > > > > > -- > > > xen mailing list > > > xen@lists.fedoraproject.org > > > https://admin.fedoraproject.org/mailman/listinfo/xen > > > > Hi list, > > > > Host crashing on 64FC12 kernel -105 dom0 when 2 PV64 machines are run. > > > > I can run HV32WinXP and HV32FC12 and 1 PV64FC12 all at the same time. > > > > However, when any combination involves 2 PV64FC12 (kernel version doesn't > > matter) the host crashes. > > > > Running on the -97 dom0 everything works in all combos. > > > > Using Xen 3.4.3. > > > > Turning off the virt network cards in the PV64FC12 machines makes things > > go (obviously not much use though). > > > > Tried disabling IPV6, firewall stuff etc. etc. > > > > Sometimes it would fire up and go but whichever machine is started second > > gets really long ping times like it's not receiving unless it sends > > something (if that makes sense). Sooner or later the host crashes. > > > > Strangely a PV64FC12 and a PV64FC10 machine coexist happily. It's only > > when a second PV64FC12 machine starts up. > > > > V > > -- > > xen mailing list > > xen@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/xen > > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] xen 3.4.3 SRPM
Just a quick update: Just tried xen-4.0.0-2. Recompile from source on fc12.x86_64. identical behaviour. Cheers V On Fri, 18 Jun 2010 03:17:19 pm Virgil wrote: > On Sat, 29 May 2010 11:26:50 pm M A Young wrote: > > If anyone wants to test xen 3.4.3, I have put up a source RPM at > > http://myoung.fedorapeople.org/dom0/src/xen-3.4.3-0.91.fc13.src.rpm > > > > Michael Young > > > > -- > > xen mailing list > > xen@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/xen > > Hi list, > > Host crashing on 64FC12 kernel -105 dom0 when 2 PV64 machines are run. > > I can run HV32WinXP and HV32FC12 and 1 PV64FC12 all at the same time. > > However, when any combination involves 2 PV64FC12 (kernel version doesn't > matter) the host crashes. > > Running on the -97 dom0 everything works in all combos. > > Using Xen 3.4.3. > > Turning off the virt network cards in the PV64FC12 machines makes things go > (obviously not much use though). > > Tried disabling IPV6, firewall stuff etc. etc. > > Sometimes it would fire up and go but whichever machine is started second > gets really long ping times like it's not receiving unless it sends > something (if that makes sense). Sooner or later the host crashes. > > Strangely a PV64FC12 and a PV64FC10 machine coexist happily. It's only when > a second PV64FC12 machine starts up. > > V > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] xen 3.4.3 SRPM
On Sat, 29 May 2010 11:26:50 pm M A Young wrote: > If anyone wants to test xen 3.4.3, I have put up a source RPM at > http://myoung.fedorapeople.org/dom0/src/xen-3.4.3-0.91.fc13.src.rpm > > Michael Young > > -- > xen mailing list > xen@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/xen Hi list, Host crashing on 64FC12 kernel -105 dom0 when 2 PV64 machines are run. I can run HV32WinXP and HV32FC12 and 1 PV64FC12 all at the same time. However, when any combination involves 2 PV64FC12 (kernel version doesn't matter) the host crashes. Running on the -97 dom0 everything works in all combos. Using Xen 3.4.3. Turning off the virt network cards in the PV64FC12 machines makes things go (obviously not much use though). Tried disabling IPV6, firewall stuff etc. etc. Sometimes it would fire up and go but whichever machine is started second gets really long ping times like it's not receiving unless it sends something (if that makes sense). Sooner or later the host crashes. Strangely a PV64FC12 and a PV64FC10 machine coexist happily. It's only when a second PV64FC12 machine starts up. V -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] Xen 4.0.0
Success! xendom0-105/xen-3.4.3 combo. PoD memory disabled and WinXP Pro installed and operational. On Fri, 4 Jun 2010 02:03:26 pm Virgil wrote: > Is this what is happening?: > > http://lists.xensource.com/archives/html/xen-devel/2008-12/msg01030.html > > i.e. the guest does not have a balloon driver causing the PoD cache to run > out of pages and so crashing the domain? > > also: > > 09 - xend integration. > + Always calls xc_hvm_build_target_mem() with memsize=maxmem and > target=memory. If these the same, the internal function will not use > PoD. > > Trying this now. > > Success!! The 32hv12 machine is alive and kicking!!! > > Just set MAXMEM=MEMORY and PoD is disabled!! > > Very happy here. > > Now for WinXP. > > Cheers > V > > On Fri, 4 Jun 2010 10:53:40 am Virgil wrote: > > Further notes on WinXP crashes: > > > > What we did was attempt to install XP many many times. Generally what > > seemed to happen was the host machine rebooted when the XP machine > > rebooted. Sometime the XP install rebooted at what seemed the correct > > time. Other times it rebooted for no apparent reason. Sometime the WinXP > > install screen came up other times the host machine was dead, other times > > the host rebooted. > > > > Then I retrieved an old qemu XP image. I simply booted it directly in Xen > > and it started up. After a while it rebooted and took out the host. All > > this was on the xendom0-97/Xen-4.0.0 combo. > > > > I think that when the bad damage occurred to the host. Full rebuild > > yesterday. > > > > Next I tried to hardware virtualize an install on FC12 32 on the > > xendom0-105/Xen-3.9.3 combo. More or less the same thing happened with > > the rebooting. Actually it doesn't seem random. it always reboots > > when anaconda installs glibc (package number 97). > > > > However! the host never rebooted and still appears quite stable. Haven't > > tried the WinXP on this combo yet. > > > > name="32hv12" > > maxmem="2048" > > memory="1024" > > kernel="/usr/lib/xen/boot/hvmloader" > > builder="hvm" > > device_model="/usr/lib64/xen/bin/qemu-dm" > > disk=[ 'phy:/dev/VolGroup00/lv32HvFc12Spinner,ioemu:xvda,w', > > > >'file:/iso/Fedora-12-i386-DVD.iso,ioemu:xvdc:cdrom,r' > > > > ] > > vif=[ 'type=ioemu, bridge=eth0', ] > > boot="d" > > sdl=0 > > vnc=1 > > vncviewer=1 > > apic=0 > > acpi=0 > > pae=1 > > on_reboot='destroy' > > > > Some of the issue seems to be VNC related. Tried with apic and acpi > > combinations but no joy. Got better screen response by using VNC directly > > on port 5900 to the host rather than using Virtual Machine Manager mostly > > because you can turn off the mouse (possibly some TCP comms issue > > happening to the host - which is on the same LAN). Generally don't know > > what's happening though. > > > > Just looked in xm dmesg now (seems informative - what's a > > "populate-on-demand memory". I don't have enough of it): > > > > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > > large page (XEN) domain_crash called from p2m.c:1179 > > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > > large page (XEN) domain_crash called from p2m.c:1179 > > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > > large page (XEN) domain_crash called from p2m.c:1179 > > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > > large page (XEN) domain_crash called from p2m.c:1179 > > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > > large page (XEN) domain_crash called from p2m.c:1179 > > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > > large page (XEN) domain_crash called from p2m.c:1179 > > > > Lots more of these. then > > > > (XEN) Domain 9 (vcpu#0) crashed on cpu#0: > > (XEN) [ Xen-3.4.3 x86_64 debug=n Not tainted ] > > (XEN) CPU:0 > > (XEN) RIP:0060:[<c059a8cc>] > > (XEN) RFLAGS: 00200246 CONTEXT: hvm guest > > (XEN) rax: fffb2000 rbx: rcx: > > 0400 (XEN) rdx: f47a35c0 rsi: 0b8115c0 > > rdi: fffb2000 (XEN) rbp: c15cdd74 rsp: > > c15cdd68 r8: (XEN) r9: > > r10: 0
Re: [Fedora-xen] Xen 4.0.0
Is this what is happening?: http://lists.xensource.com/archives/html/xen-devel/2008-12/msg01030.html i.e. the guest does not have a balloon driver causing the PoD cache to run out of pages and so crashing the domain? also: 09 - xend integration. + Always calls xc_hvm_build_target_mem() with memsize=maxmem and target=memory. If these the same, the internal function will not use PoD. Trying this now. Success!! The 32hv12 machine is alive and kicking!!! Just set MAXMEM=MEMORY and PoD is disabled!! Very happy here. Now for WinXP. Cheers V On Fri, 4 Jun 2010 10:53:40 am Virgil wrote: > Further notes on WinXP crashes: > > What we did was attempt to install XP many many times. Generally what > seemed to happen was the host machine rebooted when the XP machine > rebooted. Sometime the XP install rebooted at what seemed the correct > time. Other times it rebooted for no apparent reason. Sometime the WinXP > install screen came up other times the host machine was dead, other times > the host rebooted. > > Then I retrieved an old qemu XP image. I simply booted it directly in Xen > and it started up. After a while it rebooted and took out the host. All > this was on the xendom0-97/Xen-4.0.0 combo. > > I think that when the bad damage occurred to the host. Full rebuild > yesterday. > > Next I tried to hardware virtualize an install on FC12 32 on the > xendom0-105/Xen-3.9.3 combo. More or less the same thing happened with the > rebooting. Actually it doesn't seem random. it always reboots when > anaconda installs glibc (package number 97). > > However! the host never rebooted and still appears quite stable. Haven't > tried the WinXP on this combo yet. > > name="32hv12" > maxmem="2048" > memory="1024" > kernel="/usr/lib/xen/boot/hvmloader" > builder="hvm" > device_model="/usr/lib64/xen/bin/qemu-dm" > disk=[ 'phy:/dev/VolGroup00/lv32HvFc12Spinner,ioemu:xvda,w', >'file:/iso/Fedora-12-i386-DVD.iso,ioemu:xvdc:cdrom,r' > ] > vif=[ 'type=ioemu, bridge=eth0', ] > boot="d" > sdl=0 > vnc=1 > vncviewer=1 > apic=0 > acpi=0 > pae=1 > on_reboot='destroy' > > Some of the issue seems to be VNC related. Tried with apic and acpi > combinations but no joy. Got better screen response by using VNC directly > on port 5900 to the host rather than using Virtual Machine Manager mostly > because you can turn off the mouse (possibly some TCP comms issue > happening to the host - which is on the same LAN). Generally don't know > what's happening though. > > Just looked in xm dmesg now (seems informative - what's a > "populate-on-demand memory". I don't have enough of it): > > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > large page (XEN) domain_crash called from p2m.c:1179 > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > large page (XEN) domain_crash called from p2m.c:1179 > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > large page (XEN) domain_crash called from p2m.c:1179 > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > large page (XEN) domain_crash called from p2m.c:1179 > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > large page (XEN) domain_crash called from p2m.c:1179 > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > large page (XEN) domain_crash called from p2m.c:1179 > > Lots more of these. then > > (XEN) Domain 9 (vcpu#0) crashed on cpu#0: > (XEN) [ Xen-3.4.3 x86_64 debug=n Not tainted ] > (XEN) CPU:0 > (XEN) RIP:0060:[<c059a8cc>] > (XEN) RFLAGS: 00200246 CONTEXT: hvm guest > (XEN) rax: fffb2000 rbx: rcx: 0400 > (XEN) rdx: f47a35c0 rsi: 0b8115c0 rdi: fffb2000 > (XEN) rbp: c15cdd74 rsp: c15cdd68 r8: > (XEN) r9: r10: r11: > (XEN) r12: r13: r14: > (XEN) r15: cr0: 80050033 cr4: 06d0 > (XEN) cr3: 015ac000 cr2: b3f67000 > (XEN) ds: 007b es: 007b fs: 00d8 gs: 00e0 ss: 0068 cs: 0060 > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > large page (XEN) domain_crash called from p2m.c:1179 > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > large page (XEN) domain_crash called from p2m.c:1179 > (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with > large page (X
Re: [Fedora-xen] Xen 4.0.0
Further notes on WinXP crashes: What we did was attempt to install XP many many times. Generally what seemed to happen was the host machine rebooted when the XP machine rebooted. Sometime the XP install rebooted at what seemed the correct time. Other times it rebooted for no apparent reason. Sometime the WinXP install screen came up other times the host machine was dead, other times the host rebooted. Then I retrieved an old qemu XP image. I simply booted it directly in Xen and it started up. After a while it rebooted and took out the host. All this was on the xendom0-97/Xen-4.0.0 combo. I think that when the bad damage occurred to the host. Full rebuild yesterday. Next I tried to hardware virtualize an install on FC12 32 on the xendom0-105/Xen-3.9.3 combo. More or less the same thing happened with the rebooting. Actually it doesn't seem random. it always reboots when anaconda installs glibc (package number 97). However! the host never rebooted and still appears quite stable. Haven't tried the WinXP on this combo yet. name="32hv12" maxmem="2048" memory="1024" kernel="/usr/lib/xen/boot/hvmloader" builder="hvm" device_model="/usr/lib64/xen/bin/qemu-dm" disk=[ 'phy:/dev/VolGroup00/lv32HvFc12Spinner,ioemu:xvda,w', 'file:/iso/Fedora-12-i386-DVD.iso,ioemu:xvdc:cdrom,r' ] vif=[ 'type=ioemu, bridge=eth0', ] boot="d" sdl=0 vnc=1 vncviewer=1 apic=0 acpi=0 pae=1 on_reboot='destroy' Some of the issue seems to be VNC related. Tried with apic and acpi combinations but no joy. Got better screen response by using VNC directly on port 5900 to the host rather than using Virtual Machine Manager mostly because you can turn off the mouse (possibly some TCP comms issue happening to the host - which is on the same LAN). Generally don't know what's happening though. Just looked in xm dmesg now (seems informative - what's a "populate-on-demand memory". I don't have enough of it): (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with large page (XEN) domain_crash called from p2m.c:1179 (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with large page (XEN) domain_crash called from p2m.c:1179 (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with large page (XEN) domain_crash called from p2m.c:1179 (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with large page (XEN) domain_crash called from p2m.c:1179 (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with large page (XEN) domain_crash called from p2m.c:1179 (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with large page (XEN) domain_crash called from p2m.c:1179 Lots more of these. then (XEN) Domain 9 (vcpu#0) crashed on cpu#0: (XEN) [ Xen-3.4.3 x86_64 debug=n Not tainted ] (XEN) CPU:0 (XEN) RIP:0060:[<c059a8cc>] (XEN) RFLAGS: 00200246 CONTEXT: hvm guest (XEN) rax: fffb2000 rbx: rcx: 0400 (XEN) rdx: f47a35c0 rsi: 0b8115c0 rdi: fffb2000 (XEN) rbp: c15cdd74 rsp: c15cdd68 r8: (XEN) r9: r10: r11: (XEN) r12: r13: r14: (XEN) r15: cr0: 80050033 cr4: 06d0 (XEN) cr3: 015ac000 cr2: b3f67000 (XEN) ds: 007b es: 007b fs: 00d8 gs: 00e0 ss: 0068 cs: 0060 (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with large page (XEN) domain_crash called from p2m.c:1179 (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with large page (XEN) domain_crash called from p2m.c:1179 (XEN) pg error: p2m_set_entry(): configure P2M table 4KB L2 entry with large page (XEN) domain_crash called from p2m.c:1179 (XEN) p2m_pod_demand_populate: Out of populate-on-demand memory! tot_pages 262343 pod_entries 262944 (XEN) domain_crash called from p2m.c:1065 (XEN) Domain 12 (vcpu#0) crashed on cpu#0: (XEN) [ Xen-3.4.3 x86_64 debug=n Not tainted ] (XEN) CPU:0 (XEN) RIP:0060:[<c059a8cc>] (XEN) RFLAGS: 0246 CONTEXT: hvm guest (XEN) rax: fffb2000 rbx: rcx: 0400 (XEN) rdx: 4e4ed000 rsi: b1b5f000 rdi: fffb2000 (XEN) rbp: c15a7d74 rsp: c15a7d68 r8: (XEN) r9: r10: r11: (XEN) r12: r13: r14: (XEN) r15: cr0: 8005003b cr4: 06d0 (XEN) cr3: 015a9000 cr2: b1b60000 (XEN) ds: 007b es: 007b fs: 00d8 gs: 00e0 ss: 0068 cs: 0060 On Thu, 3 Jun 2010 04:59:12
Re: [Fedora-xen] Xen 4.0.0
Further testing (haven't done the extra recommended things yet). xendom0-105/xen-3.9.3 Success. This works but hardware virtualization exhibits the same issues with WinXP as the xendom0-97/xen-4.0.0 combo. The configs are identical except that qemu-dm is in /usr/lib64/xen/bin whereas with xen-4.0.0 it lives in /usr/lib/xen/bin (i.e. changed in the xm create file). So these work for me: xendom0-97/xen-4.0.0 xendom0-105/xen-3.9.3 This doesn't: xendom0-105/xen-4.0.0 Here's the grub menu file (you are mind readers! - as you can see nomodeset! The machine is not running gnome or kde desktops. It's pretty much headless): # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/VolGroup00-LogVol00 # initrd /initrd-[generic-]version.img #boot=/dev/sda default=1 timeout=0 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Fedora (2.6.32.11-1.2.97.xendom0.fc12.x86_64) root (hd0,0) kernel /xen.gz dom0_mem=1024M module /vmlinuz-2.6.32.11-1.2.97.xendom0.fc12.x86_64 ro root=/dev/mapper/VolGroup00-LogVol00 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us selinux=0 ipv6.disable=1 nomodeset module /initramfs-2.6.32.11-1.2.97.xendom0.fc12.x86_64.img title Fedora (2.6.32.14-1.2.105.xendom0.fc12.x86_64) root (hd0,0) kernel /xen.gz dom0_mem=1024M module /vmlinuz-2.6.32.14-1.2.105.xendom0.fc12.x86_64 ro root=/dev/mapper/VolGroup00-LogVol00 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us selinux=0 ipv6.disable=1 nomodeset module /initramfs-2.6.32.14-1.2.105.xendom0.fc12.x86_64.img title Fedora (2.6.32.12-115.fc12.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32.12-115.fc12.x86_64 ro root=/dev/mapper/VolGroup00-LogVol00 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us selinux=0 ipv6.disable=1 initrd /initramfs-2.6.32.12-115.fc12.x86_64.img title Fedora (2.6.31.5-127.fc12.x86_64) root (hd0,0) kernel /vmlinuz-2.6.31.5-127.fc12.x86_64 ro root=/dev/mapper/VolGroup00-LogVol00 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us selinux=0 ipv6.disable=1 initrd /initramfs-2.6.31.5-127.fc12.x86_64.img Cheers V On Thu, 3 Jun 2010 10:37:34 pm Pasi Kärkkäinen wrote: > On Thu, Jun 03, 2010 at 01:33:37PM +0100, M A Young wrote: > > On Thu, 3 Jun 2010, Pasi Kärkkäinen wrote: > >>> xendom0-105/xen-4.0.0 crashes and burns badly with a pv32fc12 domU (so > >>> badly the keyboard lights blink in pain. Reset button required. Lots > >>> and lots of hypervisorish stuff all over the screen. Very likely the > >>> cause is noted in there somewhere). > >> > >> Please set up a serial console so you can capture the full boot and > >> error/crash messages: > >> http://wiki.xensource.com/xenwiki/XenSerialConsole > >> > >> A couple of questions: > >> > >> - Do you have "nomodeset" parameter for the dom0 kernel? > >> - Did you limit dom0 memory to, say, 1024 MB ? > > > > This last point could be an issue as I think the balloon driver has > > problems in the current kernel. I can certainly get a crash on a low > > memory machine. > > Yeah, it's good to give a fixed amount of memory for dom0 and remove the > need for dom0 ballooning when creating new vms. > > -- Pasi -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] Xen 4.0.0
On Thu, 3 Jun 2010 05:34:34 am M A Young wrote: > On Wed, 2 Jun 2010, Virgil wrote: > > Just doing an rpmbuild on: > > > > xen-4.0.0-0.7.fc12.x86_64 > > > > and I get this error towards the end: > > > > Processing files: xen-debuginfo-4.0.0-0.7.fc12.x86_64 > > Checking for unpackaged file(s): /usr/lib/rpm/check-files > > /root/rpmbuild/BUILDROOT/xen-4.0.0-0.7.fc12.x86_64 > > > > error: Installed (but unpackaged) file(s) found: > > /etc/hotplug/xen-backend.agent > > If you actually got some RPMs built then you should be able to use them. > It looks like you might have the hotplug package installed (current Fedora > doesn't have this package) and xen is trying to set things up accordingly. > > If you didn't get any RPMs I did a test build of xen-4.0.0-0.7.fc12 at > http://koji.fedoraproject.org/koji/taskinfo?taskID=2225738 for rawhide > that you might be able to use. > > Michael Young OK have rebuilt the machine from the ground up. DVD install then `yum update` What works: xendom0-97/xen-4.0.0 runs most domU images (not WinXP - runs for a while then locks up). Even the old FC6 domUs run well. What doesn't: xendom0-105/xen-4.0.0 crashes and burns badly with a pv32fc12 domU (so badly the keyboard lights blink in pain. Reset button required. Lots and lots of hypervisorish stuff all over the screen. Very likely the cause is noted in there somewhere). Not tested: xen-3.4.3 with either kernel. Is this version of Xen more likely to react in a more stable manner? Or is this a kernel thing? └── Xen-fc12 ├── xen-3.4.3 │ ├── xen-3.4.3-2.fc12.x86_64.rpm │ ├── xen-devel-3.4.3-2.fc12.x86_64.rpm │ ├── xen-doc-3.4.3-2.fc12.x86_64.rpm │ ├── xen-hypervisor-3.4.3-2.fc12.x86_64.rpm │ ├── xen-libs-3.4.3-2.fc12.x86_64.rpm │ └── xen-runtime-3.4.3-2.fc12.x86_64.rpm ├── xen-4.0.0 │ ├── xen-4.0.0-0.7.fc12.src.rpm │ ├── xen-4.0.0-0.7.fc12.x86_64.rpm │ ├── xen-debuginfo-4.0.0-0.7.fc12.x86_64.rpm │ ├── xen-devel-4.0.0-0.7.fc12.x86_64.rpm │ ├── xen-doc-4.0.0-0.7.fc12.x86_64.rpm │ ├── xen-hypervisor-4.0.0-0.7.fc12.x86_64.rpm │ ├── xen-libs-4.0.0-0.7.fc12.x86_64.rpm │ └── xen-runtime-4.0.0-0.7.fc12.x86_64.rpm ├── xendom0-105 │ ├── kernel-2.6.32.14-1.2.105.xendom0.fc12.x86_64.rpm │ ├── kernel-devel-2.6.32.14-1.2.105.xendom0.fc12.x86_64.rpm │ ├── kernel-firmware-2.6.32.14-1.2.105.xendom0.fc12.noarch.rpm │ └── kernel-headers-2.6.32.14-1.2.105.xendom0.fc12.x86_64.rpm └── xendom0-97 ├── kernel-2.6.32.11-1.2.97.xendom0.fc12.x86_64.rpm ├── kernel-devel-2.6.32.11-1.2.97.xendom0.fc12.x86_64.rpm ├── kernel-firmware-2.6.32.11-1.2.97.xendom0.fc12.noarch.rpm └── kernel-headers-2.6.32.11-1.2.97.xendom0.fc12.x86_64.rpm Cheers V -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
[Fedora-xen] Xen 4.0.0
Hi list, Just doing an rpmbuild on: xen-4.0.0-0.7.fc12.x86_64 and I get this error towards the end: Processing files: xen-debuginfo-4.0.0-0.7.fc12.x86_64 Checking for unpackaged file(s): /usr/lib/rpm/check-files /root/rpmbuild/BUILDROOT/xen-4.0.0-0.7.fc12.x86_64 error: Installed (but unpackaged) file(s) found: /etc/hotplug/xen-backend.agent RPM build errors: Installed (but unpackaged) file(s) found: /etc/hotplug/xen-backend.agent The question is: Does this matter? Can I just ignore it and use the RPM anyway? Cheers Virgil. -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
Re: [Fedora-xen] dom0 kernel and xen hypervisor
file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libusb-0.1.so.4' -> `': No such file or directory ln: creating symbolic link `libudev.so.0' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libblkid.so.1' -> `': No such file or directory ln: creating symbolic link `libuuid.so.1' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libdl.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `libdl.so.2' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `libdl.so.2' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `librt.so.1' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `libpthread.so.0' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `libdl.so.2' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `librt.so.1' -> `': No such file or directory ln: creating symbolic link `libcap.so.2' -> `': No such file or directory ln: creating symbolic link `libacl.so.1' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `libpthread.so.0' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libdl.so.2' -> `': No such file or directory ln: creating symbolic link `libattr.so.1' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libacl.so.1' -> `': No such file or directory ln: creating symbolic link `libattr.so.1' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `libdl.so.2' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libacl.so.1' -> `': No such file or directory ln: creating symbolic link `libattr.so.1' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `libdl.so.2' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `libdl.so.2' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libtinfo.so.5' -> `': No such file or directory ln: creating symbolic link `libpcre.so.0' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ln: creating symbolic link `libc.so.6' -> `': No such file or directory ln: creating symbolic link `ld-linux-x86-64.so.2' -> `': No such file or directory ldconfig: Cannot mmap file /lib64/libdmraid-events-isw.so. ldconfig: Cannot mmap file /lib64/libnss_files.so.2. /sbin/dracut: line 307: : No such file or directory E: dracut: creation of failed mkinitrd failed warning: %post(kernel-2.6.32.14-1.2.105.xendom0.fc12.x86_64) scriptlet failed, exit status 1 Cheers Virgil. -- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
