Troubleshooting interrupt delivery

[Stefan Kalkowski]

Hello Tomasz,

On Fri, Oct 15, 2021 at 01:06:26AM +0200, Tomasz Gajewski wrote:
> 
>     On Raspberry Pi 2 and 3 there are no other logs from this component.
> 
>     On Raspberry Pi 3 there is however a message that will probably
>     allow someone to explain me what is going on but unfortunately I
>     failed to explain it by myself for quite some time. This message is:
> 
>       Kernel: MMU-fault not handled ESR=0x92000035
>       Kernel: init -> drivers -> rpi_usb_host_drv -> ep raised unhandled MMU fault ip=0x70e80 fault-addr=0x1400c200 type=unknown
> 
>     and the fault-addr is exactly an address of the mutex that is being
>     locked. I've added two additional fields in this class (one before
>     the mutex and one after it) to verify that I can access (and modify)
>     their values and I can. But there is some problem with locking the
>     mutex that causes silent hang on Raspberry Pi 2 (arm_v7a) MMU-fault
>     on Raspberry Pi 3 (arm_v8a) and works without problems on Raspberry
>     Pi 1 (arm_v6).

The MMU fault means: "unsupported exclusive or atomic access", which
is propably due to the memory type the mutex is residing in. May it be
that the related memory is uncached? In that case the error would make
sense. Because the atomic monitoring is hardly coupled with
shareability/cache settings of the corresponding memory's page flags.

Just a general remark: I know you have spent much time on these
issues, and it might be frustrating to restart attempts to some
extent. But maybe following our new - the original semantic more
preserving - approach of porting Linux drivers might be more
sustainable for you too? At least Linux semantics like: this memory is
cached/uncached, cache maintainance operations, memory barriers etc.
are handled exactly like in the original code by following the new DDE
principles.
Also first blueprint drivers exist for USB, SD-card, Ethernet, display
manager etc. within the external repositories:

  https://github.com/nfeske/genode-allwinner.git
  https://github.com/skalk/genode-imx.git

Maybe, it is more fruitful to restart at least the USB host driver
with this new approach? But it's just an idea, no pressure ;-).

Best regards
Stefan

-- 
Stefan Kalkowski
Genode labs

https://github.com/skalk | https://genode.org