Classic Mac Hardware (Troubleshooting, Upgrading, & Modifying) > Mac CPU Upgrades

Debugging the Power Mac 9600 G4

(1/5) > >>

GorfTheChosen:
So I've mentioned this system in a couple of other threads.

The short version of the backstory is that I acquired this unit back in the day as a new (at the time) unit ... so one-owner (IIRC) It was near or maybe even past EOL and its discontinuation date at the time I picked it up.

Think I was probably holding off on moving to a G3 because of software compatibility issues and because for what I was doing (motion graphics and animation) the G4 was on the horizon and would have offered some further advantages with Altivec over the G3 (or so I thought) while allowing developers to further sort out any issues with their code.

If I recall correctly it had a fairly short useful life before I moved up to a dual processor Gigabit Ethernet model.

After that the 9600 was mostly relegated to back up machine status and a node on the render farm.

At some point or another in there I picked up a Sonnet G4/450 upgrade card for it, added additional RAM (probably from other machines of its generation), etc.

So the RAM has been a bit of a hodgepodge ... some big DIMMs with lots of low density chips (pulled at the present time) combined with the better stuff (fewer, higher density chips) ... but its what I had.

Trying to get the unit back up running and functional has been kind of a nightmare, due to how unstable it has been. Some of that has possibly been due to 3rd party SCSI cards I had installed (now removed) ... will save troublehshooting those until after I get the machine running stably.

After tracking down some of the problems down to a pair of DIMMS that were returning lots of errors when tested, I'm now down to eight 128MB DIMMS which all use fewer, high density chips.

As covered in previous posts:

1. The machine is booting and running with a variety of different PCI cards installed (but no SCSI cards)

2. The machine seems to currently freeze/lock up doing two things: trying to write to a CD or DVD using Toast 5.2.3 (although this was occurring with Toast 5.2 as well) using either a Sony CD-RW (SCSI) or a Pioneer DVR-106D (Firewire), and using Fetch to transfer large files (several hundred MB) across the network @ 100Mb speeds.

I'm using TestMem, which was written by Mark Granger I believe (of EIAS fame), to test the installed memory. Basically what it does is repeatedly test memory in passes until you kill it. It does this by generating a random seed number and then writing that to all (unused) installed memory and then reporting each memory address where the value that was actually read back was different than the value that should have been written.

Each miss counts as an error, and the values (original and result) and the memory location are reported in a form something like:

"At address xxx, a value of yyy was reported, and it should have been zzz."

In the initial testing the bad RAM was returning many, many errors (easily in the hundreds)

After better than 12+ hour run last night, on around 1GB of RAM, the error count was 12 when I checked it a couple of hours ago.
 
That isn't "too bad" (probably less than 1 per hour) ... but it's not zero either.

Here's my question, owing to my own ignorance and lack of technical expertise:

Can the addresses where the errors occurred be translated into a location (memory slot A5 for example) where the suspect DIMM likely is ... or does the way the OS software handle memory management preclude that ?

Here are some of the address locations that were reported as having errors during this last overnight run:

$2BF4BC94
$2783DA5C
$2783DA5C
$2BF3DC94
$2BEFAC94
$2BE79C94
$2783DA5C
$2BEEEC94

I couldn't get the rest (of the 12 errors reported) because the machine is basically unresponsive while its testing (window is not scrollable) and the rest of the addresses had scrolled off the screen at the top. (The only option you get is to command-period it to kill it, at which point the window disappears - I should probably check and see if it creates a log file in the prefs folder or something)

The reason I'm asking is that I'd prefer not to spend possibly the next 4 or 5 days trying to track down which DIMM is actually bad if I don't need to.

Thanks in advance for any advice or insights.

FdB:
Just for giggles:
https://www.ebay.com/i/352749484991?chn=ps&norover=1&mkevt=1&mkrid=711-117182-37290-0&mkcid=2&itemid=352749484991&targetid=869553625409&device=c&mktype=pla&googleloc=9023890&poi=&campaignid=9241642556&mkgroupid=89053486690&rlsatarget=pla-869553625409&abcId=1141156&merchantid=6296724&gclid=EAIaIQobChMIuuWR-qvu5wIVUr7ACh1eVwdCEAQYAiABEgKKC_D_BwE

At what cost... new RAM? ;)

GorfTheChosen:

--- Quote from: FdB on February 25, 2020, 08:12:40 PM ---Just for giggles:
https://www.ebay.com/i/352749484991?chn=ps&norover=1&mkevt=1&mkrid=711-117182-37290-0&mkcid=2&itemid=352749484991&targetid=869553625409&device=c&mktype=pla&googleloc=9023890&poi=&campaignid=9241642556&mkgroupid=89053486690&rlsatarget=pla-869553625409&abcId=1141156&merchantid=6296724&gclid=EAIaIQobChMIuuWR-qvu5wIVUr7ACh1eVwdCEAQYAiABEgKKC_D_BwE
--- End quote ---

Yeah ... I saw that while scoping out eBay a while back and then saw it referred to on another thread here.

He's clearly an optimist ...  ;D


--- Quote from: FdB on February 25, 2020, 08:12:40 PM ---At what cost... new RAM? ;)

--- End quote ---

Can you even buy NEW RAM for these machines today ?

 ::)

GorfTheChosen:
Truth be told, the likelihood is very high that this machine will become "surplus to my needs" in fairly short order.

At that time I hope I can find it a good home with someone who has a need for it and can utilize the slots.

Right now, I'm just enjoying the challenge of trying to debug it and get it running stably ...  :)

FdB:
Well... maybe not brand new RAM. (Seems I've a few sticks leftover 'round here.)
And if it really does come down to finding it a home... check here with Syntho.

(Read his thread / book covering his exploits with the 9600.)
http://macos9lives.com/smforum/index.php/topic,2656.msg15938.html#msg15938

Navigation

[0] Message Index

[#] Next page

Go to full version