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

[Xen-devel] Xenbus problems solved (soft of)

  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Jacob Gorm Hansen <jacobg@xxxxxxx>
  • Date: Thu, 6 Oct 2005 12:41:21 +0200
  • Delivery-date: Thu, 06 Oct 2005 10:38:54 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Z/ew4fAurwILfLqGADSQL7w9HS5WBeZH0xpGG3hFUqT62Z12HLcorM7LQK2rtILaFZ7XAaSka34ERP5laxthvmahypMlONiwQiyl8SQRvv53RI8j5acAmd/g2vlYDka1UsTpiU+QJT6xwLz/oC9XC4bDhwOuy40UHI8jh0LHtis=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>


I discovered that if I do not call xs_interface_close() in my tools
(especially the one calling xs_init() and introducing dom0), all
following xenbus transactions fail silently. They are logged as (T) in
the trace-file, but have no effect on what is actually in the store. I
suppose this is a bug in xenstored.

Also, with the evtchn fix from Stephan Berger I am now able to
successfully connect  a physical block device to my domU :-)

Another thing that I discovered is that the use of xenstore for error
messages is problematic. The backend will typically have a watch on
the node it is logging the error message to, causing infinite watch
trigger -> log error -> watch trigger loops.
The use of the store for error should probably be reconsidered.


Save time and bandwidth with EDelta: http://www.diku.dk/~jacobg/edelta/

Xen-devel mailing list



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