Thank you Stefan for quick response.
Stefan Kalkowski stefan.kalkowski@genode-labs.com writes:
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.
This information is definitely important and gives me something I can trace for. Thank you.
Nevertheless I'm curious why there is no similar message when executing on arm_v7a even though error probably happens. First message is missing for this architecture (in [1] I tried to add log to similar log to one for arm_v8a). Unfortunately nothing about error is printed and that's why I initially suspected problems with interrupts delivery. Especially that new platrorm driver introduced changes in handling of interrupts.
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.
I'm well aware of this and maybe I'll make an attempt to start again using this new aproach but I wouldn't like to fight with too many changes at once. And there are many changes in this area implemented in recent months. They are all great but each require some porting and if there is too much of them at once this work becomes uncomprehensible for me in limited time I can spend on it.
On the other side as this driver was somewhat working (not really stable at that time) for rpi 1/2/3 I initially want to rebase to current release. Unfortunately introducing platform driver made some change in behavior that cause trouble. I hope I'll be able to make it work and maybe later try an upgrade. Being able to compare behavior between working and new implementations definitely would help with troubleshooting.
[1] https://github.com/tomga/genode/blob/8aa1a006d33de38b879c0acced7231f9513273f...
Regards Tomasz Gajewski