Maybe you can add a workaround like a FORCE Option for NetShutdown. So it will shut down Roadshow after the timeout. It may result in an unstable system but could help in some cases. If you document this it should be enough. The user is then responsible if he uses the FORCE option. I guess it would be better at least then the user tries to use Scout/XOpa or whatever tool to kill Roadshow. Unfortunately, we have no resource management that would help.olsen wrote: ↑25.07.2022 - 11:40Sadly, there is no truly reliable way to shut down the Roadshow TCP/IP stack through the "NetShutdown" command. It may succeed but it may not succeed, for reasons which are hard to explain. Basically, "NetShutdown" asks every program currently using it nicely (under the circumstances) to stop doing so and waits for all of them to sign off. This is not always attainable because, for example, the original design of the AmiTCP TCP/IP stack did not plan for client software to listen to such requests. Quitting is not mandatory, it is "voluntary".
Navigation
«
«
«
Amiga Future
«
Community
«
Knowledge
«
Last Magazine
«
Service
«
Search
«
Social Media
«
Advertisement
«
Partnerlinks
Roadshow and WHDLoad
Support Roadshow
Re: Roadshow and WHDLoad
Re: Roadshow and WHDLoad
I am afraid there is no halfway house between the TCP/IP stack running and it not runningdaxb wrote: ↑26.07.2022 - 11:14Maybe you can add a workaround like a FORCE Option for NetShutdown. So it will shut down Roadshow after the timeout. It may result in an unstable system but could help in some cases. If you document this it should be enough. The user is then responsible if he uses the FORCE option. I guess it would be better at least then the user tries to use Scout/XOpa or whatever tool to kill Roadshow. Unfortunately, we have no resource management that would help.olsen wrote: ↑25.07.2022 - 11:40Sadly, there is no truly reliable way to shut down the Roadshow TCP/IP stack through the "NetShutdown" command. It may succeed but it may not succeed, for reasons which are hard to explain. Basically, "NetShutdown" asks every program currently using it nicely (under the circumstances) to stop doing so and waits for all of them to sign off. This is not always attainable because, for example, the original design of the AmiTCP TCP/IP stack did not plan for client software to listen to such requests. Quitting is not mandatory, it is "voluntary".
The design of AmiTCP never took into account that you might want to stop the TCP/IP stack without the willing cooperation of the programs which are still holding onto it and are expecting a specific well-defined behaviour.
Roadshow attempts to do as much as can be done without breaking the implied and explicit rules of the TCP/IP stack, how client software uses it, and how the network device drivers make use of it. In the end that may not be enough because of the unpredictability of the many moving parts involved.
For example, some network device drivers cannot be closed safely, even if all the currently queued I/O requests have been cancelled and taken out of service (Amiga device drivers tend to be a very mixed bag, which goes double for network device driver and in particular legacy drivers for legacy hardware which never received updates and bug fixes). Client code may still be executing TCP/IP kernel code, waiting for a condition change which will never arrive, but removing it by force from that queue may render the signal semaphore which polices access to kernel data inconsistent. Roadshow is chock full of such interlocking, concurrent operations and not just the TCP/IP kernel.
The "NetShutdown" command is limited to delivering safe and predictable outcomes. Either it succeeds or it fails at shutting down the network. If it fails, then this needs to be respected and handled accordingly. The only safe way to avoid not being able to shut down the network is not starting it in the first place and nothing I could do to the TCP/IP kernel code could change that.
Re: Roadshow and WHDLoad
Ok, I understand and back in the days when I used 56k modem I had noticed that sometimes MiamiaDX couldn't go off for some unknown reason. Further, I think it (FORCE option) wouldn't help in jjmarcos case. The WHDLoad options should help more.
jjmarcos you could try to find out what is the reason that stops Roadshow shutdown and then just avoid it. However, this might not be possible.
jjmarcos you could try to find out what is the reason that stops Roadshow shutdown and then just avoid it. However, this might not be possible.
Re: Roadshow and WHDLoad
Hello everyone!
I'm gonna reply to myself 2 years later
The thing is that I've been putting together yet another A1200, in this case with a PiStorm32 and a CM4 (it's freaking fast btw!)
I stumbled upon the same issue again. I thought that maybe it was related to the PCMCIA card I was using, so I got a Netgear that uses a different driver (cnet.device). Same behaviour I'm afraid, if the network is configured, I get a black screen launching WHDLoad games, even after running NetShutdown.
So, what is the solution? Well, besides running NetShutdown, I also run CardReset TICKS 50 from this Aminet package: https://aminet.net/package/util/boot/CardReset
The way that I have it configured, if it helps anyone else, is:
Roadshow starts on boot, S:user-startup calls S:network-startup
I have a drawer on my Workbench Screen with icons to launch AGS and TinyLauncher (WHDLoad games). Besides that, I have three scripts right there:
stop-network: I wanna play something, let's shutdown the network for real.
start-network: Useful when I have stopped the network to play something, but I want to get back online after playing. The timeout parameter is pretty handy if you configure the IP address via DHCP.
show-network-status
I do not run these scripts as pre or post WHDLoad tasks, I prefer to run them manually once I want to start playing or I have finished playing.
Also, I have a hardware PCMCIA bug reset fix (Rastport KA21B) in place, so I do not run on boot CardPatch or any other software solution for the normal operation of the network card.
In the end I ditched the Netgear and sticked to the 3com Etherlink III (3c589), way faster and reliable!
Hope it helps!
I'm gonna reply to myself 2 years later
The thing is that I've been putting together yet another A1200, in this case with a PiStorm32 and a CM4 (it's freaking fast btw!)
I stumbled upon the same issue again. I thought that maybe it was related to the PCMCIA card I was using, so I got a Netgear that uses a different driver (cnet.device). Same behaviour I'm afraid, if the network is configured, I get a black screen launching WHDLoad games, even after running NetShutdown.
So, what is the solution? Well, besides running NetShutdown, I also run CardReset TICKS 50 from this Aminet package: https://aminet.net/package/util/boot/CardReset
The way that I have it configured, if it helps anyone else, is:
Roadshow starts on boot, S:user-startup calls S:network-startup
I have a drawer on my Workbench Screen with icons to launch AGS and TinyLauncher (WHDLoad games). Besides that, I have three scripts right there:
stop-network: I wanna play something, let's shutdown the network for real.
Code: Select all
echo Stopping network services...
wait 1 sec
C:NetShutdown
wait 1 sec
C:CardReset TICKS 50
quit
Code: Select all
echo Starting network services...
AddNetInterface DEVS:NetInterfaces/~(#$.info) QUIET TIMEOUT=90
echo Done!
wait 1 sec
quit
Code: Select all
ShowNetStatus
wait 3 sec
quit
Also, I have a hardware PCMCIA bug reset fix (Rastport KA21B) in place, so I do not run on boot CardPatch or any other software solution for the normal operation of the network card.
In the end I ditched the Netgear and sticked to the 3com Etherlink III (3c589), way faster and reliable!
Hope it helps!
Re: Roadshow and WHDLoad
Here I'm using Roadie to switch off the net before starting a whdload, afterwards it's just clicking Connect to go online again. While it's not an "automatic" solution it's convenient enough for me to not be bothered by it
https://aminet.net/package/comm/net/Roadie
https://aminet.net/package/comm/net/Roadie
Re: Roadshow and WHDLoad
Why do you bump an old thread?yevnovikova wrote: ↑03.01.2024 - 15:35 Gute Skripte, und für solche Dinge muss man heutzutage nicht einmal mehr Fullstack-Entwickler einstellen
Jump to
- Amiga Future
- ↳ Internes
- ↳ Termine
- Computer
- ↳ Amiga und Kompatible Allgemein
- ↳ Amiga und Kompatible Spiele
- ↳ Amiga und Kompatible Hardware
- ↳ Amiga Programmieren
- ↳ Amiga Emulation
- ↳ Amiga General Chat english
- ↳ Andere Systeme
- Sonstiges
- ↳ Kleinanzeigen - Classifieds
- ↳ OffTopic
- APC&TCP
- ↳ APC&TCP-News
- ↳ APC&TCP-Support
- ↳ CygnusEd Support
- ↳ DigiBooster Support
- ↳ Roadshow Support