Mac Studio Ventura panic / boot loop with kext

App & System Services Core OS
lundman OP
Created Oct ’22
Replies 1
Boosts 0
Views 995
Participants 1

So we have produced kexts that run well, on Intel and Arm64, on (for example) an MBP/M1 (all macOS currently available), and MacStudio (Monterey).

But on Monterey + Ventura it enters a boot panic loop.

One example is:

  "build" : "macOS 13.1 (22C5033e)",  "product" : "Mac13,2",  "socId" : "0x00006002",  "kernel" : "Darwin Kernel Version 22.2.0: Sun Oct 16 18:09:52 PDT 2022; root:xnu-8792.60.32.0.1~11\/RELEASE_ARM64_T6000",  "incident" : "8D3814E3-DCBB-42A6-AACF-C37F66D6BBC8",  "crashReporterKey" : "FF922DC9-99E1-68B9-75FB-9427F2BBF431",  "date" : "2022-10-28 00:12:53.22 +0100", 

 "panicString" : "panic(cpu 6 caller 0xfffffe001e4b11e8): \"apciec[pcic2-bridge]::handleInterrupt: Request address is greater than 32 bits linksts=0x99000001 pcielint=0x02220060 linkcdmsts=0x00000000 (ltssm 0x11=L0)\\n\" @AppleT8103PCIeCPort.cpp:1301\n

