2006/3/24, Alan Stern <[EMAIL PROTECTED]>:
> On Fri, 24 Mar 2006, Franck Bui-Huu wrote:
> This output is very meager.
sorry I forgot to mention that it was snipped. Here is a more complete one:
d5161c80 2492837178 S Co:014:00 -115 0
d5161c80 2492892431 C Co:014:00 0 0
d7aa5180 2492892503 S Ci:014:00 -115 18 D
d5161980 2492892509 S Ci:014:00 -115 9 D
d5161b00 2492892513 S Ci:014:00 -115 1 D
cc7ec500 2492892517 S Ci:014:00 -115 2 D
c5c83900 2492892520 S Ci:014:00 -115 2 D
c5c83780 2492892524 S Ci:014:00 -115 10 D
d93b4800 2492892527 S Ci:014:00 -115 18 D
dbc56480 2492892531 S Ci:014:00 -115 9 D
dc01bf00 2492892534 S Co:014:00 -115 0
c5c83580 2492892538 S Ci:014:00 -115 2 D
d5161400 2492892541 S Ci:014:00 -115 1024 D case 10
d5161080 2492892548 S Ci:014:00 -115 9 D case 11
d3fd0b80 2492892551 S Ci:014:00 -115 9 D case 12
d5161300 2492892554 S Ci:014:00 -115 960 D
d5161880 2492892561 S Ci:014:00 -115 64 D
c5c83b00 2492892565 S Ci:014:00 -115 18 D
c5c83d00 2492892568 S Ci:014:00 -115 9 D
cc7ec480 2492892573 S Ci:014:00 -115 1 D
cc7ec400 2492892577 S Ci:014:00 -115 2 D
cc7ec380 2492892580 S Ci:014:00 -115 2 D
c5c83300 2492892584 S Ci:014:00 -115 10 D
c5c83280 2492892588 S Ci:014:00 -115 18 D
cc7ec580 2492892592 S Ci:014:00 -115 9 D
d84ba480 2492892595 S Co:014:00 -115 0
d5161500 2492892599 S Ci:014:00 -115 2 D
d7aa5180 2492893431 C Ci:014:00 0 18 D
d7aa5180 2492893434 S Ci:014:00 -115 18 D
d5161980 2492893439 C Ci:014:00 0 9 D
d5161980 2492893441 S Ci:014:00 -115 9 D
d5161b00 2492893445 C Ci:014:00 0 1 D
d5161b00 2492893447 S Ci:014:00 -115 1 D
cc7ec500 2492893451 C Ci:014:00 0 2 D
cc7ec500 2492893454 S Ci:014:00 -115 2 D
c5c83900 2492893457 C Ci:014:00 0 2 D
c5c83900 2492893460 S Ci:014:00 -115 2 D
c5c83780 2492893463 C Ci:014:00 -32 0
c5c83780 2492893466 S Ci:014:00 -115 10 D
d93b4800 2492894429 C Ci:014:00 0 18 D
d93b4800 2492894431 S Ci:014:00 -115 18 D
dbc56480 2492894436 C Ci:014:00 -32 0
dbc56480 2492894438 S Ci:014:00 -115 9 D
dc01bf00 2492895429 C Co:014:00 0 0
dc01bf00 2492895431 S Co:014:00 -115 0
c5c83580 2492895435 C Ci:014:00 0 2 D
c5c83580 2492895437 S Ci:014:00 -115 2 D
d5161400 2492895442 C Ci:014:00 -121 32 D case 10
d5161400 2492895444 S Ci:014:00 -115 1024 D
d5161080 2492904427 C Ci:014:00 -75 9 D case 11
d3fd0b80 2492906427 C Ci:014:00 -104 0 case 12
d5161300 2492906431 C Ci:014:00 -104 0
d5161880 2492906434 C Ci:014:00 -104 0
c5c83b00 2492906437 C Ci:014:00 -104 0
c5c83d00 2492906440 C Ci:014:00 -104 0
cc7ec480 2492906443 C Ci:014:00 -104 0
cc7ec400 2492906446 C Ci:014:00 -104 0
cc7ec380 2492906449 C Ci:014:00 -104 0
> You really should use a later kernel for your
> testing. Like 2.6.16.
yeah I know, but I can't do that now...
>
> Also, how can you tell that the -75 status was for case 10? All you can
> see from the trace above is that the URB at d5161080 got that status. The
I made a mistake, it's not case 10 that failed but rather case 11.
This case ask for 9 bytes but the device answer with 32 bytes, thus
the EOVERFLOW status given by the host. If I remember well, the device
should stall in that case, but the zero driver doesn't notice any
errors to the UDC driver...who is doing the wrong thing ?
Thanks
--
Franck
-------------------------------------------------------
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&kid0944&bid$1720&dat1642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
