[PATCH v9 1/6] arm64: Add macros to manage processor debug state

[Catalin Marinas]

On Wed, Feb 19, 2014 at 04:44:05AM +0000, Vijay Kilari wrote:
> On Tue, Feb 18, 2014 at 5:32 PM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
> > On Tue, Feb 18, 2014 at 11:29:40AM +0000, Vijay Kilari wrote:
> >> On Mon, Feb 17, 2014 at 6:31 PM, Catalin Marinas
> >> <catalin.marinas at arm.com> wrote:
> >> > On Mon, Feb 17, 2014 at 12:21:45PM +0000, Vijay Kilari wrote:
> >> >>    If it is ok, can you please merge these patches
> >> >
> >> > I was about to merge them but I wanted to try first. Enabling kgd tests
> >> > at boot time, I get plenty of failures as below. Have you successfully
> >> > run the kgdb tests?
> >>
> >>   I re-tested v9 version patches with our internal arm64 simulator and
> >> I don't see these warnings. Also I tested with 3.13 kernel from linaro with v8
> >> foundation model and no errors are seen (logs below).
> >
> > It's good to know. Could you please rebase against 3.14-rc3 and rerun
> > the tests? If they work, please send me your .config file that you used
> > with the foundation model.
> >
> > (and since you rebase on 3.14-rc3, you could repost a v10 with all the
> > acks in place so that it's easier for me to merge)
> 
>  Reposted v10 version of patches which is rebased on 3.14-rc3 kernel.
> Test results are as follows on v8 foundation model.
> 
>  vda: vda1 vda2
> kgdb: Registered I/O driver kgdbts.
> kgdbts:RUN plant and detach test
> kgdbts:RUN sw breakpoint test
> kgdbts:RUN bad memory access test
> kgdbts:RUN singlestep test 1000 iterations
> kgdbts:RUN singlestep [0/1000]
> kgdbts:RUN singlestep [100/1000]
> kgdbts:RUN singlestep [200/1000]
> kgdbts:RUN singlestep [300/1000]
> kgdbts:RUN singlestep [400/1000]
> kgdbts:RUN singlestep [500/1000]
> kgdbts:RUN singlestep [600/1000]
> kgdbts:RUN singlestep [700/1000]
> kgdbts:RUN singlestep [800/1000]
> kgdbts:RUN singlestep [900/1000]
> kgdbts:RUN do_fork for 100 breakpoints

OK, I eventually managed to reproduce this. But by running with two
CPUs, I get (during the do_fork() tests):

BUG: scheduling while atomic: kworker/u8:0/6/0x00000002
Modules linked in:
CPU: 1 PID: 6 Comm: kworker/u8:0 Not tainted 3.14.0-rc3+ #306
Workqueue: khelper __call_usermodehelper
Call trace:
[<ffffffc000087dbc>] dump_backtrace+0x0/0x12c
[<ffffffc000087efc>] show_stack+0x14/0x1c
[<ffffffc00043c224>] dump_stack+0x78/0xc4
[<ffffffc000439b48>] __schedule_bug+0x40/0x54
[<ffffffc00043d67c>] __schedule+0x514/0x604
[<ffffffc00043d794>] schedule+0x28/0x78
[<ffffffc00043cc90>] schedule_timeout+0x170/0x1bc
[<ffffffc00043e16c>] wait_for_common+0xc0/0x14c
[<ffffffc00043e280>] wait_for_completion_killable+0x14/0x28
[<ffffffc0000942f8>] do_fork+0x158/0x2a8
[<ffffffc000094478>] kernel_thread+0x30/0x38
[<ffffffc0000a842c>] __call_usermodehelper+0x34/0xa8
[<ffffffc0000ab300>] process_one_work+0x118/0x354
[<ffffffc0000abfcc>] worker_thread+0x13c/0x3c0
[<ffffffc0000b1e84>] kthread+0xd4/0xe8


It gets much worse if I run with two CPUs and CONFIG_KGDB_KDB enabled
(but fine with a single CPU).

So no need to post another series for now but please check the multi-CPU
case as well and send a separate fix. I'll dig a bit on my side as well.

-- 
Catalin