graphic: 0.853 mistranslation: 0.829 device: 0.812 other: 0.784 boot: 0.770 semantic: 0.769 instruction: 0.767 vnc: 0.765 assembly: 0.733 KVM: 0.676 socket: 0.649 network: 0.633 qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974 I try to do a fresh install of NeXTStep 3.3 on qemu. After all install floppies are successfully read in, the installation shall start, but aborts right away. During installation process the SCSI host adapter is correctly detected. I don't know, if these adapter where equipped with some special ROM. I thought of installing NeXTStep on a SCSI system due to the IDE problems already known under #1276879. If necessary I would use gdb to track more into this. System info: Linux prerow 3.11.10-29-desktop #1 SMP PREEMPT Thu Mar 5 16:24:00 UTC 2015 (338c513) x86_64 x86_64 x86_64 GNU/Linux NAME=openSUSE VERSION="13.1 (Bottle)" VERSION_ID="13.1" PRETTY_NAME="openSUSE 13.1 (Bottle) (x86_64)" qemu commandline parameter: /usr/bin/qemu-system-i386 \ -cpu pentium \ -monitor stdio \ -k de \ -vga cirrus \ -m 128 \ -localtime \ -drive \ file=.qemu/floppy/3.3_Boot_Disk.floppyimage,format=raw,if=floppy,index=0 \ -drive \ file=.qemu/disk/scsihd-2G.qcow2,format=qcow2,id=scsihd0,if=none \ -drive \ file=.qemu/cdrom/3.3_InstallCD-NeXTIntel.cdromimage,format=raw,id=scsicd0,if=none \ -net \ none \ -device \ am53c974,id=AMD0 \ -device \ scsi-cd,drive=scsicd0,bus=AMD0.0,lun=0,scsi-id=1,physical_block_size=512,logical_block_size=512 \ -device \ scsi-hd,drive=scsihd0,bus=AMD0.0,lun=0,scsi-id=0,removable=off,secs=125,heads=8,cyls=4176,product="ST32151N ",vendor="Seagate ",serial="89683587",ver="2356",physical_block_size=512,logical_block_size=512,dpofua=off qemu error message: qemu: fatal: Trying to execute code outside RAM or ROM at 0xc01754a8 EAX=000000ff EBX=0000fffb ECX=000000ff EDX=000000a1 ESI=00000009 EDI=00011010 EBP=0000ff84 ESP=0000ff6c EIP=001754a8 EFL=00000007 [-----PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] CS =0008 c0000000 3fffffff 00c39a00 DPL=0 CS32 [-R-] SS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] DS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] FS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] GS =0050 00000000 bfffffff 00cb9300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 001c9a58 000000ff IDT= 001c9bac 000007ff CR0=00000033 CR2=00000000 CR3=00000000 CR4=00000000 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 CCS=00000001 CCD=0000000c CCO=INCL EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? Am 21.06.2018 um 16:37 schrieb Thomas Huth: Dear Thomas, the issue is still reproducible. I'm still eager to run this old beast because of an old database application that has not been converted to our new platform. There is an old NeXTStep Black Hardware that is running the sybase database. The frontend runs under NeXTStep intel. Using qemu would allow to remove some old i486 NeXTStep systems. The error looks like: qemu-system-i386: Trying to execute code outside RAM or ROM at 0xc01754a8 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. Best regards Uwe > Looking through old bug tickets... can you still reproduce this issue > with the latest version of QEMU? Or could we close this ticket nowadays? > > > ** Changed in: qemu > Status: New => Incomplete > On Tue, 26 Jun 2018, Uwe Lienig wrote: > the issue is still reproducible. I'm still eager to run this old beast > because of an old database application that has not been converted to > our new platform. There is an old NeXTStep Black Hardware that is > running the sybase database. The frontend runs under NeXTStep intel. > Using qemu would allow to remove some old i486 NeXTStep systems. This reminds me to this: http://lists.nongnu.org/archive/html/qemu-devel/2012-09/msg00280.html my reply to a patch submitted on list a few years ago that was needed to fix OpenStep (which might be the same for NeXTStep too) but at the end after several iterations it was not accepted due to fear that it may break backwards migration which was deemed more important than supporting old guests at the time. Maybe this could be reconsidered now if it fixes your problem or at least you can have a local fix. The actual patch needed is just this: http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg02360.html from this series: http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg02356.html which is the last version I've found. You can discover the whole story and a lot of background info by searching the qemu-devel list archives for "Microport UNIX". For KVM, I think another set of patches are needed (or one of those patches) that are linked from one of those messages somewhere but I don't remember that. This may not fix your SCSI problems but could be relevant to the other IDE bug mentioned in this bug but it was easier to reply to this email than trying to log into launchpad. Sorry for the noise if this turns out not to be relevant. Regards, BALATON Zoltan This is an automated cleanup. This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets marked as 'expired' now. Please continue with the discussion here: https://gitlab.com/qemu-project/qemu/-/issues/116