AROS ABIv0 20201110 Development

[Devlin]

sanautil -d rtl8169.device status

Other than this command, i've tried all the rest. Even down to trying different versions of the device I could find.

I'll come back after i've tried that one, though.

[deadwood]

deadwood, I tested your latest Bulit, and found that the Pointer Prefs does not work, basically it does not allow to set and save the Pointer !

The latest build tested is "pc-i386-20230702-163909.tar.gz"

With Build "AROS-20201110-2-pc-i386-boot-iso" the Pointer Prefs worked fine !

Thanks, I'll investigate.

[Amiwell]

sorry this thread is about system updates abiv0 open another thread to talk about more sorry again

[AMIGASYSTEM]

Salvo we are discussing AROS ABIv0 " by "deadwood, which is an advance update of " AROS ABIv0 20201110", which includes some important fixes see "BoingIconBar", which can now be closed by a Shell, keymap.library, kms.library and more !
This reporting is important otherwise in the next core you would have this problem !

--- Italiano ----

Salvo stiamo discutendo  di AROS ABIv0 " di "deadwood, che è un anticipo di aggiornamento di " AROS ABIv0 20201110", che include alcuni fix importanti vedi "BoingIconBar", che ora può essere chiuso da una Shell, keymap.library, kms.library e altro ancora !
Questa segnalazione è importante altrimenti nel prossimo core avresti questo problema !

[Amiwell]

I was referring to the other discussions not yours

[Devlin]

I'm using the AROS 20201110-2 iso as found on axrt.org (which is why i'm posting here)

I can't find sanautil, but there has been a development:

I got the network going, without messing with any AROS settings at all, in fully-automatic.

I had feared hardware failure, so I booted up a haiku liveusb i had laying around to make sure the network wasn't busted.
Networking in haiku worked fine, so i warm-rebooted into AROS and the network was just working no faff no fuss.

THEN - I did a cold reboot and the network never seems to actually *start up*(i.e. no activity lights on the eth port) at any point if AROS is the only thing set up to start, hence the bizarre failures.
to temporarily mitigate this (though it's kinda serious and imho should be fixed) on my box I've set the boot priority to PXE(LAN booting) first, and then manually cancel PXE booting, so it "starts up" the network port ready for AROS.

[AMIGASYSTEM]

@Devlin

If you are looking for SANAUtil, you can find it on AROS One x86, path Extras\DOS-Tools

If the Network works "Only" after a hot reboot, it may be that no save in the "Env-Archive\AROSTCP" was made, but only a save in the ENV

You could solve it by copying the "AROSTCP" folder from ENV: to Env-Archive

Also make sure that in "Network Prefs" you have checked "Start network during system boot"

[Devlin]

@Devlin

If you are looking for SANAUtil, you can find it on AROS One x86, path Extras\DOS-Tools

If the Network works "Only" after a hot reboot, it may be that no save in the "Env-Archive\AROSTCP" was made, but only a save in the ENV

You could solve it by copying the "AROSTCP" folder from ENV: to Env-Archive

Also make sure that in "Network Prefs" you have checked "Start network during system boot"

1: Noted.

2/3: There's definitely stuff in ENVARC: relating to arostcp

3: It definitely is set.

[AMIGASYSTEM]

Yes AROSTCP is present in Env-Archive, but the content might be different, "when the connection works", delete the folder from AROSTCP from Env-Archive, and exstitute it with that of ENV:

AROS like Amiga, after a warm reboot reads the preferences from ENV, while after a Cold reboot, the preferences are taken from Env-Archive.

I use this procedure for the DVDLive and PendriveLive of my AROS One Distribution, for all those who use AROS One on a VM, this way the connection is active and functional even from the DVD Live or Pendrive Live.

You can do this test, when the network works, delete the data from ENV, and you will notice that the network no longer works, because I will read the data from Env-Archive.

[Devlin]

Yes AROSTCP is present in Env-Archive, but the content might be different, "when the connection works", delete the folder from AROSTCP from Env-Archive, and exstitute it with that of ENV:

AROS like Amiga, after a warm reboot reads the preferences from ENV, while after a Cold reboot, the preferences are taken from Env-Archive.

I use this procedure for the DVDLive and PendriveLive of my AROS One Distribution, for all those who use AROS One on a VM, this way the connection is active and functional even from the DVD Live or Pendrive Live.

You can do this test, when the network works, delete the data from ENV, and you will notice that the network no longer works, because I will read the data from Env-Archive.

It's nothing to do with the config, though I did try your suggestion, nothing changed. I think that part is, as previously thought, just fine.

From a cold boot, and AROS being the first boot option - the network "card" is not told to wake up before it attempts to connect to the internet, to which it silently fails and causes my issue.

Whereas, if like my "workaround", the PXE network boot starts first, the network card is sent whatever "wake up" command it needs to start, I cancel the network boot, and then AROS boots up and it's all "hey i'm awake, internet a go go!"

ed: this was posted from said AROS box, with working network as enabled by my "workaround"

[deadwood]

It's a long shot, but maybe you have some sort of power saving mode set in BIOS for network card that makes it "suspend" by default and your workaround wakes it.

[AMIGASYSTEM]

Ok Devlin, out of curiosity have you tried a clean Bulid, or replacing the "System/Network/AROSTCP" folder as well ?

[Devlin]

Ok Devlin, out of curiosity have you tried a clean Bulid, or replacing the "System/Network/AROSTCP" folder as well ?

Yep, done both. I don't think AROSTCP is specifically the problem here, as it is configured correctly and is known to work.

It's a long shot, but maybe you have some sort of power saving mode set in BIOS for network card that makes it "suspend" by default and your workaround wakes it.

Even the way it is, other OSes(in my case, haiku) will "wake" the network up (which is how i discovered it was doing this in the first place).
I think that it could be a driver thing? like, perhaps the driver expects the network card to be awake when it initialises, and because it can *see* it, doesn't fail if it's asleep?

[ntromans]

Apologies if you have already tried this, bue have you tried not starting netwoork automatically at boot but starting it manually via 'startnet'? One thing you might also try - issue startnet, stopnet and then startnet again; for me this has helped with a reluctant internet connection, albeit for wifi rather than ethernet.

Cheers,
Nigel.

[AMIGASYSTEM]

Apologies if you have already tried this, bue have you tried not starting netwoork automatically at boot but starting it manually via 'startnet'? One thing you might also try - issue startnet, stopnet and then startnet again; for me this has helped with a reluctant internet connection, albeit for wifi rather than ethernet.

Cheers,
Nigel.

Great idea I used it some time ago for a partially functioning Wifi Sheda, the "startnet" command can be inserted at the end of the User-startup, possibly also the double command startnet, stopnet, startnet.