All of lore.kernel.org
 help / color / mirror / Atom feed
* [PPC/MPC5200B] strange data loss on uart reception
@ 2010-10-31 17:27 Albrecht Dreß
  2010-11-01  3:10 ` Greg KH
  0 siblings, 1 reply; 5+ messages in thread
From: Albrecht Dreß @ 2010-10-31 17:27 UTC (permalink / raw)
  To: linux-serial

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

[re-posted from the linuxppc-dev list...]

Hi all,

I'm not sure if this is the right list, so please excuse me if I'm totally wrong here, or if my question is really dumb...

My platform is a MPC5200B (roughly Icecube) based board with kernel 2.6.32.  From a PC I try to send data through the MPC5200B's serial port, using the standard mpc52xx_uart driver.  The reading process is rather slow in processing the incoming data.  Thus, the uart is configured to use rts/cts  handshaking.  The port is opened in (O_EXCL | O_RDWR) mode.

Sending large data blocks to the 5200, I noticed that complete chunks of data are missing in the output read in user space.  This is apparently *not* a problem on the uart layer; the result of the TIOCGICOUNT ioctl does not report any errors from the uart, and the serial_icounter_struct.rx field contains *exactly* the correct number of data bytes I transmitted.  The data loss seems to occur only if the block is larger than 64 kByte, but I didn't find a scheme of the actually missing number of bytes.  However, it's always a larger chunk of several hundred bytes to kBytes.

Am I simply too dumb to use the uart correctly, or is there some issue in the kernel causing this effect?  I noticed that the function mpc52xx_uart_int_rx_chars() does not check the return value of tty_insert_flip_char().  If the system runs out of space (actually, the maximum buffer size used should be limited, in particular on embedded systems!), might this go undetected?  This might explain the bigger "chunks", as the '5200's uart has a rather big fifo (512 bytes).

Any insight would be really appreciated!

Thanks in advance,
Albrecht.

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PPC/MPC5200B] strange data loss on uart reception
  2010-10-31 17:27 [PPC/MPC5200B] strange data loss on uart reception Albrecht Dreß
@ 2010-11-01  3:10 ` Greg KH
  2010-11-01 14:41   ` Albrecht Dreß
  0 siblings, 1 reply; 5+ messages in thread
From: Greg KH @ 2010-11-01  3:10 UTC (permalink / raw)
  To: Albrecht Dre?; +Cc: linux-serial

On Sun, Oct 31, 2010 at 06:27:00PM +0100, Albrecht Dre? wrote:
 Am I simply too dumb to use the uart correctly, or is there some issue
> in the kernel causing this effect?  I noticed that the function
> mpc52xx_uart_int_rx_chars() does not check the return value of
> tty_insert_flip_char().  If the system runs out of space (actually,
> the maximum buffer size used should be limited, in particular on
> embedded systems!), might this go undetected?  This might explain the
> bigger "chunks", as the '5200's uart has a rather big fifo (512
> bytes).

That might help, have you tried changing this and seeing if it fixes
anything?

Also, are you sure your userspace application is checking the return
value of write() to verify that it really wrote everything it thought it
did?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PPC/MPC5200B] strange data loss on uart reception
  2010-11-01  3:10 ` Greg KH
@ 2010-11-01 14:41   ` Albrecht Dreß
  2010-11-02 18:06     ` Albrecht Dreß
  0 siblings, 1 reply; 5+ messages in thread
From: Albrecht Dreß @ 2010-11-01 14:41 UTC (permalink / raw)
  To: Greg KH, linux-serial

[-- Attachment #1: Type: text/plain, Size: 2647 bytes --]

Am 01.11.10 04:10 schrieb(en) Greg KH:
> On Sun, Oct 31, 2010 at 06:27:00PM +0100, Albrecht Dre? wrote:
>> Am I simply too dumb to use the uart correctly, or is there some issue in the kernel causing this effect?  I noticed that the function mpc52xx_uart_int_rx_chars() does not check the return value of tty_insert_flip_char().  If the system runs out of space (actually, the maximum buffer size used should be limited, in particular on embedded systems!), might this go undetected?  This might explain the bigger "chunks", as the '5200's uart has a rather big fifo (512 bytes).
> 
> That might help, have you tried changing this and seeing if it fixes anything?

Hmmm, apparently it's not possible to disable the fifo completely in this chip if I interpret the manual correctly.  I played with the fifo alarm levels (the number of space left in the fifo to immediately trigger an irq), though, and it doesn't change anything.

> Also, are you sure your userspace application is checking the return value of write() to verify that it really wrote everything it thought it did?

The UART is connected to a ftdi usb/rs232 converter, and I write data using USB functions into the ftdi, which in turn sends them into the 5200's uart at 3 MBaud (yes, the wires are *very* short, and the uart doesn't see any framing or parity errors... ;-).  And I am pretty sure the uart's rx register sees the correct number of bytes, as the TIOCGICOUNT ioctl reports exactly the number of bytes I sent.  The rx counter is updated in the isr mpc52xx_uart_int_rx_chars() which reads data from the fifo, btw.

