@kas1eQuote:

2 years ago I tried AROS x86 in qemu with it's rtl8139 driver. It showed similiar behaviour. I did not have much clue about networking stuff, but I looked in the driver source and it had a "TODO:" comment about "wrapped buffers".

I managed to do a quick fix and the bad behaviour (load fast, stall, load fast, ...) disappeared.

The issue was that a packet in the rx buffer for whatever reason (maybe not happening on real hw) can end up being partly put at the end of the rx buffer, and the rest of it (parts which did not fit) wrapped over and was put at the beginning of the rx buffer.

So the quick fix was to allocate the rx buffer 2 times as big, and when a wrap over was detected ("if (ring_offset + rx_size > np->rx_buf_len)" copy the overspilled part from the beginning to
"rx_buffer + rx_buf_len".

Without this (I think) ~broken packets (only parts of them valid, because not fully/correctly copied) ended up going through network stack.

Well done. Amazing. Does it depend on Update 3 and the new isochronous support?

Great news! Thank you afxgroup. I'll check this driver with 2 DACs TOPPING EX5 and Topping D10.

@samo79

+1

Great work. Many thanks indeed!

@afxgroup
Great! Thank you very much!
It is not only driver - it also means one free slot in Sam460LE !

@kas1e
thanks for effort!
It will be great to have ( finally ) driver for X1000 NIC!

@balaton
Quote:

Yeah, will have to check all this while i am at it..

But it's not only this : when i hit reset one time then with 100% case NIC led didn't fire up, then i hit again reset (or 2 more times) and then connection from onboard internet fire up. I.e. 2 problems: 1). Not everytime boot, so no x1000 logo, 2). Sometime even if boot to logo, no onboard ethernet boot up.

Quote:

At least that can explain why it uses on linux much : they utilize both cores of x1000, while os4 only one, so maybe there no sense to worry, but sure i need do dig in.

Quote:

Of course that all with help of AI: it creates skeletons quite fast, how else i can come to even transfer something for just 2 days :) But then it still need understanding in end to deal everything right. For me were important to know if my onboard network works at all (it is), and if it can transfer data at all (as all those issues with onboard driver there for many years already).

So, talking about which, if you (and joerg :) ) have time , can you plz light me up on this and fix if i talk bull:

As far as i understand, when x1000 (on any amigaos4) hw) boot up, it doing some PCI mapping from physical to virtual called ECAM, and for x1000 (found by tests on real x1000 hw) the start address of ECAM are 0xE0000000.

Next, we have there whole PCI(e) three, which include IOB (first , right at the 0xE0000000, then come other stuff like L2, and then on 0xe00a3000 (00:14.3) we had Ethernet, after which come XAUI, and then at 0xe00d0000 (00:1a.0) DMA engine, and then things go further with SMBus, Serial, etc, etc.

Now, what i also found is that some devices have BAR, some have none at all. The IOB, MAC, DMA, L2, few internal to soc PCIe Bridges have no BAR at all, GetResourceRange() just return NULL for them. While others ones (which also part of SOC) still have BARs : SB600, SMBus, Serial, etc. And of course all external devices have BARs too.

Then, as i see it, for BAR devices we use GetResourceRange() + ReadConfigLong/WriteConfigLong() (or we can directly (volatile ULONG *)r->BaseAddress; just take care byteswapping). For NOBAR devices (our onboard network as one of them), we just use ECAM address+offset, and then again, then same ReadConfigLong/WriteConfigLong() or direct "(volatile ULONG *)0xE0000000;".


Next, we can 2 ways to wrote driver :

1. polling/busywait one , so no interrupts, and probably on real hardware no go ? Currently that the way i use with beta driver.

2. interrupt driven one : this one probably way to go on x1000, but then , currently i didn't get for now full picture of how i should operate with. I.e. this can't be not just simple AddIntServer,like done in the atheros5000 driver by Neils like PCI interrupt path → AddIntServer(MapInterrupt(), handler) , but totally different we should compute ourselfs with usage of DMA_engine where interrupts are, etc ?


Did i get everything right till that point ? Because AI of course helps, but offten generate unlogical crap, so had to sort it all before moving to the next steps..

Thanks!

@trixie

For next release could you add support for localization?

@trixie

Hi threr is another issue:
When clicking (click or click and drag) on right side border of waveform preview/gadget the apps crashes/freezes system.

@Maijestro

Using the existing 2.9 build, Rhea crashes, is this something you've been able to look into?

https://bugs.scummvm.org/ticket/15865

@joerg
Quote:
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 ..

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

@msteed

Quote:
It was a race condition. More details in my next blog post

@trixie

Quote:
With all the weird symptoms, I'm curious what the problem turned out to be.

@kas1e
Quote: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.

@trixieQuote:
Thank to both of you!

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

@Tuvok

Welcome to the the top ten high score list at amiboing.de

@ graff

Thanks

@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)