Hi Alastair, If you are now experiencing Kernel Panics and because you also mentioned you had run Memtest and it reported many errors, that your RAM (Memory) ‘could’ be the problem. This is not conclusive as there are other things that can cause Kernel Panics. If you have run memtest before I imagine you have already read all the documentation regarding running memtest.
When you ran Memtest, did you run it in ‘Single-User Mode’? In this mode, nearly all of the installed ram can be tested whereas under the full OS, a considerable portion of memory is tied up by OS X processes and the Quartz window manager. Running memtest in single-user mode maximizes the effectiveness of the memory test. To boot into single-user mode, hold down the "Command" and "S" keys during startup. You will be automatically logged in as the user root with a minimal command line environment. The login directory for the root account is "/" which is the top-level directory of the boot volume. Assuming that the memtest folder resides in your Applications folder, a typical invocation of memtest would be the following: > /Applications/memtest/memtest all 3 -L <RETURN> ( <RETURN> means press > the Return key) This would run three passes of the test suite, testing all available free memory. The "-L" switch instructs memtest to save the transcript of the run to a file named "memtest.log" within the working directory from which you invoked memtest (also known as the current working directory). Under the full OS, launching a terminal window sets the working directory to /Users/login_name where login_name is the account name you logged in with. Note that when running in single-user mode, you are automatically logged in as the "root" user so the default current working directory is /private/var/root. The main thing to remember is that the memtest.log file is always saved in the current working directory which is the same thing as the login directory unless the user manually changes to a different working directory. Alternatively, you can cd into the memtest folder and run the program using the command > ./memtest all 3 -L <RETURN> (Don't forget the period before the forward > slash!) Best to run at least 3 to 5 passes to obtain the best test coverage of marginal or intermittently failing DIMMs. To test less than all of the available free memory, replace the all option with the number of megabytes to test (e.g. 10, 100, 512, etc). The number entered is assumed to be in MB. For example, the command, > /Applications/memtest/memtest 1150 3 -L <RETURN> will test 1150 MB of the installed memory assuming this much is available for testing. TIPS FOR ISOLATING DEFECTIVE DIMMS Memtest currently does not have the ability to isolate which DIMM or DIMMs are marginal or defective when the test results report a failure. This feature is planned for a future release. For now, the best way to isolate the offending DIMM(s) is to use a binary search methodology. This is an algorithm which is popular in many sorting routines and can lead to the discovery of a defective DIMM in a minimal number of swap/test sequences. When memtest reports one or more failures, the first step in isolating the offending DIMMs is to remove half of them and then rerun memtest. If there are no failures, then the suspect DIMMs are the ones that were removed. If failures are still reported, then one or more of the still-installed DIMMs are bad. If the failures are in the still-installed DIMMs, again remove half of them and retest. If the failure are gone, then swap the installed half for the removed half and retest. Each time a test is run, either cut the number of installed DIMMs in half (for a failure) or swap the installed DIMMs for the removed ones (no failure) until the minimal number of DIMMs are installed (e.g., one pair in the G5 systems). Once you're down to the minimal installation, put back in all of the now known good DIMMs and swap one of the remaining suspects out for the next test. Under normal circumstances, you should be able to isolate the failing DIMMs in just a few swap/test cycles. There are many other reasons DIMMs can appear to be bad. Sometimes, a defective DIMM socket is the culprit and simply not using that socket solves the problem. Problems can also arise from mixing and matching different brands of DIMMs, especially if they aren't all rated with the same timing specs. It's even possible that the motherboard CPU caches may be bad and the fault doesn't lie with the DIMMs at all. Suspect the CPU caches if the tests pass in single-user mode but fail in a terminal window under the full OS. The CPU caches are turned off in single-user mode and are therefore not part of the memory test, whereas the caches are in the test path under full OS operation. EXITING SINGLE-USER MODE To exit single-user mode, type either the reboot command or the shut command at the unix prompt. The reboot command reboots the machine into the full operating system and is analogous to restarting from the Finder. The shut command powers down the machine and is analogous to shutting down the system from the Finder. These are the only recommended methods for exiting single-user mode. Carlo might suggest doing something else first. Cheers, Ronni On 10/11/2011, at 11:43 AM, alas.i...@iinet.net.au wrote: > Hi Ronni and Carlo > > Well I did the permission repair from the disc and it found a whole > paragraph of things to fix which hadn't appeared before, and so far > no safari quits (though it hasn't been long and I'm not using > illustrator this morning) > > But I've had 2 kernel panics. Don't remember ever having one on the > PB before. Any further thoughts appreciated > > best > alastair > > > > On 09/11/2011, at 12:31 PM, cm wrote: > >> Hi Alastair, >> >> (Just saw Ronni's email but this was mostly written so I will send >> it along) >> >> When a problem is really baffling it can sometimes be hardware >> related but at this stage you can't rule out a software problem. >> Some serious diagnostics are in order. :-) >> >> These tests could be run in order so that if one test comes back >> positive there is no need to proceed to the next. >> >> To check for a software problem: >> 1) Check your system log for anything unusual. >> 2) Try to repair permission from the CD so that you do not actually >> boot into your potentially faulty system. >> 3) Create a new account and run Safari to see if it is stable. If >> it is then the problem could be in the user settings of your >> original account. >> 4) Get an external drive with a clean install on the external drive >> see if Safari is stable -- if this works there could be something >> wrong with your system level settings, but there could also be a >> hard-drive hardware problem. >> >> To check for a hardware problem. The most likely candidates are the >> hard drive and memory. >> 1) Clone your current installation to an external drive. Run from >> the external drive and see if it is stable -- if so the hard drive >> is likely at fault. >> 2) If you have spares or know of someone with a similar model >> computer swap out the memory and give it a try. >> >> If you choose to do any of the above please write back and we can >> give you a hand interpreting the results. >> >> Cheers, >> Carlo >> >> On 09/11/2011, at 11:11 , alas.i...@iinet.net.au wrote: >> >>> Hi all >>> >>> Been googling this till my fingers bleed and can't fix it. >>> >>> G4 powerbook 1.5 10.4.11 Applications keep quitting unexpectedly - >>> worst culprits safari and illustrator CS2 - no use switching to >>> firefox or camino; if safari is doing it, so do they. Sometimes i can >>> go all day without quits, others it happens every 2 mins. if i repair >>> permissions and restart things are usually ok for a while but problem >>> soon returns. tried trashing plists and entire illustrator folder in >>> application support, turning off plug-ins in safari, deactivating all >>> but system fonts, run onyx and fsck. i'm running out of ideas! sorry >>> about one hand typing - small niece on lap. >>> >>> your suggestions much appreciated >>> kind regards >>> alastair -- The WA Macintosh User Group Mailing List -- Archives - <http://www.wamug.org.au/mailinglist/archives.shtml> Guidelines - <http://www.wamug.org.au/mailinglist/guidelines.shtml> Settings & Unsubscribe - <http://lists.wamug.org.au/listinfo/wamug.org.au-wamug>
