nic@wuwei:/usr/src/xen/xen-unstable.hg$ sudo xm create breezy -c Using config file "/etc/xen/breezy". Started domain breezy Linux version 2.6.12-xenU (nic@wuwei) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #3 SMP Thu Oct 13 14:56:20 NZDT 2005 kernel direct mapping tables upto 10000000 @ 568000-5ea000 Built 1 zonelists Kernel command line: root=/dev/sda1 ro 4 lockd.udpport=32768 lockd.tcpport=32768 Unknown boot option `lockd.udpport=32768'': ignoring Unknown boot option `lockd.tcpport=32768'': ignoring Initializing CPU#0 PID hash table entries: 2048 (order: 11, 65536 bytes) Xen reported: 2194.794 MHz processor. Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Software IO TLB disabled Memory: 251904k/262144k available (2569k kernel code, 9752k reserved, 814k data, 160k init) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) Booting processor 1/1 rip ffffffff80100008 rsp ffff8800014f5f58 Initializing CPU#1 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) AMD Opteron(tm) Processor 248 stepping 01 Brought up 2 CPUs NET: Registered protocol family 16 xen_mem: Initialising balloon driver. SCSI subsystem initialized PCI: System does not support PCI PCI: System does not support PCI TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca) Grant table initialized IA-32 Microcode Update Driver: v1.14-xen <tigran@veritas.com> IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $ Installing knfsd (copyright (C) 1996 okir@monad.swb.de). SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled SGI XFS Quota Management subsystem Initializing Cryptographic API Failed to obtain physical IRQ 8 Real Time Clock Driver v1.12 i8042.c: No controller found. io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize loop: loaded (max 8 devices) WARNING: Failed to register Xen virtual console driver as ''tty1'' Event-channel device installed. xen_blk: Initialising virtual block device driver xen_net: Initialising virtual ethernet driver. mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 1024 buckets, 16Kbytes TCP established hash table entries: 16384 (order: 6, 262144 bytes) TCP bind hash table entries: 16384 (order: 6, 262144 bytes) TCP: Hash tables configured (established 16384 bind 16384) NET: Registered protocol family 1 NET: Registered protocol family 17 Bridge firewalling registered Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "sda1" or unknown-block(2,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) nic@wuwei:/usr/src/xen/xen-unstable.hg$ hg tip changeset: 7353:29db5bded574 nic@wuwei:/etc/xen$ cat breezy kernel = "/boot/vmlinuz-2.6.12-xenU" memory = 256 name = "breezy" vcpus = 2 nics=1 vif = [ "mac=aa:00:00:88:02:40, bridge=xen-br0" ] disk = [ ''phy:ww/breezy-fs,sda1,w'', ''phy:ww/breezy-swap,sda2,w'' ] root = "/dev/sda1 ro" extra = "4 lockd.udpport=32768 lockd.tcpport=32768" restart = ''onreboot'' nic@wuwei:/usr/src/xen/xen-unstable.hg$ sudo lvdisplay ww/breezy-fs --- Logical volume --- LV Name /dev/ww/breezy-fs VG Name ww ... Can someone explain what I might be missing here. Note I previously got domU booting, but had problems with the net device. Now it looks like the net device is initialising but the block device is having issues. Thanks. -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nicholas Lee wrote:>xen_blk: Initialising virtual block device driver >xen_net: Initialising virtual ethernet driver. >mice: PS/2 mouse device common for all mice >NET: Registered protocol family 2 >IP: routing cache hash table of 1024 buckets, 16Kbytes >TCP established hash table entries: 16384 (order: 6, 262144 bytes) >TCP bind hash table entries: 16384 (order: 6, 262144 bytes) >TCP: Hash tables configured (established 16384 bind 16384) >NET: Registered protocol family 1 >NET: Registered protocol family 17 >Bridge firewalling registered >Root-NFS: No NFS server available, giving up. >VFS: Unable to mount root fs via NFS, trying floppy. >VFS: Cannot open root device "sda1" or unknown-block(2,0) >Please append a correct "root=" boot option >Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) > >Yep... exactly what I''ve been battling for days now!! Rob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Oct 13, 2005 at 03:20:19PM +1300, Nicholas Lee wrote: <snip>> Root-NFS: No NFS server available, giving up. > VFS: Unable to mount root fs via NFS, trying floppy. > VFS: Cannot open root device "sda1" or unknown-block(2,0) > Please append a correct "root=" boot option > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)^^^^^^^^^^^^^^^^^^ I am seeing exactly this failure per the previous email thread.> nic@wuwei:/usr/src/xen/xen-unstable.hg$ hg tip > changeset: 7353:29db5bded574Same change set. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/13/05, Sean Dague <sean@dague.net> wrote:> I am seeing exactly this failure per the previous email thread.I''m not even seeing the first domU come up. I''m distclean and trying again with the default default kernal (plus XFS as I use that here.) Otherwise is there a ''good'' changeset to revert too? -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13 Oct 2005, at 04:25, Nicholas Lee wrote:>> I am seeing exactly this failure per the previous email thread. > > I''m not even seeing the first domU come up. I''m distclean and trying > again with the default default kernal (plus XFS as I use that here.) > > Otherwise is there a ''good'' changeset to revert too?There are some fixes for domU device probing waiting in the queue to get pushed to the public tree. Hopefully should fix some of these failures. I expect they''ll get pushed out some time this morning after testing. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> > There are some fixes for domU device probing waiting in the queue to > get pushed to the public tree. Hopefully should fix some of these > failures.They didn''t. I did a pull this morning and rebuilt everything.... same behavior, same problem. Rob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I have continue to have the same problem as well. (cs 7369:92c6021f23e4) nic@wuwei:~$ sudo xm create breezy -c Using config file "/etc/xen/breezy". Started domain breezy Linux version 2.6.12-xenU (nic@wuwei) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP Fri Oct 14 10:38:59 NZDT 2005 Built 1 zonelists Kernel command line: root=/dev/sda1 ro 4 ... NET: Registered protocol family 1 NET: Registered protocol family 17 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. VFS: Cannot open root device "sda1" or unknown-block(0,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I just noted these additional error messages in xm dmesg that might help: (XEN) (file=irq.c, line=224) Cannot bind IRQ 2 to guest. In use by ''cascade''. (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000080,00010000,00010000). (XEN) (file=traps.c, line=960) Non-priv domain attempted WRMSR(00000000c0000100,00000000,00000000). (XEN) (file=traps.c, line=960) Non-priv domain attempted WRMSR(00000000c0000102,00000000,00000000). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000080,00000000,00000000). (XEN) (file=traps.c, line=960) Non-priv domain attempted WRMSR(00000000c0000100,00000000,00000000). (XEN) (file=traps.c, line=960) Non-priv domain attempted WRMSR(00000000c0000102,00000000,00000000). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000080,00000000,00000000). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000100,00000045,ffffffffff5fd000). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000101,ab124740,00002aaa). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000102,8038c980,ffffffff). -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nicholas Lee wrote:>I have continue to have the same problem as well. (cs 7369:92c6021f23e4) > >I just succeeded in working around the problem by the simple expedient of reinstalling linux. ;) I created a new disk partition, installed a fresh linux into it to host xen and dom0, then copied over the latest build, and now I can boot domU with no problems. The conclusion: something was messed up on my system, and doing a xen install did not clean it up. I had tried manually removing all the xen files I could find or think of, but nothing seemed to help. Whatever was messed up, or stale, was hiding very very well. Rob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/14/05, Rob Gardner <rob.gardner@hp.com> wrote:> I just succeeded in working around the problem by the simple expedient > of reinstalling linux. ;)I can to this conclusion just last night as well. When I reverted to a changeset that worked previously. I was thinking I''d boot into the non-xen kernel some time today and nuke all the Xen files. You are right though, completely reinstall might be the best option. Sounds like a windows box. :P I guess at least with Xen we can be safe in the knowledge that might domU data will remain completely unaffected. -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/14/05, Nicholas Lee <emptysands@gmail.com> wrote:> I just noted these additional error messages in xm dmesg that might help:Installing a CONFIG_XEN_PRIVILEGED_GUEST=y guest doesn''t seem to change this. Exactly same error messages. (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000101,ab124740,00002aaa). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000102,8038c980,ffffffff). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000080,00010000,00010000). (XEN) (file=traps.c, line=960) Non-priv domain attempted WRMSR(00000000c0000100,00000000,00000000). (XEN) (file=traps.c, line=960) Non-priv domain attempted WRMSR(00000000c0000102,00000000,00000000). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000080,00000000,00000000). (XEN) (file=traps.c, line=960) Non-priv domain attempted WRMSR(00000000c0000100,00000000,00000000). (XEN) (file=traps.c, line=960) Non-priv domain attempted WRMSR(00000000c0000102,00000000,00000000). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000080,00000000,00000000). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000100,00000045,ffffffffff577000). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000101,ab124740,00002aaa). (XEN) (file=traps.c, line=968) Non-priv domain attempted RDMSR(00000000c0000102,803f5c00,ffffffff). nic@wuwei:~$ sudo xm block-list 3 (2049 ((virtual-device 2049) (backend-id 0) (backend /local/domain/0/backend/vbd/3/2049) (ring-ref 8) (event-channel 9) (error ''2 reading backend fields at /local/domain/0/backend/vbd/3/2049''))) -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On 10/14/05, Nicholas Lee <emptysands@gmail.com> wrote: > > I just noted these additional error messages in xm dmesg > that might help: > > Installing a CONFIG_XEN_PRIVILEGED_GUEST=y guest doesn''t seem > to change this.These grumbles from Xen are nothing to worry about -- you only see them because we''re using a verbose build by default. Ian> Exactly same error messages. > > (XEN) (file=traps.c, line=968) Non-priv domain attempted > RDMSR(00000000c0000101,ab124740,00002aaa). > (XEN) (file=traps.c, line=968) Non-priv domain attempted > RDMSR(00000000c0000102,8038c980,ffffffff). > (XEN) (file=traps.c, line=968) Non-priv domain attempted > RDMSR(00000000c0000080,00010000,00010000). > (XEN) (file=traps.c, line=960) Non-priv domain attempted > WRMSR(00000000c0000100,00000000,00000000). > (XEN) (file=traps.c, line=960) Non-priv domain attempted > WRMSR(00000000c0000102,00000000,00000000). > (XEN) (file=traps.c, line=968) Non-priv domain attempted > RDMSR(00000000c0000080,00000000,00000000). > (XEN) (file=traps.c, line=960) Non-priv domain attempted > WRMSR(00000000c0000100,00000000,00000000). > (XEN) (file=traps.c, line=960) Non-priv domain attempted > WRMSR(00000000c0000102,00000000,00000000). > (XEN) (file=traps.c, line=968) Non-priv domain attempted > RDMSR(00000000c0000080,00000000,00000000). > (XEN) (file=traps.c, line=968) Non-priv domain attempted > RDMSR(00000000c0000100,00000045,ffffffffff577000). > (XEN) (file=traps.c, line=968) Non-priv domain attempted > RDMSR(00000000c0000101,ab124740,00002aaa). > (XEN) (file=traps.c, line=968) Non-priv domain attempted > RDMSR(00000000c0000102,803f5c00,ffffffff). > > nic@wuwei:~$ sudo xm block-list 3 > (2049 ((virtual-device 2049) (backend-id 0) (backend > /local/domain/0/backend/vbd/3/2049) (ring-ref 8) > (event-channel 9) (error ''2 reading backend fields at > /local/domain/0/backend/vbd/3/2049''))) > > > > > -- > Nicholas Lee > http://stateless.geek.nz > gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/15/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> These grumbles from Xen are nothing to worry about -- you only see them > because we''re using a verbose build by default.I was wondering about that. Still I guess since we are in testing mode its better for me to be as noisy as possible as well. :) -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/15/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> These grumbles from Xen are nothing to worry about -- you only see them > because we''re using a verbose build by default.I was wondering about that. Still I guess since we are in testing mode its better for me to be as noisy as possible as well. :) -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/15/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> These grumbles from Xen are nothing to worry about -- you only see them > because we''re using a verbose build by default.I was wondering about that. Still I guess since we are in testing mode its better for me to be as noisy as possible as well. :) -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/15/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> These grumbles from Xen are nothing to worry about -- you only see them > because we''re using a verbose build by default.I was wondering about that. Still I guess since we are in testing mode its better for me to be as noisy as possible as well. :) -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
" >There are some fixes for domU device probing waiting in the queue to
" >get pushed to the public tree. Hopefully should fix some of these
" >failures.
I tried today''s pull and xenU will still not detect the vbd.
This is not consistent across hardware. xenU detects the vbd OK on
a Dell PE1650 but not on an IBM HS20 Blade (type 8678).
The Dell has a scsi drive and the IBM has IDE. Both hosts
have LVM partitions for the xenUs.
xenU on the IBM says:
Xen virtual console successfully installed as tty1
Event-channel device installed.
xen_blk: Initialising virtual block device driver
xen_net: Initialising virtual ethernet driver.
xenU on the Dell says:
Xen virtual console successfully installed as tty1
Event-channel device installed.
xen_blk: Initialising virtual block device driver
Registering block device major 3
xen_net: Initialising virtual ethernet driver.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
David Becker wrote:>" >There are some fixes for domU device probing waiting in the queue to >" >get pushed to the public tree. Hopefully should fix some of these >" >failures. > >I tried today''s pull and xenU will still not detect the vbd. >This is not consistent across hardware. xenU detects the vbd OK on >a Dell PE1650 but not on an IBM HS20 Blade (type 8678). >The Dell has a scsi drive and the IBM has IDE. Both hosts >have LVM partitions for the xenUs. > > >xenU on the IBM says: > Xen virtual console successfully installed as tty1 > Event-channel device installed. > xen_blk: Initialising virtual block device driver > xen_net: Initialising virtual ethernet driver. > >This is exactly the problem I was seeing all last week. I re-imaged my base system to clean up the filesystem, and that appears to have solved the problem on two different machines. So it seems that the bug is also exposed or affected by something in the filesystem, possibly an out of date library, or something. The only clue I can offer (which may just be coincidence) is that all the affected systems had previously run xen 2.0 in the past, while the new (working) system was a clone of a system that had only ever had xen 3.0 on it. Rob Gardner _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
bah, the problem host was missing the hotplug package. This hotplug dependency bit me once before. Can xm create just fail when hotplug is missing? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10/19/05, David Becker <becker@cs.duke.edu> wrote:> dependency bit me once before. Can xm create just fail when > hotplug is missing?I thought about suggesting this as well. I''m guessing it would be easier enough to put an existence test in the "xm create" python script. I''m not sure sure exactly why Xen 3.0 depends on hotplug though. -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel