Date:	Sat, 5 May 2007 11:53:39 +0200
From:	"Antonino Ingargiola" <tritemio@...il.com>
To:	"Paul Fulghum" <paulkf@...rogate.com>
Cc:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	linux-usb-users@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

On 5/4/07, Paul Fulghum <paulkf@...rogate.com> 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 assume you meant tty_buffer_flush(). I've built kernel 1). In kernel
2), do you mean:

    /*if (ld->ioctl)
            tty_buffer_flush(tty);*/
    tty_ldisc_deref(ld);

right? This is what I'm building... I'll report these new tests soon.

While waiting for kernel building I'll document the testing procedure.
In this way someone else can easily try to reproduce the problem.

1. Hardware.

Two serial ports required. Connect the two port witth a null-modem
cable, or patch, for each port the Tx pin with the Rx of the other
port[0].

2. Software

I assume python is installed. Install also pyserial[1] (in debian
python-serial), if you manually download the package you can put the
"serial" dir in the dir you use to perform the test (no need to
install system-wide). If you can, install also the ipython shell that
has colored output and auto-completition.

3. Test

>From the python shell:

    import serial
    s0 = serial.Serial(0, timeout=1)

open the /dev/ttyS0 port with default values, hit 's0' [enter] to see
the serial parameters.

    s1 = serial.Serial(1, timeout=1)

with the previous comma we open /dev/ttyS1 with the same serial port
settings. To write to one serial port:

    s0.write('test\n')

and to read use the .read() or .readline() method:

    s1.readline()

The .inWaiting() methods gives the numbers of bytes in the input
buffer. The .flushInput() method flushes the input buffer:

	In [6]: s0.write('test\n')

	In [7]: s1.inWaiting()
	Out[7]: 5L

	In [8]: s1.readline()
	Out[8]: 'test\n'

	In [9]: s1.inWaiting()
	Out[9]: 0L

If all works, now fill one serial port with a bunch of data (an
increasing 8-digit number):

    for i in xrange(10000):
        s0.write(str(i).zfill(8)+'\n')

we can see that the s1 input buffer is full:

    s1.inWaiting()
    Out[21]: 4095L

then empty the buffer and see what happens:

	In [22]: s1.flushInput()
	In [23]: s1.inWaiting()
	Out[23]: 4095L

the buffer is still full. You have to flush the buffer more then once
to completely flush all the buffer chain (including the flip buffer).
With the patched kernel at this point I get correctly:

	In [22]: s1.flushInput()
	In [23]: s1.inWaiting()
	Out[23]: 0L

but then I can't read any other byte from the serial without closing
and reopening it:

	In [24]: s0.write('test\n')

	In [25]: s1.inWaiting()
	Out[25]: 0L

	In [26]: s1.read()
	Out[26]: ''

	In [27]: s1.close()

	In [28]: s1.open()

	In [29]: s1.inWaiting()
	Out[29]: 0L

	In [30]: s0.write('test\n')

	In [31]: s1.inWaiting()
	Out[31]: 5L

	In [32]: s1.readline()
	Out[32]: 'test\n'

Hope the explanation is clear If someone else want to try...

Regards,

  ~ Antonio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists