I realize you're not working on this now, but for the record here's my 
analysis...

On Fri, 17 Mar 2006, Niels Sterrenburg wrote:

> Hi Alan and others on the list,
> 
> The patch doesn't give new behaviour (thanks for sorting it out anyway ;-).
> 
> This is what I see with the protocol analyzer:
> 
> ----------------------------------------------------------------------
> Logged event describtions (without Token=SOF events)
> 
> Reset
> Token=setup     (Adr=0, Endpoint=0, CRC5=02h)
> Data0
> Request=GET_DESCRIPTOR
> Handshake=ACK
> Token=In        (adr=0, endpoint=0)
> Handshake=NAK   !!!
> Token=In        (adr=0, endpoint=0)
> Handshake=NAK   !!!
> ...             (lot of the same, token=In-> NaCK)
> Token=In        (adr=0, endpoint=0)
> Handshake=NAK   !!!

You seem to be missing a Token=In packet right here.  Not that it matters 
much.

> Data1
> Describtor=DEVICE
>         bLength=18
>         USB spec version: 2.0
>         deviceClass=02h
>         subclass=0
>         protocol=0
>         maxpacketsize=64
>         idVEndor=0B95h
>         idProduct=1720h
>         device release=00.01
>         iManufacturar=1
>         iProduct=2
>         iSerialNr=0
>         bNumConfigurations=1
>         CRC16=9DCEh
> Handshake=ACK
> Token=out       (adr=0, endpoint=0, CRC5=02h)
> Data1           (crc16=0000h)
> Handshake=ACK
> Reset
> --------> long time and lots of Token=SOF later
> Toke=Setup      (adr=0, endp=0)
> Data0
> Request=SET_ADDRESS
>         Target=device
>         Type=Standard, Host to Device
>         Address=3
>         Index=0000h
>         Length=0
>         CRC16=C7EAh
> Handshake=Ack
> Token=in        (adr=0, endp=0)
> Data1           (CRC16=0000h)
> Reset
> ----------------------------------------------------------------------
> 
> Is the Reset after the DEVICE stage normal ?

Yes.  Windows does exactly the same thing.  The Reset after the 
Set-Address is _not_ normal, however.

> Host appearantly tries to give the device an address afterwards as
> expected in enumeration stage....
> I would expect to see communication to/from the new given address,
> instead there is a reset after which all stops.

Right.  The question is: Why did that last reset occur?

> From Linux point of view if I do an lsusb -t then it hangs on the console....

Probably because the khubd thread is hung, so it never releases the 
device lock.  Then lsusb waits for the lock and hangs.

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Reply via email to