• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Understanding cores...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Understanding cores...


  • Subject: Understanding cores...
  • From: Michael Tuexen <email@hidden>
  • Date: Sat, 6 Jan 2007 19:10:16 +0100

Dear all,

I'm looking at a core of a MacPro. It crashes a lot and it use an NKE. So I would
like to understand why the system is crashing, if it is related to the NKE and
finally how to fix it...


The problem is that all data structures of the NKE look fine, from a network
trace which was also made at the time of the crash we know that there was no
incoming SCTP packet (this is the transport layer which is implemented by the
NKE), no system call by the user and no timer was running of. The paniclog says:


(gdb) source KernelDebugKit/kgmacros
Loading Kernel GDB Macros package. Type "help kgm" for more info.
(gdb) paniclog
panic(cpu 2 caller 0x001A3135): Unresolved kernel trap (CPU 2, Type 14=page fault), registers:
CR0: 0x8001003b, CR2: 0xffffffe0, CR3: 0x011b0000, CR4: 0x000006e0
EAX: 0x00000000, EBX: 0x352c4038, ECX: 0x352c4000, EDX: 0x352dd008
CR2: 0xffffffe0, EBP: 0x00000000, ESI: 0x352f4010, EDI: 0x004ae85c
EFL: 0x00010046, EIP: 0x00135f3b, CS: 0x00000008, DS: 0x03820010


Backtrace, Format - Frame : Return Address (4 potential args on stack)
0x252a3d68 : 0x128d1f (0x3c9540 0x252a3d8c 0x131df4 0x0)
0x252a3da8 : 0x1a3135 (0x3cf1f4 0x2 0xe 0x3cea24)
0x252a3eb8 : 0x19a8d4 (0x252a3ed0 0x352f4000 0x252a3f28 0x352f4000) Backtrace terminated-invalid frame pointer 0x0


Kernel version:
Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386


Trying to find what was running on the system results in

(gdb) showcurrentstacks
task        vm_map      ipc_space  #acts   pid  proc        command
0x03808da0  0x013e3f3c  0x037d2ef0   54      0  0x004d2200  kernel_task
            activation  thread      pri  state  wait_queue  wait_event
            0x03827c64  0x03827c64    0  IR
                reserved_stack=0x25008000
                kernel_stack=0x25258000
                stacktop=0x2525bf18
                0x2525bf18  0x1a42f5 <machine_idle_cstate+32>
                0x2525bf38  0x19d871 <machine_idle+128>
                0x2525bf58  0x135f23 <idle_thread+96>
                0x2525bfc8  0x19a74c <call_continuation+28>
                stackbottom=0x2525bfc8

task        vm_map      ipc_space  #acts   pid  proc        command
0x03808da0  0x013e3f3c  0x037d2ef0   54      0  0x004d2200  kernel_task
            activation  thread      pri  state  wait_queue  wait_event
            0x03822b04  0x03822b04    0  IR
                reserved_stack=0x24fd8000
                kernel_stack=0x25378000
                stacktop=0x2537bf18
                0x2537bf18  0x1a42f5 <machine_idle_cstate+32>
                0x2537bf38  0x19d871 <machine_idle+128>
                0x2537bf58  0x135f23 <idle_thread+96>
                0x2537bfc8  0x19a74c <call_continuation+28>
                stackbottom=0x2537bfc8

task        vm_map      ipc_space  #acts   pid  proc        command
0x03808da0  0x013e3f3c  0x037d2ef0   54      0  0x004d2200  kernel_task
            activation  thread      pri  state  wait_queue  wait_event
            0x03822e68  0x03822e68    0  IR
                reserved_stack=0x24ff8000
                kernel_stack=0x252a0000
                stacktop=0x252a3d68
                0x252a3d68  0x128d1f <panic+382>
                0x252a3da8  0x1a3135 <kernel_trap+1538>
                0x252a3eb8  0x19a8d4 <trap_from_kernel+19>
                stackbottom=0x252a3eb8

task        vm_map      ipc_space  #acts   pid  proc        command
0x03808da0  0x013e3f3c  0x037d2ef0   54      0  0x004d2200  kernel_task
            activation  thread      pri  state  wait_queue  wait_event
            0x03825050  0x03825050    0  IR
                reserved_stack=0x24fe0000
                kernel_stack=0x252c0000
                stacktop=0x252c3f18
                0x252c3f18  0x1a42f5 <machine_idle_cstate+32>
                0x252c3f38  0x19d871 <machine_idle+128>
                0x252c3f58  0x135f23 <idle_thread+96>
                0x252c3fc8  0x19a74c <call_continuation+28>
                stackbottom=0x252c3fc8

So how can I figure out why the system crashed?

The systems runs MacOS X 10.4.8 Server. So could it be that the system locked up and
the Watchdog forced it to reboot. Would we then see a trace like the one above?


Thank you very much for your help in advance.

Best regards
Michael

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Understanding cores...
      • From: "Brian Bechtel" <email@hidden>
  • Prev by Date: Re: Kext suspension question
  • Next by Date: User-space to kernel communication
  • Previous by thread: Re: Kext suspension question
  • Next by thread: Re: Understanding cores...
  • Index(es):
    • Date
    • Thread