Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Persistent double fault kernel panics, probably caused by OpenCore Legacy Patcher #46

Closed
liuyi12138 opened this issue Mar 24, 2023 · 24 comments
Closed

Persistent double fault kernel panics, probably caused by OpenCore Legacy Patcher #46

liuyi12138 opened this issue Mar 24, 2023 · 24 comments

Comments

@liuyi12138
Copy link

When I first use HookCase 7.1.3, it works properly.
But the next time i load it, if i try to inject, the kernel panic.
Then, even though i use HookCase 7.1.2, the kernel panic either.

panic(cpu 2 caller 0xffffff8005f496b7): Double fault at 0xffffff8008816d5b, registers:
CR0: 0x0000000080010033, CR2: 0xffffffbe064c3ff8, CR3: 0x00000000588b21c8, CR4: 0x00000000003626e0
RAX: 0xffffff8006a87b00, RBX: 0xffffff86b6d0c200, RCX: 0x0000000002000000, RDX: 0x0000000000000008
RSP: 0xffffffbe064c4000, RBP: 0xffffffbe064c4020, RSI: 0x0000000000000290, RDI: 0xffffffcb37069000
R8:  0x0000000000000004, R9:  0xffffffbe064c42e0, R10: 0xffffffbe064c4308, R11: 0xffffffbe064c4450
R12: 0xffffffcb3706b800, R13: 0xffffffcb37069000, R14: 0x0000000000000290, R15: 0x0000000000000008
RFL: 0x0000000000010246, RIP: 0xffffff8008816d5b, CS:  0x0000000000000008, SS:  0x0000000000000010
Error code: 0x0000000000000000
 @trap_native.c:168
