Flex 8 and 2 Thunde...
 
Notifications
Clear all

Flex 8 and 2 Thunderbay 3 Bay's Are Paper Weights

Page 5 / 9
(@jwbuckl)
Eminent Member

@softraid-support the one disk scenario will not mount the disks for me so not a work around I’m afraid. Also pushing in one remaining disk still crashes system just FYI

ReplyQuote
Posted : 26/11/2021 11:38 am
(@softraid-support)
Member Admin

@jwbuckl

Next engineering meeting, Monday, I will find out if we need anything special from you (System Diagnostic) with the 6.2.1 driver. Probably not, but I will l let you know if so. We have a crashing system in house still, and are working with that first.

ReplyQuote
Posted : 26/11/2021 2:25 pm
(@j_rez)
New Member

What was the outcome of the engineering meeting?  I'm in the same boat as the others with respect to kernel panics on M1 Max.  ThunderBay 8 and a ThunderBay 4 mini are collecting dust at this point.  

ReplyQuote
Posted : 30/11/2021 6:56 am
(@softraid-support)
Member Admin

@j_rez

Driver work is not quick.

Here are the workarounds I have found so far:

 - Change to RAID 4

 - Connect the enclosure with one drive missing. It should not panic. In my test machine, it will not panic if you connect the 4th drive after a couple minutes and let it rebuild. But you must repeat each restart.

 - Clean macOS install

The 6.2.1 b3 fixes about half or more instances, it seems.

ReplyQuote
Posted : 30/11/2021 9:50 am
(@j_rez)
New Member
Posted by: @softraid-support

@j_rez

Driver work is not quick.

Here are the workarounds I have found so far:

 - Change to RAID 4

 - Connect the enclosure with one drive missing. It should not panic. In my test machine, it will not panic if you connect the 4th drive after a couple minutes and let it rebuild. But you must repeat each restart.

 - Clean macOS install

The 6.2.1 b3 fixes about half or more instances, it seems.

I understand and appreciate that it can take time to suss out the root cause of the behavior of interactions between the driver and the OS.  I've also been through the extended SoftRAID beta efforts in prior versions of macOS with great success from a functionality and reliability (i.e. no data loss) perspective.  I'm able to get by with RAID-10 on the ThunderBay 4 Mini using the latest beta.  If everything other than RAID-5 is functioning as intended/expected (i.e. no kernel panics), would the issue be related to the memory leaks and other miscellaneous errata that's plaguing Monterrey in general?

ReplyQuote
Posted : 04/12/2021 8:43 am
(@softraid-support)
Member Admin

@j_rez

We think it is a memory descriptor or something. Whether we can work around the issue, or must wait for macOS is still unclear to our engineering.

ReplyQuote
Posted : 04/12/2021 1:41 pm
(@pisseduser)
Trusted Member

The suggestion to leave 1 drive out of each raid 5 bay works and if I wait 5+ minutes after startup I can re-insert that drive and all is good (as you know that is a major hassle with 4 raid 5 bays but for my longer sessions its worth the trade off).  I do still get the Boot OSX drives though, 12 of them to be exact.  Hoping for a fix very soon.

ReplyQuote
Topic starter Posted : 08/12/2021 9:20 am
(@softraid-support)
Member Admin

@pisseduser 

The Boot OSX are pseudo volumes. In most cases, this is a side effect from Acronis. Did you give Acronis "full disk access"? That may fix this.

Note: on the disk, just pull it out about a 1/2 inch.

This post was modified 1 year ago by SoftRAID Support
ReplyQuote
Posted : 08/12/2021 10:46 am
(@pisseduser)
Trusted Member

@softraid-support I don’t have acronis, I used the command you all provided to delete it.  Don’t even know why it was on my Mac to begin with.  

ReplyQuote
Topic starter Posted : 08/12/2021 11:02 am
(@softraid-support)
Member Admin

@pisseduser 

Then this issue should have gone away. It was a bug in Catalina for some users, would go away, then it came back with Acronis. I do not know why you should see it.

Note: in 6.2, we removed the boot partition from newly initialized SoftRAID disks, so if you reconfigure your system in the future, initialize the drives, then this would go away naturally also.

ReplyQuote
Posted : 08/12/2021 12:00 pm
(@pisseduser)
Trusted Member

Weird stuff happening.  I've had success booting up my 4 raid 5 bays minus 1 disk then waiting several minutes and pushing disk back in.  BUT, every time I go to do the same boot process (next day for example) I still get a panic even with 1 disk removed from each bay.  I've only found that while unplugged from my MacBook I have to turn off my flex 8, push the drives back in on all 4 bays, pull out a different drive on 2 of my bays, boot up, wait a bit and then turn on my flex 8.  Here is the panic log from a panic with 1 drive removed from each bay.  Not sure if it shows anything different.

 

ReplyQuote
Topic starter Posted : 12/12/2021 10:31 am
(@softraid-support)
Member Admin

@pisseduser 

It is still a Thunderbolt crash, but slightly different:

"DART DART exception SID 0 ERROR_STATUS 0x90000001 ERROR_ADDRESS 0x0000000080008040 (no exceptionInfo)" @AppleT8110DART.cpp:1451

I do not know what this means.

Fortunately, we hope to learn something later this week about this.

ReplyQuote
Posted : 12/12/2021 11:38 am
(@pisseduser)
Trusted Member

The last two times I've booted up my bays minus a disk I've been getting this error for just 1 of the 4 bays.  I have a flex 8 with the top 4 disks and bottom 4 disks on 2 different raid 5 setups.  The one that is getting this error shows the full amount available on the desktop although there is about 5TB on there.  When you select get info it shows the true available amount so must be a weird bug once it says a disk can't be repaired?  Cause for concern regarding my data on that bay?

Screen Shot 2021 12 28 at 7.36.54 PM

 

ReplyQuote
Topic starter Posted : 28/12/2021 7:04 pm
(@pisseduser)
Trusted Member

Now that disk will no longer allow me to copy any data to that disk.  When I try to drag something into it I get a circle with a line through it.  

ReplyQuote
Topic starter Posted : 28/12/2021 8:11 pm
(@softraid-support)
Member Admin

@pisseduser 

That write protected volume scenario is what the message from MacOS indicates, that at volume mount, the built in fsck tool saw a "dirty" volume, tried to fix it, and failed. So the volume was marked as "read only" so the user can backup and restore. This protects the data, but you cannot alter it.

(sometimes when failing repair, macOS marks the volume as unmountable, which means it can never mount until it is fixed, see below)

Do you have access to Disk Warrior? That is the best tool for repairing volumes, (HFS only) and I am not clear on how Monterey compatible it is)

 

ReplyQuote
Posted : 28/12/2021 8:38 pm
Page 5 / 9
Share:
close
open