@All So happy to share that i have working virtio-net.device for amigaos4/qemu, so you have no more needs to tinker with rtl device issues !
Big thanks coming to derfs who made a base for that with his virtioSCSI.device, with code from which were matter of "just" add a SANA2 support and get rid of SCSI code. Also thanks to Neil Cafferkey who share his network drivers code for prism2 and atheros5000, it also help with os4 bits.
For one day it was some boring/AI cleaning to just start and make ping 127.0.0.1 to work, then bunch of crashes and issues (of course) of all sort, which were dealt only with Neil's code of drivers, then some debugging as always, and yeah !
(click to open in new tab for full sized images):
detected device in Ranger, network settings and ping of localhost
actually working state
debug split without which you can't fix a shit
Now all what need it is to remove debug output, check the speed (and improve if possible), and that all !
For one day it was some boring/AI cleaning to just start and make ping 127.0.0.1 to work, then bunch of crashes and issues (of course) of all sort, which were dealt only with Neil's code of drivers, then some debugging as always, and yeah !
So if you managed to clean AI cruft from the virtio part it's time to make that a virtio.library so others don't have to clean the other drivers one by one an won't have this code repeated in all drivers but can all use the same virtio.library so if one driver improves it all the others can benefit.
I not sure, and i can be wrong, but it looks like it share same issues which i have with rtl ! Need to be double sure, but so far i can see how my network died after a while, and i start to have packet loss even on ping. But that of course can be easy bugs in this device, but strangely repeats same issues as with rtl .. Maybe some of you can check how it reacts on your qemus. Thanks!
I not sure, and i can be wrong, but it looks like it share same issues which i have with rtl !
Did you try it with your WSL2 QEmu setup already? Even if it's slower it may be stable as IIRC the AmigaOS 4.x RTL drivers are working with QEmu running on Linux and MaxOS hosts and there are only problems with (some?) Windows hosts. It may be the same for your virtio-net.device.
I.e. lines just exactly same, just change "rtl8139" on "virtio-net-pci,disable-legacy=on"
@joerg Quote:
Did you try it with your WSL2 QEmu setup already? Even if it's slower it may be stable as IIRC the AmigaOS 4.x RTL drivers are working with QEmu running on Linux and MaxOS hosts and there are only problems with (some?) Windows hosts. It may be the same for your virtio-net.device.
Currently tried only directly on own win64 build, where it seems that once i surf a bit with odyssey, then whole stack start to acts : i tried to ping in another console same what i were able to ping normally, and have 66% of packet loss. Then reboot, and all fine. Remind me same issue i have with rtl driver , when i start to do something, it like works, and then all going to crawl. But will check on wsl2 build as well to see how it will be ..
The rtl8139 AmigaOS driver author has looked at it before and also checked the emulation in QEMU and could not find any problem in either of those so it could well be the issue is somewhere else. It could be in AmigaOS common SANAII code or network stack too. That it works on real machines does not mean the AmigaOS side does not have race conditions that do not happen as long as things are slow as on real machine but could break when replies come faster than expected (sometimes instantly) on emulation that may never happen on real machines. It could also be in QEMU's Windows version as that's less tested but since all network cards use the same netdev backends in QEMU and a lot of people use those it should not be completely broken so it's more likely to be either in rtl8139 emulation (which does not seem to be the case), pegasos2 emulation (you could try with other machines to check) or somewhere on the AmigaOS side but not in other parts of QEMU.
It also freezes on Asahi Linux ARM64 (Fedora). But it's a little different than RTL8139. Small packets still get through. On RTL8139, access is completely cut off.
Now my question, Roadshow (maybe a stupid one). From what I've read, it works strangely even on real machines. The INTERNET speed is poor. You can get some good values on the LAN. Is there a problem there? I don't currently know how packets are transmitted through QEMU. QEMU definitely emulates network cards, but what if a guest (AOS4 with an old TCP/IP stack) gets a “large packet” exceeding some limit (10Mb/100Mb/1Gb)? It will try to limit it, but it won't be able to handle it... will it crash? I'm just writing theoretically - these are just my random thoughts and I may be talking nonsense. One last thing: qemu-system-ppc and MacOS 9 PPC and Linux PPC work fine. There are no problems there.
But it's a little different than RTL8139. Small packets still get through. On RTL8139, access is completely cut off.
Are you using the RTL driver versions from os4welt.de with the workarounds for the QEmu RTL emulation bugs? The public versions (for real hardware) are unlikely to work without problems.
Quote:
The INTERNET speed is poor. You can get some good values on the LAN. Is there a problem there?
You may manually have to reduce the MTU/MRU sizes as a router adds some overhead causing packet splits for connections outside of the LAN if you use the max. MTU/MRU sizes supported by your LAN. IIRC MTU path discovery doesn't work or isn't even implemented in RoadShow and the only AmigaOS TCP/IP stack supporting it was the "Deluxe" version of Miami (MiamiDx).
Quote:
I don't currently know how packets are transmitted through QEMU. QEMU definitely emulates network cards, but what if a guest (AOS4 with an old TCP/IP stack) gets a “large packet” exceeding some limit (10Mb/100Mb/1Gb)? It will try to limit it, but it won't be able to handle it... will it crash?
It's not possible to receive too large packets like jumbo frames, IPv6, or anything else modern not supported by the ancient AmigaOS TCP/IP stacks (nearly all are based on the BSD 4.3 lite TCP/IP stack, incl. AmiTCP, Miami/MiamiDx and RoadShow, only the Commodore AS225 TCP/IP stack with it's socket.library, and some tiny TCP/IP stacks with minimal functionality on Aminet, use other code bases): The max. packet sizes, features supported, etc., are configured by the TCP/IP stack and it's SANA-II device drivers.
Are you using the RTL driver versions from os4welt.de with the workarounds for the QEmu RTL emulation bugs? The public versions (for real hardware) are unlikely to work without problems.
Yes, I use this driver. It works quite well for my purposes, and I have no complaints about it. But it can also crash. For example, if you start copying a large number of very small files (such as program sources via RNOXfer), the driver will stop working. But I've learned how to use it. Quote:
You may manually have to reduce the MTU/MRU sizes as a router adds some overhead causing packet splits for connections outside of the LAN if you use the max. MTU/MRU sizes supported by your LAN. IIRC MTU path discovery doesn't work or isn't even implemented in RoadShow and the only AmigaOS TCP/IP stack supporting it was the "Deluxe" version of Miami (MiamiDx)
MTU cannot be changed to AOS4 above the value of 1500. Above this value, e.g., 9000, they change to 1500. It is possible to change something using Roadshowcontrol. Changing the tcp.sendspace/tcp.recvspace value to the minimum value with the virtio-net.device driver causes a very quick “TransmitPacket: TX timout ..” error. I don't really know where this comes from and where the value 1000000 comes from.
I tried on the qemu side and with the virtio-net-pci options to limit the RX buffer and speed, but it didn't help. But as I wrote, after the error “TransmitPacket: TX timout ..” appeared, the driver It still works. Something has stifled it.
I have no idea how to quickly clear buffers in AOS4, reset certain things like in Linux. It's hard to find any documentation for AOS4.
The virtio-net.device driver is definitely faster than RTL8139. Maybe the symptoms show up faster, but is that a problem with the early version of the virtio-net.device driver?
@smarkusg I read somewhere that issues with rtl driver happens only on the windows version of qemu, did i get it right that you have them on linux too ? (just want to understand the patterns with both rtl and virtio drivers issues)
@smarkusg 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.
detected device in Ranger, network settings and ping of localhost
From the Ranger screenshot: "Interrupt: Line 0x09, PIN: A" Looks like Pegasos2 emulation. That will never work reliable, at least not with any of the public kernel versions... Try AmigaOne or Sam460 emulation instead.
@kas1e I thought that RTL8139 only works well under Windows The only person who did not report any problems was using Windows (he did not specify which driver version he was using) It does not work properly on any emulated machine (A1, Peg2, and Sam460 - official driver even 53.11 and unofficial 53.7). What version of the RTL8139 driver are you using? The 53.7 driver can be easily identified even when starting the system with debug it prints additional information that is not available in the final versions -- [HW_BoardReset] PCI Vendor ID...: 0x10EC PCI Device ID...: 0x8139 PCI Capabilities: 0x00000003 PCI IO Range....: 0x00001200 [HW_SpeedSetup] Unit 0: 100Mbps full-duplex operation! [HW_BoardInit] Board at unit 0 ready for operation! -- There was a discussion about problems with RTl8139 two years ago. You would have to go through all these topics, which could take a long time. I also don't remember how MorphOS worked with RTL8139 and Qemu.
@joerg I changed the IRQ for A1 and PEG2 - it didn't help. The problem was the same - complete disconnection of the driver/device after a while. RTL8129 does not work under QEMU and ASO4.
The best test would be to insert an RTL8139 PCI card into a machine with QEMU PCI passthrough. Pass the RTL8139 card directly to AOS4 on Peg2 or A1 emulation and check. My machine is packed away in a cupboard. Maybe I'll run it when QEMU-11 comes out. If anyone has a machine with QEMU PCI passthrough, they can check it themselves.
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).
I checked everything before: none works. I tested many versions of rtl8139 with no luck, same as ne2000 (didnt eork at all on qemu) and so on.
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 ?
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 ?
@smarkusg I betatester so were able to test many versions : none works ..
News feed
OS4 Feedback forum
OS4Depot Feedback 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
Donate
