Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: AndyFC on March 27, 2022, 04:50:17 PM
-
I've had a very stable system for years but recently I've been getting more crashes (prompt in WB error 80000004 and then when I reboot I get the red software failure box). I've scanned with VirusZ and no issues, and used the PFS tools to check the drive which is ok.
One memtest app from Aminet (memtest by Fernando Martinez) gave errors straight away but another (memtest by Custom Services ) didn't pick up any errors.
I've not applied any patches recently. The last major one was 3.2.1 but it was stable after that. However I have been running some more taxing games like Doom, Wolfenstein etc.
I can always get to WB. Today I got a crash in Ibrowse which was the first app I ran after MiamiDX. After a reboot it ran fine. Other times it happens after I've run different apps for a while. Often it doesn't happen at all.
Any suggestions for good test apps would be welcome.
-
This sounds like a power supply issue. Got another one you can try?
-
I have a tower and ATX PSU and it's rigged up so I can do a simple swap out. It's an idea though...it wasn't unstable until I moved my miggy and the connector back into the mobo came loose.
Earlier this eve it ran for ages and I burnt 2 CDs without any issue.
-
I've used Test Program from Aminet this afternoon and it consistently picks up errors in FastRam, so a relief it's not something on the main board and hopefully it can be resolved by cleaning the SIMM contacts (at worst replacing the SIMM).
Update: I think it's software related. If I boot from the TestProg floppy there are no errors. If I boot from HD (no power cycle, just reset) run the app from Floppy in WB, I get errors in the last MB of the FastRam test. Another reset and boot from Floppy again and the errors go away. I'm just doing a soak test now.
-
It turns out the Memory test was a false indicator (I've not found out which patch results in the memory test showing errors). I have 3 devices on an unbuffered IDE interface and the cables were just a bit too long. I've used shorter, higher quality cables and it seems much more stable.
I realised the common factor in the crashes was a lot of HD activity, not CPU or memory intensive tasks.
-
Good diagnostic work! I hope that solves it for you and that this is a case study for anyone else with similar issues.
-
Interesting indeed. Just for the record, is this A4000 we are talking about? I mean, I get guru every cold boot on mine, but can't figure out what started this. I might try different IDE cable for sure. Thanks!
-
I have an A1200. The A4000 has a buffered IDE interface but if the cable cable is faulty or too long it might still result in errors.
Something else you could try is edit your startup sequence to wait for after each significant command. Echo a comment to the screen too and that will help show where the crash happens.
So if you have e.g SETPATCH as a line add
Echo "SETPATCH ran ok"
Wait 1
-
From 2015:
To enable tracing, use the following command in the shell:
set interactive on
If this is put top in a shell script, for example into the startup-sequence (with an editor of your choice), the shell will prompt you for each command it is going to be executed. If you press RETURN, the shell will run the command. If you press N or DEL, the shell will skip over it. If you press ESC, the shell will abort tracing and execute the rest of the script without bothering you further. If you press Control+D, the script will be aborted.