anyone using pvusb?

anyone using pvusb?

[James Harper]

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

Re: anyone using pvusb?

[Keir Fraser]

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

Re: anyone using pvusb?

[Noboru Iwamatsu]

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

RE: anyone using pvusb?

[James Harper]

> 
> 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

RE: anyone using pvusb?

[James Harper]

> 
> # 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

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.

James

Re: anyone using pvusb?

[Noboru Iwamatsu]

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

RE: anyone using pvusb?

[James Harper]

I just tested on an Intel box and had the same problems.

James

Re: anyone using pvusb?

[Noboru Iwamatsu]

 >> 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

RE: anyone using pvusb?

[James Harper]

> 
>  >> 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

Re: anyone using pvusb?

[Noboru Iwamatsu]

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
> 

Re: anyone using pvusb?

[Noboru Iwamatsu]

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

RE: anyone using pvusb?

[James Harper]

> 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

Re: anyone using pvusb?

[Noboru Iwamatsu]

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

Re: anyone using pvusb?

[Neobiker]

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.

RE: anyone using pvusb?

[James Harper]

> 
> 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.

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 found
here:
> 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

RE: anyone using pvusb?

[James Harper]

>  > 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

Re: anyone using pvusb?

[Noboru Iwamatsu]

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.

Re: anyone using pvusb?

[Ian Jackson]

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.