Re: [Xen-devel] anyone using pvusb?

[Noboru Iwamatsu <n_iwamatsu@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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