USB virt 2.6 port status

USB virt 2.6 port status

[Harry Butterworth]

Progress this week:

The 2.6 front end loads, discovers the 2.4 back-end, installs a USB hcd
device, Linux turns on power to the virtual port, resets it and
discovers the attached device.

Linux sends the first URB.  The behaviour of the Linux USB hub driver
has changed since 2.4.  Where previously it would send a set address
request first it now starts with a get descriptor request.

This get descriptor request currently fails against my USB disgo key,
the hub driver tries to reset the port which isn't supported by the 2.4
back end and no further progress is made.

Some debugging showed that the existing Xen usbif inter-domain protocol
was passing the URB transfer-flags as defined in the usb.h header file
and the definition of the bits in these flags has changed between 2.4
and 2.6 such that the values passed by the 2.6 kernel are incorrect when
interpreted by the 2.4 kernel.

I need to fix the xen usbif protocol so the parameters passed are
expressed independent of the linux kernel headers.

I put in a quick hack for this and re-ran the test but the initial urb
still failed.

I'm not sure whether there are still 2.4/2.6 incompatibilities to fix in
the inter-domain protocol or if the disgo key simply can't cope with the
get descriptor request in which case explicitly handling the get
descritor request in the back-end or implementing resets in the back-end
to allow the front-end to pursue its retry strategy might be the next
step.

More debugging is required.

I'm on vacation for a week now and will resume working on this when I
return.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: USB virt 2.6 port status

[Ian Pratt]

Good to hear that progress is being made.

I suspect that linux 2.4 dom0 (as opposed to domU) functionality will be
dropped at some point in the not too distant future. Moving the
IOAPIC/PCI functionality from Xen into dom0 will certainly break it, and
its not clear who will care enough to fix it. Maybe someone will.

Ian 

> -----Original Message-----
> From: xen-devel-admin@lists.sourceforge.net 
> [mailto:xen-devel-admin@lists.sourceforge.net] On Behalf Of 
> Harry Butterworth
> Sent: 18 March 2005 19:07
> To: Mark.Williamson@cl.cam.ac.uk
> Cc: xen-devel@lists.sourceforge.net
> Subject: [Xen-devel] USB virt 2.6 port status
> 
> Progress this week:
> 
> The 2.6 front end loads, discovers the 2.4 back-end, installs 
> a USB hcd
> device, Linux turns on power to the virtual port, resets it and
> discovers the attached device.
> 
> Linux sends the first URB.  The behaviour of the Linux USB hub driver
> has changed since 2.4.  Where previously it would send a set address
> request first it now starts with a get descriptor request.
> 
> This get descriptor request currently fails against my USB disgo key,
> the hub driver tries to reset the port which isn't supported 
> by the 2.4
> back end and no further progress is made.
> 
> Some debugging showed that the existing Xen usbif 
> inter-domain protocol
> was passing the URB transfer-flags as defined in the usb.h header file
> and the definition of the bits in these flags has changed between 2.4
> and 2.6 such that the values passed by the 2.6 kernel are 
> incorrect when
> interpreted by the 2.4 kernel.
> 
> I need to fix the xen usbif protocol so the parameters passed are
> expressed independent of the linux kernel headers.
> 
> I put in a quick hack for this and re-ran the test but the initial urb
> still failed.
> 
> I'm not sure whether there are still 2.4/2.6 
> incompatibilities to fix in
> the inter-domain protocol or if the disgo key simply can't 
> cope with the
> get descriptor request in which case explicitly handling the get
> descritor request in the back-end or implementing resets in 
> the back-end
> to allow the front-end to pursue its retry strategy might be the next
> step.
> 
> More debugging is required.
> 
> I'm on vacation for a week now and will resume working on this when I
> return.
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from 
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click