summary refs log tree commit diff stats
path: root/results/scraper/launchpad-without-comments/1671173
diff options
context:
space:
mode:
Diffstat (limited to 'results/scraper/launchpad-without-comments/1671173')
-rw-r--r--results/scraper/launchpad-without-comments/167117333
1 files changed, 33 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1671173 b/results/scraper/launchpad-without-comments/1671173
new file mode 100644
index 00000000..d811843d
--- /dev/null
+++ b/results/scraper/launchpad-without-comments/1671173
@@ -0,0 +1,33 @@
+OS started to crash with a message: "Trying to execute code outside RAM or ROM"
+
+There is a project (https://github.com/narke/colorForth ) wich always worked with qemu up to version 2.5.1.1 but doesn't works from version 2.6 onwards. It continues to work with bochs.
+
+Downlaod: git clone https://github.com/narke/colorForth.git
+Build: make
+Test: qemu-system-i386 -drive format=raw,file=cf2012.img,index=0,if=floppy
+
+
+System information: Ubuntu LTS 16.04 x86-64
+Affected qemu versions: 2.6 to present (2.8)
+
+
+I got the message:
+
+
+WARNING: Image format was not specified for 'cf2012.img' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+         Specify the 'raw' format explicitly to remove the restrictions.
+qemu-system-i386: Trying to execute code outside RAM or ROM at 0x8998c426
+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.
+
+
+Thank you in advance.
\ No newline at end of file