Open jsb2092 opened 11 years ago
Hm. That's the start of memory-mapped I/O...
Are the registers always the same value when this crash happens? You say the time is random, do you have an average? Is it 10 minutes or 10 hours?
I'm most interested to find out if r6, r13 (these three look like stack addresses), r14 and r15 are the same for every crash. Since r14 (link register) and r15 (program counter) are garbage, It'll be tough to find out what function was being run. Perhaps you could attach gdb (before qemu crashes) and do some poking around the stack (where r14 points) to see if you can find anything that looks like a code address (0x00010000 to 0x0001EB27s).
The Raspberry Pi locks up after a random time after the UART fix. This issue occurs more frequently when less memory is allocated to the Pi. This occurs in the emulator and the Pi.
In the emulator, qemu catches the following: emu: fatal: Trying to execute code outside RAM or ROM at 0x20000000
R00=00000000 R01=00000000 R02=000108d0 R03=00000002 R04=02000000 R05=00000080 R06=07fefc64 R07=00000080 R08=00000002 R09=02000000 R10=00000080 R11=02000000 R12=000130b0 R13=07fefc6c R14=00000002 R15=20000000 PSR=2000015f --C- A sys32 s00=00000000 s01=00000000 d00=0000000000000000 s02=00000000 s03=00000000 d01=0000000000000000 s04=00000000 s05=00000000 d02=0000000000000000 s06=00000000 s07=00000000 d03=0000000000000000 s08=00000000 s09=00000000 d04=0000000000000000 s10=00000000 s11=00000000 d05=0000000000000000 s12=00000000 s13=00000000 d06=0000000000000000 s14=00000000 s15=00000000 d07=0000000000000000 s16=00000000 s17=00000000 d08=0000000000000000 s18=00000000 s19=00000000 d09=0000000000000000 s20=00000000 s21=00000000 d10=0000000000000000 s22=00000000 s23=00000000 d11=0000000000000000 s24=00000000 s25=00000000 d12=0000000000000000 s26=00000000 s27=00000000 d13=0000000000000000 s28=00000000 s29=00000000 d14=0000000000000000 s30=00000000 s31=00000000 d15=0000000000000000 FPSCR: 00000000 Aborted (core dumped)