Date: Sat, 9 Jan 2021 16:01:49 -0800 From: bob prohaska <fbsd@www.zefox.net> To: freebsd-arm@freebsd.org Subject: Re: USB problems on FreeBSD-current and Raspberry Pi3B+, MMCCAM perhaps? Message-ID: <20210110000149.GA45206@www.zefox.net> In-Reply-To: <20210109203341.GA44642@www.zefox.net> References: <20210109203341.GA44642@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 09, 2021 at 12:33:41PM -0800, bob prohaska wrote: > A UGreen USB3 storage card adapter (model 30333) has stopped working > with FreeBSD-current, reporting a stream of > > (da1:umass-sim1:1:0:0): TEST UNIT READY. CDB: 00 00 00 00 00 00 > (da1:umass-sim1:1:0:0): CAM status: SCSI Status Error > (da1:umass-sim1:1:0:0): SCSI status: Check Condition > (da1:umass-sim1:1:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > (da1:umass-sim1:1:0:0): Error 6, Unretryable error > (da2:umass-sim1:1:0:1): TEST UNIT READY. CDB: 00 00 00 00 00 00 > (da2:umass-sim1:1:0:1): CAM status: SCSI Status Error > (da2:umass-sim1:1:0:1): SCSI status: Check Condition > (da2:umass-sim1:1:0:1): SCSI sense: NOT READY asc:3a,0 (Medium not present) > (da2:umass-sim1:1:0:1): Error 6, Unretryable error > in what looks like an infinite loop (there are 4 daX devices on the adapter). > > The present kernel displaying these errors is > FreeBSD 13.0-CURRENT (GENERIC-MMCCAM) #5 main-c255664-g4d64c7243d26: > Sat Jan 9 11:27:58 PST 2021 > > Unplugging the adapter restores normal operation. > Well, maybe not always. The latest unplugging (with / on da0) caused (noperiph:umass-sim0:0:-1:ffffffff): (pass4:umass-sim0:0:0:3): xpt_async(AC_PATH_DEREGISTERED) Periph destroyed (da3:umass-sim0:0:0:3): Periph destroyed umass0: detached panic: mountroot: unable to (re-)mount root. cpuid = 2 time = 665 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x30 pc = 0xffff0000007593a0 lr = 0xffff00000011ad90 sp = 0xffff00004033e390 fp = 0xffff00004033e590 db_trace_self_wrapper() at vpanic+0x194 pc = 0xffff00000011ad90 lr = 0xffff000000454cc4 sp = 0xffff00004033e5a0 fp = 0xffff00004033e600 vpanic() at panic+0x44 pc = 0xffff000000454cc4 lr = 0xffff000000454a6c sp = 0xffff00004033e610 fp = 0xffff00004033e6c0 panic() at vfs_mountroot+0x1854 pc = 0xffff000000454a6c lr = 0xffff00000052c8fc sp = 0xffff00004033e6d0 fp = 0xffff00004033e830 vfs_mountroot() at start_init+0x24 pc = 0xffff00000052c8fc lr = 0xffff0000003e2848 sp = 0xffff00004033e840 fp = 0xffff00004033e8f0 start_init() at fork_exit+0x7c pc = 0xffff0000003e2848 lr = 0xffff00000040eb78 sp = 0xffff00004033e900 fp = 0xffff00004033e950 fork_exit() at fork_trampoline+0x10 pc = 0xffff00000040eb78 lr = 0xffff00000077b5c8 sp = 0xffff00004033e960 fp = 0x0000000000000000 KDB: enter: panic [ thread pid 1 tid 100002 ] Stopped at 0 db> So it looks like there's some interference between da0 (boot device) and da1 through da4, the device names used by the adapter. > Rebooting to > FreeBSD www.zefox.org 13.0-CURRENT FreeBSD 13.0-CURRENT #3 r361820: Sun Jun 7 22:19:00 PDT 2020 bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 > exhibits normal behavior, the adapter can be read and written without trouble. > > As an aside, a Raspberry Pi4 8GB suffers even worse mischief when the adapter > is connected, losing communication with the USB root device even after the > adapter is unplugged. A power cycle is required to recover. That system is > Linux raspberrypi 5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020 armv7l GNU/Linux > Since it implements onboard WiFi presumably it has some equivalent to MMCCAM. > > Might this behavior have anything to do with MMCCAM ? > Thanks for reading, bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210110000149.GA45206>