Panicked task 0xffffff951e6e9208: 1 threads: pid 1467: ls
Backtrace (CPU 2), panicked thread: 0xffffff8b85f10598, Frame : Return Address
0xffffff8005b0d270 : 0xffffff8005deb31d mach_kernel : _handle_debugger_trap + 0x4ad
0xffffff8005b0d2c0 : 0xffffff8005f59236 mach_kernel : _kdp_i386_trap + 0x116
0xffffff8005b0d300 : 0xffffff8005f48480 mach_kernel : _kernel_trap + 0x3e0
0xffffff8005b0d350 : 0xffffff8005d85951 mach_kernel : _return_from_trap + 0xc1
0xffffff8005b0d370 : 0xffffff8005deb5fd mach_kernel : _DebuggerTrapWithState + 0x5d
0xffffff8005b0d460 : 0xffffff8005deaca9 mach_kernel : _panic_trap_to_debugger + 0x1a9
0xffffff8005b0d4c0 : 0xffffff80065e08cb mach_kernel : _panic + 0x84
0xffffff8005b0d5b0 : 0xffffff8005f496b7 mach_kernel : _sync_iss_to_iks_unconditionally + 0x167
0xffffff8005b0d6c0 : 0xffffff80065e88f8 mach_kernel : _panic_double_fault64 + 0x27
0xffffff8005b0d6d0 : 0xffffff8005d85e4f mach_kernel : _hndl_double_fault + 0xf
0xffffffbe064c4020 : 0xffffff8008816cf2 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD10space_freeEP9vtd_spacejj + 0x1da
0xffffffbe064c4060 : 0xffffff800881678e com.apple.iokit.IOPCIFamily : __ZN8AppleVTD9checkFreeEP9vtd_spacej + 0xca
0xffffffbe064c40a0 : 0xffffff8008816211 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD11space_allocEP9vtd_spacejjjPK21IODMAMapSpecificationPK13upl_page_info + 0x125
0xffffffbe064c4140 : 0xffffff8008818c21 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD14spaceMapMemoryEP9vtd_spaceP18IOMemoryDescriptoryyjPK21IODMAMapSpecificationP12IODMACommandPK16IODMAMapPageListPySC_ + 0x23b
0xffffffbe064c4240 : 0xffffff800881960f com.apple.iokit.IOPCIFamily : __ZN20AppleVTDDeviceMapper13iovmMapMemoryEP18IOMemoryDescriptoryyjPK21IODMAMapSpecificationP12IODMACommandPK16IODMAMapPageListPySA_ + 0xb1
0xffffffbe064c42b0 : 0xffffff800652b0ef mach_kernel : __ZN25IOGeneralMemoryDescriptor6dmaMapEP8IOMapperP18IOMemoryDescriptorP12IODMACommandPK21IODMAMapSpecificationyyPyS9_ + 0x1df
0xffffffbe064c4340 : 0xffffff8006526a54 mach_kernel : __ZNK25IOGeneralMemoryDescriptor19dmaCommandOperationEjPvj + 0x2b4
0xffffffbe064c43f0 : 0xffffff800651c51a mach_kernel : __ZN12IODMACommand7prepareEyybb + 0x30a
0xffffffbe064c4520 : 0xffffff80085848ad com.apple.iokit.IONVMeFamily : __ZN24IONVMeBlockStorageDevice16doAsyncReadWriteEP18IOMemoryDescriptoryyP19IOStorageAttributesP19IOStorageCompletion + 0x365
0xffffffbe064c4600 : 0xffffff80089391ed com.apple.iokit.IOStorageFamily : __ZN20IOBlockStorageDriver14executeRequestEyP18IOMemoryDescriptorP19IOStorageAttributesP19IOStorageCompletionPNS_7ContextE + 0x129
0xffffffbe064c4670 : 0xffffff800893be07 com.apple.iokit.IOStorageFamily : __ZN20IOBlockStorageDriver14prepareRequestEyP18IOMemoryDescriptorP19IOStorageAttributesP19IOStorageCompletion + 0x21b
0xffffffbe064c4720 : 0xffffff80089428c2 com.apple.iokit.IOStorageFamily : __ZL11dkreadwritePv9dkrtype_t + 0x61c
0xffffffbe064c47d0 : 0xffffff8006020124 mach_kernel : _spec_strategy + 0x454
0xffffffbe064c4830 : 0xffffff8005fb6fd5 mach_kernel : _buf_strategy + 0x1f5
0xffffffbe064c48d0 : 0xffffff8008e952ff com.apple.filesystems.apfs : _apfs_vnop_strategy + 0x731
0xffffffbe064c49c0 : 0xffffff8005fc0a71 mach_kernel : _cluster_pageout_ext + 0x1011
0xffffffbe064c4b10 : 0xffffff8005fc96d5 mach_kernel : _advisory_read_ext + 0x365
0xffffffbe064c4bd0 : 0xffffff8005fc9989 mach_kernel : _advisory_read_ext + 0x619
0xffffffbe064c4c40 : 0xffffff8005fc67d7 mach_kernel : _cluster_read_ext + 0x827
0xffffffbe064c4e00 : 0xffffff8005fc6124 mach_kernel : _cluster_read_ext + 0x174
0xffffffbe064c4e70 : 0xffffff8008e9ec8e com.apple.filesystems.apfs : _apfs_nstream_read + 0x288
0xffffffbe064c4f40 : 0xffffff8008e9f6e3 com.apple.filesystems.apfs : _apfs_inode_getxattr + 0x1b5
0xffffffbe064c5030 : 0xffffff8008e9f508 com.apple.filesystems.apfs : _apfs_vnop_getxattr + 0xfb
0xffffffbe064c5080 : 0xffffff80060159ec mach_kernel : _VNOP_GETXATTR + 0x4c
0xffffffbe064c50d0 : 0xffffff80071feb99 com.apple.AppleFSCompression.AppleFSCompressionTypeZlib : _compression_decode_buffer + 0x198d
0xffffffbe064c5130 : 0xffffff80071fddbc com.apple.AppleFSCompression.AppleFSCompressionTypeZlib : _compression_decode_buffer + 0xbb0
0xffffffbe064c5220 : 0xffffff800602aa3b mach_kernel : _decmpfs_pagein_compressed + 0x7fb
0xffffffbe064c5390 : 0xffffff8008ebb739 com.apple.filesystems.apfs : _apfs_pagein_with_verification + 0x3a2
0xffffffbe064c54c0 : 0xffffff8008ebb257 com.apple.filesystems.apfs : _apfs_pagein + 0x8c3
0xffffffbe064c55c0 : 0xffffff8008eb1522 com.apple.filesystems.apfs : _apfs_vnop_pagein + 0xd7
0xffffffbe064c5600 : 0xffffff80063c2166 mach_kernel : _vnode_pagein + 0x1256
0xffffffbe064c5700 : 0xffffff8005e7f948 mach_kernel : _vnode_pager_cluster_read + 0x48
0xffffffbe064c5760 : 0xffffff8005e95ed5 mach_kernel : _vm_fault_page + 0x925
0xffffffbe064c5870 : 0xffffff8005e9072f mach_kernel : _vm_fault$XNU_INTERNAL + 0xf4f
0xffffffbe064c5ad0 : 0xffffff8005f483ba mach_kernel : _kernel_trap + 0x31a
0xffffffbe064c5b40 : 0xffffff8005d85951 mach_kernel : _return_from_trap + 0xc1
0xffffffbe064c5b60 : 0xffffff8005f02115 mach_kernel : _strncmp + 0x15
0xffffffbe064c5c50 : 0xffffff7f9cc2d4bd org.smichaud.HookCase : __Z11find_symbolPKcP13_symbol_table + 0xca
0xffffffbe064c5cb0 : 0xffffff7f9cc304f9 org.smichaud.HookCase : __Z15maybe_cast_hookP4proc + 0x4ee
0xffffffbe064c7e20 : 0xffffff7f9cc34be0 org.smichaud.HookCase : __Z28thread_bootstrap_return_hookP17x86_saved_state_tP10_kern_hook + 0xc4
0xffffffbe064c7e70 : 0xffffff7f9cc25055 org.smichaud.HookCase : _kernel_trampoline + 0x25
0xffffffbe064c7fa0 : 0xffffff8005d8519e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         com.apple.iokit.IOPCIFamily(2.9)[752CD69F-309E-31FF-881C-2A22ACB6C0B6]@0xffffff8008800000->0xffffff800882ffff
         com.apple.iokit.IOStorageFamily(2.1)[521B092C-AECB-357C-BE62-5E582EF058A2]@0xffffff8008933000->0xffffff8008949fff
         com.apple.iokit.IONVMeFamily(2.1)[2351626F-4F3C-3971-AAB5-08FCF53022E1]@0xffffff8008568000->0xffffff8008594fff
            dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[4E741445-0025-3DB8-8292-C7533F3C0917]@0xffffff8007392000->0xffffff80073c0fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[752CD69F-309E-31FF-881C-2A22ACB6C0B6]@0xffffff8008800000->0xffffff800882ffff
            dependency: com.apple.iokit.IOReportFamily(47)[EF0F8F2D-D40B-3B22-A3BC-8BB0145DA2F7]@0xffffff8008841000->0xffffff8008843fff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[521B092C-AECB-357C-BE62-5E582EF058A2]@0xffffff8008933000->0xffffff8008949fff
         com.apple.filesystems.apfs(2142.61.2)[11FBF316-D87F-396C-803B-F1CBD0C96179]@0xffffff8008e4c000->0xffffff8008fdbfff
            dependency: com.apple.driver.AppleEFINVRAM(2.1)[53554E15-F0D2-3EA5-BB35-30ED9C5283EA]@0xffffff80071bd000->0xffffff80071c6fff
            dependency: com.apple.driver.AppleEffaceableStorage(1.0)[BFFA34B0-1747-3367-8C51-665BCD859E31]@0xffffff80071d3000->0xffffff80071d8fff
            dependency: com.apple.iokit.CoreAnalyticsFamily(1)[D0FF0186-6F90-3AF1-9F7E-A2BD383CCA20]@0xffffff80076dc000->0xffffff80076e5fff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[521B092C-AECB-357C-BE62-5E582EF058A2]@0xffffff8008933000->0xffffff8008949fff
            dependency: com.apple.kec.corecrypto(12.0)[7A2A4035-FDBB-38A2-88B7-7AF62A0BD48B]@0xffffff8009021000->0xffffff8009099fff
            dependency: com.apple.security.AppleImage4(5.0.0)[726F02C0-67F1-3D38-9BE4-CDFE14227DAE]@0xffffff800725e000->0xffffff800727cfff

