From owner-freebsd-arm@freebsd.org Wed Jul 15 16:51:16 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4B2EF36AA40 for ; Wed, 15 Jul 2020 16:51:16 +0000 (UTC) (envelope-from freebsd@dsllsn.net) Received: from mail.disillusion.net (mail.disillusion.net [96.126.127.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.disillusion.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6Ngj20Y5z48PX for ; Wed, 15 Jul 2020 16:51:12 +0000 (UTC) (envelope-from freebsd@dsllsn.net) Received: from roast.disillusion.net (localhost [127.0.0.1]) by roast.disillusion.net (OpenSMTPD) with ESMTP id 04e2c7fe for ; Wed, 15 Jul 2020 11:51:02 -0500 (CDT) Received: by mail.disillusion.net (OpenSMTPD) with ESMTPSA id 468d8666 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for ; Wed, 15 Jul 2020 11:51:02 -0500 (CDT) From: William Carson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: big.LITTLE status for rk3399/rockpro64? Date: Wed, 15 Jul 2020 11:51:01 -0500 References: <878sfnz61y.wl-bsd@zeppelin.net> <20200714094519.f61b85e267d24c02f6a1c09f@bidouilliste.com> <877dv4dhyy.wl-bsd@zeppelin.net> To: freebsd-arm@freebsd.org In-Reply-To: <877dv4dhyy.wl-bsd@zeppelin.net> Message-Id: <0BAC613E-E139-462A-89D2-B865675D396F@dsllsn.net> X-Mailer: Apple Mail (2.3445.104.14) X-Rspamd-Queue-Id: 4B6Ngj20Y5z48PX X-Spamd-Bar: - X-Spamd-Result: default: False [-1.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[dsllsn.net:s=drip]; NEURAL_HAM_MEDIUM(-1.01)[-1.010]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.995]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; DKIM_TRACE(0.00)[dsllsn.net:+]; DMARC_POLICY_ALLOW(-0.50)[dsllsn.net,reject]; NEURAL_HAM_SHORT(-0.03)[-0.031]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:63949, ipnet:96.126.112.0/20, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 16:51:16 -0000 > On Jul 15, 2020, at 8:29 AM, Josh Howard wrote: >=20 > On Tue, 14 Jul 2020 08:18:53 -0700, > Vincent Milum Jr wrote: >>=20 >> I can confirm that USB Mass Storage causes kernel panics ~50% of the = time. >> This happens during detection/initialization of the device. >> Leaving the drive in during boot has the same chance of panic. >> It is not 100%, as sometimes I can get the drive to register and use = it. >> I've yet to see any other USB device have an issue though. >> I'm actively using a USB-3 hub with keyboard, mouse, and ethernet = without >> issue. >>=20 >>>=20 >>> On rockpro64 it was (it's been a while since I've tested) very easy = to >>> trigger a panic doing anything usb related (sometimes just inserting = a >>> usb thumb drive would triggers it). This is why I've disabled the = big >>> cores on the rockpro64 image. >>>=20 >>> -- >>> Emmanuel Vadot >>>=20 >=20 > Attempting to use a USB3 drive does seem to lead to panics / hangs / = generally > bad behavior when combined with ncpu > 4. Are there any current leads = as to > what's behind the behavior? Any relation to the RPI4 issues in the = other > threads? I've noticed USB drives on my RPI4 also exhibit somewhat = similar > behavior. There is also the issue of corrupting NVMe drives, which is being = tracked in bug ID 243148. I have not tested it recently as there hasn't been any indication it's been resolved/worked on, but if that's simply due to my = own ignorance, I'm happy to test again.=