For a few days, my Catalina installation was behaving well. Now, I get not-infrequent kernel panics. I have run Etre-Check, which did not flag any problems. I have also removed Ejector form my startup items (the panics started a few days after I installed it), reset SMC, started in Safe Mode (and restarted), checked memory with TechToolPro, reset NVRAM, and run SMART. There has not been enough time to see if the problem recurs, but the report has been sent to Apple, but maybe someone here can diagnose this for me:

panic(cpu 0 caller 0xffffff7f8358d238): "IOAHCIBlockStorageDriver::CommandTimeout! reallocated sectors = 0x0, pending sectors = 0x0, power on hours = 0x1, fBuiltIn = 0, LBA = 0x0, Block Count = 0x0, Tag = 0x14, Operation Type = 0x6 fis[0]=0x2EF8027, fis[1]=0x0, fis[2]=0x0, fis[3]=0x0, fis[4]=0x0"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/IOAHCIBlockStorage/IOAHCIBlockStorage-316.40.3/IOAHCIBlockStorageDriver.cpp:6311
Backtrace (CPU 0), Frame : Return Address
0xffffff801749ba70 : 0xffffff8001d3bb1b
0xffffff801749bac0 : 0xffffff8001e733e5
0xffffff801749bb00 : 0xffffff8001e64e5e
0xffffff801749bb50 : 0xffffff8001ce2a40
0xffffff801749bb70 : 0xffffff8001d3b207
0xffffff801749bc70 : 0xffffff8001d3b5eb
0xffffff801749bcc0 : 0xffffff80024d24f9
0xffffff801749bd30 : 0xffffff7f8358d238
0xffffff801749bde0 : 0xffffff7f83584213
0xffffff801749be20 : 0xffffff8002445a89
0xffffff801749be90 : 0xffffff80024459a9
0xffffff801749bec0 : 0xffffff8001d7d765
0xffffff801749bf40 : 0xffffff8001d7d291
0xffffff801749bfa0 : 0xffffff8001ce213e
Kernel Extensions in backtrace:
com.apple.iokit.IOAHCIBlockStorage(316.40.3)[482BE005-DE90-3BA3-80BC-68C59FE8ED40]@0xffffff7f8357c000->0xffffff7f835a3fff
dependency: com.apple.iokit.IOAHCIFamily(290.0.1)[1348CB77-02A5-333C-BD2D-2E33F6B182FA]@0xffffff7f83551000
dependency: com.apple.driver.AppleEFINVRAM(2.1)[07910380-1296-307C-A25B-FDB9D2DEBDDE]@0xffffff7f82ae9000
dependency: com.apple.iokit.IOStorageFamily(2.1)[D6C7A1D3-1E90-37A3-9D36-F6793A476858]@0xffffff7f82665000

BSD process name corresponding to current thread: kernel_task

Mac OS version:
19C57

Kernel version:
Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64
Kernel UUID: C3E7E405-C692-356B-88D3-C30041FD1E72
Kernel slide: 0x0000000001a00000
Kernel text base: 0xffffff8001c00000
__HIB text base: 0xffffff8001b00000
System model name: iMac15,1 (Mac-42FD25EABCABB274)
System shutdown begun: NO
Panic diags file available: YES (0x0)

