summary refs log tree commit diff stats
path: root/results/classifier/118/none/1921
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/118/none/192160
-rw-r--r--results/classifier/118/none/192108279
-rw-r--r--results/classifier/118/none/1921444145
-rw-r--r--results/classifier/118/none/1921635189
4 files changed, 473 insertions, 0 deletions
diff --git a/results/classifier/118/none/1921 b/results/classifier/118/none/1921
new file mode 100644
index 00000000..c90a86a5
--- /dev/null
+++ b/results/classifier/118/none/1921
@@ -0,0 +1,60 @@
+graphic: 0.700
+debug: 0.691
+boot: 0.671
+permissions: 0.668
+performance: 0.653
+peripherals: 0.631
+architecture: 0.613
+register: 0.604
+TCG: 0.597
+risc-v: 0.593
+PID: 0.578
+semantic: 0.572
+files: 0.561
+user-level: 0.561
+KVM: 0.543
+ppc: 0.534
+assembly: 0.527
+vnc: 0.526
+hypervisor: 0.517
+device: 0.502
+socket: 0.486
+VMM: 0.484
+network: 0.478
+arm: 0.464
+x86: 0.461
+virtual: 0.458
+mistranslation: 0.452
+kernel: 0.416
+i386: 0.332
+
+qemu-system-x86_64 segfaults in iotlb_to_section() on riscv64
+Description of problem:
+QEMU segfaults when booting up the Arch Linux x86_64 installation ISO. The ISO could be downloaded from https://geo.mirror.pkgbuild.com/iso/2023.09.01/archlinux-2023.09.01-x86_64.iso or any other Arch Linux mirrors.
+
+The crash often happens after "Probing EDD...". It's more reliably reproducible with higher `-smp` numbers, and may hang with "rcu_preempt detected stalls" without the -smp option.
+Additional information:
+I have reproduced the same issues with different RISC-V hardware, including SG2042 and TH1520.
+
+Errors:
+```
+qemu-system-x86_64: ../qemu-8.1.1/softmmu/physmem.c:2419: iotlb_to_section: Assertion `section_index < d->map.sections_nb' failed.
+```
+
+Backtrace:
+```
+#0  0x0000003fa74f0ece in __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
+#1  0x0000003fa74f0f0e in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
+#2  0x0000003fa74ba912 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
+#3  0x0000003fa74aa164 in __GI_abort () at abort.c:79
+#4  0x0000003fa74b54a4 in __assert_fail_base
+    (fmt=0x3fa7594c10 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x2ae1de0458 "section_index < d->map.sections_nb", file=file@entry=0x2ae1ddf980 "../qemu-8.1.1/softmmu/physmem.c", line=line@entry=2419, function=function@entry=0x2ae1f05f20 <__PRETTY_FUNCTION__.11> "iotlb_to_section") at assert.c:92
+#5  0x0000003fa74b54f8 in __assert_fail (assertion=0x2ae1de0458 "section_index < d->map.sections_nb", file=0x2ae1ddf980 "../qemu-8.1.1/softmmu/physmem.c", line=2419, function=0x2ae1f05f20 <__PRETTY_FUNCTION__.11> "iotlb_to_section") at assert.c:101
+#6  0x0000002ae1b69788 in iotlb_to_section () at ../qemu-8.1.1/softmmu/physmem.c:2419
+#7  0x0000002ae1b9d774 in io_writex () at ../qemu-8.1.1/accel/tcg/cputlb.c:1432
+#8  0x0000002ae1b9d924 in do_st_mmio_leN () at ../qemu-8.1.1/accel/tcg/cputlb.c:2755
+#9  0x0000002ae1ba127c in do_st_4 () at ../qemu-8.1.1/accel/tcg/cputlb.c:2921
+#10 do_st4_mmu () at ../qemu-8.1.1/accel/tcg/cputlb.c:3006
+#11 0x0000003f600dd7ec in code_gen_buffer ()
+#12 0x5f085e2755518600 in  ()
+```
diff --git a/results/classifier/118/none/1921082 b/results/classifier/118/none/1921082
new file mode 100644
index 00000000..2f1acdc9
--- /dev/null
+++ b/results/classifier/118/none/1921082
@@ -0,0 +1,79 @@
+hypervisor: 0.701
+performance: 0.689
+virtual: 0.681
+x86: 0.636
+architecture: 0.635
+device: 0.629
+register: 0.628
+semantic: 0.573
+KVM: 0.572
+user-level: 0.568
+risc-v: 0.566
+ppc: 0.551
+VMM: 0.536
+kernel: 0.525
+vnc: 0.521
+i386: 0.514
+network: 0.484
+files: 0.468
+peripherals: 0.467
+permissions: 0.455
+assembly: 0.446
+debug: 0.442
+arm: 0.434
+PID: 0.427
+graphic: 0.420
+socket: 0.378
+TCG: 0.362
+boot: 0.359
+mistranslation: 0.332
+
+VM crash when process broadcast MCE
+
+When i do memory SRAR test for VM, I meet the following issue:
+
+My VM has 16 vCPU, I will inject one UE error to memory which is accessed by VM, Then host MCE is raised and SIGBUS is send to VM, and qemu take control.
+Qemu will check the broadcast attribute by following  cpu_x86_support_mca_broadcast();  
+
+Then Qemu may inject MCE to all vCPU, as vCPU is just one process for HOST, we can't guarantee all the vCPUs will enter MCE hander in 1S sync time, and the VM may panic.
+
+This issue will be easily fixed by expand monarch_timeout configuration, but the exact monarch_timeout can't be easily got, as it will depand on the num of vCPUs and current system schedule status.
+
+I am wondering why VM need broadcast attribute for MCE, When qeme process MCE event form host, it will always be signaled for one vCPU? If so, why does qemu need boradcast the MCE event to all vCPUs?
+
+Can weu just deliver LMCE to one specifc vCPU and make this behavior default?
+
+If anything wrong, Please point out.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/none/1921444 b/results/classifier/118/none/1921444
new file mode 100644
index 00000000..5e4c4cb5
--- /dev/null
+++ b/results/classifier/118/none/1921444
@@ -0,0 +1,145 @@
+mistranslation: 0.797
+semantic: 0.672
+user-level: 0.665
+ppc: 0.641
+risc-v: 0.606
+x86: 0.601
+peripherals: 0.555
+TCG: 0.532
+debug: 0.515
+PID: 0.499
+graphic: 0.499
+KVM: 0.488
+virtual: 0.487
+VMM: 0.473
+vnc: 0.436
+arm: 0.412
+hypervisor: 0.408
+register: 0.405
+permissions: 0.384
+assembly: 0.366
+network: 0.358
+device: 0.324
+i386: 0.306
+performance: 0.306
+kernel: 0.258
+architecture: 0.231
+boot: 0.183
+socket: 0.162
+files: 0.116
+
+Q35 doesn't support to hot add the 2nd PCIe device to KVM guest
+
+KVM: https://git.kernel.org/pub/scm/virt/kvm/kvm.git  branch: next, commit: 4a98623d
+Qemu: https://git.qemu.org/git/qemu.git  branch: master, commit: 9e2e9fe3
+
+Created a KVM guest with Q35 chipset, and try to hot add 2 PCIe device to guest with qemu internal command device_add, the 1st device can be added successfully, but the 2nd device failed to hot add.
+
+If guest chipset is legacy i440fx, the 2 device can be added successfully.
+
+1. Enable VT-d in BIOS
+2. load KVM modules in Linux OS: modprobe kvm; modprobe kvm_intel
+3. Bind 2 device to vfio-pci
+    echo 0000:b1:00.0 > /sys/bus/pci/drivers/i40e/unbind
+    echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id 
+    echo 0000:b1:00.1 > /sys/bus/pci/drivers/i40e/unbind
+    echo "8086 1572" > /sys/bus/pci/drivers/vfio-pci/new_id 
+
+4. create guest with Q35 chipset:
+qemu-system-x86_64 --accel kvm -m 4096 -smp 4 -drive file=/home/rhel8.2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -cpu host -machine q35 -device pcie-root-port,id=root1 -daemonize
+
+5. hot add the 1st device to guest successfully
+in guest qemu monitor "device_add vfio-pci,host=b1:00.0,id=nic0,bus=root1"
+6. hot add the 2nd device to guest
+in guest qemu monitor "device_add vfio-pci,host=b1:00.1,id=nic1,bus=root1"
+The 2nd device doesn't be added in guest, and the 1st device is removed from guest. 
+
+Guest partial log:
+[  110.452272] pcieport 0000:00:04.0: pciehp: Slot(0): Attention button pressed
+[  110.453314] pcieport 0000:00:04.0: pciehp: Slot(0) Powering on due to button press
+[  110.454156] pcieport 0000:00:04.0: pciehp: Slot(0): Card present
+[  110.454792] pcieport 0000:00:04.0: pciehp: Slot(0): Link Up
+[  110.580927] pci 0000:01:00.0: [8086:1572] type 00 class 0x020000
+[  110.582560] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x007fffff 64bit pref]
+[  110.583453] pci 0000:01:00.0: reg 0x1c: [mem 0x00000000-0x00007fff 64bit pref]
+[  110.584278] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref]
+[  110.585051] pci 0000:01:00.0: Max Payload Size set to 128 (was 512, max 2048)
+[  110.586621] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
+[  110.588140] pci 0000:01:00.0: BAR 0: no space for [mem size 0x00800000 64bit pref]
+[  110.588954] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00800000 64bit pref]
+[  110.589797] pci 0000:01:00.0: BAR 6: assigned [mem 0xfe800000-0xfe87ffff pref]
+[  110.590703] pci 0000:01:00.0: BAR 3: assigned [mem 0xfe000000-0xfe007fff 64bit pref]
+[  110.592085] pcieport 0000:00:04.0: PCI bridge to [bus 01]
+[  110.592755] pcieport 0000:00:04.0:   bridge window [io  0x1000-0x1fff]
+[  110.594403] pcieport 0000:00:04.0:   bridge window [mem 0xfe800000-0xfe9fffff]
+[  110.595847] pcieport 0000:00:04.0:   bridge window [mem 0xfe000000-0xfe1fffff 64bit pref]
+[  110.597867] PCI: No. 2 try to assign unassigned res
+[  110.597870] release child resource [mem 0xfe000000-0xfe007fff 64bit pref]
+[  110.597871] pcieport 0000:00:04.0: resource 15 [mem 0xfe000000-0xfe1fffff 64bit pref] released
+[  110.598881] pcieport 0000:00:04.0: PCI bridge to [bus 01]
+[  110.600789] pcieport 0000:00:04.0: BAR 15: assigned [mem 0x180000000-0x180bfffff 64bit pref]
+[  110.601731] pci 0000:01:00.0: BAR 0: assigned [mem 0x180000000-0x1807fffff 64bit pref]
+[  110.602849] pci 0000:01:00.0: BAR 3: assigned [mem 0x180800000-0x180807fff 64bit pref]
+[  110.604069] pcieport 0000:00:04.0: PCI bridge to [bus 01]
+[  110.604941] pcieport 0000:00:04.0:   bridge window [io  0x1000-0x1fff]
+[  110.606237] pcieport 0000:00:04.0:   bridge window [mem 0xfe800000-0xfe9fffff]
+[  110.607401] pcieport 0000:00:04.0:   bridge window [mem 0x180000000-0x180bfffff 64bit pref]
+[  110.653661] i40e: Intel(R) Ethernet Connection XL710 Network Driver
+[  110.654443] i40e: Copyright (c) 2013 - 2019 Intel Corporation.
+[  110.655314] i40e 0000:01:00.0: enabling device (0140 -> 0142)
+[  110.672396] i40e 0000:01:00.0: fw 6.0.48442 api 1.7 nvm 6.01 0x800035b1 1.1747.0 [8086:1572] [8086:0008]
+[  110.750054] i40e 0000:01:00.0: MAC address: 3c:fd:fe:c0:59:98
+[  110.751792] i40e 0000:01:00.0: FW LLDP is enabled
+[  110.764644] i40e 0000:01:00.0 eth1: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: None
+[  110.779390] i40e 0000:01:00.0: PCI-Express: Speed 8.0GT/s Width x8
+[  110.789841] i40e 0000:01:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 4 RSS FD_ATR FD_SB NTUPLE DCB VxLAN Geneve PTP VEPA
+[  111.817553] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
+[  205.130288] pcieport 0000:00:04.0: pciehp: Slot(0): Attention button pressed
+[  205.131743] pcieport 0000:00:04.0: pciehp: Slot(0): Powering off due to button press
+[  205.133233] pcieport 0000:00:04.0: pciehp: Slot(0): Card not present
+[  205.135728] i40e 0000:01:00.0: i40e_ptp_stop: removed PHC on eth1
+
+
+
+You need a root port per device you want to hotplug, you cannot independently hotplug multiple devices to a PCIe link.
+
+Alex, thanks for you response.
+
+I tried to create guest with multiple root ports, but qemu report error:
+# qemu-system-x86_64 --accel kvm -m 4096 -smp 4 -drive file=/home/hao/rhel8.2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 -device virtio-net-pci,netdev=nic0,mac=00:16:3e:0d:e4:ab -netdev tap,id=nic0,br=virbr0,helper=/usr/local/libexec/qemu-bridge-helper -cpu host -machine q35 -device pcie-root-port,id=root1 -device pcie-root-port,id=root2 -daemonize
+qemu-system-x86_64: -device pcie-root-port,id=root2: Can't add chassis slot, error -16
+
+Is the command wrong?
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/none/1921635 b/results/classifier/118/none/1921635
new file mode 100644
index 00000000..0f2511e5
--- /dev/null
+++ b/results/classifier/118/none/1921635
@@ -0,0 +1,189 @@
+KVM: 0.536
+hypervisor: 0.517
+TCG: 0.477
+peripherals: 0.470
+ppc: 0.468
+VMM: 0.465
+x86: 0.462
+i386: 0.460
+vnc: 0.433
+risc-v: 0.422
+virtual: 0.389
+user-level: 0.385
+mistranslation: 0.363
+debug: 0.360
+register: 0.358
+files: 0.345
+performance: 0.344
+graphic: 0.337
+device: 0.335
+architecture: 0.330
+kernel: 0.327
+semantic: 0.323
+PID: 0.321
+boot: 0.320
+arm: 0.320
+permissions: 0.319
+assembly: 0.314
+network: 0.306
+socket: 0.299
+
+ESP SCSI adapter not working with DOS ASPI drivers
+
+I have been trying to install the DOS ASPI drivers for the ESP scsi card. Both in am53c974 and dc390 modes. Neither works but they don't work in different ways.
+
+The following things appear to be problematic:
+
+* The am53c974 should work with the PcSCSI drivers (AMSIDA.SYS) but the ASPI driver never manages to get past initializing the card. The VM never continues.
+* The dc390 ASPI driver fares a little better. The ASPI driver loads and is semi-functional but the drivers for the peripherals don't work.
+ - ASPI.SYS (creative name) loads
+ - TRMDISK.SYS fails to load when a cd-drive is attached and will crashs scanning the scsi-id where the cd drive is attached
+ - TRMDISK.SYS loads without a CD drive attached but fails to read any scsi-hd devices attached. The TFDISK.EXE formatter crashes.
+ - TRMCD.SYS loads, but can not detect any CD drives.
+
+The various permutations:
+am53c974 hang on ASPI driver load: (CD only attached)
+
+~/src/qemu/build/qemu-system-i386 -m 64 -device am53c974,id=scsi0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda am53c974_aspi.img -bios /home/hp/src/seabios/out/bios.bin -boot a  -trace 'scsi*' -trace 'esp*' -D log
+
+dc390 crash because of CDROM attachment and loading TRMDISK.SYS (Only CD attached)
+~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_all.img  -bios /home/hp/src/seabios/out/bios.bin -boot a  -trace 'scsi*' -trace 'esp*' -D log
+
+dc390 successful boot, but TRMDISK.SYS not working (TFDISK.EXE will crash)
+~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0 -device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0,logical_block_size=512 -drive file=small.qcow2,if=none,id=drive0 -vga cirrus -fda dc390_all.img -bios /home/hp/src/seabios/out/bios.bin -boot a  -trace 'scsi*' -trace 'esp*' -D log
+
+dc390 successful boot, TRMDISK.SYS not loaded, only TRMCD.SYS. CDROM not detected
+~/src/qemu/build/qemu-system-i386 -m 64 -device dc390,id=scsi0,rombar=0 -device scsi-cd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0 -drive file=../Windows\ 98\ Second\ Edition.iso,if=none,id=drive0 -vga cirrus -fda dc390_cd.img  -bios /home/hp/src/seabios/out/bios.bin -boot a  -trace 'scsi*' -trace 'esp*' -D log
+
+All of these tests were done on 7b9a3c9f94bcac23c534bc9f42a9e914b433b299 as well as the 'esp-next' branch found here: https://github.com/mcayland/qemu/tree/esp-next
+
+The bios file is a seabios master with all int13 support disabled. With it enabled even less works but I figured this would be a seabios bug and not a qemu one.
+
+The actual iso and qcow2 files used don't appear the matter. the 'small.qcow2' is an empty drive of 100MB. I have also tried other ISOs in the CD drives, or even not put any cd in the drives with the same results.
+
+I will attach all of the above images.
+
+
+
+
+
+
+
+
+
+
+
+Something maybe worth noting is that the DC390 driver detectes attached CDROM drives as 'Fixed Disks' which seems a little fishy. The same appears to happen with the lsilogic card (that is cdrom drives get detected as hard drives and causes a failure to load the drivers)
+
+I've had a look at your am53c974 boot floppy with PcSCSI drivers and I'm fairly sure that disabling INT13 support isn't helping here. With your custom SeaBIOS I see a hang issuing the first SCSI command: without your custom SeaBIOS I can see that the default SeaBIOS issues several successful commands to the SCSI bus before booting from the floppy.
+
+Dropping the -bios option and booting your floppy here I see the following sequence with -trace 'scsi*' -trace 'esp*' after the BIOS has initialised:
+
+
+esp_mem_writeb reg[3]: 0x42 -> 0x02
+esp_mem_writeb_cmd_reset Chip reset (0x02)
+esp_mem_writeb reg[3]: 0x02 -> 0x80
+esp_mem_writeb_cmd_nop NOP (0x80)
+esp_mem_writeb reg[11]: 0x00 -> 0x40
+esp_mem_readb reg[14]: 0x12
+esp_pci_sbac_read sbac: 0x00000000
+esp_pci_sbac_write sbac: 0x00000000 -> 0x02000000
+esp_mem_writeb reg[3]: 0x80 -> 0x02
+esp_mem_writeb_cmd_reset Chip reset (0x02)
+esp_mem_writeb reg[3]: 0x02 -> 0x80
+esp_mem_writeb_cmd_nop NOP (0x80)
+esp_mem_writeb reg[8]: 0x00 -> 0x17
+esp_mem_writeb reg[12]: 0x00 -> 0x88
+esp_mem_writeb reg[13]: 0x00 -> 0x40
+esp_mem_writeb reg[11]: 0x00 -> 0x40
+esp_mem_writeb reg[9]: 0x00 -> 0x07
+esp_mem_writeb reg[5]: 0x00 -> 0x8d
+esp_mem_writeb reg[5]: 0x8d -> 0x02
+esp_mem_readb reg[8]: 0x17
+esp_mem_writeb reg[8]: 0x17 -> 0x07
+esp_mem_writeb reg[4]: 0x00 -> 0x00
+esp_mem_writeb reg[3]: 0x80 -> 0x01
+esp_mem_writeb_cmd_flush Flush FIFO (0x01)
+esp_mem_writeb reg[2]: 0x00 -> 0x00
+esp_mem_writeb reg[2]: 0x00 -> 0x00
+esp_mem_writeb reg[2]: 0x00 -> 0x00
+esp_mem_writeb reg[2]: 0x00 -> 0x00
+esp_mem_writeb reg[2]: 0x00 -> 0x00
+esp_mem_writeb reg[2]: 0x00 -> 0x00
+esp_mem_writeb reg[3]: 0x01 -> 0x41
+esp_mem_writeb_cmd_sel Select without ATN (0x41)
+esp_get_cmd len 6 target 0
+esp_do_busid_cmd busid 0x0
+scsi_req_parsed target 0 lun 0 tag 0 command 0 dir 0 length 0
+scsi_req_parsed_lba target 0 lun 0 tag 0 command 0 lba 0
+scsi_req_alloc target 0 lun 0 tag 0
+scsi_disk_new_request Command: lun=0 tag=0x0 data= 0x00 0x00 0x00 0x00 0x00 0x00
+scsi_test_unit_ready target 0 lun 0 tag 0
+scsi_req_dequeue target 0 lun 0 tag 0
+esp_command_complete SCSI Command complete
+esp_raise_irq Raise IRQ
+esp_lower_drq Lower DREQ
+
+******
+esp_pci_dma_read reg[5]: 0x00000018
+esp_mem_readb reg[4]: 0x93
+esp_mem_readb reg[6]: 0x00
+esp_lower_irq Lower IRQ
+esp_mem_readb reg[5]: 0x18
+esp_mem_readb reg[8]: 0x07
+esp_mem_writeb reg[8]: 0x07 -> 0x47
+esp_mem_writeb reg[3]: 0x41 -> 0x03
+esp_mem_writeb_cmd_bus_reset Bus reset (0x03)
+******
+
+
+The loading of the "test unit ready" command and execution look fine to me: QEMU's SCSI layer is executing the command (indicating success) and raises the ESP IRQ. However at this point in the section marked by "******" the ASPI driver seems not be happy with the RSTAT/RINTR register contents or the 0x18 read back from the PCI DMA registers, issues a bus reset and stops.
+
+What is interesting here is that the "Select without ATN (0x41)" command issued is a non-DMA command so I wouldn't expect it to affect the ESP PCI DMA register state, but I suspect you'll need to have a look what the driver is doing using a disassembler/gdbstub and the am53c974 datasheet to try and understand what is happening here.
+
+Finally it may be worth checking the IRQ routing with -trace 'pci*' to see if SeaBIOS updates the PCI "Interrupt Pin" register indicating where it thinks the IRQ should be routed, and stepping through the esp_raise_irq() in QEMU for the final test unit ready command to ensure that all of QEMU, SeaBIOS and AMSIDA.SYS all agree on what IRQ is being used.
+
+I'm looking at this document: http://bitsavers.trailing-edge.com/components/amd/_dataSheets/1993_53c974_PCscsi.pdf 
+
+But I can't find this RSTAT/RINTR register in it. Am I looking at the wrong document, or is there a name mapping to the official names that I'm missing?
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+
+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/569
+
+