diff options
Diffstat (limited to 'results/classifier/108/other/1471904')
| -rw-r--r-- | results/classifier/108/other/1471904 | 176 |
1 files changed, 176 insertions, 0 deletions
diff --git a/results/classifier/108/other/1471904 b/results/classifier/108/other/1471904 new file mode 100644 index 000000000..3b7826a0d --- /dev/null +++ b/results/classifier/108/other/1471904 @@ -0,0 +1,176 @@ +graphic: 0.853 +device: 0.812 +other: 0.784 +debug: 0.782 +performance: 0.775 +boot: 0.770 +semantic: 0.769 +vnc: 0.765 +permissions: 0.718 +PID: 0.699 +files: 0.699 +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 + + |