Debugger message: panic\nMemory ID: 0x6\nOS release type: User\nOS version: 22C5033e\nKernel version: Darwin Kernel Version 22.2.0: Sun Oct 16 18:09:52 PDT 2022; root:xnu-8792.60.32.0.1~11\/RELEASE_ARM64_T6000\nFileset Kernelcache UUID: D767CC1C43ABBCC48AD47B6010804F47\nKernel UUID: 99C80004-214F-342C-ADF2-402BC1EAC155\nBoot session UUID: 8D3814E3-DCBB-42A6-AACF-C37F66D6BBC8\niBoot version: iBoot-8419.60.31\nsecure boot?: YES\nroots installed: 0\nPaniclog version: 14\nKernelCache slide: 0x00000000149f4000\nKernelCache base:  0xfffffe001b9f8000\nKernel slide:      0x0000000015c54000\nKernel text base:  0xfffffe001cc58000\nKernel text exec slide: 0x0000000015d40000\nKernel text exec base:  0xfffffe001cd44000\nmach_absolute_time: 0x1506187a\nEpoch Time:        sec       usec\n  Boot    : 0x635b102d 0x0009de48\n  Sleep   : 0x00000000 0x00000000\n  Wake    : 0x00000000 0x00000000\n  Calendar: 0x635b1035 0x000bfb29\n\nZone info:\n  Zone map: 0xfffffe10219f0000 - 0xfffffe30219f0000\n  . VM    : 0xfffffe10219f0000 - 0xfffffe14ee6bc000\n  . RO    : 0xfffffe14ee6bc000 - 0xfffffe1688054000\n  . GEN0  : 0xfffffe1688054000 - 0xfffffe1b54d20000\n  . GEN1  : 0xfffffe1b54d20000 - 0xfffffe20219ec000\n  . GEN2  : 0xfffffe20219ec000 - 0xfffffe24ee6b8000\n  . GEN3  : 0xfffffe24ee6b8000 - 0xfffffe29bb384000\n  . DATA  : 0xfffffe29bb384000 - 0xfffffe30219f0000\n  Metadata: 0xfffffe3021a00000 - 0xfffffe3029a00000\n  Bitmaps : 0xfffffe3029a00000 - 0xfffffe3049a00000\n\nTPIDRx_ELy = {1: 0xfffffe29bae26818  0: 0x0000000000000006  0ro: 0x0000000000000000 }\nCORE 0 PVH locks held: None\nCORE 1 PVH locks held: None\nCORE 2 PVH locks held: None\nCORE 0: PC=0x00000001af0305ec, LR=0x00000001af0304e8, FP=0x000000016dda6200\nCORE 1: PC=0x00000001aeee1c94, LR=0x00000001bb020624, FP=0x000000016e206140\nCORE 2: PC=0xfffffe001d4a15e0, LR=0xfffffe001d4a14cc, FP=0xfffffe8ff2263d30\nCORE 3: PC=0xfffffe001cd9c9f8, LR=0xfffffe001d6eac6c, FP=0xfffffe80212ab920\nCORE 4: PC=0xfffffe001d416704, LR=0xfffffe001d4a265c, FP=0xfffffe802138fd50\nCORE 5: PC=0xfffffe001cd9c974, LR=0xfffffe001f14aca0, FP=0xfffffe8020a4ba50\nCORE 6 is the one that panicked. Check the full backtrace for details.\nCORE 7: PC=0xfffffe001cdbbad0, LR=0xfffffe001cdbbb88, FP=0xfffffe8ff1f6fd90\nCORE 8: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8020edff00\nCORE 9: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8ff2197f00\nCORE 10: PC=0xfffffe001cfd1054, LR=0xfffffe001f9d7d14, FP=0xfffffe8ff1f87610\nCORE 11: PC=0x00000001b2064b88, LR=0x00000001b2064af0, FP=0x000000016f3e5860\nCORE 12: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8021543f00\nCORE 13: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8020963f00\nCORE 14: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8020adff00\nCORE 15: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8020a03f00\nCORE 16: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8ff1f4bf00\nCORE 17: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe802146bf00\nCORE 18: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe8ff21c7f00\nCORE 19: PC=0xfffffe001cddfca4, LR=0xfffffe001cddfca4, FP=0xfffffe88090fff00\nCompressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space\nPanicked task 0xfffffe168805d678: 0 pages, 1020 threads: pid 0: kernel_task\nPanicked thread: 0xfffffe29bae26818, backtrace: 0xfffffe80213176a0, tid: 285\n\t\t  lr: 0xfffffe001cda2adc  fp: 0xfffffe8021317710\n\t\t  lr: 0xfffffe001cda2884  fp: 0xfffffe8021317790\n\t\t  lr: 0xfffffe001cf06a18  fp: 0xfffffe80213177b0\n\t\t  lr: 0xfffffe001cef7f88  fp: 0xfffffe8021317820\n\t\t  lr: 0xfffffe001cef588c  fp: 0xfffffe80213178e0\n\t\t  lr: 0xfffffe001cd4b7f8  fp: 0xfffffe80213178f0\n\t\t  lr: 0xfffffe001cda220c  fp: 0xfffffe8021317ca0\n\t\t  lr: 0xfffffe001d5e6b74  fp: 0xfffffe8021317cc0\n\t\t  lr: 0xfffffe001e4b11e8  fp: 0xfffffe8021317d80\n\t\t  lr: 0xfffffe001e4be774  fp: 0xfffffe8021317e50\n\t\t  lr: 0xfffffe001d4ea934  fp: 0xfffffe8021317ea0\n\t\t  lr: 0xfffffe001d4e6b54  fp: 0xfffffe8021317ee0\n\t\t  lr: 0xfffffe001d4e779c  fp: 0xfffffe8021317f20\n\t\t  lr: 0xfffffe001cd54e98  fp: 0x0000000000000000\n      Kernel Extensions in backtrace:\n         com.apple.driver.AppleT6000PCIeC(1.0)[D6E00E5A-7BC8-33A5-9CDC-C4CF13DB1C01]@0xfffffe001e4a2250->0xfffffe001e4c7fa3\n            dependency: com.apple.driver.AppleARMPlatform(1.0.2)[F8A12C7A-9C6E-3DCC-A2C3-56A2050A7E73]@0xfffffe001d78def0->0xfffffe001d7dc45f\n            dependency: com.apple.driver.AppleEmbeddedPCIE(1)[2BA5358A-87CA-33DF-A148-FFE0C2733367]@0xfffffe001ddc8400->0xfffffe001dde2817\n            dependency: com.apple.driver.ApplePIODMA(1)[7CB8682A-FA16-3841-9E30-B6032E5C6925]@0xfffffe001e1d7e60->0xfffffe001e1dc5eb\n            dependency: com.apple.driver.IODARTFamily(1)[5C3EEB18-7785-328B-B994-3B0DA5B7D2FE]@0xfffffe001edfd870->0xfffffe001ee1135f\n            dependency: com.apple.iokit.IOPCIFamily(2.9)[D6265950-5027-3125-A532-DC325E6A0639]@0xfffffe001f176220->0xfffffe001f1a12a3\n            dependency: com.apple.iokit.IOReportFamily(47)[ED601736-6073-3B7D-A228-0FEC344992FA]@0xfffffe001f1a4ee0->0xfffffe001f1a7ecb\n            dependency: com.apple.iokit.IOThunderboltFamily(9.3.3)[4F558D51-13A7-3E87-AAD6-23E0A7C0A146]@0xfffffe001f2a02c0->0xfffffe001f3dbd4f\n\nlast started kext at 341403491: com.apple.UVCService\t1 (addr 0xfffffe001c13a690, size 1772)\nloaded

Presumably our kext is guilty of something, but it isn't (obviously) involved yet. Machine generally boots without our kext, but not always. Same kext works on Monterey, as well as Ventura on M1.

Any particular areas to look at for this kind of panic? Are there hints in the stack? (can we resolve panic stack yet?)

Replies  1
Boosts  0
Views  995
Participants  1
lundman OP
Nov ’22

With exhaustive printf debugging - since this is now the best available, we found out the old line:

       static char initial_default_block[16ULL*1024ULL*1024ULL]
           __attribute__((aligned(16384))) = { 0 };

Used to bootstrap our memory allocator, would not work on Ventura+M1+more-than-16GB ram. Ie, MacStudio 128G. Monterey on same hardware (As well as all lower M1s, and x86_64) are fine.

We replaced it with:

       initial_default_block =
           IOMallocAligned(INITIAL_BLOCK_SIZE, 16384);
       memset(initial_default_block, 0, INITIAL_BLOCK_SIZE);

Unlikely anyone else would bump into this issue, but it feels more complete to post the answer.

0
Mac Studio Ventura panic / boot loop with kext
First post date Last post date
 
 
Q