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 !!!
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 ?
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.
>From Linux point of view if I do an lsusb -t then it hangs on the console....
thanks in advance,
Niels
> On Thu, 16 Mar 2006, Niels Sterrenburg wrote:
>
>> Hi Alan,
>>
>> Thanks for the quick reaction.
>>
>> > However, I don't understand the last line of your log. After the
>> second
>> > port reset, why isn't there another "port 1 high speed" line? Why did
>> the
>> > status change to 000000? It should be 001005, like it was after the
>> first
>> > reset.
>> I have aranged myself a USB2 protocol analyzer, so I'll check whats
>> happening on the bus.
>>
>> > If possible you should move up to 2.6.11, or even better, 2.6.15.
>> I did fuzzle a bit in the ehci_reset as on some boards it complained
>> that ehci_reset failed...
>> I will port 2.6.15 later on but that's not a quick action for now.
>>
>> I'll keep you posted when I discover what it is.
>
> At least apply this patch. It might turn out to be important.
>
> Alan Stern
>
>
>
> --- usb-2.6.10/drivers/usb/core/hub.c 2005-01-03 09:39:35.000000000 -0500
> +++ usb-2.6.10b/drivers/usb/core/hub.c 2006-03-16 11:00:05.000000000
> -0500
> @@ -1375,6 +1375,9 @@ static int hub_port_reset(struct usb_dev
> /* return on disconnect or reset */
> switch (status) {
> case 0:
> + /* TRSTRCY = 10 ms; plus some extra */
> + msleep(10 + 40);
> + /* FALL THROUGH */
> case -ENOTCONN:
> case -ENODEV:
> clear_port_feature(hdev,
>
>
>
> -------------------------------------------------------
> 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
>
-------------------------------------------------------
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
