[Kajo]

I've started to get Kernel Panics lately. Nothing has changed hardware wise except that it appears my PCMCIA slot has died. I am posting the panic.log for all you savy operators out there. They didn't mean much to me.

I have a Ti867 w/1 gig memory. I've done all the latest software updates but have not actually reloaded the operating system for a year or so.

Start Logs.

Fri Jan 27 12:53:06 2006
panic(cpu 0 caller 0x00034874): stack_alloc: kernel_memory_allocate
Latest stack backtrace for cpu 0:
Backtrace:
0x00095718 0x00095C30 0x0002683C 0x00034874 0x000398B4 0x000A9894
Proceeding back via exception chain:
Exception state (sv=0x00AABA00)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.4.0: Tue Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC

*********

Sun Jan 29 23:04:55 2006
panic(cpu 0 caller 0x00034874): stack_alloc: kernel_memory_allocate
Latest stack backtrace for cpu 0:
Backtrace:
0x00095718 0x00095C30 0x0002683C 0x00034874 0x000398B4 0x000A9894
Proceeding back via exception chain:
Exception state (sv=0x00AABA00)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.4.0: Tue Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC

*********

Mon Jan 30 10:01:36 2006
panic(cpu 0 caller 0x00034874): stack_alloc: kernel_memory_allocate
Latest stack backtrace for cpu 0:
Backtrace:
0x00095718 0x00095C30 0x0002683C 0x00034874 0x000398B4 0x000A9894
Proceeding back via exception chain:
Exception state (sv=0x00AAAC80)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.4.0: Tue Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC

[Dr. Smoke]

Hi, Kajo.

Your panic log indicates the panic originated in the stack.c OS component, specifically it was unable to allocate a kernel stack for a thread. For example, errors such as this can result if the application you were running at the time violated the "Performance and Stability Tips" section of the Kernel Programming Guide, however, there could be more to it than that.

See my "Resolving Kernel Panics" FAQ. This FAQ includes step-by-step instructions for identifying and resolving some of the most common causes of kernel panics.

My FAQ is a roadmap: start at the beginning and work through to the end, following the instruction in the order specified, including the "If all else fails..." section if a cause or resolution is not found in an earlier troubleshooting step therein.

[Detrius]

Originally Posted by Dr. Smoke

...See my "Resolving Kernel Panics" FAQ. This FAQ includes step-by-step instructions for identifying and resolving some of the most common causes of kernel panics.

My FAQ is a roadmap: start at the beginning and work through to the end, following the instruction in the order specified, including the "If all else fails..." section if a cause or resolution is not found in an earlier troubleshooting step therein.

Dr. Smoke, I have a few recommendations for changes to your FAQ:

1) TechTool Pro and TechTool Deluxe are virtually useless for any hardware tests other than a hard drive surface scan. This comes from many many experiences of watching TechTool Pro pass known-bad hardware, including three bad RAM modules of eight installed, and including the iBook G3 logic board/video card problem. TechTool Pro passes the video memory when the OS can't even find a video card. It's useless.

2) There is a fourth instance that I have seen cause panic logs not to be written: when the hard drive flat out stops responding. Since the hard drive is effectively gone, the kernel can neither read nor write to the drive. It panics with an ATA related error, but the log is not put on the drive, as the drive does not exist to write on.

3) Sometimes re-seating a RAM module stops kernel panics. Software RAM tests should be done before removing RAM modules.

4) RAM sockets can be bad too. Recurring panics after reinstalling a module do not mean the module is bad. It very easily could be the socket.

5) An OS install with bad RAM installed will very likely result in a corrupt installation. Therefore, panics and/or software crashes may not go away after removing bad RAM modules.


See my thread on this stuff for more info: http://forums.macnn.com/90/mac-os-x/248286/the-thread-computer-freezes-panics-crashes/

BTW, just because I'm an ACSA and was an Apple Certified Desktop/Portable Technician when I wrote this doesn't necessarily mean that I have all the facts. But also just because you wrote a book on this stuff doesn't mean you have all the details either.

[Dr. Smoke]

Detrius: thanks for your input.

1) I disagree w.r.t. TTP, and it's the only option for those whose Macs did not come with the AHT, which I recommend first.

2) Sudden hard drive failure generally = panic regardless (can't swap, lost swap data) and will be obvious at the next attempted restart.

3) Checking the RAM seating, and that it's recognized in System Profiler, may be worth noting. With respect to software RAM tests before testing DIMMs by process of elimination, I recommend this in the FAQ: it comes before the "Process of Elimination" approach in the FAQ. Covering all bases.

4) Usually found by the AHT in the logic board test as an issue with the logic board.

5) It's hard to install the OS with bad RAM from the start: the Mac usually panics during the install. You get there — reinstalling the OS — eventually in my process, but only after ruling out more likely causes.

I'm very comfortable with all of the facts I have. ;-)

[CharlesS]

Originally Posted by Detrius

