MDD 1.42GHz CPU Board Suddenly Lost 1GHz (False Alarm)

helmetguy

New Tinkerer
Apr 1, 2024
24
24
3
This is a new one:

Picture 2.png


This dual 1.42GHz CPU board has suddenly turned into a dual 417MHz board.

My immediate thought is that something has happened to the resistors that set the FSB multiplier, which has caused it to go from 8.5x to 2.5x. The resistors are still present, on the correct pads, and I can't visibly (with a video microscope) see anything lifted off the board. I'm going to reflow the resistors anyway.

The machine has had a logic board swap which could also be related to the cause of this. If the reflow doesn't fix the issue, I should be able to get the old board back in the weekend to test.

This issue is occurring with a clean install of Tiger, PMU reset, PRAM reset and a fully charged PRAM battery.

Has anyone else had 71% of their Mac's CPU speed suddenly vanish? :ROFLMAO:😭 Any input would be greatly appreciated.
 
  • Wow
Reactions: eric

helmetguy

New Tinkerer
Apr 1, 2024
24
24
3
Well this is embarrassing. It's a good thing that I thought to run a benchmark before messing with the CPU board.

Here's the machine's Geekbench 2.20 result:

Code:
Benchmark Summary
  Integer Score              1579 ||||||||||||||||||||
  Floating Point Score       1368 ||||||||||||||||||
  Memory Score                557 |||||||
  Stream Score                384 |||||

  Geekbench Score            1181 |||||||||||||||

A dual 1.42GHz should get around a 1200 Geekbench 2 score, according to EveryMac.

So OSX (and OS9, and AHT) is fibbing about the CPU speed.
 

helmetguy

New Tinkerer
Apr 1, 2024
24
24
3
There was a similar theme on macos9lives, and it seems to have ended badly. 😵
This thread has some really useful info in it, thanks for sharing!

The table that was linked, showing the resistor configs on the CPU board that set the multiplier, is useful in particular:

Screenshot 2024-04-23 at 11.05.20.png


It turns out that the multiplier config for 417MHz and 1.42GHz is the same!!! Further proof that reflowing the resistors would've been a waste of time.

The question remains as to why OSX has interpreted CPU speed being 417MHz after a logic board swap. Although I'm not too fussed on finding an answer - it is definitely running at 1.42GHz, judging by the Geekbench 2.20 result, and judging by OSX not being painfully slow.
 

ifrit05

New Tinkerer
Apr 19, 2024
12
9
3
If the CPU speed reporting is bothering you (and you for-sure know nothing else is wrong with your hardware) you can create a script for OpenFirmware to spoof CPU speed that runs automatically on every boot.

Create a txt file on the root of your boot partition. Name does not matter, for this example we will use "speedfix.txt". Paste this inside:

Code:
\ comment
cr

dev /cpus/PowerPC,G4@0
d# 1417000000 encode-int " clock-frequency" property
dev /cpus/PowerPC,G4@1
d# 1417000000 encode-int " clock-frequency" property

boot hd:,\\:tbxi

Reboot into OpenFirmware and run this command: setenv boot-device hd:\speedfix.txt then reset-all to reboot.

This will instruct OpenFirmware to "boot" using the speedfix.txt instead of the HD, but inside speedfix.txt it tells OF to boot the HD, after running the commands to spoof the CPU speed.

Keep in mind if you reset your PRAM you will have to run the setenv command again for it to run the script.
 
Last edited:

helmetguy

New Tinkerer
Apr 1, 2024
24
24
3
If the CPU speed reporting is bothering you (and you for-sure know nothing else is wrong with your hardware) you can create a script for OpenFirmware to spoof CPU speed that runs automatically on every boot.

Create a txt file on the root of your boot partition. Name does not matter, for this example we will use "speedfix.txt". Paste this inside:

Code:
\ comment
cr

dev /cpus/PowerPC,G4@0
d# 1417000000 encode-int " clock-frequency" property
dev /cpus/PowerPC,G4@1
d# 1417000000 encode-int " clock-frequency" property

boot hd:,\\:tbxi

Reboot into OpenFirmware and run this command: setenv boot-device hd:\speedfix.txt then reset-all to reboot.

This will instruct OpenFirmware to "boot" using the speedfix.txt instead of the HD, but inside speedfix.txt it tells OF to boot the HD, after running the commands to spoof the CPU speed.

Keep in mind if you reset your PRAM you will have to run the setenv command again for it to run the script.
Brilliant! Many thanks for this.

Although I did update the boot ROM to 4.4.8f2, thinking it might fix the odd CPU speed reporting:

Screenshot 2024-04-25 at 12.19.10 AM.png


It did :D