Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Jul 2020 23:00:04 +0300
From:      Furkan Salman <furkan@fkardame.com>
To:        "freebsd-arm" <freebsd-arm@freebsd.org>
Subject:   Re: freebsd-arm Digest, Vol 744, Issue 1
Message-ID:  <17391dc5b01.e2706ff9533101.6473059816379684006@fkardame.com>
In-Reply-To: <mailman.91.1595851201.24978.freebsd-arm@freebsd.org>
References:  <mailman.91.1595851201.24978.freebsd-arm@freebsd.org>

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


I have a Khadas Edge-V which is also RK3399, I have enabled the big core as=
 explained by sergey and I have been running it with all 6 cores and compil=
ed opnsense images for testing which took around 7+ hours and it didn't cra=
sh for me.


It never crashed in my regular use and I am just using it headless and not =
a DE, AFAIK if you have NVMe connected and you enable all 6cores then it cr=
ashes.=C2=A0



If there is any test you want me to do then please do let me know.

Thank You.


---- On Mon, 27 Jul 2020 15:00:01 +0300  <freebsd-arm-request@freebsd.org> =
wrote ----


Send freebsd-arm mailing list submissions to=20
=C2=A0=C2=A0=C2=A0=C2=A0mailto:freebsd-arm@freebsd.org=20
=20
To subscribe or unsubscribe via the World Wide Web, visit=20
=C2=A0=C2=A0=C2=A0=C2=A0https://lists.freebsd.org/mailman/listinfo/freebsd-=
arm=20
or, via email, send a message with subject or body 'help' to=20
=C2=A0=C2=A0=C2=A0=C2=A0mailto:freebsd-arm-request@freebsd.org=20
=20
You can reach the person managing the list at=20
=C2=A0=C2=A0=C2=A0=C2=A0mailto:freebsd-arm-owner@freebsd.org=20
=20
When replying, please edit your Subject line so it is more specific=20
than "Re: Contents of freebsd-arm digest..."=20
=20
=20
Today's Topics:=20
=20
 1. Re: big.LITTLE status for rk3399/rockpro64? (Josh Howard)=20
=20
=20
----------------------------------------------------------------------=20
=20
Message: 1=20
Date: Sun, 26 Jul 2020 10:19:56 -0700=20
From: Josh Howard <mailto:bsd@zeppelin.net>=20
To: mailto:freebsd-arm@freebsd.org=20
Subject: Re: big.LITTLE status for rk3399/rockpro64?=20
Message-ID: <mailto:87y2n6tcqr.wl-bsd@zeppelin.net>=20
Content-Type: text/plain; charset=3DISO-8859-1=20
=20
On Tue, 14 Jul 2020 00:45:19 -0700,=20
Emmanuel Vadot wrote:=20
>=20
> On Mon, 13 Jul 2020 19:06:22 +0100=20
> Danilo Eg?a Gondolfo <mailto:danilo@freebsd.org> wrote:=20
>=20
> > On Mon, Jul 13, 2020 at 6:27 PM Vincent Milum Jr <mailto:freebsd-arm@da=
rkain.com>=20
> > wrote:=20
> >=20
> > > I'm curious about this, too. I recently got the Pinebook Pro up and=
=20
> > > running, and would like to start testing all 6 CPU cores for doing=20
> > > compilation tasks.=20
> > >=20
> > > On Mon, Jul 13, 2020 at 10:19 AM Josh Howard <mailto:bsd@zeppelin.net=
> wrote:=20
> > >=20
> > > > It looks like it's been a couple of months since there's been any n=
ews=20
> > > > around it. Anything in particular still needed as far as testing or=
=20
> > > > debugging that goes? I have a Rockpro64 and a RockPi4e (though I do=
n't=20
> > > have=20
> > > > that booting yet.) that I could potentially test on.=20
> > > >=20
> > > > Thanks=20
> >=20
> > The number of CPUs was limited here=20
> > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D360321=20
> >=20
> > If you remove the hw.ncpu from your loader.conf you'll be able to use a=
ll=20
> > the 6 cores.=20
> >=20
> > Although the commit message mentions a "known issue" with the big.LITTL=
E=20
> > architecture, I was able to use all the 6 cores to rebuild the entire=
=20
> > system and I didn't face any issue.=20
> >=20
> > Maybe manu@ could give us some context about that.=20
>=20
>  On rockpro64 it was (it's been a while since I've tested) very easy to=
=20
> trigger a panic doing anything usb related (sometimes just inserting a=20
> usb thumb drive would triggers it). This is why I've disabled the big=20
> cores on the rockpro64 image.=20
>=20
> --=20
> Emmanuel Vadot <mailto:manu@bidouilliste.com>=20
=20
Yes, anything USB related does seem to cause a panic still. Furthermore,=20
even without any USB device plugged in and hw.ncpu left alone, I've noticed=
=20
that the system will simply hard lock up after a relatively short period (2=
-24=20
hours) of time on both a Rockpro64 and a RockPi4. Connecting via UART doesn=
't=20
show anything interesting, it just simply stops working.=20
=20
=20
=20
=20
=20
=20
=20
------------------------------=20
=20
Subject: Digest Footer=20
=20
_______________________________________________=20
mailto:freebsd-arm@freebsd.org mailing list=20
https://lists.freebsd.org/mailman/listinfo/freebsd-arm=20
To unsubscribe, send any mail to "mailto:freebsd-arm-unsubscribe@freebsd.or=
g"=20
=20
=20
------------------------------=20
=20
End of freebsd-arm Digest, Vol 744, Issue 1=20
*******************************************
From owner-freebsd-arm@freebsd.org  Tue Jul 28 12:32:11 2020
Return-Path: <owner-freebsd-arm@freebsd.org>
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 A9E4E368769
 for <freebsd-arm@mailman.nyi.freebsd.org>;
 Tue, 28 Jul 2020 12:32:11 +0000 (UTC)
 (envelope-from ticso@cicely18.cicely.de)
Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
 client-signature RSA-PSS (2048 bits) client-digest SHA256)
 (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified))
 by mx1.freebsd.org (Postfix) with ESMTPS id 4BGGJp4rTfz4Llc
 for <freebsd-arm@freebsd.org>; Tue, 28 Jul 2020 12:32:09 +0000 (UTC)
 (envelope-from ticso@cicely18.cicely.de)
