Hi. I have three disk partitions on my MacBook Air M1. The one with Monterey, the one with Sonoma, and the one with Sequoia (15.3.1 in particular). When I try to download the 15.4 Beta from software update in settings, everything would go "fine" - the download process is being completed, the computer says it's going to restart in 60seconds, the countdown begins, etc. However, when restarting several times, I am being logged in once again into previous macOS (15.3.1) version, with a kernel panic report. I had the same panic on macOS 15.3 when attempting to download 15.4 Beta. I've upgraded my macOS to 15.3.1, as I thought I'd need the very last available version of regular macOS to participate in the newest beta. However, the panic occurs, pointing to some t8020dart.c file. I don't even theoretically know what is this and couldn't find any reference to that C file. Attaching a part of panic report: panic(cpu 3 caller 0x0): t8020dart 0xfffffdf02c980000 (dart-disp0): Can't ignore lock validation @t8020dart.c:535 Debugger message: panic Memory ID: 0xff OS release type: Not set yet OS version: Not set yet Kernel version: Darwin Kernel Version 24.4.0: Sat Feb 15 22:43:38 PST 2025; root:xnu-11417.100.533.501.4~3/RELEASE_ARM64_T8103 Fileset Kernelcache UUID: 232D67A6D42C66E14780A24B3C0AE05D Kernel UUID: F2602757-A486-30A9-8D8E-714224E5FE4A Boot session UUID: 575CD5EA-6898-47ED-9AEC-05E318135695 iBoot version: iBoot-11881.100.964.0.1 iBoot Stage 2 version: iBoot-11881.100.964.0.1 secure boot?: YES roots installed: 0 Paniclog version: 14 KernelCache slide: 0x00000000181d8000 KernelCache base: 0xfffffe001f1dc000 Kernel slide: 0x00000000181e0000 Kernel text base: 0xfffffe001f1e4000 Kernel text exec slide: 0x00000000198d0000 Kernel text exec base: 0xfffffe00208d4000 mach_absolute_time: 0x85b39c4 Epoch Time: sec usec Boot : 0x00000000 0x00000000 Sleep : 0x00000000 0x00000000 Wake : 0x00000000 0x00000000 Calendar: 0x00000000 0x00000000 Zone info: Zone map: 0xfffffe120c000000 - 0xfffffe380c000000 . VM : 0xfffffe120c000000 - 0xfffffe17d8000000 . RO : 0xfffffe17d8000000 - 0xfffffe1a72000000 . GEN0 : 0xfffffe1a72000000 - 0xfffffe203e000000 . GEN1 : 0xfffffe203e000000 - 0xfffffe260a000000 . GEN2 : 0xfffffe260a000000 - 0xfffffe2bd6000000 . GEN3 : 0xfffffe2bd6000000 - 0xfffffe31a2000000 . DATA : 0xfffffe31a2000000 - 0xfffffe380c000000 Metadata: 0xfffffe76ce010000 - 0xfffffe76d7810000 Bitmaps : 0xfffffe76d7810000 - 0xfffffe76d8d80000 Extra : 0 - 0 CORE 0 recently retired instr at 0xfffffe0020a9d2d0 CORE 1 recently retired instr at 0xfffffe0020a9d2d0 CORE 2 recently retired instr at 0xfffffe0020a9d2d0 CORE 3 recently retired instr at 0xfffffe0020a9b9ec CORE 4 recently retired instr at 0xfffffe0020a9d2d0 CORE 5 recently retired instr at 0xfffffe0020a9d2d0 CORE 6 recently retired instr at 0xfffffe0020a9d2d0 CORE 7 recently retired instr at 0xfffffe0020a9d2d0 TPIDRx_ELy = {1: 0xfffffe2040392fb0 0: 0x0000000000000003 0ro: 0x0000000000000000 } CORE 0 PVH locks held: None CORE 1 PVH locks held: None CORE 2 PVH locks held: None CORE 3 PVH locks held: None CORE 4 PVH locks held: None CORE 5 PVH locks held: None CORE 6 PVH locks held: None CORE 7 PVH locks held: None CORE 0: PC=0xfffffe002102157c, LR=0xfffffe0021021568, FP=0xfffffebf22637890 CORE 1: PC=0xfffffe00210207a4, LR=0xfffffe0020fe4eb0, FP=0xfffffebf2262b890 CORE 2: PC=0xfffffe002094c790, LR=0xfffffe002094c63c, FP=0xfffffebf22643890 CORE 3 is the one that panicked. Check the full backtrace for details. CORE 4: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2213fed0 CORE 5: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf22163ed0 CORE 6: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2216fed0 CORE 7: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2211bed0 Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space Panicked task 0xfffffe260c042b78: 0 pages, 268 threads: pid 0: kernel_task Panicked thread: 0xfffffe2040392fb0, backtrace: 0xfffffebf22666920, tid: 279 lr: 0xfffffe00209332bc fp: 0xfffffebf226669b0 lr: 0xfffffe0020a93cdc fp: 0xfffffebf22666a20 lr: 0xfffffe0020a91e94 fp: 0xfffffebf22666ae0 lr: 0xfffffe00208dbb94 fp: 0xfffffebf22666af0 lr: 0xfffffe0020932ba0 fp: 0xfffffebf22666ec0 lr: 0xfffffe0020932924 fp: 0xfffffe0031577e90 lr: 0xfffffe00211cb198 fp: 0xfffffe0031577eb0 lr: 0xfffffe002120aae4 fp: 0xfffffe0031577f80 lr: 0xfffffe00211f9104 fp: 0xfffffe0031577fe0 lr: 0xfffffe00208dc3fc fp: 0xfffffebf22666ee0 lr: 0xfffffe0020a82d74 fp: 0xfffffebf22666f30 lr: 0xfffffe00222f9964 fp: 0xfffffebf22667c00 lr: 0xfffffe002107c198 fp: 0xfffffebf22667c90 lr: 0xfffffe002107b79c fp: 0xfffffebf22667dc0 lr: 0xfffffe002107963c fp: 0xfffffebf22667e40 lr: 0xfffffe002107ffc8 fp: 0xfffffebf22667f20 lr: 0xfffffe00208e4f04 fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.AppleT8020DART(1.0)[6BE1928B-115D-345C-B457-FD1101FC7E1E]@0xfffffe00222f9120->0xfffffe002230139b dependency: com.apple.driver.AppleARMPlatform(1.0.2)[4EB15554-31E0-3057-9A85-EAA79C69E848]@0xfffffe0021369200->0xfffffe00213bf21f dependency: com.apple.driver.IODARTFamily(1)[8FC5A69F-6052-3F02-9EA3-78D080116812]@0xfffffe0022ec6750->0xfffffe0022eda9cf last started kext at 139867172: com.apple.plugin.IOgPTPPlugin 1340.12 (addr 0xfffffe001fba3f70, size 139368)

