Further Teething Problems – M1 Pro/Max

The tandem of the problematic Monterrey and a lack of support for software that was previously iterated to address errata which manifested during the M1 Silicon introduction continue to manifest in Apple’s latest architecture. There are now enough external data points available to confirm our findings related to disruptions for workflows or compromises to system stability. The three primary issues uncovered thus far and applicable platforms will be provided below.

1.) Memory Leaks – (Apple Silicon and Intel Mac platforms): The GA release for all Mac hardware involves macOS version 12.0.1. Early MacBook Pros may contain 12.0 but will provide notification for applying the 12.0.1 update. The initial report at Macrumors builds upon instances identified across their forums, the Apple Communities forums, and Reddit. Memory management or system optimization utilities, such as CleanMyMacX, will provide an alert and run tasks to provide partial relief for the issue. In the absence of reactive cleanup, allowing this condition to persist for an extended period of time may result in a purple screen of death reboot based on experience with an M1 Mac mini. A temporary workaround for this condition has been identified by The Eclectic Light Company (when it relates to use of Accessibility features). Proactive monitoring of system resources and force quitting applications that are exacerbating the leak will be required for all other use cases until Apple fixes the glitch.

2.) VideoToolbox is not operating as expected – (M1 Pro/M1 Max Apple Silicon platforms): With the considerable uplift in available CPU cores and GPU prowess provided by the Pro and Max Apple Silicon solutions, it would be realistic to expect an uplift along the lines of what was stated during the Apple Unleashed event. Full-blown editing applications, such as Final Cut Pro and Davinci Resolve, do indeed slice through workloads much faster and output completed files in record time. These solutions can leverage the media blocks that are part of the SoC design. Performing transcodes between container formats (i.e. *.ts -> *.mp4) is an area where M1 has excelled from the performance per watt perspective. 480p files process at over 800fps, 720p files process around 220fps, and 1080p files process in the 100fps+ range. Executing this same transcode procedure using the same version of Handbrake (1.4.2 – most recent at the time of publication) provides performance in the ~50fps range when VIdeoToolbox is selected and ~90fps when the transcode is CPU only for 1080p content. This errata was confirmed by Anthony Young at Linus Tech Tips as well as the following Github discussion. Hopefully, this is something that can be sorted out by Apple or the developers of Handbrake.

3.) OWC SoftRAID kernel panic-stravaganza – (M1 Pro/M1 Max Apple Silicon Platforms): We normally advocate that the break point where the Apple Tax goes from “egregious” to “insane in the membrane” is where one should stop throwing money at the platform. The 4TB and 8TB storage options are realistically within this category for M1 Pro and M1 Max. Initial issues when the next version of macOS comes out have been consistent for multiple releases of OWC’s SoftRAID solution. However, the current sticky thread in the SoftRAID forums undersells how pervasive and problematic this issue will be for the user community. This thread highlights the exact combination (M1 Max MBP + ThunderBay 4 Mini) that was about to undergo testing in our environment. We’ve also acquired a ThunderBay 8 for bulk/non-performant local storage. This will suffer the same fate at the ThunderBay 4 Mini until the necessary fixes are implemented by OWC and/or Apple.

Update (4/12/2022): The final release of SoftRAID 6.2.1 has resolved the aforementioned compatibility issues with RAID-5 configurations on Apple Silicon platforms.

Update 2 (2/7/2023): The kernel panic bug has been reintroduced in SoftRAID 7.0.1 with Apple Silicon for RAID-5 configurations using a 16KB stripe size, which is the default/recommended by the tool. Instead of releasing an update to address this disruptive and potentially data-destroying behavior when creating a new array, OWC continues to point its finger at Apple while burying its head in the sand.

We’ve already made our case for Apple to open up the Genius Bar diagnostic tools. Empowering its customers to better pinpoint issues related to erratic components within their system saves time in the overall remediation process. We’re now making the case that Apple either needs to slow down the major point release cadence while focusing on quality -or- appropriately ramp up staffing and bug fix releases to mitigate identified errata as quickly as possible between the x.0 and the x.1 release. For comparison, Windows 11 has had its fair share of issues related to the scheduler (AMD-specific), Windows Explorer (allegedly fixed this month), blue screens of death, and random app crashes. There was a roughly three-week difference between the release of Windows 11 and the availability of macOS Monterrey (12.x) alongside the newest Apple Silicon. At this point, Microsoft has been FAR more aggressive in correcting deficiencies within their latest and greatest OS. We haven’t seen a Supplemental Update from Apple yet to take care of identified errata. It’s doubtful that a point release or supplemental update will become available between now and the start of 2022. Gaining agility related to stomping out Day 1 bugs that somehow made it through QA/QC checks will be MANDATORY if a fully autonomous vehicle is expected by 2025.