Received: from mail.cicely.de ([10.1.1.37])
 by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id 06SCVwWj060441
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Tue, 28 Jul 2020 14:32:00 +0200 (CEST)
 (envelope-from ticso@cicely18.cicely.de)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default;
 t=1595939520; bh=LuxtJjv7ebGpV9QPQjP8TEB2U8CZ5/apHHLAeKpKRaw=;
 h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To;
 b=M7M5lrkPqStibJxofXq/TLyB3v3QTLqOU/Y0jMM43lIUSjJh71HI8yHvf7dfu1Ufu
 fH2NDNFKmY50ILfas7Qii4fXa13WJEKb3nAhPcqFAtE3InOH7ouuj0v6yp6au/JHGd
 ZPh2LGb2G1nPaeg9efZkBlZZ8Hx/1nj02EKsVCHY=
Received: from cicely18.cicely.de (cicely18.cicely.de [10.177.1.50])
 by mail.cicely.de (8.15.2/8.15.2) with ESMTP id 06SCVkGG007480;
 Tue, 28 Jul 2020 14:31:47 +0200 (CEST)
 (envelope-from ticso@cicely18.cicely.de)
Received: from cicely18.cicely.de (localhost [127.0.0.1])
 by cicely18.cicely.de (8.15.2/8.15.2) with ESMTPS id 06SCVjSO005817
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
 Tue, 28 Jul 2020 14:31:45 +0200 (CEST)
 (envelope-from ticso@cicely18.cicely.de)
Received: (from ticso@localhost)
 by cicely18.cicely.de (8.15.2/8.15.2/Submit) id 06SCVhld005816;
 Tue, 28 Jul 2020 14:31:43 +0200 (CEST) (envelope-from ticso)
Date: Tue, 28 Jul 2020 14:31:43 +0200
From: Bernd Walter <ticso@cicely7.cicely.de>
To: Josh Howard <bsd@zeppelin.net>
Cc: freebsd-arm@freebsd.org
Subject: Re: big.LITTLE status for rk3399/rockpro64?
Message-ID: <20200728123143.GB96119@cicely18.cicely.de>
Reply-To: ticso@cicely.de
References: <878sfnz61y.wl-bsd@zeppelin.net>
 <CAOWUMWGY+=w+9jJ8yhb9Lew6MjGorVquvATgok1_fyRMUBS6vg@mail.gmail.com>
 <CAFU7VyNzbFbOP5rMuVEZiMpHs_pdaD3X0Cp0GJRZTyd2pXTHPQ@mail.gmail.com>
 <20200714094519.f61b85e267d24c02f6a1c09f@bidouilliste.com>
 <87y2n6tcqr.wl-bsd@zeppelin.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87y2n6tcqr.wl-bsd@zeppelin.net>
X-Operating-System: FreeBSD cicely18.cicely.de 12.1-RELEASE-p2 amd64
X-Spam-Status: No, score=-1.9 required=4.5 tests=BAYES_00=-1.9 autolearn=ham
 version=3.3.0
X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de
X-Rspamd-Queue-Id: 4BGGJp4rTfz4Llc
X-Spamd-Bar: -
Authentication-Results: mx1.freebsd.org;
 dkim=pass header.d=cicely.de header.s=default header.b=M7M5lrkP;
 dmarc=none;
 spf=none (mx1.freebsd.org: domain of ticso@cicely18.cicely.de has no SPF
 policy when checking 2a02:21e0:16e0:fe::101:1)
 smtp.mailfrom=ticso@cicely18.cicely.de
X-Spamd-Result: default: False [-1.67 / 15.00];
 HAS_REPLYTO(0.00)[ticso@cicely.de]; ARC_NA(0.00)[];
 R_DKIM_ALLOW(-0.20)[cicely.de:s=default];
 NEURAL_HAM_MEDIUM(-0.91)[-0.912]; FROM_HAS_DN(0.00)[];
 TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.948];
 MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[];
 DMARC_NA(0.00)[cicely.de]; RCVD_COUNT_THREE(0.00)[4];
 TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cicely.de:+];
 RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.81)[-0.813];
 RCVD_TLS_LAST(0.00)[];
 FORGED_SENDER(0.30)[ticso@cicely7.cicely.de,ticso@cicely18.cicely.de];
 R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+];
 SUBJECT_ENDS_QUESTION(1.00)[];
 ASN(0.00)[asn:21461, ipnet:2a02:21e0::/32, country:DE];
 FROM_NEQ_ENVFROM(0.00)[ticso@cicely7.cicely.de,ticso@cicely18.cicely.de]
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.33
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>;
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 12:32:11 -0000

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@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 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@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@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@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17391dc5b01.e2706ff9533101.6473059816379684006>