On 2021-May-14, at 13:48, Rodney W. Grimes
wrote:
>>
>> On 2021-May-14, at 05:52, Rodney W. Grimes > gndrsh.dnsmgr.net> wrote:
>>
Note: The context was using a non-debug main build
from mid-2021-Mar. (More details identified
later.)
The issue happend while
>
> On 2021-May-14, at 05:52, Rodney W. Grimes gndrsh.dnsmgr.net> wrote:
>
> >> Note: The context was using a non-debug main build
> >> from mid-2021-Mar. (More details identified
> >> later.)
> >>
> >> The issue happend while attempting a:
> >>
> >> # zfs send -R zpold@for-copy |
On 2021-May-14, at 05:52, Rodney W. Grimes
wrote:
>> Note: The context was using a non-debug main build
>> from mid-2021-Mar. (More details identified
>> later.)
>>
>> The issue happend while attempting a:
>>
>> # zfs send -R zpold@for-copy | zfs recv -Fdv zpnew
>>
>> where the
> Note: The context was using a non-debug main build
> from mid-2021-Mar. (More details identified
> later.)
>
> The issue happend while attempting a:
>
> # zfs send -R zpold@for-copy | zfs recv -Fdv zpnew
>
> where the drives involved in the command were:
>
> zpold: a USB3 SSD,
On May 14, 2021 5:59:48 AM UTC, Mark Millard via freebsd-current
wrote:
>The [usb{usbus2}] process eventually got stuck-busy, no
>more I/O:
>
>
>The system was a MACCHIATObin Double Shot.
I've noticed USB issues on the mcbin too.
In my experience uaudio was the most likely thing to freeze:
Note: The context was using a non-debug main build
from mid-2021-Mar. (More details identified
later.)
The issue happend while attempting a:
# zfs send -R zpold@for-copy | zfs recv -Fdv zpnew
where the drives involved in the command were:
zpold: a USB3 SSD, using /dev/da0p3
zpnew:
