WD SN850 panic

[Bergier3K]

Hello good people, I'm recently experiencing random panics that seem to related to my NVMe drive, that is odd, because I picked a SN850 especially for its "compatibility" with MacOs. It's been running perfectly for almost a year, and about a month ago the panics started out of the blue...

Any idea why ?

Extract from the report "
panic(cpu 2 caller 0xffffff800678c676): nvme: "3rd party NVMe controller. Controller fatal bit set. Delete IO submission queue. fBuiltIn=1 MODEL=WDS500G1X0E-00AFY0 FW=613000WD CSTS=0x3 US[1]=0x0 US[0]=0x82 VID=0x15b7 DID=0x5011 CRITICAL_WARNING=0x0.\n" @IONVMeController.cpp:6151

Panicked task 0xffffff8be99ed218: 287 threads: pid 0: kernel_task"

I can add the whole report if needed...

Cheers !

 

[Edhawk]

Do you regularly run Trim on your system, so the Garbage collector can clean up your WD SN850?

• Fixed SetApfsTrimTimeout on macOS 12 (only works when set to zero)

This was added to OC release 0.7.9, which version are you using?

Are you using NvmeFix.kext in your OC setup for NVME power control?
Which version of the kext are you using, the latest?

GitHub - acidanthera/NVMeFix

Contribute to acidanthera/NVMeFix development by creating an account on GitHub.

github.com

 

[Bergier3K]

@Edhawk thanx again

I though Trim was running automatically during boot, no ?

1. SetApfsTrimTimeout is set to -1.
2. NvmeFix.kext is not used, therefore the SN850 is supposed to be working really well without it, and it indeed worked flawlessly for about 6 months.
3. OC version is 0.8.5

 

[Edhawk]

No, the -1 timeout entry stops Trim from running. It doesn't disable Trim just stops it from running. To disable Trim you need to specify '0' in place of '-1'.

You may need to enable the Kernel > Quirks > ThirdPartyDrives option for Trim to be enabled on your drive.

Alternatively you can try using the sudo TrimForce Enable terminal command.

If your drive is full, or the system thinks your drive is full because the deleted files/pages have not been removed by the 'Garbage Collector' feature. Then Trim won't run as it requires an area of free space on the drive to work.

The OC developers point to a Russian site/guide in their Configuration.pdf, which explains what Trim is for and What it does. After reading the page it seems to say the best way to keep a drive in top performance is to allocate 20-25% of the drive as an unused area, i.e. unpartitioned free space. Which the rest of the drive can use to enable Trim and Garbage Collection, without causing any adverse effects. This is something similar to how Server drives are setup, with extended read/write and performance capabilities.

The Configuration.pdf is within the Docs folder (alongside the Sample.plist) look at pages 37 & 38 for details on Trim functions within OpenCore.

The Russian Trim Article is linked on page 37.

 

[Bergier3K]

@Edhawk I remember reading something about an empty unmapped partition, and I forgot about it instantly I will do that. And you were right, my drive was getting crowded, I made some space now. However, after reading the documentation, it remains unclear to me if SetApfsTrimTimeout should be -1 or 0, and if ThirdPartyDrives should be enabled. Do you have any insight on this ?

Note that the problem didn't occur since last time, maybe making some space did the trick....

 

[Edhawk]

Leave SetApfsTrimTimeout as -1

Enable the ThirdPartyDrives quirk.

 

[Bergier3K]

Undergoing testing with ThirdPartyDrives enabled and some free space on the drive. If the panics stop, I will tag the thread as success.

Thanx for the help @Edhawk !

 

[Bergier3K]

Unfortunately ThirdPartyDrives doesn't seem to make the SN850 more stable. I got another crash out of the blue :

