MacOS Interchangeable From 1 PM to Another
If a drive in a Sawtooth gets erased (zeroed) and a fresh install of Leopard will that same drive (system) function without difficulty in a MDD?
Just curious (troubleshooting).
Apple Event: May 7th at 7 am PT
If a drive in a Sawtooth gets erased (zeroed) and a fresh install of Leopard will that same drive (system) function without difficulty in a MDD?
Just curious (troubleshooting).
Yes, assuming it's jumpered correctly for where it is on the cable, MDDs generally use Cable Select, Earlier G4s used Master, Slave, or Single depending on make of drive.
Yes, assuming it's jumpered correctly for where it is on the cable, MDDs generally use Cable Select, Earlier G4s used Master, Slave, or Single depending on make of drive.
Thank you BDAqua.
I took it from the MDD while I worked on the PSU and installed it (the drive) into the Sawtooth. I kept the Sawtooth boot drive cabled to the grey terminal and the MDD drive to the black terminal. Seemed to work just fine. I zeroed and installed a fresh 10.5 on the MDD drive while still in the Sawtooth. Then when the PSU work was done, moved the drive back to the MDD in to it's original spot.
It's working but slooooowly. I ran DW on the drive and surpised to find it 30+% out of order. Surprised because it had just been zeroed. Thought perphaps DWs findings reflected my OP.
Another quick question. The MDD is just about 'stock' at this point. Aside from extra ram and an upgraded cpu heatsink there are no extras. Equally nothing installed beyond 10.5.8 - no third party software. I have a small digital thermometer I have placed on top of the optical drive carrier, right in front of the PSU air intake and atm it's reading 118ºF ..... does that sound excessive?
Hi-
Excessive? Not for a MDD.
The area above the optical drive is a hot spot, so higher than ambient temps are to be expected.
What you are seeing there is what has prompted many a modder to add a "blow hole" fan on top or in front of the case.
This is an example of one of those:
http://www.s155158671.websitehome.co.uk/finalmddaqua-mac.html
>I ran DW on the drive and surpised to find it 30+% out of order.
That's normal with a fresh install, the Installer makes many temporary files during installation.
>I have placed on top of the optical drive carrier, right in front of the PSU air intake and atm it's reading 118ºF ..... does that sound excessive?
Not too bad for an MDD, which are the absolute worst for heat buildup, mostly due to the fact that it takes air in at the top & exhausts it at the bottom... like heat sinks or something! 😉
Some people have had success using PCI slot coolers, I did not though.
>It's working but slooooowly.
If you have 2 drives on an IDE cable, both tend to operate at the speed of the slowest drive.
Thanks japamac. I haven't added any of the Chud or Nap scripts back in yet. Just finished the PSU and finding things sluggish so ferreting things out before I put the MDD back in service. Like I said it's very nearly in stock condition .... kinda nostalgic - lol.
That is some serious cooling - looks a little like a hotrod.
Thinking I may run rember to check the ram - one of two things that aren't stock.
BDAqua - just one drive, the original that came with it. I have most of the cooling mods (new fans etc) including a pci slot fan 'somewhere', never figured it helped much.
Checking RAM is fine, but don't forget that Spotlight is running indexing services in the background.
Until the drive is fully indexed, expect up to 80% CPU usage "in the background".
Set the drive to Privacy in Spotlight preferences to test and see if that is the case.
You can also look in Activity Monitor for "mdworker" processes.
Best I can tell mdworker isn't too busy, maybe just 'keeping up'. Safari on the other hand was any where from 10 - 25 (% I assume) until just now and it's back off to .x%. Wonder what Safari was up to.
Safari in Leopard can be a real CPU hog.
I'm using v5.0.3, and Safari uses at a minimum 5%, but usually 25% or more.
Just moving the cursor across the page can get 80% spikes......
If I forget that have a window with Flash ads running on it behind what I'm looking at, forget any performance.
Back to Spotlight, along with mdworker, the root process mds is very busy when indexing.
The MDD has been running off and on a few hours today (maybe 3 or 4) and am thinking maybe any indexing could be done - it's just the system at this point. mdworker wasn't even registering a % yet was btwn 5th and 10th on the list.
Ran the rember memory test and the computer went to sleep and would not awaken. Had to shut down manually and restart. On boot I get the grey screen and gear for about 2 mins then the blue screen (no gear) for 4 mins before the desktop appears.
If it's not the memory modules then I'm thinking the hard drive itself - there's no where else to point the finger. Re-running the memory test now, checked the memory in system profiler and profiler reports all there and ok.
The Rember memory test completed. I just ran the minimal default test. Wondering what the FAILURE at the bottom of the report means:
Memtest version 4.22 (32-bit)
Copyright (C) 2004 Charles Cazabon
Copyright (C) 2004-2008 Tony Scaminaci (Macintosh port)
Licensed under the GNU General Public License version 2 only
Mac OS X 10.5.8 (9L31a) running in multiuser mode
Memory Page Size: 4096
System has 2 PPC processors(s) with Altivec
Requested memory: 1714MB (1797931008 bytes)
Available memory: 1714MB (1797931008 bytes)
Allocated memory: 1714MB (1797931008 bytes) at local address 0x01000000
Attempting memory lock... locked successfully
Partitioning memory into 2 comparison buffers...
Buffer A: 857MB (898965504 bytes) starts at local address 0x01000000
Buffer B: 857MB (898965504 bytes) starts at local address 0x36952000
Running 1 test sequence... (CTRL-C to quit)
Test sequence 1 of 1:
Running tests on full 1714MB region...
Stuck Address : setting 1 of 16ok
Linear PRN : ok
Running comparison tests using 857MB buffers...
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV :
FAILURE! Data mismatch at local BUFA address 0x0b2202b0, BUFB address 0x40b722b0
BUFA Data: 0x00800001, BUFB Data: 0x00000001
I think the report would indicate a bad chip/DIMM.
The test splits the allocated memory into two banks and stuffs them with the same data.
It looks like there are 4 address errors...
This would raise Cain with any data handling, and would explain why the drive needed repair so soon after install; the RAM "helped" write corrupt data.
Ok - thank you for that. 2 questions ....
1. How do I determine the bad ram - there are 4 ram modules, is it trial and error pulling one at a time?
2. Would the bad ram contribute to the long boot sequence? I ran DU to see what it said, reported the disk is ok. I installed another drive that has 10.5 on it (a 20G drive from the Sawtooth that is meant as a backup boot drive) and had identical boot sequence as the 80G currently in the MDD. From grey screen and gear to desktop is almost exactly 4 mins.
Restarts are interesting as well. Selecting 'restart' and it sounds like the computer shuts down instead. Then 30 or 40 seconds later the boot sequence starts.
/shrug
Testing ALL RAM is the way to get the memory test to tell you which DIMM is bad.
Running the AHT or ASD will also tell you (if the error is caught).
Otherwise, pull all but one, test, add, test, etc.
If you need the AHT/ASD, you might email me for direction.
Bad RAM will definitely contribute to a long boot sequence, as will data errors on a drive due to corrupt data being written to the drive.
Running another Rember test now - this time minus one stick. Email is on it's way.
MacOS Interchangeable From 1 PM to Another