Guys, this has been a reported problem for a long time, yet nobody has ever been able to provide any feedback on it.
In all my testing, which has involved a lot of reordering of inits and rebooting with different memory configurations over the years, I've personally never had the problem. As you know "Marinetti does so much memory moving, if anything in the system is a little flakey,
using Marinetti will probably cause you to see it."
However, there are a number of things which would be helpful in tracking down such a problem, if it were in Marinetti. All of these must be performed in the same boot that you get the problem. So
there's no point for example getting a non-ESTABLISHED problem, then rebooting so you can get the error table. I need the table at the
time of the problem.
1. $0A36 _TCPIPGetErrorTable - Send me a copy of the error table.
2. $1E36 _TCPIPGetTuningTable - Send me a copy of the tuning table.
3. $3936 _TCPIPGetDP - Send me a copy of the Marinetti direct page.
This call is probably not documented in the user manual, but I think it is in the TCIPIPX macros. It simply returns a word address of the Marinetti direct page.
4. $3E36 _TCPIPGetUserRecord - Again, probably not documented in the user manual, but does work. I THINK you give it an IPID and it returns the longword address of the IPID's record. Each record is inside a handle, so do a FindHandle and GetHandleSize to find the length of the record. I need this for the IPID which is having the
problem, so it needs to be still logged in.
You can do all of these in Nifty List or Pixie. We should probably put an app together which does it automatically, but for now, this should do. Dump everything, include the exact Marinetti version
number you're using, and the exact link layer module and version you're using and email 'em over.
Andrew, might be a good idea to put this info on MOSP somewhere.
Regards,
Richard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This problem absolutely exists, but I agree there's no proof it's not a system software problem somewhere. We do need to figure out what's
causing it so we can try to work around it. It makes debugging Marinetti apps almost impossible. Half the time I was testing gsAIM was spent shuffling extensions and DAs in and out of my system trying to make combinations that would actually work.
We should seriously look at writing an app like Richard suggested; something that starts up Marinetti, attempts a connection, and saves
all the relevant logging info so we can send helpful problem reports in.
> Can someone at least figure out *why* reordering or removing
> extensions is fixing this?
How long is a piece of string?
How easy is it to find a needle in a very large haystack?
It could be one of three or more things:
1. There is a memory bug in Marinetti.
2. There is a memory bug in one of the extensions.
3. There is a bug in the memory Manager of OS 6.0.1.
Marinetti moves hunks of data around in memory constantly, as it handles a lot of data passing through it in both directions. Quite apart from a possible bug in the way Marinetti is handling these
memory moves, if an application, or an extension, or the memory manager itself is flaky, then havoc can ensue.
The only thing we know is that something is causing a problem with memory, but we do not know which. Nobody has exactly the same setup
with their IIgs, so it is extremely difficult to track this problem down.
I am sure Richard would be the first to give a slab of XXXX to whoever manages to track the problem down. He has extensively checked out the Marinetti code, and cannot see anywhere that Marinetti itself is doing anything wrong. The unknowns are the Memory manager itself, and the Extensions and Inits you may have on your system...
Ewen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some people have reported problems with establishing a connection to services with Marinetti applications.
This issue can sometimes be resolved by reordering the load order of extensions in your System.Setup folder or removing one/some.
Personally, I use a very minimal system for testing. This can be achieved quite easily by setting up a dedicated testing partition.
Guys, this has been a reported problem for a long time, yet nobody has ever been able to provide any feedback on it.
In all my testing, which has involved a lot of reordering of inits and rebooting with different memory configurations over the years, I've personally never had the problem. As you know "Marinetti does so much memory moving, if anything in the system is a little flakey,
using Marinetti will probably cause you to see it."
However, there are a number of things which would be helpful in tracking down such a problem, if it were in Marinetti. All of these must be performed in the same boot that you get the problem. So
there's no point for example getting a non-ESTABLISHED problem, then rebooting so you can get the error table. I need the table at the
time of the problem.
1. $0A36 _TCPIPGetErrorTable - Send me a copy of the error table.
2. $1E36 _TCPIPGetTuningTable - Send me a copy of the tuning table.
3. $3936 _TCPIPGetDP - Send me a copy of the Marinetti direct page.
This call is probably not documented in the user manual, but I think it is in the TCIPIPX macros. It simply returns a word address of the Marinetti direct page.
4. $3E36 _TCPIPGetUserRecord - Again, probably not documented in the user manual, but does work. I THINK you give it an IPID and it returns the longword address of the IPID's record. Each record is inside a handle, so do a FindHandle and GetHandleSize to find the length of the record. I need this for the IPID which is having the
problem, so it needs to be still logged in.
You can do all of these in Nifty List or Pixie. We should probably put an app together which does it automatically, but for now, this should do. Dump everything, include the exact Marinetti version
number you're using, and the exact link layer module and version you're using and email 'em over.
Andrew, might be a good idea to put this info on MOSP somewhere.
Regards,
Richard
This problem absolutely exists, but I agree there's no proof it's not a system software problem somewhere. We do need to figure out what's
causing it so we can try to work around it. It makes debugging Marinetti apps almost impossible. Half the time I was testing gsAIM was spent shuffling extensions and DAs in and out of my system trying to make combinations that would actually work.
We should seriously look at writing an app like Richard suggested; something that starts up Marinetti, attempts a connection, and saves
all the relevant logging info so we can send helpful problem reports in.
--
Eric Shepherd
Owner
Syndicomm
http://www.syndicomm.com
> Can someone at least figure out *why* reordering or removing
> extensions is fixing this?
How long is a piece of string?
How easy is it to find a needle in a very large haystack?
It could be one of three or more things:
1. There is a memory bug in Marinetti.
2. There is a memory bug in one of the extensions.
3. There is a bug in the memory Manager of OS 6.0.1.
Marinetti moves hunks of data around in memory constantly, as it handles a lot of data passing through it in both directions. Quite apart from a possible bug in the way Marinetti is handling these
memory moves, if an application, or an extension, or the memory manager itself is flaky, then havoc can ensue.
The only thing we know is that something is causing a problem with memory, but we do not know which. Nobody has exactly the same setup
with their IIgs, so it is extremely difficult to track this problem down.
I am sure Richard would be the first to give a slab of XXXX to whoever manages to track the problem down. He has extensively checked out the Marinetti code, and cannot see anywhere that Marinetti itself is doing anything wrong. The unknowns are the Memory manager itself, and the Extensions and Inits you may have on your system...
Ewen