Data collection for proper issue reporting, regular panics

[incumbent]

hello,

i had to rebuild my workstation that uses a thunderbolt 3 NVME jbod and an external USB jbod of mechanical drives. I have unloaded the extensions for preview releases of 2.2.3 and stable release 2.2.2 on intel macOS Sonoma 14.4.1 in order to run exhaustive hardware testing because this intel mini is panicking and bouncing multiple times a day. since unloading OpenZFS kext entirely it has been stable but this is not how I need to use this workstation. i'm in the process of getting a new creative workstation to replace the mini anyway but i suspect if there is a problem with OpenZFS i'll still be getting spontaneous reboots just on a more expensive machine

if i don't have time/hardware for hitching up another mac for proper debugging, which is way over my head anyway, i am trying to figure out what i should be collecting and how i should configure things to collect useful data that could be used in an issue report, although i don't have anything pointing to ZFS other than the fact that it's been stable running Rember on endless loops for 48 hours and previously it never went longer than 12 hours without a kernel panic that implicates APFS.

i'm having a heck of a time finding the root cause, i suspected it was hardware at first but the apple repair center near me here wanted to use the 8GB of RAM it shipped with for their testing and they didn't see anything wrong. i don't see anything wrong with 64GB in there other than it occasionally reboots.i have OWC and Crucial 2x32GB and i don't even want to boot this thing with 8GB installed unless my zpools aren't connected.

if i don't have another mac attached for debugging, what can i do to submit a proper report? i don't want to hassle anyone here with a wild goose chase so i figure i would take suggestions. i can't find the wiki page that i thought talked about this scenario where i don't have another development machine hooked up to this basket case. if you're curious here's one or two excerpts from the diagnostic dump it sends to apple every every one of these panics:

most of them look like this in the kernel extensions in backtrace:

Code: Select all

      Kernel Extensions in backtrace:
         com.apple.filesystems.apfs(2236.101.1)[0055B7C6-B196-3361-BF71-3B8A4B66DCD9]@0xffffff80065ef000->0xffffff80067a1fff
            dependency: com.apple.driver.AppleEFINVRAM(2.1)[94B0A0E7-BA52-30BC-B65B-30282BF844E4]@0xffffff80050b3000->0xffffff80050bdfff
            dependency: com.apple.driver.AppleEffaceableStorage(1.0)[D5CCC882-9FDA-32BA-99C3-D500724CE7CD]@0xffffff80050ca000->0xffffff80050cffff
            dependency: com.apple.iokit.CoreAnalyticsFamily(1)[E1F636C6-9D4A-3288-B37E-5A5AEB4CD6CA]@0xffffff8005682000->0xffffff800568bfff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[1EEEAAAA-95C2-3606-8488-591BE79DB5B4]@0xffffff800609c000->0xffffff80060b2fff
            dependency: com.apple.kec.corecrypto(14.0)[A9D9B3D6-1F98-357A-AE06-E1D8B5BD31F2]@0xffffff80067e7000->0xffffff8006863fff
            dependency: com.apple.security.AppleImage4(6.3.0)[EED3E65A-C662-391F-AEB8-11A32115BCCD]@0xffffff8005139000->0xffffff800515afff

Process name corresponding to current thread (0xffffff91466e40c8): kernel_task


another example:

Code: Select all

         com.apple.filesystems.apfs(2236.101.1)[0055B7C6-B196-3361-BF71-3B8A4B66DCD9]@0xffffff8017fef000->0xffffff80181a1fff
            dependency: com.apple.driver.AppleEFINVRAM(2.1)[94B0A0E7-BA52-30BC-B65B-30282BF844E4]@0xffffff8016ab3000->0xffffff8016abdfff
            dependency: com.apple.driver.AppleEffaceableStorage(1.0)[D5CCC882-9FDA-32BA-99C3-D500724CE7CD]@0xffffff8016aca000->0xffffff8016acffff
            dependency: com.apple.iokit.CoreAnalyticsFamily(1)[E1F636C6-9D4A-3288-B37E-5A5AEB4CD6CA]@0xffffff8017082000->0xffffff801708bfff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[1EEEAAAA-95C2-3606-8488-591BE79DB5B4]@0xffffff8017a9c000->0xffffff8017ab2fff
            dependency: com.apple.kec.corecrypto(14.0)[A9D9B3D6-1F98-357A-AE06-E1D8B5BD31F2]@0xffffff80181e7000->0xffffff8018263fff
            dependency: com.apple.security.AppleImage4(6.3.0)[EED3E65A-C662-391F-AEB8-11A32115BCCD]@0xffffff8016b39000->0xffffff8016b5afff


i've confirmed that it is/was using 2.2.2 release again, i look in the loaded kexts on the crash report to apple and all the recent ones have `org.openzfsonosx.zfs 2.2.2` listed so at least i'm not somehow still on 2.2.3-prerelease.

thanks for reading and any suggestions

[jawbroken]

Did you test your 64GB memory, at least? Or you should try with the 8GB of RAM that passed testing, at least. I don't see any ZFS kernel extensions in those backtraces, which is unusual if ZFS related (but not impossible I think). Do you have an APFS-formatted drive as well?

[incumbent]

i have tested three sets of memory and they're all as intended, although the machine failed a dozen net installs until the apple 8GB was in there. unbelievable.

there's some discussion in two other threads that are similar to my problem and tl;dr after changing all of my mimic APFS properties to hfs it hasn't panicked once. i am not qualified to hypothesize especially a coincidence but this thing was panicking non stop while i ran a giant brew bundle install and nothing else changed.