Notifications
Clear all
Topic starter
@antonyrock Thanks.
Do you have another Big Sur computer (either intel or M1) that you can try to get a "core dump?" We still need one.
This requires:
2 comptuers, the M1 that crashes and another Big Sur or later OS install
Ethernet, either built in, or a Ethernet/Thunderbolt adapter, or a dock with Eithernet. Connect the two computers together.
The instructions for setting up to capture a core dump are not simple. YOu would use a PDF from Apple. We have another user trying to get the core dump, but I have not heard back. Let me know if you can set this up.
Posted : 16/08/2021 9:00 am
@softraidsupport
Can you please show me where I can get the instructions for capturing a "core dump" with Big Sur? I can do it either with a Mac Mini M1 (same as mine) or with an MBPro 13"/2018 in case the M1 will go sold as i hope. I also need to know what problem is needed to be dumped (sorry, I read about it in the past but I can't find it anymore). If I'm able to replicate it, of course.
By the way, back to my problems, I had a odd behaviour of SR setting up a RAID 10 in my Terramaster d5-300 w/5x WD RED SSD (using only 4, of course). There was no way to get the new volume to have a filesystem on it (either HFS+ or APFS) and no way to apply labels to the disks. As you told me there shuoldn't be problems to do this, I then dug further and rememberd that quality of the cables is very important (got problems in the past with any kind: USB-A to USB-A, TB2, HDMI ecc ecc) and I'm aware that "high quality" branded cables means nothing. I then changed my TB3-TB3 cable with one that looks thougher and everything worked fine. I then tried to create a RAID5 and is working fine. Sometimes, at startup (either the Mac or the RAID after the Mac is on) I get the message that 1 or more disks are missing but after a few seconds everthing is OK.
Simon
This post was modified 3 years ago by majortom67
Posted : 16/08/2021 10:12 am
Topic starter
Are you still getting kernel panics? that is what the core dump is needed for. If you are, or can trigger one by for example connecting the drives immediately after startup, during startup, that is easy. If it happens occasionally during the day, then you need to just use your system until you experience a kernel panic.
When you do:
if the machine hard hangs, hold the power button for one second (only)
If it restarts, wait until fully booted, then hold the power button for one second (only)
After ten minutes the folder with the core dump should pop up, if it does not, you can look for it in (go to folder)
/private/var/tmp/kernel_panics on the target machine. (You can also keep this folder open on the target and wait until a fil appears)
that is what we will need.
When you set this up, you can hold the power button and test to make sure it works.
Instructions next post
Posted : 16/08/2021 10:45 am
Topic starter
These instructions are in the readme for the two machine debugging KDK for Apple developers. I have extracted out unnecessary details.
-
-
Configure Apple silicon as a Target Device
Use the following steps to configure your Apple silicon as a target device for debugging.
Step 1: Modify the Security Configuration of Your Mac
Modify the security configuration of your system as follows:
1. Reboot your Mac in Recovery Mode.
2. Launch Terminal and run the following command to disable System Integrity Protection (SIP):
-
⁃ csrutil disable
3. If prompted to lower your system security to “permissive”, enter y to accept.
4. Reboot your Mac.
Step 2: Identify the Correct Ethernet Device
Run the ifconfig tool in Terminal to identify which Ethernet device your target device uses to connect to the network. In the following example, en1 is the Ethernet device connected to the network.
en0: flags=8963 mtu 1500
options=60
ether 32:00:13:er:19:e0
media: autoselect
status: inactive
en1: flags=8863 mtu 1500
options=10b
ether 40:6c:8f:5b:a2:96
inet6 fe80::426c:8fff:fe5b:a296%en2 prefixlen 64 scopeid 0x4
inet6 2620::1b07:114:426c:8fff:fe5b:a296 prefixlen 64 autoconf
inet6 2620::1b07:114:88d6:bbba:7ac9:b0a7 prefixlen 64 autoconf
temporary
inet 10.128.19.135 netmask 0xfffff800 broadcast 10.128.23.255
nd6 options=1
media: autoselect (1000baseT )
status: active
Step 3: Set the boot-args
Run the nvram tool in Terminal to add the following arguments to your target device’s boot- args key:
-
debug=0x44—Tells the kernel to wait for a debugger to attach to the device, when the kernel receives a non-maskable interrupt (NMI).
-
kdp_match_name=enX—Set the value of this key to the Ethernet device (en0, en1, etc.) identified in Step 2: Identify the Correct Ethernet Device.
-
wdt=-1—Disables watchdog monitoring. For example:
sudo nvram boot-args=“debug=0x44 kdp_match_name=en1 wdt=-1”Step 4: Reboot the Device
Upon reboot, you may connect to your target device from the host.
Configure an Intel-based Mac as a Target Device
Use the following steps to configure your target device for debugging.
Step 1: Modify the Security Configuration of Your Mac
Modify the security configuration of your system as follows:
1. Reboot your Mac in Recovery Mode.
2. If your device has the Apple T2 Security Chip, set the Secure Boot policy to “Medium
Security”.
3. Launch Terminal and run the following command to disable System Integrity Protection (SIP):
⁃ csrutil disable 4. Reboot your Mac.
Step 2: Identify the Correct Ethernet Device
Run the ifconfig tool in Terminal to identify which Ethernet device your target device uses to connect to the network. In the following example, en1 is the Ethernet device connected to the network.
en0: flags=8963 mtu 1500
options=60
ether 32:00:13:er:19:e0
media: autoselect
status: inactive
en1: flags=8863 mtu 1500
options=10b
ether 40:6c:8f:5b:a2:96
inet6 fe80::426c:8fff:fe5b:a296%en2 prefixlen 64 scopeid 0x4
inet6 2620::1b07:114:426c:8fff:fe5b:a296 prefixlen 64 autoconf
inet6 2620::1b07:114:88d6:bbba:7ac9:b0a7 prefixlen 64 autoconf
temporary
inet 10.128.19.135 netmask 0xfffff800 broadcast 10.128.23.255
nd6 options=1
media: autoselect (1000baseT )
status: active
Step 3: Set the boot-args
Run the nvram tool in Terminal to add the following arguments to your target device’s boot- args key:
-
debug=0x44—Tells the kernel to wait for a debugger to attach to the device, when the kernel receives a non-maskable interrupt (NMI).
-
kdp_match_name=enX—Set the value of this key to the Ethernet device (en0, en1, etc.) identified in Step 2: Identify the Correct Ethernet Device.
-
wdt=-1—Disables watchdog monitoring. For example:
sudo nvram boot-args=“debug=0x44 kdp_match_name=en1 wdt=-1”Let me know if you need help, I can get one of our engineers to assist if necessary. We will send this info to our Apple engineering contact to investigate. It is possible they may want to contact you directly.
Posted : 16/08/2021 10:48 am
@softraidsupport
No, I never had kernel panics, I had machine restarts (if raid on) after login and screen changed fully to violet for 1/10 of second. If this is what you're looking for I can replicate it with a low quality USBC-USBC or USBC-USBA cable. I have 2 backups of my RAID, no problem to take some time and try. Let me know (but I'll do it tomorrow GMT+1, now it's almost 6 P.M.).
Simon
Posted : 16/08/2021 10:57 am
P.s.: please clarify me which is the "target" machine and which is the "host" machine.
Other clarifications may come as I don't have yet understood the needing of a second machine (is it the machine collecting the core dump data = the target machine?).
Simon
Posted : 16/08/2021 12:45 pm
Topic starter
Can you independently, do this:
after the next crash get the following data:
Click on "report to Apple", more details and save the text into a text edit file.
a new SoftRAID Tech Support file
Save a system Profile report (about this Mac)
System Diagnose: (Paste this into the terminal.app)
sudo sysdiagnose -f ~/Desktop/
(this is a large file, I will tell you how to send it to me)
Even if you cannot get the core dump, this is important and we can forward this to Apple. they will ask for it anyway, and might be able to investigate without the core dump, but ultimately, I need to get one from a user. thanks
Posted : 16/08/2021 12:58 pm
Topic starter
See the instructions I gave majortom67 below for how to create a core dump.
And also, can you get this information, which I need also?
after the next crash get the following data:
Click on "report to Apple", more details and save the text into a text edit file.
a new SoftRAID Tech Support file
Save a system Profile report (about this Mac)
System Diagnose: (Paste this into the terminal.app)
sudo sysdiagnose -f ~/Desktop/
(this is a large file, I will tell you how to send it to me)
Even if you cannot get the core dump, this is important and we can forward this to Apple. they will ask for it anyway, and might be able to investigate without the core dump, but ultimately, I need to get one from a user. thanks
Posted : 16/08/2021 1:00 pm
Topic starter
When you have the restart, do you get a "your machine restarted because of a problem" alert after restart?
This seems like a kernel panic to me. Whether Apple cares about a "hardware issue" might be a different issue, but I would think they would.
Posted : 16/08/2021 1:37 pm
Topic starter
On an intel machine, macOS can save the "core dump" onto itself. The M1 does not have this ability. So the "source" is the M1. the target is your second computer, where the Core Dump will be save to.
Sorry this is complicated, but the M1's do not have full debug kits working yet. I will try to help out where you get stuck. I should be available when you pick this up.
Posted : 16/08/2021 1:39 pm
Yes it give me that message at restart but didn't relate it just to kernel panics.
Posted : 16/08/2021 2:28 pm
@softraidsupport
Ok. Tomorrow after 2 p.m. gmt+1 I'll begin the experiment in order to collect the requested data including the core dump log assuming I understood that the latter will be automatcally generated on the target machine (mbpro 2018) after pressing the startup button after full boot (better if I enable automatic login).
Just one note: after the Mac Mini M1 crash I'll need to shut down immediately the raid box otherwise it will enter a crash loop. Is it ok?
Simon
This post was modified 3 years ago by majortom67
Posted : 16/08/2021 2:37 pm
Topic starter
Getting that message is indeed a kernel panic. My guess is if you report to Apple, get details and look, you will see something like this line in the panic log, near the top:
dart-apciec1 (0xfffffe2333374000): DART(DART) error: SID 2 write protect exception on write with DVA
Posted : 16/08/2021 10:54 pm
Topic starter
Hopefully it won't loop when saving a crash log core dump. Are you saying if it crashed one time, it goes into a loop (then I am guessing after three starts, it disables the SoftRAID driver?)
if it does that then get the core dump after this.
Also be sure to get the system diagnose in this scenario.
thanks!
Posted : 16/08/2021 10:56 pm
@softraidsupport
Core Dump doesn't appear. Although getting raid in crash has been more difficult than predicted, I've checked al parameters, set my Mini to base system with no unneeded peripherals connected. Checked and rechecked the procedure (should be right), I can't get the Core Dump file. Both Macs have a fixed IP so it can't change between a restart and another. Going to try once or twice more.
Sorry.
Posted : 19/08/2021 8:17 am