However, in this function I added a printk when tty_insert_flip_char() returns 0, and actually this happens when more than 64kb are sent quickly!  Reading through the code, the following seems to happen:
- tty_insert_flip_char() detects that the struct tty_buffer is full and calls tty_insert_flip_string_flags()
- tty_insert_flip_string_flags() calls tty_buffer_request_room()
- tty_buffer_request_room() calls tty_buffer_find()
- tty_buffer_find() calls tty_buffer_alloc() if no free buffer is found
- tty_buffer_alloc() contains at the very beginning

         if (tty->buf.memory_used + size > 65536)
                 return NULL;

I didn't add more debug output here, but for me it looks as if the kernel simply rejects buffering more than 64kByte.  Could this be the correct interpretation of the path outlined above?  If this is the case, then IMHO there is a serious problem, as data can be lost completely undetected, at least in any uart driver which ignores the return value of tty_insert_flip_char()!

Thanks,
Albrecht.

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PPC/MPC5200B] strange data loss on uart reception
  2010-11-01 14:41   ` Albrecht Dreß
@ 2010-11-02 18:06     ` Albrecht Dreß
  2010-11-03  4:02       ` Greg KH
  0 siblings, 1 reply; 5+ messages in thread
From: Albrecht Dreß @ 2010-11-02 18:06 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-serial

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Am 01.11.10 15:41 schrieb(en) Albrecht Dreß:
> Am 01.11.10 04:10 schrieb(en) Greg KH:
>> On Sun, Oct 31, 2010 at 06:27:00PM +0100, Albrecht Dre? wrote:
>>> Am I simply too dumb to use the uart correctly, or is there some issue in the kernel causing this effect?  I noticed that the function mpc52xx_uart_int_rx_chars() does not check the return value of tty_insert_flip_char().  If the system runs out of space (actually, the maximum buffer size used should be limited, in particular on embedded systems!), might this go undetected?  This might explain the bigger "chunks", as the '5200's uart has a rather big fifo (512 bytes).
>> 
>> That might help, have you tried changing this and seeing if it fixes anything?

Ummm.  Apparently this was a hardware problem.  No errors on a 2nd board, and re-soldering the chip on the 1st fixed it there, too.  Probably a "cold" soldering.

Sorry for the noise!

Cheers, Albrecht.

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PPC/MPC5200B] strange data loss on uart reception
  2010-11-02 18:06     ` Albrecht Dreß
@ 2010-11-03  4:02       ` Greg KH
  0 siblings, 0 replies; 5+ messages in thread
From: Greg KH @ 2010-11-03  4:02 UTC (permalink / raw)
  To: Albrecht Dre?; +Cc: linux-serial

On Tue, Nov 02, 2010 at 07:06:02PM +0100, Albrecht Dre? wrote:
> Am 01.11.10 15:41 schrieb(en) Albrecht Dre?:
>> Am 01.11.10 04:10 schrieb(en) Greg KH:
>>> On Sun, Oct 31, 2010 at 06:27:00PM +0100, Albrecht Dre? wrote:
>>>> Am I simply too dumb to use the uart correctly, or is there some issue in the kernel causing this effect?  I noticed that the function mpc52xx_uart_int_rx_chars() does not check the return value of tty_insert_flip_char().  If the system runs out of space (actually, the maximum buffer size used should be limited, in particular on embedded systems!), might this go undetected?  This might explain the bigger "chunks", as the '5200's uart has a rather big fifo (512 bytes).
>>>
>>> That might help, have you tried changing this and seeing if it fixes anything?
>
> Ummm.  Apparently this was a hardware problem.  No errors on a 2nd board, and re-soldering the chip on the 1st fixed it there, too.  Probably a "cold" soldering.

Ah, good, I like the "buggy hardware" type resolutions :)

thanks for letting us know.

greg k-h

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-11-03  4:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-31 17:27 [PPC/MPC5200B] strange data loss on uart reception Albrecht Dreß
2010-11-01  3:10 ` Greg KH
2010-11-01 14:41   ` Albrecht Dreß
2010-11-02 18:06     ` Albrecht Dreß
2010-11-03  4:02       ` Greg KH

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.