On Wed, Jun 22, 2016 at 11:49 AM, Francis Greaves francis@choughs.net wrote:
More information... I have pcifront showing as a module in the DomU and the usb shows in dmesg as: [ 3.167543] usbcore: registered new interface driver usbfs [ 3.167563] usbcore: registered new interface driver hub [ 3.167585] usbcore: registered new device driver usb [ 3.196056] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.196060] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.196064] usb usb1: Product: EHCI Host Controller [ 3.196068] usb usb1: Manufacturer: Linux 3.2.0-4-686-pae ehci_hcd [ 3.196071] usb usb1: SerialNumber: 0000:00:00.0 [ 3.508036] usb 1-1: new high-speed USB device number 2 using ehci_hcd [ 19.064072] usb 1-1: device not accepting address 2, error -110 [ 19.176070] usb 1-1: new high-speed USB device number 3 using ehci_hcd [ 34.732067] usb 1-1: device not accepting address 3, error -110 [ 34.844082] usb 1-1: new high-speed USB device number 4 using ehci_hcd [ 45.280073] usb 1-1: device not accepting address 4, error -110 [ 45.392067] usb 1-1: new high-speed USB device number 5 using ehci_hcd [ 55.824112] usb 1-1: device not accepting address 5, error -110
Can you post your question with your guest config file, lspci in dom0, and lspci in your domU to xen-users? There will be a lot more eyeballs there to help you get things sorted out.
I am looking at xl dmesg in Dom0 where there are some messages relating to the PCI usb: [VT-D] It's disallowed to assign 0000:00:1a.0 with shared RMRR at 7b800000 for Dom6. (XEN) XEN_DOMCTL_assign_device: assign 0000:00:1a.0 to dom6 failed (-1) (XEN) [VT-D] It's risky to assign 0000:00:1a.0 with shared RMRR at 7b800000 for Dom7. (XEN) [VT-D] It's risky to assign 0000:00:1a.0 with shared RMRR at 7b800000 for Dom8. (XEN) [VT-D] It's risky to assign 0000:00:1a.0 with shared RMRR at 7b800000 for Dom9. (XEN) [VT-D] It's risky to assign 0000:00:1a.0 with shared RMRR at 7b800000 for Dom10.
This looks like you tried once to start your guest without "rdm_policy=relaxed" (which failed), and then tried it four times with "rdm_policy=relaxed" (which succeeded). Other than warning that there's a shared RMRR (which could potentially be a security risk), everything here looks normal.
There's a possibility that the shared RMRR is what's tripping things up, but it's not very likely.
In the as an aside... I just get blocks on the screen after the scrubbing message, and no text. I see there is a message: (XEN) Xen is relinquishing VGA console. How can I prevent this? Is there something wrong with my /etc/default/grub
... GRUB_CMDLINE_LINUX="crashkernel=auto intremap=no_x2apic_optout" GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=13312M,max:14336M dom0_max_vcpus=6 dom0_vcpus_pin" GRUB_GFXMODE=1024x768 GRUB_GFXPAYLOAD_LINUX=keep GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="console=hvc0 earlyprintk=xen"
Could you post this as a separate message to xen-users?
Thanks. -George