Re: Handshaking on USB serial devices

[Gene Heskett]

On Thursday 14 February 2008, Greg KH wrote:
>On Thu, Feb 14, 2008 at 03:04:41PM -0500, Gene Heskett wrote:
>> On Thursday 14 February 2008, Alan Cox wrote:
>> >> byte of a packet is being thrown away about .1% of the time for the
>> >> pl2303, but I'm not sure if the FTDI driver still suffers from a
>> >> similar rash.  I
>> >
>> >A 20 byte low speed message is too small for flow control to account for
>> >it.
>>
>> Where then could the first byte go?  Note I'm not fussing about flow
>> controls per sei, so the subject line maybe needs to be adjusted, but they
>> obviously work well enough that a multimegabyte transfer to my printer
>> works very well, but about usb trying to entirely replace serial here. 
>> There does seem to be a problem but I'm not 100% positive where it is in
>> the chain of a usb packets travels.  What I've observed, with hidraw I
>> think it was, is that the first 'wake up' byte incoming didn't seem to be
>> there.
>
>I have not seen this kind of error in years, why have you not reported
>it?
I did make some noise, probably over a year ago now, but I guess it fell 
through the cracks or no one else could duplicate it.  And my expiry on this 
list means any and all such messages have been expired for several months.

>Can you enable debugging in the pl2303 driver with a simple:
>	modprobe pl2303 debug=1
>or when the driver is running with:
>	echo 1 > /sys/module/pl2303/parameters/debug
>
>That way you can see the data flowing through the device.  If the host
>sends it to the device, perhaps your device is just dropping it somehow?
>
>These pl2303 devices are really cheap, there are lots of different
>variations of them, and none of them are documented at all.  We might be
>missing some kind of interaction here, but in my tests, I have not had
>any lost data.

I have two, both very early models sold by Radio Shack but they have been 
hanging on the pegs except for when I take roadnav with me on a long trip.

>Are you sure your userspace program isn't constantly setting the line
>settings?  We have seen instances where the device does get confused and
>resets itself if that happens a lot.  That was just fixed in the last
>kernel release.

Maybe that is what I was seeing?  ATM runing on 2.6.24 final. Just for grins I 
fired up a 'cat /dev/hideaw0 | hexdump -v' and I'm seeing traffic, mostly 
from the motion sensor, but because hexdump makes a 16 byte line out of one 
byte, and may display that byte anyplace in that 16 byte buffer, I can't tell 
what is right and what is wrong even though I am familiar with the x10 
protocol.  Do we have another such tool that will output only those bytes 
actually received as they come in?  Something that prints the hex value of 
the byte, and then issues a newline to the screen?  Or some way to ship the 
$00's to /dev/null so hexdump ignores them?

>thanks,
>
>greg k-h



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"But I don't like Spam!!!!"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/