From owner-freebsd-arm@freebsd.org Sat Feb 8 22:13:37 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 A9A6B24CE19 for ; Sat, 8 Feb 2020 22:13:37 +0000 (UTC) (envelope-from ag@x86.ch) Received: from einstein.sui-inter.net (einstein.sui-inter.net [80.74.145.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.sui-inter.net", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48FRJc5XzGz4ML5 for ; Sat, 8 Feb 2020 22:13:36 +0000 (UTC) (envelope-from ag@x86.ch) Received: from einstein.sui-inter.net (localhost [127.0.0.1]) by einstein.sui-inter.net (Postfix) with ESMTPSA id E774FB1C032D for ; Sat, 8 Feb 2020 23:13:33 +0100 (CET) Received-SPF: pass (einstein.sui-inter.net: connection is authenticated) Received: from [213.55.225.147] ([213.55.225.147]) by webmail.x86.ch (Horde Framework) with HTTPS; Sat, 08 Feb 2020 23:13:33 +0100 Date: Sat, 08 Feb 2020 23:13:33 +0100 Message-ID: <20200208231333.Horde.jhC2I9DWb9rRTjrt0WlL1JI@webmail.x86.ch> From: ag@x86.ch To: freebsd-arm@freebsd.org Subject: Re: RPi3 not using SMP? References: <20200208011940.GA8570@www.zefox.net> <6B6CCB8F-B56A-4758-BEEC-6418718C95CB@yahoo.com> <643F7D8B-25CF-47FD-907F-820785A9E8D5@yahoo.com> In-Reply-To: <643F7D8B-25CF-47FD-907F-820785A9E8D5@yahoo.com> User-Agent: Horde Application Framework 5 MIME-Version: 1.0 X-Rspamd-Queue-Id: 48FRJc5XzGz4ML5 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ag@x86.ch has no SPF policy when checking 80.74.145.25) smtp.mailfrom=ag@x86.ch X-Spamd-Result: default: False [3.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[25.145.74.80.rep.mailspike.net : 127.0.0.18]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_LOW(-0.10)[25.145.74.80.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:21069, ipnet:80.74.144.0/20, country:CH]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[147.225.55.213.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; IP_SCORE(0.54)[ipnet: 80.74.144.0/20(1.69), asn: 21069(0.96), country: CH(0.04)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[x86.ch]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.29)[0.290,0]; NEURAL_SPAM_LONG(0.87)[0.866,0]; FROM_NO_DN(0.00)[]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Transfer-Encoding: 8bit Content-Disposition: inline Content-Description: Textnachricht X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2020 22:13:37 -0000   I have: rpi3b + with: FreeBSD bsdrasp3 13.0-CURRENT FreeBSD 13.0-CURRENT r343104 GENERIC  arm64   no problem Zitat von Mark Millard via freebsd-arm : > On 2020-Feb-8, at 03:44, Michael Tuexen wrote: > >>> On 8. Feb 2020, at 03:46, Mark Millard via freebsd-arm >>> wrote: >>> >>> On 2020-Feb-7, at 17:19, bob prohaska wrote: >>> >>>> For some weeks now an RPi3 running -current has seemed rather slow.... >>>> >>>> On looking at the early part of the boot message the processor >>>> attributes seem rather scant: >>>> >>>> ...... >>>> elease APs...APs not started >>>> CPU  0: ARM Cortex-A53 r0p4 affinity:  0 >>>> Instruction Set Attributes 0 = >>>> Instruction Set Attributes 1 = <> >>>>      Processor Features 0 = >>>>      Processor Features 1 = <> >>>>   Memory Model Features 0 = >>> ASID,1TB PA> >>>>   Memory Model Features 1 = <8bit VMID> >>>>   Memory Model Features 2 = <32bit CCIDX,48bit VA> >>>>          Debug Features 0 = <2 CTX BKPTs,4 Watchpoints,6 >>>> Breakpoints,PMUv3,Debugv8> >>>>          Debug Features 1 = <> >>>>      Auxiliary Features 0 = <> >>>>      Auxiliary Features 1 = <> >>>> CPU  1: (null) (null) r0p0 affinity:  0 >>>> CPU  2: (null) (null) r0p0 affinity:  0 >>>> CPU  3: (null) (null) r0p0 affinity:  0 >>>> ............ >>>> In a top window, STATE is reported as RUN, rather than the >>>> former CPUn. >>>> >>>> Is a software switch now required to enable multiprocessing? >>>> >>>> Or, could it be related to  the lines: >>>> psci0: PSCI version number mismatched with DT >>>> as pointed out by Mark M in reference to the cpu_reset failed >>>> problem, which is still manifest? >>>> >>>> The kernel is at r357644. >>> >>> Head -r356767's kernel does not have this problem for RPi3/4 used as >>> aarch64 FreeBSD. >>> >>> Head -r356776 and later all have this problem for both RPi3 and RPi4. >>> >>> Note: There are no head versions between those. >> >> Did you ping Jeff (CCed), since it is his commit and he might know >> what is going on? > > My messages that contained additional evidence had > jeff listed, including the one that you replied to. > > I've tended to remove Jeff from my messages that did > not contain new evidence, including this message. > > I've not come up with any new ways to get potentially > useful information. Other things than PSCI may be > messed up. It is just the PSCI is the only thing with > identified evidence and some known way to test for > the problem being present vs. not. > >> Best regards >> Michael >>> The console log shows evidence of the problem much earlier. >>> Instead of saying: >>> >>> psci0: on ofwbus0 >>> psci0: PSCI version 0.2 compatible >>> >>> (once) it says: >>> >>> psci0: on ofwbus0 >>> psci0: PSCI version number 0 mismatched with DT, default 2 >>> device_attach: psci0 attach returned 6 >>> >>> (and those 3 lines repeat in various places) for which none of >>> them show up for -r356767 . >>> >>> Without identifying and using PSCI, the extra cores will not >>> start and the cpu(s) will not reset. (PSCI is the ARM interface >>> for doing such things.) >>> >>> I've no clue why, but the version number it gets in my RPi4 >>> experiments is 0. My only guess is that at some point >>> memory important to ARM's PSCI operation has been touched >>> and is no longer valid for the PSCI operation. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-armTo > unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Links: ------ [1] http://www.zefox.net