Re: Problem of concurrency in arch/ppc/8260_io/uart.c

Hi,

I have seen a similar problem for the 2.4.20.

When I force a lot of console output via the following command:

  while true; do cd /; ls -R; done

and type-in some letters in parallel, the console
becomes crazy.

I have added some instrumentation in order to dump the
TX Buffer Descriptor Table. I have found that the
hardware pointer (TBPTR) and the software pointer (tx_cur)
are not more synchronized together:

quoted

make new rlogin session <<

/root# cd /proc/driver

/root# cat uart-bdtables; cat mpc82xx/smc1_pram | grep SMC1_PRAM_TBPTR

TX BD table
  (000 at 0xfff005f0) status: 0x1000 len: 0001 addr: 0x001bb084
  (001 at 0xfff005f8) status: 0x1000 len: 0001 addr: 0x001bb0a4
* (002 at 0xfff00600) status: 0x1000 len: 0001 addr: 0x001bb0c4
  (003 at 0xfff00608) status: 0x3000 len: 0004 addr: 0x001bb0e4
   SMC1_PRAM_TBPTR            0x20         2     0600

   --> hardware and software pointer still synchronized

   >> force console to become crazy (see above) <<

/root# cat uart-bdtables; cat mpc82xx/smc1_pram | grep SMC1_PRAM_TBPTR

TX BD table (tbptr: 0x00000088)
  (000 at 0xfff005f0) status: 0x1000 len: 0003 addr: 0x001bb084
* (001 at 0xfff005f8) status: 0x1000 len: 0021 addr: 0x001bb0a4
  (002 at 0xfff00600) status: 0x1000 len: 0001 addr: 0x001bb0c4
  (003 at 0xfff00608) status: 0x3000 len: 0001 addr: 0x001bb0e4
   SMC1_PRAM_TBPTR            0x20         2     0600

   --> hardware and software pointer NOT more synchronized

   >> make additional console output: echo foo >/dev/console <<

/root# cat uart-bdtables; cat mpc82xx/smc1_pram | grep SMC1_PRAM_TBPTR

* (000 at 0xfff005f0) status: 0x1000 len: 0003 addr: 0x001bb084
  (001 at 0xfff005f8) status: 0x9000 len: 0004 addr: 0x001bb0a4
  (002 at 0xfff00600) status: 0x1000 len: 0001 addr: 0x001bb0c4
  (003 at 0xfff00608) status: 0x3000 len: 0001 addr: 0x001bb0e4
   SMC1_PRAM_TBPTR            0x20         2     05f0

   --> hardware pointer hangs at 0x5f0 because R-Bit not set, but
       at 0x5f8

Inside uart.c, there are the following output routines:

  rs_8xx_put_char()
  rs_8xx_write()
  rs_8xx_send_xchar()
  my_console_write()

I think there must be a synchronization accessing the
TX BD table. I suggest the patch attached.


Best Regards
Steffen
--


--------------------------------------------------------------

Steffen Rumler
ICN CP D NT SW 7
Siemens AG
Hofmannstr. 51                 Email: Steffen.Rumler@siemens.com
D-81359 Munich                 Phone: +49 89 722-44061
Germany                        Fax  : +49 89 722-36703

--------------------------------------------------------------

Hi,

Hi Steffen.

I have seen a similar problem for the 2.4.20.

When I force a lot of console output via the following command:

   while true; do cd /; ls -R; done

and type-in some letters in parallel, the console
becomes crazy.

My custom mpc860 also becomes crazy or just locks up when I do this. The
drivers are pretty the same, so this is no surprise.

I have added some instrumentation in order to dump the
TX Buffer Descriptor Table. I have found that the
hardware pointer (TBPTR) and the software pointer (tx_cur)
are not more synchronized together:
Inside uart.c, there are the following output routines:

[SNIP]

   rs_8xx_put_char()
   rs_8xx_write()
   rs_8xx_send_xchar()
   my_console_write()

I think there must be a synchronization accessing the
TX BD table. I suggest the patch attached.

Hmm, don't you turn off irq's for a long time with this patch?

 Jocke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/