x1000 onboard network opensource driver in progress: new version

@kas1e

Quote:

It's as if the processor is overloaded; the graphics in the various dockies (CPUDock, NetDock, ...) do not refresh constantly and struggle to function.
I need to check with the RTL driver.
Edit: Ok I've got the same behavior with the RTL driver.

Quote:

As soon as I start a download on my Mac, I also see the activity in the Dockie. I can also see the amount of data received or sent increasing, not only in the dockie, but also in Ranger for example, in the Network/General tab you can see this by refreshing the page.
I don't see That with RTL driver.

I'm using default settings for the dockie.

In case it could help, this what I've got on the serial :


Kind regards,

I ran VNC with shows Twitch for about two hours and didn't have any problems. Downloads worked fine, too. Uploads seem to be slow, but maybe only Problem here?

Quote from page 1:
Find out that on my x1000, when i connect router to the onboard NIC and then power on machine, then the leds both on router and on the NIC are green. All fine. Then, if i do reset by reset button on tower, they go to offline, and never come up even after OS4 loads up again. So , to make link again to work, i had to do exactly power off / power on.

I guess I still have that here.

@Petrol
Quote:
Good ! So this rule out issues with pa6t driver. Probably dockyes itself not very well done ?

Quote:

I am currently (for diagnostic tests) scan all ethernet packets, but then, i don't reply anything back it it not for us.. But if RTL have no this issue, then its something to check on my side..

Did i understand right, that you have router, to which you connect by cables Mac machine, and X1000 , both in the same network like 192.168.x.x , right ?

Quote:

That just some basic diagnostic telling all the necessary bits initialized, and that there still "crash checker", which, if lockup or something without output on serial you can check after reboot from special CFE memory which survive the reboot (which of course mean this checker write to cfe memory 4 times in a second => making driver slower than it can be, and that of course will be removed once we all sure there is no bugs related to driver itself.


@TearsOfMe

Quote:

Cool, so it works ! Banana ! :)

Quote:

Checked the same upload to the same place with RTL to confirm that upload slow with pa6t, and not with the place where you upload ?

Quote:

At least you have the same problem as me on x1000, then it mean i am not alone and we share same issue in HW .. Maybe that some first batchs of x1000 ? Or maybe some faulty component somewhere ?

Anyway, once it "up" it works, and that can't explain slow upload (if that of course the case vs RTL driver, check it plz if you can).

@kas1e

Quote:

Yep.

Kind regards,

@Thread

Absolutely no problem here!

All working as expected (even better since CPU usage has dropped, I was using a PCI 1GBs card formerly).

I've been using Odyssey with Borwservice (high network consumption) and tried many downlads at the same time.

Really great work Kas1e!

@K-L
That nice to hear !

@All
So as current version even in this form worth to upload to os4depot ? (because there can be some other things to be done , like cleaning diag, debug, speed up a little bit for sure). So just if i will not come further for any reason something usable will be already present for everyone later ?

@kas1e

I think it can be released on OS4Depot in its actual form.

👍

I just ran a test with the 8169 and then the pa6t again, and there wasn't a problem with the upload speed. So all ok with Upload Speed.

@All
Thanks you all for tests, much apricated !

Its now in upload query on os4depot.

Also, there is todo i want to do for next version:

- Add interrupt driven TX channel + pre-allocated buffers.

Currently TX is "fire and forget", which add to have speed worse than it can be.

- Re-use RX buffers

Those one also can speed things up.

- Disable promiscuous mode (so not catch whole traffic in the
network)

That one which Petrol found : i just for tests originally enable promiscuous mode which mean all the network traffic flying in the network are filtered through.

- Auto-discover free RX/TX channels instead of hardcoded rx1,tx1

Currently it's hardcoded to RX = 1 , and TX = 1 ( 0 is used by pasemi_dma.resource, which not by resource itself, but by graphics.libraries's PA6T DMA support). So will be "auto" , like if 1,1 fail choose next, etc. I just release it as it, so users will have something stable and usable already, while i can cookie next one when can.

- Remove diagnostic crash hunter

That one was added to catch this damn lockup bug : in each irq fireup i wrote debug info of registers state and co to the physical memory which is survaved when i hit "reset" button, so i can do "d 0xaddress" in CFE after reboot. I still leave it for this version just maybe someone else crash, etc.

- Replace internal Roadshow's copy functions by own AltiVec
based replacement

I already have function for replace, but, it's to be tested and seen if it will give _Any_ benefit, because Roashow it's Roadshow, and have all own internal things even if external copy routines will be used.

- ENV variables with minimal set (choose between internal and
external copy functions, speed, duplex, MTU, etc.)

That one low priority, but maybe worth to have some bits of control there too, so it will be amiiiga, etc :)

If you have any suggestions , feel free

Thanks again !

@kas1e
Thank you!
More than 30% speedup - very nice work!

@kas1e

And what was the reason or the solution for the lock up?

@MightyMax
Quote:

Latest Balaton suggestion were in right way : access of DAM and RAM at the same time => something with cache coherence.

Short story: When you have MEMATTRF_CACHEINHIBIT | MEMATTRF_COHERENT , you didn't have second one working ! It simple bypass some bits of first one, and there you go:

Amigaos4/CFE were set as "cache-inhibited + coherent" , while Linux are "cached + coherent". Simple removing MEMATTRF_CACHEINHIBIT deal with everything.


Long story:

I start stripping out Linux driver to minimum to find that it still works even in base form as i have on os4 and in raw-CFE version. Then after dumping whole PCI config space, registers and co inside of os4, linux and cfe find out they practically identically : damn.

Then wrote marker after EVERY single operation in the poll loop (it was without interrupts in test case), which like our "debugprintf()" way: where it stop writes, then there we died. And i wrote this marked to the CFE physical memory which survive the "reset" button (at 0x7f000000).

Then 4 tests, in a row, all show that we stop on the clearing of descriptor , always same. So CPU suck smock at descriptor clearing, i.e. writing zeros to DRAM while DMA writes nearby. That was it and clear that what Balaton says (DMA vs CPU fight) is it. And now i were sure too it's clearly something with memory sets. Checked how Linux maps that same memory -> checked how we (not by code, but what bits sets, etc) -> changed in CFE test case - WORKS ! Changed in OS4 test case WORKS ! Fixed in drivers - WORKS !

It may sounds like simple stuff and loosing of a week for just finding wrong settings of memory at init stage, but then, i lear how to write code over CFE, how to hack MCE trap, how to deal with Linux stuff on X1000, and many other things ! That was surely cool journey, if we can say so about sitting a week over 2 monitors :)

Thanks to the efforts of Kasie and Balaton, a major achievement has been achieved, solving a problem we've been struggling with for 20 years.
Now, beyond possible further optimizations, we could join forces and go further. Perhaps by reworking the old ATI graphics card drivers and introducing new ones. The same goes for sound cards and other hardware that has never been fully supported.
..<obviously with open source code.

@flash
That quite bold to write new radeon drivers: Hans loose years on it :) Even with age of AI help its still quite non trivial, especially with all those shaders and hardcore init of modern cards..

@All
Can anyone test Remote Destop with this driver ? How it acts ?

@kas1e

In what direction?

I'm connected on a regular basis to my server thanks to TightVNC client. No problem so far.

Never tested the other way round (connecting to a VNC server installed on my X1000).

@K-L
Yeah, thanks for test, thats enough info.