Follow-up on Visit from the Colonel (Panic) memtest

[guitarist]

Since getting a few Kernel Panics, troubleshooting efforts have begun in earnest. I've been trouble-free for so long, I'm out of practice.

First, the hardware profile: It's a 2010 Mac Mini, 2.4 Core 2 Duo with 8 GB RAM. When I purchased it from Apple, refurb, I installed OWC memory to make it 8 GBs, and replaced the factory internal drive with a hybrid drive, also from OWC. It's running the most current version of Mountain Lion, 10.8.3

Okay, that said, here's the rundown.

On the advice of a C(-)ris, who identified iPhoto in my logs as being implicated in the panic event, and made some comments about the Mini's graphics card, and shared memory, he suggested I test the RAM.

I took his recommendation and downloaded and installed memtest. Then booted in Single User mode, and ran the test. After about 15 minutes of testing, the Mini crashed. I rebooted, and tried again. Same result. Crashed before completing the test.

In the last few days I've done additional elementary troubleshooting and maintenance things in advance of trying the memory test one more time, to make sure I'm getting a clean result, or reducing any additional potential problems or errors. Repair permissions. Log in from a backup drive, and run first aid on the main boot disk. Things like that. Test peripherals, hubs, etc. All appears good.

I read logs, not seeing any specific thing I recognized, but googling some of the noiser bits of chatter and complaints in the logs. Got some suggested solutions, the simplest of which was an instruction to run fsk (I think that's how it's spelled--by holding the Shift key down during boot)That helped correct or clear some of the repeating error-chatter found in logs.

Another example: I saw a repeating complaint about an item on a specific USB port. I isolated it to one attached HD. I removed the external USB hard drive (with what I think has a faulty cable) and replaced it with more reliable external hard drive and cable. And that problem went away.

Satisfied that my Mini's system is relatively clean and okay, this morning, I ran memtest again.

Same result. Crashed in middle of test.

Okay, so it's possible I have a RAM issue.

I've had dozens of computers over the years, but have been fortunate, this is my first time encountering this. I've never, to my knowledge, had bad RAM.

What are my next steps?

I assume the next step might be: I should physically remove one RAM module from the Mini, boot again, and test. Then remove the other RAM module, boot again, and test. Is this correct?

Jumping ahead, if I DO have a bad module (assuming I can get a clear confirmation of this) and need to replace it, I contact OWC to invoke the warranty, yes? I got it from OWC the same year I bought the Mini, about a year or two ago.

That said--what's the best way to test and confirm it is in fact a problem RAM module? I don't want to draw premature conclusions, or make a mistake by not testing it fully,or correctly. I'm not sure how to identify a bad RAM module (if that turns out to be the issue)

Since I'm not familiar with this problem, the steps required are unclear.

I welcome any advice or questions.

One final note: I've never been satisfied with the disappointing performance of this Mini. I didn't expect to to be super-fast. But I've come to the conclusion it's unusually slow for certain processes. Handbrake, for example. As mentioned in a previous message, it's so much slower than a MacBook Pro that's four years older (but has nearly identical processor speed) I simply never use HB on this Mini. Since HB, I presume, involves graphics-card shared memory processing, this might be an indicator. It also chokes on Garage Band. Again, I've had problem-free performance with GarageBand on less well-endowed Macs. And, it has demonstrated problems when using iPhoto.

This adds to my concerns that it's been operating under sub-optimal conditions, or has been laboring with a hidden problem, since the very beginning. I might actually might have better performance from this 2010 Mini if I can identify and address what appears to be an underlying hardware problem.

[C(-)ris]

Could be bad ram. You are correct, test one stick at a time now. When you have the bottom off check and make sure the fan is spinning.

[guitarist]

Okay, testing one 4 GB module now.

Damn. To complicate things a little, when removing the module, one of the two miniature brackets (that help the RAM flip up at an angle) made of plastic and metal, came off into my fingers. I am not sure if it was already weak or detached, or my handling (or mis-handling) prompted it to break off, but it's now in two little pieces on my desk. I was very gentle. But, here it is. Hopefully a minor thing to repair. Or can work okay with just one arm. It doesn't play a role in properly seating or unseating the RAM, but it does play a role in accessing it, the flipper. It now has only the right miniature bracket.

