Re: 64-bit userspace root file system for hppa64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:

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?


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 :/

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.

Anyway, traces with your esp-rework-testing branch are here:
-> transfer limited to 4k, boots up, fails later with spurious irqs
and traces.
-> 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?



[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux