Re: [PATCH] rtdm/drvlib: Prevent pagefaults on arm on io mapping

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 20.06.22 12:44, Grau, Gunter wrote:
>> Hi,
>> 
>> I added a dump_stack() in cobalt_assert_nrt() where the XCPU signal is generated.
>> Maybe you can give me advice if you need better information.
>> 
>> [   13.690407] CPU: 1 PID: 581 Comm: UT1  Tainted: G           O      5.4.191-00703-gbfba1d43d087-dirty #23
>> [   13.699901] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
>> [   13.714083] I-pipe domain: Linux
>> [   13.717347] [<8010f314>] (unwind_backtrace) from [<8010b824>] (show_stack+0x10/0x14)
>> [   13.725118] [<8010b824>] (show_stack) from [<8084604c>] (dump_stack+0xd8/0xf4)
>> [   13.732365] [<8084604c>] (dump_stack) from [<801d8318>] (ipipe_trap_hook+0x1b0/0x33c)
>> [   13.748287] [<801d8318>] (ipipe_trap_hook) from [<801be9d0>] (__ipipe_notify_trap+0x98/0xdc)
>> [   13.748304] [<801be9d0>] (__ipipe_notify_trap) from [<80114114>] (do_page_fault+0x20/0x444)
>> [   13.748317] [<80114114>] (do_page_fault) from [<80114800>] (do_DataAbort+0x3c/0xe0)
>> [   13.782231] [<80114800>] (do_DataAbort) from [<80101f7c>] (__dabt_usr+0x3c/0x40)
>> [   13.789655] Exception stack(0xc2129fb0 to 0xc2129ff8)
>> [   13.794735] 9fa0:                                     6c1d7000 00000600 72c61910 0000013c
>> [   13.802954] 9fc0: 72bff024 72c618e8 004247c8 76ba5000 ffffffff 00000000 004247c8 6a87da3c
>> [   13.811155] 9fe0: 6c1d9000 6a87da20 00020000 72bb5c68 20010010 ffffffff
>
> OK, a regular page fault that the out-of-band code in I-pipe was not
> able to fix up. The question is whether we lack some logic there to do
> that or if that fixup really requires Linux.
>
> Can you trace which resolution Linux applies to this after switching to
> non-RT? Or do you already have a suspicion, Philippe?
>
> Can this be reproduced in qemu-arm as well? With some dummy device and
> driver? Would allow to examine it also with Dovetail.
>
> Jan

The I-pipe is wrong at:
https://source.denx.de/Xenomai/ipipe-arm/-/blob/ipipe/master/arch/arm/mm/fault.c#L564

Reporting a trap entry to the real-time core should be postponed until
__do_kernel_fault() can attempt to fixup the exception, in which case
we would remain on the oob stage as expected:
https://source.denx.de/Xenomai/ipipe-arm/-/blob/ipipe/master/arch/arm/mm/fault.c#L265
https://source.denx.de/Xenomai/ipipe-arm/-/blob/ipipe/master/arch/arm/mm/fault.c#L200

Dovetail has it right:
https://source.denx.de/Xenomai/linux-dovetail/-/blob/v5.19-dovetail-rebase/arch/arm/mm/fault.c#L557
https://source.denx.de/Xenomai/linux-dovetail/-/blob/v5.19-dovetail-rebase/arch/arm/mm/fault.c#L279
https://source.denx.de/Xenomai/linux-dovetail/-/blob/v5.19-dovetail-rebase/arch/arm/mm/fault.c#L205

-- 
Philippe.