On Mon, Jan 29, 2007 at 02:27:07PM -0500, Lennart Sorensen wrote:
> I have run some tests with 8 patches from Linus's 2.6 tree on top of the
> 2.6.16.25 along with a bit of debug code in the n_tty.c, which ran
> perfectly for 3 days. I now removed the debug code to see if it will
> still run perfe
On Fri, Jan 26, 2007 at 11:08:42AM -0500, Lennart Sorensen wrote:
> OK, the tty settings according to stty that I am using are:
> # stty -F /dev/ttyn0 -a
> speed 230400 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 =
> ; start = ^Q; stop =
On Fri, Jan 26, 2007 at 09:06:52AM -0600, Paul Fulghum wrote:
> ioctl(TIOCSETD/TIOCGETD) sets/returns an integer identifier
> that can be compared agains the N_XXX macros. If you are
> not explicitly setting this then is is probably the default N_TTY.
Yes it is N_TTY (value 0). I never set it.
>
Lennart Sorensen wrote:
I am not sure actually. I just open /dev/ttyn0 and /dev/ttyn1 and write
to one, and read from the other. I didn't even know about the line
diciplines actually. How do I tell which one I am using?
ioctl(TIOCSETD/TIOCGETD) sets/returns an integer identifier
that can be
On Fri, Jan 26, 2007 at 08:51:02AM -0600, Paul Fulghum wrote:
> You can eliminate the tty buffering altogether
> by observing what gets passed to the line discipline.
I will have to find where in the code that is happening.
> I assume you are using the default line discipline N_TTY.
>
> Look at
Lennart Sorensen wrote:
Well it turns out that didn't help. Neither does 2.6.18 (that one was
the easiest newer one to try). It does seem as if the error rate is
lower with 2.6.18 than with 2.6.16, so perhaps there was more than one
place that could cause losses in the tty buffering. I had onl
On Thu, Jan 25, 2007 at 10:16:39AM -0500, Lennart Sorensen wrote:
> I am now trying this, which so far seem to help (I had a printk in there
> earlier and managed to trigger that).
>
> --- ori/drivers/char/tty_io.c 2007-01-24 18:02:48.0 -0500
> +++ new/drivers/char/tty_io.c 2007-01-25 09:5
On Wed, Jan 24, 2007 at 03:20:53PM -0600, Paul Fulghum wrote:
> In 2.6.16 the tty buffering pushes data to the line
> discipline without regard to tty->receive_room.
> If the line discipline can't keep up, the data gets dropped.
> I observed this data loss at higher speeds when
> placing the system
On Wed, Jan 24, 2007 at 04:34:47PM -0500, Lennart Sorensen wrote:
> I am using the GPIO lines too, and didn't want to mess with the 8250
> driver (since I use that for a serial console on a 16550 UART), plus
> being able to use the 64byte fifo rather than 16byte 16550 mode fifo
> seems nicer.
Note
On Wed, Jan 24, 2007 at 03:20:53PM -0600, Paul Fulghum wrote:
> In 2.6.16 the tty buffering pushes data to the line
> discipline without regard to tty->receive_room.
> If the line discipline can't keep up, the data gets dropped.
> I observed this data loss at higher speeds when
> placing the system
On Wed, Jan 24, 2007 at 03:19:53PM -0600, Kilau, Scott wrote:
> There are a couple interesting things I would do here.
>
> 1) The tty "flip" buffer stuff was changed in 2.6.16+.
>
> Maybe you could try going downwards to 2.6.15 or below and see if the
> problem
> still exists.
That looked like a
Lennart Sorensen wrote:
I have confirmed that the driver does in fact receive all the
characters, and that they are correct, and that they are being passed to
the tty layer using tty_insert_flip_string, and that it returns that all
the characters have been passed to the tty layer. The user space
Hi Len,
> I am seeing a very strange problem which seems to be in the tty layer.
>
> I am using an exar 17D154 based PCI card (like the digi neo style
card)
> using the jsm driver. Kernel version 2.6.16.25.
There are a couple interesting things I would do here.
1) The tty "flip" buffer stuff w
I am seeing a very strange problem which seems to be in the tty layer.
I am using an exar 17D154 based PCI card (like the digi neo style card)
using the jsm driver. Kernel version 2.6.16.25.
My test involves connecting two ports together with a cross over cable
and then sending a test pattern of
14 matches
Mail list logo