Hi. I am facing a panic in distributed virtual filesystem of my own making. The panic arises on attempt of copying a large folder, or writing a large file (both around 20gb). An important note here is that the amount of files we try to copy is larger than available space (for testing purposes, the virtual file system had a capacity of 18 gigabytes). The panic arises somewhere on 12-14gigabytes deep into copying. On the moment of panic, there are still several gigabytes of storage left. The problem is present for sure for such architectures and macOS versions: Sonoma 14.7.1 arm64e Monterey 12.7.5 arm64e Ventura 13.7.1 intel Part from panic log from Ventura 13.7.1 intel, with symbolicated addresses: panic(cpu 2 caller 0xffffff80191a191a): watchdog timeout: no checkins from watchdogd in 90 seconds (48 total checkins since monitoring last enabled) Panicked task 0xffffff907c99f698: 191 threads: pid 0: kernel_task Backtrace (CPU 2), panicked thread: 0xffffff86e359cb30, Frame : Return Address 0xffffffff001d7bb0 : 0xffffff8015e70c7d mach_kernel : _handle_debugger_trap + 0x4ad 0xffffffff001d7c00 : 0xffffff8015fc52e4 mach_kernel : _kdp_i386_trap + 0x114 0xffffffff001d7c40 : 0xffffff8015fb4df7 mach_kernel : _kernel_trap + 0x3b7 0xffffffff001d7c90 : 0xffffff8015e11971 mach_kernel : _return_from_trap + 0xc1 0xffffffff001d7cb0 : 0xffffff8015e70f5d mach_kernel : _DebuggerTrapWithState + 0x5d 0xffffffff001d7da0 : 0xffffff8015e70607 mach_kernel : _panic_trap_to_debugger + 0x1a7 0xffffffff001d7e00 : 0xffffff80165db9a3 mach_kernel : _panic_with_options + 0x89 0xffffffff001d7ef0 : 0xffffff80191a191a com.apple.driver.watchdog : IOWatchdog::userspacePanic(OSObject*, void*, IOExternalMethodArguments*) (.cold.1) 0xffffffff001d7f20 : 0xffffff80191a10a1 com.apple.driver.watchdog : IOWatchdog::checkWatchdog() + 0xd7 0xffffffff001d7f50 : 0xffffff80174f960b com.apple.driver.AppleSMC : SMCWatchDogTimer::watchdogThread() + 0xbb 0xffffffff001d7fa0 : 0xffffff8015e1119e mach_kernel : _call_continuation + 0x2e Kernel Extensions in backtrace: com.apple.driver.watchdog(1.0)[BD08CE2D-77F5-358C-8F0D-A570540A0BE7]@0xffffff801919f000->0xffffff80191a1fff com.apple.driver.AppleSMC(3.1.9)[DD55DA6A-679A-3797-947C-0B50B7B5B659]@0xffffff80174e7000->0xffffff8017503fff dependency: com.apple.driver.watchdog(1)[BD08CE2D-77F5-358C-8F0D-A570540A0BE7]@0xffffff801919f000->0xffffff80191a1fff dependency: com.apple.iokit.IOACPIFamily(1.4)[D342E754-A422-3F44-BFFB-DEE93F6723BC]@0xffffff8018446000->0xffffff8018447fff dependency: com.apple.iokit.IOPCIFamily(2.9)[481BF782-1F4B-3F54-A34A-CF12A822C40D]@0xffffff80188b6000->0xffffff80188e7fff Process name corresponding to current thread (0xffffff86e359cb30): kernel_task Boot args: keepsyms=1 Mac OS version: 22H221 Kernel version: Darwin Kernel Version 22.6.0: Thu Sep 5 20:48:48 PDT 2024; root:xnu-8796.141.3.708.1~1/RELEASE_X86_64 The origin of the problem is surely inside my filesystem. However, the panic happens not there but somewhere in watchdog. As far as I can tell, the source code for watchdog is not available for public. I can't understand what causes the panic. Let's say we have run out of space. Couldn't write data. Writing received a proper error message and aborted. That's what is expected. However, it is unclear for why the panic arises.

