I haven't heard reports from there but I don't usually hear anything from MorphOS people. Not many people use MorphOS with QEMU as you can't register only try the demo and maybe the few who do use it use mac99 with sungem instead.

When clicking (click or click and drag) on right side border of waveform preview/gadget the apps crashes/freezes system.

Why then on all machines include x5000 rtl8139 show no bugs ? Too slow in compare with qemu ? But imho x5000 faster than qemu emulation, shouldnt be issue with too many irqs ?

Also, all in all, we can try non interrupt way for virtionet.device , i mean this busy-waiting/polling by cpu instead of irqs ? I tried it on real x1000 now (i mean non interrupt way) and while have ai bugs it works, and i didnt see lot of cpu loading (if at all) probably because roadshow limited speed anyway .. maybe as test worth of try ?

I also don't remember how MorphOS worked with RTL8139 and Qemu.

Using RTL8139 with QEmu doesn't make any sense, instead you should always try to emulate the simplest hardware as it's less likely to have emulation bugs and emulating simple hardware is usually faster than emulating more complex hardware.
For example NE2000 (rtl8029.device), or if it's supported by QEmu the 3Com (AmigaOne) or VIA Rhine (Pegasos2).

Also very important: Make sure the IRQ used for the network card (emulation) isn't shared with other PCI devices.
Ethernet I/O causes a huge number of IRQs per second anyway, with fast emulation maybe more than the kernel, other parts of the OS or drivers can handle, but if the same IRQ is shared with other PCI devices as well it's nearly guarantied to fail...
It may be a problem on the Pegasos2 which AFAIK uses a single IRQ for all PCI devices, but on the AmigaOne you have 4 IRQs which are freely configurable for each PCI port.

In case there is a problem in the kernel, the TCP/IP stack or the SANA-II drivers handling thousands of IRQs per second it's getting worse with virtio: Less overhead -> more speed -> more IRQs and task switches per second.

- The author of the OS4 RTL8139 driver found bugs in the QEmu emulation of it, that's why there were some special QEmu beta version of it.

- It's emulated. If your host has a 1 Gbit or even 10 Gbit ethernet controller that's the speed you get from the emulation as well. With the slow (every packet is copied several times around inside the TCP/IP stack while processing it) and ancient TCP/IP stacks on AmigaOS flooding it with that many packets and IRQs per second is similar to a DDoS attack

Limiting the host ethernet controller to 10 or 100 Mbit might help, at least while developing a network driver and beta testing it.
If you can't do that on your host computer itself most routers have such an option, usually called "ECO mode" or similar.

As for interrupts and speed:

Why then on all machines include x5000 rtl8139 show no bugs ? Too slow in compare with qemu ? But imho x5000 faster than qemu emulation, shouldnt be issue with too many irqs ?

kas1e wrote:

but, still have some problem with whole thing, awfull pings (sometime good enough like 0.5ms, sometime 1000(!) ms), and so all the data load up like "load fast -> stall for a while -> load fast".

If it hangs on DRAM did you check if memory is good? What is printed after that when it boots? Maybe check that too,

To answer that you may first need to understand what dma_alloc_coherent() does, in other word what coherence refers to here and why would that be needed. Maybe it does not matter as long as you only use one core. Coherence may refer to cache coherence between cores but maybe also be for PCI as was the case with graphics cards. That's why you have to find out the above first to get an answer.

If this is AI generated code then who knows, could be anything and nobody could guess without trying to make sense of the code