Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pi locks up after random time with core dump #12

Open
jsb2092 opened this issue Apr 3, 2013 · 2 comments
Open

Pi locks up after random time with core dump #12

jsb2092 opened this issue Apr 3, 2013 · 2 comments
Labels

Comments

@jsb2092
Copy link
Member

jsb2092 commented Apr 3, 2013

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)

@DavidDiPaola
Copy link

Hm. That's the start of memory-mapped I/O...

@caltry
Copy link
Contributor

caltry commented Apr 6, 2013

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants