Hi, On 4/13/19 2:11 AM, Michael Schmitz wrote: [...]
Here problem is the second value in stack. Maybe missing auto-increment when auto-increment instruction page faults causes later issues, when bus errors with them are ignored. => I'll discuss this on Hatari list
Toni's reply: --------------------------------------------------- I guess this means CPU does increment (and pre-decrement, possibly even flags are partially set at this point depending on instruction) before MMU detects the fault and because MMU is not fully integrated to CPU (like in 68040+. 68030 is basically 68020+68851+data cache integrated in single package with reduced 68851 instruction set), it is MMU's task to handle the exception logic which means there is only fault address that needs to be known (source of address is irrelevant at this point) and CPU only needs to know where to continue execution after RTE. 68030 continues after MMU fault, 68040+ restarts. Current emulation can't handle this because whole instruction is retried (with already executed memory writes skipped and already executed reads returning "cached" values to simulate continuation). Most likely new "68030 MMU continuation" CPU core would be needed to fully emulate this behavior. Fortunately this is undocumented behavior so no "normal" program should care except perhaps some debugger like programs. ---------------------------------------------------
Yes, missing auto-increment or additional stack fixup that the m68k kernel does not expect might cause trouble later on. My hack to sidestep bus error to the parent process may also have unintended side effects.
You mean things like bus_error030() function and the faulting functions list of clobbered instructions and stack fixup not matching each other yet, even on real HW? > The kernel didn't crash yet, but there's no load to speak of on that > system. You were using SLAB allocator, so I think I need to test that now (instead of default SLUB). - Eero
