Date: Tue, 28 Jul 2020 08:43:19 -0700 From: Vincent Milum Jr <freebsd-arm@darkain.com> To: freebsd-arm@freebsd.org Subject: Fwd: big.LITTLE status for rk3399/rockpro64? Message-ID: <CAOWUMWFicnTLnHL_F7k-X_455-VLfdDHk=Ka5oBKv=NiWcu=oA@mail.gmail.com> In-Reply-To: <CAOWUMWEMPR9M8wTLsyrA4S_fkhAKL9Z_mjydZC4tARp3jD-kDg@mail.gmail.com> References: <878sfnz61y.wl-bsd@zeppelin.net> <CAOWUMWGY%2B=w%2B9jJ8yhb9Lew6MjGorVquvATgok1_fyRMUBS6vg@mail.gmail.com> <CAFU7VyNzbFbOP5rMuVEZiMpHs_pdaD3X0Cp0GJRZTyd2pXTHPQ@mail.gmail.com> <20200714094519.f61b85e267d24c02f6a1c09f@bidouilliste.com> <87y2n6tcqr.wl-bsd@zeppelin.net> <20200728123143.GB96119@cicely18.cicely.de> <CAOWUMWEMPR9M8wTLsyrA4S_fkhAKL9Z_mjydZC4tARp3jD-kDg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The issue is most certainly from the big.LITTLE setup. Talking with others via Twitter, we've determined the issue is the CAM system doesn't play nicely in this setup. Anything that touches CAM on a big.LITTLE setup has a chance (but not guarantee) of breaking the system. I'm personally running on the Pinebook Pro, also RK3399 based. Any non-CAM based USB devices work absolutely beautifully. I have a USB 3.0 hub with 1gbe ethernet, and plugged into that is a mouse and keyboard. All work fine without issue. USB mass storage will cause the kernel panic, as well NVMe drives. SD/MMC doesn't use CAM by default, so it's fine. Without using any CAM based devices, I've had the Pinebook Pro up and running for a few days fully stable and online, doing things such as recompiling the kernel and various ports without issue. I'm currently using NFS for my /usr/src and /usr/ports trees due to the fact they were thrashing the SD card too hard, and this is all going over the USB NIC, with all 6 cores active and stable. The downside is that the two big cores are not fully clocking up to their max speed, because FreeBSD doesn't have support yet to clock cores or groups of cores independently. On Tue, Jul 28, 2020 at 5:31 AM Bernd Walter <ticso@cicely7.cicely.de> wrote: > On Sun, Jul 26, 2020 at 10:19:56AM -0700, Josh Howard wrote: > > On Tue, 14 Jul 2020 00:45:19 -0700, > > Emmanuel Vadot wrote: > > > > > > On Mon, 13 Jul 2020 19:06:22 +0100 > > > Danilo Eg=C3=AAa Gondolfo <danilo@freebsd.org> wrote: > > > > > > > On Mon, Jul 13, 2020 at 6:27 PM Vincent Milum Jr < > freebsd-arm@darkain.com> > > > > wrote: > > > > > > > > > I'm curious about this, too. I recently got the Pinebook Pro up a= nd > > > > > running, and would like to start testing all 6 CPU cores for doin= g > > > > > compilation tasks. > > > > > > > > > > On Mon, Jul 13, 2020 at 10:19 AM Josh Howard <bsd@zeppelin.net> > wrote: > > > > > > > > > > > It looks like it's been a couple of months since there's been > any news > > > > > > around it. Anything in particular still needed as far as testin= g > or > > > > > > debugging that goes? I have a Rockpro64 and a RockPi4e (though = I > don't > > > > > have > > > > > > that booting yet.) that I could potentially test on. > > > > > > > > > > > > Thanks > > > > > > > > The number of CPUs was limited here > > > > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D360321 > > > > > > > > If you remove the hw.ncpu from your loader.conf you'll be able to > use all > > > > the 6 cores. > > > > > > > > Although the commit message mentions a "known issue" with the > big.LITTLE > > > > architecture, I was able to use all the 6 cores to rebuild the enti= re > > > > system and I didn't face any issue. > > > > > > > > Maybe manu@ could give us some context about that. > > > > > > 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. > > > > > > -- > > > Emmanuel Vadot <manu@bidouilliste.com> > > > > Yes, anything USB related does seem to cause a panic still. Furthermore= , > > even without any USB device plugged in and hw.ncpu left alone, I've > noticed > > that the system will simply hard lock up after a relatively short perio= d > (2-24 > > hours) of time on both a Rockpro64 and a RockPi4. Connecting via UART > doesn't > > show anything interesting, it just simply stops working. > > I've noticed a hard look on mine as well with r362469. > Installed a kernel, rebooted into all CPUs. > I'm running with ZFS mirror on USB stick, but it booted and I was happy. > Tried a buildworld with all CPUs and it locked hard, no break to dbg > possible. > On next boot it paniced on the stick again therefor I rebooted with 4 > CPUs and since then it had no issue with buildworld and anything else. > Can't say if the hard lock was really related to the number of CPUs thoug= h. > > -- > B.Walter <bernd@bwct.de> http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOWUMWFicnTLnHL_F7k-X_455-VLfdDHk=Ka5oBKv=NiWcu=oA>