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
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/
Arnd Bergmann wrote:
On Friday 04 May 2007, Paul Fulghum wrote:
- It is fishy that apart from one outlier in kexec.h, synclink.h is the
only header file which uses compat_ulong_t. Are we doing this right?
Arnd, do you have any comment on this?
I think most others just define the compat
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
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
> b
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
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.
cdc
Arnd Bergmann wrote:
On Friday 04 May 2007, Paul Fulghum wrote:
- It is fishy that apart from one outlier in kexec.h, synclink.h is the
only header file which uses compat_ulong_t. Are we doing this right?
Arnd, do you have any comment on this?
I think most others just define the compat
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
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
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.
---
Andrew Morton wrote:
On Thu, 03 May 2007 13:01:17 -0500
Paul Fulghum <[EMAIL PROTECTED]> wrote:
Add compat_ioctl handler to synclink_gt driver.
i386 allmodconfig:
make[3]: *** No rule to make target
`/usr/src/devel/usr/include/linux/.check.synclink.h', needed by
`__headerscheck'.
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
has the advantage that a driver
can use the same function for both ->ioctl and ->compat_ioctl
if all calls are compatible.
Any comments on this or should I assume that
compat_ioctl() will stay with ulong return type?
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list
fine with it either way. I'm not in
a position to be making those kinds of decisions
for widely used infrastructure, so I'll leave
that for someone further up the food chain.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-k
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
a to the line discipline
without regard for tty->receive room.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/drivers/char/tty_io.c 2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-04 14:25:08.0 -0500
@@ -936,13 +936,6 @@ restar
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 Syst
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 in
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
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
clear any data in the hardware
receive FIFOs.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
in the hardware
receive FIFOs.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
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
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
}
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 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 problem.
Does
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
regard for tty-receive room.
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
--- a/drivers/char/tty_io.c 2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/tty_io.c 2007-05-04 14:25:08.0 -0500
@@ -936,13 +936,6 @@ restart:
return -EINVAL
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 possible
fine with it either way. I'm not in
a position to be making those kinds of decisions
for widely used infrastructure, so I'll leave
that for someone further up the food chain.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
has the advantage that a driver
can use the same function for both -ioctl and -compat_ioctl
if all calls are compatible.
Any comments on this or should I assume that
compat_ioctl() will stay with ulong return type?
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send
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
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
Andrew Morton wrote:
On Thu, 03 May 2007 13:01:17 -0500
Paul Fulghum [EMAIL PROTECTED] wrote:
Add compat_ioctl handler to synclink_gt driver.
i386 allmodconfig:
make[3]: *** No rule to make target
`/usr/src/devel/usr/include/linux/.check.synclink.h', needed by
`__headerscheck'. Stop.
I
Paul Fulghum wrote:
Arnd Bergmann wrote:
- In your driver you don't get the big kernel lock in the
compat_ioctl function. I assume that this is correct for
the particular driver, but it may be nice if you could
consequently also add an unlocked_ioctl function that can
be used without the BKL
Arnd Bergmann wrote:
- The return value of the new compat_ioctl methods should probably
'int', not 'long'. We've had the discussion before and then
decided not to change the existing compat_ioctl and
unlocked_ioctl functions -- even though int is more appropriate,
but having the same prototype
-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/include/linux/synclink.h 2007-04-25 22:08:32.0 -0500
+++ b/include/linux/synclink.h 2007-05-03 12:44:09.0 -0500
@@ -9,6 +9,8 @@
* the terms of the GNU Public License (GPL)
*/
+#include
+
#ifndef _SYNCLINK_H_
#define _SYNCL
Add compat_ioctl method for tty code to allow processing
of 32 bit ioctl calls on 64 bit systems by tty core,
tty drivers, and line disciplines.
Based on patch by Arnd Bergmann:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0511.0/1732.html
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]&
On Thu, 2007-05-03 at 00:05 -0700, Andrew Morton wrote:
> On Wed, 02 May 2007 11:17:33 -0500 Paul Fulghum <[EMAIL PROTECTED]> wrote:
>
> > Change synclink_gt driver to use dynamic tty device registration.
> >
> > ...
> >
> > + for (i=0; i < port_co
On Thu, 2007-05-03 at 00:05 -0700, Andrew Morton wrote:
On Wed, 02 May 2007 11:17:33 -0500 Paul Fulghum [EMAIL PROTECTED] wrote:
Change synclink_gt driver to use dynamic tty device registration.
...
+ for (i=0; i port_count; ++i)
+ tty_register_device(serial_driver
Add compat_ioctl method for tty code to allow processing
of 32 bit ioctl calls on 64 bit systems by tty core,
tty drivers, and line disciplines.
Based on patch by Arnd Bergmann:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0511.0/1732.html
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
CC: Arnd
-by: Paul Fulghum [EMAIL PROTECTED]
--- a/include/linux/synclink.h 2007-04-25 22:08:32.0 -0500
+++ b/include/linux/synclink.h 2007-05-03 12:44:09.0 -0500
@@ -9,6 +9,8 @@
* the terms of the GNU Public License (GPL)
*/
+#include linux/compat.h
+
#ifndef _SYNCLINK_H_
#define
Arnd Bergmann wrote:
- The return value of the new compat_ioctl methods should probably
'int', not 'long'. We've had the discussion before and then
decided not to change the existing compat_ioctl and
unlocked_ioctl functions -- even though int is more appropriate,
but having the same prototype
Paul Fulghum wrote:
Arnd Bergmann wrote:
- In your driver you don't get the big kernel lock in the
compat_ioctl function. I assume that this is correct for
the particular driver, but it may be nice if you could
consequently also add an unlocked_ioctl function that can
be used without the BKL
Arnd Bergmann wrote:
The same function contains a copy_from_user(), which cannot
be called with interrupts disabled, so yes, I am very certain
it will not change.
Good point.
--
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Arnd Bergmann wrote:
+ case MGSL_IOCGPARAMS32:
+ rc = get_params32(info, (struct MGSL_PARAMS32 __user
*)compat_ptr(arg));
+ break;
No need for the cast here.
OK, for some reason I remember getting a warning
error without it. I must have been mistaken.
+
+
Arnd Bergmann wrote:
Looks ok mostly. Just some details:
...
+#ifdef CONFIG_COMPAT
+ long (*compat_ioctl)(struct tty_struct *tty, struct file * file,
+unsigned int cmd, unsigned long arg);
+#endif
I wouldn't hide this inside of an #ifdef. The structures are
-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/drivers/char/synclink_gt.c2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/synclink_gt.c2007-05-02 14:52:48.0 -0500
@@ -73,6 +73,7 @@
#include
#include
#include
+#include
#include
#include
@@ -530,6 +531,10 @@
in compat_ioctl.[ch]
That will be implemented in a separate patch.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
CC: Arnd Bergmann <[EMAIL PROTECTED]>
--- a/drivers/char/n_tty.c 2007-04-30 15:13:19.0 -0500
+++ b/drivers/char/n_tty.c 2007-04-30 15:17:28.0 -0500
Change synclink_gt driver to use dynamic tty device registration.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/drivers/char/synclink_gt.c2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/synclink_gt.c2007-05-02 11:11:34.0 -0500
@@ -3415,6 +3415,9 @@
Change synclink_gt driver to use dynamic tty device registration.
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
--- a/drivers/char/synclink_gt.c2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/synclink_gt.c2007-05-02 11:11:34.0 -0500
@@ -3415,6 +3415,9 @@ static
in compat_ioctl.[ch]
That will be implemented in a separate patch.
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
CC: Arnd Bergmann [EMAIL PROTECTED]
--- a/drivers/char/n_tty.c 2007-04-30 15:13:19.0 -0500
+++ b/drivers/char/n_tty.c 2007-04-30 15:17:28.0 -0500
@@ -1545,21 +1545,18
-by: Paul Fulghum [EMAIL PROTECTED]
--- a/drivers/char/synclink_gt.c2007-04-25 22:08:32.0 -0500
+++ b/drivers/char/synclink_gt.c2007-05-02 14:52:48.0 -0500
@@ -73,6 +73,7 @@
#include linux/bitops.h
#include linux/workqueue.h
#include linux/hdlc.h
+#include linux/compat.h
Arnd Bergmann wrote:
Looks ok mostly. Just some details:
...
+#ifdef CONFIG_COMPAT
+ long (*compat_ioctl)(struct tty_struct *tty, struct file * file,
+unsigned int cmd, unsigned long arg);
+#endif
I wouldn't hide this inside of an #ifdef. The structures are
Arnd Bergmann wrote:
+ case MGSL_IOCGPARAMS32:
+ rc = get_params32(info, (struct MGSL_PARAMS32 __user
*)compat_ptr(arg));
+ break;
No need for the cast here.
OK, for some reason I remember getting a warning
error without it. I must have been mistaken.
+
+
Arnd Bergmann wrote:
The same function contains a copy_from_user(), which cannot
be called with interrupts disabled, so yes, I am very certain
it will not change.
Good point.
--
Paul
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Arnd Bergmann wrote:
So you are interested in the MGSL_* set of ioctls, right?
AFAICS, they are all compatible, with the exception of
MGSL_IOCGPARAMS and MGSL_IOCSPARAMS.
Fortunately, these two have different ioctl numbers on
64 bit, so you can define a new
#define MGSL_IOCSPARAMS32
Arnd Bergmann wrote:
It depends a lot on what your specific driver does in the ioctl
handler, but normally you should define a compat_ioctl() function.
What driver are you talking about?
drivers/char/synclink.c
drivers/char/synclinkmp.c
drivers/char/synclink_gt.c
to know what the
officially sanctioned method is. I haven't found any definitive
documentation and a review of mailing list archives does not
suggest a prevailing opinion.
Does anyone have pointers on which way would be most likely
to be accepted as a patch?
Thanks,
Paul
--
Paul Fulghum
Microgate
to know what the
officially sanctioned method is. I haven't found any definitive
documentation and a review of mailing list archives does not
suggest a prevailing opinion.
Does anyone have pointers on which way would be most likely
to be accepted as a patch?
Thanks,
Paul
--
Paul Fulghum
Microgate
Arnd Bergmann wrote:
It depends a lot on what your specific driver does in the ioctl
handler, but normally you should define a compat_ioctl() function.
What driver are you talking about?
drivers/char/synclink.c
drivers/char/synclinkmp.c
drivers/char/synclink_gt.c
Arnd Bergmann wrote:
So you are interested in the MGSL_* set of ioctls, right?
AFAICS, they are all compatible, with the exception of
MGSL_IOCGPARAMS and MGSL_IOCSPARAMS.
Fortunately, these two have different ioctl numbers on
64 bit, so you can define a new
#define MGSL_IOCSPARAMS32
Alan Cox wrote:
It breaks if any existing driver is doing no cleanup in ->open() when it
fails but relying upon ->close() being called. That is what needs
auditing first of all.
Yes, I did not think of that.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list
ctly without the extra
and unnecessary driver->close().
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-inf
and unnecessary driver-close().
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox wrote:
It breaks if any existing driver is doing no cleanup in -open() when it
fails but relying upon -close() being called. That is what needs
auditing first of all.
Yes, I did not think of that.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line
, altering the timing/behavior of the serial
device during open may be provoking the hardware fault.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
, altering the timing/behavior of the serial
device during open may be provoking the hardware fault.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
also suggested running cat on a standard serial port
and getting that working first. Then applying those stty
settings to his custom device/driver.
(Background: he says other user mode programs work
to read/write but that cat < /dev/foocustom does nothing.)
--
Paul Fulghum
Microgate Systems,
also suggested running cat on a standard serial port
and getting that working first. Then applying those stty
settings to his custom device/driver.
(Background: he says other user mode programs work
to read/write but that cat /dev/foocustom does nothing.)
--
Paul Fulghum
Microgate Systems, Ltd
Mockern wrote:
I have a question, what is really difference between serial and tty
drivers?
As I understand tty is high level and communicates with user space.
The serial core implements many of the details of a tty
driver in a common place so that individual hardware drivers
(serial
Mockern wrote:
> When it's necessary to use line discipline in tty driver
> (to call ldisc.write(), ldisc.read(), ldisc.receive_buf())
> and when I can ignore line discipline in my tty driver?
You should not call any of these from your driver.
transmit data is sent first to the line discipline
Mockern wrote:
When it's necessary to use line discipline in tty driver
(to call ldisc.write(), ldisc.read(), ldisc.receive_buf())
and when I can ignore line discipline in my tty driver?
You should not call any of these from your driver.
transmit data is sent first to the line discipline
Mockern wrote:
I have a question, what is really difference between serial and tty
drivers?
As I understand tty is high level and communicates with user space.
The serial core implements many of the details of a tty
driver in a common place so that individual hardware drivers
(serial
setting
should keep enabled. What makes it back to disabled? Now I guess there
must be something wrong with serial core.
Is there an mgetty or similar program monitoring
the same serial port?
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe
. What makes it back to disabled? Now I guess there
must be something wrong with serial core.
Is there an mgetty or similar program monitoring
the same serial port?
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
control how
much data must be available before returning data to a read().
Try VTIME=0 and VMIN=1.
Since your 'missing' data is always on the tail end, maybe
VMIN is set to 64 or something.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe
buffering code
followed by a tty_flip_buffer_push call).
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
P
buffering code
followed by a tty_flip_buffer_push call).
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
control how
much data must be available before returning data to a read().
Try VTIME=0 and VMIN=1.
Since your 'missing' data is always on the tail end, maybe
VMIN is set to 64 or something.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux
tional printk
to drivers/char/tty_io.c:flush_to_ldisc()
If tty->receive_room is less than the size of the buffer
passed to disc->receive_buf() then you are losing data.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
to drivers/char/tty_io.c:flush_to_ldisc()
If tty-receive_room is less than the size of the buffer
passed to disc-receive_buf() then you are losing data.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
again to get internal spinlock
With low_latency == 1, flush_to_ldisc() is deferred
until the ISR is complete and the internal spinlock is released.
I forget the exact driver callback that caused this.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line "un
Paul Fulghum wrote:
With low_latency == 1, flush_to_ldisc() is deferred
until the ISR is complete and the internal spinlock is released.
Oops, I meant low_latency == 0 of course.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-k
Paul Fulghum wrote:
With low_latency == 1, flush_to_ldisc() is deferred
until the ISR is complete and the internal spinlock is released.
Oops, I meant low_latency == 0 of course.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
and the internal spinlock is released.
I forget the exact driver callback that caused this.
--
Paul Fulghum
Microgate Systems, Ltd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
the
threads on LKML before posting about this solution.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- a/drivers/char/synclink.c 2006-11-29 15:57:37.0 -0600
+++ b/drivers/char/synclink.c 2006-12-01 14:38:13.0 -0600
@@ -101,8 +101,10 @@
#include
#include
-
the
threads on LKML before posting about this solution.
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
--- a/drivers/char/synclink.c 2006-11-29 15:57:37.0 -0600
+++ b/drivers/char/synclink.c 2006-12-01 14:38:13.0 -0600
@@ -101,8 +101,10 @@
#include linux/hdlc.h
#include linux/dma
lds that
do not conform to atomic_t, using volatile seems
a valid way of preventing the compiler from
optimizing access to the field out of a loop.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
[patch] synclink_cs add statistics clear
From: Paul Fulghum <[EMAIL PROTECTED]>
Add ability to clear statistics.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- linux-2.6.13/drivers/char/pcmcia/synclink_cs.c 2005-08-28
18:41:01.0 -0500
+++ linux-2.6.13-mg/drivers
[patch] synclink_cs add statistics clear
From: Paul Fulghum [EMAIL PROTECTED]
Add ability to clear statistics.
Signed-off-by: Paul Fulghum [EMAIL PROTECTED]
--- linux-2.6.13/drivers/char/pcmcia/synclink_cs.c 2005-08-28
18:41:01.0 -0500
+++ linux-2.6.13-mg/drivers/char/pcmcia
that
do not conform to atomic_t, using volatile seems
a valid way of preventing the compiler from
optimizing access to the field out of a loop.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
[patch] synclinkmp.c fix async internal loopback
From: Paul Fulghum <[EMAIL PROTECTED]>
Fix async internal loopback by not using
enable_loopback function which reprograms
clocking and should only be used for hdlc mode.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- linux-2.
[patch] synclinkmp.c add statistics clear
From: Paul Fulghum <[EMAIL PROTECTED]>
Add ability to clear statistics.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- linux-2.6.13/drivers/char/synclinkmp.c 2005-08-28 18:41:01.0
-0500
+++ linux-2.6.13-mg/drivers/char/
[patch] synclinkmp.c disable burst transfers
From: Paul Fulghum <[EMAIL PROTECTED]>
Disable burst transfers on adapter local bus.
Hardware feature does not work on latest
version of adapter.
Signed-off-by: Paul Fulghum <[EMAIL PROTECTED]>
--- linux-2.6.13/drivers/char/synclinkmp.c
101 - 200 of 265 matches
Mail list logo
