Thank you Stefan for quick response. Stefan Kalkowski <stefan.kalkow...@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/8aa1a006d33de38b879c0acced7231f9513273f2/repos/base-hw/src/core/spec/arm/cpu.cc#L85 Regards Tomasz Gajewski _______________________________________________ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
