3 files changed, 113 insertions, 0 deletions
diff --git a/results/classifier/108/other/1252 b/results/classifier/108/other/1252
new file mode 100644
index 000000000..ac860412f
--- /dev/null
+++ b/results/classifier/108/other/1252
@@ -0,0 +1,32 @@
+graphic: 0.901
+device: 0.822
+PID: 0.792
+files: 0.780
+performance: 0.775
+socket: 0.742
+network: 0.742
+semantic: 0.723
+debug: 0.628
+permissions: 0.582
+vnc: 0.539
+boot: 0.537
+other: 0.528
+KVM: 0.375
+
+Debian Raspberry Pi images do not boot with version 7 and higher
+Description of problem:
+The Debian Bullseye RPi4 4GB image [here](https://raspi.debian.net/tested-images/) does not boot with versions 7 and higher, while it does boot with v6.2.0.  The Bookworm image works with v7.
+Steps to reproduce:
+0. `export DEB_VERS=5.10.0-11`
+1. `wget https://raspi.debian.net/tested/20220121_raspi_4_bullseye.img.xz`
+2. `dd if=/dev/null of=disk-$DEB_VERS.img bs=1M seek=10240`
+    * NB: This creates a 10 GB file 
+3. `xzcat $RPI_IMG | dd of=disk-$DEB_VERS.img conv=notrunc status=progress`
+4. `partx -a -v disk-$DEB_VERS.img`
+5. `mount /dev/loop0p1 /mnt`
+6. `cp /mnt/initrd.img-$DEB_VERS-arm64 .`
+7. `cp /mnt/vmlinuz-$DEB_VERS-arm64 .`
+8. `umount /mnt`
+9. `qemu-system-aarch64 -M virt -m 4096 -cpu max -drive format=raw,file=disk-$DEB_VERS.img -nographic -append "console=tty0 console=ttyAMA0,115200 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=64M rootwait" -initrd initrd.img-$DEB_VERS-arm64 -kernel vmlinuz-$DEB_VERS-arm64`
+Additional information:
+The URL for the image in step 1 has been known to change, so if you get a 404, go to the URL above and find the correct one.
diff --git a/results/classifier/108/other/1252010 b/results/classifier/108/other/1252010
new file mode 100644
index 000000000..346051151
--- /dev/null
+++ b/results/classifier/108/other/1252010
@@ -0,0 +1,31 @@
+device: 0.891
+graphic: 0.828
+boot: 0.754
+PID: 0.694
+performance: 0.632
+vnc: 0.624
+semantic: 0.595
+socket: 0.358
+permissions: 0.352
+debug: 0.327
+other: 0.289
+network: 0.258
+KVM: 0.238
+files: 0.167
+
+can't assign enough RAM to the VM
+
+QEMU version: 1.6.90.0 from 2013 11 16
+Host OS: Windows XP SP3 x86
+Host machine: 3.2 GHz AMD Athlon 64 dual core processor, 4 GB DDR II (3.2 seen by the OS) memory
+Guest OS: Grub4Dos boot manager menu
+Problem: you can't assign more than 880 MB memory to the VM, although with 0.15.1.0 version you can assign up to 1179 MB.
+
+QEMU currently needs contiguous memory for the guest memory. Hosts running 32 bit Windows only provide about 2 GiB for programs. This 2 GiB is used for the executable, all loaded dlls and dynamic memory. Especially the dlls cause memory fragmentation, so newer versions of QEMU which need more dlls get less contiguous memory.
+
+Running 32 bit QEMU on 64 bit Windows helps, and 64 bit QEMU also has no problem with allocating a large guest RAM.
+
+Could we close this bug now - I think most people are using 64-bit host systems nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1252270 b/results/classifier/108/other/1252270
new file mode 100644
index 000000000..566fa4a21
--- /dev/null
+++ b/results/classifier/108/other/1252270
@@ -0,0 +1,50 @@
+graphic: 0.714
+PID: 0.640
+device: 0.596
+semantic: 0.577
+network: 0.560
+other: 0.537
+socket: 0.518
+debug: 0.512
+performance: 0.496
+vnc: 0.451
+permissions: 0.434
+files: 0.403
+boot: 0.318
+KVM: 0.107
+
+installing NT4 on MIPS Magnum/Jazz asserts
+
+While installing NT4 on MIPS Magnum (Jazz), when the NT Installer tries to format the harddisk, QEmu 1.6.1 crashes with an assertion:
+
+qemu-system-mips64el: g364: invalid read at [0000000000102000]
+qemu-system-mips64el: hw/scsi/scsi-bus.c:1577: scsi_req_data: Assertion `req->cmd.mode != SCSI_XFER_NONE' failed.
+./nt4mips.sh: line 3: 20336 Aborted                 (core dumped) ./qemu-system-mips64el --machine magnum -m 64 -net nic -net user -hda nt4.dsk -cdrom NTWKS40D.ISO -global ds1225y.filename=nvram.bin -global ds1225y.size=16384
+
+This assertion also occurred with the stock Ubuntu version of QEmu (1.5.0 (Debian 1.5.0+dfsg-3ubuntu5)) which I tried before.
+
+Note that to even get this far, you need the patch mentioned in BUG1245924, otherwise QEmu 1.6.1 won't even start/boot at all
+
+NT4 installation guide I'm following:
+http://gunkies.org/wiki/Installing_Windows_NT_4.0_on_Qemu(MIPS)
+http://virtuallyfun.superglobalmegacorp.com/?p=2255
+
+As a side note, that "invalid read at..." warning is unrelated, as it happens right on startup
+
+This bug is still present in qemu 1.7.0:
+
+qemu-system-mips64el: g364: invalid read at [0000000000102000]
+qemu-system-mips64el: hw/scsi/scsi-bus.c:1578: scsi_req_data: Assertion `req->cmd.mode != SCSI_XFER_NONE' failed.
+./nt4mips.sh: line 3: 26409 Aborted                 (core dumped) ./qemu-system-mips64el --machine magnum -m 64 -net nic -net user -hda nt4.dsk -cdrom NTWKS40D.ISO -global ds1225y.filename=nvram.bin -global ds1225y.size=16384
+
+
+We're about to release 2.0, so it would be more interesting to know whether it still happens in latest qemu.git.
+
+And since this seems to depend on .iso and nvram.bin files that we don't have available for reproducing, some tracing on your part might help narrow down whether this is caused by a bug in MIPS-specific or generic SCSI code and what exactly it's been trying to do at the point of assertion. Running it in gdb to get a backtrace on SIGABRT would be a start. --enable-trace-backend= and -trace would be further options to investigate.
+
+Indeed the crash doesn't happen in current git anymore. Setup still doesn't copy anything off the CD (hangs on the first file) but at least the crash is fixed and formatting the harddisk works now.
+
+I'll investigate the other issue and maybe open up a new bug for that.
+
+This bug here can be closed. Thank you!
+