[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191231153703.GA15302@afzalpc>
Date: Tue, 31 Dec 2019 21:07:03 +0530
From: afzal mohammed <afzal.mohd.ma@...il.com>
To: Russell King <linux@...linux.org.uk>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>,
Catalin Marinas <catalin.marinas@....com>,
Greg Ungerer <gerg@...ux-m68k.org>,
Vladimir Murzin <vladimir.murzin@....com>
Subject: Re: [RFC PATCH 2/2] ARM: !MMU: v7-M: preemption support
Hi,
On Mon, Dec 30, 2019 at 05:25:27PM +0530, afzal mohammed wrote:
> A. Before this change,
>
> A.1
> ~ # cat /dev/mymisc
> [ 28.099225] mymisc_open
> [ 28.101625] mymisc_read: enter
>
> command prompt is not usable (expected), interrupts do happen during
> this time.
> B. After this change,
>
> B.1
> ~ # cat /dev/mymisc
> [ 27.374821] mymisc_open
> [ 27.377349] mymisc_read: enter
>
> though user will not get control back (as expected as it is fg process),
> entering on prompt causes new line, doesn't know what to make out of
> this behaviour, this doesn't happen in the A.1 case. Interrupts happen
> here as well.
Behaviour B.1 (which is how most of the system behaves) seems due to
serial driver's threaded interrupt handler being able to preempt 'cat'
process, this can't happen in the case of A.1 as preemption doesn't
work.
Also it seems that preemption does happen by tracking __schedule() at
runtime, but issue mentioned in B.2 (below) remains.
So it seems preemption is happening, but is very fragile.
Regards
afzal
> B.2
> ~ # cat /dev/mymisc &
> [1] 41 cat /dev/mymisc
> ~ # [ 44.836417] mymisc_open
> [ 44.838814] mymisc_read: enter
>
> though prompt is available under the control of user, upon typing
> anything on the prompt (typed character doesn't get echoed), it crashes
> as follows,
>
> [ 44.838814] mymisc_read: enter
> [ 51.710314]
> [ 51.710314] Unhandled exception: IPSR = 00000006 LR = fffffffd
> [ 51.717576] CPU: 0 PID: 37 Comm: sh Not tainted 5.5.0-rc4-00004-g2328d01dbd85 #105
> [ 51.725078] Hardware name: STM32 (Device Tree Support)
> [ 51.730206] PC is at 0x90195958
> [ 51.733329] LR is at 0x901c4df3
> [ 51.736471] pc : [<90195958>] lr : [<901c4df3>] psr: 21000000
> [ 51.742713] sp : 901e5a58 ip : 00000000 fp : 901d89fc
> [ 51.747911] r10: 00000000 r9 : 00000000 r8 : 00000001
> [ 51.753143] r7 : 000000a8 r6 : 901e5a58 r5 : 901e5b08 r4 : ffffffff
> [ 51.759643] r3 : 000000a8 r2 : ffffffff r1 : 00000001 r0 : 00000001
> [ 51.766122] xPSR: 21000000
> [ 51.768866] CPU: 0 PID: 37 Comm: sh Not tainted 5.5.0-rc4-00004-g2328d01dbd85 #105
> [ 51.776369] Hardware name: STM32 (Device Tree Support)
> [ 51.781594] [<0800c0c9>] (unwind_backtrace) from [<0800b25b>] (show_stack+0xb/0xc)
> [ 51.789166] [<0800b25b>] (show_stack) from [<0800b9eb>] (__invalid_entry+0x4b/0x4c)
>
> It is a Usage Fault happening while in thread(user) mode. PC & LR in the
> dump is strange in the sense that they do not point to text section.
Powered by blists - more mailing lists