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

Re: [Xen-users] pciback and pci passtrought problems


  • To: Velten Spägele <xen@xxxxxxxxx>
  • From: Paul Schulze <avlex@xxxxxxx>
  • Date: Tue, 10 Mar 2009 12:04:48 +0100
  • Cc: Xen Users <xen-users@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 10 Mar 2009 04:06:07 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-pgp-agent:x-mailer; b=GBM9Tog8NLKTspjImVJ8qBCjPtphl182ZEWIQJ6FN5DtmgoKCv59IFj8wilLlGuTt1 fC5j9oFxcZllaDuQIUiHeQyFKtfYoo/U+tVwtDkt1bCT4yssRJj9rr8qTcyl5hW/WPV0 bhtyu+mLv3lrQgICMyZkuj3ECJpSigPd6AeeE=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Velten,

On 5 Mar 2009, at 20:09, Velten Spägele wrote:

so can i use the last xen release only with very special Hardware, or would it be possible to use it like in the older versions ?


I have the same problem, but it has nothing to do with PCI passthrough in general. It seems to be a problem with passing devices in a specific state to a DomU.

I currently have a DomU which gets all the USB controllers on my mainboard passed through, or at least is supposed to. However, when I start up the domain it complains about device 00:13.2, which is an USB EHCI controller and I think the only controller that has a device connected to it, because that device does not show up in lsusb inside the DomU. The second Controller (or rather the first, 00:12.2) works fine. I haven't been able to test what happens if I unplug the device, the case LCD to be more precise, because the system is currently running and I don't like working inside running systems, so this is only a hunch.

In your case, the device might be in that (undesired) state, because it was already initialized/used by a device driver in Dom0, so the first thing to try would be to use a kernel with pciback built in. That way, it will be able to grab your PCI devices on boot as you specified on the command-line (which shouldn't do much right now). An alternative would be to blacklist the device driver module (8139too in your case), to prevent the system from loading it automatically on boot. However, in both cases, you will not be able to start up your DomU again without rebooting, after you try to use it in Dom0.

If that does not help, removing that specific device from the DomU "fixes" the problem for me and my DomU starts up normally with all the other devices visible inside. Since the device that causes the problem on your system is a NIC, this might be a good idea anyways, since you will need it in Dom0 with a bridge and a virtual NIC in your Fli4L DomU in order to have other DomUs and Dom0 access your LAN (if you're doing what I think you are :) ).

I hope this helps you a little,


Paul.

- --
Paul Schulze
Mail: avlex82@xxxxxxxxx

Why can't a programmer tell the difference between Halloween and Christmas?
Because OCT31 = DEC25.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iEYEARECAAYFAkm2SV4ACgkQj2zIQLJNnKNYkACfdgEYkCXyDg4HTkT0yGxYbfO8
bZ8AoO4N4Pz2f+x0DWa0OJy2gtkgCD7y
=zwvK
-----END PGP SIGNATURE-----

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


 


Rackspace

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