Looks like the author of the AmigaOS 4.x RTL 8[01][23]9 drivers found a workaround for the QEmu problems. It looks like it's not sure yet if it's bug in the QEmu emulation, or the AmigaOS 4.x drivers, but the combination of both failed with older versions.
Any details on what this workaround is?
I haven't had the time lately to investigate the interrupt issues further. One problem with VirtioGPU is the sheer number of interrupts. It triggers one interrupt per submitted command buffer. Due to how AmigaOS' graphics.library works, that's one interrupt per draw call...
Supported Realtek Ethernet controllers are 8029, 8139 and 8169.
So does this driver on the install CD also support 8029? QEMU also emulates that as -device ne2k_pci so maybe that can also be tested then as an alternative to fix the problem with previous driver versions. As the driver is named rtl8139 I did not know it also supported other similar chips as well so I've never tried.
So does this driver on the install CD also support 8029? ... As the driver is named rtl8139 I did not know it also supported other similar chips as well so I've never tried.
No, there are 3 different RTL drivers: rtl8029.device (not limited to Realtek, any NE2k compatible card should work), rtl8139.device and rtl8169.device IIRC the 8029/NE2k cards are slow PIO cards and therefore not used on real hardware, except for classic Amigas without PCI DMA support. A list of hardware supported by AmigaOS 4.1 is available on https://www.acube-systems.biz/compatibility/compatibility_41.php
@white I don't think your problems in AmiCygnix were related to the guest network card type but more likely to port forwarding or other network setup on the host but you can try with -device ne2k_pci instead of -device rtl8139 and see if it works at all (could be it does not work if the driver expects something the QEMU emulation does not support) or try the udpated rtl8139 driver that was mentioned above in case that works better (but if you had no connection at all and not a connection that breaks then it's a different issue than this updated driver fixes).
white wrote:I must have said it a thousand times. RTL8029 is the only driver in "EMULATION" that supports AmiCygnix.
Even with WinUAE RTL8029 is the only one that supports AmiCygnix.
All other drivers do not support AmiCygnix.
The reasons ?
I don't know, I'm not a programmer.
But there must be a reason if it works so if possible I would dedicate myself with qemu AmigaOs4.1 to the RTL8029.
I'm not sure what they are trying to tell us, but it's about the RTL8139 driver under Qemu.
This is now available as a test driver....earlier versions always caused the internet connection to break SMB2/FTP upload/download under Qemu AmigaOs4.1.
With the new test driver the network is really stable for the first time.
As soon as the final version 9 comes out I'll try it. A thousand thanks. Of course I always appreciate your work.
I'm currently playing "Elden Ring" and have almost played 150 hours. I haven't had this much fun with a game in years, aside from swearing I haven't finished the first "run" yet, I'm practically at the end, just long enough to wait for "qemu 9"
qemu RTL 8139 I access the Linux shell with AmiCygnix "sshterm" but not the graphics part for example "Firefox" or FFPlayer is executed because you only hear the sound inside AmiCygnix.
WinUae RTL 8139 I can't access the Linux shell with AmiCygnix or even the graphics part in any way.
WinUae RTL 8029 with AmiCygnix I access both the shell and the graphics part therefore FFPlay Firefox etc. always using sshterm .
a little note: I use qemu with Linux but also on Windows.
I use Windows 10 LTSC 2021 and no automatic patch has been released to fix the recovery partition with this update KB5034441 to resolve a vulnerability.
now I understand how diskpart works with Windows and how to mount the various partitions with qemu even with Windows by correctly identifying them with the correct ID.
I will try running the various X graphics for Windows with AmiCygnix.
now I understand how diskpart works with Windows and how to mount the various partitions with qemu even with Windows by correctly identifying them with the correct ID.
I will try running the various X graphics for Windows with AmiCygnix.
This is just a little note.
That's right, you can basically transfer anything with the correct device ID to Qemu. Just recently I transferred a real external CDRom drive, the only important thing is that the devices must not be registered in the host system.
Looking into this a bit more, it looks like the problem might be triggered when an interrupt from the VirtioGPU device comes in while the OS is still busy calling interrupt handlers for another device.
I added a second interrupt handler to the end of the chain, and the last thing visible before it hangs, is the VirtioGPU's Interrupt Status Register changing between the top of the chain, and the end.
That should trigger an interrupt the moment that interrupts are enabled again, but for some reason it doesn't.
@Hans Interrupts probably only retrigger if level sensitive is used so is it set correctly in PIC? Does this only happen with BBoot or also with booting from pegasos2.rom? If only with BBoot maybe we're missing some PIC or other init that the firmware does normally.
I've checked the docs and emulation. VIA southbridges function 0 (ISA bridge) config register 0x54 is documented to set PIRQ inputs to edge or level sensitive, default is level sensitive. BBoot sets this for amigaone but not for pegasos2 but this does not matter as this register is not emulated and always set to level sensitive. This is (more or less) implemented in qemu/hw/isa/vt82c686.c::via_isa_set_irq(). It should keep track of interrupt states and keep the interrupt raised as long as there's one source active. But PIRQ pins are kept track together so if a PCI device uses more than one pin (PCI has INTA-INTD) or maybe if more than one device uses the same pin (but the latter should be handled by the PCI emulation so should not be a problem) it might clear PCI interrupts. I wonder if uint16_t mask = BIT(f) calculation should be moved after the switch (f) to keep track of PIRQ pins separately?
After that it goes to the i8259 PIC emulation and I don't know what that does with it and when does it raise the CPU interrupt. That may need to be checked separately but no time for that and without being able to test and reproduce the issue it's hard to check.
Edited by balaton on 2024/4/10 22:50:15 Edited by balaton on 2024/4/10 22:52:09 Edited by balaton on 2024/4/10 22:56:22 Edited by balaton on 2024/4/10 23:34:30
It doesn't help that the ISR is cleared by reading. So, trying to monitor that register from the driver when not running the interrupt handler is guaranteed to cause interrupts to be missed.
Is everything completely frozen or are other things (not using/affected directly or indirectly by gfx) still running in the system? Like if you create a (high pri) task that every second kprintfs something to debug output.
Is everything completely frozen or are other things (not using/affected directly or indirectly by gfx) still running in the system? Like if you create a (high pri) task that every second kprintfs something to debug output.
Good question. The rest of the OS is still running, so things like timer interrupts still work. So, the problem really is that external interrupts stop making it through to the interrupt handler(s).
The "virtio_pci_notify" log entries are the VirtioGPU triggering an interrupt. So, the failure starts with the VirtioGPU triggering an interrupt while AmigaOS is processing a previous interrupt. The OS has interrupts disabled at this point. It looks like the interrupts are triggered once the OS enables interrupts again, but the PIC's Interrupt Request Register (IRR) has a different value.
I'll have to look at the PIC's documentation again. It wasn't clear to me how the IRR register is supposed to behave.
@Georg I've already got a way to log various events.
@all I've been reading up on the PIC, and it looks like something is indeed going wrong with it.
The 8259 has a master and slave, and the slave is mapped through to one of the interrupt lines on the master (IRR = 2, so IRQ 1). The PCI interrupts appear to be routed to the slave (IRR = 2 as well, which is IRQ 9).
So, when a PCI interrupt occurs, then bit 2 should be set on both the master and the slave. However, after something has gone wrong, the master's IRR is 128 instead, which signals IRQ 7 alone. So, IRQ 1 no longer gets set, and no more interrupts get through.
The next question is: is this an emulation error? Or a PIC programming error from the AmigaOS side? I don't understand the PIC well enough yet to decipher the QEMU PIC logging.
Final notes for the day. The PIC is programmed in edge-triggered mode, and somehow ends up in a state where bit 2 of last_irr is set, but bit 2 of irr is 0.
That sounds wrong if you want it to retrigger interrupts that were not yet serviced. I think edge mode will only trigger the interrupt once when the device signals it but does not keep the state, but I could be wrong about that.
I've asked this before but did you try if the problem also reproduces with -bios pegasos2.rom or using -machine sam460ex that does not use ISA PIC? I think either the firmware may set something in PIC that is missing from BBoot or there's something in the PIC emulation not working as AmigaOS expects. If the emulation or the expectation is wrong I can't tell but this ISA PIC model is used by everything in QEMU that has a PIC and all OSes running on those are fine with it so unless it's some obscure feature not normally relied upon the PIC model should be generally OK.
For getting values of registers you could also add debug printfs to QEMU if needed. Other than that I don't know the PIC or its emulation either so can't help much with that.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
