[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PATCH: Re: [Xen-devel] Error: Device 0 (vkbd) is already connected.



On Wed, Apr 11, 2007 at 03:32:19PM -0600, Alex Williamson wrote:
> Hi,
> 
>    Is vfb working well lately?  I thought I'd test it out on ia64 and it
> works great, but only once per boot.  If I stop the domain and restart
> it, I get the following:
> 
> Error: Device 0 (vkbd) is already connected.
> 
> To make sure this isn't an ia64 anomaly, I tried it on an x86_64 system.
> Same thing, works the first time, reboot the domain and it's broken.  I
> see someone reported a similar issue last month, but there was no
> response:
> 
> http://lists.xensource.com/archives/html/xen-devel/2007-03/msg01141.html
> 
> The backtrace in xend.log looks like this:
> 
> [2007-04-11 15:23:07 2659] ERROR (__init__:1072) XendDomainInfo.initDomain: 
> exce
> ption occurred
> Traceback (most recent call last):
>   File "//usr/lib/python/xen/xend/XendDomainInfo.py", line 1518, in 
> _initDomain
>     self._createDevices()
>   File "//usr/lib/python/xen/xend/XendDomainInfo.py", line 1316, in 
> _createDevices
>     devid = self._createDevice(devclass, config)
>   File "//usr/lib/python/xen/xend/XendDomainInfo.py", line 1292, in 
> _createDevice
>     return self.getDeviceController(deviceClass).createDevice(devConfig)
>   File "//usr/lib/python/xen/xend/server/DevController.py", line 111, in 
> createDevice
>     raise VmError("Device %s is already connected." % dev_str)
> VmError: Device 0 (vkbd) is already connected.
> 
> My domain config file has the following options to enable vfb:
> 
> vfb = [ 'type=vnc, vnclisten=0.0.0.0, vncunused=1' ]
> extra = "console=ttyS0 xencons=ttyS video=xenfb"
> 
> Is anyone able to make this work reliably more than once?  Thanks,

I've done some testing & this is (reasonably) reproducable on x86 too. On
some occassions I can't even get it to start once, other times it works
a couple of times.

After some debugging I think I've identified a race condition:

 1. XendDomainInfo._createDevices() gets a list of devices to be created
    from XendConfig.ordered_device_refs()

    On a simple guest, this has 4 devices, vfb, vbd, vif, vkbd - in that
    order

 2. It iterates over those devices, creating the appropriate DevController
    subclass instance, and then calling createDevice() on that object.

 3. When createDevice() is called on the vfb  device, it spawns xen-vncfb
    daemon.

 4. During startup xen-vncfb writes into the backend paths

            /local/domain/0/backend/vfb/0

     And

            /local/domain/0/backend/vkbd/0

 5. When createDevice() is called on the vkbd device in XenD, if the 2nd
    xenstore path write from step 4 has occurred, then you'll hit the
    'Device 0 (vkbd) is already connected' error. If the 2nd path write
    didn't complete yet then everything is fine.


I think the reason it often works once after boot is that loading xen-vncfb
from disk the first time around is just enough of a slow down to ensure step 
5 occurs before the 2nd xenstore write in step 4 has occurred.


The key seems to be to ensure the vkbd device is initialized in xenstore
before the vfb device - this ensures all the xenstored setup from XenD
is complete before the xen-vncfb daemon starts. I'm attaching a patch
which implements this - I've been able to create & destroy a domain many
times over with this patch & never hit the error message anymore.


   Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>


Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Attachment: xen-vkbd-order.patch
Description: Text document

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.