panic(cpu 0 caller 0xffffff8006f8c676): nvme: "3rd party NVMe controller. Controller fatal bit set. Delete IO submission queue. fBuiltIn=1 MODEL=WDS500G1X0E-00AFY0 FW=613000WD CSTS=0x3 US[1]=0x0 US[0]=0x94 VID=0x15b7 DID=0x5011 CRITICAL_WARNING=0x0.\n" @IONVMeController.cpp:6151
Panicked task 0xffffff8bc342a218: 294 threads: pid 0: kernel_task
Backtrace (CPU 0), panicked thread: 0xffffff908f2eb0c8, Frame : Return Address
0xffffffcae8dbbaa0 : 0xffffff80047edf9d mach_kernel : _handle_debugger_trap + 0x4ad
0xffffffcae8dbbaf0 : 0xffffff800495b786 mach_kernel : _kdp_i386_trap + 0x116
0xffffffcae8dbbb30 : 0xffffff800494aa10 mach_kernel : _kernel_trap + 0x3e0
0xffffffcae8dbbb80 : 0xffffff8004788951 mach_kernel : _return_from_trap + 0xc1
0xffffffcae8dbbba0 : 0xffffff80047ee27d mach_kernel : _DebuggerTrapWithState + 0x5d
0xffffffcae8dbbc90 : 0xffffff80047ed929 mach_kernel : _panic_trap_to_debugger + 0x1a9
0xffffffcae8dbbcf0 : 0xffffff8004fe0ecb mach_kernel : _panic + 0x84
0xffffffcae8dbbde0 : 0xffffff8006f8c676 com.apple.iokit.IONVMeFamily : __ZN16IONVMeController14CommandTimeoutEP16AppleNVMeRequest.cold.1
0xffffffcae8dbbdf0 : 0xffffff8006f6f7db com.apple.iokit.IONVMeFamily : __ZN16IONVMeController13FatalHandlingEv + 0x141
0xffffffcae8dbbe20 : 0xffffff8006f77c04 com.apple.iokit.IONVMeFamily : __ZN16IONVMeController22ProcessCompletionQueueEP24AppleNVMeCompletionQueue + 0x2a6
0xffffffcae8dbbe90 : 0xffffff8006f75e23 com.apple.iokit.IONVMeFamily : __ZN16IONVMeController22HandleInterruptRequestEP22IOInterruptEventSourcei + 0xdf
0xffffffcae8dbbed0 : 0xffffff8004f14d04 mach_kernel : __ZN22IOInterruptEventSource12checkForWorkEv + 0x114
0xffffffcae8dbbf20 : 0xffffff8004f135fe mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x12e
0xffffffcae8dbbf60 : 0xffffff8004f12c37 mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x37
0xffffffcae8dbbfa0 : 0xffffff800478819e mach_kernel : _call_continuation + 0x2e
Kernel Extensions in backtrace:
com.apple.iokit.IONVMeFamily(2.1)[C5B719D4-17A7-38C9-A9C5-3C256948B95D]@0xffffff8006f67000->0xffffff8006f93fff
dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[2E7C729D-2485-32DC-B478-D490A81E1419]@0xffffff8005d91000->0xffffff8005dbffff
dependency: com.apple.iokit.IOPCIFamily(2.9)[E2CE416B-59DA-3836-9985-FDC527C5E6C7]@0xffffff80071ff000->0xffffff800722efff
dependency: com.apple.iokit.IOReportFamily(47)[3115840D-90F4-383F-8991-D3CF8891C24C]@0xffffff8007240000->0xffffff8007242fff
dependency: com.apple.iokit.IOStorageFamily(2.1)[FB7B8D23-9A09-33DA-89B8-FC81EAA04353]@0xffffff8007332000->0xffffff8007348fff

Process name corresponding to current thread (0xffffff908f2eb0c8): kernel_task
Boot args: keepsyms=1 dk.e1000=0 -wegbeta agdpmod=pikera -no_compat_check amfi_get_out_of_my_way=1

 

[trs96]

It's been running perfectly for almost a year, and about a month ago the panics started out of the blue...

ThirdPartyDrives doesn't seem to make the SN850 more stable.

I don't think it's correct to blame the hardware (SSD) for the kernel panics unless the drive itself is failing. Why not run something like Crystal Disk Info in Windows to determine if it's actually the drive or something software or EFI folder related instead ? Drives can and do fail but you really need to determine if that's the direct cause of the kernel panics first.

As @Edhawk mentions, we need to know the size of the drive and how much free space is left on it. I haven't seen that stated anywhere.

 

[Bergier3K]

@trs96 I have to shamefully confess the fact that I didn't think of using Crystal Disk Info under Windows I will do that next reboot. Though I think the hardware itself is not to blame, the drive is fairly new and WD is usually quite reliable. But it needs to be tested so I can remove that possibility, great idea !

I have never looked into the relationship between EFI/plist and my drives, because they all have worked right of the box without problems (I started hackintoshing with Mavericks and had numerous drives of all sorts without an issue). I might be wrong, but I think the problems started after updating from Monterey to Ventura.

Are there any usual suspects in the EFI/plist that I should look into ?