User-agent: Mozilla Thunderbird 0.7 (Windows/20040616)
Dan Shoop wrote:
... which led me to look for a panic.log file, which I found, which
had an "unresolved kernel trap (cpu0)" error. The server is brand new
(tho running for about two months with no problems), fresh from Apple,
with a SCSI card and ATI video card. I'll test the RAM I guess, and
cross fingers.
Not that your reboot and the original posters have any reason to be
related, but analyzing any crash dumps might be in order, no?
I looked at the panic.log and the watchdog.event.logs, but I certainly
wouldn't call it analysis. The panic.log had this in it:
=== begin panic.log ===
Tue Sep 28 23:27:15 2004
Unresolved kernel trap(cpu 0): 0x300 - Data access
DAR=0x000000001000001E PC=0x00000000001D9904
Latest crash info for cpu 0:
Exception state (sv=0x0099FC80)
PC=0x001D9904; MSR=0x00009030; DAR=0x1000001E; DSISR=0x40000000;
LR=0x001D9714; R1=0x1C3D3D40; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0xFFFFFFFF 0x001D9714 0x001EE850 0x0020A82C 0x002452B4
0x00094200 0x00000000
backtrace terminated - frame not mapped or invalid: 0xBFFFB860
Proceeding back via exception chain:
Exception state (sv=0x0099FC80)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x32946000)
PC=0x9001040C; MSR=0x0200F030; DAR=0x05AF0B68; DSISR=0x40000000;
LR=0x90297A30; R1=0xBFFFB860; XCP=0x00000030 (0xC00 - System call)
Kernel version:
Darwin Kernel Version 7.5.0:
Thu Aug 5 19:26:16 PDT 2004; root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC
panic(cpu 0): 0x300 - Data access
Latest stack backtrace for cpu 0:
Backtrace:
0x000836E4 0x00083BC8 0x0001EDA4 0x00090C60 0x0009406C
Proceeding back via exception chain:
Exception state (sv=0x0099FC80)
PC=0x001D9904; MSR=0x00009030; DAR=0x1000001E; DSISR=0x40000000;
LR=0x001D9714; R1=0x1C3D3D40; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0xFFFFFFFF 0x001D9714 0x001EE850 0x0020A82C 0x002452B4
0x00094200 0x00000000
backtrace terminated - frame not mapped or invalid: 0xBFFFB860
Exception state (sv=0x32946000)
PC=0x9001040C; MSR=0x0200F030; DAR=0x05AF0B68; DSISR=0x40000000;
LR=0x90297A30; R1=0xBFFFB860; XCP=0x00000030 (0xC00 - System call)
Kernel version:
Darwin Kernel Version 7.5.0:
Thu Aug 5 19:26:16 PDT 2004; root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC
=== end panic.log ===
The last entries in the watchdog monitor look like this:
#Start-Date: 2004-09-19 14:12:08 EDT
#Fields: date time s-comment
2004-09-19 14:12:08 EDT Started child "/usr/sbin/PasswordService" as pid
343.
2004-09-19 14:12:08 EDT Started child "/usr/sbin/PrintServiceMonitor" as
pid 344.
2004-09-19 14:12:08 EDT Started child "/usr/libexec/postfix/master" as
pid 345.
2004-09-19 14:12:08 EDT Started child "/usr/bin/cyrus/bin/master" as pid
346.
2004-09-19 14:12:08 EDT Started child "/usr/sbin/hwmond" as pid 347.
2004-09-19 14:12:08 EDT Automatic reboot timer enabled.
#Start-Date: 2004-09-28 23:27:15 EDT
#Fields: date time s-comment
2004-09-28 23:27:16 EDT Started child "/usr/sbin/PasswordService" as pid
349.
2004-09-28 23:27:16 EDT Started child "/usr/sbin/PrintServiceMonitor" as
pid 350.
2004-09-28 23:27:16 EDT Started child "/usr/libexec/postfix/master" as
pid 351.
2004-09-28 23:27:16 EDT Started child "/usr/bin/cyrus/bin/master" as pid
352.
2004-09-28 23:27:16 EDT Started child "/usr/sbin/hwmond" as pid 356.
2004-09-28 23:27:16 EDT Automatic reboot timer enabled.
... which just looks like normal startup messages.
I simply don't know enough about these logs to be able to tell what
happened. I tested the memory (tho while in multiuser mode, so I
realize that's pretty lame) today and it came through with no errors, on
multiple passes. I'll do a more comprehensive test of the modules when
the time is right.
One thread on afp548.com suggested that a resource hog (like, say,
Retrospect, which was running at the time of the crash) could cause
watchdog to restart the server, but I'd think there'd be a message about
it in the watchdog log.
periodic sends me its output each day, and I haven't seen anything in
there indicating a festering problem, and besides that and the logs I
reported above, I don't know where else to look for a problem. Maybe I
can renice the retrospect processes. Graspin' at straws ain't a great
server management stragety, but that's where I'm at.
----
Rob Guglielmetti
e. email@hidden
w. www.rumblestrip.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden