On Oct 23, 2006, at 2:56 AM, Tony Breeds wrote:

Hi all,
        I'm slowly working my way through a default run on xm-test on my
JS20 trying to determine if the tests that fail represent real problems with xen on PPC, or if they're showing problems with the tests themselves.

By correcting some of the create/* tests (patches posted to xen-devel)
XenPPC now passes that whole group.

In looking at the block-* tests, I see that the failures are due to the domU kernel including scsi support, which then causes a conflict on major
number 8, resulting in a lot of failures in xm-test.

If I try to do this manually, I get:
  Registering block device major 8
  register_blkdev: cannot get major 8 for sd
  xen_blk: can't get major 8 with name sd
  vbd vbd-2065: 19 xlvbd_add at /local/domain/0/backend/vbd/1/2065

The problem is described in:
http://wiki.xensource.com/xenwiki/XenFaq#head- baa7000e8fc28fd168650114dd2741b7f21da8fa

Where we are told:
  "all you need to do is disable the entire scsi subsystem"

GTFOOH! (said in my best soprano)
There has to be a better way!


I'd like to know how everyone feels about creating a "make xen_domu_config"
target which turns of the driver that aren't needed?

I think it is unacceptable.
Seriously, it is really important to XenPPC that the same kernel image work everywhere

Or alternatively suggestions on how to keep a unified kernel image that "works"?

One alternative is to use the ide devices
  $ xm block-attach 3 file:/root/disk2 hdb2 w
Works just fine, for disks.
There is also the "xvd" (Xen Virtual Block Device) which can be attached using xen major 20
  $  xm block-attach 6 file:/root/disk2 xvda w

Which translates into (202,0), which is lanana blessed:
http://www.be.kernel.org/pub/linux/docs/lanana/device-list/ devices-2.6+.txt

I had to:
  mknod /dev/xvda b 202 0

to be able to mount it.

I do not know what the official/current Xen support for "xvd", but it is a good question, I'll ask.


Xen-ppc-devel mailing list

Reply via email to