M1/arm64 panic logs information

Question

Created Sep ’22

Replies 0

Boosts 0

Views 1.1k

Participants 1

The amr64 panic logs are new and a bit different, has a whole bunch of information which is nice but, sometimes I get something like:

panic(cpu 11 caller 0xfffffe0013d81f1c): Kernel data abort. at pc 0xfffffe001512adb4, lr 0xfffffe001512ad9c

Debugger message: panic\n
Memory ID: 0x6\n
OS release type: User\n
OS version: 21G115\n
Kernel version: Darwin Kernel Version 21.6.0: Mon Aug 22 20:19:52 PDT 2022; root:xnu-8020.140.49~2\/RELEASE_ARM64_T6000\n
Fileset Kernelcache UUID: 39A7E336B0FAA0022B3764E49DFF29D2\n
Kernel UUID: 778CC57A-CF0B-3D35-8EE8-5035142D0177\ni
Boot version: iBoot-7459.141.1\n
secure boot?: YES\n
Paniclog version: 13\n
KernelCache slide: 0x000000000bc48000\n
KernelCache base:  0xfffffe0012c4c000\n
Kernel slide:      0x000000000c40c000\n
Kernel text base:  0xfffffe0013410000\n
Kernel text exec slide: 0x000000000c4f4000\n
Kernel text exec base:  0xfffffe00134f8000

ktrace: 0xfffffe180eaaea80, tid: 144477\n\t\t  lr: 0xfffffe0013551400  fp: 0xfffffe180eaaeaf0\n\t\t  lr: 0xfffffe00135510c8  fp: 0xfffffe180eaaeb60\n\t\t  lr: 0xfffffe001369733c  fp: 0xfffffe180eaaeb80\n\t\t  lr: 0xfffffe00136890cc  fp: 0xfffffe180eaaebf0\n\t\t  lr: 0xfffffe0013686cb0  fp: 0xfffffe180eaaecb0\n\t\t  lr: 0xfffffe00134ff7f8  fp: 0xfffffe180eaaecc0\n\t\t  lr: 0xfffffe0013550d4c  fp: 0xfffffe180eaaf060\n\t\t  lr: 0xfffffe0013550d4c  fp: 0xfffffe180eaaf0d0\n\t\t  lr: 0xfffffe0013d7954c  fp: 0xfffffe180eaaf0f0\n\t\t  lr: 0xfffffe0013d81f1c  fp: 0xfffffe180eaaf270\n\t\t  lr: 0xfffffe0013688ecc  fp: 0xfffffe180eaaf2e0\n\t\t  lr: 0xfffffe0013686fb4  fp: 0xfffffe180eaaf3a0\n\t\t  lr: 0xfffffe00134ff7f8  fp: 0xfffffe180eaaf3b0\n\t\t  lr: 0xfffffe001512ad9c  fp: 0xfffffe180eaaf740\n\t\t  lr: 0xfffffe001515ac20  fp: 0xfffffe180eaaf7a0\n\t\t  lr: 0xfffffe001511a03c  fp: 0xfffffe180eaaf9a0\n\t\t  lr: 0xfffffe001511dc78  fp: 0xfffffe180eaafa10\n\t\t  lr: 0xfffffe0015148d14  fp: 0xfffffe180eaafa40\n\t\t  lr: 0xfffffe00137b8b24  fp: 0xfffffe180eaafad0\n\t\t  lr: 0xfffffe0015145c4c  fp: 0xfffffe180eaafce0\n\t\t  lr: 0xfffffe00137cc864  fp: 0xfffffe180eaafd20\n\t\t  lr: 0xfffffe00137b88c8  fp: 0xfffffe180eaafda0\n\t\t  lr: 0xfffffe00137cc7ac  fp: 0xfffffe180eaafdb0\n\t\t  lr: 0xfffffe0013bbaa28  fp: 0xfffffe180eaafe50\n\t\t  lr: 0xfffffe0013686d84  fp: 0xfffffe180eaaff10\n\t\t  lr: 0xfffffe00134ff7f8  fp: 0xfffffe180eaaff20\n
      Kernel Extensions in backtrace:\n 
        com.apple.filesystems.hfs.kext(583.100.10)[45F25204-8A60-3A88-B71F-974BDDBDB3BF]@0xfffffe00151148a0->0xfffffe00151634e3\n 
           dependency: com.apple.filesystems.hfs.encodings.kext(1)[4183166A-286A-3CEB-8C2C-AF85AA1F4D16]@0xfffffe00151634f0->0xfffffe001516441f\n\n
last started kext at 3074954554: com.apple.filesystems.smbfs\t4.0 (addr 0xfffffe00133f4c30, size 65195)\n
loaded kexts:\n
org.openzfsonosx.zfs\t2.1.99\n
com.apple.filesystems.smbfs\t

So if you are really lucky, it will list the address of your kext here, in this case, just com.apple.filesystems.hfs.kext. But nearly all the time, you have no way to get the load address for org.openzfsonosx.zfs, which I think means I can not lookup symbols, or anything useful at all.

I think HFS called into ZFS and we returned something cursed.

Would it be possible to have the load addresses listed in the large list of kext loaded?

Boost