working virtio-net.device for QEMU : no more issues with rtl drivers !

	Bottom Previous Topic Next Topic
Register To Post

« 1 (2)

balaton

Re: working virtio-net.device for QEMU : no more issues with rtl drivers !

Posted on: Yesterday 20:17 #21

Just can't stay away

@smarkusg
Quote:

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.

https://qmiga.codeberg.page/

balaton

Re: working virtio-net.device for QEMU : no more issues with rtl drivers !

Posted on: Yesterday 20:23 #22

Just can't stay away

@kas1e
Quote:

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.

https://qmiga.codeberg.page/

smarkusg

Re: working virtio-net.device for QEMU : no more issues with rtl drivers !

Posted on: Yesterday 23:27 #23

Quite a regular

@balaton
Quote:

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.

kas1e

Re: working virtio-net.device for QEMU : no more issues with rtl drivers !

Posted on: Today 8:55 #24

Home away from home

@joerg
Quote:

- 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.

Join us to improve dopus5!
AmigaOS4 on youtube

smarkusg

Re: working virtio-net.device for QEMU : no more issues with rtl drivers !

Posted on: Today 14:16 #25

Quite a regular

@joerg
Quote:

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

 

 qdisc htb 2: root refcnt 2 r2q 100 default 0x100 direct_packets_stat 6 direct_qlen 1000

 Sent 17699603 bytes 13217 pkt (dropped 14, overlimits 12285 requeues 0)

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 wonder if it's from AOS or QEMU.
The only explanation that it could be from AOS4 is this entry:
https://pl.wikipedia.org/wiki/0xDEADBEEF
https://forum.icomp.de/index.php?threa ... tcp-with-daynaport-amiga/

Register To Post	« 1 (2)
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 4 ( 0 members and 4 Anonymous Users )