I also don't remember how MorphOS worked with RTL8139 and Qemu.
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.
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 ?
CPU speed probably does not matter here more network speed. X5000 uses different kernel so problem may only be with pegasos2 or with IRQ sharing. If there's a problem with interrupt handling in AmigaOS it could explain a hang. Is it possible to get a stacktrace of a hung driver to see where it stopped?
Quote:
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 ?
Polling is not an option as it would be very ineffifient so I don't think it's usable. It may only be used to test if the problem is in interrupt handling. With polling if you limit the number of polls to avoid high load it will limit the speed and if you do it too often it will generate constant load even if nothing is transferred. That's why these normally use interrupts which is a better way to handle these async events.
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.
I have a MorphOS disk image version 3.19 for PEG2 somewhere and I can take a look. Generally speaking, apart from MorphOS, we would have to redo the tests for RTL8139 on the current version of QEMU and AOS4. There have been a few changes over the past few years. UP3 Roadshow had an update to version 1.15, drivers... Even the systems on which QEMU runs. It is possible that some of the old reports are outdated regarding AOS4 and may be incorrect. Even if someone wrote that everything works correctly on Windows, it was true, but they did not provide any details. If anyone is willing to test RTL8139 and QEMU, please let me know. It would be best to start a new thread related to this on amigans.net. I will definitely not check it myself because it is time-consuming on all QEMU machines where QEMU runs (A1, PEG2, Sam460), various macOS and Linux systems, and possible stupid changes in system settings (e.g., MTU). If no one is willing to do it and everyone is waiting for a ready-made solution, they will certainly not find out whether RTL8139 is currently working properly.
- 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.
Nope, it was like this version deal with issue, but in end turns out that it not, and this unnecessary change were reverted after all (and few more beta versions were out since then, none of which fix it).
In other words , i test about 10 version of rtl8139 where the "fixed on from os4welt" (which fix nothing in end) were a middle one, so 5 before and 5 after : all same or kind of same issues. No differences.
@balaton Quote:
Polling is not an option as it would be very ineffifient so I don't think it's usable. It may only be used to test if the problem is in interrupt handling.
Yes, that exactly what i mean, just to check if issue persist. If no we know where to look at. If yes, we then also know where to not look at :)
@All In other words, i only one time somewhere on os4welt from one user read that he make rtl8139 to work, with "fixed" driver, which didn't fix anything for me, but then, when i read this topic, it was "today fixed, tomorrow not fixed, i changed params, nope didnt' changed, oh all works, not not works" , so no proper tests were done.
Also, it's now clear (or still not?) that it's not only windows build problem, as smarkusg confirm right now he have same on Linux machine as well.
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.
I started QEMU with ‘-netdev tap,id=mynet0,ifname=tap0,script=no,downscript=no -device virtio-net-pci-non-transitional,netdev=mynet0' I did simple HTB qdisc shapes traffic in Linux on tap where all traffic goes
tc qdisc add dev tap0 root handle 2: htb default 400 r2q 100
tc class add dev tap0 parent 2:10 classid 2:100 htb rate 2000kbit ceil 200kbit
I still get an error, the transfer is limited to 2Mb [virtio-net] TransmitPacket: TX timeout after 100. Then the transfer drops to low values. But out of curiosity, I see something like this in tcpdump
14:36:53.167782 be:ef:de:ad:be:ef > 67:6f:b2:10:de:ad, ethertype Unknown (0xdead), length 134:
0x0000: beef dead beef dead beef dead beef dead ................
0x0010: beef dead beef dead beef dead beef dead ................
0x0020: beef dead beef dead beef dead beef dead ................
0x0030: beef dead beef dead beef dead beef dead ................
0x0040: beef dead beef dead beef dead beef dead ................
0x0050: beef dead beef dead beef dead beef dead ................
0x0060: beef dead beef dead beef dead beef dead ................
0x0070: beef dead beef dead
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.
QEMu Peg2 rtl8139 works fine on Morphos. I copied data via sftp from my Raspberry Pi, which is connected via 2.4Ghz wifi (transfer was limited - QEMU sources over 880MB (small files). It copied about 200MB Nothing crashed. Unfortunately, the dorm user's time ran out. The same test - under the same conditions (Raspberry Pi wifi sftp) AOS4 is unable to pass. It would have crashed either a long time ago ...or under good conditions the transfers were negligible. It is clear that QEMU emulation on Peg2 works correctly. No one from Morphos has certainly done anything to make something work better on QEMU. The Morphos license cannot be purchased for QEMU. I hope that the port of the AOS4 system to Mirari (if it ever happens) will be better than Peg2 for AOS4 :-/
AmigaOS 4.x ExceSG kernel with "munge" in the os4_commandline (may also require using "kernel.debug" instead of "kernel" kickstart module): If the value is 0xDEADBEEF or 0xFEFEBEEF then you have accessed some memory after it has been freed;.
IIRC 0xFEFEBEEF was used on Sam440/460 instead because it may have something valid mapped in the 0xDEAD.... range.
I think that my level of debugging programs for AOS4 is too low, unfortunately... I hope it was worth sharing what I managed to find.
It is clear that QEMU emulation on Peg2 works correctly.
No, it's not. Just because some RTL 8139 guest drivers (MorphOS, Linux, etc.) are working with the emulation of it in QEmu doesn't mean the emulation is 100% correct.
No, it's not. Just because some RTL 8139 guest drivers (MorphOS, Linux, etc.) are working with the emulation of it in QEmu doesn't mean the emulation is 100% correct.
If you're convinced it's a bug in emulation can you tell me what it is so we can fix it? So far nobody could identify any bug even after comparing the emulation with the chip docs and other OSes rtl8139 drivers don't seem to have a problem.
It's not clear if that was something valid the driver did not handle because it wasn't seen with cards and machines tested so far or something that should not happen. The docs aren't very clear and may also depend on which mode the chip is used. What I've found in RTL8139C(L)+ datasheet v1.6 03 September 2004 says: Quote:
C Mode: ... The Rx buffer should be pre-allocated and indicated in RCR before packet reception. All received packets stored in Rx buffer, including Rx header and 4-byte CRC, are double-word alignment. I.e., each received packet is placed at next available double-word alignment address after the last received packet in Rx buffer.
This seems to allow wrapped packets if the buffer is larger than the packet but there's also a wrap bit in RX control register to disable that which seems to be emulated. Then: Quote:
C+ Mode: ... Similar to the transmit FIFO, the receive FIFO is controlled by the FIFO threshold value in RXFTH. This value determines the number of long words written into the FIFO from the MAC unit before a DMA request for system memory occurs. Once the RTL8139C(L)+ gets the bus, it will continue to transfer the long words from the FIFO until the data in the FIFO is less than one long word, or has reached the end of the packet, or the max DMA burst size is reached , as set in MXDMA.
This mentions end of packet and also the wrap bit says that's for C mode only or when RX buffer is not set to 64k but does not say which setting it defaults to otherwise. But I don't know what mode the AmigaOS driver uses or if it has the same issue as the AROS driver so not sure if any of the above would help.
joerg wrote:@smarkusg AROS RTL 8139 driver needed workarounds for QEmu as well.
Not sure it was workaround. May have been real bug. The driver readme says "incomplete/experimental". Don't know how much tested or used at all it was. And how much on real hw or "only" emus or virtual machines. Maybe it was fine on things like VirtualBox or VMWare which is or was typically used for AROS instead of qemu.
The driver definitely has more bugs, for example you can see some code (32bit status peeking from rx packet header) that would certainly not work on AROS big endian versions.
No, it's not. Just because some RTL 8139 guest drivers (MorphOS, Linux, etc.) are working with the emulation of it in QEmu doesn't mean the emulation is 100% correct.
etc=Windows XP. I have Windows XP under qemu-system-i386 (3dfx) where the network card is RTL8139 (original drivers from Microsoft). It works there too. But it is possible that there is something specific in the drivers for the system or the system itself, or even, as you wrote, that the fast hardware on which the emulation is running behaves in a certain way for the system that is strange for the “guest” and may cause problems with the operation of RTL8139. QEMU does not reproduce everything 1:1 (it is not low-level emulation) - this must be kept in mind. The simplest example of 1:1 emulation is https://86box.net. There, the main emphasis is on reproducing low-level operations. It is great for running Amithlon. Building a PC from scratch (without GUI support, relying only on documentation, checking if the motherboard will work with the CPU, RAM, etc.) is great fun ;-D
Without cluttering up the virtio-net.device thread, the RTL8139 problem in QEMU AOS4 emulation is known and awaiting a solution.
Without cluttering up the virtio-net.device thread, the RTL8139 problem in QEMU AOS4 emulation is known and awaiting a solution.
Problem is known but cause is not so we can't solve it. This came up here because apparently the virtio-net driver showed the same problem. If that's true it means cause maybe not in rtl8139 driver or emulation as both of these are different with virtio-net but it may be somewhere else.
That Windows XP works does not mean much for this as that's totally different machine. Do other guest OSes work with same qemu-system-ppc command that has problem with AmigaOS? Can it be reproduced with Linux or MorphOS on same QEMU machine? If other guests work then it's also likely that machine emulation also works so problem is most likely in AmigaOS but not in its rtl8139 driver but somewhere else or in some part of machine emulation that only AmigaOS uses.
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
