virtio-drivers icon indicating copy to clipboard operation
virtio-drivers copied to clipboard

getting a IoError but no clue what it means or how to fix

Open walksanatora opened this issue 1 year ago • 11 comments

https://github.com/walksanatora/oc2kernel/blob/master/src/main.rs#L119-L136 is the virtio code but yet it always returns with a IO error you can see my qemu args in run.sh

walksanatora avatar May 23 '23 21:05 walksanatora

switched to using the propper blocking command but now (updated from 0.4.0 to 0.6.0) it hangs when i create the VirtioBlk using the mmio transport and the last line is virtio_mmio_setting_irq virtio_mmio setting IRQ 1

walksanatora avatar Aug 14 '23 18:08 walksanatora

I have no clue what I am doing wrong and #os-dev is not helping

walksanatora avatar Aug 14 '23 18:08 walksanatora

Where is that log line coming from? Have you tried attaching a debugger to see where it is hanging?

qwandor avatar Aug 14 '23 19:08 qwandor

it is the last line from qemu stderr (before it hangs*) with

qemu-system-riscv64 -kernel kernel.bin \
    -machine virt \
    -cpu rv64 \
    -serial stdio \
    -device virtio-blk-device,serial=deadbeef,drive=disk0 \
    -global virtio-mmio.force-legacy=false \
    -drive id=disk0,format=raw,if=none,file=disk0.img \
    -trace virtio_mmio*

(specifically the -trace virtio_mmio*)

walksanatora avatar Aug 14 '23 20:08 walksanatora

[stderr.txt] the full stderr

walksanatora avatar Aug 14 '23 20:08 walksanatora

the last println! being hit is https://github.com/walksanatora/oc2kernel/blob/7b16402b3b7035d4cd5eb5470ce117584090dca6/src/main.rs#L123 then it enters the VirtIOBlk setup, and i get a few more messages from log

Device features: BlkFeature(SEG_MAX | GEOMETRY | BLK_SIZE | FLUSH | TOPOLOGY | C
ONFIG_WCE | DISCARD | WRITE_ZEROES | RING_INDIRECT_DESC | RING_EVENT_IDX | VERSIO
N_1)
config: 0x10008100
found a block device of size 8192KB

2 calls to allocate DMA pages

alloc@0?1: 1000000000000000000000000000000000000000000000000000000000000000
2151837760 + (4096 * 0) = 2151837760
alloc@1?1: 1100000000000000000000000000000000000000000000000000000000000000
2151837760 + (4096 * 1) = 2151841856

and then hang... full combined log of stdout+stderr out.txt

walksanatora avatar Aug 14 '23 20:08 walksanatora

Well the virtio_mmio_write_offset virtio_mmio_write offset 0x70 value 0xf line suggests that it gets as far as transport.finish_init(), and virtio_mmio_write_offset virtio_mmio_write offset 0x50 value 0x0 is notifying the device that there is an entry in the queue to process. It's weird that your log lines before that don't make it to the console though. I suggest stepping through it in a debugger to see where it actually gets stuck.

qwandor avatar Aug 15 '23 10:08 qwandor

so you mean Uart is somehow dying? hmm (idk how to do debugging with qemu, lemme search it up) okay after using some basid GDB it is reaching the Temp end panic but it is not writing the disk wait... is the blockid base 0 ofc it is

walksanatora avatar Aug 15 '23 16:08 walksanatora

but still no clue why stdio stops working

walksanatora avatar Aug 15 '23 16:08 walksanatora

okay stdio started working again. but now i have to use PciTransport to interact with VirtIO console but when I connect to it it always fails with Bar 4 not allocated and i cant find any function to allocate the bar

walksanatora avatar Aug 16 '23 02:08 walksanatora

Why do you need to use the PCI transport rather than MMIO?

If your bootloader doesn't allocate PCI BARs, you can see https://github.com/rcore-os/virtio-drivers/blob/master/examples/aarch64/src/main.rs#L394 for an example of how you might do it. There's nothing VirtIO-specific about it though, it's just standard PCI initialisation.

qwandor avatar Aug 16 '23 09:08 qwandor