thr3ads.net - Xen users - [Xen-users] No DomU boot after upgrade to xen 4.0 [Apr 2010]

If this information is useful, please help other people find it:
Share via:

Ralf Hornik Mailings

2010-Apr-25 11:31 UTC

[Xen-users] No DomU boot after upgrade to xen 4.0

Dear list,

I use debian 5.0 lenny with xen 4.0 built from source.
When I try to start any previously worked domU I get:

dom0:~# xm create -c server01
Using config file "/etc/xen/server01".
Error: Domain ''server01'' does not exist.
dom0:~#

And the logfile says:

domid: 4
warning: could not open /dev/net/tun: no virtual network emulation
Could not initialize device ''tap''

Also VTd is disabled even that I have enabled "pci passthrough" while 
compiling the kernel.
When I fall back to xen 3.4 any DomU is back again (w. pci passthrough).
Any ideas what is missing?

Thank you and best regards

Ralf



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Christian Kujau

2010-Apr-25 13:43 UTC

head link

Re: [Xen-users] No DomU boot after upgrade to xen 4.0

On Sun, 25 Apr 2010 at 13:31, Ralf Hornik Mailings
wrote:> warning: could not open /dev/net/tun: no virtual network emulation
> Could not initialize device ''tap''
Has the Dom0 kernel CONFIG_TUN enabled? If so, is TUN/TAP working?

Christian.
-- 
BOFH excuse #305:

IRQ-problems with the Un-Interruptible-Power-Supply

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Ralf Hornik Mailings

2010-Apr-25 19:39 UTC

head link

Re: [Xen-users] No DomU boot after upgrade to xen 4.0

Hi Christian,

Christian Kujau schrieb:> Has the Dom0 kernel CONFIG_TUN enabled? If so, is TUN/TAP working?
>No it isn''t. How do I enable it? The default "make world"
doesn''t seem
to do that

However:

make linux-2.6-xen-config CONFIGMODE=menuconfig

as in 2.6.18 does not work as its downloading the 2.6.18 kernel then. Is 
there any documentation how to conmpile a custom kernel with xen 4 and 
2.6.31?

For VTd I found out the following:

xm dmesg:

