big.LITTLE status for rk3399/rockpro64?

[Bernd Walter]

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êa Gondolfo <danilo at freebsd.org> wrote:
> > 
> > > On Mon, Jul 13, 2020 at 6:27 PM Vincent Milum Jr <freebsd-arm at darkain.com>
> > > wrote:
> > > 
> > > > I'm curious about this, too. I recently got the Pinebook Pro up and
> > > > running, and would like to start testing all 6 CPU cores for doing
> > > > compilation tasks.
> > > >
> > > > On Mon, Jul 13, 2020 at 10:19 AM Josh Howard <bsd at 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 testing 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=revision&revision=360321
> > > 
> > > 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 entire
> > > 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 at 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 period (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 though.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.