System uptime in nanoseconds: 2488232943312
last loaded kext at 2472242905832: >!UMergeNub 900.4.2 (addr 0xffffff7f8625c000, size 12288)
last unloaded kext at 62041693660: >usb.!UHostPacketFilter 1.0 (addr 0xffffff7f82dda000, size 24576)
loaded kexts:
@fileutil 20.036.15
>!AUpstreamUserClient 3.6.8
@kext.AMDFramebuffer 3.0.4
>AudioAUUC 1.70
@kext.AMDRadeonX4000 3.0.4
@kext.AMDRadeonServiceManager 3.0.4
>!AGraphicsDevicePolicy 4.5.21
@AGDCPluginDisplayMetrics 4.5.21
>!AHV 1
|IOUserEthernet 1.0.1
>!AMikeyHIDDriver 131
|IO!BSerialManager 7.0.2f4
>!APlatformEnabler 2.7.0d0
>AGPM 111.4.1
>X86PlatformShim 1.0.0
>!AMikeyDriver 283.15
>pmtelemetry 1
>AGDCBacklightControl 4.5.21
>!AHDAHardwareConfigDriver 283.15
@Dont_Steal_Mac_OS_X 7.0.0
>!A!IHD5000Graphics 14.0.3
@kext.AMD7000!C 3.0.4
>!AMCCSControl 1.13
>!AHDA 283.15
>eficheck 1
>!A!ISlowAdaptiveClocking 4.0.0
>ACPI_SMC_PlatformPlugin 1.0.0
>!AThunderboltIP 3.1.3
>!ABacklight 180.1
>!A!IFramebufferAzul 14.0.3
|!ABCM5701Ethernet 10.3.5
>!ASMCLMU 212
>!ALPC 3.1
>AirPort.BrcmNIC 1400.1.1
@filesystems.autofs 3.0
>!AVirtIO 1.0
@filesystems.hfs.kext 522.0.9
@!AFSCompression.!AFSCompressionTypeDataless 1.0.0d1
@BootCache 40
@!AFSCompression.!AFSCompressionTypeZlib 1.0.0
@filesystems.apfs 1412.61.1
>!ASDXC 1.7.7
>!AAHCIPort 341.0.2
@private.KextAudit 1.0
>!ARTC 2.0
>!AACPIButtons 6.1
>!AHPET 1.8
>!ASMBIOS 2.1
>!AACPIEC 6.1
>!AAPIC 1.7
$!AImage4 1
@nke.applicationfirewall 303
$TMSafetyNet 8
@!ASystemPolicy 2.0.0
|EndpointSecurity 1
>!UMergeNub 900.4.2
>!AXsanScheme 3
>!UAudio 320.49
>usb.cdc 5.0.0
@kext.AMDRadeonX4030HWLibs 1.0
@kext.AMDRadeonX4000HWServices 3.0.4
>!AGraphicsControl 4.5.21
|IOAVB!F 800.17
>!ASSE 1.0
@plugin.IOgPTPPlugin 800.14
>X86PlatformPlugin 1.0.0
>!AThunderboltEDMSink 4.2.2
@kext.AMDSupport 3.0.4
>!ASMBus!C 1.0.18d1
>DspFuncLib 283.15
@kext.OSvKernDSPLib 529
>!A!ILpssGspi 3.0.60
|IOSlowAdaptiveClocking!F 1.0.0
>IOPlatformPluginLegacy 1.0.0
@!AGPUWrangler 4.5.21
>!ABacklightExpert 1.1.0
|IONDRVSupport 569.3
@!AGraphicsDeviceControl 4.5.21
|IOAccelerator!F2 438.2.8
|IOEthernetAVB!C 1.1.0
>!AHDA!C 283.15
|IOHDA!F 283.15
>IOPlatformPlugin!F 6.0.0d8
>!ASMBusPCI 1.0.14d1
|IO80211!F 1200.12.2b1
>mDNSOffloadUserClient 1.0.1b8
>corecapture 1.0.4
|IOSkywalk!F 1
|IOGraphics!F 569.3
@kext.triggers 1.0
>!UHIDMouse 192
>!AHIDMouse 192
|IOUSBHIDDriver 900.4.2
|Broadcom!BHost!CUSBTransport 7.0.2f4
|IO!BHost!CUSBTransport 7.0.2f4
|IO!BHost!CTransport 7.0.2f4
|IO!B!F 7.0.2f4
|IO!BPacketLogger 7.0.2f4
>usb.IOUSBHostHIDDevice 1.2
>!AThunderboltDPInAdapter 6.2.4
>!AThunderboltDPOutAdapter 6.2.4
>!AThunderboltDPAdapter!F 6.2.4
>!AThunderboltPCIUpAdapter 2.5.2
>!AThunderboltPCIDownAdapter 2.5.2
>usb.!UHub 1.2
>usb.networking 5.0.0
>usb.!UHostCompositeDevice 1.2
|IOAudio!F 300.2
@vecLib.kext 1.2.0
|IOSerial!F 11
|IOSurface 269.6
@filesystems.hfs.encodings.kext 1
|IOAHCIBlock!S 316.40.3
>!AThunderboltNHI 5.8.1
|IOThunderbolt!F 7.4.7
|IOAHCI!F 290.0.1
>usb.!UXHCIPCI 1.2
>usb.!UXHCI 1.2
|IOUSB!F 900.4.2
>!AEFINVRAM 2.1
>!AEFIRuntime 2.1
|IOSMBus!F 1.1
|IOHID!F 2.0.0
$quarantine 4
$sandbox 300.0
@kext.!AMatch 1.0.0d1
>DiskImages 493.0.0
>!AFDEKeyStore 28.30
>!AEffaceable!S 1.0
>!AKeyStore 2
>!UTDM 489.60.3
|IOSCSIBlockCommandsDevice 422.0.2
>!ACredentialManager 1.0
>KernelRelayHost 1
>!ASEPManager 1.0.1
>IOSlaveProcessor 1
|IOTimeSync!F 800.14
|IONetworking!F 3.4
|IOUSBMass!SDriver 157.40.7
|IOSCSIArchitectureModel!F 422.0.2
|IO!S!F 2.1
|IOUSBHost!F 1.2
>!UHostMergeProperties 1.2
>usb.!UCommon 1.0
>!ABusPower!C 1.0
|CoreAnalytics!F 1
>!AMobileFileIntegrity 1.0.5
@kext.CoreTrust 1
|IOReport!F 47
>!AACPIPlatform 6.1
>!ASMC 3.1.9
>watchdog 1
|IOPCI!F 2.9
|IOACPI!F 1.4
@kec.pthread 1
@kec.Libm 1
@kec.corecrypto 1.0

