On Fri, Feb 22, 2008 at 06:05:09AM +1030, David Newall wrote:
> Alan Cox wrote:
> >> developing is entirely wrong. Oh well. Mind you, providing a
> >> write_room function is NOT a real solution; it merely reduces the
> >> condition to a usually-winnable race. (Ironically, when I back-ported
> >>
Alan Cox wrote:
>> developing is entirely wrong. Oh well. Mind you, providing a
>> write_room function is NOT a real solution; it merely reduces the
>> condition to a usually-winnable race. (Ironically, when I back-ported
>> the 2.6 driver, I excluded its new write_room function. Mistake.)
>>
> developing is entirely wrong. Oh well. Mind you, providing a
> write_room function is NOT a real solution; it merely reduces the
> condition to a usually-winnable race. (Ironically, when I back-ported
> the 2.6 driver, I excluded its new write_room function. Mistake.)
What race do you see le
Alan,
Alan Cox wrote:
>> That's a very good point. Even so: on the 2.4 driver, write_room isn't
>> implemented (refer to a previous message by Alan); and in 2.6, a 1k
>> buffer is built into the driver, with nothing to prevent it being sent
>> when the hardware buffer fills.
>>
[...]
> Care
Gene Heskett <[EMAIL PROTECTED]> wrote:
['cat /dev/hideaw0 | hexdump -v']
> Or some way to ship the
> $00's to /dev/null so hexdump ignores them?
.. | perl -pe 's/\00//g/' | ...
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED
Greg KH wrote:
> On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote:
>
>> The current 2.6 driver maintains it's own buffer. I think that's a bad
>> thing: usbserial already buffers writes, and the extra buffer copy seems
>> unnecessary, however it does solve the putchar problem. Buff
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.
I agree. I've observed the first
On Thursday 14 February 2008, Krzysztof Halasa wrote:
>Gene Heskett <[EMAIL PROTECTED]> writes:
>> Apparently they do not Alan, the pl2303 in particular is a problem child,
>> throwing several lost com errors a day when doing nothing more strenuous
>> than talking to my belkin UPS from apcupsd, ver
Gene Heskett <[EMAIL PROTECTED]> writes:
> Apparently they do not Alan, the pl2303 in particular is a problem child,
> throwing several lost com errors a day when doing nothing more strenuous than
> talking to my belkin UPS from apcupsd, very small packets there, 20 bytes I
> believe at several
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
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 spe
On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote:
> The current 2.6 driver maintains it's own buffer. I think that's a bad
> thing: usbserial already buffers writes, and the extra buffer copy seems
> unnecessary, however it does solve the putchar problem. Buffered (i.e.
> by the 2.6 s
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 c
> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux
> That's a very good point. Even so: on the 2.4 driver, write_room isn't
> implemented (refer to a previous message by Alan); and in 2.6, a 1k
> buffer is built into the driver, with nothing to prevent it being sent
> when the hardware buffer fills. These could be bugs in the two versions
Which
On Thursday 14 February 2008, Alan Cox wrote:
>O> believe at several second intervals. I can cut those messages to about
>
>> weekly by using an FDTI adaptor in its place, or I can stop them entirely
>> if
>
>Sorry don't see the connection between the two stories ?
>
>Alan
The connection is that
On Thursday 14 February 2008, David Newall wrote:
> RS232 is (normally) so much slower than USB that, on an extended
> transmission, the buffer internal to the local hardware can fill well
> before the remote device has demanded that transmission stop. In fact,
> now that you've mentioned it, I ca
Alan Cox wrote:
>> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
>> a race: An in-flight write URB can fill all hardware buffers, making
>> unsafe what previously appeared to be a safe write. I think it's
>> essential to delay submission of the URB on a stop-transmit cond
O> believe at several second intervals. I can cut those messages to about
> weekly by using an FDTI adaptor in its place, or I can stop them entirely if
Sorry don't see the connection between the two stories ?
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the b
On Thursday 14 February 2008, Alan Cox wrote:
>> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
>> a race: An in-flight write URB can fill all hardware buffers, making
>> unsafe what previously appeared to be a safe write. I think it's
>> essential to delay submission of t
> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
> a race: An in-flight write URB can fill all hardware buffers, making
> unsafe what previously appeared to be a safe write. I think it's
> essential to delay submission of the URB on a stop-transmit condition.
Hardware flo
On Wed, 13 Feb 2008 21:02:11 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote:
> > Consider a USB-attached serial port that is set to do RTS/CTS (or
> > DSR/DTR) handshaking: What stops the kernel sending more data to it when
> > the remote en
Greg KH wrote:
> On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote:
>
>> Consider a USB-attached serial port that is set to do RTS/CTS (or
>> DSR/DTR) handshaking: What stops the kernel sending more data to it when
>> the remote end lowers CTS (or DTR)?
>>
>
> The tty layer shoul
On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote:
> Consider a USB-attached serial port that is set to do RTS/CTS (or
> DSR/DTR) handshaking: What stops the kernel sending more data to it when
> the remote end lowers CTS (or DTR)?
The tty layer should look at the proper flags and not s
24 matches
Mail list logo
