Date: Fri, 14 May 2021 10:07:13 -0700
From: Mark Millard <marklmi@yahoo.com>
To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
Cc: freebsd-arm <freebsd-arm@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>
Subject: Re: FYI for aarch64 main [14] running a mid March version: I ended up with [usb{usbus2}] stuck at (near) 100% cpu
Message-ID: <14C02B9D-7342-41EF-AADD-E466C04E17EA@yahoo.com>
In-Reply-To: <202105141252.14ECqA0h081135@gndrsh.dnsmgr.net>
References: <202105141252.14ECqA0h081135@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-May-14, at 05:52, Rodney W. Grimes <freebsd-rwg at =
gndrsh.dnsmgr.net> wrote:
>> Note: The context was using a non-debug main build
>> from mid-2021-Mar. (More details identified
>> later.)
>>=20
>> The issue happend while attempting a:
>>=20
>> # zfs send -R zpold@for-copy | zfs recv -Fdv zpnew
>>=20
>> where the drives involved in the command were:
>>=20
>> zpold: a USB3 SSD, using /dev/da0p3
>> zpnew: an 480 GiByte Optane in the PCIe slot, using /dev/nda0p3
>>=20
>> with:
>>=20
>> # gpart show -pl
>> =3D> 40 468862048 da0 GPT (224G)
>> 40 532480 da0p1 4C8GCA72EFI (260M)
>> 532520 2008 - free - (1.0M)
>> 534528 29360128 da0p2 4C8GCA72swp14 (14G)
>> 29894656 4194304 - free - (2.0G)
>> 34088960 33554432 da0p4 4C8GCA72swp16 (16G)
>> 67643392 401217536 da0p3 4C8GCA72zfs (191G)
>> 468860928 1160 - free - (580K)
>>=20
>> =3D> 40 2000409184 ada0 GPT (954G)
>> 40 409600 ada0p1 (null) (200M)
>> 409640 1740636160 ada0p2 FBSDmacchroot (830G)
>> 1741045800 58720256 ada0p3 FBSDmacchswp0 (28G)
>> 1799766056 176160768 ada0p4 FBSDmacchswp1 (84G)
>> 1975926824 24482400 - free - (12G)
>>=20
>> =3D> 40 937703008 nda0 GPT (447G)
>> 40 532480 nda0p1 CA72opt0EFI (260M)
>> 532520 2008 - free - (1.0M)
>> 534528 117440512 nda0p2 CA72opt0swp56 (56G)
>> 117975040 16777216 - free - (8.0G)
>> 134752256 134217728 nda0p4 CA72opt0swp64 (64G)
>> 268969984 668731392 nda0p3 CA72opt0zfs (319G)
>> 937701376 1672 - free - (836K)
>>=20
>> The system running was that on /dev/ada0p2 (FBSDmacchroot,
>> which is UFS instead of ZFS).
>>=20
>> The [usb{usbus2}] process eventually got stuck-busy, no
>> more I/O:
>>=20
>> CPU 0: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% =
idle
>> CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% =
idle
>> CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% =
idle
>> CPU 3: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% =
idle
>>=20
>> PID USERNAME PRI NICE SIZE RES STATE C TIME =
CPU COMMAND
>> 15 root -72 - 0B 262144B CPU0 0 8:51 =
99.95% [usb{usbus2}]
>>=20
>> 1295 root -8 0 20108Ki 8092Ki q->bq_ 2 0:04 =
0.00% zfs recv -Fdv zpnew{receive_writer_thre}
>> 1295 root 48 0 20108Ki 8092Ki piperd 2 0:22 =
0.00% zfs recv -Fdv zpnew{zfs}
>> 1294 root -8 0 17544Ki 7740Ki q->bq_ 2 0:01 =
0.00% zfs send -R zpold@for-copy{send_reader_thread}
>> 1294 root -8 0 17544Ki 7740Ki q->bq_ 0 0:00 =
0.00% zfs send -R zpold@for-copy{send_merge_thread}
>> 1294 root -8 0 17544Ki 7740Ki hdr->b 2 0:00 =
0.00% zfs send -R zpold@for-copy{send_traverse_threa}
>> 1294 root 52 0 17544Ki 7740Ki range- 3 0:20 =
0.00% zfs send -R zpold@for-copy{zfs}
>>=20
>> 1036 root -8 - 0B 1488Ki t->zth 0 0:00 =
0.00% [zfskern{z_checkpoint_discar}]
>> 1036 root -8 - 0B 1488Ki t->zth 1 0:00 =
0.00% [zfskern{z_livelist_condense}]
>> 1036 root -8 - 0B 1488Ki t->zth 2 0:00 =
0.00% [zfskern{z_livelist_destroy}]
>> 1036 root -8 - 0B 1488Ki t->zth 1 0:00 =
0.00% [zfskern{z_indirect_condense}]
>> 1036 root -8 - 0B 1488Ki mmp->m 3 0:00 =
0.00% [zfskern{mmp_thread_enter}]
>> 1036 root -8 - 0B 1488Ki tx->tx 1 0:00 =
0.00% [zfskern{txg_thread_enter}]
>> 1036 root -8 - 0B 1488Ki tx->tx 2 0:00 =
0.00% [zfskern{txg_thread_enter}]
>>=20
>> I was unable to ^c or ^z the process where I
>> typed the command. I eventually stopped the
>> system with "shutdown -p now" from a ssh
>> session (that had already been in place).
>=20
> Should this occur again before doing the shutdown run a
> zpool status &
> I have gotten in this state when the recv pool was a usb device
The USB device had the send pool in my example.
> and for some reason it had a timeout and gone offline.
No messages about timeouts or other such were made.
> The clue
> this occured are in dmesg, and zpool status.
No console, dmesg -a, or /var/log/messages output were
generated. (And the system was running from a SATA SSD
that was operating well.)
For reference, the USB EtherNet device that was in a
USB2 port continued to operate just fine, allowing the
use of existing ssh sessions that were displaying
gstat -spod and top -Samio -ototal until I started
looking at the problem. (I did not try making a new
ssh session).
I did not do the "zpool status" so I can not report
about it.
> Unplug/plug the USB device, check dmesg that it came online,
> and do a zpool clear.
Okay. I normally avoid unplugging USB storage media
if the system overall does not hang up: hopes of
a clean shutdown leaving things better.
The system did appear to shutdown to completion.
>>=20
>> When I retried after rebooting and scrubbing (no
>> problems found), the problem did not repeat.
>>=20
>> I do not have more information nor a way to repeat
>> the problem on demand, unfortunately.
>>=20
>> Details of the vintage of the system software and
>> such:
>>=20
>> # ~/fbsd-based-on-what-freebsd-main.sh=20
>> FreeBSD FBSDmacch 14.0-CURRENT FreeBSD 14.0-CURRENT =
mm-src-n245445-def0058cc690 GENERIC-NODBG arm64 aarch64 1400005 1400005
>> def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build =
in git context.
>> merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
>> merge-base: CommitDate: 2021-03-12 20:29:42 +0000
>> 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run =
all XPT_ASYNC ccbs in a dedicated thread
>> n245444 (--first-parent --count for merge-base)
>>=20
>> The system was a MACCHIATObin Double Shot.
>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14C02B9D-7342-41EF-AADD-E466C04E17EA>