1) TechTool Pro and TechTool Deluxe are virtually useless for any hardware tests other than a hard drive surface scan. This comes from many many experiences of watching TechTool Pro pass known-bad hardware, including three bad RAM modules of eight installed, and including the iBook G3 logic board/video card problem. TechTool Pro passes the video memory when the OS can't even find a video card. It's useless.

Well, I had it find a bad RAM module back in the clone era. Granted, that was a long time ago, but apparently it's not completely useless. Still, Dr. Smoke's assertion that it's the only choice after AHT is not true - there are free alternatives like Rember that may be better than TTP.

[Dr. Smoke]

Originally Posted by CharlesS

Dr. Smoke's assertion that it's the only choice after AHT is not true - there are free alternatives like Rember that may be better than TTP.

You've misunderstood my assertion.

My point w.r.t. TTP is that it is the only choice for a hardware testing suite — not just RAM testing — if one's Mac pre-dates the inclusion of the AHT. My FAQ also cites MEMTEST and Rember.

[Detrius]

Originally Posted by Dr. Smoke

Detrius: thanks for your input.

1) I disagree w.r.t. TTP, and it's the only option for those whose Macs did not come with the AHT, which I recommend first.

2) Sudden hard drive failure generally = panic regardless (can't swap, lost swap data) and will be obvious at the next attempted restart.

3) Checking the RAM seating, and that it's recognized in System Profiler, may be worth noting. With respect to software RAM tests before testing DIMMs by process of elimination, I recommend this in the FAQ: it comes before the "Process of Elimination" approach in the FAQ. Covering all bases.

4) Usually found by the AHT in the logic board test as an issue with the logic board.

5) It's hard to install the OS with bad RAM from the start: the Mac usually panics during the install. You get there — reinstalling the OS — eventually in my process, but only after ruling out more likely causes.

I'm very comfortable with all of the facts I have. ;-)

Dr. Smoke:

1) I never tried booting from the TTP CD, so it's possible the results may be different there, but as of a year ago, an installed version of the latest TTP was useless on newer machines. But TTP isn't the only option. Apple has shipped a program called MacTest Pro to AASPs since the beginning. While not as reliable as AHT and ASD, it's far better than TTP. Of course, this involves taking your machine to an AASP if you don't have access to Service Source ($300/year subscription to the technician training).

2) Hard drive failure can be intermittent. It's possible for the drive to work correctly after a reboot. I've seen this several times. It's rare, but it happens. Claiming there are only three cases is therefore wrong. (In addition, I wouldn't claim that there are only four either, as there very easily could be other extremely rare conditions that neither of us know of.)

3) I would recommend explicitly stating that software should be run before re-seating because of the fact that re-seating the module can fix issues. Some people may skip steps, not knowing that details are important. Without explicitly stating it, people that think they know more than they do may not realize they are skipping an important detail.

4) I've never seen a bad RAM socket show up as a logic board failure--Apple Hardware Test and Apple Service Diagnostics have consistently shown bad sockets in exactly the same way that they show bad RAM--they don't distinguish between the two. Also, I saw one really really weird situation where one module wouldn't work in one socket, but all other combinations were fine.

5) I've found that whether or not an OS installation works (or even a boot from the CD) depends on how much RAM is in the machine and where the bad RAM is located. If there is enough good RAM to fit the running OS and application(s), then only the copied data will go through the bad RAM (i.e. it depends on which portion of the memory address space is bad). Of course, configurations like this tend to run longer between panics and tend to have application crash issues.


Of course, it's your site, so you can do whatever you like with it. I'm out of the business now, so it in no way affects me one way or the other. I just remember talking to people in various places that would dispute things I had observed based on what they had read.

Anyway... I have to make dinner now...

[Dr. Smoke]

1. MacTest Pro isn't an option for the average user, which is the audience. But they'd get to that at the end if they take it in for service: the last step.

2. The panic log is saved in PRAM and written to the panic.log file at the next restart. So if your theory of "intermittent hard drive failure" is the cause of the panic, but the drive works at the next reboot as you indicate, you'll get a panic.log unless the other reasons stated in my FAQ apply. I suppose one could add that if you reset PRAM as part of the first restart after the panic, that will clear the log from PRAM, but I think that's highly unlikely.

3. They may not be in a position where they can download tests like MEMTEST or REMBER, nor have the Micromat products on hand. So they have options. Most people will opt for software-based testing before opening the case. If you can't do additional software-based testing, you need to open the case. The FAQ instructs the reader to follow the steps in the order specified. If someone wants to deviate from that, it's their choice, but then they may work harder than they have to in order to get to the cause, or, by skipping steps, miss the cause entirely if it's in their power to correct it. Instructions are written to be followed.

4. The "one really weird situation" is getting into statistical outliers vs. common causes. Perhaps adding something along the lines of checking individual DIMMs in different sockets to rule out a bad socket vs. a bad DIMM would be worthwhile.

5. RAM testing should again uncover this. One gets to the "reinstall the OS" bit later in the FAQ: if one follows the steps, this is covered.

Hope you had a good dinner. ;-)