On 01-31 19:58, Ian Campbell wrote: > On Tue, 2012-01-31 at 18:41 +0100, Witold Baryluk wrote: > > On 01-31 16:51, Ian Campbell wrote: > > > On Tue, 2012-01-31 at 12:32 +0100, Witold Baryluk wrote: > > > > I found NetBSD user/developer had very similar problem (when using xl > > > > as TOOLSTACK, > > > > just like me!) about year ago (Mar 2011). > > > > > > > > http://mail-index.netbsd.org/port-xen/2011/03/31/msg006552.html > > > > with some discussion, that NetBSD doesn't have gnttap implemented in > > > > kernel: > > > > > > I think that is correct and I'm afraid this will prevent the use of > > > either vfb or qdisk (which is what file:// becomes in the absence of > > > blktap, which freebsd does not have) disk backends. Userspace PV device > > > backends simply cannot work without a gnttab device. > > > > > > There has been some work on xen-unstable (by Roger Pau Monet) to make > > > file:// type disks use the in kernel vbd backend (which won't need vbd) > > > but this is still a work in progress and won't be in 4.1. Hopefully this > > > will be in in time for 4.2. > > > > > > As a workaround in the meantime you can use the FreeBSD equivalent of > > > losetup (vnconfig?) to manually turn your file:/path/etc into a > > > phy:/dev/vndN which will use the in kernel vbd backend. > > > > > > (I'm not a FreeBSD guy so I may have got some of the names above wrong) > > > > > > I do not know what you are talking about. Im using Debian's Xen and > > Debian/GNU Linux 3.2 kernel as dom0. The same happens with freebsd and linux > > kernels as domU. Clearly I expect Linux dom0 (and domU) to support > > gnttab. (btw. there is NO dom0 support in FreeBSD). > > Your bug report said: > movax-dev:/etc/xen# dpkg -l | grep -- -image > ii gnumach-image-1-xen-486 2:1.3.99.dfsg.git20111010-1 The GNU > version of the Mach microkernel > ii gnumach-image-1.3.99-xen-486 2:1.3.99.dfsg.git20111010-1 The GNU > version of the Mach microkernel for Xen > ii kfreebsd-image-9-xen 9.0-1 kernel > of FreeBSD 9 image (meta-package) > ii kfreebsd-image-9.0-1-xen 9.0-1 kernel > of FreeBSD 9.0 image > [...] > > so I'm sure you can see where I got the idea you might be running > Debian/kfreebsd from. >
Indeed, I may not stress this sufficiently in initial post. (there was uname -a and some host information, at the end, but I probably should start from it) > [...] > > I think this is because /dev/xen/gntdev file was provided by xen-evtchn > > or xenfs module in previous kernels (like 2.6.32 in squeeze), but is now > > in separate module (xen-gntdev). > > > > > > I performed 'lsmod' after reboot, and there was NO single xen releated > > module loaded, even after 'xl create ...'. So clearly something is not doing > > its job. I guess, 'xl' tool should make sure proper modules are loaded, > > or /etc/init.d/xen(d) should modprobe them. > > $ grep modprobe /etc/init.d/xen* > /etc/init.d/xend: modprobe xenfs 2>/dev/null > /etc/init.d/xend: modprobe xen-evtchn 2>/dev/null > > so it is loading some things but clearly it needs to load some more, > like xen-gntdev and xen-*back. > I guess, even with xl toolstack, a some parts of /etc/init.d/xend will be started, like modprobing, but is not yet done in sid. I think it is good to add this modprobes, but how about checking also in qemu-dm and quiting with error when it cannot open this devices in /dev/xen/ ? Currently qemu-dm is busy-looping there infinitly, using 100% CPU, and without giving good error message. Why qemu-dm is busy-looping anyway? Should there be some exit(1) or sleep(1) ? > > I loaded xen-gntdev xen-evtchn xen-blkback xen-netback (not in this > > order) manually, and now everything works. > > Great. Hope to see this changes in xen-utils-common soon. Good work! I'm using Debian/Linux Xen on few machines for like 5 years now, and it is awesome. Thanks. :) Regards, Witek -- Witold Baryluk JID: witold.baryluk // jabster.pl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