Process name corresponding to current thread (0xffffff8b85f10598): ls
Boot args: keepsyms=1
@steven-michaud
Copy link
Owner

Your kernel panic is almost identical to the one reported at issue #42 on HookCase 7.1.0. Are you also running macOS from an external drive?

What version of macOS are you using? Is your Mac a Hackintosh?

There is no "HookCase 7.1.3". I assume you're running version 7.1.2.

The panics happen deep in Apple code, and I've never seen anything like them (though I use HookCase a lot, on several different kinds of hardware). I don't think HookCase can be the cause of these panics, though it may be a contributing factor. But if it is, there are no recent changes that can explain how.

Here's a more-or-less random suggestion: Try disabling watchpoints and rebuilding.

@steven-michaud steven-michaud changed the title HookCase 7.1.3 cause kernel panic sometimes Occasional kernel panic on HookCase 7.1.2 Mar 24, 2023
@steven-michaud
Copy link
Owner

steven-michaud commented Mar 25, 2023 •
edited
Loading

For what it's worth, I've created a bootable macOS 13.2.1 partition on an external drive (a 1TB Seagate FireCuda NVMe Thunderbolt 3 SSD), and have been using HookCase from it (version 7.1.2, the current version) on a MacBookPro16,1 with 32GB of RAM. I've had no problems, and certainly not any kernel panics. I'll keep using it for the next week or so, and see what happens.

