Re: [Xen-users] pci device not owned by pciback.

[James Pifer <jep@xxxxxxxxxxxxxxxx>]

On Tue, 2010-04-27 at 17:04 +0200, Mark Hurenkamp wrote:
> Hi James,
> 
> 
> >> Error: pci: improper device assignment specified: pci: 0000:0e:04.0 must
> >> be co-assigned to the same guest with 0000:0e:04.0, but it is not owned
> >> by pciback.
> What Xen version are you using? Are you using a pvops based kernel? Or a
> 'classic' xen kernel based on 2.6.18+patches?
> Are you sure it mentions the exact same id twice? It is more likely to
> report two almost identical ids, with a small difference in the last
> digit... (e.g. 0000:0e:04.1 must be co-assigned with 0000:0e:04.0)
> 
> >> How do I make this card owned by pciback on reboot. Do I need to use the
> >> hide parameter on the kernel line on boot?
> >
> > It says to add something like this to the module line:
> > pciback.hide=(01:00.0)(00:02.0)
> For older kernel versions, you should use the command as stated above. For
> newer versions, the module is renamed to xen-pciback, and you'd state:
> xen-pciback.hide=(01:00.0)(00:02.0)
> 
> > This page talks about VT and my domU is a PV. Does this same pciback
> > apply?
> Hiding is the same for VTd and for PV. However, the 'co-assigned' error
> message is typical for VTd, it doesn't allow devices on the same PCI bus
> to be divided over more than one vm.
> If you are passing through a single device to a PV machine, and xen gives
> you the above mentioned 'co-assigned' error, it is probably due to a bug
> in xen (which appeared a while ago, but has since been fixed).


I tried adding this to my modules line:
module /boot/vmlinuz-2.6.27.19-5-xen 
root=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part2 
resume=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part1 
splash=silent showopts vga=0x317 pciback.hide=(0e:04.0)(0e:04.1)

When the system came up it looks like the host server still took control
of the scsi card:
0e:04.0 SCSI storage controller: Atto Technology Ultra320 SCSI Host Adapter 
(rev 08)
        Subsystem: Atto Technology ExpressPCI UL5D Low Profile
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 30
        I/O ports at 5000 [size=256]
        Memory at fafc0000 (64-bit, non-prefetchable) [size=256K]
        Memory at faf80000 (64-bit, non-prefetchable) [size=256K]
        [virtual] Expansion ROM at e8100000 [disabled] [size=1M]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 
Enable-
        Capabilities: [68] PCI-X non-bridge device
        Kernel driver in use: mptspi
        Kernel modules: mptspi

0e:04.1 SCSI storage controller: Atto Technology Ultra320 SCSI Host Adapter 
(rev 08)
        Subsystem: Atto Technology ExpressPCI UL5D Low Profile
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 37
        I/O ports at 5400 [size=256]
        Memory at faf40000 (64-bit, non-prefetchable) [size=256K]
        Memory at faf00000 (64-bit, non-prefetchable) [size=256K]
        [virtual] Expansion ROM at e8200000 [disabled] [size=1M]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 
Enable-
        Capabilities: [68] PCI-X non-bridge device
        Kernel driver in use: mptspi
        Kernel modules: mptspi

I tried unloading mptspi and it unloads, but I still can't start the
virtual machine assigned those cards. Same error as before:
Error: pci: improper device assignment specified: pci: 0000:0e:04.0 must be 
co-assigned to the same guest with 0000:0e:04.0, but it is not owned by pciback.

It's weird that it worked yesterday, but the difference was we plugged
in the DLT drive AFTER the hosts system was already running. 

Looked at dmesg:
# dmesg | grep pciback
Command line: 
root=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part2 
resume=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part1 
splash=silent vga=0x317 pciback.hide=(0e:04.0)(0e:04.1)
Kernel command line: 
root=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part2 
resume=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part1 
splash=silent vga=0x317 pciback.hide=(0e:04.0)(0e:04.1)
Unknown boot option `pciback.hide=(0e:04.0)(0e:04.1)': ignoring

So then I tried xen-pciback:
# dmesg | grep pciback
Command line: 
root=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part2 
resume=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part1 
splash=silent vga=0x317 xen-pciback.hide=(0e:04.0)(0e:04.1)
Kernel command line: 
root=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part2 
resume=/dev/disk/by-id/cciss-3600508b1001030364643393433300000-part1 
splash=silent vga=0x317 xen-pciback.hide=(0e:04.0)(0e:04.1)
Unknown boot option `xen-pciback.hide=(0e:04.0)(0e:04.1)': ignoring

Does this mean it is not compiled in the kernel? That would really suck.

What would my next step be?

Thanks,
James


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