On 10/12/2023 21:42, Helge Deller wrote:
On 12/10/23 22:15, Mark Cave-Ayland wrote:
On 10/12/2023 15:47, Helge Deller wrote:
On 12/10/23 01:22, Mark Cave-Ayland wrote:
On 09/12/2023 23:43, Helge Deller wrote:
On 12/9/23 23:57, Guenter Roeck wrote:
On 12/9/23 13:58, Helge Deller wrote:
On 12/9/23 19:56, Mark Cave-Ayland wrote:
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 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).
A diff of the qemu traces shows, that at some stage
esp_transfer_data transfer() is called for 4k/transaction,
but is not started for 12k/transaction...
Full traces are here:
http://www.dellerweb.de/qemu/qemu-bugs/FAIL
http://www.dellerweb.de/qemu/qemu-bugs/OK
verify with:
diff -u OK FAIL | vi -
and go to line 2496:
-STC: 1000 hi/mid/lo: 00/10/00
+STC: 3000 hi/mid/lo: 00/30/00
esp_dma_enable Raise enable
-esp_handle_ti Transfer Information len 4096
+esp_handle_ti Transfer Information len 12288
esp_raise_irq Raise IRQ
esp_lower_drq Lower DREQ
-esp_transfer_data transfer 0/4096 <<<<<<<<<<< this seems missing for 12k
esp_pci_dma_read reg[5]: 0x00000010
esp_mem_readb reg[4]: 0x91
esp_mem_readb reg[6]: 0x04
@@ -8081,21 +7111,22 @@
Thanks for the traces, but it looks as if they are from QEMU git
master rather than the esp-rework-testing branch?
Yes.
The existing code has a number of known issues so it would be good to
eliminate those first if possible.
That's probably true, but I assume your new code is for qemu > 8.2,
while a few small fixes for 8.2 would be good to have too.
I'm not sure if that is possible, mainly because the ESP changes are dependent and
order sensitive on each other :/
Sure. I just thought of a simple patch before all your other changes.
But that's not priority.
I've repushed the esp-rework-testing branch which contains an extra WIP commit I
hope should fix the "Spurious IRQ" messages based upon some traces and experiments
done by Guenter.
Will try soon.
Anyway, traces with your esp-rework-testing branch are here:
http://www.dellerweb.de/qemu/qemu-bugs/FAIL-esp-rework-testing-4k
-> transfer limited to 4k, boots up, fails later with spurious irqs
and traces.
http://www.dellerweb.de/qemu/qemu-bugs/FAIL-esp-rework-testing-8k
-> transfers limited to 8k, fails to boot as empty pages are returned.
(same issue as with git head)
As far as I can tell looking at the traces, the 8k DMA transfers look
to be correct so I'm wondering if either the DMA descriptors are
incorrect or there is something else going on here. Can you give me
some more information as to how you detect the empty pages?
I actually don't know if null-bytes are transferred.
But ext4 reports CRC errors, so I added this hunk to the Linux kernel:
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index d7732320431a..9b12fbd44e06 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4732,6 +4736,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long
ino,
if (ret < 0)
goto bad_inode;
raw_inode = ext4_raw_inode(&iloc);
+// printk("raw_info provided %px %x\n", &raw_inode->i_checksum_lo,
raw_inode->i_checksum_lo);
+// printk(" iloc->bh->b_data %px iloc->offset %lx\n", iloc.bh->b_data, iloc.offset);
+if (raw_inode->i_checksum_lo == 0) asm(".word 0xfffdead0");
The last line immediately stops qemu if the checksum is zero.
I start qemu with
./qemu-system-hppa -drive file=../qemu-images/hdd.img.new,if=none,id=d0 -kernel
vmlinux -append "root=/dev/sda5 console=ttyS0 single earlycon=pdc" -serial
mon:stdio -smp cpus=3 -machine C3700 -nographic -snapshot -device am53c974,id=scsi
-device scsi-hd,bus=scsi.0,drive=d0
qemu aborts with the am53c974 driver.
If I use exactly the same command, but with the lsi53c895a driver instead of
am53c974, it boots correctly.
Any other idea?
I'd try setting a breakpoint on esp_pci_dma_memory_write() if len > 4096, stepping
over pci_dma_rw() in esp_pci_dma_memory_rw() and then checking with the monitor that
the entire 8k transfer is present in memory using the "xp" command to check the start
and end of the data have been copied to physical memory.
Is there an IOMMU involved here at all?
ATB,
Mark.
