Is anyone successfully using pvusb under 3.4-testing and 2.6.18-xen? I''ve been trying to figure out why my windows drivers are hanging after the first or second BULK packet is sent, and only just occurred to me to see if it actually works under Linux, and it doesn''t. The device I''m testing with is a flash memory stick, and basically the first BULK packet gets sent successfully, which I assume is a read request, and then a packet is sent to be filled with data read from the flash device and it either hangs there, or comes back with 0 bytes and then the next packet hangs - usb_submit_urb returns success but the complete callback routine is never called. Under Linux DomU (frontend), I get: Sep 3 20:33:12 smtp2 kernel: usbcore: registered new driver usb-storage Sep 3 20:33:12 smtp2 kernel: USB Mass Storage support registered. Sep 3 20:33:12 smtp2 kernel: usb-storage: device found at 2 Sep 3 20:33:12 smtp2 kernel: usb-storage: waiting for device to settle before scanning Sep 3 20:33:23 smtp2 kernel: vusb vusb-0: Unlink after no-IRQ? Controller is probably using the wrong IRQ. Nothing is logged in the backend. lsusb -v under the DomU appears to be just fine - everything is reported correctly. Any ideas? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cc''ing the PVUSB author. -- Keir On 03/09/2009 11:42, "James Harper" <james.harper@bendigoit.com.au> wrote:> Is anyone successfully using pvusb under 3.4-testing and 2.6.18-xen? > > I''ve been trying to figure out why my windows drivers are hanging after > the first or second BULK packet is sent, and only just occurred to me to > see if it actually works under Linux, and it doesn''t. > > The device I''m testing with is a flash memory stick, and basically the > first BULK packet gets sent successfully, which I assume is a read > request, and then a packet is sent to be filled with data read from the > flash device and it either hangs there, or comes back with 0 bytes and > then the next packet hangs - usb_submit_urb returns success but the > complete callback routine is never called. > > Under Linux DomU (frontend), I get: > > Sep 3 20:33:12 smtp2 kernel: usbcore: registered new driver usb-storage > Sep 3 20:33:12 smtp2 kernel: USB Mass Storage support registered. > Sep 3 20:33:12 smtp2 kernel: usb-storage: device found at 2 > Sep 3 20:33:12 smtp2 kernel: usb-storage: waiting for device to settle > before scanning > Sep 3 20:33:23 smtp2 kernel: vusb vusb-0: Unlink after no-IRQ? > Controller is probably using the wrong IRQ. > > Nothing is logged in the backend. > > lsusb -v under the DomU appears to be just fine - everything is reported > correctly. > > Any ideas? > > Thanks > > James > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi James,>> Is anyone successfully using pvusb under 3.4-testing and 2.6.18-xen?Could you explain more details about the issue? - changeset of xen/kernel, arch (x86 or x64) - H/W (CPU, M/B, USB Host controller, ...) - USB device (Device name and VendorId/ProdId) - your setting (show me xenstore entries)>> The device I''m testing with is a flash memory stick, and basically the >> first BULK packet gets sent successfully, which I assume is a read >> request, and then a packet is sent to be filled with data read from the >> flash device and it either hangs there, or comes back with 0 bytes and >> then the next packet hangs - usb_submit_urb returns success but the >> complete callback routine is never called.Failure of the SCSI-device scanning did not occur with the storage devices that I''ve tested. But, this error might happen due to the mismatch of the urb->transfer_flags. I''ve seen this in the very early version of pvusb. Regards, Noboru Keir Fraser wrote:> Cc''ing the PVUSB author. > > -- Keir > > On 03/09/2009 11:42, "James Harper" <james.harper@bendigoit.com.au> wrote: > >> Is anyone successfully using pvusb under 3.4-testing and 2.6.18-xen? >> >> I''ve been trying to figure out why my windows drivers are hanging after >> the first or second BULK packet is sent, and only just occurred to me to >> see if it actually works under Linux, and it doesn''t. >> >> The device I''m testing with is a flash memory stick, and basically the >> first BULK packet gets sent successfully, which I assume is a read >> request, and then a packet is sent to be filled with data read from the >> flash device and it either hangs there, or comes back with 0 bytes and >> then the next packet hangs - usb_submit_urb returns success but the >> complete callback routine is never called. >> >> Under Linux DomU (frontend), I get: >> >> Sep 3 20:33:12 smtp2 kernel: usbcore: registered new driver usb-storage >> Sep 3 20:33:12 smtp2 kernel: USB Mass Storage support registered. >> Sep 3 20:33:12 smtp2 kernel: usb-storage: device found at 2 >> Sep 3 20:33:12 smtp2 kernel: usb-storage: waiting for device to settle >> before scanning >> Sep 3 20:33:23 smtp2 kernel: vusb vusb-0: Unlink after no-IRQ? >> Controller is probably using the wrong IRQ. >> >> Nothing is logged in the backend. >> >> lsusb -v under the DomU appears to be just fine - everything is reported >> correctly. >> >> Any ideas? >> >> Thanks >> >> James >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Hi James, > > >> Is anyone successfully using pvusb under 3.4-testing and2.6.18-xen?> > Could you explain more details about the issue? > > - changeset of xen/kernel, arch (x86 or x64)Xen is very recent 3.4-testing.hg Kernel is latest 2.6.18-xen.hg x64> - H/W (CPU, M/B, USB Host controller, ...)# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : Dual-Core AMD Opteron(tm) Processor 1210 stepping : 3 cpu MHz : 1800.006 cache size : 1024 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni cx16 lahf_lm cmp_legacy cr8_legacy bogomips : 3601.83 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc> - USB device (Device name and VendorId/ProdId)# lsusb -v Bus 001 Device 006: ID 0204:6025 Chipsbank Microelectronics Co., Ltd CBM2080 Flash drive controller Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0204 Chipsbank Microelectronics Co., Ltd idProduct 0x6025 CBM2080 Flash drive controller bcdDevice 1.00 iManufacturer 1 USB2.0 iProduct 2 Flash Disk iSerial 3 229360546401 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0001 Self Powered> - your setting (show me xenstore entries)# xenstore-ls /local/domain/2/device/vusb 0 = "" backend-id = "0" backend = "/local/domain/0/backend/vusb/2/0" state = "4" ring-ref = "797" event-channel = "10" # xenstore-ls /local/domain/0/backend/vusb/2/0 frontend-id = "2" frontend = "/local/domain/2/device/vusb/0" num-ports = "8" port-1 = "2" port-2 = "0" port-3 = "0" port-4 = "0" port-5 = "0" port-6 = "0" port-7 = "0" port-8 = "0" state = "4"> > >> The device I''m testing with is a flash memory stick, and basicallythe> >> first BULK packet gets sent successfully, which I assume is a read > >> request, and then a packet is sent to be filled with data read fromthe> >> flash device and it either hangs there, or comes back with 0 bytesand> >> then the next packet hangs - usb_submit_urb returns success but the > >> complete callback routine is never called. > > Failure of the SCSI-device scanning did not occur with the storage > devices that I''ve tested. > > But, this error might happen due to the mismatch of the > urb->transfer_flags. > I''ve seen this in the very early version of pvusb.I have tested a few combinations of transfer_flags and haven''t had any success, but haven''t investigated that thoroughly Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > # lsusb -v > > Bus 001 Device 006: ID 0204:6025 Chipsbank Microelectronics Co., LtdCBM2080> Flash drive controller > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.10For some reason the device has booted up as USB 1.10 instead of USB 2.00. It didn''t work any better when it booted as USB 2.00 though. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, > I have tested a few combinations of transfer_flags and haven''t had any > success, but haven''t investigated that thoroughly I will try in the latest tip with my environment. However, I do not have AMD Opteron platform. I can test only with Intel Core2 CPU and USB host controller that included in the Intel ICH. The difference of the USB host controller''s behavior might cause the issue. Please inform me of the chipset or M/B that you are using and show me lsusb outputs from both dom0 and domU. BTW, I''m now working for some pvusb enhancements. New device probe mechanism, bugfix of hotplug issue that you pointed out and xend support are coming in October or November. Regards, Noboru James Harper wrote:>> Hi James, >> >>>> Is anyone successfully using pvusb under 3.4-testing and > 2.6.18-xen? >> Could you explain more details about the issue? >> >> - changeset of xen/kernel, arch (x86 or x64) > > Xen is very recent 3.4-testing.hg > Kernel is latest 2.6.18-xen.hg x64 > >> - H/W (CPU, M/B, USB Host controller, ...) > > # cat /proc/cpuinfo > > processor : 0 > vendor_id : AuthenticAMD > cpu family : 15 > model : 67 > model name : Dual-Core AMD Opteron(tm) Processor 1210 > stepping : 3 > cpu MHz : 1800.006 > cache size : 1024 KB > physical id : 0 > siblings : 1 > core id : 0 > cpu cores : 1 > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat > clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext > 3dnow up pni cx16 lahf_lm cmp_legacy cr8_legacy > bogomips : 3601.83 > TLB size : 1024 4K pages > clflush size : 64 > cache_alignment : 64 > address sizes : 40 bits physical, 48 bits virtual > power management: ts fid vid ttp tm stc > >> - USB device (Device name and VendorId/ProdId) > > # lsusb -v > > Bus 001 Device 006: ID 0204:6025 Chipsbank Microelectronics Co., Ltd > CBM2080 Flash drive controller > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x0204 Chipsbank Microelectronics Co., Ltd > idProduct 0x6025 CBM2080 Flash drive controller > bcdDevice 1.00 > iManufacturer 1 USB2.0 > iProduct 2 Flash Disk > iSerial 3 229360546401 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 32 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 8 Mass Storage > bInterfaceSubClass 6 SCSI > bInterfaceProtocol 80 Bulk (Zip) > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 1 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Device Status: 0x0001 > Self Powered > >> - your setting (show me xenstore entries) > > # xenstore-ls /local/domain/2/device/vusb > 0 = "" > backend-id = "0" > backend = "/local/domain/0/backend/vusb/2/0" > state = "4" > ring-ref = "797" > event-channel = "10" > > # xenstore-ls /local/domain/0/backend/vusb/2/0 > frontend-id = "2" > frontend = "/local/domain/2/device/vusb/0" > num-ports = "8" > port-1 = "2" > port-2 = "0" > port-3 = "0" > port-4 = "0" > port-5 = "0" > port-6 = "0" > port-7 = "0" > port-8 = "0" > state = "4" > >>>> The device I''m testing with is a flash memory stick, and basically > the >>>> first BULK packet gets sent successfully, which I assume is a read >>>> request, and then a packet is sent to be filled with data read from > the >>>> flash device and it either hangs there, or comes back with 0 bytes > and >>>> then the next packet hangs - usb_submit_urb returns success but the >>>> complete callback routine is never called. >> Failure of the SCSI-device scanning did not occur with the storage >> devices that I''ve tested. >> >> But, this error might happen due to the mismatch of the >> urb->transfer_flags. >> I''ve seen this in the very early version of pvusb. > > I have tested a few combinations of transfer_flags and haven''t had any > success, but haven''t investigated that thoroughly > > Thanks > > James > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I just tested on an Intel box and had the same problems. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> Bus 001 Device 006: ID 0204:6025 Chipsbank Microelectronics Co., Ltd> CBM2080 >> Flash drive controller >> Device Descriptor: >> bLength 18 >> bDescriptorType 1 >> bcdUSB 1.10 > > For some reason the device has booted up as USB 1.10 instead of USB > 2.00. It didn''t work any better when it booted as USB 2.00 though. I want to confirm. Does this device surely work properly on Dom0 kernel (w/o pvusb)? Noboru _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > >> Bus 001 Device 006: ID 0204:6025 Chipsbank Microelectronics Co.,Ltd> > CBM2080 > >> Flash drive controller > >> Device Descriptor: > >> bLength 18 > >> bDescriptorType 1 > >> bcdUSB 1.10 > > > > For some reason the device has booted up as USB 1.10 instead of USB > > 2.00. It didn''t work any better when it booted as USB 2.00 though. > > I want to confirm. Does this device surely work properly > on Dom0 kernel (w/o pvusb)? >Yes, it works perfectly, even without a reboot since trying to use it with pvusb On the Intel machine that I''m testing with now, I do this to use it with pvusb: # Set some variables device_id="1-4:1.0" bus_id=`echo $device_id | sed ''s/:.*//''` domid=`xm domid $1` # unlink all devices from any currently bound vports cat /sys/bus/usb/drivers/usbback/vports | while read port do echo "$port" >/sys/bus/usb/drivers/usbback/remove_vport done # set vport echo "$bus_id:$domid:0:1" >/sys/bus/usb/drivers/usbback/new_vport # call provided init script ~/usb_init_xs.sh $domid 0 # wait for a bit echo waiting sleep 5 # unbind device from whatever it is currently bound to (usb-storage in this case) then wait a bit more echo unbind echo -n "$device_id" >/sys/bus/usb/devices/$device_id/driver/unbind sleep 5 # bind the device to usbback echo bind echo -n "$device_id" >/sys/bus/usb/drivers/usbback/bind after that, I unbound the device from usbback and re-bound it to usb-storage and mounted the filesystem. Have you been able to test with 3.4.1 or 3.4-testing yet? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi James, Thank you for your informations. The platform (AMD or Intel) seems to be unrelated to the problem. > Have you been able to test with 3.4.1 or 3.4-testing yet? Not yet. Will test early next week. Regards, Noboru James Harper wrote:>> >> Bus 001 Device 006: ID 0204:6025 Chipsbank Microelectronics Co., > Ltd >> > CBM2080 >> >> Flash drive controller >> >> Device Descriptor: >> >> bLength 18 >> >> bDescriptorType 1 >> >> bcdUSB 1.10 >> > >> > For some reason the device has booted up as USB 1.10 instead of USB >> > 2.00. It didn''t work any better when it booted as USB 2.00 though. >> >> I want to confirm. Does this device surely work properly >> on Dom0 kernel (w/o pvusb)? >> > > Yes, it works perfectly, even without a reboot since trying to use it > with pvusb > > On the Intel machine that I''m testing with now, I do this to use it with > pvusb: > > # Set some variables > device_id="1-4:1.0" > bus_id=`echo $device_id | sed ''s/:.*//''` > domid=`xm domid $1` > > # unlink all devices from any currently bound vports > cat /sys/bus/usb/drivers/usbback/vports | while read port > do > echo "$port" >/sys/bus/usb/drivers/usbback/remove_vport > done > > # set vport > echo "$bus_id:$domid:0:1" >/sys/bus/usb/drivers/usbback/new_vport > > # call provided init script > ~/usb_init_xs.sh $domid 0 > > # wait for a bit > echo waiting > sleep 5 > > # unbind device from whatever it is currently bound to (usb-storage in > this case) then wait a bit more > echo unbind > echo -n "$device_id" >/sys/bus/usb/devices/$device_id/driver/unbind > sleep 5 > > # bind the device to usbback > echo bind > echo -n "$device_id" >/sys/bus/usb/drivers/usbback/bind > > > > after that, I unbound the device from usbback and re-bound it to > usb-storage and mounted the filesystem. > > Have you been able to test with 3.4.1 or 3.4-testing yet? > > Thanks > > James >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi James, I have tested with current tip. My flash drive worked properly. I found no regression with my environment. The main difference between us is flash drive. In your environment, do other devices become the same error? Or, some devices work? My test environment is as follows. PC: Core 2 Quad Q9450 with Q35+ICH9DO Xen: xen-3.4-testing.hg (c/s 19749) Dom0 OS: CentOS 5.3 Dom0 kernel: linux-2.6.18-xen.hg (c/s 931) DomU OS: CentOS 5.3 Dom0 kernel: linux-2.6.18-xen.hg (c/s 931) Tested Device: Buffalo RUF2-R2GS (VendorID:0411, ProductID:0098) dmesg output on domU: vusb vusb-0: Xen USB2.0 Virtual Host Controller driver (usbfront) drivers/usb/core/inode.c: creating file ''devices'' drivers/usb/core/inode.c: creating file ''001'' vusb vusb-0: new USB bus registered, assigned bus number 1 usb usb1: default language 0x0409 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: Xen USB2.0 Virtual Host Controller driver (usbfront) usb usb1: Manufacturer: Linux 2.6.18.8-cs931-domU xen_hcd usb usb1: SerialNumber: vusb-0 usb usb1: uevent usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: uevent hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: no power switching (usb 1.0) hub 1-0:1.0: individual port over-current protection hub 1-0:1.0: Single TT hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns) hub 1-0:1.0: power on to power good time: 20ms hub 1-0:1.0: local power source is good hub 1-0:1.0: trying to enable port power on non-switchable hub drivers/usb/core/inode.c: creating file ''001'' hub 1-0:1.0: state 7 ports 8 chg 0000 evt 0000 hub 1-0:1.0: state 7 ports 8 chg 0000 evt 0002 hub 1-0:1.0: port 1, status 0501, change 0001, 480 Mb/s hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x501 usb 1-1: new high speed USB device using vusb and address 2 usb 1-1: default language 0x0409 usb 1-1: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: USB Flash Disk usb 1-1: Manufacturer: BUFFALO usb 1-1: SerialNumber: F215700809250007 usb 1-1: uevent usb 1-1: configuration #1 chosen from 1 choice usb 1-1: adding 1-1:1.0 (config #1, interface 0) usb 1-1:1.0: uevent drivers/usb/core/inode.c: creating file ''002'' hub 1-0:1.0: state 7 ports 8 chg 0000 evt 0002 SCSI subsystem initialized Initializing USB Mass Storage driver... usb-storage 1-1:1.0: usb_probe_interface usb-storage 1-1:1.0: usb_probe_interface - got id scsi0 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usbcore: registered new driver usb-storage USB Mass Storage support registered. Vendor: BUFFALO Model: USB Flash Disk Rev: 4000 Type: Direct-Access ANSI SCSI revision: 00 usb-storage: device scan complete scsi 0:0:0:0: Attached scsi generic sg0 type 0 SCSI device sda: 3973120 512-byte hdwr sectors (2034 MB) sda: Write Protect is off sda: Mode Sense: 00 00 00 00 sda: assuming drive cache: write through SCSI device sda: 3973120 512-byte hdwr sectors (2034 MB) sda: Write Protect is off sda: Mode Sense: 00 00 00 00 sda: assuming drive cache: write through sda: sda1 sd 0:0:0:0: Attached scsi removable disk sda Regards, Noboru _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Hi James, > > I have tested with current tip. > My flash drive worked properly. > > I found no regression with my environment.Thanks for taking the time to test that.> > The main difference between us is flash drive. > In your environment, do other devices become > the same error? Or, some devices work?I have only tested with that one flash device.> > > My test environment is as follows. > > PC: Core 2 Quad Q9450 with Q35+ICH9DO > Xen: xen-3.4-testing.hg (c/s 19749) > Dom0 OS: CentOS 5.3 > Dom0 kernel: linux-2.6.18-xen.hg (c/s 931) > DomU OS: CentOS 5.3 > Dom0 kernel: linux-2.6.18-xen.hg (c/s 931) > Tested Device: Buffalo RUF2-R2GS > (VendorID:0411, ProductID:0098) >Do you have 64 bit xen, dom0 or domU? Mine are all 64 bit. I tested usb debug to see if there was a difference in the packets sent, but the one time I tried it it crashed with usbback... I think usb debug is better in later kernel versions... James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, > I have only tested with that one flash device. Where can I get that one? Do you know the product''s URL? > Do you have 64 bit xen, dom0 or domU? Mine are all 64 bit. Oh, I forgot. All 64-bit too. > I tested usb debug to see if there was a difference in the packets sent, > but the one time I tried it it crashed with usbback... I think usb debug > is better in later kernel versions... It may take a while, but I will add the verbose debug functions for the pvusb. Regards, Noboru James Harper wrote:>> Hi James, >> >> I have tested with current tip. >> My flash drive worked properly. >> >> I found no regression with my environment. > > Thanks for taking the time to test that. > >> The main difference between us is flash drive. >> In your environment, do other devices become >> the same error? Or, some devices work? > > I have only tested with that one flash device. > >> >> My test environment is as follows. >> >> PC: Core 2 Quad Q9450 with Q35+ICH9DO >> Xen: xen-3.4-testing.hg (c/s 19749) >> Dom0 OS: CentOS 5.3 >> Dom0 kernel: linux-2.6.18-xen.hg (c/s 931) >> DomU OS: CentOS 5.3 >> Dom0 kernel: linux-2.6.18-xen.hg (c/s 931) >> Tested Device: Buffalo RUF2-R2GS >> (VendorID:0411, ProductID:0098) >> > > Do you have 64 bit xen, dom0 or domU? Mine are all 64 bit. > > I tested usb debug to see if there was a difference in the packets sent, > but the one time I tried it it crashed with usbback... I think usb debug > is better in later kernel versions... > > James > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi James,
I''m using PVUSB successfully with XEN 3.4.1 under Debian Lenny and XEN
Kernel 2.6.18-8 (64-Bit and 32-Bit). Dom0 is 64-Bit, DomUs are usually
32-Bit Lenny.
I tested 4-5 USB-Sticks, an Canon USB Printer and a USB-DVB-S TV-Card
(digital Satellite TV) for VDR (Video Disk Recorder), i use it productiv
because it''s stable for me.
I wrote a script (named pvusb) to ease usage, details can be found here:
http://www.neobiker.de/wiki/index.php?title=XEN-PVUSB
The script is able to parse a configfile (/etc/xen/pvusb.conf), which looks
like:
# Configfile for pvusb
# Dev_Id <domain> <Comment>
# USBPort <domain> <Comment>
# 0000:0000 <domain> <Comment>
04a9:1093 srv Canon Printer IP4000
5-1 dmz Anything on USB Port 5-1
0000:0000 vm01 initialize ''vm01'' for PVUSB
Usage of script work''s like this:
m450:~# pvusb -h
usage: pvusb -b [-t] | -i
pvusb -s <domain> -a [ -t ]
pvusb -d <device_id> -s <domain> [-c <comment>] -w [
-t ]
pvusb -u <usb-port> -s <domain> [-c <comment>] -w [ -t
]
pvusb -l | -r
pvusb -x <usb-port>:<domain>:0:<vport>
------------
-a # activate PVUSB (for -s <domain>)
-b # boot/initialise PVUSB with hotplug rules
(/etc/xen/pvusb.conf)
-i # initialize PVUSB without hotplug rules
(/etc/xen/pvusb.conf)
-s <domain> # server domain_name or domain_id
-u <usb-port> # USB-PORT e.g. ''3-2''
-d <device_id># USB device_id e.g. ''0912:1234'' (use
''lsusb'' to get the
ID)
-c <comment> # e.g. "Canon IP4000 Printer"
-l # list grabbed PVUSB Devices
-r # read PVUSB hotplug rules
-w # write/activate PVUSB hotplug rule
-x # delete PVUSB hotplug rule (use copy/paste from -r list)
-t # try to trigger all domains (per ssh) to init PVUSB
-q # be quiet
-D # Debug option (set -x)
Any comments are welcome!
regards neobiker
James Harper wrote:>
> Is anyone successfully using pvusb under 3.4-testing and 2.6.18-xen?
>
> Thanks
>
> James
>
--
View this message in context:
http://www.nabble.com/anyone-using-pvusb--tp25273516p25297935.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> > Hi James, > I''m using PVUSB successfully with XEN 3.4.1 under Debian Lenny and XEN > Kernel 2.6.18-8 (64-Bit and 32-Bit). Dom0 is 64-Bit, DomUs are usually > 32-Bit Lenny. > > I tested 4-5 USB-Sticks, an Canon USB Printer and a USB-DVB-S TV-Card > (digital Satellite TV) for VDR (Video Disk Recorder), i use itproductiv> because it''s stable for me.Wow. That''s almost the exact same environment I am running under, except my Linux testing DomU''s are 64 bit. Thanks so much for confirming that. I guess I''ll try with another USB stick...> I wrote a script (named pvusb) to ease usage, details can be foundhere:> http://www.neobiker.de/wiki/index.php?title=XEN-PVUSB >I wrote a tiny wrapper around the usb_init_xs.sh which simply unbinds the device from whatever driver it is currently bound to (normally usb-storage in my case) and then binds it to usbback. Yours looks pretty nifty though :) James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > I have only tested with that one flash device. > > Where can I get that one? > Do you know the product''s URL? >Noboru, I tried another flash device and it seems to be behaving properly. I don''t yet know if the flash device itself is defective or if it is a general problem with that model. We have a whole box of them though so I should be able to find out easily enough. If you are interested in investigating further I could probably send you one. I am wondering if maybe it is just a quirk of that model or something that the first usb packet that gets sent times out or something and needs to be unlinked. When I look at what happens under Linux, the frontend tries to unlink it but fails. Is it normally the hcd or the device driver that is responsible for maintaining timeouts and retrying etc? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi James,> I am wondering if maybe it is just a quirk of that model or something > that the first usb packet that gets sent times out or something and > needs to be unlinked. When I look at what happens under Linux, the > frontend tries to unlink it but fails. Is it normally the hcd or the > device driver that is responsible for maintaining timeouts and retrying > etc?HCD''s urb_dequeue() function that is called from hcd_unlink_urb() has to be responsible for dequeueing the urb from the actual HCD hardware and giving back the urb within the next time of the HCD hardware interrupt. If no urb returns for a given length of time after usbcore or device drivers unlinked the urb, they might identify the HCD as broken. About the PVUSB''s implementation of urb_dequeue(), it''s incomplete. usbfront can only dequeue the urb that is in the frontend, and cannot dequeue the urb already transferred to the backend. So, if the device goes into stalled state in the backend (probably triggered from wrong urb), The frontend can do nothing. I think main cause of the flash drive failure is the above wrong urb, but I will solve the urb-canceling issue too. Thanks, Noboru. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noboru Iwamatsu writes ("Re: [Xen-devel] anyone using
pvusb?"):> usbfront can only dequeue the urb that is in the frontend, and cannot
> dequeue the urb already transferred to the backend.
usbfront should send a dequeue message to usbback, to tell usbback to
dequeue it.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel