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
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.
>>
[...]
>
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.
[...]
Careful - a
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 left
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.)
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
the 2.6
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-kernel" in
the body of a message to [EMAIL
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-kernel 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.
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
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,
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
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
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
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
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
> 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
> 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
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
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-kernel" in
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
> 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
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
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
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 should look at
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 end lowers
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 flow
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-kernel in
the
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 the URB
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 condition.
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 windows
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 can't
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
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
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
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
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
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
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, 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, very small
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 byte of
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. Buffered
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
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)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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)?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
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
50 matches
Mail list logo
