On 09/12/2023 17:10, Helge Deller wrote:
On 12/9/23 13:49, Helge Deller wrote:
On 12/9/23 13:12, Mark Cave-Ayland wrote:
On 08/12/2023 23:36, Helge Deller wrote:
On 12/8/23 23:09, Helge Deller wrote:
On 12/8/23 22:25, Mark Cave-Ayland wrote:
On 08/12/2023 20:28, Guenter Roeck wrote:
On 12/8/23 11:55, Mark Cave-Ayland wrote:
On 08/12/2023 19:37, Helge Deller wrote:
On 12/8/23 20:26, Helge Deller wrote:
Yeah that's one of the many bugs which should be fixed by my latest
series. I've pushed the current version of my branch with the ESP
rewrite to https://github.com/mcayland/qemu/tree/esp-rework-testing
if you would both like to give it a test.
Tried it with qemu-hppa:
[ 4.257547] am53c974 0000:00:04.0: enabling SERR and PARITY (0107 -> 0147)
[ 4.917824] am53c974 0000:00:04.0: esp0: regs[(ptrval):(ptrval)] irq[70]
[ 4.918704] am53c974 0000:00:04.0: esp0: is a AM53C974, 40 MHz (ccf=0),
SCSI ID 15
[ 8.010626] scsi host1: esp
[ 8.026345] scsi 1:0:0:0: Direct-Access QEMU QEMU HARDDISK
2.5+ PQ: 0 ANSI: 5
[ 8.032066] scsi target1:0:0: Beginning Domain Validation
[ 8.043254] scsi target1:0:0: Domain Validation skipping write tests
[ 8.044284] scsi target1:0:0: Ending Domain Validation
[ 8.123681] sd 1:0:0:0: Power-on or device reset occurred
[ 8.134707] sd 1:0:0:0: [sda] 209715200 512-byte logical blocks: (107
GB/100 GiB)
[ 8.140043] sd 1:0:0:0: [sda] Write Protect is off
[ 8.144759] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 8.205316] sda: sda1 sda2 sda3 < sda5 sda6 >
[ 8.222763] sd 1:0:0:0: [sda] Attached SCSI disk
[ 8.231170] sd 1:0:0:0: Attached scsi generic sg0 type 0
...> [ 8.679666] Freeing unused kernel image (initmem) memory: 3072K
[ 8.680679] Write protected read-only-after-init data: 2k
[ 8.681338] Run /sbin/init as init process
[ 8.731576] EXT4-fs error (device sda5): ext4_lookup:1855: inode
#787975: comm swapper/0: iget: checksum invalid
[ 8.736664] scsi host1: Spurious irq, sreg=10.
[ 8.760106] Starting init: /sbin/init exists but couldn't execute it
(error -67)
The driver isn't so bad in general.
With my current seabios-hppa from
https://github.com/hdeller/seabios-hppa/tree/devel
and booting like this:
./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0
-serial mon:stdio -smp cpus=3 -machine C3700 -nographic -snapshot -device
dc390,id=scsi -device scsi-hd,bus=scsi.0,drive=d0 -bios
../seabios-hppa/out/hppa-firmware.img
it actually can *partly* boot from disc:
...
Selected kernel: /vmlinux from partition 2
Selected ramdisk: /initrd.img from partition 2
ELF64 executable
Segment 0 load 0x000e0000 size 5171564 mediaptr 0x1000
Segment 1 load 0x01a00000 size 25012 mediaptr 0x4f0000
Loading ramdisk 23869192 bytes @ 3e92a000...
Decompressing Linux... XZ-compressed data is corrupt
-- System halted
So, it can read partition table, even load some sectors, but
the data returned can be corrupt, as the "XZ-compressed data is corrupt"
message states.
This fits with the CRC checksum errors I saw when booting
from ext4 disc.
Is the dc390/esp driver functional on other big-endian machines?
Yes it is, in fact the majority of my test images were from SPARC/m68k
(including a hppa image) and the series in its current form passes all my
boot tests except for an x86 DOS image with ASPI.
The command line I used for testing hppa is below:
./qemu-system-hppa \
-kernel vmlinux-parisc \
-no-reboot \
-snapshot \
-device am53c974,id=scsi \
-device scsi-hd,bus=scsi.0,drive=d0 \
-drive file=rootfs.ext2-parisc,format=raw,if=none,id=d0 \
-append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0,115200" \
-nographic -monitor null
If you are still seeing errors then I'd suspect an issue with the hppa CPU
emulation or the esp-pci device.
I suspect it has more to do with ext4 vs. ext2 because ext2 works just fine
for me
while I get unaligned access crashes with ext4. I started some tests with btrfs
and f2fs in addition to ext2 to see how those are doing.
That sounds really useful, thanks for testing.
I think there are multiple issues.
Most likely some CPU emulation bug, maybe happens in CRC checksumming.
Nevertheless, with this command:
./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -serial
mon:stdio -smp cpus=3 -machine C3700 -nographic -snapshot -device
am53c974,id=scsi -device scsi-hd,bus=scsi.0,drive=d0 -bios
../seabios-hppa/out/hppa-firmware.img
I get this error:
Decompressing Linux... XZ-compressed data is corrupt
Replacing the scsi driver "am53c974" by "lsi53c895a" does boot.
At this stage no linux kernel is loaded yet, it's just the seabios-hppa
which loaded some scsi blocks into memory.
Does the esp driver has a limit of only being able to
load max. 64kb at once (per SCSI command) ?
By reducing to 64kb, booting directly from Seabios-hppa
now works for me.
From a QEMU perspective it should support a maximum 24-bit transfer size.
I fixed it now in my Seabio-hppa devel branch.
Booting from firmware now works (with your branch), but kernel
still shows crc errors, which is probably a cpu emulation bug.
Still analyzing.
If I limit the disc transfer size of am53c974 to just 4K per transaction
(like the patch below against Linux kernel 6.6.4), then qemu-hppa
boots up nicely with qemu git head (and Günther's patches applied).
Nice detective work :)
If you're using the esp-rework-testing branch then the only patch you should need is
the patch to esp-pci.c: otherwise if you also apply Günther's esp.c patch then you
break the reset of the ESP_RSTAT flags when reading ESP_RINTR. Can you confirm that
this is the case in your tests?
No ext4 crc errors in this case.
Mark, your git tree then still gives IRQ issues and other problems.
Presumably this is just the "Spurious irq, sreg=%02x." errors, or are you seeing
something else?
I wonder if this isn't a qemu issue....
diff --git a/drivers/scsi/am53c974.c b/drivers/scsi/am53c974.c
index fbb29dbb1e50..f2066544da5e 100644
--- a/drivers/scsi/am53c974.c
+++ b/drivers/scsi/am53c974.c
@@ -251,6 +251,7 @@ static u32 pci_esp_dma_length_limit(struct esp *esp, u32
dma_addr, u32 dma_len)
*/
if (esp->config2 & ESP_CONFIG2_FENAB)
dma_limit = 24;
+dma_limit = 12; // 4096 bytes
if (dma_len > (1U << dma_limit))
dma_len = (1U << dma_limit);
ATB,
Mark.