Looking at your backtrace report, I would agree that your focus on the Ejector app was appropriate....the report said you had a time-out on the ioKit BlockStorageDriver which is what reads and writes to the HDD / SSD. If the Ejector app didn't "play nice" with that driver, it could very likely be the culprit behind the time-outs that you experienced.

If removing that app has cleared the issue for you (as time will tell), check back here to close the loop with us and send the same info to the app developer to let them know.

Thanks, Joe. Will do.

Time for your second cup of joe.

According to MacUpdate, Ejector hasn't been updated since 2010 and is 32 bit...don't even know how you managed to install it in the first place.

More: Double-clicking /System/Library/CoreServices/Menu Extras/Eject.menu will place an "Eject" menu extra in your menu bar.

Actually, Ejector has been updated and the website is https://ejector.app The old 32-bit app was much more convenient because it had a menulet in the menu bar. It also shows all my removable disks whereas the Eject menu shows only .dmg files or external devices (such as my scanner for i1Profiler).

To my chagrin, thinking that the new version worked like the old, I bought it without trying it first. Oh well, there's $10 out the window.

Like you I have no need for the Ejector app (?), but I just downloaded it from the Ejector Home page and it is dated February 20, 2019 and is 64 bit. MacUpdate needs updating — another reason I always go directly to the developer's web site.

Since I had downloaded Ejector I decided to take a look at it and decided that it may be a handy utility that does far more than the built in EjectMenu. It activates the eject key on my Magic Keyboard and will eject ANY mounted volume (except, if course, the boot volume). Not that can't be done in Finder and/or Disk Utility but it is a neat convenience. I plan to try it out for a while to see

• Are there any kernel panics?
• Is its utility worth the $9.99 price — that is my biggest question

Apparently, Ejector is not the issue. The KP just happened again. This time, my suspicions fall on the OWC dock that has two SSDs plugged into it. During the entire time that I have had it, the SSDs would sometimes be spontaneously disconnected, giving me a warning that they had been improperly ejected. OWC replaced the original dock under warranty, but the replacement exhibits the same behavior.

Consequently, I manually ejected both SSDs and disconnected the device. We'll see what happens.

Your and Jon's Ejector is either an entirely different app than the one listed on MacUpdate or the original has changed hands; the dev link on the MU page points to a different page than you've linked.

I prefer to start at MU, because it very often tells me lots of stuff that doesn't appear on a dev's website. Also, MU points to the dev, but not the opposite.

Ejector is an exception, but a most unusual one.

