Problem of concurrency in arch/ppc/8260_io/uart.c
Jean-Denis Boyer
jdboyer at m5t.com
Tue Sep 16 02:26:58 EST 2003
I have just tested your patch on 8260 and it fixes the problem when printk is called from interrupt context while data is printed from user mode application. GREAT!
I also ported the patch to 860 (as said earlier, code is almost the same), but it hung at boot up, just after printing "Calibrating delay loop..." :-(
I remember I had such problems in the past (on 860), when calling "spin_lock_irqsave/restore" from interrupt context. If I use function "in_interrupt()" to avoid calling them from interrupt, everything works fine, and the bug is effectively fixed.
I just don't know where is the problem??? It looks like there is a bug on 860 using "local_irq_save/restore" in interrupt context?!?
I'm working with 2.4.19.
--------------------------------------------
Jean-Denis Boyer, Eng.
Software Designer
M5T Centre d'Excellence en Télécom Inc.
4283 Garlock Street
Sherbrooke (Québec)
J1L 2C8 CANADA
(819)829-3972 x241
--------------------------------------------
> -----Original Message-----
> From: Steffen Rumler [mailto:Steffen.Rumler at siemens.com]
> Sent: 15 septembre, 2003 06:18
> To: linuxppc
> Subject: 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:
>
> >> 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 at siemens.com
> D-81359 Munich Phone: +49 89 722-44061
> Germany Fax : +49 89 722-36703
>
> --------------------------------------------------------------
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-embedded
mailing list