1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
register: 0.967
user-level: 0.962
peripherals: 0.961
architecture: 0.958
assembly: 0.958
semantic: 0.956
device: 0.953
kernel: 0.950
graphic: 0.948
mistranslation: 0.948
arm: 0.943
permissions: 0.942
debug: 0.937
risc-v: 0.931
boot: 0.930
PID: 0.928
socket: 0.925
vnc: 0.912
virtual: 0.909
x86: 0.906
performance: 0.905
VMM: 0.902
ppc: 0.900
network: 0.891
hypervisor: 0.872
TCG: 0.869
KVM: 0.859
files: 0.837
i386: 0.748
qemu-system-arm crashed with SIGABRT in cpu_abort()
-kernel u-boot.bin
ProblemType: Crash
DistroRelease: Ubuntu 12.10
Package: qemu-system 1.2.0-2012.09-0ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.6.1-0ubuntu1
Architecture: amd64
CrashCounter: 1
Date: Fri Oct 5 19:30:23 2012
ExecutablePath: /usr/bin/qemu-system-arm
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110804)
ProcCmdline: qemu-system-arm -M versatilepb -kernel u-boot.bin
Signal: 6
SourcePackage: qemu-linaro
StacktraceTop:
raise () from /lib/x86_64-linux-gnu/libc.so.6
abort () from /lib/x86_64-linux-gnu/libc.so.6
?? ()
?? ()
?? ()
Title: qemu-system-arm crashed with SIGABRT in raise()
UpgradeStatus: Upgraded to quantal on 2012-08-11 (54 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare vboxusers
StacktraceTop:
cpu_abort (env=env@entry=0x7f7603204b78, fmt=fmt@entry=0x7f7600a056f0 "Trying to execute code outside RAM or ROM at 0x%08x\n") at /build/buildd/qemu-linaro-1.2.0-2012.09/exec.c:1774
get_page_addr_code (env1=0x7f7603204b78, env1@entry=0xffffffffffff4bc2, addr=addr@entry=4294903824) at /build/buildd/qemu-linaro-1.2.0-2012.09/cputlb.c:340
tb_find_slow (flags=<optimized out>, pc=4294903824, env=0xffffffffffff4bc2, cs_base=<optimized out>) at /build/buildd/qemu-linaro-1.2.0-2012.09/cpu-exec.c:96
tb_find_fast (env=0xffffffffffff4bc2) at /build/buildd/qemu-linaro-1.2.0-2012.09/cpu-exec.c:152
cpu_arm_exec (env=0xffffffffffff4bc2, env@entry=0x7f7603204b78) at /build/buildd/qemu-linaro-1.2.0-2012.09/cpu-exec.c:569
Status changed to 'Confirmed' because the bug affects multiple users.
Marked as affecting Ubuntu's qemu package, as bug 1103405 (a dup of this one) happened with the new qemu, not qemu-linaro, package.
qemu-system-arm -M versatilepb -kernel u-boot.bin
[...]
Trying to execute code outside RAM or ROM
This almost always means that you tried to execute a guest binary which wasn't for the VersatilePB. Without more info about exactly what this u-boot.bin file was this bug report can't progress any further.
Marking incomplete pending more information about the origin of u-boot.bin per comment #8.
Also happens on wily when running
$ qemu-system-arm -machine realview-pb-a8
#10: if that's your entire command line then that's expected behaviour, and is saying "we just executed a pile of zeros and fell off the end of RAM". You need to supply a kernel to run.
In the upcoming QEMU 2.7 we've removed the abort() call in this code path, and instead will print an error message which hopefully is clearer at suggesting to users where they've gone wrong rather than implying that this is a QEMU bug:
======
qemu-system-arm: Trying to execute code outside RAM or ROM at 0x08000000
This usually means one of the following happened:
(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere
This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.
Execution cannot continue; stopping here.
======
So I'm going to mark this bug as fix-committed, at least for upstream QEMU.
|