FOR YOUR INFORMATION: I have one of the very first first generation OWC Thunderbolt 3 Docks with two USB 3.1 drive enclosures and one Thunderbolt 2 RAID enclosure (with adaptor cable) attached to it and although I have not had any kernel panics I have had multiple cases of unexpected drive disconnection. Always the USB 3.1 drives but never the Thunderbolt 2 connected drive.

NOTE: In retrospect I do not recall having any disconnects since installing MacOS 10.15.2 Beta (19C56a) — the fourth beta. Supposedly the fourth beta is the 10.15.2 release version, but there may be subtle differences. I will make a mental note and let you know if I have any further disconnects, but at the moment it appears to me that whatever was causing those disconnects may have been in MacOS and not the OWC Dock (at least I hope so).

My disconnects have been with the Thunderbolt 2 connection. I haven't used USB but I could try it.

I also have an OWC Mercury Elite Pro Dual enclosure with an SSD and an HDD. It is not plug-and-play but requires disassembly and reassembly to use the drives. It has never exhibited any disconnects (Thunderbolt 2 also).

I came in this morning to find two unexpected disconnections, but in this case it was two volumes on the same USB 3.1 Gen 1 drive connected to the OWC TB3 Dock. At this point I don't have enough information to draw any conclusions, but I will switch to drive to another USB port not on the TB3 Dock and see what happens.

So far, since disconnecting the OWC dock, I have not had a KP. I used the computer for several hours yesterday and this morning with no issue. I am considering replacing that dock with this one. I will probably wait awhile to be sure that the issue has been resolved. I wonder, however, if reseating the SSDs in the dock will have any effect. I may try that first.

Jon, I just looked at your proposed dock replacement and realized that I have been equating your DRIVE Dock with my PORT Dock. They are both OWC products and both connect to the computer via Thunderbolt 3/USB C but that is the extent of their similarity. My apologies for any confusion I might have created.

Here's the latest:

I received the USB dock, installed the two SSDs and tried to update the clones on both. I got a message that both drives had failed! I ejected them and tried to remount them, but Disk Utility could not see them.

Consequently, I phoned OWC (they are 1 TB Mercury Extreme 6G drives) and the upshot is that OWC will replace them under warranty. Luckily, I had ordered the models with a 5-year warranty so there was no issue. I am sending them back to OWC today and OWC is, in the meantime, shipping two new drives to me.

When I described the kernel panics to OWC, I was told that the new docks have had a firmware update that should solve that issue. As usual, time will tell (fingers crossed).

The latest update:

