Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Jul 2020 11:51:01 -0500
From:      William Carson <freebsd@dsllsn.net>
To:        freebsd-arm@freebsd.org
Subject:   Re: big.LITTLE status for rk3399/rockpro64?
Message-ID:  <0BAC613E-E139-462A-89D2-B865675D396F@dsllsn.net>
In-Reply-To: <877dv4dhyy.wl-bsd@zeppelin.net>
References:  <878sfnz61y.wl-bsd@zeppelin.net> <CAOWUMWGY%2B=w%2B9jJ8yhb9Lew6MjGorVquvATgok1_fyRMUBS6vg@mail.gmail.com> <CAFU7VyNzbFbOP5rMuVEZiMpHs_pdaD3X0Cp0GJRZTyd2pXTHPQ@mail.gmail.com> <20200714094519.f61b85e267d24c02f6a1c09f@bidouilliste.com> <CAOWUMWGjE9ttZmasMEJ9046Gq_FaOogWahsRRhhycp=GAefn0g@mail.gmail.com> <877dv4dhyy.wl-bsd@zeppelin.net>

next in thread | previous in thread | raw e-mail | index | archive | help


> On Jul 15, 2020, at 8:29 AM, Josh Howard <bsd@zeppelin.net> 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 <manu@bidouilliste.com>
>>>=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.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0BAC613E-E139-462A-89D2-B865675D396F>