One module removed, being tested as we speak. I'll soon know if the results are different than testing both.

If bad RAM is the conclusion, I assume I'll want to get both replaced, since it's matched pair.

[Article Accelerator]

guitarist wrote: Jumping ahead, if I DO have a bad module (assuming I can get a clear confirmation of this) and need to replace it, I contact OWC to invoke the warranty, yes? I got it from OWC the same year I bought the Mini, about a year or two ago.

That said--what's the best way to test and confirm it is in fact a problem RAM module?

Remove the OWC RAM and reinstall the original RAM. If it runs satisfactorily, you've found the culprit.

This adds to my concerns that it's been operating under sub-optimal conditions, or has been laboring with a hidden problem, since the very beginning.

That may be true.

[guitarist]

Re: testing the first of two 4 GB modules:

Well, it made it longer through the test this time, but it just shut down again, before testing was complete.

I'll test the other one solo, too, and see if I can get all the way through a test and see a result.

Or --is this the way the test identifies bad RAM? If it survives the test, it's okay, if your computer crashes mid-test, it's bad RAM?

Re: original RAM. It's likely I saved it somewhere, but don't immediately know where. Never having discovered bad RAM before, it appears likely that I'll not have that option, I didn't keep the original module handy in the event of a problem like this.

Which means when I return this RAM to OWC, my computer will be down until it's replaced.

Such is the nature of losing my RAM cherry.

I'll plan differently in the future.

One more test to go, then I'm done testing.

[guitarist]

Test fails individually on both modules.

Okay, in touch with OWC. Resolution coming.

Thanks again for the comments and help.

[GGD]

guitarist wrote:
Test fails individually on both modules.

Okay, in touch with OWC. Resolution coming.

Thanks again for the comments and help.

But does the test pass when running with the original factory RAM.

[guitarist]

As mentioned above, factory RAM not available for testing. I haven't been able to locate it. I upgraded the RAM when setting up the computer new in 2011, and remodeled my house since then. Don't know where I stored it. Not having it to test bothers me, but there's not much I can do about it, I don't have that option.

[GGD]

I don't think your testing has conclusively pointed to RAM as the problem, and actually might indicate that RAM is not the problem.

It seems very unlikely for two RAM modules to fail at the same time. You really need to get to a point where you have a working configuration, then change a single variable to cause it to become a failing configuration. You've never gotten to working configuration.

Can you run Apple Hardware Test to see if it might find something else wrong with the system? Or use it's RAM test to see if it can run to completion with at least one of the two modules.

[guitarist]

GGD, your comments prompts me to investigate further.

I was already uneasy because of a lack of conclusive evidence of failure. An instruction I read for memtest indicated that a freeze or crash during testing is a sign of RAM failing.

But that strikes me as unsatisfactory, not conclusive enough to merit pulling out RAM, marking it failed, and shipping it back for replacement.

If it crashed while testing one module, but not the other, and I could isolate it, repeat that step, duplicate the results, and see a pattern, it would be more compelling. Both modules failing at once, it's less clear. And as you suggest, far less likely, and might even be evidence to the contrary.

Starting this morning--having tried the test in Single User Mode, originally--I've now done the test on one module, then both modules, using Terminal, running in Multiuser Mode. In Terminal in Multiuser Mode, the Mini doesn't crash, in fact, it passes the tests.

And to complicate things, those miniature brackets on each side of the RAM modules, for flipping up at an angle for access, then back down flat again, no longer work. The left bracket detached, and the right bracket also had a tiny piece fall off, it's compromised. It no longer flips back down into the flat position. It's permanently in the flipped up position.

(Those brackets are teeny, and were fragile. First time I've encountered that. It wasn't due to undue pressure from my fingers, it simply detached as I was gently handling it)

It doesn't appear to interfere with the Mini's booting up and operating. But it's still an undesirable complication.

But at this stage--seeing the RAM pass tests in Multiuser Mode--I'm no longer certain it's a problem of bad memory. Whatever caused the KP apparently lies elsewhere.

Bonus question: Should I be aware of any relevant difference between testing RAM in Single or Multiuser mode? Why would one method pass, and the other cause the system to crash?