Both your kernel panic log and the one from Issue 42 indicate the use of file system compression. This isn't something that happens automatically. You must have used some kind of utility to compress some or all of the files on one or more of your drives. Tell me as much as you can about this.

@steven-michaud
Copy link
Owner

steven-michaud commented Mar 26, 2023 •
edited
Loading

This isn't something that happens automatically.

Oops, I was wrong about this. I built afsctool and used it to check how many files on my MacBook Pro were already compressed. I didn't expect to find any, but found lots. The number of files on my built-in SSD was only a small proportion of the total -- about 1%, for a total size saving of 3.1%. But the proportion was much higher on my external SSD -- about 28%, for a total size saving of about 40%.

So you may not have used any file system compression utilities. Though please tell me if you have.

Please also tell me as much as you can about the system you're using. At a minimum I need answers to all of the following questions:

  1. What version of macOS are you using?
  2. What kind of Mac are you using?
  3. Is your boot partition on an external drive? If so what kind?
  4. How often have you seen the kernel panic you reported? (This isn't clear from your comment above.)
  5. Is the kernel panic reproducible? If so, tell me the steps you use to reproduce it.
  6. Does disabling watchpoints make any difference?

@liuyi12138
Copy link
Author

This isn't something that happens automatically.

Oops, I was wrong about this. I built afsctool and used it to check how many files on my MacBook Pro were already compressed. I didn't expect to find any, but found lots. The number of files on my built-in SSD was only a small proportion of the total -- about 1%, for a total size saving of 3.1%. But the proportion was much higher on my external SSD -- about 28%, for a total size saving of about 40%.

So you may not have used any file system compression utilities. Though please tell me if you have.

Please also tell me as much as you can about the system you're using. At a minimum I need answers to all of the following questions:

  1. What version of macOS are you using?
  2. What kind of Mac are you using?
  3. Is your boot partition on an external drive? If so what kind?
  4. How often have you seen the kernel panic you reported? (This isn't clear from your comment above.)
  5. Is the kernel panic reproducible? If so, tell me the steps you use to reproduce it.
  6. Does disabling watchpoints make any difference?
  1. I'm using Ventura 13.2.1 with xnu-8792.81.3
  2. I'm using a MacBookPro with Four Inter Core I5, not Hackintosh
  3. my external drive not on an external drive
  4. the panic happend everytime when i try to inject
  5. If i use HookCase 7.1.2 everytime i try to inject, the panic happed, then i try HookCase 7.1.1 , panic happen again. so i try to reinstall my mac, and try HookCase 7.1.1, it works. So i think maybe HookCase 7.1.2 cause it.
  6. disabling watchpoints does not work for me, panic happen either.

And i also try it in a virtual machine mac 12.6, the panic would not happed, I hope it will be useful for you.

@steven-michaud
Copy link
Owner

steven-michaud commented Mar 27, 2023 •
edited
Loading

Thanks for your information. It's not enough to resolve the problem. But, looking again at your kernel panic log and the one from issue #42, I now realize these panics have nothing to do with file system compression. As the values of CR2 and RSP show, they're kernel stack underflows. It just so happens that the decompression code runs deep enough on the call stack to often trigger them.

If I'm right about this, the fix should be easy: Add kernel_stack_pages=6 to your kernel boot args (using sudo nvram boot-args=...). Or if that argument is already present, increase its value to kernel_stack_pages=8.

What are your current kernel boot args? What does nvram boot-args return?

Are you using any other non-Apple kernel extensions?

@steven-michaud steven-michaud changed the title Occasional kernel panic on HookCase 7.1.2 Persistent kernel panic on HookCase 7.1.2 Mar 27, 2023
@steven-michaud
Copy link
Owner

6. disabling watchpoints does not work for me, panic happen either.

"panic happen either" should be "panics still happen".

@steven-michaud
Copy link
Owner

Just so that you're aware: Don't upgrade to macOS 13.3 for the time being. It breaks HookCase.

@liuyi12138
Copy link
Author

Thanks for your information. It's not enough to resolve the problem. But, looking again at your kernel panic log and the one from issue #42, I now realize these panics have nothing to do with file system compression. As the values of CR2 and RSP show, they're kernel stack underflows. It just so happens that the decompression code runs deep enough on the call stack to often trigger them.

If I'm right about this, the fix should be easy: Add kernel_stack_pages=6 to your kernel boot args (using sudo nvram boot-args=...). Or if that argument is already present, increase its value to kernel_stack_pages=8.

What are your current kernel boot args? What does nvram boot-args return?

Are you using any other non-Apple kernel extensions?

I didn't use any other non-Apple kernel extensions, and set kernel_stack_pages=6or kernel_stack_pages=8 didn't work for me. boot-args just include keepsyms=1 before i set kernel_stack_pages.

@steven-michaud
Copy link
Owner

steven-michaud commented Mar 28, 2023 •
edited
Loading

After you use sudo nvram boot-args=... to change your kernel boot args, you need to reboot your computer for the change to take effect. I hope you did this before re-running your tests.

Assuming that you did, here are two more requests:

  1. Please post your latest kernel panic log. It may have changed from your first log.
  2. Set kernel_stack_pages=6, reboot your computer, and run sysctl kern.stack_size in a Terminal session. If the kernel_stack_pages setting actually took effect, the result should be 24576 (== 4096 * 6). Let me know your results. Also try this with kernel_stack_pages=8. For that, the results of sysctl kern.stack_size should be 32768.

@steven-michaud
Copy link
Owner

Some more questions:

  1. What version of XCode are you using to build HookCase?
  2. How are you building it? From the command line using xcodebuild? If not I suggest trying that. Run xcodebuild clean to clean up your previous work, then run xcodebuild.

@liuyi12138
Copy link
Author

liuyi12138 commented Mar 29, 2023 •
edited
Loading

After you use sudo nvram boot-args=... to change your kernel boot args, you need to reboot your computer for the change to take effect. I hope you did this before re-running your tests.

Assuming that you did, here are two more requests:

  1. Please post your latest kernel panic log. It may have changed from your first log.
  2. Set kernel_stack_pages=6, reboot your computer, and run sysctl kern.stack_size in a Terminal session. If the kernel_stack_pages setting actually took effect, the result should be 24576 (== 4096 * 6). Let me know your results. Also try this with kernel_stack_pages=8. For that, the results of sysctl kern.stack_size should be 32768.

my kernel_stack_pages is right When kernel_stack_pages=6 and kernel_stack_pages=8, but the kernel panic log did't change.

@liuyi12138
Copy link
Author

Some more questions:

  1. What version of XCode are you using to build HookCase?
  2. How are you building it? From the command line using xcodebuild? If not I suggest trying that. Run xcodebuild clean to clean up your previous work, then run xcodebuild.

I use Xcode 13 and i build it by using xcodebuild

@liuyi12138
Copy link
Author

By the way, everytime after i use HookCase 7.1.2, then if i try HookCase 7.1.1, the panic still panic.
So i reinstall my system everytime after the panic happed. After reinstall, HookCase 7.1.1 will work.
Hope it will be useful for you.
And my system update to 13.3 after reinstall yesterday, I will try to reproduce it in a VM machine.

@steven-michaud
Copy link
Owner

I use Xcode 13 and i build it by using xcodebuild

You really should be using XCode 14 (14.1 or 14.2). The reason is that XCode 13's SDK is for macOS 12. XCode 14's SDK is for macOS 13. Try downloading XCode 14 and rebuilding HookCase. You'll also need to install its command line tools.

You kernel panics are a mystery to me -- one I don't have the information to solve. There must be something about your system that's unusual, but I can't guess what. I've run out of questions to ask about it.

On the chance there's something wrong with your hard drive, you should run Disk Utility's First Aid on it.

@steven-michaud
Copy link
Owner

So i reinstall my system everytime after the panic happed. After reinstall, HookCase 7.1.1 will work.

What do you mean by "reinstall my system"? Do you reinstall macOS 13?

@liuyi12138
Copy link
Author

So i reinstall my system everytime after the panic happed. After reinstall, HookCase 7.1.1 will work.

What do you mean by "reinstall my system"? Do you reinstall macOS 13?

yes, i start up my computer in macOS Recovery, and select reinstall for your my release.
Firstly, I begin to reinstall and then exit quickly, the panic will disappear.
Yesterday i try HookCase with kernel_stack_pages=8, but the panic still happened, so i reinstall the system once and for all, so it update to 13.3.
I don't know if this has anything to do with kernel_stack_pages, i can not try it again

@steven-michaud
Copy link
Owner

steven-michaud commented Mar 29, 2023 •
edited
Loading

Firstly, I begin to reinstall and then exit quickly, the panic will disappear.

I don't know what you mean by "exit quickly", but this doesn't sound safe. You probably shouldn't do it. Nor do I have any idea why it seems to "work". I don't object to your reinstalling macOS. Just don't interrupt it like this.

It does sound like there's something wrong with your hard disk. You really should run Disk Utility's First Aid on it.

You should always build HookCase on the same version of macOS where you're going to use it, with an appropriate version of XCode. In your case you should build HookCase (the next version) on macOS 13.3 with XCode 14.1 or 14.2.

You should set kernel_stack_pages=8 now, using sudo nvram boot-args="keepsyms=1 kernel_stack_pages=8". Then restart your computer. This should prepare you for when I release the next version of HookCase, sometime in the next few days. It will work around the breakage caused by changes in macOS 13.3.

@liuyi12138
Copy link
Author

Firstly, I begin to reinstall and then exit quickly, the panic will disappear.

I don't know what you mean by "exit quickly", but this doesn't sound safe. You probably shouldn't do it. Nor do I have any idea why it seems to "work". I don't object to your reinstalling macOS. Just don't interrupt it like this.

It does sound like there's something wrong with your hard disk. You really should run Disk Utility's First Aid on it.

You should always build HookCase on the same version of macOS where you're going to use it, with an appropriate version of XCode. In your case you should build HookCase (the next version) on macOS 13.3 with XCode 14.1 or 14.2.

You should set kernel_stack_pages=8 now, using sudo nvram boot-args="keepsyms=1 kernel_stack_pages=8". Then restart your computer. This should prepare you for when I release the next version of HookCase, sometime in the next few days. It will work around the breakage caused by changes in macOS 13.3.

ok, i will wait for the next version of HookCase and try again.

@steven-michaud
Copy link
Owner

I've just released HookCase 7.1.3, which works on macOS 13.3.

@steven-michaud
Copy link
Owner

You didn't tell me, but you are using third party kernel extensions (besides HookCase). In fact you're using the OpenCore Legacy Patcher. I've now started using it myself, to install macOS Ventura 13.3.1 on a machine that Apple says doesn't support Ventura -- a "mid-2015 MacBook Pro", model id MacBookPro11,5.

I now get exactly the kernel panic you reported. Setting kernel_stack_pages to 6 or 8 doesn't help. I'll keep looking for workarounds. But for now HookCase is incompatible with OCLP.

@steven-michaud steven-michaud changed the title Persistent kernel panic on HookCase 7.1.2 HookCase appears to be incompatible with the OpenCore Legacy Patcher May 11, 2023
@steven-michaud
Copy link
Owner

I'm closing this as a duplicate of issue #42.

@steven-michaud
Copy link
Owner

I no longer think this is a duplicate of issue #42, but I'm still pretty sure you're using OCLP.

I'm about to release a new version of HookCase that works with OCLP, at least in my tests. I found I could get rid of this bug's panic by using a kernel_stack_pages=16 boot arg. But afterwards there were a few other, different kernel panics that I also needed to fix.

@steven-michaud steven-michaud changed the title HookCase appears to be incompatible with the OpenCore Legacy Patcher Persistent double fault kernel panics, probably caused by OpenCore Legacy Patcher May 15, 2023
@steven-michaud
Copy link
Owner

I've just released HookCase 7.3, which should fix these kernel panics. See Using the OpenCore Legacy Patcher for detailed instructions on how to set kernel_stack_pages.

@liuyi12138
Copy link
Author

I didn't actually use the OpenCore Legacy Patcher. But i will try HookCase 7.3 and watch if it panic again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@steven-michaud @liuyi12138