I received one of the new SSDs, hooked it up to the new USB dock, followed all the instructions, and the drive not only would not mount on the desktop (which it shouldn't, being unformatted) but did not show in Disk Utility. I didn't know if the dock or the SSD was faulty, so took the old dock and connected it via USB (formerly connected via Thunderbolt).

I immediately got a window asking if I wanted to format the drive. I launched Disk Utility, formatted it APFS, and successfully made a clone. I will be receiving the second SSD today and will make another clone.

It will be interesting to see if I have any more kernel panics. It's possible that the Thunderbolt connection was the problem, and now it's connected via USB.

Via OWC's website, I requested a replacement. That's where I stand so far.

You may be in for a bumpy ride. I just helped a local here upgrade his mini (running 10.14) to an SSD. I remember fondly the ease of upgrading HDDs before APFS came along with its bag of spanners. Format the new, enable owners on both, ditto over, set startup, reboot. done.

APFS adds two new quirks: Preboot and Restore. You MUST clone the preboot for the mac to boot from the system volume you have copied. And if you want to have access to the system recovery startup, you've got to clone that too. (there are options for creating a new recovery, and it usually requires a great deal more work)

These partitions must be added using a special diskutil apfs command, so they are assigned the right role. Both require renaming the folder to the new system UUID, and the Preboot also requires running a "fix".

Sorry I don't have all the technical fine details of doing this memorized just yet. I had to google-fu the answers on Tuesday.

Here's a quick sampler (that may not have all the info you need): https://www.belightsoft.com/products/resources/apfs-bootable-clone-with-command-line

the preboot fixer is the "diskutil apfs updatePreboot disk3s1"

create a preboot:
diskutil apfs addVolume disk3 apfs Preboot -role B

use role "R" when creating the recovery

don't forget to rename those folders for the system (Macintosh HD)'s UUID

Have you looked into Carbon Copy Cloner lately?

I believe it takes care of all those "technicalities..." no muss, no fuss, no bother.

Artie is right.

The APFS pane in Marcel Bresink's TinkerTool System 6.8.3 uses the same MacOS 10.15 (Catalina) command to copy APFS Containers, Volume Groups, volumes as well as creating deleting/ copying Snapshots. Copying a bootable APFS volume container creates a bootable duplicate of the original. The user interface is not as slick as CCC but the result is the same.

Does that mean that TTS creates clones (as does CCC), which is what it sounds like?

If so, TTS is an ENORMOUS package for $14!

Yes it means TTS can do the same thing as CCC's "Full Clone". Yes that means TTS is a really bargain. However, TTS's interface is not a clean or self explanatory as CCC's. Download the free trial and see what I mean.

I d/l'ed the trial, took a quick look around and quit it without realizing that quitting would cost me one of my 5 launches. ¯\_(ツ)_/¯

My immediate reaction to TTS was that it isn't a Swiss Army Knife, it's the entire Swiss Army plus reinforcements from surrounding countries...all working for next to nothing.

It's go SO MUCH functionality, much of which I don't even understand, that I actually found it off-putting. (I'll save my remaining 3 launches and hope I never need them.)

At any rate, I see what you mean about TTS's cloning UI, but beyond its total obscurity, I found that TTS won't even attempt to clone an APFS System/Data set to another volume in the same container...presumably because it wouldn't be bootable anyhow in almost all situations.

The "Copy..." button activated only when I selected my other container as my destination, but it returned this error


which, considering that I didn't enter any information on my own...just selected from what was offered, is pretty strange.

The error message is even more obscure than the UI.

More: Figgered it out!

TTS wouldn't allow me to use my boot volume as my source; to clone any volume to a second volume I had to be booted into a third volume, which, although it's admittedly the ideal cloning situation, cripples it in the context in which I do my cloning. (TTS and CCC full clones take the same amount of time to complete.)

Further, not only did TTS rename my destination volume, but I wound up with two volumes with the same name and, apparently, content, which shouldn't be possible, because running the task erases the destination, and beyond that, since I then had three volumes with the same name, my source and two destinations, testing bootability was a giant PIA.

AARGH!

Read the TTS Help file. It is full of interesting information explaining the various features. Yes when TTS clones it CLONES — an exact duplicate of whatever APFS layer you selected. CCC does the same thing but then it more sophisticated interface cleans up the naming etc. Hey! What do you expect for $14? 😜

By-the-way I cloned my boot volume using TTS without a hitch. Of course I then had to rename the cloned drive so I could tell them apart. I haven't tried it yet but TTS also offers restoring to a previous version using APFS Snapshots. That is the entire volume not individual files, but for a beta tester like me that could be invaluable.

Getting back to the subject of this thread, I received the following from OWC tech support regarding kernel panics:

Thank you for choosing OWC for your technical needs. There is, at present, a known issue with external Thunderbolt drives/enclosures/drive docks, and 10.15 Catalina, not just for our items, but all external solutions. We're working with Apple to get this resolved but presently, there is no firmware update, or fix, available for this, my apologies.

Currently, it’s recommended to keep an eye on our official blog, where we will post this information when it is available: https://blog.macsales.com/

Didn't they just sell you that dock with NO caveats?

No, I purchased a USB-only dock that was considerably less expensive. It was defective and the replacement has just been shipped. Currently, I have the original Thunderbolt 2/USB 3 dock connected, with two clones, but not powered on. I have been reluctant (understandably) to deal with more kernel panics but I suspect that USB is not susceptible. At any rate, I will ask OWC about their experience and post back when I receive a reply.

Interesting information.

FOR WHAT IT IS WORTH:
Among the collection of external HDs and SSDs I have an OWC Aura TB3 SSD connected to one of the TB3 ports on my Mac mini that kept inexplicably dismounting, usually when the computer was not in use. An OWC tech recommended resetting the PRAM and disabling "put hard disk to sleep" as but it still dismounted although perhaps the interval between dismounts was longer (the dismounts were so irregular it was difficult to tell).

In an effort to clean up the jungle of cords on the back of my desk I decided to re-configure all of my externally connected devices and found I could eliminate a 12 port OWC TB3 Dock several other devices were connected to. That was three days ago and so far the Aura drive has not "unexpectedly disconnected". 🤞The Aura drive is brilliantly fast — nearly as fast as the internal SSD — but I have been reluctant to use it in production because of the unexpected disconnects. Now I am beginning to think it is actually going to be very useful. ✌️

I can't definitively determine whether or not the OWC TB3 Dock played a part in the unexpected disconnects 🙅‍♂️. I am running a beta version of MacOS 10.13.3, there were too many other changes made while thinning out the wire jungle, and frankly I am not interested/curious enough to test out the theory. But I am definitely suspicious and I am reporting my experience to OWC.

Vis-à-vis the USB vs. Thunderbolt question, OWC replied:

So far, it seems to be limited to the Thunderbolt connection types. USB 3 should be fine.

It isn't just Thunderbolt, apparently, because I have on OWC Mercury Elite Pro Dual connected via Thunderbolt and have had neither disconnects nor kernel panics with it. This device is RAID capable (although I don't use it that way) and is older than the dock. In fact, I bought it at the same time that I bought my iMac, in early 2015.

I have a USB 3.2 Gen 2 Type C SSD that is 100% stable and reliable, but removing the TB3 Dock did not solved my problem of the disconnecting TB3 SSD. However, I may have finally arrived on a solution to the disconnects by preventing the computer from sleeping. It has now gone 48 hours without the drive disconnecting. 🤞

My inability to do so turned out to be a bug in TTS.



How did you determine which volume was your clone? Neither QuickBoot nor an option boot gave me any indication of which of my identically named volumes was which. (I'm going to submit a feature request.)

Before I clone, I switch to a another desktop picture, so that my internal drive and my clones have different ones. After cloning, I switch back to the original. That way, I can tell which drive I am booted from.

I cheated

My Source and Target drives were not exactly the same size so it was easy to tell which was which and rename the Clone.

TIPS:

• After cloning I rename the cloned volume
• and for quick visual identification give each volume a unique icon.
• OWC provides a number of custom drive icons that match the physical enclosure.
• System Preferences > Startup Disk tells which drive you are booted from in case you are ever unsure.

NOTE: In Catalina (MacOS 10.15.3 beta) you can only change the name and/or icon of the current boot drive — or at least I could never get it to work otherwise.

Or I could have put an extraneous folder on my desktop, or I could simply have gone into Finder and changed the volume name.

Isn't that contradicted by
or do you mean you renamed your source, NOT your destination.

Also, I just cloned "CCC" from a different container to the container into which I was booted, and I was able to change its name, albeit only that of the system volume, and the set remained bootable.


But if you've got two volumes with the same name, it doesn't differentiate between them.

The most annoying thing is that an option-boot sometimes shows both volumes of a volume group, and if you select the wrong one, you get a new and improved forbidden sign and must do a hard shutdown to get back into business.

When you erased the volume to clone to it (or when your cloning app did), it changed the volume's GUID, which severed it from the preboot volume on that drive. You have to fix the preboot folder name, and then will probably also need to run the preboot update command as I described earlier.

I'm not sure precisely what you're referring to, but I don't think your response is applicable.

As I"ve confirmed via MANY successful cloning operations with Carbon Copy Cloner and TinkerTool System, the cloning apps take care of all the behind-the-scenes work.

As noted by Marcel Bresink, my failed TinkerTool System clones resulted from the bug.

I reboot from the cloned volume to verify that it works correctly and as a part of that exercise change the icon and volume name. NOTE: You can change the volume name of a boot volume while booted from from another boot volume but you cannot change the icon.


Apparently changing the group volume name takes care of all of that and the preboot volume remains connected.


Which would appear to confirm my experience


That is why I change the startup volume in System Preferences rather than using an Option Boot.

ADDENDUM I just installed MaxOS 10.15.3 (19D62e) this morning and CCC Version 5.1.15-b2 (5899) I haven't had time to see if that changes anything we are discussing.