Major Stability issues with M1 Mac Mini, Big Sur 11.6, SoftRaid 6.1
@softraid-support , seems this forum doesn't like something about the panic logs I pasted here.. I'll attach the panic data as a file and see if that works.
Long story short, beta 3 did not fix the crash on login.
I uninstalled the driver as you instructed, then I restarted the computer. Note that it STILL crashed even with the driver uninstalled! Is that to be expected? I had to unplug the TB4 to get it to boot. Then I was able to install the b3 driver. Reboot and it still crashed on log in.
(I then uninstalled b3, re-installed stable 6.2 driver. I was able to log in only with TB4 unplugged from computer. After I logged in, I waited many minutes and then I plugged in. I did not move the mouse or anything and just waited a while while it went through SMART checks etc. I don't know that this makes a difference, but at least it is mounted again and seems to be work. Will be happy when this is resolved. As a "Hail Mary" I'm contemplating upgrading to Monterey.)
Please find attached that last kernel panic log and the .supt file.
Your earlier crash I suspect was because mac OS did not actually remove the driver from the extensions cache. So it loaded, triggering your panic.
Another way, users (including my test machine) can remove one disk ,start up, then insert/rebuild.
We are making progress in our investigation/reporting to Apple engineering, hopefully we will have news in the next week or two.
Its been months now. If I could get the volume to mount, it was stable. However, occasional reboots do have to happen.. and then it was constant retries to get the volume to mount without crashing. As a last ditch effort, I upgraded to Monterey - something I wanted to do but _was_ waiting for SoftRaid stability. The problem seems worse in Monterey.
At this point, I will have to stop trying to use SoftRaid. I have installed SoftRaid on my Intel MacBook Pro and mounted the ThunderBay4 there without issues. (It must be something about the new M1 architecture / codebase..) I'm in the process of copying my data to multiple drives so that I can wipe the volume. I will fall back to using the ThunderBay4 with MacOS Software RAID 10 - I had tested this configuration earlier and it was stable.
I'll go through official support channels to try to get refunded for SoftRaid. I'm disappointed, but after months of waiting, I need stability over additional speed and storage that SoftRaid would offer.
If it helps the sleuthing, I've attached a Monterey kennel panic log.
You are correct this is an M1 issue. However, if you can convert your volume to RAID 4 (RAID 10 will work also, but it is lower capacity), that would avoid this issue.
Apple has a unit in engineering that reproduces this, we expect to hear any day now, the holidays are over, so I expect very soon.
Throwing my hat into this ring before I throw my DAS in the trash...
I've spent countless hours with Apple trying to address issues resulted from this software causing kernel panics. We've followed the advise of the forums & "Known Issues", up the point of completely rebuilding my volume. Using b13, it was stable enough, didn't kernel panic, to copy the photos library to a new USB-C SSD. Apple support has asked me to run diagnostics on the library that lives on the RAID, since it never scans the library for faces, memories, etc. - I've let it run for days with "0 faces scanned" the only result. It works as expected on test Photos libraries on the internal SSD & the external SSD.
The 6.2.1b13 has since expired, now back to 6.2.1 (as far as I know; there is no good documentation about rolling back from a beta).
Is there documentation detailing the best procedure for M1 Macs? Is there any way to change the stripe unit size without rebuilding the volume? I'd rather not have to take the time to backup, wipe and rebuild the volume, but I do still have my old Intel iMac with which I could perform this task (too risky to attempt the backup with the M1)
This volume is only used for Photos.app, what is the best configuration for such use? I currently have it set up as RAID 5, stripe unit size 16 KB (was the only option at the time?)
We have a new beta now, same link. But going back to 6.2.1 is just a driver install. The beta's cannot address the DART panics, as this has to be addressed in macOS.
The 16k/64k requires deleting the volume, recreating it, but outside of kernel panics on some M1's, there should be no "finder" differences in behavior. Its not clear what you are referring to besides the "DART" bug. if you are getting panics which do not say DART in the top line, attach a panic log here (use TextEdit and "make plain text" so you can attach it)
In the next SoftRAID update (a few weeks from now) the Quickstart has all the steps in detail, but you must have done them, essentially enable third party developers and "Allow" OWC as a third party developer. Nothing else is required.
Seems like you have documented a Photos' bug, where if the library is on an external SoftRAID volume, it cannot scan for faces. Has the Apple tech you spoke to mentioned anything about entering this as a bug? Photos' should work fine, a SoftRAID volume is recognized the same as a standard volume in macOS.
@softraid-support Thank you for your reply. Yes, all of the crash reports that I saved show "dart-apciec..." at the beginning.
Yes, I've enabled 3rd party extensions. I just ran 6.2.1, which shows "Driver v 6.2.1" at the bottom right of the Monitor window. So, seems okay.
I guess we're just at the mercy of Apple. Have they given you any indication that they are working on a fix? Timeline?
I haven't filed a bug report outside the months-long tech support. They had me install a profile in Photos, open the library on the SoftRAID Volume, close it, then send the diagnostic to them. They asked me to re-run it for some reason, but I couldn't at the time bc of the beta being expired. At this point, with the recommendation to change the RAID type or stripe unit size, the support agent agrees that a new diagnostic won't be helpful in diagnosing the Photos.app issue of not scanning faces. I'm not sure if it is bc it is a SoftRAID volume, or if the volume/library is corrupt (due to the kernel panics?). I've repaired it several times, so I assume that SoftRAID is the variable, but who knows, it could be something else. I'll run a new diagnostic when I have the time to rebuild the RAID.
That being said, what is the optimal RAID configuration for Photos libraries? Would it be helpful to uninstall/re-install the driver, etc? Will there be an option for stripe unit size for RAID 4? I like RAID 5, but if it's not ideal, I'm not opposed to using 4 or even 1+0 since I would have to rebuild anyhow just to change the stripe unit size. I also have the option to wait for a fix from SoftRAID or Apple, as long as it's not months away.
A complete list of steps (or list of articles) for the exact procedure would be very welcome, including the 'undoing' of the RAID & drivers, etc. to start from zero and back up to 100%.
-M1 Mac mini, ThunderBay4, 4x 3TB RAID 5 (approximately 3TB used of 9), plugged into UPS.
If this is a photo's bug, I would guess it happens with a non RAID SoftRAID volume also.
the M1 panic is being worked on, I have heard that a possible fix is in the works, but do not know when such a fix will be released.
RAID 4 is best for flash media, it works the same as RAID 5 functionally. you can select the stripe unit size when creating the volume.
To change the RAID volume, or stripe unit size you must":
Delete the volume
Create a new volume
Select the Stripe unit size.
Only RAID 5 has the 16k Stripe unit issue.