(XEN) [VT-D]dmar.c:679: Host address width 36
(XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:398:   dmaru->address = feb00000
(XEN) [VT-D]dmar.c:334:   endpoint: 0:1b.0
(XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
(XEN) [VT-D]dmar.c:398:   dmaru->address = feb01000
(XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
(XEN) [VT-D]dmar.c:334:   endpoint: 0:2.1
(XEN) [VT-D]dmar.c:447:   Non-existent device (0:2.1) is reported in 
this DRHD''s scope!
(XEN) [VT-D]dmar.c:469:   The DRHD is invalid due to there are devices 
under its scope are not PCI discoverable! Pls try option iommu=force or 
iommu=workaround_bios_bug if you really want VT-d
(XEN) Failed to parse ACPI DMAR.  Disabling VT-d.

When I set iommu=force then vtd will be enabled but what should I do to 
solve this better?
Thank you and best Regards

Ralf

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Matej Zary

2010-Apr-25 19:57 UTC

head link

Re: Re: [Xen-users] No DomU boot after upgrade to xen 4.0

On Sun, 2010-04-25 at 21:39 +0200, Ralf Hornik Mailings
wrote:> Hi Christian,
> 
> Christian Kujau schrieb:
> > Has the Dom0 kernel CONFIG_TUN enabled? If so, is TUN/TAP working?
> >
> No it isn't. How do I enable it? The default "make world"
doesn't seem
> to do that
> 
> However:
> 
> make linux-2.6-xen-config CONFIGMODE=menuconfig
> 
> as in 2.6.18 does not work as its downloading the 2.6.18 kernel then. Is 
> there any documentation how to conmpile a custom kernel with xen 4 and 
> 2.6.31?
> 
> For VTd I found out the following:
> 
> xm dmesg:
> 
> (XEN) [VT-D]dmar.c:679: Host address width 36
> (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
> (XEN) [VT-D]dmar.c:398:   dmaru->address = feb00000
> (XEN) [VT-D]dmar.c:334:   endpoint: 0:1b.0
> (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
> (XEN) [VT-D]dmar.c:398:   dmaru->address = feb01000
> (XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
> (XEN) [VT-D]dmar.c:334:   endpoint: 0:2.1
> (XEN) [VT-D]dmar.c:447:   Non-existent device (0:2.1) is reported in 
> this DRHD's scope!
> (XEN) [VT-D]dmar.c:469:   The DRHD is invalid due to there are devices 
> under its scope are not PCI discoverable! Pls try option iommu=force or 
> iommu=workaround_bios_bug if you really want VT-d
> (XEN) Failed to parse ACPI DMAR.  Disabling VT-d.
> 
> When I set iommu=force then vtd will be enabled but what should I do to 
> solve this better?
> Thank you and best Regards
> 
> Ralf
You cand find nice "howto" for 2.6.31 kernel compilation (also
with .config files) in the second half of this page -
http://wiki.xensource.com/xenwiki/XenParavirtOps.

I would still do "make menuconfig" with these provided .config files,
IIRC there are some debug options turned on, which can negatively impact
performance (which could matter on production servers).




$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
linux-2.6-xen
$ cd linux-2.6-xen
$ git reset --hard
$ git checkout -b xen/stable-2.6.31.x origin/xen/stable-2.6.31.x
$ git pull
$ git log | less

cd linux-2.6-xen
make clean
cp -a .config .config-old
wget -O .config
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/config-2.6.31.6-pvops-dom0-xen-master-x86_64
make oldconfig
make menuconfig (if you need to change something)
make bzImage
make modules
make modules_install
# in the following lines replace "version" with the actual kernel
version you're compiling.
cp -a .config /boot/config-version
cp -a System.map /boot/System.map-version
cp -a arch/x86/boot/bzImage /boot/vmlinuz-version
# And then generate initrd/initramfs image for your dom0 kernel, example
for Fedora/RHEL/CentOS:
mkinitrd -f /boot/initrd-version.img version


Regards

Matej


 



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Mike Viau

2010-Apr-25 23:36 UTC

head link

RE: [Xen-users] No DomU boot after upgrade to xen 4.0

> Sun, 25 Apr 2010 21:57:15 +0200 <zary@cvtisr.sk> wrote:
> On Sun, 2010-04-25 at 21:39 +0200, Ralf Hornik Mailings wrote:
> > Hi Christian,
> >
> > Christian Kujau schrieb:
> > > Has the Dom0 kernel CONFIG_TUN enabled? If so, is TUN/TAP
working?
> > >
> > No it isn''t. How do I enable it? The default "make
world" doesn''t seem
> > to do that
> >
> > However:
> >
> > make linux-2.6-xen-config CONFIGMODE=menuconfig
> >
> > as in 2.6.18 does not work as its downloading the 2.6.18 kernel then.
Is
> > there any documentation how to conmpile a custom kernel with xen 4 and
> > 2.6.31?
> >
> > For VTd I found out the following:
> >
> > xm dmesg:
> >
> > (XEN) [VT-D]dmar.c:679: Host address width 36
> > (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
> > (XEN) [VT-D]dmar.c:398:   dmaru->address = feb00000
> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:1b.0
> > (XEN) [VT-D]dmar.c:694: found ACPI_DMAR_DRHD:
> > (XEN) [VT-D]dmar.c:398:   dmaru->address = feb01000
> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:2.0
> > (XEN) [VT-D]dmar.c:334:   endpoint: 0:2.1
> > (XEN) [VT-D]dmar.c:447:   Non-existent device (0:2.1) is reported in
> > this DRHD''s scope!
> > (XEN) [VT-D]dmar.c:469:   The DRHD is invalid due to there are devices
> > under its scope are not PCI discoverable! Pls try option iommu=force
or
> > iommu=workaround_bios_bug if you really want VT-d
> > (XEN) Failed to parse ACPI DMAR.  Disabling VT-d.
> >
> > When I set iommu=force then vtd will be enabled but what should I do
to
> > solve this better?
> > Thank you and best Regards
> >
> > Ralf
> 
> You cand find nice "howto" for 2.6.31 kernel compilation (also
> with .config files) in the second half of this page -
> http://wiki.xensource.com/xenwiki/XenParavirtOps.
> 
> I would still do "make menuconfig" with these provided .config
files,
> IIRC there are some debug options turned on, which can negatively impact
> performance (which could matter on production servers).
> 
> 
Can anyone confirm if the debug options have been removed from the 
pv_ops kernel config reference on
http://wiki.xensource.com/xenwiki/XenParavirtOps yet or not?



I read on another thread that these options were degrading some network 
throughput.
> 
> 
> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> linux-2.6-xen
> $ cd linux-2.6-xen
> $ git reset --hard
> $ git checkout -b xen/stable-2.6.31.x origin/xen/stable-2.6.31.x
> $ git pull
> $ git log | less
> 
> cd linux-2.6-xen
> make clean
> cp -a .config .config-old
> wget -O .config
>
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/config-2.6.31.6-pvops-dom0-xen-master-x86_64
> make oldconfig
> make menuconfig (if you need to change something)
> make bzImage
> make modules
> make modules_install
> # in the following lines replace "version" with the actual kernel
> version you''re compiling.
> cp -a .config /boot/config-version
> cp -a System.map /boot/System.map-version
> cp -a arch/x86/boot/bzImage /boot/vmlinuz-version
> # And then generate initrd/initramfs image for your dom0 kernel, example
> for Fedora/RHEL/CentOS:
> mkinitrd -f /boot/initrd-version.img version
> 
Very nice +1
> 
> Regards
> 
> Matej
> 
> 
> 
>  		 	   		  
_________________________________________________________________
Hotmail & Messenger are available on your phone. Try now.
http://go.microsoft.com/?linkid=9724461

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Ralf Hornik

2010-Apr-26 16:10 UTC

head link

Re: [Xen-users] No DomU boot after upgrade to xen 4.0

Matej Zary schrieb:> You cand find nice "howto" for 2.6.31 kernel compilation (also
> with .config files) in the second half of this page -
> http://wiki.xensource.com/xenwiki/XenParavirtOps.
>
> I would still do "make menuconfig" with these provided .config
files,
> IIRC there are some debug options turned on, which can negatively impact
> performance (which could matter on production servers).Thank you Matej. With that howto I built a working kernel.
But why is the TUN disabled? I use a quite standard config for my hvms 
which then always will fail.

Another problem:

Sometimes I get this trace while booting.

[  257.653395] BUG: scheduling while atomic: xenwatch/28/0x00000002
[  257.791008] Modules linked in: [last unloaded: scsi_wait_scan]
[  257.926138] Pid: 28, comm: xenwatch Not tainted 2.6.31.13 #2
[  258.062008] Call Trace:
[  258.118138]  [<ffffffff81060a70>] __schedule_bug+0x5c/0x60
[  258.242138]  [<ffffffff8159c8af>] schedule+0xd1/0x8ec
[  258.359139]  [<ffffffff8120a347>] ? kvasprintf+0x45/0x6e
[  258.481140]  [<ffffffff8159e7d5>] ? _spin_unlock_irqrestore+0x34/0x3f
[  258.631139]  [<ffffffff8126bd80>] read_reply+0x9a/0x12f
[  258.749139]  [<ffffffff81080dfb>] ? autoremove_wake_function+0x0/0x38
[  258.899139]  [<ffffffff8126bfb8>] xs_talkv+0xc7/0x184
[  259.014140]  [<ffffffff8102ef25>] ? xen_force_evtchn_callback+0xd/0xf
[  259.162139]  [<ffffffff8126c19d>] xs_single+0x42/0x44
[  259.278138]  [<ffffffff8126c908>] xenbus_read+0x3d/0x54
[  259.404139]  [<ffffffff8126c9f5>] xenbus_gather+0xd6/0x166
[  259.531139]  [<ffffffff8126c8b7>] ? xenbus_printf+0xdd/0xf1
[  259.659139]  [<ffffffff8103034d>] ? kzalloc+0xf/0x11
[  259.772138]  [<ffffffff8126a8e5>] xenbus_read_driver_state+0x29/0x39
[  259.919138]  [<ffffffff81276d66>] pciback_attach+0x49/0x1b5
[  260.048138]  [<ffffffff8126ad25>] ? xenbus_switch_state+0x5d/0x97
[  260.187139]  [<ffffffff812773dd>] pciback_be_watch+0x251/0x263
[  260.321139]  [<ffffffff8159e7d5>] ? _spin_unlock_irqrestore+0x34/0x3f
[  260.469139]  [<ffffffff81205ea6>] ? __up_read+0x92/0x9c
[  260.593139]  [<ffffffff81084273>] ? up_read+0x9/0xb
[  260.706138]  [<ffffffff8126c5a3>] ? register_xenbus_watch+0xfd/0x108
[  260.852138]  [<ffffffff812778b8>] pciback_xenbus_probe+0x143/0x167
[  260.994139]  [<ffffffff8126d8d6>] xenbus_dev_probe+0x96/0x134
[  261.127008]  [<ffffffff812dccba>] driver_probe_device+0x97/0x13c
[  261.263139]  [<ffffffff812dcdda>] ? __device_attach+0x0/0x3c
[  261.395139]  [<ffffffff812dce0d>] __device_attach+0x33/0x3c
[  261.523138]  [<ffffffff812dc2c4>] bus_for_each_drv+0x51/0x88
[  261.654139]  [<ffffffff812dce98>] device_attach+0x5e/0x73
[  261.776138]  [<ffffffff812dc133>] bus_probe_device+0x1f/0x36
[  261.910139]  [<ffffffff812dac43>] device_add+0x3bd/0x546
[  262.031139]  [<ffffffff812026fa>] ? kobject_init+0x43/0x83
[  262.159138]  [<ffffffff812dade5>] device_register+0x19/0x1d
[  262.285008]  [<ffffffff8126d496>] xenbus_probe_node+0x126/0x1aa
[  262.422139]  [<ffffffff812dc5cb>] ? bus_for_each_dev+0x75/0x85
[  262.556138]  [<ffffffff8126d683>] xenbus_dev_changed+0x169/0x187
[  262.694139]  [<ffffffff8126db2d>] backend_changed+0x16/0x18
[  262.821139]  [<ffffffff8126bcb3>] xenwatch_thread+0x11a/0x14d
[  262.955139]  [<ffffffff81080dfb>] ? autoremove_wake_function+0x0/0x38
[  263.110139]  [<ffffffff8159e7d5>] ? _spin_unlock_irqrestore+0x34/0x3f
[  263.259139]  [<ffffffff8126bb99>] ? xenwatch_thread+0x0/0x14d
[  263.390138]  [<ffffffff810809e4>] kthread+0x8f/0x97
[  263.502138]  [<ffffffff81034d9a>] child_rip+0xa/0x20
[  263.617139]  [<ffffffff81033f27>] ? int_ret_from_sys_call+0x7/0x1b
[  263.760008]  [<ffffffff810346e1>] ? retint_restore_args+0x5/0x6
[  263.894138]  [<ffffffff81034d90>] ? child_rip+0x0/0x20

It is a known bug but how to solve this?
Best regards

Ralf
 


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Ralf Hornik Mailings

2010-Apr-26 16:28 UTC

head link

Re: [Xen-users] No DomU boot after upgrade to xen 4.0

Matej Zary schrieb:> You cand find nice "howto" for 2.6.31 kernel compilation (also
> with .config files) in the second half of this page -
> http://wiki.xensource.com/xenwiki/XenParavirtOps.
>
> I would still do "make menuconfig" with these provided .config
files,
> IIRC there are some debug options turned on, which can negatively impact
> performance (which could matter on production servers).Thank you Matej. With that howto I built a working kernel.
But why is the TUN disabled? I use a quite standard config for my hvms 
which then always will fail.

Another problem:

Sometimes I get this trace while booting.

[  257.653395] BUG: scheduling while atomic: xenwatch/28/0x00000002
[  257.791008] Modules linked in: [last unloaded: scsi_wait_scan]
[  257.926138] Pid: 28, comm: xenwatch Not tainted 2.6.31.13 #2
[  258.062008] Call Trace:
[  258.118138]  [<ffffffff81060a70>] __schedule_bug+0x5c/0x60
[  258.242138]  [<ffffffff8159c8af>] schedule+0xd1/0x8ec
[  258.359139]  [<ffffffff8120a347>] ? kvasprintf+0x45/0x6e
[  258.481140]  [<ffffffff8159e7d5>] ? _spin_unlock_irqrestore+0x34/0x3f
[  258.631139]  [<ffffffff8126bd80>] read_reply+0x9a/0x12f
[  258.749139]  [<ffffffff81080dfb>] ? autoremove_wake_function+0x0/0x38
[  258.899139]  [<ffffffff8126bfb8>] xs_talkv+0xc7/0x184
[  259.014140]  [<ffffffff8102ef25>] ? xen_force_evtchn_callback+0xd/0xf
[  259.162139]  [<ffffffff8126c19d>] xs_single+0x42/0x44
[  259.278138]  [<ffffffff8126c908>] xenbus_read+0x3d/0x54
[  259.404139]  [<ffffffff8126c9f5>] xenbus_gather+0xd6/0x166
[  259.531139]  [<ffffffff8126c8b7>] ? xenbus_printf+0xdd/0xf1
[  259.659139]  [<ffffffff8103034d>] ? kzalloc+0xf/0x11
[  259.772138]  [<ffffffff8126a8e5>] xenbus_read_driver_state+0x29/0x39
[  259.919138]  [<ffffffff81276d66>] pciback_attach+0x49/0x1b5
[  260.048138]  [<ffffffff8126ad25>] ? xenbus_switch_state+0x5d/0x97
[  260.187139]  [<ffffffff812773dd>] pciback_be_watch+0x251/0x263
[  260.321139]  [<ffffffff8159e7d5>] ? _spin_unlock_irqrestore+0x34/0x3f
[  260.469139]  [<ffffffff81205ea6>] ? __up_read+0x92/0x9c
[  260.593139]  [<ffffffff81084273>] ? up_read+0x9/0xb
[  260.706138]  [<ffffffff8126c5a3>] ? register_xenbus_watch+0xfd/0x108
[  260.852138]  [<ffffffff812778b8>] pciback_xenbus_probe+0x143/0x167
[  260.994139]  [<ffffffff8126d8d6>] xenbus_dev_probe+0x96/0x134
[  261.127008]  [<ffffffff812dccba>] driver_probe_device+0x97/0x13c
[  261.263139]  [<ffffffff812dcdda>] ? __device_attach+0x0/0x3c
[  261.395139]  [<ffffffff812dce0d>] __device_attach+0x33/0x3c
[  261.523138]  [<ffffffff812dc2c4>] bus_for_each_drv+0x51/0x88
[  261.654139]  [<ffffffff812dce98>] device_attach+0x5e/0x73
[  261.776138]  [<ffffffff812dc133>] bus_probe_device+0x1f/0x36
[  261.910139]  [<ffffffff812dac43>] device_add+0x3bd/0x546
[  262.031139]  [<ffffffff812026fa>] ? kobject_init+0x43/0x83
[  262.159138]  [<ffffffff812dade5>] device_register+0x19/0x1d
[  262.285008]  [<ffffffff8126d496>] xenbus_probe_node+0x126/0x1aa
[  262.422139]  [<ffffffff812dc5cb>] ? bus_for_each_dev+0x75/0x85
[  262.556138]  [<ffffffff8126d683>] xenbus_dev_changed+0x169/0x187
[  262.694139]  [<ffffffff8126db2d>] backend_changed+0x16/0x18
[  262.821139]  [<ffffffff8126bcb3>] xenwatch_thread+0x11a/0x14d
[  262.955139]  [<ffffffff81080dfb>] ? autoremove_wake_function+0x0/0x38
[  263.110139]  [<ffffffff8159e7d5>] ? _spin_unlock_irqrestore+0x34/0x3f
[  263.259139]  [<ffffffff8126bb99>] ? xenwatch_thread+0x0/0x14d
[  263.390138]  [<ffffffff810809e4>] kthread+0x8f/0x97
[  263.502138]  [<ffffffff81034d9a>] child_rip+0xa/0x20
[  263.617139]  [<ffffffff81033f27>] ? int_ret_from_sys_call+0x7/0x1b
[  263.760008]  [<ffffffff810346e1>] ? retint_restore_args+0x5/0x6
[  263.894138]  [<ffffffff81034d90>] ? child_rip+0x0/0x20

It is a known bug but how to solve this?
Best regards

Ralf

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Ralf Hornik Mailings

2010-Apr-26 18:27 UTC

head link

Re: [Xen-users] No DomU boot after upgrade to xen 4.0

Ralf Hornik Mailings schrieb:

Additional Info: It always happens when assigning a pci device to a hvm 
via passthrough and boot it.
After 4 or 5 traces the domu boots then...>
> [  257.653395] BUG: scheduling while atomic: xenwatch/28/0x00000002
> [  257.791008] Modules linked in: [last unloaded: scsi_wait_scan]
> [  257.926138] Pid: 28, comm: xenwatch Not tainted 2.6.31.13 #2
> [  258.062008] Call Trace:
> [  258.118138]  [<ffffffff81060a70>] __schedule_bug+0x5c/0x60
> [  258.242138]  [<ffffffff8159c8af>] schedule+0xd1/0x8ec
> [  258.359139]  [<ffffffff8120a347>] ? kvasprintf+0x45/0x6e
> [  258.481140]  [<ffffffff8159e7d5>] ?
_spin_unlock_irqrestore+0x34/0x3f
> [  258.631139]  [<ffffffff8126bd80>] read_reply+0x9a/0x12f
> [  258.749139]  [<ffffffff81080dfb>] ?
autoremove_wake_function+0x0/0x38
> [  258.899139]  [<ffffffff8126bfb8>] xs_talkv+0xc7/0x184
> [  259.014140]  [<ffffffff8102ef25>] ?
xen_force_evtchn_callback+0xd/0xf
> [  259.162139]  [<ffffffff8126c19d>] xs_single+0x42/0x44
> [  259.278138]  [<ffffffff8126c908>] xenbus_read+0x3d/0x54
> [  259.404139]  [<ffffffff8126c9f5>] xenbus_gather+0xd6/0x166
> [  259.531139]  [<ffffffff8126c8b7>] ? xenbus_printf+0xdd/0xf1
> [  259.659139]  [<ffffffff8103034d>] ? kzalloc+0xf/0x11
> [  259.772138]  [<ffffffff8126a8e5>]
xenbus_read_driver_state+0x29/0x39
> [  259.919138]  [<ffffffff81276d66>] pciback_attach+0x49/0x1b5
> [  260.048138]  [<ffffffff8126ad25>] ? xenbus_switch_state+0x5d/0x97
> [  260.187139]  [<ffffffff812773dd>] pciback_be_watch+0x251/0x263
> [  260.321139]  [<ffffffff8159e7d5>] ?
_spin_unlock_irqrestore+0x34/0x3f
> [  260.469139]  [<ffffffff81205ea6>] ? __up_read+0x92/0x9c
> [  260.593139]  [<ffffffff81084273>] ? up_read+0x9/0xb
> [  260.706138]  [<ffffffff8126c5a3>] ?
register_xenbus_watch+0xfd/0x108
> [  260.852138]  [<ffffffff812778b8>] pciback_xenbus_probe+0x143/0x167
> [  260.994139]  [<ffffffff8126d8d6>] xenbus_dev_probe+0x96/0x134
> [  261.127008]  [<ffffffff812dccba>] driver_probe_device+0x97/0x13c
> [  261.263139]  [<ffffffff812dcdda>] ? __device_attach+0x0/0x3c
> [  261.395139]  [<ffffffff812dce0d>] __device_attach+0x33/0x3c
> [  261.523138]  [<ffffffff812dc2c4>] bus_for_each_drv+0x51/0x88
> [  261.654139]  [<ffffffff812dce98>] device_attach+0x5e/0x73
> [  261.776138]  [<ffffffff812dc133>] bus_probe_device+0x1f/0x36
> [  261.910139]  [<ffffffff812dac43>] device_add+0x3bd/0x546
> [  262.031139]  [<ffffffff812026fa>] ? kobject_init+0x43/0x83
> [  262.159138]  [<ffffffff812dade5>] device_register+0x19/0x1d
> [  262.285008]  [<ffffffff8126d496>] xenbus_probe_node+0x126/0x1aa
> [  262.422139]  [<ffffffff812dc5cb>] ? bus_for_each_dev+0x75/0x85
> [  262.556138]  [<ffffffff8126d683>] xenbus_dev_changed+0x169/0x187
> [  262.694139]  [<ffffffff8126db2d>] backend_changed+0x16/0x18
> [  262.821139]  [<ffffffff8126bcb3>] xenwatch_thread+0x11a/0x14d
> [  262.955139]  [<ffffffff81080dfb>] ?
autoremove_wake_function+0x0/0x38
> [  263.110139]  [<ffffffff8159e7d5>] ?
_spin_unlock_irqrestore+0x34/0x3f
> [  263.259139]  [<ffffffff8126bb99>] ? xenwatch_thread+0x0/0x14d
> [  263.390138]  [<ffffffff810809e4>] kthread+0x8f/0x97
> [  263.502138]  [<ffffffff81034d9a>] child_rip+0xa/0x20
> [  263.617139]  [<ffffffff81033f27>] ? int_ret_from_sys_call+0x7/0x1b
> [  263.760008]  [<ffffffff810346e1>] ? retint_restore_args+0x5/0x6
> [  263.894138]  [<ffffffff81034d90>] ? child_rip+0x0/0x20
>
> It is a known bug but how to solve this?
> Best regards
>
> Ralf
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Xen users - Apr 2010 - No DomU boot after upgrade to xen 4.0

[Xen-users] No DomU boot after upgrade to xen 4.0

Re: [Xen-users] No DomU boot after upgrade to xen 4.0

Re: [Xen-users] No DomU boot after upgrade to xen 4.0

Re: Re: [Xen-users] No DomU boot after upgrade to xen 4.0

RE: [Xen-users] No DomU boot after upgrade to xen 4.0

Re: [Xen-users] No DomU boot after upgrade to xen 4.0

Re: [Xen-users] No DomU boot after upgrade to xen 4.0

Re: [Xen-users] No DomU boot after upgrade to xen 4.0