On Saturday 05 May 2007, Oliver Neukum wrote:
You are included this time David because 3 messages I posted this morning,
whose text should resemble this one, the first of those 3, were
also /dev/nulled. this is BS when I can't even discuss a patch in the same
manner as others can.
So whats wr
On Saturday 05 May 2007, Oliver Neukum wrote:
>Am Samstag, 5. Mai 2007 20:08 schrieb Antonino Ingargiola:
>> Now I don't want to abuse your kindness, but I (personally) would be
>> *really* interested in a similar fix for the FTDI usb-serial driver,
>> because many measurements I do use an FTDI dev
On Saturday 05 May 2007, Oliver Neukum wrote:
>Am Samstag, 5. Mai 2007 20:08 schrieb Antonino Ingargiola:
>> Now I don't want to abuse your kindness, but I (personally) would be
>> *really* interested in a similar fix for the FTDI usb-serial driver,
>> because many measurements I do use an FTDI dev
2007/5/6, Antonino Ingargiola <[EMAIL PROTECTED]>:
2007/5/5, Oliver Neukum <[EMAIL PROTECTED]>:
> Am Samstag, 5. Mai 2007 20:08 schrieb Antonino Ingargiola:
> > Now I don't want to abuse your kindness, but I (personally) would be
> > *really* interested in a similar fix for the FTDI usb-serial dr
On Mon, 7 May 2007, Oliver Neukum wrote:
> Am Montag, 7. Mai 2007 18:34 schrieb Alan Stern:
> > On Mon, 7 May 2007, Diego Zuccato wrote:
> >
> > > Thinking with a 300bps modem (anybody else remembers such an ancient
> > > thing?):
> >
> > I used a 110 bps modem for several years!
>
> I knew 110
Luxury! When I was a lad . . . .
On 5/7/07 12:34 PM, "Alan Stern" <[EMAIL PROTECTED]> wrote:
> On Mon, 7 May 2007, Diego Zuccato wrote:
>
>> Thinking with a 300bps modem (anybody else remembers such an ancient
>> thing?):
>
> I used a 110 bps modem for several years!
>
> Alan Stern
>
-
To
Am Montag, 7. Mai 2007 18:34 schrieb Alan Stern:
> On Mon, 7 May 2007, Diego Zuccato wrote:
>
> > Thinking with a 300bps modem (anybody else remembers such an ancient
> > thing?):
>
> I used a 110 bps modem for several years!
I knew 110 bps is slow, but what took you years to transmit?
On Mon, 7 May 2007, Diego Zuccato wrote:
> Thinking with a 300bps modem (anybody else remembers such an ancient
> thing?):
I used a 110 bps modem for several years!
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Paul Fulghum ha scritto:
> There is no one policy here that will make everyone happy.
> Some will want all the data before some was lost,
> others the data after some was lost.
IMVHO the only sane thing is ALWAYS avoid "holes" (some old data, then
the "hole" of lost data, then some new data) after
2007/5/6, Alan Stern <[EMAIL PROTECTED]>:
On Sun, 6 May 2007, Alan Cox wrote:
> > However, whatever policy the buffer uses, the fundamental point it's that
> > when I flush the input buffer I should be sure that each byte read
> > after the flush is *new* (current) data and not old one. This bec
On Sun, 6 May 2007, Alan Cox wrote:
> > However, whatever policy the buffer uses, the fundamental point it's that
> > when I flush the input buffer I should be sure that each byte read
> > after the flush is *new* (current) data and not old one. This because
>
> Define "new" and "old" in this cas
> To conclude, the store the *last* N bytes received seems a more
> reasonable policy for the input buffers managed by the kernel. If the
For your use maybe, but it is not the normal behaviour and it is not the
behaviour supported by hardware, which generally buffers the first few
bytes (and some
2007/5/6, Alan Cox <[EMAIL PROTECTED]>:
> However, whatever policy the buffer uses, the fundamental point it's that
> when I flush the input buffer I should be sure that each byte read
> after the flush is *new* (current) data and not old one. This because
Define "new" and "old" in this case. I
Alan Cox wrote:
On Sat, 5 May 2007 20:07:15 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
should I understand this so that, if tty_buffer_request_room() returns
less than requested, the rest of the data should be dropped on the
floor?
If it returns NULL then either there is > 64K buffered (we
Antonino Ingargiola wrote:
For my use case would be more sensible to accept the new data and
discard the older one in the tty buffer: the tty buffer would be a
moving window of the most recent incoming data. This because if
someone does not read the incoming data maybe he's not interested in
it.
> However, whatever policy the buffer uses, the fundamental point it's that
> when I flush the input buffer I should be sure that each byte read
> after the flush is *new* (current) data and not old one. This because
Define "new" and "old" in this case. I don't believe you can give a
precise defin
2007/5/5, Alan Cox <[EMAIL PROTECTED]>:
On Sat, 5 May 2007 20:07:15 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
[cut]
> should I understand this so that, if tty_buffer_request_room() returns
> less than requested, the rest of the data should be dropped on the
> floor?
If it returns NULL the
2007/5/5, Oliver Neukum <[EMAIL PROTECTED]>:
Am Samstag, 5. Mai 2007 20:08 schrieb Antonino Ingargiola:
> Now I don't want to abuse your kindness, but I (personally) would be
> *really* interested in a similar fix for the FTDI usb-serial driver,
> because many measurements I do use an FTDI device
On Sat, 5 May 2007 20:07:15 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Samstag, 5. Mai 2007 18:36 schrieb Alan Cox:
> > > In the serial driver this usually just results in dropping
> > > RTS to signal the remote end to stop sending. The serial
> > > driver always immediately gives receive
> > This is a bug in cdc-acm really. It should not double buffer, but to be
> > fair to the authors prior to the new tty buffering it *had* to do this.
>
> I assume this applies to all serial drivers in the wider sense?
When possible at least. Obviously there will always be some buffering in
the
Am Samstag, 5. Mai 2007 20:08 schrieb Antonino Ingargiola:
> Now I don't want to abuse your kindness, but I (personally) would be
> *really* interested in a similar fix for the FTDI usb-serial driver,
> because many measurements I do use an FTDI device.
Does this work?
Regards
2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:
On Sat, 2007-05-05 at 18:58 +0200, Antonino Ingargiola wrote:
> This patch does not solve the problem with the cdc_acd driver. I still
> need to flush two times to really flush the input. And the "secondary
> buffer" still seems 26 bytes (as before).
I
Am Samstag, 5. Mai 2007 18:36 schrieb Alan Cox:
> > In the serial driver this usually just results in dropping
> > RTS to signal the remote end to stop sending. The serial
> > driver always immediately gives receive data to the tty buffering
> > without regard to the throttled state.
> >
> > I wou
On 5/5/07, Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
> Antonino:
>
> Can you try two tests (with my patch applied):
>
> 1. comment out the tty_flush_buffer() call in tty_ldisc_flush() and test
>
> 2. uncomment (reenable) the above call and c
Forgot to include the links in the previous mail:
[0] http://www.lammertbies.nl/comm/info/RS-232_null_modem.html
[1] http://pyserial.sourceforge.net/
~ Antonio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:
On Sat, 2007-05-05 at 18:46 +0200, Oliver Neukum wrote:
> Am Samstag, 5. Mai 2007 18:08 schrieb Paul Fulghum:
> > I would argue that cdc-acm should do the same as the serial driver.
>
> Has this been tested?
> If so we could reduce the complexity of the
On Sat, 2007-05-05 at 18:58 +0200, Antonino Ingargiola wrote:
> This patch does not solve the problem with the cdc_acd driver. I still
> need to flush two times to really flush the input. And the "secondary
> buffer" still seems 26 bytes (as before).
I missed a bit, try this.
--- a/drivers/usb/cl
On Sat, 2007-05-05 at 18:46 +0200, Oliver Neukum wrote:
> Am Samstag, 5. Mai 2007 18:08 schrieb Paul Fulghum:
> > I would argue that cdc-acm should do the same as the serial driver.
>
> Has this been tested?
> If so we could reduce the complexity of the throtteling logic in the usb
> drivers.
Ant
2007/5/5, Antonino Ingargiola <[EMAIL PROTECTED]>:
2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:
> On Sat, 2007-05-05 at 11:08 -0500, Paul Fulghum wrote:
> > I would argue that cdc-acm should do the same as the serial driver.
>
> Try this patch for the usb ports. (I don't have that hardware)
Build
Am Samstag, 5. Mai 2007 18:36 schrieb Alan Cox:
> > In the serial driver this usually just results in dropping
> > RTS to signal the remote end to stop sending. The serial
> > driver always immediately gives receive data to the tty buffering
> > without regard to the throttled state.
> >
> > I wou
Am Samstag, 5. Mai 2007 18:08 schrieb Paul Fulghum:
> If the line discipline throttles the driver input,
> the cdc-acm driver stops giving data to the tty buffering
> and instead stores them internally.
So do usb serial drivers.
> In the serial driver this usually just results in dropping
> RTS
> In the serial driver this usually just results in dropping
> RTS to signal the remote end to stop sending. The serial
> driver always immediately gives receive data to the tty buffering
> without regard to the throttled state.
>
> I would argue that cdc-acm should do the same as the serial drive
2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:
On Sat, 2007-05-05 at 11:08 -0500, Paul Fulghum wrote:
> I would argue that cdc-acm should do the same as the serial driver.
Try this patch for the usb ports. (I don't have that hardware)
Building... thanks.
The HW is a cypress demo-board for their
On Sat, 2007-05-05 at 11:08 -0500, Paul Fulghum wrote:
> I would argue that cdc-acm should do the same as the serial driver.
Try this patch for the usb ports. (I don't have that hardware)
--- a/drivers/usb/class/cdc-acm.c 2007-04-25 22:08:32.0 -0500
+++ b/drivers/usb/class/cdc-acm.c
On Fri, 2007-05-04 at 17:30 -0600, Paul Fulghum wrote:
> OK, this behavior is so unexpected I must be missing
> something basic.
And so I was. Try this patch.
--- a/drivers/char/tty_io.c 2007-05-04 05:46:55.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-05 03:23:46.0 -0500
@@
On Sat, 2007-05-05 at 10:43 -0600, Paul Fulghum wrote:
> There is not an input flush method for the tty driver
> and individual drivers don't process that ioctl.
> The tty drivers I've seen immediately pass receive data to the
> tty buffering and I'm not sure why a driver would
> behave otherwise.
Antonino Ingargiola wrote:
The patch now boot properly and solves
completely the testcase with two serial lines:
Good, thanks for testing.
I think this patch should be included in mainline, since if one flushes
the input buffer, really want to flush the entire buffer chain and
doesn't want to
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
Antonino:
Can you try two tests (with my patch applied):
1. comment out the tty_flush_buffer() call in tty_ldisc_flush() and test
2. uncomment (reenable) the above call and comment out the
tty_flush_buffer() call in tty_ioctl() and test
I as
2007/5/5, Paul Fulghum <[EMAIL PROTECTED]>:
On Fri, 2007-05-04 at 17:30 -0600, Paul Fulghum wrote:
> OK, this behavior is so unexpected I must be missing
> something basic.
And so I was. Try this patch.
--- a/drivers/char/tty_io.c 2007-05-04 05:46:55.0 -0500
+++ b/drivers/char/tty_i
Antonino:
Can you try two tests (with my patch applied):
1. comment out the tty_flush_buffer() call in tty_ldisc_flush() and test
2. uncomment (reenable) the above call and comment out the
tty_flush_buffer() call in tty_ioctl() and test
Thanks,
Paul
-
To unsubscribe from this list: send the li
Antonino Ingargiola wrote:
"With the patch, flushing the input results effectively in a complete flush.
However after doing the flush I can't read [further] chars [sent to
the serial port]
without closing and reopening the port. I've verified this behavior both
communicating between two serial po
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
On Fri, 2007-05-04 at 21:06 +0200, Antonino Ingargiola wrote:
> Filling with echo console-screen.sh I've found that the blocking command is:
>
> unicode_start 2> /dev/null || true
>
> or at least the echo before this command is the last show
On Fri, 2007-05-04 at 21:06 +0200, Antonino Ingargiola wrote:
> Filling with echo console-screen.sh I've found that the blocking command is:
>
> unicode_start 2> /dev/null || true
>
> or at least the echo before this command is the last shown.
I still don't know what is blocking.
It is pos
On 5/4/07, Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
[cut]
I'm quite confident the system blocks on "Setting consoles fonts and
modes.", and thus during the boot script console-screen.h. I'll try to
see which commands blocks...
Filling with echo console-screen.sh I've found that the blocki
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
On Fri, 2007-05-04 at 19:25 +0200, Antonino Ingargiola wrote:
> No. Ehmm ... I've an usb keybord and vga monitor on a standard desktop pc.
OK, I'm stumped.
I don't see how my patch could cause the machine to not boot
and I'm not seeing that be
On Fri, 2007-05-04 at 19:25 +0200, Antonino Ingargiola wrote:
> No. Ehmm ... I've an usb keybord and vga monitor on a standard desktop pc.
OK, I'm stumped.
I don't see how my patch could cause the machine to not boot
and I'm not seeing that behavior here.
--
Paul Fulghum
Microgate Systems, Ltd
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
On Fri, 2007-05-04 at 19:13 +0200, Antonino Ingargiola wrote:
> On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
> > Antonino Ingargiola wrote:
> > > The system blocks during booting. I can unblock it with SysReq+K but
> > > then I'm unable to
On Fri, 2007-05-04 at 19:13 +0200, Antonino Ingargiola wrote:
> On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
> > Antonino Ingargiola wrote:
> > > The system blocks during booting. I can unblock it with SysReq+K but
> > > then I'm unable to log into X.
> >
> > Hmmm, it tests here with no probl
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
Antonino Ingargiola wrote:
> The system blocks during booting. I can unblock it with SysReq+K but
> then I'm unable to log into X.
Hmmm, it tests here with no problem.
Does reversing the patch and rebuilding the kernel fix the boot?
The kerne
Antonino Ingargiola wrote:
The system blocks during booting. I can unblock it with SysReq+K but
then I'm unable to log into X.
Hmmm, it tests here with no problem.
Does reversing the patch and rebuilding the kernel fix the boot?
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from th
On 5/4/07, Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
> Here is a patch against 2.6.21 which flushes the tty flip buffer
> on ioctl(TCFLSH) for input.
>
> --- a/drivers/char/tty_io.c 2007-04-25 22:08:32.0 -0500
> +++ b/drivers/cha
On 5/4/07, Paul Fulghum <[EMAIL PROTECTED]> wrote:
Here is a patch against 2.6.21 which flushes the tty flip buffer
on ioctl(TCFLSH) for input.
--- a/drivers/char/tty_io.c 2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-04 09:30:01.0 -0500
Thanks! I've
Here is a patch against 2.6.21 which flushes the tty flip buffer
on ioctl(TCFLSH) for input.
--- a/drivers/char/tty_io.c 2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-04 09:30:01.0 -0500
@@ -365,6 +365,28 @@ static void tty_buffer_free(struct tty_s
}
/
Paul Fulghum wrote:
A new function to flush the tty flip buffer needs to
be added and then called from tty_io.c:tty_ldisc_flush().
That is not enough.
It looks like tty_ioctl() needs to process ioctl(TCFLSH)
to clear the flip buffer before passing that ioctl
to the line discipline.
--
Paul Fu
Antonino Ingargiola wrote:
Nope. In python I use the flushInput() method of the serial object
defined by the pyserial library[0]. The method does just this system
call:
termios.tcflush(self.fd, TERMIOS.TCIFLUSH)
that I think is correct.
There is intermediate buffering between the driver a
> > How do you flush the buffers? Simply reading them out?
>
> Nope. In python I use the flushInput() method of the serial object
> defined by the pyserial library[0]. The method does just this system
> call:
>
> termios.tcflush(self.fd, TERMIOS.TCIFLUSH)
case TCFLSH:
Accidentally I've replied privately, sorry. Forwarding to ML...
-- Forwarded message --
From: Antonino Ingargiola <[EMAIL PROTECTED]>
Date: May 4, 2007 11:29 AM
Subject: Re: [SOLVED] Serial buffer corruption [was Re: FTDI
usb-serial possible bug]
To: Oliver Neu
Am Freitag, 4. Mai 2007 10:38 schrieb Antonino Ingargiola:
> To solve the problem we must do a complete flush of all the buffer
> chain. I do this flushing the input multiple times with a small pause
> between them. In my case 10 flushes separated by a 10ms pause always
> empties the whole buffer c
Hi,
On 4/14/07, Antonino Ingargiola <[EMAIL PROTECTED]> wrote:
Hi to the list,
I report a problem found with a device that use the FTDI chip to
communicate data to pc.
The scenario is: a serial device streams data continuously toward the
pc. The application requires the data be read once in
59 matches
Mail list logo
