diff options
Diffstat (limited to 'results/classifier/118/none/1921635')
| -rw-r--r-- | results/classifier/118/none/1921635 | 189 |
1 files changed, 189 insertions, 0 deletions
diff --git a/results/classifier/118/none/1921635 b/results/classifier/118/none/1921635 new file mode 100644 index 000000000..0f2511e51 --- /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 + + |