Thanks again Ronni and Carlo Yes, I ran memtest in single user mode - 3 passes of which 2 had quite a few mismatches and the third, I think, only one.
I will try taking out one dimm (don't have a spare to do a swap) and testing again. But have to get some work done first, between panics! thanks alastair On 10/11/2011, at 12:14 PM, Ronda Brown wrote: > 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> -- 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>