Hi. I am developing a custom virtual file system and facing such behaviour: Upon using some graphical apps, for example Adobe Media Encoder, attempting to navigate inside my filesystem deeper than root folder will fail - nothing will happen on "double click" on that subfolder. Another problem, is that whether I try to re-navigate into root directory, it will be empty. The problem is not present for most GUI apps - for example navigation inside Finder, upon choosing download path for file in Safari, apps like Microsoft Word, Excel and other range of applications work totally correctly. A quick note here. From what I have seen - all apps that work correctly actually have calls to VFS_VGET - a predefined vfs layer hook. Whether the Adobe Media Encoder does not call for it - neither in my filesystem, nor in Samba, so my guess is that some applications have different browsing and retrieving algorithm. Is there anything I should examine further ? Default routines (vnop_open, vnop_lookup, vnop_readdir, vnop_close) behave as expected, without any errors. P.S. This application (Adobe Media Encoder) works properly on Samba.

I'm writing a virtual file system as my educational project (generic kernel extension). Currently, mostly everything is implemented, however, I'm having trouble using Finder search and tags. The results simply don't show up - despite I am having vnop_... calls to those files. The extended attributes are supported. Inodes are stable. Mmap is implemented. Vnop_ioctl returns KERN_SUCCESS (but no implementation). An important moment: Previously, the search didn't work at all. Researching the web has shown me, that Spotlight indexation and Finder search are tightly glued. So basically I was trying to enable support for spotlight, thinking that would be the source of the problem. I was receiving "Unknown indexing state". All those tricks with mdutil, launchd, manual and reindexation either were doing nothing or returning error. The problem was resolved FOR SONOMA by making by VFS appear as local one (adding flags for MNT_LOLCAL and MNT_DOVOLFS). This has changed the state from Unknown indexing state for spotlight to Indexing is disabled. No need to turn it on for me - I am interested only in search and tags, not the spotlight itself. Basically, whether spotlight recognises my driver as no-error, the Finder works correctly, even with indexation disabled. Whether on Monterey*, or Ventura, I get the same problem. However, neither system logs nor my driver show any kinds of errors. The spotlight simply returns error. Reindexation attempt via Security&Privacy returns "Unknown error occured". The metadata for Ventura and Monterey read attempt (mdls) returns "Unable to locate file", however returns a huge list for Sonoma. *Monterey and Ventura never have .Spotlight-V100 folder. No disable indexing files or other spotlight restrictions are present. No user space solutions seem to help. The kext is unsigned and running in an environment with SIP disabled and Security Mode reduced to Permissive. Maybe there some abstract rules for what is required on VFS side to be recognised okay'ish by Spotlight ? Or maybe something specific right for my case ? Any pointers and/or assistance would be greatly appreciated.