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
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
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
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
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 driver,
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 device.
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 device.
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
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
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
>
-
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
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
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]
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?
Regards
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 unsubscribe
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 bps is slow,
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 because
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 a
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
> 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
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
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
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
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.
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 then
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 definition
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.
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
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 don't
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
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 case. I don't
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
> > 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).
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
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
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
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.
---
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.
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)
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
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
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
+++
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
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
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
+++
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_io.c
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
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
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.
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 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
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
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 driver.
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 to
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 would argue
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.
Antonino
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)
Building...
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.
---
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
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
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 would argue
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 comment out
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 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
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
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 data to
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
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
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
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
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
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
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,
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
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
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
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
> +++
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
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
> > 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 Neukum &
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
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
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.
summary of snipped problem description
The scenario is: a serial device streams data continuously toward the
pc. The
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
1 - 100 of 118 matches
Mail list logo
