[BTP]

The one thing I miss about OS 9 is how familiar I was with it. There were few problems that I couldn't fix myself and I had a great understanding of the OS. Now, as that knowledge slowly fades, I am replacing it with what I have learned from OS X.

I realize now that I am not as good with X as I was with 9. I am having a *lot* of trouble with my G4/450. Forced logouts, corrupted files, kernel panics daily and other freezes and such.

One consistent message in the Console crash log is "kernel protction fault", which I'd like to blame on RAM. I am replacing all the RAM in the machine tomorrow as a last resort.

I can look through a kernel panic, well the pre-x.2 ones, and read whatever made some sense to get an idea of what caused the panic, but no longer. Is there a way to dechipher the crash logs (which I have turned on) to point to the culprit?

RAM is the last thing I can check. I have used a few OS 9 RAM testing programs and they pass, but always crash on the longer ones. The hard drive is new, the system new as well. No cards other than the stock ATI, nothing attached, still this this is completely unreliable. The firmware is upto date, I have zapped the PRAM and pushed the CUDA swtich.

If RAM doesn't solve the problem, I can't think of anything else to try. What would make life easier if there were a way to better understand the meanings of the crash logs. Maybe it is just that easy, but they do not make sense to me yet. Anyone care to enlighten me if you can?

[normyzo]

If you're a developer and your program crashes, they are invaluable Anyway, if you know what you are looking for, then you can get an idea of what went wrong. For example:

Thread 0 Crashed:
#0 0x8fe01280 in halt
#1 0x8fe106b4 in link_in_need_modules
#2 0x8fe12a24 in _dyld_bind_fully_image_containing_address
#3 0x990ed374 in _dyld_bind_fully_image_containing_address
#4 0x990ed2cc in sigaction__
#5 0x990f7340 in signal__
#6 0x00006938 in 0x6938
#7 0x00004b34 in 0x4b34
#8 0x000049b4 in 0x49b4

This crashlog means that the run-time linker couldn't load in a library it needed and therefore can't run the program. If you open a terminal, type 'setenv DYLD_PRINT_LIBRARIES' and then do 'open <your program' then you'll see exactly which library was not able to be loaded, and therefore the culprit.

With a kernel panic, the culprit is usually a device driver. If that's the case (I get a lot of AppleSerial ones b/c of my USB modem b/c PPP with a USB modem _still_ sucks), the device driver name itself will probably give you a clue as to what is malfunctioning so you can remove it and test how the machine runs without it.

Things like Kernel Protection Faults are usually problems in the kernel or in the machine's hardware itself (ie motherboard or RAM). If you've got any non-Apple RAM, try replacing it.

Run the Disk Utility's Fix Permissions option frequently. Many installers screw permissions on system stuff like /Library or /System up because they aren't coded properly, and I've had wierd issues from Classic refusing to launch to programs quitting unexpectedly until I do this from time to time.

Dan

[BTP]

Dan-

Thanks for that. I do like to understand and to tinker around. I ran the permissions repair and there were a lot that were repaired.

I guess the errors/crash logs are a lot better than the old ones (Error 11?!). I'll am replacing all the RAM today and I am hoping that cures things. The thought that there could be a motherboard isssue is a concern, as this is well out of warranty, as well as I have no way of testing for that, as the test disk for this is long gone. Someone gave me their test disk for thier G4, but it wouldn't work with mine. Is there any other software that will test the motherboard?

[BTP]

Norm,

Since you seem able to read the error messages, can you make sense of this one?

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x41bc0474

Thread 0 Crashed:
#0 0x0014630c in invert_pointer_at
#1 0x00146600 in compact_heap
#2 0x00146ce4 in compact_heap_maybe
#3 0x00145560 in major_collection_slice
#4 0x001444f0 in minor_collection
#5 0x0014457c in check_urgent_gc
#6 0x0013da84 in alloc_string
#7 0x0013a774 in create_string

PPC Thread State:
srr0: 0x0014630c srr1: 0x0200d030 vrsave: 0x00000000
xer: 0x20000000 lr: 0x00146600 ctr: 0x0014637c mq: 0x00000000
r0: 0x41bc0474 r1: 0xbffff858 r2: 0x2400044a r3: 0x007f243c
r4: 0x002e2620 r5: 0x00000001 r6: 0x0014625c r7: 0x000023df
r8: 0x41bc0474 r9: 0x007f2340 r10: 0x007f2348 r11: 0x00000000
r12: 0x00000000 r13: 0x00000000 r14: 0x00f40814 r15: 0x000259c6
r16: 0x000f4241 r17: 0x000259c5 r18: 0x000259c6 r19: 0x00020b69
r20: 0x00020b6a r21: 0x00000001 r22: 0x00020b69 r23: 0x00020b69
r24: 0x00f40814 r25: 0x00804000 r26: 0x00000308 r27: 0x007c2000
r28: 0x007f2434 r29: 0x00000002 r30: 0x00000004 r31: 0x001464ac

[Person Man]

Originally posted by BTP:

RAM is the last thing I can check. I have used a few OS 9 RAM testing programs and they pass, but always crash on the longer ones.

I think this is the key. You say that the longer RAM tests always crash under OS 9. Mac OS X uses RAM very differently from earlier versions of the operating system, and the longer tests put more stress on the RAM chips, similar to how OS X does.

This is one of the reasons why (IMHO) Apple released a firmware updater a few years back that disabled certain (cheap and out-of-spec) RAM chips. Under previous OS versions they were fine, but when placed under any sort of major stress (as in OS X) they would cause errors. Rather than have people blame their OS X problems on Apple or the machine hardware itself (nobody would ever think of RAM problems... "why, the RAM has worked all these years"), Apple decided to disable "out-of-spec" RAM in firmware. Sure, they caught hell for doing it, but it forced people to look at the issue of out-of-spec RAM and made people realize that "cheaper is not always better."

That said, I think you will find that replacing the RAM will help matters greatly. You should also probably do a complete reinstall of the system after the new RAM is put in the machine to remove any other remaining gremlins.

[BTP]

I pulled all four DIMMs out and found that there were 3 different types:

1 NEC 128MB PC100(3-2-2)
2 PLUSS 128MB PC100 (3-3-3)
1 PQI 256MB PC133

I replaced them with a Kingston 512MB PC100 and so far, things are *perfect*. I'll say for sure in 24 hours, but it is looking very much like bad RAM was the issue.

Is there a way to test RAM via a hardware tester? I hate to toss all 4 DIMMs when some may still be good. I am not going to put them back in the machine to test either....

[ngrundy]

Originally posted by BTP:

Is there a way to test RAM via a hardware tester? I hate to toss all 4 DIMMs when some may still be good. I am not going to put them back in the machine to test either....

The best way even though you indicate you don't want to do it is to install one stick at a time, run the memory test that would kill itself (the extended os9 ones?) and see what stick falls on its face.

I reacently did the hunt-for-broken-ram in my now defunct (read replaced by a powerbook) x86 desktop.