x1000 onboard network opensource driver in progress

	Bottom Previous Topic Next Topic
Register To Post

« 1 2 3 4 (5)

balaton

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 14:32 #81

Just can't stay away

@joerg
Quote:

MCE is implemented and enabled in the kernel.

Never seen something like
Quote:
Dump of context at 0x12345678
Trap type: Machine check exception
...
in the serial output yet?

No, I haven't seen that. Never happens with emulation. Have you seen it on real machines?

https://qmiga.codeberg.page/

balaton

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 14:35 #82

Just can't stay away

@nbache
Quote:

nbache wrote:@kas1e

I remember something similar, not sure when and where it was discussed (but loooong ago).

However when I check my X1000 with Ranger, it reports a MAC address of C4:3D: ..., i.e. different from yours.

So either it was solved at some point, or it was never all X1000 machines?

Could depend on firmware version? Maybe updated firmware could fix that or it's set in nvram? I have no idea just guessing.

https://qmiga.codeberg.page/

joerg

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 15:00 #83

Home away from home

@balaton
Quote:

No, I haven't seen that. Never happens with emulation. Have you seen it on real machines?

Yes. On emulation it may not be possible at all, or only when using real hardware like a passed through PCIe gfx card.

joerg

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 15:14 #84

Home away from home

@kas1e
Quote:

I do not remember, but wasn't there some issue with MAC addresses on x1000 where they all the same? I sure remember something of that sort, just dunno if for x1000.

No idea about the X1000, but the X5000 has, or at least had, the same issue:
In the default U-Boot env variables on the MicroSD card delivered with it the variables for the MAC addresses were set

All systems using this default use those same 2 MAC addresses, probably the ones of a X5000 of an U-Boot developer.
If the MAC address env variables are set (and saved) the values from the env variables are used.
Only if it's not set/deleted the firmware reads it from the hardware, which is, or at least should be, different for each system, and stores it to the U-Boot MAC env variables again.

But it's only a problem if you have >= 2 X1000 or >= 2 X5000 in the same LAN

joerg

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 15:24 #85

Home away from home

@Georg
Quote:

Using AOS4 version of maybe undocumented ~PA_CALL/~PA_FASTCALL instead of PA_SOFTINT for the timer replyport would work better.

I don't know what AROS ~PA_CALL/~PA_FASTCALL is, and what the difference between both is, but in AmigaOS 4.x it' the same as in AmigaOS 0.x-3.9, except that on AmigaOS 4.x it has to be a PPC native function and no emulated m68k code:
A single, undocumented but implemented method.

I'm not sure anymore, but I think the value required for it is (the same as) PF_ACTION.

joerg

Re: x1000 onboard network opensource driver in progress

Posted on: Yesterday 16:20 #86

Home away from home

@Georg
Quote:

Are gfx drivers in AOS4 already loaded/running when S:startup-sequence is executed?

Of course they are, required for example to display the "Early Startup Menu" on the gfx card.
But it's limited to a special "BootVGA" screen mode, IIRC 800x600.
It's the same when booting without executing S:Startup-Sequence, from the early startup menu, or with some special keys.

Only after the OS is completey loaded, after starting the DEVS:Monitors drivers, etc., you have access to FHD, 4k, 8k, etc. (depending on gfx card and monitor hardware) screen modes.

kas1e

Re: x1000 onboard network opensource driver in progress

Posted on: Today 3:17 #87

Home away from home

@All
Ok, there it is, cleaned and structured as much as possible so it will be easy to read:

https://github.com/kas1e/pa6t_eth

There is also a "DRIVER_OVERVIEW.txt" explaining how it works in brief.

Also there is a "linux_ref" dir: it contains the Linux source code of the drivers for everything supported on the X1000 (including our network driver), and the necessary parts from the platform support, so you have no need to search for anything anywhere -- everything is there.

Please check this, maybe some of you will immediately find what is wrong, or will have some ideas, etc.

Thanks a lot!

ps. And thanks to Derffs for device skeleton code, that helps much!

EDIT: Check again latest version (the one on github) via my stress tool which doing that: open multiple TCP connections and recieve data as fast as possible (on the server side i send bunch of AAAAAA when connected by stress tool from x1000), so we force drirver's RX ring wraps many times per second. Now first run after boot pass 300 seconds run fine, then immediately i run it second time, and


[stress] =====================================================

[stress] PA6T-1682M RX ring-wrap stress tester

[stress] =====================================================

[stress] Server     : 192.168.0.144:9999

[stress] Connections: 8

[stress] Duration   : 300 seconds

[stress] Ring wrap  : every 64 frames



[stress] Connection 0 open (fd=0)

[stress] Connection 1 open (fd=1)

[stress] Connection 2 open (fd=2)

[stress] Connection 3 open (fd=3)

[stress] Connection 4 open (fd=4)

[stress] Connection 5 open (fd=5)

[stress] Connection 6 open (fd=6)

[stress] Connection 7 open (fd=7)

[stress] 8/8 connections open.  Starting receive...



[stress]  Time | Received  | Est.pkts  | Est.wraps | Active

[stress] ------|-----------|-----------|-----------|-------

[stress]     1s |   12351 KB |      9447 |       147 | 8

[stress]     2s |   25083 KB |     19129 |       298 | 8

[stress]     3s |   37837 KB |     28825 |       450 | 8

[stress]     4s |   50398 KB |     38365 |       599 | 8

[stress]     5s |   63073 KB |     47953 |       749 | 8

[stress]     6s |   75541 KB |     57403 |       896 | 8

[stress]     7s |   88256 KB |     67065 |      1047 | 8

[stress]     8s |  100934 KB |     76661 |      1197 | 8

[stress]     9s |  113444 KB |     86194 |      1346 | 8

[stress]    10s |  125966 KB |     95743 |      1495 | 8

[stress]    11s |  138519 KB |    105294 |      1645 | 8

[stress]    12s |  151033 KB |    114816 |      1794 | 8

[stress]    13s |  164048 KB |    124705 |      1948 | 8

[stress]    14s |  176794 KB |    134376 |      2099 | 8

[stress]    15s |  189770 KB |    144202 |      2253 | 8

[stress]    16s |  202344 KB |    153775 |      2402 | 8

[stress]    17s |  215006 KB |    163382 |      2552 | 8

[stress]    18s |  227536 KB |    172925 |      2701 | 8

[stress]    19s |  240256 KB |    182565 |      2852 | 8

[stress]    20s |  253032 KB |    192312 |      3004 | 8



*** HARD LOCKUP DIE CPU EVERYTHINK IN SMOKE ****

Sometime,s i not need to even transfer big amount, i can just run it + ctrl, and repeat it few times and if i lucky (or not lucky) can lockup right after 5-6 ctrl+c. So it's not amount of the transfered data or the time, it just happens anytime.

Edited by kas1e on 2026/3/19 4:16:10

Join us to improve dopus5!
AmigaOS4 on youtube

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

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