From owner-freebsd-arm@freebsd.org Sun Jul 21 00:51:50 2019 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 CE4CAA49F3 for ; Sun, 21 Jul 2019 00:51:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 715BF953A1 for ; Sun, 21 Jul 2019 00:51:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id x6L0pa6Y018682 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 20 Jul 2019 17:51:37 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id x6L0paNZ018681; Sat, 20 Jul 2019 17:51:36 -0700 (PDT) (envelope-from fbsd) Date: Sat, 20 Jul 2019 17:51:35 -0700 From: bob prohaska To: Jamie Landeg-Jones , freebsd-arm@freebsd.org Subject: Re: Lethargic rpi3, but seemingly still running Message-ID: <20190721005135.GA18642@www.zefox.net> References: <20190718034838.GA1921@www.zefox.net> <201907180958.x6I9wBF8075274@donotpassgo.dyslexicfish.net> <20190718151858.GB4325@www.zefox.net> <20190718182050.GL2342@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190718182050.GL2342@funkthat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 715BF953A1 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.76 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.09)[ip: (0.36), ipnet: 50.1.16.0/20(0.18), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.46)[0.464,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.12)[0.116,0]; MX_GOOD(-0.01)[cached: www.zefox.net]; NEURAL_SPAM_LONG(0.20)[0.201,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[] 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: Sun, 21 Jul 2019 00:51:50 -0000 On Thu, Jul 18, 2019 at 11:20:51AM -0700, John-Mark Gurney wrote: > bob prohaska wrote this message on Thu, Jul 18, 2019 at 08:18 -0700: > > On Thu, Jul 18, 2019 at 10:58:11AM +0100, Jamie Landeg-Jones wrote: > > > bob prohaska wrote: > > > > > > > Every once in a while bsdtar will use a fraction of a percent of cpu, but > > > > that seems to be all that's happening. The timestamp updates every other > > > > second, typing echoes as expected but something like pwd takes twenty > > > > seconds to answer. The controlling terminal for portmaster-devel has been > > > > sitting at > > > > > > What's your I/O like? > > > > > > systat -v 1 > > > > > > > The machine got past the bottleneck and is running normally now, but > > I'll try it the next time the machine bogs down. Does systat use a > > different measurement method than top? > > top doesn't like block device io... iostat or systat -v 1 will do that. > Here's a snippet of systat -v 1 output while un-tarring firefox files. %busy was close to zero, it looks like there's congestion or a deadlock writing to the microSD card. At the time things like cd and ls were very slow to respond (tens of seconds) 28 pdpgs cpu2:ast Disks mmcsd da0 pass0 intrn cpu3:ast KB/t 12.00 0.00 0.00 152904 wire 9 cpu0:preem tps 5 0 0 80072 act 51 cpu1:preem MB/s 0.06 0.00 0.00 671344 inact 80 cpu2:preem %busy 213 0 0 120 21104 27 cpu3:preem Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Sun Jul 21 04:06:41 2019 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 8D2F7A8C78 for ; Sun, 21 Jul 2019 04:06:41 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [95.85.46.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 443F66B6E8 for ; Sun, 21 Jul 2019 04:06:35 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.164] (82-203-140-69.bb.dnainternet.fi [82.203.140.69]) (authenticated bits=0) by mail.kronometrix.org (8.15.2/8.15.2) with ESMTPSA id x6L46KGI067239 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 21 Jul 2019 04:06:21 GMT (envelope-from sparvu@kronometrix.org) X-Authentication-Warning: mail.kronometrix.org: Host 82-203-140-69.bb.dnainternet.fi [82.203.140.69] claimed to be [192.168.1.164] From: Stefan Parvu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Rasclock (PCF2127 ) Hardware Clock FreeBSD 12.0 Date: Sun, 21 Jul 2019 07:06:14 +0300 References: <41A4CA5C-B487-490F-8A19-2D51F43E1004@kronometrix.org> <95616620-bbaf-dbc3-49eb-3e2562638d49@bunyatech.com.au> <74E3E782-8481-4B5B-A0AF-A04590C27D6D@kronometrix.org> <790afcb5f0809a89b45982958a85f1539fec05c7.camel@freebsd.org> <36088812-2135-4433-BC49-0BC433EC6767@kronometrix.org> <86CC4711-47AC-45C6-B6D3-71C9FFDD4A91@kronometrix.org> <2ec7d7f63de31065b9cab396c662fe24f0107078.camel@freebsd.org> <2AC05799-7D11-4200-8D16-38E3718470BB@kronometrix.org> <91E26684-07A0-4F03-92BC-8D49359B1358@kronometrix.org> <5F33E59B-7EA5-4B8B-A95A-CD1FB569ACDC@kronometrix.org> <6a39f74088d2984b5426e8585b5f7e864a6766f8.camel@freebsd.org> <571EABD9-364C-4D91-9177-CC25CB382D76@kronometrix.org> <2dd107308cb7fc21bab793218d8e37039dbc108e.camel@freebsd.org> <77885EA9-6AA4-4106-B447-3A83FB6033BA@kronometrix.org> <7aafd9f1f1cc072081a14c41a0253e72cd449811.camel@freebsd.org> <89879D9D-9432-44FA-B4E0-A6D3EE969E7A@kronometrix.org> <5F7CD5C3-5107-48BE-B301-3193B4E7A4A2@kronometrix.org> <3C0049D3-5998-49F1-9B1E-A877A85A9268@kronometrix.org> <218CD5DF-9484-4FD7-9F7E-ADDB297185BE@kronometrix.org> To: freebsd-arm@freebsd.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 443F66B6E8 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 95.85.46.90 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org X-Spamd-Result: default: False [1.32 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_XAW(0.00)[]; NEURAL_SPAM_MEDIUM(0.26)[0.256,0]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.29)[-0.295,0]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[mail.kronometrix.org]; DMARC_NA(0.00)[kronometrix.org]; NEURAL_SPAM_SHORT(0.71)[0.710,0]; IP_SCORE(0.46)[ip: (0.32), ipnet: 95.85.0.0/18(0.95), asn: 14061(1.07), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:95.85.0.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Sun, 21 Jul 2019 04:06:41 -0000 > Next: I will pick up today from postal office the rasclocks 4.2 and = will repeat the tests > using the new clocks.=20 okay. we are getting to the bottom of this issue. Problem solved.=20 rasclock 4.2 works fine with RBPI3B/3B+. rasclock 4.0 does not. Not sure = what are the=20 main differences but it is clear now. I can keep rasclock 4.2 installed = on the RBPI3B+ 1hr, 5hrs etc and it does recover and set the time correctly during = boot. Ian, 10 x thanks for help and fix. Stefan= From owner-freebsd-arm@freebsd.org Sun Jul 21 04:26:05 2019 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 EC296A918D for ; Sun, 21 Jul 2019 04:26:05 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [95.85.46.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F37D6BD4E for ; Sun, 21 Jul 2019 04:26:05 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.164] (82-203-140-69.bb.dnainternet.fi [82.203.140.69]) (authenticated bits=0) by mail.kronometrix.org (8.15.2/8.15.2) with ESMTPSA id x6L4Q2lM067425 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 21 Jul 2019 04:26:03 GMT (envelope-from sparvu@kronometrix.org) X-Authentication-Warning: mail.kronometrix.org: Host 82-203-140-69.bb.dnainternet.fi [82.203.140.69] claimed to be [192.168.1.164] From: Stefan Parvu Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Lethargic rpi3, but seemingly still running Date: Sun, 21 Jul 2019 07:25:57 +0300 References: <20190718034838.GA1921@www.zefox.net> To: freebsd-arm@freebsd.org In-Reply-To: <20190718034838.GA1921@www.zefox.net> Message-Id: <61E8C3B0-C5A8-4F7C-B12C-DABCC2479BD3@kronometrix.org> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 2F37D6BD4E X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 95.85.46.90 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org X-Spamd-Result: default: False [3.82 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; URI_COUNT_ODD(1.00)[5]; MX_GOOD(-0.01)[cached: mail.kronometrix.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:14061, ipnet:95.85.0.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.54)[0.539,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[kronometrix.org]; NEURAL_SPAM_MEDIUM(0.80)[0.798,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.45)[ip: (0.32), ipnet: 95.85.0.0/18(0.94), asn: 14061(1.07), country: US(-0.05)]; NEURAL_SPAM_LONG(0.84)[0.842,0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: Sun, 21 Jul 2019 04:26:06 -0000 >=20 > I'm playing with an RPI3 running -current at r349989 and trying to = build > a port (firefox) with the ports tree at (....long delay to svnlite = info > command.....) 506825 using portmaster under the portmaster-devel = script. > The system is still running and mostly idle, as reported by top: If you plan to use this system for some time and you want to see and = check its usage and=20 performance, you might want to give a try to Kronometrix (data recording = + analytics included).=20 We support ARMv8, FreeBSD and we have built applications designed for = performance and=20 operational availability which might help you in long run to understand = how your system works. * Open your account kronometrix.io =20 * Create a new Computer Performance subscription and provision a FreeBSD = 12 system Or of course you can manually install the data recording package [1] and = use data recorders interactively or automatic as you want. [1] - https://gitlab.com/kronometrix/recording Stefan From owner-freebsd-arm@freebsd.org Sun Jul 21 14:14:30 2019 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 CEE76B49FE for ; Sun, 21 Jul 2019 14:14:30 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.protonmail.ch", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DB84824D9 for ; Sun, 21 Jul 2019 14:14:29 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sun, 21 Jul 2019 14:14:12 +0000 To: "freebsd-arm@freebsd.org" From: Robert Crowston Reply-To: Robert Crowston Subject: Raspberry Pi 4 boot hangs in sched_idletd. Message-ID: Feedback-ID: 2OVbcR1yHYpdkD8cgQllkFwcuMVZg_LiVMMPvptooFDfHD_03MuQO4ZaF626jWHZYFEhNR2cmIbZ53j4QGWMBQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_52ddbc48b3c09239cdcadbfd6134490a" X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Rspamd-Queue-Id: 1DB84824D9 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.67 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; FREEMAIL_FROM(0.00)[protonmail.com]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; MX_GOOD(-0.01)[mailsec.protonmail.ch,mail.protonmail.ch]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-0.93)[-0.928,0]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:19905, ipnet:185.70.40.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[132.40.70.185.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=default]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_PHPMAILER_SIG(0.00)[]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.73)[ip: (-9.81), ipnet: 185.70.40.0/24(-4.90), asn: 19905(-3.91), country: US(-0.05)]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] 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: Sun, 21 Jul 2019 14:14:30 -0000 This is a multi-part message in MIME format. --b1_52ddbc48b3c09239cdcadbfd6134490a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I need a bit of a hand with this. I've been working on getting FreeBSD 13.0= -Current up and running on my pi4. I'm using the GENERIC configuration for = now. I have a JTAG hardware debugger so I've got a pretty good introspectio= n on what's going on at the detail level, but I'm missing some of the bigge= r picture. The first problem is, this board has two interrupt controllers on the FDT; = the bcm2836-l1-intc local interrupt controller (local_intc) that was presen= t on the RPi3, and also a new gic400. Both the drivers call intr_pic_claim_= root(), which causes a panic. If I remove the gic400 from the FDT, very lit= tle of the hardware enumeration succeeds and the kernel panics because ther= e is no event timer. If I remove the local_intc, a few devices, including t= he BCM2835 DMA controller, the SD card controllers, and the GPIO drivers fa= il to start, but the rest of the hardware enumeration finishes. I don't kno= w enough about the hardware topology to figure out which one is the real ro= ot and fix the drivers accordingly. So, without local_intc, we get another problem. Late in the boot sequence, = the idle thread gets swapped in, and there are still threads on the sleep q= ueue, including thread0, but no other threads get put on the run queue, and= the Pi loops through sched_idletd thread forever instead of finishing the = boot. By poking things in the debugger I can progress as far as vfs_mountroot_wai= t(), and I think there is a race condition because the behaviour is differe= nt if I step through manually without changing anything, but whatever happe= ns, eventually I end up stuck in the sched_idletd loop. I think perhaps event timer interrupts are not being delivered so the sleep= queue never gets moved to the run queue?, but I'm guessing here. More detail: So far I'm in mi_startup(), and about ~1150 out of ~1200 SYSINIT tasks are = done. Eventually we get to initialize the usbus. One of its worker threads = calls _sleep(): Breakpoint 6, _sleep (ident=3D0xffff000000c5eb28 , lock=3D0x0,= priority=3D0, wmesg=3D0xffff000000775d55 "USBWAIT", sbt=3D47244637, pr=3D0, flags=3D2= 56) at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:139 139 td =3D curthread; (gdb) bt #0 _sleep (ident=3D0xffff000000c5eb28 , lock=3D0x0, priority= =3D0, wmesg=3D0xffff000000775d55 "USBWAIT", sbt=3D47244637, pr=3D0, flags=3D2= 56) at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:139 #1 0xffff00000029db08 in usbd_req_set_address (udev=3D0xfffffd0000d23000, = mtx=3D0x0, addr=3D) at /skeleton/root/sandbox/src/sys/dev/usb/usb_r= equest.c:1580 #2 0xffff00000028d05c in usb_alloc_device (parent_dev=3D, b= us=3D0xffff0000405fe000, parent_hub=3D0x0, depth=3D, port_index=3D= , port_no=3D, speed=3DUSB_SPEED_HIGH, mode=3D) at /skeleton/root/sandbox/src/sys/dev/usb/usb_device.c:1824 #3 0xffff000000281524 in usb_bus_attach (pm=3D) at /skeleton/root/sandbox/src/sys/dev/usb/controller/usb_controller.c:7= 67 #4 0xffff00000029b750 in usb_process (arg=3D0xffff0000405fe130) at /skeleton/root/sandbox/src/sys/dev/usb/usb_process.c:178 #5 0xffff0000003b78c0 in fork_exit (callout=3D0xffff00000029b65c , arg=3D0xffff0000405fe130, frame=3D0xffff00004024cba0) at /skeleton/root/sandbox/src/sys/kern/kern_fork.c:1056 #6 0xffff00000071fe88 in fork_trampoline () at /skeleton/root/sandbox/src/sys/arm64/arm64/swtch.S:214 _sleep() swaps the usb_process thread off the CPU. If I step through, anoth= er few threads are put on the CPU, including taskqueue_thread_loop, soaio_k= proc_loop, random_kthread. Sometimes I also see the interrupt event thread,= but not always. Sometimes if I step, I'll find thread0 does get back on th= e CPU, in which case we can progress as far as release_aps(), but then the = other CPUs get stuck in sched_idletd and eventually CPU0 will hang in smp_r= endezvous() waiting for the other CPUs. Does anyone have any ideas what I should investigate next? Boot log attached. --b1_52ddbc48b3c09239cdcadbfd6134490a Content-Type: text/plain; name="rpi4 boot log GENERIC 2019-07-21T1440.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rpi4 boot log GENERIC 2019-07-21T1440.txt" TG9hZGluZyBrZXJuZWwuLi4KL2Jvb3Qva2VybmVsL2tlcm5lbCB0ZXh0PTB4OTM3M2I0IGRhdGE9 MHgxOTEwNDgrMHg4NGFiMWMgc3ltcz1bMHg4KzB4MTM4Nzk4KzB4OCsweDEyNGEzMF0KTG9hZGlu ZyBjb25maWd1cmVkIG1vZHVsZXMuLi4KY2FuJ3QgZmluZCAnL2Jvb3QvZW50cm9weScKVXNpbmcg RFRCIHByb3ZpZGVkIGJ5IEVGSSBhdCAweDdmMDQwMDAuCi0tLTw8Qk9PVD4+LS0tCktEQjogZGVi dWdnZXIgYmFja2VuZHM6IGRkYgpLREI6IGN1cnJlbnQgYmFja2VuZDogZGRiCiAgICAgICAgICAg ICAgICAgICBUeXBlICAgICBQaHlzaWNhbCAgICAgIFZpcnR1YWwgICAjUGFnZXMgQXR0cgogICAg ICAgICAgICAgICBSZXNlcnZlZCAwMDAwMDAwMDAwMDAgICAgICAgICAgICAwIDAwMDAwMDAxIFdC CiAgICAgQ29udmVudGlvbmFsTWVtb3J5IDAwMDAwMDAwNDAwMCAgICAgICAgIDQwMDAgMDAwMDdm MDAgV0IKICAgICAgIEJvb3RTZXJ2aWNlc0RhdGEgMDAwMDA3ZjA0MDAwICAgICAgN2YwNDAwMCAw MDAwMDAwOSBXQgogICAgIENvbnZlbnRpb25hbE1lbW9yeSAwMDAwMDdmMGQwMDAgICAgICA3ZjBk MDAwIDAwMDI3ZGU0IFdCCiAgICAgICAgICAgICBMb2FkZXJEYXRhIDAwMDAyZmNmMTAwMCAgICAg MmZjZjEwMDAgMDAwMDQwMDEgV0IKICAgICAgIEJvb3RTZXJ2aWNlc0RhdGEgMDAwMDMzY2YyMDAw ICAgICAzM2NmMjAwMCAwMDAwMDAwMiBXQgogICAgICAgICAgICAgTG9hZGVyRGF0YSAwMDAwMzNj ZjQwMDAgICAgIDMzY2Y0MDAwIDAwMDA0MDAwIFdCCiAgICAgICAgICAgICBMb2FkZXJDb2RlIDAw MDAzN2NmNDAwMCAgICAgMzdjZjQwMDAgMDAwMDAwOWMgV0IKICAgICAgICAgICAgICAgUmVzZXJ2 ZWQgMDAwMDM3ZDkwMDAwICAgICAzN2Q5MDAwMCAwMDAwMDAwMiBXQgogICAgICAgICAgICAgTG9h ZGVyRGF0YSAwMDAwMzdkOTIwMDAgICAgIDM3ZDkyMDAwIDAwMDAyMWExIFdCCiAgICAgICAgICAg ICBMb2FkZXJDb2RlIDAwMDAzOWYzMzAwMCAgICAgMzlmMzMwMDAgMDAwMDAwMTUgV0IKICAgICAg ICAgICAgICAgUmVzZXJ2ZWQgMDAwMDM5ZjQ4MDAwICAgICAzOWY0ODAwMCAwMDAwMDAwNiBXQgog ICAgUnVudGltZVNlcnZpY2VzRGF0YSAwMDAwMzlmNGUwMDAgICAgIDM5ZjRlMDAwIDAwMDAwMDAx IFdCIFJVTlRJTUUKICAgICAgICAgICAgICAgUmVzZXJ2ZWQgMDAwMDM5ZjRmMDAwICAgICAzOWY0 ZjAwMCAwMDAwMDAwNSBXQgogICAgUnVudGltZVNlcnZpY2VzRGF0YSAwMDAwMzlmNTQwMDAgICAg IDM5ZjU0MDAwIDAwMDAwMDAxIFdCIFJVTlRJTUUKICAgICAgICAgICAgICAgUmVzZXJ2ZWQgMDAw MDM5ZjU1MDAwICAgICAzOWY1NTAwMCAwMDAwMDAwMSBXQgogICAgICAgICAgICAgTG9hZGVyRGF0 YSAwMDAwMzlmNTYwMDAgICAgIDM5ZjU2MDAwIDAwMDAxM2ZhIFdCCiAgICBSdW50aW1lU2Vydmlj ZXNDb2RlIDAwMDAzYjM1MDAwMCAgICAgM2IzNTAwMDAgMDAwMDAwMTAgV0IgUlVOVElNRQogICAg ICAgICAgICAgTG9hZGVyRGF0YSAwMDAwM2IzNjAwMDAgICAgIDNiMzYwMDAwIDAwMDAwMGEwIFdC CiAgICAgICAgIE1lbW9yeU1hcHBlZElPIDAwMDBmZTEwMDAwMCAgICAgZmUxMDAwMDAgMDAwMDAw MDEgUlVOVElNRQpQaHlzaWNhbCBtZW1vcnkgY2h1bmsocyk6CiAgMHgwMDAwNDAwMCAtIDB4Mzdk OGZmZmYsICAgODkzIE1CICggMjI4NzQ4IHBhZ2VzKQogIDB4MzdkOTIwMDAgLSAweDM5ZjQ3ZmZm LCAgICAzMyBNQiAoICAgODYzMCBwYWdlcykKICAweDM5ZjRlMDAwIC0gMHgzOWY0ZWZmZiwgICAg IDAgTUIgKCAgICAgIDEgcGFnZXMpCiAgMHgzOWY1NDAwMCAtIDB4MzlmNTRmZmYsICAgICAwIE1C ICggICAgICAxIHBhZ2VzKQogIDB4MzlmNTYwMDAgLSAweDNiMzRmZmZmLCAgICAxOSBNQiAoICAg NTExNCBwYWdlcykKICAweDNiMzYwMDAwIC0gMHgzYjNmZmZmZiwgICAgIDAgTUIgKCAgICAxNjAg cGFnZXMpCkV4Y2x1ZGVkIG1lbW9yeSByZWdpb25zOgogIDB4MDAwMDAwMDAgLSAweDAwMDAwZmZm LCAgICAgMCBNQiAoICAgICAgMSBwYWdlcykgTm9BbGxvYwogIDB4MmZlMDAwMDAgLSAweDMxNWEz ZmZmLCAgICAyMyBNQiAoICAgNjA1MiBwYWdlcykgTm9BbGxvYwogIDB4MzdkOTAwMDAgLSAweDM3 ZDkxZmZmLCAgICAgMCBNQiAoICAgICAgMiBwYWdlcykgTm9BbGxvYwogIDB4MzlmNDgwMDAgLSAw eDM5ZjU1ZmZmLCAgICAgMCBNQiAoICAgICAxNCBwYWdlcykgTm9BbGxvYwogIDB4M2IzNTAwMDAg LSAweDNiMzVmZmZmLCAgICAgMCBNQiAoICAgICAxNiBwYWdlcykgTm9BbGxvYwogIDB4ZmUxMDAw MDAgLSAweGZlMTAwZmZmLCAgICAgMCBNQiAoICAgICAgMSBwYWdlcykgTm9BbGxvYwpGb3VuZCA0 IENQVXMgaW4gdGhlIGRldmljZSB0cmVlCkNvcHlyaWdodCAoYykgMTk5Mi0yMDE5IFRoZSBGcmVl QlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NAogICAgICAgIFRoZSBSZWdlbnRzIG9mIHRoZSBV bml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMg YSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVlQlNE IDEzLjAtQ1VSUkVOVCAjMCAyNDc0YTY4MjE2ZihtYXN0ZXIpLWRpcnR5OiBTYXQgSnVsIDEzIDIx OjE5OjM1IEJTVCAyMDE5CiAgICByb290QGNyb3NzYnVpbGQudGliZXJpdXM6L3NrZWxldG9uL3Jv b3Qvc2FuZGJveC93b3JrLXJwaTQuMS9vYmovc2tlbGV0b24vcm9vdC9zYW5kYm94L3NyYy9hcm02 NC5hYXJjaDY0L3N5cy9HRU5FUklDIGFybTY0CkZyZWVCU0QgY2xhbmcgdmVyc2lvbiA4LjAuMSAo YnJhbmNoZXMvcmVsZWFzZV84MCAzNjMwMzApIChiYXNlZCBvbiBMTFZNIDguMC4xKQpXQVJOSU5H OiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4KVlQ6 IGluaXQgd2l0aG91dCBkcml2ZXIuClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwv a2VybmVsIiBhdCAweGZmZmYwMDAwMDE1NzkwMDAuClN0YXJ0aW5nIENQVSAxICgxKQpTdGFydGlu ZyBDUFUgMiAoMikKU3RhcnRpbmcgQ1BVIDMgKDMpCkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3Nv ciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwphcmM0cmFuZG9tOiBXQVJOSU5HOiBpbml0aWFsIHNl ZWRpbmcgYnlwYXNzZWQgdGhlIGNyeXB0b2dyYXBoaWMgcmFuZG9tIGRldmljZSBiZWNhdXNlIGl0 IHdhcyBub3QgeWV0IHNlZWRlZCBhbmQgdGhlIGtub2IgJ2J5cGFzc19iZWZvcmVfc2VlZGluZycg d2FzIGVuYWJsZWQuClZJTUFHRSAodmlydHVhbGl6ZWQgbmV0d29yayBzdGFjaykgZW5hYmxlZApV TEU6IHNldHVwIGNwdSAwClVMRTogc2V0dXAgY3B1IDEKVUxFOiBzZXR1cCBjcHUgMgpVTEU6IHNl dHVwIGNwdSAzCnJhbmRvbTogZW50cm9weSBkZXZpY2UgZXh0ZXJuYWwgaW50ZXJmYWNlCnNuZF91 bml0X2luaXQoKSB1PTB4MDBmZjgwMDAgWzUxMl0gZD0weDAwMDA3YzAwIFszMl0gYz0weDAwMDAw M2ZmIFsxMDI0XQpmZWVkZXJfcmVnaXN0ZXI6IHNuZF91bml0PS0xIHNuZF9tYXhhdXRvdmNoYW5z PTE2IGxhdGVuY3k9NSBmZWVkZXJfcmF0ZV9taW49MSBmZWVkZXJfcmF0ZV9tYXg9MjAxNjAwMCBm ZWVkZXJfcmF0ZV9yb3VuZD0yNQpNQVAgMzlmNGUwMDAgbW9kZSAyIHBhZ2VzIDEKTUFQIDM5ZjU0 MDAwIG1vZGUgMiBwYWdlcyAxCk1BUCAzYjM1MDAwMCBtb2RlIDIgcGFnZXMgMTYKRUZJIFJ1bnRp bWUgZW50cnkgMTkgbWFwcGluZyBhdHRyaWJ1dGVzIHVuc3VwcG9ydGVkCk1BUCBmZTEwMDAwMCBt b2RlIDEgcGFnZXMgMQpuZnNsb2NrOiBwc2V1ZG8tZGV2aWNlCmNyeXB0bzogPGNyeXB0byBjb3Jl PgprYmQwIGF0IGtiZG11eDAKbWVtOiA8bWVtb3J5PgpudWxsOiA8ZnVsbCBkZXZpY2UsIG51bGwg ZGV2aWNlLCB6ZXJvIGRldmljZT4Kb3BlbmZpcm06IDxPcGVuIEZpcm13YXJlIGNvbnRyb2wgZGV2 aWNlPgpvZndidXMwOiA8T3BlbiBGaXJtd2FyZSBEZXZpY2UgVHJlZT4Kc2ltcGxlYnVzMDogPEZs YXR0ZW5lZCBkZXZpY2UgdHJlZSBzaW1wbGUgYnVzPiBvbiBvZndidXMwCm9md19jbGtidXMwOiA8 T0ZXIGNsb2NrcyBidXM+IG9uIG9md2J1czAKY2xrX2ZpeGVkMDogPEZpeGVkIGNsb2NrPiBvbiBv ZndfY2xrYnVzMApjbGtfZml4ZWQxOiA8Rml4ZWQgY2xvY2s+IG9uIG9md19jbGtidXMwCnNpbXBs ZWJ1czE6IDxGbGF0dGVuZWQgZGV2aWNlIHRyZWUgc2ltcGxlIGJ1cz4gb24gb2Z3YnVzMApzaW1w bGVidXMyOiA8RmxhdHRlbmVkIGRldmljZSB0cmVlIHNpbXBsZSBidXM+IG9uIG9md2J1czAKcmVn Zml4MDogPEZpeGVkIFJlZ3VsYXRvcj4gb24gb2Z3YnVzMApyZWdmaXgxOiA8Rml4ZWQgUmVndWxh dG9yPiBvbiBvZndidXMwCnBzY2kwOiA8QVJNIFBvd2VyIFN0YXRlIENvLW9yZGluYXRpb24gSW50 ZXJmYWNlIERyaXZlcj4gb24gb2Z3YnVzMApwc2NpMDogUFNDSSB2ZXJzaW9uIDAuMiBjb21wYXRp YmxlCmdpYzA6IDxBUk0gR2VuZXJpYyBJbnRlcnJ1cHQgQ29udHJvbGxlcj4gbWVtIDB4NDAwNDEw MDAtMHg0MDA0MWZmZiwweDQwMDQyMDAwLTB4NDAwNDNmZmYsMHg0MDA0NDAwMC0weDQwMDQ1ZmZm LDB4NDAwNDYwMDAtMHg0MDA0N2ZmZiBvbiBzaW1wbGVidXMwCnNpbXBsZWJ1czA6IG5vIGRlZmF1 bHQgcmVzb3VyY2VzIGZvciByaWQgPSAwLCB0eXBlID0gMQpnaWMwOiBwbiAweDIsIGFyY2ggMHgy LCByZXYgMHgxLCBpbXBsZW1lbnRlciAweDQzYiBpcnFzIDI1NgpncGlvMDogPEJDTTI3MDgvMjgz NSBHUElPIGNvbnRyb2xsZXI+IG1lbSAweDdlMjAwMDAwLTB4N2UyMDAwYjMgaXJxIDIyLDIzLDI0 LDI1IG9uIHNpbXBsZWJ1czAKZ3Bpb2J1czA6IDxPRlcgR1BJTyBidXM+IG9uIGdwaW8wClByb2Nl c3NpbmcgMyBwaW4tY29uZmlnIG5vZGUocykgaW4gcGluY3RybC0wIGZvciBzZXJpYWxAN2UyMDEw MDAKZ3BpbzA6IHNldCBwaW4gMzAgdG8gZnVuYyA3LCBwdWxsIDIKZ3BpbzA6IHNldCBwaW4gMzEg dG8gZnVuYyA3LCBwdWxsIDAKZ3BpbzA6IHNldCBwaW4gMzIgdG8gZnVuYyA3LCBwdWxsIDAKZ3Bp bzA6IHNldCBwaW4gMzIgdG8gZnVuYyA3LCBwdWxsIDAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWzEz My85MTM0XQpncGlvMDogc2V0IHBpbiAzMyB0byBmdW5jIDcsIHB1bGwgMgpncGlvMDogc2V0IHBp biA0MyB0byBmdW5jIDQsIHB1bGwgMApQcm9jZXNzaW5nIDEgcGluLWNvbmZpZyBub2RlKHMpIGlu IHBpbmN0cmwtMCBmb3IgaTJjQDdlMjA1MDAwCmdwaW8wOiBzZXQgcGluIDAgdG8gZnVuYyA0Cmdw aW8wOiBzZXQgcGluIDEgdG8gZnVuYyA0ClByb2Nlc3NpbmcgMSBwaW4tY29uZmlnIG5vZGUocykg aW4gcGluY3RybC0wIGZvciBzZXJpYWxAN2UyMTUwNDAKZ3BpbzA6IHNldCBwaW4gMTQgdG8gZnVu YyAyCmdwaW8wOiBzZXQgcGluIDE1IHRvIGZ1bmMgMgpQcm9jZXNzaW5nIDEgcGluLWNvbmZpZyBu b2RlKHMpIGluIHBpbmN0cmwtMCBmb3Igc2RoY2lAN2UzMDAwMDAKZ3BpbzA6IHNldCBwaW4gMzQg dG8gZnVuYyA3LCBwdWxsIDAKZ3BpbzA6IHNldCBwaW4gMzUgdG8gZnVuYyA3LCBwdWxsIDIKZ3Bp bzA6IHNldCBwaW4gMzYgdG8gZnVuYyA3LCBwdWxsIDIKZ3BpbzA6IHNldCBwaW4gMzcgdG8gZnVu YyA3LCBwdWxsIDIKZ3BpbzA6IHNldCBwaW4gMzggdG8gZnVuYyA3LCBwdWxsIDIKZ3BpbzA6IHNl dCBwaW4gMzkgdG8gZnVuYyA3LCBwdWxsIDIKUHJvY2Vzc2luZyAxIHBpbi1jb25maWcgbm9kZShz KSBpbiBwaW5jdHJsLTAgZm9yIGkyY0A3ZTgwNDAwMApncGlvMDogc2V0IHBpbiAyIHRvIGZ1bmMg NApncGlvMDogc2V0IHBpbiAzIHRvIGZ1bmMgNApQcm9jZXNzaW5nIDIgcGluLWNvbmZpZyBub2Rl KHMpIGluIHBpbmN0cmwtMCBmb3IgcHdtQDdlMjBjODAwCmdwaW8wOiBzZXQgcGluIDQwIHRvIGZ1 bmMgNApncGlvMDogc2V0IHBpbiA0MSB0byBmdW5jIDQKZ3Bpb3JlZ3VsYXRvcjA6IDxHUElPIGNv bnRyb2xsZWQgcmVndWxhdG9yPiBvbiBvZndidXMwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgZ2V0 IHBpbiAwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgcGFyc2UgcGFyYW1ldGVycwpkZXZpY2VfYXR0 YWNoOiBncGlvcmVndWxhdG9yMCBhdHRhY2ggcmV0dXJuZWQgNgpnZW5lcmljX3RpbWVyMDogPEFS TXY3IEdlbmVyaWMgVGltZXI+IGlycSA0LDUsNiw3IG9uIG9md2J1czAKVGltZWNvdW50ZXIgIkFS TSBNUENvcmUgVGltZWNvdW50ZXIiIGZyZXF1ZW5jeSA1NDAwMDAwMCBIeiBxdWFsaXR5IDEwMDAK RXZlbnQgdGltZXIgIkFSTSBNUENvcmUgRXZlbnR0aW1lciIgZnJlcXVlbmN5IDU0MDAwMDAwIEh6 IHF1YWxpdHkgMTAwMApncGlvcmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1bGF0b3I+ IG9uIG9md2J1czAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBnZXQgcGluIDAKZ3Bpb3JlZ3VsYXRv cjA6IGNhbm5vdCBwYXJzZSBwYXJhbWV0ZXJzCmRldmljZV9hdHRhY2g6IGdwaW9yZWd1bGF0b3Iw IGF0dGFjaCByZXR1cm5lZCA2CnVzYl9ub3BfeGNlaXYwOiA8VVNCIE5PUCBQSFk+IG9uIG9md2J1 czAKZ3Bpb3JlZ3VsYXRvcjA6IDxHUElPIGNvbnRyb2xsZWQgcmVndWxhdG9yPiBvbiBvZndidXMw CmdwaW9yZWd1bGF0b3IwOiBjYW5ub3QgZ2V0IHBpbiAwCmdwaW9yZWd1bGF0b3IwOiBjYW5ub3Qg cGFyc2UgcGFyYW1ldGVycwpkZXZpY2VfYXR0YWNoOiBncGlvcmVndWxhdG9yMCBhdHRhY2ggcmV0 dXJuZWQgNgplZmlydGMwOiBjYW5ub3QgcmVhZCBFRkkgcmVhbHRpbWUgY2xvY2ssIGVycm9yIDc4 Cm9md2J1czA6IDxmcmFtZWJ1ZmZlcj4gZGlzYWJsZWQgY29tcGF0IHNpbXBsZS1mcmFtZWJ1ZmZl ciAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8dHhwQDdlMDA0MDAwPiBtZW0gMHg3 ZTAwNDAwMC0weDdlMDA0MDFmIGlycSA4IGNvbXBhdCBicmNtLGJjbTI4MzUtdHhwIChubyBkcml2 ZXIgYXR0YWNoZWQpCmJjbV9kbWEwOiA8QkNNMjgzNSBETUEgQ29udHJvbGxlcj4gbWVtIDB4N2Uw MDcwMDAtMHg3ZTAwN2FmZiBpcnEgOSwxMCwxMSwxMiwxMywxNCwxNSwxNiwxNywxOCwxOSBvbiBz aW1wbGVidXMwCmJjbV9kbWEwOiBjYW5ub3Qgc2V0dXAgaW50ZXJydXB0IGhhbmRsZXIKZGV2aWNl X2F0dGFjaDogYmNtX2RtYTAgYXR0YWNoIHJldHVybmVkIDYKYmNtd2QwOiA8QkNNMjcwOC8yODM1 IFdhdGNoZG9nPiBtZW0gMHg3ZTEwMDAwMC0weDdlMTAwMTEzLDB4N2UwMGEwMDAtMHg3ZTAwYTAy MywweDdlYzExMDAwLTB4N2VjMTEwMWYgb24gc2ltcGxlYnVzMApzaW1wbGVidXMwOiA8Y3BybWFu QDdlMTAxMDAwPiBtZW0gMHg3ZTEwMTAwMC0weDdlMTAyZmZmIGNvbXBhdCBicmNtLGJjbTI4Mzgt Y3BybWFuIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxybmdAN2UxMDQwMDA+IG1l bSAweDdlMTA0MDAwLTB4N2UxMDQwMGYgaXJxIDIwIGNvbXBhdCBicmNtLGJjbTI4Mzgtcm5nMjAw IChubyBkcml2ZXIgYXR0YWNoZWQpCm1ib3gwOiA8QkNNMjgzNSBWaWRlb0NvcmUgTWFpbGJveD4g bWVtIDB4N2UwMGI4ODAtMHg3ZTAwYjhiZiBpcnEgMjEgb24gc2ltcGxlYnVzMApncGlvYzA6IDxH UElPIGNvbnRyb2xsZXI+IG9uIGdwaW8wCnVhcnQwOiA8UHJpbWVDZWxsIFVBUlQgKFBMMDExKT4g bWVtIDB4N2UyMDEwMDAtMHg3ZTIwMTFmZiBpcnEgMjYgb24gc2ltcGxlYnVzMAp1YXJ0MDogZmFz dCBpbnRlcnJ1cHQKdWFydDA6IFBQUyBjYXB0dXJlIG1vZGU6IERDRApzaW1wbGVidXMwOiA8bW1j QDdlMjAyMDAwPiBtZW0gMHg3ZTIwMjAwMC0weDdlMjAyMGZmIGlycSAyNyBkaXNhYmxlZCBjb21w YXQgYnJjbSxiY20yODM1LXNkaG9zdCAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8 aTJzQDdlMjAzMDAwPiBtZW0gMHg3ZTIwMzAwMC0weDdlMjAzMDIzIGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI4MzUtaTJzIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2Uy MDQwMDA+IG1lbSAweDdlMjA0MDAwLTB4N2UyMDQxZmYgaXJxIDI4IGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI4MzUtc3BpIChubyBkcml2ZXIgYXR0YWNoZWQpCmlpY2hiMDogPEJDTTI3MDgvMjgz NSBCU0MgY29udHJvbGxlcj4gbWVtIDB4N2UyMDUwMDAtMHg3ZTIwNTFmZiBpcnEgMjkgb24gc2lt cGxlYnVzMApzaW1wbGVidXMwOiA8cGl4ZWx2YWx2ZUA3ZTIwNjAwMD4gbWVtIDB4N2UyMDYwMDAt MHg3ZTIwNjBmZiBpcnEgMzAgY29tcGF0IGJyY20sYmNtMjgzNS1waXhlbHZhbHZlMCAobm8gZHJp dmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8cGl4ZWx2YWx2ZUA3ZTIwNzAwMD4gbWVtIDB4N2Uy MDcwMDAtMHg3ZTIwNzBmZiBpcnEgMzEgY29tcGF0IGJyY20sYmNtMjgzNS1waXhlbHZhbHZlMSAo bm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8ZHBpQDdlMjA4MDAwPiBtZW0gMHg3ZTIw ODAwMC0weDdlMjA4MDhiIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtZHBpIChubyBkcml2 ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxkc2lAN2UyMDkwMDA+IG1lbSAweDdlMjA5MDAwLTB4 N2UyMDkwNzcgaXJxIDMyIGNvbXBhdCBicmNtLGJjbTI4MzUtZHNpMCAobm8gZHJpdmVyIGF0dGFj aGVkKQpzaW1wbGVidXMwOiA8YXV4QDdlMjE1MDAwPiBtZW0gMHg3ZTIxNTAwMC0weDdlMjE1MDA3 IGNvbXBhdCBicmNtLGJjbTI4MzUtYXV4IChubyBkcml2ZXIgYXR0YWNoZWQpCnVhcnQxOiA8QkNN MjgzNSBNaW5pLVVBUlQ+IG1lbSAweDdlMjE1MDQwLTB4N2UyMTUwN2YgaXJxIDMzIG9uIHNpbXB1 YXJ0MTogY29uc29sZSAoMTE1MjAwLG4sOCwxKQp1YXJ0MTogZmFzdCBpbnRlcnJ1cHQKdWFydDE6 IFBQUyBjYXB0dXJlIG1vZGU6IERDRApzaW1wbGVidXMwOiA8c3BpQDdlMjE1MDgwPiBtZW0gMHg3 ZTIxNTA4MC0weDdlMjE1MGJmIGlycSAzNCBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY20yODM1LWF1 eC1zcGkgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPHNwaUA3ZTIxNTBjMD4gbWVt IDB4N2UyMTUwYzAtMHg3ZTIxNTBmZiBpcnEgMzUgZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjgz NS1hdXgtc3BpIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxwd21AN2UyMGMwMDA+ IG1lbSAweDdlMjBjMDAwLTB4N2UyMGMwMjcgZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjgzNS1w d20gKG5vIGRyaXZlciBhdHRhY2hlZCkKc2RoY2lfYmNtMDogPEJyb2FkY29tIDI3MDggU0RIQ0kg Y29udHJvbGxlcj4gbWVtIDB4N2UzMDAwMDAtMHg3ZTMwMDBmZiBpcnEgMzYgb24gc2ltcGxlYnVz MApkZXZpY2VfYXR0YWNoOiBzZGhjaV9iY20wIGF0dGFjaCByZXR1cm5lZCA2CnNpbXBsZWJ1czA6 IDxodnNAN2U0MDAwMDA+IG1lbSAweDdlNDAwMDAwLTB4N2U0MDVmZmYgaXJxIDM3IGNvbXBhdCBi cmNtLGJjbTI4MzUtaHZzIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxkc2lAN2U3 MDAwMDA+IG1lbSAweDdlNzAwMDAwLTB4N2U3MDAwOGIgaXJxIDM4IGRpc2FibGVkIGNvbXBhdCBi cmNtLGJjbTI4MzUtZHNpMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8Y3NpQDdl ODAwMDAwPiBtZW0gMHg3ZTgwMDAwMC0weDdlODAwN2ZmLDB4N2U4MDIwMDAtMHg3ZTgwMjAwMyBp cnEgMzkgZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjgzNS11bmljYW0gKG5vIGRyaXZlciBhdHRh Y2hlZCkKc2ltcGxlYnVzMDogPGNzaUA3ZTgwMTAwMD4gbWVtIDB4N2U4MDEwMDAtMHg3ZTgwMTdm ZiwweDdlODAyMDA0LTB4N2U4MDIwMDcgaXJxIDQwIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4 MzUtdW5pY2FtIChubyBkcml2ZXIgYXR0YWNoZWQpCmlpY2hiMTogPEJDTTI3MDgvMjgzNSBCU0Mg Y29udHJvbGxlcj4gbWVtIDB4N2U4MDQwMDAtMHg3ZTgwNGZmZiBpcnEgNDEgb24gc2ltcGxlYnVz MAppaWNoYjI6IDxCQ00yNzA4LzI4MzUgQlNDIGNvbnRyb2xsZXI+IG1lbSAweDdlODA1MDAwLTB4 N2U4MDVmZmYgaXJxIDQyIG9uIHNpbXBsZWJ1czAKc2ltcGxlYnVzMDogPHZlY0A3ZTgwNjAwMD4g bWVtIDB4N2U4MDYwMDAtMHg3ZTgwNmZmZiBpcnEgNDMgY29tcGF0IGJyY20sYmNtMjgzNS12ZWMg KG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPHBpeGVsdmFsdmVAN2U4MDcwMDA+IG1l bSAweDdlODA3MDAwLTB4N2U4MDcwZmYgaXJxIDQ0IGNvbXBhdCBicmNtLGJjbTI4MzUtcGl4ZWx2 YWx2ZTIgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDogPGhkbWlAN2U5MDIwMDA+IG1l bSAweDdlOTAyMDAwLTB4N2U5MDI1ZmYsMHg3ZTgwODAwMC0weDdlODA4MGZmIGlycSA0NSw0NiBj b21wYXQgYnJjbSxiY20yODM1LWhkbWkgKG5vIGRyaXZlciBhdHRhY2hlZCkKYmNtMjgzeF9kd2Nv dGcwOiA8RFdDIE9URyAyLjAgaW50ZWdyYXRlZCBVU0IgY29udHJvbGxlciAoYmNtMjgzeCk+IG1l bSAweDdlOTgwMDAwLTB4N2U5OGZmZmYgaXJxIDQ3IG9uIHNpbXBsZWJ1czAKdXNidXMwIG9uIGJj bTI4M3hfZHdjb3RnMApiY20yODN4X2R3Y290ZzA6IHVzYnBmOiBBdHRhY2hlZApzaW1wbGVidXMw OiA8Z3B1PiBjb21wYXQgYnJjbSxiY20yODM1LXZjNCAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1w bGVidXMwOiA8dGhlcm1hbEA3ZDVkMjIwMD4gbWVtIDB4N2Q1ZDIyMDAtMHg3ZDVkMjIyYiBpcnEg NDggY29tcGF0IGJyY20sYXZzLXRtb24tYmNtMjgzOCAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1w bGVidXMwOiA8c2VyaWFsQDdlMjAxNDAwPiBtZW0gMHg3ZTIwMTQwMC0weDdlMjAxNWZmIGlycSA0 OSBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY20yODM1LXBsMDExIChubyBkcml2ZXIgYXR0YWNoZWQp CnNpbXBsZWJ1czA6IDxzZXJpYWxAN2UyMDE2MDA+IG1lbSAweDdlMjAxNjAwLTB4N2UyMDE3ZmYg aXJxIDUwIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtcGwwMTEgKG5vIGRyaXZlciBhdHRh Y2hlZCkKc2ltcGxlYnVzMDogPHNlcmlhbEA3ZTIwMTgwMD4gbWVtIDB4N2UyMDE4MDAtMHg3ZTIw MTlmZiBpcnEgNTEgZGlzYWJsZWQgY29tcGF0IGJyY20sYmNtMjgzNS1wbDAxMSAobm8gZHJpdmVy IGF0dGFjaGVkKQpzaW1wbGVidXMwOiA8c2VyaWFsQDdlMjAxYTAwPiBtZW0gMHg3ZTIwMWEwMC0w eDdlMjAxYmZmIGlycSA1MiBkaXNhYmxlZCBjb21wYXQgYnJjbSxiY20yODM1LXBsMDExIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2UyMDQ2MDA+IG1lbSAweDdlMjA0NjAw LTB4N2UyMDQ3ZmYgaXJxIDUzIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtc3BpIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2UyMDQ4MDA+IG1lbSAweDdlMjA0ODAw LTB4N2UyMDQ5ZmYgaXJxIDU0IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtc3BpIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2UyMDRhMDA+IG1lbSAweDdlMjA0YTAw LTB4N2UyMDRiZmYgaXJxIDU1IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtc3BpIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxzcGlAN2UyMDRjMDA+IG1lbSAweDdlMjA0YzAw LTB4N2UyMDRkZmYgaXJxIDU2IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtc3BpIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2UyMDU2MDA+IG1lbSAweDdlMjA1NjAw LTB4N2UyMDU3ZmYgaXJxIDU3IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtaTJjIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2UyMDU4MDA+IG1lbSAweDdlMjA1ODAw LTB4N2UyMDU5ZmYgaXJxIDU4IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtaTJjIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2UyMDVhMDA+IG1lbSAweDdlMjA1YTAw LTB4N2UyMDViZmYgaXJxIDU5IGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtaTJjIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxpMmNAN2UyMDVjMDA+IG1lbSAweDdlMjA1YzAw LTB4N2UyMDVkZmYgaXJxIDYwIGRpc2FibGVkIGNvbXBhdCBicmNtLGJjbTI4MzUtaTJjIChubyBk cml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czA6IDxwd21AN2UyMGM4MDA+IG1lbSAweDdlMjBjODAw LTB4N2UyMGM4MjcgY29tcGF0IGJyY20sYmNtMjgzNS1wd20gKG5vIGRyaXZlciBhdHRhY2hlZCkK c2RoY2lfYmNtMDogPEJyb2FkY29tIDI3MDggU0RIQ0kgY29udHJvbGxlcj4gbWVtIDB4N2UzNDAw MDAtMHg3ZTM0MDBmZiBpcnEgNjEgb24gc2ltcGxlYnVzMApkZXZpY2VfYXR0YWNoOiBzZGhjaV9i Y20wIGF0dGFjaCByZXR1cm5lZCA2CnNpbXBsZWJ1czA6IDxmaXJtd2FyZT4gY29tcGF0IHJhc3Bi ZXJyeXBpLGJjbTI4MzUtZmlybXdhcmUgKG5vIGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMDog PHBvd2VyPiBjb21wYXQgcmFzcGJlcnJ5cGksYmNtMjgzNS1wb3dlciAobm8gZHJpdmVyIGF0dGFj aGVkKQpvZndidXMwOiA8YXJtLXBtdT4gaXJxIDAsMSwyLDMgY29tcGF0IGFybSxjb3J0ZXgtYTcy LXBtdSAobm8gZHJpdmVyIGF0dGFjaGVkKQpjcHVsaXN0MDogPE9wZW4gRmlybXdhcmUgQ1BVIEdy b3VwPiBvbiBvZndidXMwCmNwdTA6IDxPcGVuIEZpcm13YXJlIENQVT4gb24gY3B1bGlzdDAKY3B1 MDogbWlzc2luZyAnY2xvY2stZnJlcXVlbmN5JyBwcm9wZXJ0eQpjcHUxOiA8T3BlbiBGaXJtd2Fy ZSBDUFU+IG9uIGNwdWxpc3QwCmNwdTE6IG1pc3NpbmcgJ2Nsb2NrLWZyZXF1ZW5jeScgcHJvcGVy dHkKY3B1MjogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MApjcHUyOiBtaXNzaW5nICdj bG9jay1mcmVxdWVuY3knIHByb3BlcnR5CmNwdTM6IDxPcGVuIEZpcm13YXJlIENQVT4gb24gY3B1 bGlzdDAKY3B1MzogbWlzc2luZyAnY2xvY2stZnJlcXVlbmN5JyBwcm9wZXJ0eQpzaW1wbGVidXMx OiA8djNkQDdlYzA0MDAwPiBtZW0gMHg3ZWMwMDAwMC0weDdlYzAzZmZmLDB4N2VjMDQwMDAtMHg3 ZWMwN2ZmZiBpcnEgNjIgY29tcGF0IGJyY20sMjcxMS12M2QgKG5vIGRyaXZlciBhdHRhY2hlZCkK c2ltcGxlYnVzMjogPHBjaWVAN2Q1MDAwMDA+IG1lbSAweDdkNTAwMDAwLTB4N2Q1MDkzMGYsMHg3 ZTAwZjMwMC0weDdlMDBmMzFmIGlycSA2Myw2NCBjb21wYXQgYnJjbSxiY203MjExLXBjaWUgKG5v IGRyaXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMjogPGdlbmV0QDdkNTgwMDAwPiBtZW0gMHg3ZDU4 MDAwMC0weDdkNThmZmZmIGlycSA2NSw2NiBjb21wYXQgYnJjbSxnZW5ldC12NSAobm8gZHJpdmVy IGF0dGFjaGVkKQpzaW1wbGVidXMyOiA8ZG1hQDdlMDA3YjAwPiBtZW0gMHg3ZTAwN2IwMC0weDdl MDA3ZWZmIGlycSA2Nyw2OCw2OSw3MCBjb21wYXQgYnJjbSxiY20yODM4LWRtYSAobm8gZHJpdmVy IGF0dGFjaGVkKQpzaW1wbGVidXMyOiA8eGhjaUA3ZTljMDAwMD4gbWVtIDB4N2U5YzAwMDAtMHg3 ZWFiZmZmZiBpcnEgNzEgZGlzYWJsZWQgY29tcGF0IGdlbmVyaWMteGhjaSAobm8gZHJpdmVyIGF0 dGFjaGVkKQpzaW1wbGVidXMyOiA8aGV2Yy1kZWNvZGVyQDdlYjAwMDAwPiBtZW0gMHg3ZWIwMDAw MC0weDdlYjBmZmZmIGNvbXBhdCByYXNwYmVycnlwaSxhcmdvbi1oZXZjLWRlY29kZXIgKG5vIGRy aXZlciBhdHRhY2hlZCkKc2ltcGxlYnVzMjogPGFyZ29uLWxvY2FsLWludGNAN2ViMTAwMDA+IG1l bSAweDdlYjEwMDAwLTB4N2ViMTBmZmYgaXJxIDcyIGNvbXBhdCByYXNwYmVycnlwaSxhcmdvbi1s b2NhbC1pbnRjIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czI6IDxoMjY0LWRlY29kZXJA N2ViMjAwMDA+IG1lbSAweDdlYjIwMDAwLTB4N2ViMmZmZmYgY29tcGF0IHJhc3BiZXJyeXBpLGFy Z29uLWgyNjQtZGVjb2RlciAobm8gZHJpdmVyIGF0dGFjaGVkKQpzaW1wbGVidXMyOiA8dnA5LWRl Y29kZXJAN2ViMzAwMDA+IG1lbSAweDdlYjMwMDAwLTB4N2ViM2ZmZmYgY29tcGF0IHJhc3BiZXJy eXBpLGFyZ29uLXZwOS1kZWNvZGVyIChubyBkcml2ZXIgYXR0YWNoZWQpCnNpbXBsZWJ1czI6IDxt YWlsYm94QDdlMDBiODQwPiBtZW0gMHg3ZTAwYjg0MC0weDdlMDBiODdiIGlycSA3MyBjb21wYXQg YnJjbSxiY20yODM4LXZjaGlxIChubyBkcml2ZXIgYXR0YWNoZWQpCmdwaW9sZWQwOiA8R1BJTyBM RURzPiBvbiBvZndidXMwCmdwaW9sZWQwOiA8UFdSPiBmYWlsZWQgdG8gbWFwIHBpbgpvZndidXMw OiA8d2lmaS1wd3JzZXE+IGNvbXBhdCBtbWMtcHdyc2VxLXNpbXBsZSAobm8gZHJpdmVyIGF0dGFj aGVkKQpncGlvcmVndWxhdG9yMDogPEdQSU8gY29udHJvbGxlZCByZWd1bGF0b3I+IG9uIG9md2J1 czAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5vdCBnZXQgcGluIDAKZ3Bpb3JlZ3VsYXRvcjA6IGNhbm5v dCBwYXJzZSBwYXJhbWV0ZXJzCmRldmljZV9hdHRhY2g6IGdwaW9yZWd1bGF0b3IwIGF0dGFjaCBy ZXR1cm5lZCA2CmNyeXB0b3NvZnQwOiA8c29mdHdhcmUgY3J5cHRvPgpjcnlwdG86IGFzc2lnbiBj cnlwdG9zb2Z0MCBkcml2ZXIgaWQgMCwgZmxhZ3MgMHg2MDAwMDAwCmNyeXB0bzogY3J5cHRvc29m dDAgcmVnaXN0ZXJzIGFsZyAxIGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQw IHJlZ2lzdGVycyBhbGcgMiBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCBy ZWdpc3RlcnMgYWxnIDMgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVn aXN0ZXJzIGFsZyA0IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lz dGVycyBhbGcgNSBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3Rl cnMgYWxnIDE2IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVy cyBhbGcgNiBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMg YWxnIDcgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFs ZyAzMiBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxn IDE4IGZsYWdzIDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcg MTkgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAy MCBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDgg ZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxNSBm bGFncyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDkgZmxh Z3MgMCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAxMCBmbGFn cyAwIG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDEzIGZsYWdz IDAgbWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMTQgZmxhZ3Mg MCBtYXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAzNCBmbGFncyAw IG1heG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDM1IGZsYWdzIDAg bWF4b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMzYgZmxhZ3MgMCBt YXhvcGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAzNyBmbGFncyAwIG1h eG9wbGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDExIGZsYWdzIDAgbWF4 b3BsZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMjIgZmxhZ3MgMCBtYXhv cGxlbiAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAyMyBmbGFncyAwIG1heG9w bGVuIDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDI1IGZsYWdzIDAgbWF4b3Bs ZW4gMApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMjQgZmxhZ3MgMCBtYXhvcGxl biAwCmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAyNiBmbGFncyAwIG1heG9wbGVu IDAKY3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDI3IGZsYWdzIDAgbWF4b3BsZW4g MApjcnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMjggZmxhZ3MgMCBtYXhvcGxlbiAw CmNyeXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAyMSBmbGFncyAwIG1heG9wbGVuIDAK Y3J5cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDE3IGZsYWdzIDAgbWF4b3BsZW4gMApj cnlwdG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgMjkgZmxhZ3MgMCBtYXhvcGxlbiAwCmNy eXB0bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAzMCBmbGFncyAwIG1heG9wbGVuIDAKY3J5 cHRvOiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDMxIGZsYWdzIDAgbWF4b3BsZW4gMApjcnlw dG86IGNyeXB0b3NvZnQwIHJlZ2lzdGVycyBhbGcgNDAgZmxhZ3MgMCBtYXhvcGxlbiAwCmNyeXB0 bzogY3J5cHRvc29mdDAgcmVnaXN0ZXJzIGFsZyAzOSBmbGFncyAwIG1heG9wbGVuIDAKY3J5cHRv OiBjcnlwdG9zb2Z0MCByZWdpc3RlcnMgYWxnIDM4IGZsYWdzIDAgbWF4b3BsZW4gMApEZXZpY2Ug Y29uZmlndXJhdGlvbiBmaW5pc2hlZC4KRm91bmQgU01DQ0MgdmVyc2lvbiAxLjAKcHJvY2ZzIHJl Z2lzdGVyZWQKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpsbzA6IGJwZiBhdHRh Y2hlZAp2bGFuOiBpbml0aWFsaXplZCwgdXNpbmcgaGFzaCB0YWJsZXMgd2l0aCBjaGFpbmluZwpJ UHNlYzogSW5pdGlhbGl6ZWQgU2VjdXJpdHkgQXNzb2NpYXRpb24gUHJvY2Vzc2luZy4KdGNwX2lu aXQ6IG5ldC5pbmV0LnRjcC50Y2JoYXNoc2l6ZSBhdXRvIHR1bmVkIHRvIDgxOTIKaWljYnVzMDog PE9GVyBJMkMgYnVzPiBvbiBpaWNoYjAKaWljMDogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVz MAppaWNidXMxOiA8T0ZXIEkyQyBidXM+IG9uIGlpY2hiMQppaWMxOiA8STJDIGdlbmVyaWMgSS9P PiBvbiBpaWNidXMxCmlpY2J1czI6IDxPRlcgSTJDIGJ1cz4gb24gaWljaGIyCmlpYzI6IDxJMkMg Z2VuZXJpYyBJL08+IG9uIGlpY2J1czIKdXNidXMwOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYy LjAK --b1_52ddbc48b3c09239cdcadbfd6134490a-- From owner-freebsd-arm@freebsd.org Sun Jul 21 14:40:56 2019 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 D8B90B519C for ; Sun, 21 Jul 2019 14:40:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D8D782E06 for ; Sun, 21 Jul 2019 14:40:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x6LEejsR008767 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 21 Jul 2019 17:40:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x6LEejsR008767 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x6LEejAc008766; Sun, 21 Jul 2019 17:40:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jul 2019 17:40:45 +0300 From: Konstantin Belousov To: Robert Crowston Cc: "freebsd-arm@freebsd.org" Subject: Re: Raspberry Pi 4 boot hangs in sched_idletd. Message-ID: <20190721144045.GI47193@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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: Sun, 21 Jul 2019 14:40:56 -0000 On Sun, Jul 21, 2019 at 02:14:12PM +0000, Robert Crowston via freebsd-arm wrote: > I need a bit of a hand with this. I've been working on getting FreeBSD 13.0-Current up and running on my pi4. I'm using the GENERIC configuration for now. I have a JTAG hardware debugger so I've got a pretty good introspection on what's going on at the detail level, but I'm missing some of the bigger picture. > > The first problem is, this board has two interrupt controllers on the FDT; the bcm2836-l1-intc local interrupt controller (local_intc) that was present on the RPi3, and also a new gic400. Both the drivers call intr_pic_claim_root(), which causes a panic. If I remove the gic400 from the FDT, very little of the hardware enumeration succeeds and the kernel panics because there is no event timer. If I remove the local_intc, a few devices, including the BCM2835 DMA controller, the SD card controllers, and the GPIO drivers fail to start, but the rest of the hardware enumeration finishes. I don't know enough about the hardware topology to figure out which one is the real root and fix the drivers accordingly. > > So, without local_intc, we get another problem. Late in the boot sequence, the idle thread gets swapped in, and there are still threads on the sleep queue, including thread0, but no other threads get put on the run queue, and the Pi loops through sched_idletd thread forever instead of finishing the boot. > > By poking things in the debugger I can progress as far as vfs_mountroot_wait(), and I think there is a race condition because the behaviour is different if I step through manually without changing anything, but whatever happens, eventually I end up stuck in the sched_idletd loop. > > I think perhaps event timer interrupts are not being delivered so the sleep queue never gets moved to the run queue?, but I'm guessing here. Sleeping state is terminated by wakeup which happens either by timeouts (which indeed requires working event timers) or due to explicit wakeup when the waiting wait channel is signalled (by wakeup(9)). For me, the sleep in root mount code sounds as io request did not finished, so the mount code cannot mount root. But really you should start examining the sleep chain of the thread0 and see which exact condition it waits for. You did not even provided the backtrace for it. > > More detail: > > So far I'm in mi_startup(), and about ~1150 out of ~1200 SYSINIT tasks are done. Eventually we get to initialize the usbus. One of its worker threads calls _sleep(): > > Breakpoint 6, _sleep (ident=0xffff000000c5eb28 , lock=0x0, priority=0, > wmesg=0xffff000000775d55 "USBWAIT", sbt=47244637, pr=0, flags=256) > at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:139 > 139 td = curthread; > (gdb) bt > #0 _sleep (ident=0xffff000000c5eb28 , lock=0x0, priority=0, > wmesg=0xffff000000775d55 "USBWAIT", sbt=47244637, pr=0, flags=256) > at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:139 > #1 0xffff00000029db08 in usbd_req_set_address (udev=0xfffffd0000d23000, mtx=0x0, > addr=) at /skeleton/root/sandbox/src/sys/dev/usb/usb_request.c:1580 > #2 0xffff00000028d05c in usb_alloc_device (parent_dev=, bus=0xffff0000405fe000, > parent_hub=0x0, depth=, port_index=, port_no=, > speed=USB_SPEED_HIGH, mode=) > at /skeleton/root/sandbox/src/sys/dev/usb/usb_device.c:1824 > #3 0xffff000000281524 in usb_bus_attach (pm=) > at /skeleton/root/sandbox/src/sys/dev/usb/controller/usb_controller.c:767 > #4 0xffff00000029b750 in usb_process (arg=0xffff0000405fe130) > at /skeleton/root/sandbox/src/sys/dev/usb/usb_process.c:178 > #5 0xffff0000003b78c0 in fork_exit (callout=0xffff00000029b65c , > arg=0xffff0000405fe130, frame=0xffff00004024cba0) > at /skeleton/root/sandbox/src/sys/kern/kern_fork.c:1056 > #6 0xffff00000071fe88 in fork_trampoline () > at /skeleton/root/sandbox/src/sys/arm64/arm64/swtch.S:214 > > _sleep() swaps the usb_process thread off the CPU. If I step through, another few threads are put on the CPU, including taskqueue_thread_loop, soaio_kproc_loop, random_kthread. Sometimes I also see the interrupt event thread, but not always. Sometimes if I step, I'll find thread0 does get back on the CPU, in which case we can progress as far as release_aps(), but then the other CPUs get stuck in sched_idletd and eventually CPU0 will hang in smp_rendezvous() waiting for the other CPUs. > > Does anyone have any ideas what I should investigate next? > > Boot log attached. > > > Loading kernel... > /boot/kernel/kernel text=0x9373b4 data=0x191048+0x84ab1c syms=[0x8+0x138798+0x8+0x124a30] > Loading configured modules... > can't find '/boot/entropy' > Using DTB provided by EFI at 0x7f04000. > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Type Physical Virtual #Pages Attr > Reserved 000000000000 0 00000001 WB > ConventionalMemory 000000004000 4000 00007f00 WB > BootServicesData 000007f04000 7f04000 00000009 WB > ConventionalMemory 000007f0d000 7f0d000 00027de4 WB > LoaderData 00002fcf1000 2fcf1000 00004001 WB > BootServicesData 000033cf2000 33cf2000 00000002 WB > LoaderData 000033cf4000 33cf4000 00004000 WB > LoaderCode 000037cf4000 37cf4000 0000009c WB > Reserved 000037d90000 37d90000 00000002 WB > LoaderData 000037d92000 37d92000 000021a1 WB > LoaderCode 000039f33000 39f33000 00000015 WB > Reserved 000039f48000 39f48000 00000006 WB > RuntimeServicesData 000039f4e000 39f4e000 00000001 WB RUNTIME > Reserved 000039f4f000 39f4f000 00000005 WB > RuntimeServicesData 000039f54000 39f54000 00000001 WB RUNTIME > Reserved 000039f55000 39f55000 00000001 WB > LoaderData 000039f56000 39f56000 000013fa WB > RuntimeServicesCode 00003b350000 3b350000 00000010 WB RUNTIME > LoaderData 00003b360000 3b360000 000000a0 WB > MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME > Physical memory chunk(s): > 0x00004000 - 0x37d8ffff, 893 MB ( 228748 pages) > 0x37d92000 - 0x39f47fff, 33 MB ( 8630 pages) > 0x39f4e000 - 0x39f4efff, 0 MB ( 1 pages) > 0x39f54000 - 0x39f54fff, 0 MB ( 1 pages) > 0x39f56000 - 0x3b34ffff, 19 MB ( 5114 pages) > 0x3b360000 - 0x3b3fffff, 0 MB ( 160 pages) > Excluded memory regions: > 0x00000000 - 0x00000fff, 0 MB ( 1 pages) NoAlloc > 0x2fe00000 - 0x315a3fff, 23 MB ( 6052 pages) NoAlloc > 0x37d90000 - 0x37d91fff, 0 MB ( 2 pages) NoAlloc > 0x39f48000 - 0x39f55fff, 0 MB ( 14 pages) NoAlloc > 0x3b350000 - 0x3b35ffff, 0 MB ( 16 pages) NoAlloc > 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc > Found 4 CPUs in the device tree > Copyright (c) 1992-2019 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-CURRENT #0 2474a68216f(master)-dirty: Sat Jul 13 21:19:35 BST 2019 > root@crossbuild.tiberius:/skeleton/root/sandbox/work-rpi4.1/obj/skeleton/root/sandbox/src/arm64.aarch64/sys/GENERIC arm64 > FreeBSD clang version 8.0.1 (branches/release_80 363030) (based on LLVM 8.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > VT: init without driver. > Preloaded elf kernel "/boot/kernel/kernel" at 0xffff000001579000. > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled. > VIMAGE (virtualized network stack) enabled > ULE: setup cpu 0 > ULE: setup cpu 1 > ULE: setup cpu 2 > ULE: setup cpu 3 > random: entropy device external interface > snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] > feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 > MAP 39f4e000 mode 2 pages 1 > MAP 39f54000 mode 2 pages 1 > MAP 3b350000 mode 2 pages 16 > EFI Runtime entry 19 mapping attributes unsupported > MAP fe100000 mode 1 pages 1 > nfslock: pseudo-device > crypto: > kbd0 at kbdmux0 > mem: > null: > openfirm: > ofwbus0: > simplebus0: on ofwbus0 > ofw_clkbus0: on ofwbus0 > clk_fixed0: on ofw_clkbus0 > clk_fixed1: on ofw_clkbus0 > simplebus1: on ofwbus0 > simplebus2: on ofwbus0 > regfix0: on ofwbus0 > regfix1: on ofwbus0 > psci0: on ofwbus0 > psci0: PSCI version 0.2 compatible > gic0: mem 0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x40046000-0x40047fff on simplebus0 > simplebus0: no default resources for rid = 0, type = 1 > gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256 > gpio0: mem 0x7e200000-0x7e2000b3 irq 22,23,24,25 on simplebus0 > gpiobus0: on gpio0 > Processing 3 pin-config node(s) in pinctrl-0 for serial@7e201000 > gpio0: set pin 30 to func 7, pull 2 > gpio0: set pin 31 to func 7, pull 0 > gpio0: set pin 32 to func 7, pull 0 > gpio0: set pin 32 to func 7, pull 0 [133/9134] > gpio0: set pin 33 to func 7, pull 2 > gpio0: set pin 43 to func 4, pull 0 > Processing 1 pin-config node(s) in pinctrl-0 for i2c@7e205000 > gpio0: set pin 0 to func 4 > gpio0: set pin 1 to func 4 > Processing 1 pin-config node(s) in pinctrl-0 for serial@7e215040 > gpio0: set pin 14 to func 2 > gpio0: set pin 15 to func 2 > Processing 1 pin-config node(s) in pinctrl-0 for sdhci@7e300000 > gpio0: set pin 34 to func 7, pull 0 > gpio0: set pin 35 to func 7, pull 2 > gpio0: set pin 36 to func 7, pull 2 > gpio0: set pin 37 to func 7, pull 2 > gpio0: set pin 38 to func 7, pull 2 > gpio0: set pin 39 to func 7, pull 2 > Processing 1 pin-config node(s) in pinctrl-0 for i2c@7e804000 > gpio0: set pin 2 to func 4 > gpio0: set pin 3 to func 4 > Processing 2 pin-config node(s) in pinctrl-0 for pwm@7e20c800 > gpio0: set pin 40 to func 4 > gpio0: set pin 41 to func 4 > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > generic_timer0: irq 4,5,6,7 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000 > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > usb_nop_xceiv0: on ofwbus0 > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > efirtc0: cannot read EFI realtime clock, error 78 > ofwbus0: disabled compat simple-framebuffer (no driver attached) > simplebus0: mem 0x7e004000-0x7e00401f irq 8 compat brcm,bcm2835-txp (no driver attached) > bcm_dma0: mem 0x7e007000-0x7e007aff irq 9,10,11,12,13,14,15,16,17,18,19 on simplebus0 > bcm_dma0: cannot setup interrupt handler > device_attach: bcm_dma0 attach returned 6 > bcmwd0: mem 0x7e100000-0x7e100113,0x7e00a000-0x7e00a023,0x7ec11000-0x7ec1101f on simplebus0 > simplebus0: mem 0x7e101000-0x7e102fff compat brcm,bcm2838-cprman (no driver attached) > simplebus0: mem 0x7e104000-0x7e10400f irq 20 compat brcm,bcm2838-rng200 (no driver attached) > mbox0: mem 0x7e00b880-0x7e00b8bf irq 21 on simplebus0 > gpioc0: on gpio0 > uart0: mem 0x7e201000-0x7e2011ff irq 26 on simplebus0 > uart0: fast interrupt > uart0: PPS capture mode: DCD > simplebus0: mem 0x7e202000-0x7e2020ff irq 27 disabled compat brcm,bcm2835-sdhost (no driver attached) > simplebus0: mem 0x7e203000-0x7e203023 disabled compat brcm,bcm2835-i2s (no driver attached) > simplebus0: mem 0x7e204000-0x7e2041ff irq 28 disabled compat brcm,bcm2835-spi (no driver attached) > iichb0: mem 0x7e205000-0x7e2051ff irq 29 on simplebus0 > simplebus0: mem 0x7e206000-0x7e2060ff irq 30 compat brcm,bcm2835-pixelvalve0 (no driver attached) > simplebus0: mem 0x7e207000-0x7e2070ff irq 31 compat brcm,bcm2835-pixelvalve1 (no driver attached) > simplebus0: mem 0x7e208000-0x7e20808b disabled compat brcm,bcm2835-dpi (no driver attached) > simplebus0: mem 0x7e209000-0x7e209077 irq 32 compat brcm,bcm2835-dsi0 (no driver attached) > simplebus0: mem 0x7e215000-0x7e215007 compat brcm,bcm2835-aux (no driver attached) > uart1: mem 0x7e215040-0x7e21507f irq 33 on simpuart1: console (115200,n,8,1) > uart1: fast interrupt > uart1: PPS capture mode: DCD > simplebus0: mem 0x7e215080-0x7e2150bf irq 34 disabled compat brcm,bcm2835-aux-spi (no driver attached) > simplebus0: mem 0x7e2150c0-0x7e2150ff irq 35 disabled compat brcm,bcm2835-aux-spi (no driver attached) > simplebus0: mem 0x7e20c000-0x7e20c027 disabled compat brcm,bcm2835-pwm (no driver attached) > sdhci_bcm0: mem 0x7e300000-0x7e3000ff irq 36 on simplebus0 > device_attach: sdhci_bcm0 attach returned 6 > simplebus0: mem 0x7e400000-0x7e405fff irq 37 compat brcm,bcm2835-hvs (no driver attached) > simplebus0: mem 0x7e700000-0x7e70008b irq 38 disabled compat brcm,bcm2835-dsi1 (no driver attached) > simplebus0: mem 0x7e800000-0x7e8007ff,0x7e802000-0x7e802003 irq 39 disabled compat brcm,bcm2835-unicam (no driver attached) > simplebus0: mem 0x7e801000-0x7e8017ff,0x7e802004-0x7e802007 irq 40 disabled compat brcm,bcm2835-unicam (no driver attached) > iichb1: mem 0x7e804000-0x7e804fff irq 41 on simplebus0 > iichb2: mem 0x7e805000-0x7e805fff irq 42 on simplebus0 > simplebus0: mem 0x7e806000-0x7e806fff irq 43 compat brcm,bcm2835-vec (no driver attached) > simplebus0: mem 0x7e807000-0x7e8070ff irq 44 compat brcm,bcm2835-pixelvalve2 (no driver attached) > simplebus0: mem 0x7e902000-0x7e9025ff,0x7e808000-0x7e8080ff irq 45,46 compat brcm,bcm2835-hdmi (no driver attached) > bcm283x_dwcotg0: mem 0x7e980000-0x7e98ffff irq 47 on simplebus0 > usbus0 on bcm283x_dwcotg0 > bcm283x_dwcotg0: usbpf: Attached > simplebus0: compat brcm,bcm2835-vc4 (no driver attached) > simplebus0: mem 0x7d5d2200-0x7d5d222b irq 48 compat brcm,avs-tmon-bcm2838 (no driver attached) > simplebus0: mem 0x7e201400-0x7e2015ff irq 49 disabled compat brcm,bcm2835-pl011 (no driver attached) > simplebus0: mem 0x7e201600-0x7e2017ff irq 50 disabled compat brcm,bcm2835-pl011 (no driver attached) > simplebus0: mem 0x7e201800-0x7e2019ff irq 51 disabled compat brcm,bcm2835-pl011 (no driver attached) > simplebus0: mem 0x7e201a00-0x7e201bff irq 52 disabled compat brcm,bcm2835-pl011 (no driver attached) > simplebus0: mem 0x7e204600-0x7e2047ff irq 53 disabled compat brcm,bcm2835-spi (no driver attached) > simplebus0: mem 0x7e204800-0x7e2049ff irq 54 disabled compat brcm,bcm2835-spi (no driver attached) > simplebus0: mem 0x7e204a00-0x7e204bff irq 55 disabled compat brcm,bcm2835-spi (no driver attached) > simplebus0: mem 0x7e204c00-0x7e204dff irq 56 disabled compat brcm,bcm2835-spi (no driver attached) > simplebus0: mem 0x7e205600-0x7e2057ff irq 57 disabled compat brcm,bcm2835-i2c (no driver attached) > simplebus0: mem 0x7e205800-0x7e2059ff irq 58 disabled compat brcm,bcm2835-i2c (no driver attached) > simplebus0: mem 0x7e205a00-0x7e205bff irq 59 disabled compat brcm,bcm2835-i2c (no driver attached) > simplebus0: mem 0x7e205c00-0x7e205dff irq 60 disabled compat brcm,bcm2835-i2c (no driver attached) > simplebus0: mem 0x7e20c800-0x7e20c827 compat brcm,bcm2835-pwm (no driver attached) > sdhci_bcm0: mem 0x7e340000-0x7e3400ff irq 61 on simplebus0 > device_attach: sdhci_bcm0 attach returned 6 > simplebus0: compat raspberrypi,bcm2835-firmware (no driver attached) > simplebus0: compat raspberrypi,bcm2835-power (no driver attached) > ofwbus0: irq 0,1,2,3 compat arm,cortex-a72-pmu (no driver attached) > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpu0: missing 'clock-frequency' property > cpu1: on cpulist0 > cpu1: missing 'clock-frequency' property > cpu2: on cpulist0 > cpu2: missing 'clock-frequency' property > cpu3: on cpulist0 > cpu3: missing 'clock-frequency' property > simplebus1: mem 0x7ec00000-0x7ec03fff,0x7ec04000-0x7ec07fff irq 62 compat brcm,2711-v3d (no driver attached) > simplebus2: mem 0x7d500000-0x7d50930f,0x7e00f300-0x7e00f31f irq 63,64 compat brcm,bcm7211-pcie (no driver attached) > simplebus2: mem 0x7d580000-0x7d58ffff irq 65,66 compat brcm,genet-v5 (no driver attached) > simplebus2: mem 0x7e007b00-0x7e007eff irq 67,68,69,70 compat brcm,bcm2838-dma (no driver attached) > simplebus2: mem 0x7e9c0000-0x7eabffff irq 71 disabled compat generic-xhci (no driver attached) > simplebus2: mem 0x7eb00000-0x7eb0ffff compat raspberrypi,argon-hevc-decoder (no driver attached) > simplebus2: mem 0x7eb10000-0x7eb10fff irq 72 compat raspberrypi,argon-local-intc (no driver attached) > simplebus2: mem 0x7eb20000-0x7eb2ffff compat raspberrypi,argon-h264-decoder (no driver attached) > simplebus2: mem 0x7eb30000-0x7eb3ffff compat raspberrypi,argon-vp9-decoder (no driver attached) > simplebus2: mem 0x7e00b840-0x7e00b87b irq 73 compat brcm,bcm2838-vchiq (no driver attached) > gpioled0: on ofwbus0 > gpioled0: failed to map pin > ofwbus0: compat mmc-pwrseq-simple (no driver attached) > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > cryptosoft0: > crypto: assign cryptosoft0 driver id 0, flags 0x6000000 > crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 32 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 34 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 35 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 36 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 37 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 29 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 30 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 31 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 40 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 39 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 38 flags 0 maxoplen 0 > Device configuration finished. > Found SMCCC version 1.0 > procfs registered > Timecounters tick every 1.000 msec > lo0: bpf attached > vlan: initialized, using hash tables with chaining > IPsec: Initialized Security Association Processing. > tcp_init: net.inet.tcp.tcbhashsize auto tuned to 8192 > iicbus0: on iichb0 > iic0: on iicbus0 > iicbus1: on iichb1 > iic1: on iicbus1 > iicbus2: on iichb2 > iic2: on iicbus2 > usbus0: 480Mbps High Speed USB v2.0 > _______________________________________________ > 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" From owner-freebsd-arm@freebsd.org Sun Jul 21 15:58:31 2019 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 95420B6938 for ; Sun, 21 Jul 2019 15:58:31 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.protonmail.ch", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ABB284E8B for ; Sun, 21 Jul 2019 15:58:31 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sun, 21 Jul 2019 15:58:24 +0000 To: Konstantin Belousov From: Robert Crowston Cc: "freebsd-arm@freebsd.org" Reply-To: Robert Crowston Subject: Re: Raspberry Pi 4 boot hangs in sched_idletd. Message-ID: <8CXuLvQgIxwpLP0upt_kfzOMKpuEKBESlNEdQXWZcr6NNTFIzJn0piQPSRs0qxb7o5NMu3sRGJo7jpMvvbgWB0CjauTZoBNDt7PuqbDqNIU=@protonmail.com> In-Reply-To: <20190721144045.GI47193@kib.kiev.ua> References: <20190721144045.GI47193@kib.kiev.ua> Feedback-ID: 2OVbcR1yHYpdkD8cgQllkFwcuMVZg_LiVMMPvptooFDfHD_03MuQO4ZaF626jWHZYFEhNR2cmIbZ53j4QGWMBQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Rspamd-Queue-Id: 6ABB284E8B X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Sun, 21 Jul 2019 15:58:31 -0000 > Sleeping state is terminated by wakeup which happens either by timeouts > (which indeed requires working event timers) or due to explicit wakeup wh= en > the waiting wait channel is signalled (by wakeup(9)). I have seen threads resume through wakeup(), so I think that part is workin= g. > But really you should start examining the sleep chain of the thread0 and > see which exact condition it waits for. That's a helpful insight. > You did not even provided the backtrace for it. Breakpoint 8, mi_switch (flags=3D260, newtd=3D0x0) at /skeleton/root/sandbo= x/src/sys/kern/kern_synch.c:402 402 td =3D curthread; /* XXX */ #0 mi_switch (flags=3D260, newtd=3D0x0) at /skeleton/root/sandbox/src/sys/= kern/kern_synch.c:402 #1 0xffff0000004492ac in sleepq_switch (wchan=3D0xffff00000099fba0 , pri=3D) at /skeleton/root/sandbox/src/sys/= kern/subr_sleepqueue.c:625 #2 0xffff000000449920 in sleepq_timedwait (wchan=3D0xffff00000099fba0 , pri=3D0) at /skeleton/root/sandbox/src/sys/kern/subr_s= leepqueue.c:739 #3 0xffff0000004006bc in _sleep (ident=3D0xffff00000099fba0 , lock=3D0xffff000000d461e0 , priority=3D0,= wmesg=3D0xffff00000080569d "conifhk", sbt=3D257698020000, pr=3D0, flags=3D256) at /skeleton/root/sandbox/src/sys/= kern/kern_synch.c:213 #4 0xffff00000042576c in boot_run_interrupt_driven_config_hooks (dummy=3D<= optimized out>) at /skeleton/root/sandbox/src/sys/kern/subr_autoconf.c:162 #5 0xffff0000003908a8 in mi_startup () at /skeleton/root/sandbox/src/sys/k= ern/init_main.c:314 #6 0xffff000000001088 in virtdone () at /skeleton/root/sandbox/src/sys/arm= 64/arm64/locore.S:142 Backtrace stopped: previous frame identical to this frame (corrupt stack?) The final time I see we are on thread0, we are running boot_run_interrupt_d= riven_config_hooks, which looks like it has a sixty second delay. It's not = the first or the last sleepq_timedwait in the boot, but it's probably the l= ongest. I'll dig into the event timer side and try to figure out what inter= rupts its expecting. From owner-freebsd-arm@freebsd.org Sun Jul 21 16:05:59 2019 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 1AB56B6E08 for ; Sun, 21 Jul 2019 16:05:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC68E8554E for ; Sun, 21 Jul 2019 16:05:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x6LG5pWn028458 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 21 Jul 2019 19:05:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x6LG5pWn028458 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x6LG5pgX028457; Sun, 21 Jul 2019 19:05:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Jul 2019 19:05:51 +0300 From: Konstantin Belousov To: Robert Crowston Cc: "freebsd-arm@freebsd.org" Subject: Re: Raspberry Pi 4 boot hangs in sched_idletd. Message-ID: <20190721160551.GK47193@kib.kiev.ua> References: <20190721144045.GI47193@kib.kiev.ua> <8CXuLvQgIxwpLP0upt_kfzOMKpuEKBESlNEdQXWZcr6NNTFIzJn0piQPSRs0qxb7o5NMu3sRGJo7jpMvvbgWB0CjauTZoBNDt7PuqbDqNIU=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CXuLvQgIxwpLP0upt_kfzOMKpuEKBESlNEdQXWZcr6NNTFIzJn0piQPSRs0qxb7o5NMu3sRGJo7jpMvvbgWB0CjauTZoBNDt7PuqbDqNIU=@protonmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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: Sun, 21 Jul 2019 16:05:59 -0000 On Sun, Jul 21, 2019 at 03:58:24PM +0000, Robert Crowston wrote: > > Sleeping state is terminated by wakeup which happens either by timeouts > > (which indeed requires working event timers) or due to explicit wakeup when > > the waiting wait channel is signalled (by wakeup(9)). > > I have seen threads resume through wakeup(), so I think that part is working. Wakeup(9) itself most likely work, otherwise you would not get to the mount root stage of boot. What did not worked, probably, is some specific event which occurence causes wakeup for intr_config_hook. There, only you can inspect the state and see why it did not happen. > > > But really you should start examining the sleep chain of the thread0 and > > see which exact condition it waits for. > > That's a helpful insight. > > > You did not even provided the backtrace for it. > > Breakpoint 8, mi_switch (flags=260, newtd=0x0) at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:402 > 402 td = curthread; /* XXX */ > #0 mi_switch (flags=260, newtd=0x0) at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:402 > #1 0xffff0000004492ac in sleepq_switch (wchan=0xffff00000099fba0 , pri=) at /skeleton/root/sandbox/src/sys/kern/subr_sleepqueue.c:625 > #2 0xffff000000449920 in sleepq_timedwait (wchan=0xffff00000099fba0 , pri=0) at /skeleton/root/sandbox/src/sys/kern/subr_sleepqueue.c:739 > #3 0xffff0000004006bc in _sleep (ident=0xffff00000099fba0 , lock=0xffff000000d461e0 , priority=0, wmesg=0xffff00000080569d "conifhk", > sbt=257698020000, pr=0, flags=256) at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:213 > #4 0xffff00000042576c in boot_run_interrupt_driven_config_hooks (dummy=) at /skeleton/root/sandbox/src/sys/kern/subr_autoconf.c:162 > #5 0xffff0000003908a8 in mi_startup () at /skeleton/root/sandbox/src/sys/kern/init_main.c:314 > #6 0xffff000000001088 in virtdone () at /skeleton/root/sandbox/src/sys/arm64/arm64/locore.S:142 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > The final time I see we are on thread0, we are running boot_run_interrupt_driven_config_hooks, which looks like it has a sixty second delay. It's not the first or the last sleepq_timedwait in the boot, but it's probably the longest. I'll dig into the event timer side and try to figure out what interrupts its expecting. It is almost certainly not the eventtimers issue. From owner-freebsd-arm@freebsd.org Sun Jul 21 16:53:51 2019 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 12C27B819F for ; Sun, 21 Jul 2019 16:53:51 +0000 (UTC) (envelope-from oskar.holmlund@yahoo.com) Received: from sonic312-26.consmr.mail.ir2.yahoo.com (sonic312-26.consmr.mail.ir2.yahoo.com [77.238.178.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C7C486FF4 for ; Sun, 21 Jul 2019 16:53:48 +0000 (UTC) (envelope-from oskar.holmlund@yahoo.com) X-YMail-OSG: dsavzU0VM1n9FOLkNz2TWoqYFM8yUgKHTAK9wqOyntCNxRKEtLYT.tB.OU2pPig wIEHP9N_PY74zgD1UdKNNNLnM.oqtxFBhbYjQ.atEoH4mdwr3oGi4V8g6rYzNEeDaF21TKBYt4IK 8bbk1JRnBs8Jo1UAqglnM7xEoAWGyT56BPgktRwzvqH2086TUesiN5fq4D1225PFG13evqXgSEfW u_8d9uFqDnntIWJN3ytwiZ8h_C9y0Azd7WDB_caFGpgGRUelphMIoZsbOBhzBTwd4qHzr5jgMw7v nEIE4wXL.N7uwsbjbewi4dWgg1Q1uGEDsr8sRDVYuW59XG5LMpGdHDeVW4UqHsl3o33iBl_aVZtp eLkDv42HNcti0F1TZsFGd3u_.GKKE7e460s7XkGkswG9hKQvg_4VU4fnF18iMaMTMuC5Wt27yjta 7raNVfDcf.NGTdaHkRte7vZWHA3EjI059G3DKwhZXE49Coy8jlGzb4P6seu_e1e8sZXi60hRXL0i 2GyHNGmbnmb0_HQ5Zts5K2Du9F5hFlUevSKj55xcUGtelpRDOA2CWy3oyuuktmMj43P0il6VqDvV FBbxgCoj7pog0t.0JPYcv29V9btvkmAlvSTXUPGKdDzfFvrhrWRoywGnfvNmhVpIYcGg8bKpzMLR NmPDvfUPyf6dCri7GPwvioIBdmxYwcVu1YQ8KQM6wBNxFweTFmDxPT4TQx1W9qjt8ZTMCcXX2kO0 wR9P8WA9K4VlrCaZWCKCkdGntExL7nfpBcoZ8QK3foKIlcDQUW6iyzMVINeOWt2EAYwju8gqiV1R 7IK887U4fbWcQEu131wzTRstxvF_MovOU8QDE6rrG6KiOM3vVFep.Rh3wGo.exSsK1jjLecKu.X_ I5EcSKyyMNuIeQpIye1JbbxkCtIHkQZu5oIpF0t9ZCY6BmGTlvG84rent.2pj6hsUBPtZFMqNgau 8VzAOlB8UrKpnu_lTV4rxuCd_BBmFVZfNAKXs0RVtclxYWoistGYrz0bn8UKvNN89SqwDZ6m27ki oOBG9ArO9jr6oPqEEn0iGvHkEBznQ330JyRoIzlSSoiXbGjpYB9gbAVjG7KaCYdK5ejAGLDTeUhr M.Hrd3Ed2wr8cdJoxLMZmeUwELzL2tBqO1zbukC1vAdqMLiMkb144la5vP0pEaNmc9wkluuBFHFb DjrHX7ZjQv4NfX9IBwBjeG7RVVgFArSJF2Ai0oc9wuuUhneIWCNc2ma1FeKvLJ_OJtGFf1rrX7FN 3h9N4nQZ0ZCiqzKgghvV0HJHDsJxBpxUlmzBJ Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ir2.yahoo.com with HTTP; Sun, 21 Jul 2019 16:53:42 +0000 Date: Sun, 21 Jul 2019 16:53:02 +0000 (UTC) From: Oskar Holmlund To: freebsd-arm@freebsd.org, sig term Message-ID: <2026970446.6253639.1563727982286@mail.yahoo.com> In-Reply-To: References: Subject: Re: BeagleBone Black hangs after importing Linux 5.0 DTS MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0 X-Rspamd-Queue-Id: 4C7C486FF4 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.95 / 15.00]; ARC_NA(0.00)[]; NEURAL_SPAM_LONG(0.81)[0.806,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.98)[0.982,0]; NEURAL_SPAM_SHORT(0.88)[0.882,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCVD_IN_DNSWL_NONE(0.00)[97.178.238.77.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(1.29)[ip: (2.49), ipnet: 77.238.176.0/22(2.26), asn: 34010(1.79), country: GB(-0.08)]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:34010, ipnet:77.238.176.0/22, country:GB]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] 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: Sun, 21 Jul 2019 16:53:51 -0000 2019-07-19 13:24 skrev sig term:=20 > I just test my BeagleBone Black board with the latest image=20 > FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20190718-r350103.img.xz > it still freezes at the same place.=20 > > I also tested it with the old am335x-boneblack.dtb from r346087, > the board boots without any problem. > _______________________________________________=20 > freebsd-arm@freebsd.org mailing list=20 > https://lists.freebsd.org/mailman/listinfo/freebsd-arm=20 > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"=20 Check out sys/gnu/dts/arm/am33xx.dtsi and the new file am33xx-l4.dtsi in R3= 46092. More informtion in the commit logs https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch= /arm/boot/dts/am33xx-l4.dtsi The Linux kernel dts description is here https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc= umentation/devicetree/bindings/bus/ti-sysc.txt We probably need to implement a driver handling the TI sysc interconnect DT= S entries. I think its chapter 10 in TI AM335x Technical reference manual (= SPRUH73P).=20 -- B=C3=A4sta H=C3=A4lsningar Oskar Holmlund Tel 070-3220292 From owner-freebsd-arm@freebsd.org Sun Jul 21 18:05:23 2019 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 BD118B9B2F for ; Sun, 21 Jul 2019 18:05:23 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 88CB48AA24 for ; Sun, 21 Jul 2019 18:05:23 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.nyi.freebsd.org (Postfix) id 86488B9B2E; Sun, 21 Jul 2019 18:05:23 +0000 (UTC) Delivered-To: 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 84ECBB9B2C for ; Sun, 21 Jul 2019 18:05:23 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90C9B8AA23 for ; Sun, 21 Jul 2019 18:05:18 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id x6LI5B3R022301 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 21 Jul 2019 11:05:11 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id x6LI5AJD022300 for arm@FreeBSD.org; Sun, 21 Jul 2019 11:05:10 -0700 (PDT) (envelope-from jmg) Date: Sun, 21 Jul 2019 11:05:10 -0700 From: John-Mark Gurney To: arm@FreeBSD.org Subject: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-ID: <20190721180510.GQ2342@funkthat.com> Mail-Followup-To: arm@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sun, 21 Jul 2019 11:05:11 -0700 (PDT) X-Rspamd-Queue-Id: 90C9B8AA23 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of jmg@gold.funkthat.com designates 208.87.223.18 as permitted sender) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [0.47 / 15.00]; R_SPF_ALLOW(-0.20)[+a]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[gold.funkthat.com]; NEURAL_HAM_SHORT(-0.46)[-0.460,0]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.976,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.978,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arm@freebsd.org]; DMARC_NA(0.00)[funkthat.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; MX_MISSING(3.50)[requested record is not found]; IP_SCORE(-0.61)[ip: (-1.57), ipnet: 208.87.216.0/21(-0.79), asn: 32354(-0.63), country: US(-0.05)] 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: Sun, 21 Jul 2019 18:05:23 -0000 The microSD card that I was using on my BeagleBone white got corrupted, so I decided to update to the latest version. The latest snapshot fails to boot. It loads the kernel, but then when starting the kernel, it hangs, and eventually it will reset. The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. Any ideas? I tried all three available 13 snaps, and they all behave the same. The following is an example of the reset loop: Kernel entry at 0x84000180... Kernel args: (null) / U-Boot SPL 2019.04 (Jul 18 2019 - 04:19:33 +0000) Trying to boot from MMC1 Loading Environment from FAT... *** Warning - bad CRC, using default environment U-Boot 2019.04 (Jul 18 2019 - 04:19:33 +0000) CPU : AM335X-GP rev 1.0 Model: TI AM335x BeagleBone DRAM: 256 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment not set. Validating first E-fuse MAC Net: eth0: ethernet@4a100000 Warning: usb_ether MAC addresses don't match: Address in ROM is de:ad:be:ef:00:01 Address in environment is d4:94:a1:85:ce:72 , eth1: usb_ether Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... 80492 bytes read in 8 ms (9.6 MiB/s) Found EFI removable media binary efi/boot/bootarm.efi Scanning disk mmc@48060000.blk... Found 3 disks BootOrder not defined 616000 bytes read in 54 ms (10.9 MiB/s) ## Starting EFI application at 82000000 ... Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm EFI loader, Revision 1.1 Command line arguments: l EFI version: 2.70 EFI Firmware: Das U-Boot (rev 8217.1024) Console: efi (0) Load Path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8)/efi\boot\bootarm.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8) Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8) Setting currdev to disk0p1: Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x193d7,0x5e6c11) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local Loading kernel... /boot/kernel/kernel text=0x85a6c4 data=0xb41e0+0x258720 syms=[0x4+0xa8d50+0x4+0x10c071] Loading configured modules... can't find '/boot/entropy' /boot/kernel/umodem.ko text=0x1be0 text=0x1310 data=0x1088+0xf80 syms=[0x4+0x1070+0x4+0xbcd] loading required module 'ucom' /boot/kernel/ucom.ko text=0x1f74 text=0x2e40 data=0x1088+0x17b4 syms=[0x4+0x14f0+0x4+0xc5d] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by EFI at 0x87ee9000. Kernel entry at 0x84000180... Kernel args: (null) / U-Boot SPL 2019.04 (Jul 18 2019 - 04:19:33 +0000) Trying to boot from MMC1 Loading Environment from FAT... *** Warning - bad CRC, using default environment -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Sun Jul 21 18:31:38 2019 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 1CD5FBA358 for ; Sun, 21 Jul 2019 18:31:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F109F8B81A for ; Sun, 21 Jul 2019 18:31:37 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id EEA94BA357; Sun, 21 Jul 2019 18:31:37 +0000 (UTC) Delivered-To: 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 EE64CBA356 for ; Sun, 21 Jul 2019 18:31:37 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD6658B818 for ; Sun, 21 Jul 2019 18:31:37 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1563733896; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=dh+JH+RyQeBlSkZwNsKaNvlJHRg+iYtEiqaI/fSeVDyCfbrMYbxXHjNUbZYlYkgK4NiNfiH3Zubjc i3Dk+OYN/GHBWjhCdrclzqjaxanzzqLc3wUtgosANHe8+q5o55wirYYz4YVDfM8dmnHIKxpLIANnY9 HvqUh4clZXZbbYYwOFsJGo4YJS5eVJKaxUr6+bq1BbywxTRyGbtVGbMddcpN3uBNcPcLuKW1Y8NtHe QWBavoZOwjdNyqYyLWl5lbrfUfXzex1Kzy3NwFp0gz4KsUM0K9Cufe7x/yP3bQDR/GHzNVFaitvzn9 5Td+SFVagpc2LFq9dElowdUi7qd5nhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=o/54j6+vqyDc1oJhOlNHz2aPvqB1yzK3Y1ozFSUsdhs=; b=uDpw1drLJvV54XayitZcoGpDdgck+8alYIYpHLtyRDAFsQxKCSgY8TdI61KsXLB1KJNHkOBJO9uh4 pksvdTZVILYsjhSURoJTmlOJcQOEuPCcdUw8rt0DAi3p9N7m2kidKeUa0XArYtIkdlpjgHsilslDBw fnRXxR5OtqcBiabAA++m2puM997KBPGebpxjF9gglXLBeYlAFYdCfsG5LW1LnSQnSo3oaSS4yVXeEv St2vKjNwmdOdRWJDiTjqLCesiL+guznYTg+BuehuKv96W+luS8sRmtIZpb6vIssKjPM/Jlkco50UoA QEG5eHMo9nsVgmme7lHJc02EU7Bw38w== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=o/54j6+vqyDc1oJhOlNHz2aPvqB1yzK3Y1ozFSUsdhs=; b=GeiG0N03M0XVRVz6JBHmxLejbAlIX4l/avEWhn3vMt48HrExFaiDNYcIYIF5YYMjlGeOO/Wf+jXgW Ibiq3J8ka3znUxfndZK0hL2JVnOANymPsiKIIa3Uk5Ho1xIvXOQ59FvvrzGBjtJ6RnoOMjrBu3rl0t K4ehjbC4i0Nv2SXn1IWVc+w5dQf3MtWumvMzaeqteNQqoYlJycOD/uJDQ+eyduHqDDVbhxXfPDCCym GT6sa4WxDw0h9A/PQpCBBqU43fu12IXMoprj4XjmFB7xIPuZ5N6KUL9nxQH7ngzzDQyVCpqaeAvvU3 7k2VdqGguOXLpi72f14ZaWBQVEwXP/g== X-MHO-RoutePath: aGlwcGll X-MHO-User: c38c61a7-abe5-11e9-90e8-c17e0c9f2e02 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id c38c61a7-abe5-11e9-90e8-c17e0c9f2e02; Sun, 21 Jul 2019 18:31:34 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x6LIVW44057709; Sun, 21 Jul 2019 12:31:32 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White From: Ian Lepore To: John-Mark Gurney , arm@FreeBSD.org Date: Sun, 21 Jul 2019 12:31:32 -0600 In-Reply-To: <20190721180510.GQ2342@funkthat.com> References: <20190721180510.GQ2342@funkthat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: AD6658B818 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Sun, 21 Jul 2019 18:31:38 -0000 On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote: > The microSD card that I was using on my BeagleBone white got > corrupted, > so I decided to update to the latest version. The latest snapshot > fails > to boot. It loads the kernel, but then when starting the kernel, it > hangs, and eventually it will reset. > > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. > > Any ideas? I tried all three available 13 snaps, and they all behave > the same. > This happened with the latest DTS import (which was months ago). A couple people have speculated that we just need a trivial do-nothing driver for the new ti,sysc device, but when I tried that a couple months ago it didn't work, so instead I just reverted sys/dts to the old source and got on with what I needed to do. This is just the latest in a years-long string of breakages because the linux TI folks just never stop tinkering with their device-tree source. I'm sure they're doing it because it gets them some benefits, but for us the changes add no value and have a high maintenance cost. A hang before the copyright banner appears is especially painful to debug (doubly so because there's no existing EARLY_PRINTF support in the ti code). - Ian > The following is an example of the reset loop: > Kernel entry at 0x84000180... > Kernel args: (null) > / > U-Boot SPL 2019.04 (Jul 18 2019 - 04:19:33 +0000) > Trying to boot from MMC1 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > > > U-Boot 2019.04 (Jul 18 2019 - 04:19:33 +0000) > I just tried the trivial sysc driver again, it definitely hangs the > same as not having the driver. > CPU : AM335X-GP rev 1.0 > Model: TI AM335x BeagleBone > DRAM: 256 MiB > NAND: 0 MiB > MMC: OMAP SD/MMC: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > not set. Validating first E-fuse MAC > Net: eth0: ethernet@4a100000 > Warning: usb_ether MAC addresses don't match: > Address in ROM is de:ad:be:ef:00:01 > Address in environment is d4:94:a1:85:ce:72 > , eth1: usb_ether > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > 80492 bytes read in 8 ms (9.6 MiB/s) > Found EFI removable media binary efi/boot/bootarm.efi > Scanning disk mmc@48060000.blk... > Found 3 disks > BootOrder not defined > 616000 bytes read in 54 ms (10.9 MiB/s) > ## Starting EFI application at 82000000 ... > Consoles: EFI console > Reading loader env vars from /efi/freebsd/loader.env > Setting currdev to disk0p1: > FreeBSD/arm EFI loader, Revision 1.1 > > Command line arguments: l > EFI version: 2.70 > EFI Firmware: Das U-Boot (rev 8217.1024) > Console: efi (0) > Load Path: /VenHw(e61d73b9-a384-4acc-aeab- > 82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8)/efi\boot\bootarm > .efi > Load Device: /VenHw(e61d73b9-a384-4acc-aeab- > 82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8) > Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab- > 82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8) > Setting currdev to disk0p1: > Trying: /VenHw(e61d73b9-a384-4acc-aeab- > 82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x193d7,0x5e6c11) > Setting currdev to disk0p2: > Loading /boot/defaults/loader.conf > Loading /boot/device.hints > Loading /boot/loader.conf > Loading /boot/loader.conf.local > Loading kernel... > /boot/kernel/kernel text=0x85a6c4 data=0xb41e0+0x258720 > syms=[0x4+0xa8d50+0x4+0x10c071] > Loading configured modules... > can't find '/boot/entropy' > /boot/kernel/umodem.ko text=0x1be0 text=0x1310 data=0x1088+0xf80 > syms=[0x4+0x1070+0x4+0xbcd] > loading required module 'ucom' > /boot/kernel/ucom.ko text=0x1f74 text=0x2e40 data=0x1088+0x17b4 > syms=[0x4+0x14f0+0x4+0xc5d] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by EFI at 0x87ee9000. > Kernel entry at 0x84000180... > Kernel args: (null) > / > U-Boot SPL 2019.04 (Jul 18 2019 - 04:19:33 +0000) > Trying to boot from MMC1 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > From owner-freebsd-arm@freebsd.org Sun Jul 21 20:56:18 2019 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 2EAE1BE0FD for ; Sun, 21 Jul 2019 20:56:18 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 644376BFDF for ; Sun, 21 Jul 2019 20:56:17 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.nyi.freebsd.org (Postfix) id 631A2BE0F1; Sun, 21 Jul 2019 20:56:17 +0000 (UTC) Delivered-To: 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 62B6BBE0F0 for ; Sun, 21 Jul 2019 20:56:17 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A1B66BFBB; Sun, 21 Jul 2019 20:56:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id x6LKtvJo024889 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 21 Jul 2019 13:55:57 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id x6LKtvHZ024888; Sun, 21 Jul 2019 13:55:57 -0700 (PDT) (envelope-from jmg) Date: Sun, 21 Jul 2019 13:55:57 -0700 From: John-Mark Gurney To: Ian Lepore Cc: arm@FreeBSD.org Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-ID: <20190721205557.GR2342@funkthat.com> Mail-Followup-To: Ian Lepore , arm@FreeBSD.org References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sun, 21 Jul 2019 13:55:58 -0700 (PDT) X-Rspamd-Queue-Id: 2A1B66BFBB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Sun, 21 Jul 2019 20:56:18 -0000 Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600: > On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote: > > The microSD card that I was using on my BeagleBone white got > > corrupted, > > so I decided to update to the latest version. The latest snapshot > > fails > > to boot. It loads the kernel, but then when starting the kernel, it > > hangs, and eventually it will reset. > > > > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. > > > > Any ideas? I tried all three available 13 snaps, and they all behave > > the same. > > > > This happened with the latest DTS import (which was months ago). A > couple people have speculated that we just need a trivial do-nothing > driver for the new ti,sysc device, but when I tried that a couple > months ago it didn't work, so instead I just reverted sys/dts to the > old source and got on with what I needed to do. Can we revert the dts in the tree then? Doesn't help when we know the fix, but don't apply it... Or add an overlay that undoes the changes? I can do some testing... > This is just the latest in a years-long string of breakages because the > linux TI folks just never stop tinkering with their device-tree source. > I'm sure they're doing it because it gets them some benefits, but for > us the changes add no value and have a high maintenance cost. A hang > before the copyright banner appears is especially painful to debug > (doubly so because there's no existing EARLY_PRINTF support in the ti > code). [...] -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Sun Jul 21 21:01:24 2019 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 03DCDBE827 for ; Sun, 21 Jul 2019 21:01:24 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D2976C58A for ; Sun, 21 Jul 2019 21:01:23 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2982715CD for ; Sun, 21 Jul 2019 21:01:22 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x6LL1M5P053516 for ; Sun, 21 Jul 2019 21:01:22 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6LL1M9Y053515 for freebsd-arm@FreeBSD.org; Sun, 21 Jul 2019 21:01:22 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201907212101.x6LL1M9Y053515@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 21 Jul 2019 21:01:22 +0000 MIME-Version: 1.0 X-Rspamd-Queue-Id: 8D2976C58A X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] Content-Type: text/plain; charset="UTF-8" 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: Sun, 21 Jul 2019 21:01:24 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 1 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Sun Jul 21 21:03:01 2019 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 E761BBEE6F for ; Sun, 21 Jul 2019 21:03:01 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3A3E6CCE0 for ; Sun, 21 Jul 2019 21:03:00 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 21 Jul 2019 23:02:52 +0200 id 00F406BF.5D34D2FC.00009BDC Date: Sun, 21 Jul 2019 23:02:52 +0200 From: Milan Obuch To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org Subject: Re: Pine64 (LTS) HDMI trouble with UHD display Message-ID: <20190721230252.3622c435@zeta.dino.sk> In-Reply-To: <20190718094432.6c868b59ace49b078ce07c16@bidouilliste.com> References: <20190718091204.410aaedd@zeta.dino.sk> <20190718094432.6c868b59ace49b078ce07c16@bidouilliste.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i386-portbld-freebsd11.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E3A3E6CCE0 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk X-Spamd-Result: default: False [-5.96 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dino.sk]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mail.dino.sk]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[72.65.245.84.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; IP_SCORE(-2.67)[ip: (-7.81), ipnet: 84.245.64.0/18(-3.91), asn: 16160(-1.68), country: SK(0.06)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16160, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2] 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: Sun, 21 Jul 2019 21:03:02 -0000 On Thu, 18 Jul 2019 09:44:32 +0200 Emmanuel Vadot wrote: > On Thu, 18 Jul 2019 09:12:04 +0200 > Milan Obuch wrote: > > > Hi, > > > > as I have now basically working FreeBSD-CURRENT on Pine64-LTS, I > > decided to try a 4K monitor via HDMI. This does not work with > > strange output, to me. This is what I captured from serial console, > > trying verbose boot after escaping to loader prompt: > > > > --- captured begin --- > > > > Type '?' for a list of commands, 'help' for more detailed help. > > OK boot -vs > > Using DTB provided by EFI at 0x47ef5000. > > Loading DTB overlays: > > 'sun50i-a64-sid,sun50i-a64-ths,sun50i-a64-timer,sun50i-a64-opp,sun50i-a64-uart2' /boot/dtb/overlays/sun50i-a64-sid.dtbo > > size=0x1fd /boot/dtb/overlays/sun50i-a64-ths.dtbo size=0x3e8 > > /boot/dtb/overlays/sun50i-a64-timer.dtbo size=0x175 > > /boot/dtb/overlays/sun50i-a64-opp.dtbo size=0x74f > > /boot/dtb/overlays/sun50i-a64-uart2.dtbo size=0x123 > > applying DTB overlay '/boot/dtb/overlays/sun50i-a64-sid.dtbo' > > applying DTB overlay '/boot/dtb/overlays/sun50i-a64-ths.dtbo' > > applying DTB overlay '/boot/dtb/overlays/sun50i-a64-timer.dtbo' > > applying DTB overlay '/boot/dtb/overlays/sun50i-a64-opp.dtbo' > > applying DTB overlay '/boot/dtb/overlays/sun50i-a64-uart2.dtbo' > > EFI framebuffer information: > > addr, size 0xbe000000, 0x1fa4000 > > dimensions 3840 x 2160 > > stride 3840 > > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > EHCI failed to shut down host controller. > > panic: Too many early devmap mappings 2 > > cpuid = 0 > > time = 1 > > KDB: stack backtrace: > > #0 0xffff0000004382b4 at ??+0 > > #1 0xffff0000003f3620 at ??+0 > > #2 0xffff0000003f33d0 at ??+0 > > #3 0xffff00000074ecdc at ??+0 > > #4 0xffff0000002bb0bc at ??+0 > > #5 0xffff0000002bd580 at ??+0 > > #6 0xffff000000395f40 at ??+0 > > #7 0xffff00000070dc14 at ??+0 > > Uptime: 1s > > > > --- captured end --- [ snip ] > > Any idea on debugging this situation? It is not show stopper for me, > > other things could be checked/tested/verified, but it would be nice > > to have working 4K/UHD video output... > > > > Regards, > > Milan > > Could you try bumping PMAP_MAPDEV_EARLY_SIZE in > sys/arm64/include/pte.h to say L2_SIZE * 12 ? > I tried with this modification, but nothing changed. Backtrace is a bit different (address a moved up, numerically), but nothing else is modified. So it must be something different, or could it be still not large enough? Regards, Milan From owner-freebsd-arm@freebsd.org Mon Jul 22 07:38:53 2019 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 5EA53AA4FA for ; Mon, 22 Jul 2019 07:38:53 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.protonmail.ch", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 217818895C for ; Mon, 22 Jul 2019 07:38:53 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Mon, 22 Jul 2019 07:19:29 +0000 To: Konstantin Belousov From: Robert Crowston Cc: "freebsd-arm@freebsd.org" Reply-To: Robert Crowston Subject: Re: Raspberry Pi 4 boot hangs in sched_idletd. Message-ID: In-Reply-To: <20190721160551.GK47193@kib.kiev.ua> References: <20190721144045.GI47193@kib.kiev.ua> <8CXuLvQgIxwpLP0upt_kfzOMKpuEKBESlNEdQXWZcr6NNTFIzJn0piQPSRs0qxb7o5NMu3sRGJo7jpMvvbgWB0CjauTZoBNDt7PuqbDqNIU=@protonmail.com> <20190721160551.GK47193@kib.kiev.ua> Feedback-ID: 2OVbcR1yHYpdkD8cgQllkFwcuMVZg_LiVMMPvptooFDfHD_03MuQO4ZaF626jWHZYFEhNR2cmIbZ53j4QGWMBQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Rspamd-Queue-Id: 217818895C X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Mon, 22 Jul 2019 07:38:53 -0000 I figured it out: when I patched armstub8.bin to enable PSCI, I didn't brin= g in a #DEFINE from upstream required to enable the GIC on the cpu. With th= at done, timercb fires, the callout that boot_run_interrupt_driven_config_h= ooks() was waiting for happens, and I get as far as the mount root prompt. Next weekend I'll work on the SD card driver. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, 21 July 2019 17:05, Konstantin Belousov wr= ote: > On Sun, Jul 21, 2019 at 03:58:24PM +0000, Robert Crowston wrote: > > > > Sleeping state is terminated by wakeup which happens either by timeou= ts > > > (which indeed requires working event timers) or due to explicit wakeu= p when > > > the waiting wait channel is signalled (by wakeup(9)). > > > > I have seen threads resume through wakeup(), so I think that part is wo= rking. > > Wakeup(9) itself most likely work, otherwise you would not get to the > mount root stage of boot. What did not worked, probably, is some specific > event which occurence causes wakeup for intr_config_hook. There, only > you can inspect the state and see why it did not happen. > > > > But really you should start examining the sleep chain of the thread0 = and > > > see which exact condition it waits for. > > > > That's a helpful insight. > > > > > You did not even provided the backtrace for it. > > > > Breakpoint 8, mi_switch (flags=3D260, newtd=3D0x0) at /skeleton/root/sa= ndbox/src/sys/kern/kern_synch.c:402 > > 402 td =3D curthread; /* XXX */ > > #0 mi_switch (flags=3D260, newtd=3D0x0) at /skeleton/root/sandbox/src/s= ys/kern/kern_synch.c:402 > > #1 0xffff0000004492ac in sleepq_switch (wchan=3D0xffff00000099fba0 , pri=3D) at /skeleton/root/sandbox/src/s= ys/kern/subr_sleepqueue.c:625 > > #2 0xffff000000449920 in sleepq_timedwait (wchan=3D0xffff00000099fba0 <= intr_config_hook_list>, pri=3D0) at /skeleton/root/sandbox/src/sys/kern/sub= r_sleepqueue.c:739 > > #3 0xffff0000004006bc in _sleep (ident=3D0xffff00000099fba0 , lock=3D0xffff000000d461e0 , priority= =3D0, wmesg=3D0xffff00000080569d "conifhk", > > sbt=3D257698020000, pr=3D0, flags=3D256) at /skeleton/root/sandbox/src/= sys/kern/kern_synch.c:213 > > #4 0xffff00000042576c in boot_run_interrupt_driven_config_hooks (dummy= =3D) at /skeleton/root/sandbox/src/sys/kern/subr_autoconf.c:= 162 > > #5 0xffff0000003908a8 in mi_startup () at /skeleton/root/sandbox/src/sy= s/kern/init_main.c:314 > > #6 0xffff000000001088 in virtdone () at /skeleton/root/sandbox/src/sys/= arm64/arm64/locore.S:142 > > Backtrace stopped: previous frame identical to this frame (corrupt stac= k?) > > The final time I see we are on thread0, we are running boot_run_interru= pt_driven_config_hooks, which looks like it has a sixty second delay. It's = not the first or the last sleepq_timedwait in the boot, but it's probably t= he longest. I'll dig into the event timer side and try to figure out what i= nterrupts its expecting. > > It is almost certainly not the eventtimers issue. From owner-freebsd-arm@freebsd.org Mon Jul 22 08:07:54 2019 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 DBC88AB258 for ; Mon, 22 Jul 2019 08:07:54 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4A6F89B6E for ; Mon, 22 Jul 2019 08:07:53 +0000 (UTC) (envelope-from dave@dogwood.com) Received: by mail-oi1-x244.google.com with SMTP id t76so28966142oih.4 for ; Mon, 22 Jul 2019 01:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dogwood.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DHEFFhr4FL0tSFdJWCFmYqU+9liMRDZz357HscXh9lk=; b=X8l+dLvLpagSfLKd5iC6iWUyQLzxPjT/HZvSW2ioUA4WV6yLHO1HdSo4BWyZ88fjsk 6XD8BRYvnOeuEQNIHaHhQJ1VPpxEb+ZF7+z7pAmhcAwl1w9fpUk+iAvJcDuWOLCaV+Yd n/3wJN7sC16rjh/o8ZxOaXhypQEv3rhCro/nI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DHEFFhr4FL0tSFdJWCFmYqU+9liMRDZz357HscXh9lk=; b=mFZ+TfW1krxQokLDLxq8qKro1vYNLIjelosfaLSsaYg87iIMrwjraL0LAAIzIeAN7B lwBpEddENcN+GuGuntuWIfcfj3h1hLR7294y/jEelsTCoR9FbKYlu1CW0AvL2nVZ/RvO +6X8sQMZabgsALj0wJDAVXPC5+c40NUPqui3s/kyBOssvkoHP7t0jc0xKLzy4UYCPQvX rvNCjDXsozuyk2GhRv57gvPARdTvbswP/uPOdJOMwzjb4HpsiEuzAAgtPaWapwhWNO6u LAu0lsSEbNu/p9r/Oz19SaDGN5Xeurc2eyHafneLKcaZ/ICjbXAYcfnfG1vu/aMe2DBl 3qPA== X-Gm-Message-State: APjAAAXHiRhJX6MRwCjNc6ZivgNaQqtzUaC7ylSLTd8yO6+G7qGE4jzK cFUYuZKbFrvLRPoRGZ2JIV4ksEgseCteHsqiDWOXEw== X-Google-Smtp-Source: APXvYqxLSTzUD0aGnVUAi6ACYF9QL7FtvHl/QH71R3HgSTWFshd4RNt9p0AUaj7alPcbOJclRrW4eZTZEfx0PiNe+kE= X-Received: by 2002:aca:5e88:: with SMTP id s130mr34714585oib.91.1563782872516; Mon, 22 Jul 2019 01:07:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Cornejo Date: Sun, 21 Jul 2019 22:07:41 -1000 Message-ID: Subject: Re: Raspberry Pi 4 boot hangs in sched_idletd. To: Robert Crowston Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B4A6F89B6E X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dogwood.com header.s=google header.b=X8l+dLvL; spf=pass (mx1.freebsd.org: domain of dave@dogwood.com designates 2607:f8b0:4864:20::244 as permitted sender) smtp.mailfrom=dave@dogwood.com X-Spamd-Result: default: False [-3.67 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[dogwood.com:s=google]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[dogwood.com]; NEURAL_HAM_SHORT(-0.49)[-0.495,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dogwood.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx5.googlemail.com,aspmx4.googlemail.com,aspmx3.googlemail.com,alt2.aspmx.l.google.com,aspmx2.googlemail.com]; IP_SCORE(-0.67)[ip: (2.22), ipnet: 2607:f8b0::/32(-3.11), asn: 15169(-2.42), country: US(-0.05)]; FREEMAIL_TO(0.00)[protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] 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: Mon, 22 Jul 2019 08:07:54 -0000 Is there some sort of guide or instructions for using a JTAG debugger on the FreeBSD kernel available somewhere? thanks, dave c On Sun, Jul 21, 2019 at 4:14 AM Robert Crowston via freebsd-arm wrote: > > I need a bit of a hand with this. I've been working on getting FreeBSD 13= .0-Current up and running on my pi4. I'm using the GENERIC configuration fo= r now. I have a JTAG hardware debugger so I've got a pretty good introspect= ion on what's going on at the detail level, but I'm missing some of the big= ger picture. > > The first problem is, this board has two interrupt controllers on the FDT= ; the bcm2836-l1-intc local interrupt controller (local_intc) that was pres= ent on the RPi3, and also a new gic400. Both the drivers call intr_pic_clai= m_root(), which causes a panic. If I remove the gic400 from the FDT, very l= ittle of the hardware enumeration succeeds and the kernel panics because th= ere is no event timer. If I remove the local_intc, a few devices, including= the BCM2835 DMA controller, the SD card controllers, and the GPIO drivers = fail to start, but the rest of the hardware enumeration finishes. I don't k= now enough about the hardware topology to figure out which one is the real = root and fix the drivers accordingly. > > So, without local_intc, we get another problem. Late in the boot sequence= , the idle thread gets swapped in, and there are still threads on the sleep= queue, including thread0, but no other threads get put on the run queue, a= nd the Pi loops through sched_idletd thread forever instead of finishing th= e boot. > > By poking things in the debugger I can progress as far as vfs_mountroot_w= ait(), and I think there is a race condition because the behaviour is diffe= rent if I step through manually without changing anything, but whatever hap= pens, eventually I end up stuck in the sched_idletd loop. > > I think perhaps event timer interrupts are not being delivered so the sle= ep queue never gets moved to the run queue?, but I'm guessing here. > > More detail: > > So far I'm in mi_startup(), and about ~1150 out of ~1200 SYSINIT tasks ar= e done. Eventually we get to initialize the usbus. One of its worker thread= s calls _sleep(): > > Breakpoint 6, _sleep (ident=3D0xffff000000c5eb28 , lock=3D0x= 0, priority=3D0, > wmesg=3D0xffff000000775d55 "USBWAIT", sbt=3D47244637, pr=3D0, flags= =3D256) > at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:139 > 139 td =3D curthread; > (gdb) bt > #0 _sleep (ident=3D0xffff000000c5eb28 , lock=3D0x0, priorit= y=3D0, > wmesg=3D0xffff000000775d55 "USBWAIT", sbt=3D47244637, pr=3D0, flags= =3D256) > at /skeleton/root/sandbox/src/sys/kern/kern_synch.c:139 > #1 0xffff00000029db08 in usbd_req_set_address (udev=3D0xfffffd0000d23000= , mtx=3D0x0, > addr=3D) at /skeleton/root/sandbox/src/sys/dev/usb/usb= _request.c:1580 > #2 0xffff00000028d05c in usb_alloc_device (parent_dev=3D,= bus=3D0xffff0000405fe000, > parent_hub=3D0x0, depth=3D, port_index=3D, port_no=3D, > speed=3DUSB_SPEED_HIGH, mode=3D) > at /skeleton/root/sandbox/src/sys/dev/usb/usb_device.c:1824 > #3 0xffff000000281524 in usb_bus_attach (pm=3D) > at /skeleton/root/sandbox/src/sys/dev/usb/controller/usb_controller.c= :767 > #4 0xffff00000029b750 in usb_process (arg=3D0xffff0000405fe130) > at /skeleton/root/sandbox/src/sys/dev/usb/usb_process.c:178 > #5 0xffff0000003b78c0 in fork_exit (callout=3D0xffff00000029b65c , > arg=3D0xffff0000405fe130, frame=3D0xffff00004024cba0) > at /skeleton/root/sandbox/src/sys/kern/kern_fork.c:1056 > #6 0xffff00000071fe88 in fork_trampoline () > at /skeleton/root/sandbox/src/sys/arm64/arm64/swtch.S:214 > > _sleep() swaps the usb_process thread off the CPU. If I step through, ano= ther few threads are put on the CPU, including taskqueue_thread_loop, soaio= _kproc_loop, random_kthread. Sometimes I also see the interrupt event threa= d, but not always. Sometimes if I step, I'll find thread0 does get back on = the CPU, in which case we can progress as far as release_aps(), but then th= e other CPUs get stuck in sched_idletd and eventually CPU0 will hang in smp= _rendezvous() waiting for the other CPUs. > > Does anyone have any ideas what I should investigate next? > > Boot log attached. > > > _______________________________________________ > 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" --=20 Kailua, Hawai=CA=BBi US +1 (808) 728-3050 UK +44 (020) 3286 2808 From owner-freebsd-arm@freebsd.org Mon Jul 22 08:27:02 2019 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 357DEAB787 for ; Mon, 22 Jul 2019 08:27:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 17FB68A61A for ; Mon, 22 Jul 2019 08:27:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.nyi.freebsd.org (Postfix) id 159ACAB783; Mon, 22 Jul 2019 08:27:02 +0000 (UTC) Delivered-To: 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 155D9AB782 for ; Mon, 22 Jul 2019 08:27:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B9D978A618; Mon, 22 Jul 2019 08:27:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id c391ec9f; Mon, 22 Jul 2019 10:26:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=lu8muJBP5iyx7GeQgATZ+5P4eNc=; b=oXlCKbAXdnEG9A5vHTMYOObcsK6H YqOKu2Kwp3LONcldidBzBvSrjQC5ymKWWxle1j5K8TiDGUZHcLhqjFA3gHZ7RPJc YRMvDxzpVS/oCR03e2k8UAPmoDYDZGnvtM2GvJrNZ9TFowtnV/sZsephSqAl8tdL HGSLL5TDM6ZTmKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=dq1fv0PG+lYtMRpm3mL9LoruDGgrLm39yXFqCpzhkADSSy1Mi/xnl+qn E8AcJDdYEHsDhnczN4psfDw0UnqcRxxgRajUV2vP3sJdSQClRT6+Zko+e8im2qoX M2+y7BOvz2LOqgayo6RozyixLgKhbWUU5ffYIFpH0h3QqCI18vM= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 683d50e1 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 22 Jul 2019 10:26:52 +0200 (CEST) Date: Mon, 22 Jul 2019 10:26:52 +0200 From: Emmanuel Vadot To: John-Mark Gurney Cc: Ian Lepore , arm@FreeBSD.org Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-Id: <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> In-Reply-To: <20190721205557.GR2342@funkthat.com> References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 17FB68A61A X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Mon, 22 Jul 2019 08:27:02 -0000 On Sun, 21 Jul 2019 13:55:57 -0700 John-Mark Gurney wrote: > Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600: > > On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote: > > > The microSD card that I was using on my BeagleBone white got > > > corrupted, > > > so I decided to update to the latest version. The latest snapshot > > > fails > > > to boot. It loads the kernel, but then when starting the kernel, it > > > hangs, and eventually it will reset. > > > > > > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. > > > > > > Any ideas? I tried all three available 13 snaps, and they all behave > > > the same. > > > > > > > This happened with the latest DTS import (which was months ago). A > > couple people have speculated that we just need a trivial do-nothing > > driver for the new ti,sysc device, but when I tried that a couple > > months ago it didn't work, so instead I just reverted sys/dts to the > > old source and got on with what I needed to do. > > Can we revert the dts in the tree then? Doesn't help when we know > the fix, but don't apply it... That would be a pain for the next updates. > Or add an overlay that undoes the changes? > > I can do some testing... Could be possible but that will probably break in a few updates of the DTS files. We need a TI maintainer that's all. > > This is just the latest in a years-long string of breakages because the > > linux TI folks just never stop tinkering with their device-tree source. > > I'm sure they're doing it because it gets them some benefits, but for > > us the changes add no value and have a high maintenance cost. A hang > > before the copyright banner appears is especially painful to debug > > (doubly so because there's no existing EARLY_PRINTF support in the ti > > code). > > [...] > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Jul 22 16:12:06 2019 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 AC61FB4FCD for ; Mon, 22 Jul 2019 16:12:06 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93F9575F80 for ; Mon, 22 Jul 2019 16:12:05 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Mon, 22 Jul 2019 18:12:02 +0200 id 00F4068B.5D35E052.00013132 Date: Mon, 22 Jul 2019 18:12:02 +0200 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Zybo Z7 board running FreeBSD success Message-ID: <20190722181202.5d69411e@zeta.dino.sk> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i386-portbld-freebsd11.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 93F9575F80 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk X-Spamd-Result: default: False [-5.86 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[cached: mail.dino.sk]; NEURAL_HAM_SHORT(-0.81)[-0.811,0]; RCVD_IN_DNSWL_NONE(0.00)[72.65.245.84.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.74)[ip: (-7.95), ipnet: 84.245.64.0/18(-3.98), asn: 16160(-1.85), country: SK(0.06)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16160, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2] 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: Mon, 22 Jul 2019 16:12:06 -0000 Hi, page at http://www.skibo.net/zedbsd/ lists Zybo can run FreeBSD, but image provided does not work on Zybo Z7 I have. After some struggles I found a way to do it. My work is based on image provided there and, with some help from Thomas Skibo, I was able to run it on my board. There was two troubles caused by some differences of the boards, main one being different clock speed. I've got DTS from Thomas, which should work on Z7, but it was not enough. It turned out u-boot need to be built specifically for Z7 vs. original Zybo. Fortunatelly, we have sysutils/u-boot-zybo port in our tree and it was easy to modify it for Z7. Basically, rewrite Makefile zybo -> zybo-z7 and using 2019.01 u-boot sources. Detail on freebsd-uboot mailing list. For some reason, not yet known, I must set verbose boot to overcome panic from kernel at start. See serial console output in that case: Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-RELEASE r341741 ZEDBOARD arm FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) CPU: ARM Cortex-A9 r3p0 (ECO: 0x00000000) CPU Features: Multiprocessing, Thumb2, Security, VMSAv7, Coherent Walk Optional instructions: UMULL, SMULL, SIMD(ext) LoUU:2 LoC:2 LoUIS:2 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Alloc real memory = 0 (0 MB) avail memory = 1039699968 (991 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random: unblocking device. random: entropy device external interface ofwbus0: simplebus0: on ofwbus0 simplebus1: on ofwbus0 l2cache0: mem 0xf02000-0xf02fff irq 0 on simplebus0 l2cache0: cannot allocate IRQ, not using interrupt l2cache0: Part number: 0x3, release: 0x8 l2cache0: L2 Cache enabled: 512KB/32B 8 ways gic0: mem 0xf01000-0xf01fff,0xf00100-0xf001ff on simplebus0 gic0: pn 0x39, arch 0x1, rev 0x2, implementer 0x43b irqs 96 mp_tmr0: mem 0xf00200-0xf002ff,0xf00600-0xf0061f irq 2,3 on simplebus0 Timecounter "MPCore" frequency 333333333 Hz quality 800 Event timer "MPCore" frequency 333333333 Hz quality 1000 zy7_slcr0: mem 0-0xfff on simplebus0 zy7_devcfg0: mem 0x7000-0x7fff irq 1 on simplebus0 uart0: mem 0x1000-0x1fff irq 7 on simplebus1 uart0: console (-1,n,8,1) ehci0: mem 0x2000-0x2fff irq 8 on simplebus1 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0 on ehci0 gpio0: mem 0xa000-0xafff irq 10 on simplebus1 gpiobus0: on gpio0 gpioc0: on gpio0 cgem0: mem 0xb000-0xbfff irq 11 on simplebus1 miibus0: on cgem0 rgephy0: PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto rgephy1: PHY 1 on miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto cgem0: Ethernet address: 00:18:3e:02:c1:3c sdhci_fdt0: mem 0x100000-0x100fff irq 14 on simplebus1 sdhci_fdt0: 1 slot(s) allocated mmc0: on sdhci_fdt0 cryptosoft0: Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 mmcsd0: 16GB at mmc0 25.0MHz/4bit/65535-block vm_thread_new: kstack allocation failed panic: kproc_start: bufdaemon: error 12 cpuid = 0 time = 1 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort No idea what's wrong, and why verbose boot 'fixes' (or maybe better just works around this) a problem. Any hint? Note: real memory being 0 MB is surely an error, but it shows this way when booting verbose too. Also our wiki at https://wiki.freebsd.org/FreeBSD/arm/Zedboard should be updated, it lists Thomas' page has 11-RELEASE images, while in reality it is 12.0-RELEASE. For now, what works for me: - serial console, of course - ethernet port (I can ssh into and from Zybo Z7) - USB port (flash disk partitions shown with gpart, could be mounted) - SD card, booted from it - gpio should work, at least gpioctl -lv spits a lot lines :) Currently, nothing else seen. I plan to investigate FPGA possibilities, too, but that's basically FreeBSD unrelated. Regards, Milan From owner-freebsd-arm@freebsd.org Mon Jul 22 17:12:59 2019 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 6D563B6763 for ; Mon, 22 Jul 2019 17:12:59 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 39AB7805A4 for ; Mon, 22 Jul 2019 17:12:59 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.nyi.freebsd.org (Postfix) id 374DCB6762; Mon, 22 Jul 2019 17:12:59 +0000 (UTC) Delivered-To: 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 36F3AB6761 for ; Mon, 22 Jul 2019 17:12:59 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 928AB805A3; Mon, 22 Jul 2019 17:12:56 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id x6MHCqv0047373 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jul 2019 10:12:52 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id x6MHCpKh047372; Mon, 22 Jul 2019 10:12:51 -0700 (PDT) (envelope-from jmg) Date: Mon, 22 Jul 2019 10:12:51 -0700 From: John-Mark Gurney To: Emmanuel Vadot Cc: Ian Lepore , arm@FreeBSD.org Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-ID: <20190722171251.GU2342@funkthat.com> Mail-Followup-To: Emmanuel Vadot , Ian Lepore , arm@FreeBSD.org References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 22 Jul 2019 10:12:52 -0700 (PDT) X-Rspamd-Queue-Id: 928AB805A3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of jmg@gold.funkthat.com designates 208.87.223.18 as permitted sender) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-3.09 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[funkthat.com]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: gold.funkthat.com]; NEURAL_HAM_SHORT(-0.49)[-0.491,0]; IP_SCORE(-0.59)[ip: (-1.53), ipnet: 208.87.216.0/21(-0.77), asn: 32354(-0.61), country: US(-0.05)]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MID_RHS_MATCH_FROM(0.00)[] 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: Mon, 22 Jul 2019 17:12:59 -0000 Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200: > On Sun, 21 Jul 2019 13:55:57 -0700 > John-Mark Gurney wrote: > > > Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600: > > > On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote: > > > > The microSD card that I was using on my BeagleBone white got > > > > corrupted, > > > > so I decided to update to the latest version. The latest snapshot > > > > fails > > > > to boot. It loads the kernel, but then when starting the kernel, it > > > > hangs, and eventually it will reset. > > > > > > > > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. > > > > > > > > Any ideas? I tried all three available 13 snaps, and they all behave > > > > the same. > > > > > > > > > > This happened with the latest DTS import (which was months ago). A > > > couple people have speculated that we just need a trivial do-nothing > > > driver for the new ti,sysc device, but when I tried that a couple > > > months ago it didn't work, so instead I just reverted sys/dts to the > > > old source and got on with what I needed to do. > > > > Can we revert the dts in the tree then? Doesn't help when we know > > the fix, but don't apply it... > > That would be a pain for the next updates. Well, IMO, better than leaving a platform broken for months... > > Or add an overlay that undoes the changes? > > > > I can do some testing... > > Could be possible but that will probably break in a few updates of the > DTS files. > > We need a TI maintainer that's all. I'd recommend we disconnect the builds then or something so that people know not even to bother to try the images instead of wasting hours of time trying to figure out what's wrong w/ the images... At least then I'd post where's the images, and you would have replied that things aren't working... > > > This is just the latest in a years-long string of breakages because the > > > linux TI folks just never stop tinkering with their device-tree source. > > > I'm sure they're doing it because it gets them some benefits, but for > > > us the changes add no value and have a high maintenance cost. A hang > > > before the copyright banner appears is especially painful to debug > > > (doubly so because there's no existing EARLY_PRINTF support in the ti > > > code). > > > > [...] -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Mon Jul 22 22:21:20 2019 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 3E7D8BDEA6 for ; Mon, 22 Jul 2019 22:21:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9DBD18E3DA for ; Mon, 22 Jul 2019 22:21:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.nyi.freebsd.org (Postfix) id 9D53BBDEA5; Mon, 22 Jul 2019 22:21:19 +0000 (UTC) Delivered-To: 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 9D16DBDEA4 for ; Mon, 22 Jul 2019 22:21:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FBC28E3D9; Mon, 22 Jul 2019 22:21:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 4968ef29; Tue, 23 Jul 2019 00:21:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=LCgDm6MXL6rsp59Ytl2PPQ2DcSE=; b=VohDdHbV4YQXC0ZpOA/YHpXgl4ZH O+uf7xf2eQToe6o9rBYlc4HADRhvrVkw28Ki/w0TmXEz07Oh8qEhIEp8vCrp8fM6 DO/Nrc5YmBHj4I25AYznaGR70W9fR4Pp1Nn5lKth47g4/t9pYPP/By+1OTNuzCCa h5NWe1nRluGadmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=BXNlGrGm/+Ji2AVqLLQDAwo8mtJgDoRPeNu3QhdiyjlLzILywQCeZwq1 ZeiwfpGb1twAg6ZpGY8XbhCUnxV8A4n3xy8TY+CrX6AOobojScuz+zBGg9Drb7Gr s8HEyB3CjsFE7HraLnkc2TfOUqvCPqTL9Jidas4vx3FZ3jCzD7Y= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e202dafc TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 23 Jul 2019 00:21:16 +0200 (CEST) Date: Tue, 23 Jul 2019 00:21:16 +0200 From: Emmanuel Vadot To: John-Mark Gurney Cc: Ian Lepore , arm@FreeBSD.org Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-Id: <20190723002116.75493451127739cf50b4077d@bidouilliste.com> In-Reply-To: <20190722171251.GU2342@funkthat.com> References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> <20190722171251.GU2342@funkthat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4FBC28E3D9 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Mon, 22 Jul 2019 22:21:20 -0000 On Mon, 22 Jul 2019 10:12:51 -0700 John-Mark Gurney wrote: > Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200: > > On Sun, 21 Jul 2019 13:55:57 -0700 > > John-Mark Gurney wrote: > > > > > Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600: > > > > On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote: > > > > > The microSD card that I was using on my BeagleBone white got > > > > > corrupted, > > > > > so I decided to update to the latest version. The latest snapshot > > > > > fails > > > > > to boot. It loads the kernel, but then when starting the kernel, it > > > > > hangs, and eventually it will reset. > > > > > > > > > > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. > > > > > > > > > > Any ideas? I tried all three available 13 snaps, and they all behave > > > > > the same. > > > > > > > > > > > > > This happened with the latest DTS import (which was months ago). A > > > > couple people have speculated that we just need a trivial do-nothing > > > > driver for the new ti,sysc device, but when I tried that a couple > > > > months ago it didn't work, so instead I just reverted sys/dts to the > > > > old source and got on with what I needed to do. > > > > > > Can we revert the dts in the tree then? Doesn't help when we know > > > the fix, but don't apply it... > > > > That would be a pain for the next updates. > > Well, IMO, better than leaving a platform broken for months... > > > > Or add an overlay that undoes the changes? > > > > > > I can do some testing... > > > > Could be possible but that will probably break in a few updates of the > > DTS files. > > > > We need a TI maintainer that's all. > > I'd recommend we disconnect the builds then or something so that people > know not even to bother to try the images instead of wasting hours of > time trying to figure out what's wrong w/ the images... > > At least then I'd post where's the images, and you would have replied > that things aren't working... > > > > > This is just the latest in a years-long string of breakages because the > > > > linux TI folks just never stop tinkering with their device-tree source. > > > > I'm sure they're doing it because it gets them some benefits, but for > > > > us the changes add no value and have a high maintenance cost. A hang > > > > before the copyright banner appears is especially painful to debug > > > > (doubly so because there's no existing EARLY_PRINTF support in the ti > > > > code). > > > > > > [...] > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." So I've unbroken the BBB. I've made two commits : r350229 ([1]) changes the hwmod driver to lookup the property in the parent node as the dts changed that. r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simplebus like bus and for now we only threat it like if it was. But this is not enough to boot on BBB for now with the latest DTS. I've put on a github branch ([3]) two other commits. The first one correct the region of uart0 which isn't correct, I guess linux doesn't care about this as much as we do. Since this patches the DTS I want to start the process of upstreaming first before commiting this patch into our tree. I also want to update the DTS to Linux 5.2 since I want to merge those for 12.1 . The second one take care of a problem in ofw_reg_to_paddr. Since we have now a lot of region in the ti.sysc drivers, using only 32 pcells for the regions isn't enough. I've temporary bumped this value to 64 which is enough for booting on the BBB but we need a cleaner solution. I'll look into it soon-ish. So right now if you want to run current on BBB please take update you source tree and take the two patches from my github branch. Note that I think that this is the last time that I fix TI related problems in the tree. I've spent too much time fixing BBB and Pandaboard during the last 12 months and I don't even use or care about those boards. If someone wants to keep them alive please invest time or money into this. Thanks to ian@ for helping me with this issue. [1] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=350229&view=markup [2] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=350230&view=markup [3] : https://github.com/evadot/freebsd/tree/bbb -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Jul 22 23:38:17 2019 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 241A7BF301 for ; Mon, 22 Jul 2019 23:38:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 069B96A46B for ; Mon, 22 Jul 2019 23:38:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D42A21CC93 for ; Mon, 22 Jul 2019 23:38:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x6MNcGWR011756 for ; Mon, 22 Jul 2019 23:38:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6MNcG3R011755 for freebsd-arm@FreeBSD.org; Mon, 22 Jul 2019 23:38:16 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 239390] Enable UART ports on Pine64-LTS platform Date: Mon, 22 Jul 2019 23:38:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kayasaman@optiplex-networks.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 069B96A46B X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.985,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] 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: Mon, 22 Jul 2019 23:38:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239390 Bug ID: 239390 Summary: Enable UART ports on Pine64-LTS platform Product: Base System Version: 12.0-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: kayasaman@optiplex-networks.com Hi, I am trying to enable the UART ports on my Pine64-LTS board however, af= ter trying all the suggestions that people gave in the Arm mailing list nothing= had any effect. The suggestions given to me were to use overlays. I attempted this but get error messages: failed to apply overlay: FDT_ERR_NOTFOUND The files do exist: ls /boot/msdos/dtb/overlays sun50i-a64-sid.dtbo sun50i-a64-timer.dtbo sun50i-a64-uart4.dtbo sun50i-a64-ths.dtbo sun50i-a64-uart2.dtbo ls /boot/dtb/overlays sun50i-a64-sid.dtbo sun50i-a64-timer.dtbo sun50i-a64-uart4.dtbo sun50i-a64-ths.dtbo sun50i-a64-uart2.dtbo Additionally I have tried to add the following directly to the .dts files: /* On Pi-2 connector */ &uart2 { pinctrl-names =3D "default"; pinctrl-0 =3D <&uart2_pins>; status =3D "okay"; }; The files I have tried to enable the UART ports in are these: /usr/src/sys/gnu/dts/arm64/allwinner - sun50i-a64-pine64.dts sun50i-a64-sopine-baseboard.dts Unfortunately nothing is working and there isn't a direct pin64-lts.dts file either. What more information could I provide here in order to get the UART's to function? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Jul 23 12:26:09 2019 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 ADFE0A8ADC for ; Tue, 23 Jul 2019 12:26:09 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 172D28E895 for ; Tue, 23 Jul 2019 12:26:09 +0000 (UTC) (envelope-from rj@obsigna.com) Received: by mailman.nyi.freebsd.org (Postfix) id 14F3AA8ADB; Tue, 23 Jul 2019 12:26:09 +0000 (UTC) Delivered-To: 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 14B08A8ADA for ; Tue, 23 Jul 2019 12:26:09 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from projectstore.net (ec2-18-228-164-192.sa-east-1.compute.amazonaws.com [18.228.164.192]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D79538E894; Tue, 23 Jul 2019 12:26:08 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [179.212.183.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by projectstore.net (Postfix) with ESMTPSA id C61CB1E11CD; Tue, 23 Jul 2019 09:22:31 -0300 (-03) Received: from rolf-mini.obsigna.com (rolf-mini.obsigna.com [192.168.222.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id DECB51350FAA4; Tue, 23 Jul 2019 09:22:25 -0300 (-03) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White From: "Dr. Rolf Jansen" In-Reply-To: <20190723002116.75493451127739cf50b4077d@bidouilliste.com> Date: Tue, 23 Jul 2019 09:22:25 -0300 Cc: Emmanuel Vadot , John-Mark Gurney , Ian Lepore Content-Transfer-Encoding: quoted-printable Message-Id: <4261EECC-29D1-4CD3-A585-8A8606BA2A2E@obsigna.com> References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> <20190722171251.GU2342@funkthat.com> <20190723002116.75493451127739cf50b4077d@bidouilliste.com> To: arm@FreeBSD.org X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: D79538E894 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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: Tue, 23 Jul 2019 12:26:09 -0000 > Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot : >=20 > ... >=20 > Note that I think that this is the last time that I fix TI related = problems > in the tree. I've spent too much time fixing BBB and Pandaboard during = the > last 12 months and I don't even use or care about those boards. If = someone > wants to keep them alive please invest time or money into this. You can have this quite easily. Simply revert your non-revisited batch = import of 3126 files of the Linux DTS tree to the previous state = (https://svnweb.freebsd.org/base?view=3Drevision&revision=3D347366) Then let others import what they need file by file or snippet by = snippet. By this you would be guaranteed to never be bothered agin with = any BeagleBone. Best regards Rolf From owner-freebsd-arm@freebsd.org Tue Jul 23 16:15:27 2019 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 2E675AD5A0 for ; Tue, 23 Jul 2019 16:15:27 +0000 (UTC) (envelope-from oskar.holmlund@yahoo.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 0F95E97CAB for ; Tue, 23 Jul 2019 16:15:27 +0000 (UTC) (envelope-from oskar.holmlund@yahoo.com) Received: by mailman.nyi.freebsd.org (Postfix) id 0EC2AAD59F; Tue, 23 Jul 2019 16:15:27 +0000 (UTC) Delivered-To: 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 0E670AD59E for ; Tue, 23 Jul 2019 16:15:27 +0000 (UTC) (envelope-from oskar.holmlund@yahoo.com) Received: from sonic302-20.consmr.mail.ir2.yahoo.com (sonic302-20.consmr.mail.ir2.yahoo.com [87.248.110.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB0AE97CA9 for ; Tue, 23 Jul 2019 16:15:26 +0000 (UTC) (envelope-from oskar.holmlund@yahoo.com) X-YMail-OSG: mNRAe8MVM1kIIbLYsNQhl4fKEvnbr30Xxoc7pFW1zDqV5d6epLIbWRLQIs7V9gZ 5NeIl_9.myJ6gjtfYcmrWmDZ8kuRV3HwNQyNefLhAiijDBE1cJ3eqIYXvoefl0Pt1pNzstbWmqTw h6DMqEltK41cOew8ZgFE.ugaMaO8.0tIgJxrVe5.VwKE_EcV2UgqecwJqNwxFXBNII0pExxMFQTz zIgm2Al5zqpsDnq91BEYGfhlE17Je3LX_9.AKVCdp.2gYABqq2L_MKjaybkE17ADSceNCUeDHglP q9aHV7VtUeofFY4.D3J4lwraY1rf8ievuks6pQjd9irdQfRCgwkMKEGrUWPXHyFaHSG1QlVCMLqI WQ5zlJcruLDEdA00Sr2auRMA_Tyu6nos2SawI3AKgCp_eVyveuBXgdrmlE7QjjjCzz1JxvWgOqqH 4kwYRDLfYs5W_m1WPvM1lO.u7QutitjIHVC_wWtp9yahrMo3pWlOE7pdlv2uQD4RZpdi6SPOa7ws 7dzun.ZcJszkAlKMXSCVwd0lO5Yr_z1mi8DYyzN4AYQuJVkNMaNfh9lgxIFAHuOvAjwRrKAmRW_l 6gC5lN60TJQg.Mek74xn15XdkYBxd4Q8kbj4._OtKrj5NoBTCL5SCMyQdTE0EW4ZPJ.tk0L1mr.. 1qYP4X7Fyo8MetaTHbVDHxPLYHhnOnvnOgqabnLY05R0paq.hMzon6amZvgFIDfU7RlG1NXBV5DW PVWtlwUXwnrOSVfvQLaV_qxX7Wb_6jtavGY2aGm5iMLAWanptmW6yfw8iIto9EHTXji6yZiMUMt0 TgWh.54jupcGFSnp2HJ1pd8KQ23lAW5Hgp8NxBYr.mOiUntrmr7SFNB2qEblzuPNf6Lt5NIPQ_Bw FSbZTNWUHheel7SiZcf4SZtrbYvK0TTwrqjOM_pTNov_Bvs1R4tp1HGtsbdJSms8Y3yS7z2I1t9A NBkb3inWm4hhXUPcxWjh.s8LDuiqNzdLfMW5WFdBYcZqeT.XxrEhFDITs4ZgLozaDWMyfIf1lIap jloyJ43Z6MfDT9.OyrVW2htGcLe.E7g.nfoRS641tTncWs9STzZafZ3EGdG3GwNzbjLwyKdPg3oe tYv8.TbTQ2EZ.8uvlVAfLsNK37.p8_JpDXErioKhxWQJOy8A2XHcv7pyi3pL_1HayqGX5gTinbfn P26m3trKfllTgm4lDwSY47ZsovZY844tn3DU7FoFF21OHCak98iVWjiFOyrERJw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ir2.yahoo.com with HTTP; Tue, 23 Jul 2019 16:15:24 +0000 Date: Tue, 23 Jul 2019 16:15:21 +0000 (UTC) From: Oskar Holmlund To: John-Mark Gurney , Emmanuel Vadot Cc: arm@FreeBSD.org, Ian Lepore Message-ID: <1962999297.7816997.1563898521984@mail.yahoo.com> In-Reply-To: <20190723002116.75493451127739cf50b4077d@bidouilliste.com> References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> <20190722171251.GU2342@funkthat.com> <20190723002116.75493451127739cf50b4077d@bidouilliste.com> Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0 X-Rspamd-Queue-Id: 0F95E97CAB X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Tue, 23 Jul 2019 16:15:27 -0000 2019-07-23 00:21 skrev Emmanuel Vadot: > On Mon, 22 Jul 2019 10:12:51 -0700 > John-Mark Gurney wrote: >=20 >> Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200: >> > On Sun, 21 Jul 2019 13:55:57 -0700 >> > John-Mark Gurney wrote: >> > >> > > Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600: >> > > > On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote: >> > > > > The microSD card that I was using on my BeagleBone white got >> > > > > corrupted, >> > > > > so I decided to update to the latest version.=C2=A0 The latest s= napshot >> > > > > fails >> > > > > to boot.=C2=A0 It loads the kernel, but then when starting the k= ernel, it >> > > > > hangs, and eventually it will reset. >> > > > > >> > > > > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. >> > > > > >> > > > > Any ideas?=C2=A0 I tried all three available 13 snaps, and they = all behave >> > > > > the same. >> > > > > >> > > > >> > > > This happened with the latest DTS import (which was months ago).= =C2=A0 A >> > > > couple people have speculated that we just need a trivial do-nothi= ng >> > > > driver for the new ti,sysc device, but when I tried that a couple >> > > > months ago it didn't work, so instead I just reverted sys/dts to t= he >> > > > old source and got on with what I needed to do. >> > > >> > > Can we revert the dts in the tree then?=C2=A0 Doesn't help when we k= now >> > > the fix, but don't apply it... >> > >> >=C2=A0 That would be a pain for the next updates. >> >> Well, IMO, better than leaving a platform broken for months... >> >> > > Or add an overlay that undoes the changes? >> > > >> > > I can do some testing... >> > >> >=C2=A0 Could be possible but that will probably break in a few updates = of the >> > DTS files. >> > >> >=C2=A0 We need a TI maintainer that's all. >> >> I'd recommend we disconnect the builds then or something so that people >> know not even to bother to try the images instead of wasting hours of >> time trying to figure out what's wrong w/ the images... >> >> At least then I'd post where's the images, and you would have replied >> that things aren't working... >> >> > > > This is just the latest in a years-long string of breakages becaus= e the >> > > > linux TI folks just never stop tinkering with their device-tree so= urce. >> > > > I'm sure they're doing it because it gets them some benefits, but = for >> > > > us the changes add no value and have a high maintenance cost.=C2= =A0 A hang >> > > > before the copyright banner appears is especially painful to debug >> > > > (doubly so because there's no existing EARLY_PRINTF support in the= ti >> > > > code). >> > > >> > > [...] >> >> -- >>=C2=A0=C2=A0 John-Mark Gurney=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0Voice: +1 415 225 5579 >> >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "All that I will do, has been done, All th= at I have, has not." >=20 >=C2=A0 So I've unbroken the BBB. >=20 I appreciate your work, thank you! >=C2=A0 I've made two commits : >=C2=A0 r350229 ([1]) changes the hwmod driver to lookup the property in th= e > parent node as the dts changed that. >=C2=A0 r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simpleb= us > like bus and for now we only threat it like if it was. >=20 >=C2=A0 But this is not enough to boot on BBB for now with the latest DTS. >=C2=A0 I've put on a github branch ([3]) two other commits. >=20 >=C2=A0 The first one correct the region of uart0 which isn't correct, I gu= ess linux >=C2=A0 doesn't care about this as much as we do. Since this patches the DT= S I want >=C2=A0 to start the process of upstreaming first before commiting this pat= ch into >=C2=A0 our tree. I also want to update the DTS to Linux 5.2 since I want t= o merge >=C2=A0 those for 12.1 . Is there any strategy for device tree imports from Linux? In the upcoming 13 i dont mind running the latest and greatest. But in 11.x= / 12.x?=20 >=C2=A0 The second one take care of a problem in ofw_reg_to_paddr. Since we= have now >=C2=A0 a lot of region in the ti.sysc drivers, using only 32 pcells for th= e regions >=C2=A0 isn't enough. I've temporary bumped this value to 64 which is enoug= h > for booting >=C2=A0 on the BBB but we need a cleaner solution. I'll look into it soon-i= sh. >=20 >=C2=A0 So right now if you want to run current on BBB please take update y= ou > source tree >=C2=A0 and take the two patches from my github branch. >=20 >=C2=A0 Note that I think that this is the last time that I fix TI related = problems >=C2=A0 in the tree. I've spent too much time fixing BBB and Pandaboard dur= ing the >=C2=A0 last 12 months and I don't even use or care about those boards. If = someone >=C2=A0 wants to keep them alive please invest time or money into this. >=20 Again, Thank you for your work. Yes I'm interested in keeping the TI SoC al= ive.=20 I will put up the resources to do periodic tests and bugfixes for the 12-st= able for AM335x (and OSD3358). If we can agree on a baseline of tests we can perform the test on other boa= rds aswell.=C2=A0 Maybe based on proposal from Mark Linimon? >=C2=A0 Thanks to ian@ for helping me with this issue. >=20 > [1] : > https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=3D35= 0229&view=3Dmarkup > [2] : > https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=3D3502= 30&view=3Dmarkup > [3] : https://github.com/evadot/freebsd/tree/bbb --=20 B=C3=A4sta H=C3=A4lsningar Oskar Holmlund Tel 070-3220292 From owner-freebsd-arm@freebsd.org Tue Jul 23 19:44:01 2019 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 C2EF6B181F for ; Tue, 23 Jul 2019 19:44:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4288D71EBF for ; Tue, 23 Jul 2019 19:44:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id x6NJhowG032968 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Jul 2019 12:43:51 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id x6NJhn2m032967; Tue, 23 Jul 2019 12:43:49 -0700 (PDT) (envelope-from fbsd) Date: Tue, 23 Jul 2019 12:43:49 -0700 From: bob prohaska To: Jamie Landeg-Jones Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Lethargic rpi3, but seemingly still running Message-ID: <20190723194349.GA32898@www.zefox.net> References: <20190718034838.GA1921@www.zefox.net> <201907180958.x6I9wBF8075274@donotpassgo.dyslexicfish.net> <20190718151858.GB4325@www.zefox.net> <20190718182050.GL2342@funkthat.com> <20190721005135.GA18642@www.zefox.net> <201907230419.x6N4JRYZ069168@donotpassgo.dyslexicfish.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201907230419.x6N4JRYZ069168@donotpassgo.dyslexicfish.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 4288D71EBF X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.15 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.09)[ip: (0.36), ipnet: 50.1.16.0/20(0.18), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.71)[0.708,0]; NEURAL_HAM_LONG(-0.05)[-0.045,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.51)[0.509,0]; MX_GOOD(-0.01)[cached: www.zefox.net]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[] 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: Tue, 23 Jul 2019 19:44:01 -0000 On Tue, Jul 23, 2019 at 05:19:27AM +0100, Jamie Landeg-Jones wrote: > bob prohaska wrote: > > > Here's a snippet of systat -v 1 output while un-tarring firefox files. > > %busy was close to zero, it looks like there's congestion or a deadlock > > writing to the microSD card. At the time things like cd and ls were > > very slow to respond (tens of seconds) > > > > 28 pdpgs cpu2:ast > > Disks mmcsd da0 pass0 intrn cpu3:ast > > KB/t 12.00 0.00 0.00 152904 wire 9 cpu0:preem > > tps 5 0 0 80072 act 51 cpu1:preem > > MB/s 0.06 0.00 0.00 671344 inact 80 cpu2:preem > > %busy 213 0 0 120 21104 27 cpu3:preem > > You say "close to zero", but it's 213(!) in the output you gave! > Sorry, I was referring the %idle number above the bargraph and inverting the fraction, without noticing the %busy in the Disks output. At the moment the same machine is compiling clang8 with about 900M of swap in use, here is another sample: Disks mmcsd da0 pass0 264 intrn cpu3:ast KB/t 5.51 5.77 0.00 169680 wire 641 cpu0:pree tps 461 457 0 645096 act 1612 cpu1:pree MB/s 2.48 2.58 0.00 2280 inact 1522 cpu2:pree %busy 77 50 0 Swap is on both mmcsd and da0 (Samsung Evo+ microsd and a Sandisk usb3 flash drive). > However, I suspected something like that - high %busy whilst little actual > transfers taking place. I've seen it before, along with the characteristics > you describe, but unfortunately I don't have a fix. > So far I think the problem has only been obvious when bsdtar is running. If there's another way to provoke it that might be interesting to try. Thanks for reading more closely than I wrote! bob prohaska From owner-freebsd-arm@freebsd.org Wed Jul 24 03:16:06 2019 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 CC524BA6D5 for ; Wed, 24 Jul 2019 03:16:06 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 801C58AF01 for ; Wed, 24 Jul 2019 03:16:06 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id x6O3G3nw001782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2019 04:16:03 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id x6O3G075001636; Wed, 24 Jul 2019 04:16:01 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201907240316.x6O3G075001636@donotpassgo.dyslexicfish.net> Date: Wed, 24 Jul 2019 04:16:00 +0100 Organization: Dyslexic Fish To: jamie@catflap.org, fbsd@www.zefox.net Cc: freebsd-arm@freebsd.org, fbsd@www.zefox.net Subject: Re: Lethargic rpi3, but seemingly still running References: <20190718034838.GA1921@www.zefox.net> <201907180958.x6I9wBF8075274@donotpassgo.dyslexicfish.net> <20190718151858.GB4325@www.zefox.net> <20190718182050.GL2342@funkthat.com> <20190721005135.GA18642@www.zefox.net> <201907230419.x6N4JRYZ069168@donotpassgo.dyslexicfish.net> <20190723194349.GA32898@www.zefox.net> In-Reply-To: <20190723194349.GA32898@www.zefox.net> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Wed, 24 Jul 2019 04:16:04 +0100 (BST) 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: Wed, 24 Jul 2019 03:16:06 -0000 bob prohaska wrote: > Sorry, I was referring the %idle number above the bargraph and inverting the > fraction, without noticing the %busy in the Disks output. Ah, ok! Yes, it was the I/O I was concerned with, not the CPU. > At the moment the same machine is compiling clang8 with about 900M of swap in use, > here is another sample: > Disks mmcsd da0 pass0 264 intrn cpu3:ast > KB/t 5.51 5.77 0.00 169680 wire 641 cpu0:pree > tps 461 457 0 645096 act 1612 cpu1:pree > MB/s 2.48 2.58 0.00 2280 inact 1522 cpu2:pree > %busy 77 50 0 > > Swap is on both mmcsd and da0 (Samsung Evo+ microsd and a Sandisk usb3 flash drive). > > > However, I suspected something like that - high %busy whilst little actual > > transfers taking place. I've seen it before, along with the characteristics > > you describe, but unfortunately I don't have a fix. > > > > So far I think the problem has only been obvious when bsdtar is running. If > there's another way to provoke it that might be interesting to try. Unfortunately, my Pii's are not working at the moment (one sdcard broke, the other sdcard was "borrowed" for something else!) so I can't test this, but my suspicion is that it's related to many file creations (and/or deletions?) You could try a script that creates lots of small files.. Do you have soft-updates enabled? And do you have 'trim' enabled for the sdcard? I didn't mention this in earlier replies, because I cannot find any reference to back it up, but here goes, take it with a pinch of salt!: >From what I understand, ARM I/O causes blocking of the CPU. I know on my android 'desktop' devices that if I have heavy I/O, everything else (even the mouse cursor) can freeze for 10s of seconds at a time, whilst the CPU is otherwise idle. At a guess, this problem gets worse with a fragmented or aging sdcard/usb stick. Does any of this match your observations? > Thanks for reading more closely than I wrote! :-) Cheers, Jamie From owner-freebsd-arm@freebsd.org Wed Jul 24 08:08:02 2019 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 3A6D2A1A27 for ; Wed, 24 Jul 2019 08:08:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id C3B586E8C1 for ; Wed, 24 Jul 2019 08:08:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.nyi.freebsd.org (Postfix) id C34E6A1A25; Wed, 24 Jul 2019 08:08:01 +0000 (UTC) Delivered-To: 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 C3038A1A24 for ; Wed, 24 Jul 2019 08:08:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BF796E8BE; Wed, 24 Jul 2019 08:08:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 34215875; Wed, 24 Jul 2019 10:07:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=+IMJoa8UvBhrpMaL1JMDKntjLk0=; b=t7ijI4A3cDrH2dOe9Xx378sagvL4 6Fz3/y67LL/IWZUM3kAs/86WE+DaqcNTLTAjW5VEsLWPRWlbJoREOtSVLTff+VmG QKzpTy6O3fq7yvS0FcX/V4PC3I0wChNbUqfTH1dBMiR1Lx9mFomnrX1ZX5qiF6df YYu8aCOo7DHEUSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=rfMW+685vN71bx83XwbCWSMw4Pv1rdStYq0n84IeG2A+GZwWg3aHa1o5 lMveHg6LViidZlOl8yhoSw5g5tKytc9IWFZIu7wUgyksus1V89bfCpk5KNX/abkT EVxExEuCVrH8aZyKzxwsLu93mU6ypsXUwy7ulWVh1bLNi1sscgI= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 5823ebf3 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 24 Jul 2019 10:07:53 +0200 (CEST) Date: Wed, 24 Jul 2019 10:07:52 +0200 From: Emmanuel Vadot To: "Dr. Rolf Jansen" Cc: arm@FreeBSD.org, John-Mark Gurney , Ian Lepore Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-Id: <20190724100752.a179207bae7da3d715fe9878@bidouilliste.com> In-Reply-To: <4261EECC-29D1-4CD3-A585-8A8606BA2A2E@obsigna.com> References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> <20190722171251.GU2342@funkthat.com> <20190723002116.75493451127739cf50b4077d@bidouilliste.com> <4261EECC-29D1-4CD3-A585-8A8606BA2A2E@obsigna.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5BF796E8BE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.971,0] 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: Wed, 24 Jul 2019 08:08:02 -0000 On Tue, 23 Jul 2019 09:22:25 -0300 "Dr. Rolf Jansen" wrote: > > Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot : > > > > ... > > > > Note that I think that this is the last time that I fix TI related problems > > in the tree. I've spent too much time fixing BBB and Pandaboard during the > > last 12 months and I don't even use or care about those boards. If someone > > wants to keep them alive please invest time or money into this. > > You can have this quite easily. Simply revert your non-revisited batch import of 3126 files of the Linux DTS tree to the previous state (https://svnweb.freebsd.org/base?view=revision&revision=347366) > > Then let others import what they need file by file or snippet by snippet. By this you would be guaranteed to never be bothered agin with any BeagleBone. > > Best regards > > Rolf Yeah that's doesn't work. A lot of DTS files are shared between boards and some bindings are even shared between arches. So you have to threat DTS as a hole. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Jul 24 11:41:02 2019 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 D1301A5BA2 for ; Wed, 24 Jul 2019 11:41:02 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B849761C0 for ; Wed, 24 Jul 2019 11:41:02 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 089B42110BC for ; Wed, 24 Jul 2019 07:40:25 -0400 (EDT) Received: from [192.168.10.16] (D6.Denninger.Net [192.168.10.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 916EB1D6895 for ; Wed, 24 Jul 2019 06:40:25 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: LLDB on a core file non-func on aarch64? Openpgp: preference=signencrypt Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= mQINBFIX1zsBEADRcJfsQUl9oFeoMfLPJ1kql+3sIaYx0MfJAUhV9LnbWxr0fsWCskM1O4cV tHm5dqPkuPM4Ztc0jLotD1i9ubWvCHOlkLGxFOL+pFbjA+XZ7VKsC/xWmhMwJ3cM8HavK2OV SzEWQ/AEYtMi04IzGSwsxh/5/5R0mPHrsIomV5SbuiI0vjLuDj7fo6146AABI1ULzge4hBYW i/SHrqUrLORmUNBs6bxek79/B0Dzk5cIktD3LOfbT9EAa5J/osVkstMBhToJgQttaMIGv8SG CzpR/HwEokE+7DP+k2mLHnLj6H3kfugOF9pJH8Za4yFmw//s9cPXV8WwtZ2SKfVzn1unpKqf wmJ1PwJoom/d4fGvQDkgkGKRa6RGC6tPmXnqnx+YX4iCOdFfbP8L9rmk2sewDDVzHDU3I3ZZ 8hFIjMYM/QXXYszRatK0LCV0QPZuF7LCf4uQVKw1/oyJInsnH7+6a3c0h21x+CmSja9QJ+y0 yzgEN/nM89d6YTakfR+1xkYgodVmMy/bS8kmXbUUZG/CyeqCqc95RUySjKT2ECrf9GhhoQkl +D8n2MsrAUSMGB4GQSN+TIq9OBTpNuvATGSRuF9wnQcs1iSry+JNCpfRTyWp83uCNApe6oHU EET4Et6KDO3AvjvBMAX0TInTRGW2SQlJMuFKpc7Dg7tHK8zzqQARAQABtCNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PokCPAQTAQIAJgUCUhfXOwIbIwUJCWYBgAYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEG6/sivc5s0PLxQP/i6x/QFx9G4Cw7C+LthhLXIm7NSH AtNbz2UjySEx2qkoQQjtsK6mcpEEaky4ky6t8gz0/SifIfJmSmyAx0UhUQ0WBv1vAXwtNrQQ jJd9Bj6l4c2083WaXyHPjt2u2Na6YFowyb4SaQb83hu/Zs25vkPQYJVVE0JX409MFVPUa6E3 zFbd1OTr3T4yNUy4gNeQZfzDqDS8slbIks2sXeoJrZ6qqXVI0ionoivOlaN4T6Q0UYyXtigj dQvvhMt0aNowKFjRqrmSDRpdz+o6yg7Mp7qEZ1V6EZk8KqQTH6htpCTQ8i79ttK4LG6bstSF Re6Fwq52nbrcANrcdmtZXqjo+SGbUqJ8b1ggrxAsJ5MEhRh2peKrCgI/TjQo+ZxfnqEoR4AI 46Cyiz+/lcVvlvmf2iPifS3EEdaH3Itfwt7MxFm6mQORYs6skHDw3tOYB2/AdCW6eRVYs2hB RMAG4uwApZfZDKgRoE95PJmQjeTBiGmRPcsQZtNESe7I7EjHtCDLwtJqvD4HkDDQwpzreT6W XkyIJ7ns7zDfA1E+AQhFR6rsTFGgQZRZKsVeov3SbhYKkCnVDCvb/PKQCAGkSZM9SvYG5Yax 8CMry3AefKktf9fqBFg8pWqtVxDwJr56dhi0GHXRu3jVI995rMGo1fLUG5fSxiZ8L5sAtokh 9WFmQpyl Message-ID: Date: Wed, 24 Jul 2019 06:40:23 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010502050909030706000904" X-Rspamd-Queue-Id: 4B849761C0 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.77 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[px.denninger.net]; NEURAL_HAM_SHORT(-0.92)[-0.923,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.64)[ip: (-9.86), ipnet: 104.236.64.0/18(-4.33), asn: 14061(1.04), country: US(-0.05)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[197.57.1.68.zen.spamhaus.org : 127.0.0.11]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:+]; DMARC_NA(0.00)[denninger.net]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[] 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: Wed, 24 Jul 2019 11:41:02 -0000 This is a cryptographically signed message in MIME format. --------------ms010502050909030706000904 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It appears it is... at least at the granularity I'd expect (the ability to show the source line where it occurred, what the variables were at the time, etc.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010502050909030706000904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNzI0MTE0MDI0 WjBPBgkqhkiG9w0BCQQxQgRAkeOZRBkCUlc+rLkfbGiOHwLQf8+oGodHcXM0/QfKMyWWEfvq u20hTV6gv+0Eah+gzqVurF6rCVUFhb226vSdDTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCuojeiUMbBPpTWgm5iD1E+PPijimak3tp5TNteFt8Xn1ZSGdBXSRmetGti2OxjWTIF F04rxqF0nUnlPqnTvNP+zqivU9OUQFCZPSthi3wbQsQIJbTsh1T71cV5ksDsNfoe+NkCjjGc 47EEXWPwd9fHFVAO7lEoA9VJgv7B6b1A6q3F04s4KrR9r2V+/soGclVSF9wFGR4t/MS1oTpH oHlgkqA3nxIJb1B4isucVBCK4ea3obXL63pWmec3BXdI0jP5iyaQ2nRRgLMpNkGi7K039dUR HKTJuSnBQ9xA3aZNHBuUxo6qxDI2Vc1uvDpd5cED6nLfD5pDgmxiKvSxl0Wt+/pAXJ5Mzvxo +NITEg+7b7NULbL+o18B+B1FzuX5Gwk+ucXnOpayiQ9o7QgpgdmwbgsHcb7n6rA8Fey28LDH Y4k103MUTgkp1NDkiYoqlbY8EZlWHZ3C+XcLwJzulPmFAowcpIesAjA/jK7EM8RMbxc5cy6h 8YrhdrsBERIY/dsLQjkqBx+/TSw6rqtOHGBTYp+V94yTzHxnXKWil6+p3lSvz2thitkF2ecD JqE4nTyRbCMjA7fOORCyun/oLOh/HLxMsrzPPm5hNR8giHsQ20ygIveuJg9L+hHf6rXtewsG LcP3siUJJ+dS7KLWq/KAVPwSJwWZo44FzGbAzeqsFQAAAAAAAA== --------------ms010502050909030706000904-- From owner-freebsd-arm@freebsd.org Thu Jul 25 00:14:49 2019 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 9B0B3BD92D for ; Thu, 25 Jul 2019 00:14:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C561853D7 for ; Thu, 25 Jul 2019 00:14:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id x6P0EfRR038641 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Jul 2019 17:14:42 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id x6P0Ef6o038640; Wed, 24 Jul 2019 17:14:41 -0700 (PDT) (envelope-from fbsd) Date: Wed, 24 Jul 2019 17:14:40 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Clang8 crash on rpi3 at r349989 building openjdk8 Message-ID: <20190725001440.GA38603@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 3C561853D7 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.97 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; URIBL_BLOCKED(0.00)[zefox.net.multi.uribl.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.50)[0.500,0]; IP_SCORE(0.09)[ip: (0.35), ipnet: 50.1.16.0/20(0.18), asn: 7065(-0.04), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.34)[0.344,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: www.zefox.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.15)[0.150,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[] 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: Thu, 25 Jul 2019 00:14:49 -0000 In trying to compile www/chromium on an rpi3 at r349989 with ports at 507005 clang8 crashed in a way that superficially resembled earlier "OOMA" kills. However, there's no swap use to speak of and no complaints of excessive swap delay on the console ..... Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspot/src/share/vm/interpreter/invocationCounter.cpp Assertion failed: (isa(Val) && "cast() argument of incompatible type!"), function cast, file /usr/src/contrib/llvm/include/llvm/Support/Casting.h, line 255. Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspot/src/share/vm/memory/iterator.cpp Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspot/src/share/vm/runtime/java.cpp Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspot/src/share/vm/classfile/javaAssertions.cpp Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspot/src/share/vm/runtime/javaCalls.cpp Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspot/src/share/vm/classfile/javaClasses.cpp c++: error: unable to execute command: Abort trap (core dumped) c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 8.0.1 (branches/release_80 364487) (based on LLVM 8.0.1) Target: aarch64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. ..... The clang8 crash report files and the swap usage log are at http://www.zefox.net/~fbsd/rpi3/swaptests/r349989/ Thanks for reading and any suggestions. bob prohaska From owner-freebsd-arm@freebsd.org Thu Jul 25 01:32:46 2019 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 01BA0BF7C4 for ; Thu, 25 Jul 2019 01:32:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-15.consmr.mail.bf2.yahoo.com (sonic309-15.consmr.mail.bf2.yahoo.com [74.6.129.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D83BA88282 for ; Thu, 25 Jul 2019 01:32:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: MkWY.nkVM1kazX31tLPPwcJKFb82kw6XRrh1ptr25p4.k3wQeuKgNS4nu9diZx8 rGYVLebSifmYGssW5_C34jsq_3ER09iC2Kn8u8f1894quZeBkewbRlhaoopGbtiBGhJSQ6nRSnq1 SOkc3ZaIU3uO1iqxtOoAKMwqszSU3EFi_r6ethKyeMf0vrIv2rUh1IEJmecCAMdSyQ7MV8S78ahQ PtcZLcnaphWyqgFW1DYgLKOYAT1Rd.chyIb0ow6Tl_i5kEbcKicGSFFC11Cw8GBJpiHyhVCby1AC .vh9GTjbbAg.Z53ZKtB9zoNRU99HTEzNUhirlDihXBmtWaBkpcjs2dTF59SGZ24ex5FQ3tbm4mWh nw.kMhYRvND8EWUmttEoybd_cm_itaQDk1kG7VLDWCBJdUVgKrV.ayESZe1TPl2x8VQCyOrXoPgq a592_OSGfVikR.U5FlhsDNEiumj8YKB6n2CY_80qeJ_NXqGKLySxsoMCiNMToA8mQT0KGWibGOyR hB_W2Kp_OmspqoBh4k6B5oGWyd.cXAnIpEBWusqwJz58XcamgVPgvc84K4Bz7iOQfMAPOpEX9UWH NS6_ltHXQc043xZBll2D5.0BDqlHwBEwKXEdJDw.YdDyEU.C_RESM5pIMMWRyWnxCbUK5U7aEPD3 CzGyjSxAPI6yTrYXF5CjMuez4Y4spkl1BKexFLWDzcUM2W4.gi_VqCq0olmOG.9OPRbSDvGGjY0y Ob9OXXNwcswyaaflcCV.gPr7Nr_1Z9otAFxmsmdDFRrvHM_Sezn1AeWVHKI3MfD3tgqpBTfbsXEv vdHMo9wvf.mST9pyQsr0STvpIUe7OzPdZIP6Qi1F6DtNrePblZSI.EFzUw5Y5f0t5ajWMu.hNHp7 u1ptUlpH9lOdF84qjKVICeyZN4dHcy4xDXQWcqQlemQ5aTfkHCv7eO02Y._tzmAJ0py7j4tsrkx9 4LTBa8xFHM3N8zcI8cHiMWWMonnGk24htG5SxyQ5kJYpVDCH0QneAu5NARWwoxqcQfV2pQCDTj7O 1aY7IetMe9HqjYtK10J3RDyw89SyC8rijM0dEtKElhf8d7omvYxCGASp5cgShKWv9ogziDnuurmS kwPSK5Wp.zmkEqtFEaoIBKljHI6aOHzLQ0QIv3fpRDt9nXpfdaOmqFqjZWHxBgx3iluSFR0ma09G 98sJACBOIpbt8JIW4PfqnEeNJrNCjUhoiN0pIyK.jcCDWQDi1bHbL85_QeTr5MCP1Y5mV.SMTtdX DZifX Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Thu, 25 Jul 2019 01:32:37 +0000 Received: by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7b91e76d19d202486c45e08453f05997; Thu, 25 Jul 2019 01:32:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Clang8 crash on rpi3 at r349989 building openjdk8 From: Mark Millard In-Reply-To: <20190725001440.GA38603@www.zefox.net> Date: Wed, 24 Jul 2019 18:32:32 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190725001440.GA38603@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: D83BA88282 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; URIBL_BLOCKED(0.00)[dsl-only.net.multi.uribl.com,zefox.net.multi.uribl.com]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.989,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.19)[ip: (3.46), ipnet: 74.6.128.0/21(1.42), asn: 26101(1.13), country: US(-0.05)]; NEURAL_SPAM_MEDIUM(0.90)[0.900,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.41)[0.412,0]; RCVD_IN_DNSWL_NONE(0.00)[125.129.6.74.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[125.129.6.74.rep.mailspike.net : 127.0.0.17] 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: Thu, 25 Jul 2019 01:32:46 -0000 On 2019-Jul-24, at 17:14, bob prohaska wrote: > In trying to compile www/chromium on an rpi3 at r349989 with > ports at 507005 clang8 crashed in a way that superficially=20 > resembled earlier "OOMA" kills. However, there's no swap use=20 > to speak of and no complaints of excessive swap delay on the console > ..... > Compiling = /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspo= t/src/share/vm/interpreter/invocationCounter.cpp > Assertion failed: (isa(Val) && "cast() argument of incompatible = type!"), function cast, file = /usr/src/contrib/llvm/include/llvm/Support/Casting.h, line 255. > Compiling = /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspo= t/src/share/vm/memory/iterator.cpp > Compiling = /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspo= t/src/share/vm/runtime/java.cpp > Compiling = /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspo= t/src/share/vm/classfile/javaAssertions.cpp > Compiling = /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspo= t/src/share/vm/runtime/javaCalls.cpp > Compiling = /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b10.1/hotspo= t/src/share/vm/classfile/javaClasses.cpp > c++: error: unable to execute command: Abort trap (core dumped) > c++: error: clang frontend command failed due to signal (use -v to see = invocation) > FreeBSD clang version 8.0.1 (branches/release_80 364487) (based on = LLVM 8.0.1) > Target: aarch64-unknown-freebsd13.0 > Thread model: posix > InstalledDir: /usr/bin > c++: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. > ..... >=20 > The clang8 crash report files and the swap usage log are at >=20 > http://www.zefox.net/~fbsd/rpi3/swaptests/r349989/ >=20 > Thanks for reading and any suggestions. Your log file shows: Assertion failed: (isa(Val) && "cast() argument of incompatible = type!"), function cast, file = /usr/src/contrib/llvm/include/llvm/Support/Casting.h, line 255. which would lead to "c++: error: unable to execute command: Abort trap (core dumped)". So: not like an inability to establish enough free RAM after some number of tries. It is likely someone would want to see the backtrace from looking at a core dump, although you may not have debug symbols in place in the compiler. Hopefully the .sh and .cpp for instance-Klass will allow reproduction of the assert. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Jul 25 04:26:57 2019 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 0E0F1C249D for ; Thu, 25 Jul 2019 04:26:57 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from mail.kronometrix.org (mail.kronometrix.org [95.85.46.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.kronometrix.org", Issuer "mail.kronometrix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DE018DD21 for ; Thu, 25 Jul 2019 04:26:51 +0000 (UTC) (envelope-from sparvu@kronometrix.org) Received: from [192.168.1.131] (82-203-140-69.bb.dnainternet.fi [82.203.140.69]) (authenticated bits=0) by mail.kronometrix.org (8.15.2/8.15.2) with ESMTPSA id x6P4Qgs1020821 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 Jul 2019 04:26:43 GMT (envelope-from sparvu@kronometrix.org) X-Authentication-Warning: mail.kronometrix.org: Host 82-203-140-69.bb.dnainternet.fi [82.203.140.69] claimed to be [192.168.1.131] From: Stefan Parvu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Clang8 crash on rpi3 at r349989 building openjdk8 Date: Thu, 25 Jul 2019 07:26:37 +0300 References: <20190725001440.GA38603@www.zefox.net> To: freebsd-arm@freebsd.org In-Reply-To: <20190725001440.GA38603@www.zefox.net> Message-Id: <14047220-3A84-4AE1-86CB-EE2FC5B43742@kronometrix.org> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 4DE018DD21 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of sparvu@kronometrix.org designates 95.85.46.90 as permitted sender) smtp.mailfrom=sparvu@kronometrix.org X-Spamd-Result: default: False [0.33 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.61)[-0.608,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.50)[-0.497,0]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[mail.kronometrix.org]; DMARC_NA(0.00)[kronometrix.org]; NEURAL_SPAM_SHORT(0.81)[0.806,0]; IP_SCORE(0.44)[ip: (0.31), ipnet: 95.85.0.0/18(0.92), asn: 14061(1.03), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14061, ipnet:95.85.0.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 25 Jul 2019 04:26:57 -0000 >=20 > In trying to compile www/chromium on an rpi3 at r349989 with > ports at 507005 clang8 crashed in a way that superficially=20 > resembled earlier "OOMA" kills. However, there's no swap use=20 > to speak of and no complaints of excessive swap delay on the console on rpi2,3 I have to always setup a decent 2GB swap in order to copy, = uncompress large files or build some sfw packages or our own product. Without swap = does not work. Try to add 2GB of swap and try again to see if that helped. Stefan= From owner-freebsd-arm@freebsd.org Thu Jul 25 06:33:15 2019 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 06542C4122 for ; Thu, 25 Jul 2019 06:33:15 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE3846B902 for ; Thu, 25 Jul 2019 06:33:13 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: by mail-pl1-x62e.google.com with SMTP id i2so23019226plt.1 for ; Wed, 24 Jul 2019 23:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=suti0gpZiIyz4JbNi6Cva6BLI+JyiAlaCWgWe4E2bV0=; b=E2ikaPYDn3OCvrTPNMf0IHIqhi9f3Avbljq5tnDaZZp825ufji8EpmPQFGJDVw3Lin SVlV01wmTeSPNf1bznN0xYgyRgEhPlLCQFF2JKBNjW6s1iVmpK3pNPXrUs5tEK4A07E0 Dcfpn3Dwmoq5I1IuXTgO2fs2ZIYCmJirvdpKx1NDCqqnbQRFO1DR66IgILmV+rN2Mlbc 6L0hpBTwpOFiROpnT+5L8F2bx5A3GWNXB/+fZtZw+E4v0ZDjxNrROgykzBJRK2WSdJX4 fSoALik2bLkVhRhpNRbl/qHv6qTNygGObXIi6oKhw1qngiJ6R92wEREPEilMAE+4S2Ox qDmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=suti0gpZiIyz4JbNi6Cva6BLI+JyiAlaCWgWe4E2bV0=; b=Xwo6JqD1trozyxPjU2cZYZFoPvvhazbGcqi0P3vb5NN5BVyukF2SBuON00MvT+GV7f N9Z4wWFJXzr3ql+LE6HY0/HDsQPQvYSqQL1bT6DyDjdPytxBZbjpb2rn+MSA5sei16y1 8zpa9G1KV8WKtcy7cscw6qhjknUKyqYvpKaJXMFBgjnTzmRpPKF47BVC19l5cwGhKl9y 1SrDeXZlqtRa87eOn7nUkjssYOhhaUtzCDykFQAdpSj78ruq3SwlSqNIqeO97jLIYrh3 iaK4FjdiddnIoLvHpDYJETaq0gisBeR88F90aJMYxWstkqaitALCvYn4imDv3ZdCTJ6I SO9g== X-Gm-Message-State: APjAAAV4rwMZRR3s6jP8KIlWQn1t2YzCAEnHt5+4wpUSBlVwKbBIesYX +DopdOmEEprLYMYO4TOXjPUUvPqX3ZsM4Z3PaPtV1BLDYUM= X-Google-Smtp-Source: APXvYqzR1AN1u80O+nOjKdZROFzGL76q7y0pCdg+Kh4XC+i065FTf5IvJ4bjRNSrZ3kzayIUluhCt9TcG80kmuWo9WU= X-Received: by 2002:a17:902:b68f:: with SMTP id c15mr90338271pls.104.1564036392454; Wed, 24 Jul 2019 23:33:12 -0700 (PDT) MIME-Version: 1.0 References: <20190725001440.GA38603@www.zefox.net> In-Reply-To: <20190725001440.GA38603@www.zefox.net> From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= Date: Thu, 25 Jul 2019 08:32:36 +0200 Message-ID: Subject: Re: Clang8 crash on rpi3 at r349989 building openjdk8 To: bob prohaska Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: CE3846B902 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=E2ikaPYD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mikaelurankar@gmail.com designates 2607:f8b0:4864:20::62e as permitted sender) smtp.mailfrom=mikaelurankar@gmail.com X-Spamd-Result: default: False [-6.91 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.91)[-0.907,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; URIBL_BLOCKED(0.00)[zefox.net.multi.uribl.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[e.2.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-3.00)[ip: (-9.40), ipnet: 2607:f8b0::/32(-3.09), asn: 15169(-2.43), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] 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: Thu, 25 Jul 2019 06:33:15 -0000 Le jeu. 25 juil. 2019 =C3=A0 02:15, bob prohaska a =C3= =A9crit : > > In trying to compile www/chromium on an rpi3 at r349989 with > ports at 507005 clang8 crashed in a way that superficially > resembled earlier "OOMA" kills. However, there's no swap use > to speak of and no complaints of excessive swap delay on the console > ..... > Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b= 10.1/hotspot/src/share/vm/interpreter/invocationCounter.cpp > Assertion failed: (isa(Val) && "cast() argument of incompatible ty= pe!"), function cast, file /usr/src/contrib/llvm/include/llvm/Support/Casti= ng.h, line 255. > Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b= 10.1/hotspot/src/share/vm/memory/iterator.cpp > Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b= 10.1/hotspot/src/share/vm/runtime/java.cpp > Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b= 10.1/hotspot/src/share/vm/classfile/javaAssertions.cpp > Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b= 10.1/hotspot/src/share/vm/runtime/javaCalls.cpp > Compiling /usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u222-b= 10.1/hotspot/src/share/vm/classfile/javaClasses.cpp > c++: error: unable to execute command: Abort trap (core dumped) > c++: error: clang frontend command failed due to signal (use -v to see in= vocation) > FreeBSD clang version 8.0.1 (branches/release_80 364487) (based on LLVM 8= .0.1) > Target: aarch64-unknown-freebsd13.0 > Thread model: posix > InstalledDir: /usr/bin > c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.fre= ebsd.org/submit/ and include the crash backtrace, preprocessed source, and = associated run script. > ..... > > The clang8 crash report files and the swap usage log are at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r349989/ > > Thanks for reading and any suggestions. It's reported here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D2365= 66 openjdkd11 is not affected by this bug (and it's the 'mixed' mode version), if you want to try it : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239246 you'll probably need #237054 From owner-freebsd-arm@freebsd.org Thu Jul 25 10:55:38 2019 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 780F2A1965 for ; Thu, 25 Jul 2019 10:55:38 +0000 (UTC) (envelope-from 0102016c285500bf-0347a25f-7386-4ba2-8717-f48360430fcf-000000@eu-west-1.amazonses.com) Received: from a6-79.smtp-out.eu-west-1.amazonses.com (a6-79.smtp-out.eu-west-1.amazonses.com [54.240.6.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1F875205 for ; Thu, 25 Jul 2019 10:55:37 +0000 (UTC) (envelope-from 0102016c285500bf-0347a25f-7386-4ba2-8717-f48360430fcf-000000@eu-west-1.amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn; d=amazonses.com; t=1564044755; h=Message-ID:Date:Subject:From:To:MIME-Version:Content-Type:List-Unsubscribe:Feedback-ID; bh=QaMly8wcgoPzTkZucY/OqxXLAG9YPK+3k23aDks6UAo=; b=YR/k1XjzeIPPYeecgSVQXesLYiPAxfx7FcdCuOM0y19t66Dy6xwrXwJFNEoDeo1S KRqSmILj8e/oA443XQGIrw8r9lTfERDY3IQmQC7y7YaQnUh/4QlHaC4x5y7CqztEUq4 j2bvVcvNGUxziex1C4YYAMRvfx+h2H+KcmhrkJfs= Message-ID: <0102016c285500bf-0347a25f-7386-4ba2-8717-f48360430fcf-000000@eu-west-1.amazonses.com> Date: Thu, 25 Jul 2019 08:52:35 +0000 Subject: =?utf-8?Q?=F0=9F=8E=84Christmas?= In July SALE! =?utf-8?Q?=F0=9F=8E=81?= From: Snatcher Deals To: freebsd-arm@freebsd.org MIME-Version: 1.0 X-EmailOctopus-Version: 2 X-EmailOctopus-Started-Preparing-At: 2019-07-25T08:41:36+00:00 X-EmailOctopus-Ses-Configuration-Set-Name: emailoctopus-92ac08625b86fcb74e8dc6e633188d55 X-EmailOctopus-Sent-At: 2019-07-25T08:52:34+00:00 X-EmailOctopus-Parent-Type-Id: campaign X-EmailOctopus-Parent-Id: e9d48bb4-aeb6-11e9-9307-06b4694bee2a X-EmailOctopus-List-Id: f3068783-93ee-11e9-9307-06b4694bee2a X-EmailOctopus-List-Contact-Id: 66d6227d-9712-11e9-9307-06b4694bee2a X-SES-Outgoing: 2019.07.25-54.240.6.79 Feedback-ID: 1.eu-west-1.S9D/OG//uxqWxLXWwJC1jmPHR4F3B2r9y7EKQ4EbeeU=:AmazonSES X-Rspamd-Queue-Id: 4B1F875205 X-Spamd-Bar: +++++++++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn header.b=YR/k1Xjz; spf=pass (mx1.freebsd.org: domain of 0102016c285500bf-0347a25f-7386-4ba2-8717-f48360430fcf-000000@eu-west-1.amazonses.com designates 54.240.6.79 as permitted sender) smtp.mailfrom=0102016c285500bf-0347a25f-7386-4ba2-8717-f48360430fcf-000000@eu-west-1.amazonses.com X-Spamd-Result: default: False [9.29 / 15.00]; R_SPF_ALLOW(0.00)[+ip4:54.240.0.0/18]; ZERO_FONT(0.10)[1]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[amazonses.com:+]; SUBJECT_HAS_EXCLAIM(0.00)[]; MX_GOOD(-0.01)[cached: feedback-smtp.eu-west-1.amazonses.com]; FORGED_SENDER(0.30)[mailer@snatcherdeals.co.za,0102016c285500bf-0347a25f-7386-4ba2-8717-f48360430fcf-000000@eu-west-1.amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+]; IP_SCORE(-0.55)[ipnet: 54.240.0.0/21(-1.35), asn: 16509(-1.34), country: US(-0.05)]; ASN(0.00)[asn:16509, ipnet:54.240.0.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[mailer@snatcherdeals.co.za,0102016c285500bf-0347a25f-7386-4ba2-8717-f48360430fcf-000000@eu-west-1.amazonses.com]; ARC_NA(0.00)[]; RSPAMD_URIBL(4.50)[eomail1.com]; R_DKIM_ALLOW(0.00)[amazonses.com:s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn]; URIBL_BLOCKED(0.00)[amazonses.com.multi.uribl.com,snatcher.co.za.multi.uribl.com,eomail1.com.multi.uribl.com,awstrack.me.multi.uribl.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HTML_SHORT_LINK_IMG_1(2.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[snatcherdeals.co.za]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; MANY_INVISIBLE_PARTS(0.20)[3]; NEURAL_SPAM_SHORT(0.76)[0.762,0]; NEURAL_SPAM_MEDIUM(1.00)[1.000,0]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[79.6.240.54.list.dnswl.org : 127.0.15.0]; RCVD_TLS_ALL(0.00)[]; GREYLIST(0.00)[pass,body] X-Spam: Yes Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 25 Jul 2019 10:55:38 -0000 Up to 80% Discount=C2=A0 Snatch Now!=20 =F0=9F=8E=84Christmas In July SALE!=C2=A0=F0=9F=8E=81 View this email in your browser [https://berrima.eomail1.com/web-version?lc=3D66d6227d-9712-11e9-9307-06b46= 94bee2a&p=3De9d48bb4-aeb6-11e9-9307-06b4694bee2a&pt=3Dcampaign&t=3D15640447= 54&s=3D7ef45bbe653f07f6b68c37583efff89f3ea7d2a749767b81f92b7ae97b5e8940] =09=09[Snatcher-Sign-1%20(002).jpg] [https://snatcher.co.za/collections/snatch-of-the-week] =09=09[Banner%20Dimensions.png] [https://snatcher.co.za/collections/christmas-in-july-1] =09=09 Unsubscribe from this list [https://berrima.eomail1.com/unsubscribe?l=3Df3068783-93ee-11e9-9307-06b469= 4bee2a&lc=3D66d6227d-9712-11e9-9307-06b4694bee2a&p=3De9d48bb4-aeb6-11e9-930= 7-06b4694bee2a&pt=3Dcampaign&spa=3D1564044096&t=3D1564044754&s=3Da23911e936= 0b0ee1123e104be8955282c99162e077420f5b7952a561d6b70519] Email Powered By Snatcher [https://snatcher.co.za/]=20 [https://snatcher.co.za/] From owner-freebsd-arm@freebsd.org Thu Jul 25 13:59:59 2019 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 E410FA55D1 for ; Thu, 25 Jul 2019 13:59:59 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.xs4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EF9F84034 for ; Thu, 25 Jul 2019 13:59:59 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from romangtfo.localnet ([IPv6:2001:985:ab38:1:21f:c6ff:feba:d9]) by smtp-cloud8.xs4all.net with ESMTP id qeGfhAoyqeD5bqeGghiBGu; Thu, 25 Jul 2019 15:58:50 +0200 From: Adriaan de Groot To: freebsd-arm@freebsd.org Subject: Re: arm support documentation [was: FreeBSD 11.3-RELEASE and 11.2-RELEASE images fail to boot on BeagleBone Black] Date: Thu, 25 Jul 2019 15:58:41 +0200 Message-ID: <1659951.NSugcIQg4l@romangtfo> Organization: FreeBSD In-Reply-To: <20190716003350.GA19462@lonesome.com> References: <8352f841-0522-9f45-148d-d2948e97857e@gmail.com> <20190714174432.GC26897@lonesome.com> <20190716003350.GA19462@lonesome.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2327121.IoJhKq2saK"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-CMAE-Envelope: MS4wfCASiQdkaLECu17ysT2f0fRR0T6rL2eTBTsNnIkx42bzu/Tuhnt49nM+Y/Uh9/cqMXSPcwHgyz2WM90UYYrrrnKzsVa54NmTUnlf4CMbHoqK/DTa7V7m 9ct1FHIgzP9SpbqnnJrNeKQ9PXh/SXfsquSvPx3tgAVqQUmnRmwzrVsmFhGx7VwzNzJJ8iaycBEmHoCe1dIgJA1qeRucGKxM+WjFSc+pHo+fqPIiYZtQVPZj X-Rspamd-Queue-Id: 7EF9F84034 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] 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: Thu, 25 Jul 2019 13:59:59 -0000 --nextPart2327121.IoJhKq2saK Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Tuesday, July 16, 2019 2:33:51 AM CEST Mark Linimon wrote: > On Sun, Jul 14, 2019 at 05:44:32PM +0000, Mark Linimon wrote: > > If enough people are interested, I can put together a page modeled on > > this, and we can see where it goes from there. > > Turning the existing rpi table on the wiki on its side gives us the > following prototype: That's really useful as a prototype. I'd be happy to add some rows for boards I have (Pine stuff, mostly, where ehaupt is infinitely more knowledgable, but I feel I ought to help anyway) Some questions about the columns, layout, etc., not meant as nit-picking. - What does the "family" column mean? Would those get "BCM..." for the Pi's, and AW-A64, AW-H6 etc for Allwinner based boards? - Would it be useful to include core type information in here? There was a recent thread about cores (A53 vs A72 for instance) which would steer board selection. (It might not be: this table looks like "you have this thing, here's what you can get out of it on FBSD" and the cores are not influenced by the FBSD part). - Is there a nice ? icon? It might be more aesthetically pleasing to have consistent widths of the symbols. - Is there a semantic difference between (footnote) and just (footnote)? - Should the camera column have camera-interface information? - For the Pi Zero, why is there b/g/n in the notes column? Shouldn't that be in the Wifi column? .. just *commenting* on this table drives home that it needs some kind of tool support to manage all the footnotes and whatnots. [ade] --nextPart2327121.IoJhKq2saK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEV+FL0c1sGYvBG/GNYafSYnfk0NsFAl05tZEACgkQYafSYnfk 0Nu/VAv/a2uXlETciwaxOgkmjSol4Q7bunf7lksHbVqGtXCFhQGiVaRQQuHyZ0/3 QarFZ5PRzYoAPzTvW2wWd7lWEhtBowOwht9seVhv2SC76cBTl/HyUFrXd3VI4VzR r6PMLl0wY5bMsCXPg26OEjgZeVyF6hMQkICe5NSAy49hWS8OX7sZuBLDJW++f7O/ sdPEPV6r9Kz4At0cFO1++ph93J9LbyC9lREgUwoEqgRTk8a76xOTeepCYr051j3s Do1T+jyh5ikviGZOgKceW7KvQrRSyGhE+AIQZZHxO5XRAHcfkS8yHaTWGT5X6ryN zB97XtnwE2EgAr9k+FEqWmzVBQKEGXm4yjE+4rKl6AGb7ns4uxpWxhQvHT1FNysg HqeSWezO9NVvekmOFRQsRGYmBVgewChTfGMQn5QBe3AQiiiInK8yeYkhqOCITDJu +ldtqGH+8IY/69ruE1SGbdyIoTzlh5WS56PctWXa+2zoEGrYjXoL+mTq14EsBM50 +7SqYRqp =lzEa -----END PGP SIGNATURE----- --nextPart2327121.IoJhKq2saK-- From owner-freebsd-arm@freebsd.org Thu Jul 25 18:23:09 2019 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 BA934AAF0B for ; Thu, 25 Jul 2019 18:23:09 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.protonmail.ch", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 858E88EDB7 for ; Thu, 25 Jul 2019 18:23:08 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Thu, 25 Jul 2019 18:22:53 +0000 To: David Cornejo From: Robert Crowston Cc: "freebsd-arm@freebsd.org" Reply-To: Robert Crowston Subject: Re: Raspberry Pi 4 boot hangs in sched_idletd. Message-ID: In-Reply-To: References: Feedback-ID: 2OVbcR1yHYpdkD8cgQllkFwcuMVZg_LiVMMPvptooFDfHD_03MuQO4ZaF626jWHZYFEhNR2cmIbZ53j4QGWMBQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch X-Rspamd-Queue-Id: 858E88EDB7 X-Spamd-Bar: ------- X-Spamd-Result: default: False [-7.72 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; FREEMAIL_FROM(0.00)[protonmail.com]; MX_GOOD(-0.01)[mailsec.protonmail.ch,mail.protonmail.ch]; DKIM_TRACE(0.00)[protonmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.92)[-0.917,0]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; RCVD_IN_DNSWL_LOW(-0.10)[18.40.70.185.list.dnswl.org : 127.0.5.1]; ASN(0.00)[asn:19905, ipnet:185.70.40.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=default]; URIBL_BLOCKED(0.00)[farnell.com.multi.uribl.com,metebalci.com.multi.uribl.com,protonmail.com.multi.uribl.com]; FROM_HAS_DN(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.69)[ip: (-9.58), ipnet: 185.70.40.0/24(-4.90), asn: 19905(-3.91), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] 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: Thu, 25 Jul 2019 18:23:09 -0000 > Is there some sort of guide or instructions for using a JTAG debugger > on the FreeBSD kernel available somewhere? I haven't seen anything. Once you have the JTAG up and running, it typicall= y presents itself to you as an GDB server, so you connect to it from gdb, a= dd the symbols for your kernel so you can make sense of what's going on, an= d treat it much like a regular executable. I found this page invaluable for the configuration needed to work on the Pi= : https://metebalci.com/blog/bare-metal-raspberry-pi-3b-jtag/#enabling-jtag= -on-raspberry-pi I use this USB-attached JTAG: https://uk.farnell.com/ftdi/c232hm-ddhsl-0/ca= ble-usb-mpsse-0-25a-3-3v-o-p/dp/2352015?CMP=3Di-ddd7-00001003 (on a MacBook= ) You'll need to build openOCD and a version of gdb targeting your intended a= rchitecture. There are a few hoops to jump through but I don't think it's too difficult = at all. Let me know if you get stuck. From owner-freebsd-arm@freebsd.org Fri Jul 26 05:01:23 2019 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 5FDB8B61A1 for ; Fri, 26 Jul 2019 05:01:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1BBC767F3 for ; Fri, 26 Jul 2019 05:01:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x742.google.com with SMTP id s145so38201019qke.7 for ; Thu, 25 Jul 2019 22:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YDcwZXFtT+VHQbb8r6VOTHrpmBhzib5+zuiRrtNg9GI=; b=I6uPyE6VE1tAk6iVrLxD8s9liqrD53Q5SuxRdPBAoWetBUn22XKnbd16pusF7hWHmz Q7d9Q93q0OnNlqzxQGHy2Wob3kYb3JAacR5iMweUQLPpBRsMx93IcPvC8T3CEl1Aoiek t08xn+54ndRLTGz11uJVSXe8M7v6lStX/hodd8LtJxruAnsz+gfIs0OXJEOntk3yOSvl qYzNGgpzcDSyJ6A5XHzA0Dy5X3wi9hadfWZuYkraKYc7LfiMoV9IZjv1ODjMMMIrgY/7 02To4MFvZ4ya4p1hyMiWE4KMCYvQMgX2ADF9xWLWYgfIc8VP3I2eTJfFXCNZk02sYfVt LBnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YDcwZXFtT+VHQbb8r6VOTHrpmBhzib5+zuiRrtNg9GI=; b=kOkNF7WvhNxm4sunN08428os+f7v9CFzP2DLem5hri1JcNp4YjeZlbnXCx48DBrlJQ Aus+WkMaBwDl/eOikXfoeJnXvGxkOJBQdntOTlhNJDaLtM9FS524IPjku9+sy37m0trW +lXue3rXKn8DBurug1/jP7Vz+T4xc6avI/SGCN834JywwkDCTNgyBrmqW81DCXUGBvgG h+H2zJUSMzoJdTIF7pkm2Qbn5bdNZrEtyINih8yWrp7rIXfCM33bjP/FIL5hY5kigoU6 eXHZOg3tt/LuyPbVxVTNLCglNHBhwPoWB4TKzNZqtipTW1m37/jjNHnE6aM7upLcv630 zN6Q== X-Gm-Message-State: APjAAAUm7GhLfhooqQVZ0msGInF1hZegybsxmqhKLPPEi4nm4pFzJuuF 2XtVwwemukrAhUxWvL3ueTNO7tmua/I+26GBzpx/xsAUnfY= X-Google-Smtp-Source: APXvYqwKT2XvB1Gg+K3eeepe6y3vdHhl/nUtA1CeK6/lxirNxZIxhElVAKMxIUqppBBpCHTyiQ/4pMmoIiplIt4e6gw= X-Received: by 2002:ae9:f107:: with SMTP id k7mr63468202qkg.215.1564117281572; Thu, 25 Jul 2019 22:01:21 -0700 (PDT) MIME-Version: 1.0 From: Warner Losh Date: Thu, 25 Jul 2019 23:01:10 -0600 Message-ID: Subject: kernel.tramp* to be removed To: "freebsd-arm@freebsd.org" X-Rspamd-Queue-Id: B1BBC767F3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=I6uPyE6V X-Spamd-Result: default: False [-2.82 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.920,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; URIBL_BLOCKED(0.00)[gappssmtp.com.multi.uribl.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-0.53)[ip: (2.95), ipnet: 2607:f8b0::/32(-3.09), asn: 15169(-2.44), country: US(-0.05)]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[2.4.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.36)[-0.363,0]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" 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: Fri, 26 Jul 2019 05:01:23 -0000 The kernel.tramp* support was for small boards w/o uboot that needed a compression story. These are primarily the early armv4 boards we supported, though a few armv5 boards could use it because they were successor to earlier armv4 boards. Today, both ralink and marvel, the only two remaining armv5 CPUs, use uboot, which has its own compression story. As such, this is dead code and will be removed. It is also getting in the way of having a unified compression story between userland and the kernel, as it's the only semi-working code that uses the old interfaces. Since this is dead code, there will be no deprecation phase. However, it won't be merged to 11.x. I might merge it to stable/12 if we have the same issue when the unified compression code gets merged. Since it's dead code, it can be removed from the branch w/o issue. Before I pull the trigger, I thought I'd post this review: https://reviews.freebsd.org/D21072 and make a 'last call' for people who are interested to object and show that it's actually still in use despite my careful analysis and the word of the closest thing we have to a marvel armv5 maintainer. Please take all feedback to the review. Thanks! Warner From owner-freebsd-arm@freebsd.org Fri Jul 26 09:59:11 2019 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 DBE96BB7EE for ; Fri, 26 Jul 2019 09:59:11 +0000 (UTC) (envelope-from vijaykumar9597@gmail.com) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27E2688792 for ; Fri, 26 Jul 2019 09:59:11 +0000 (UTC) (envelope-from vijaykumar9597@gmail.com) Received: by mail-io1-xd2b.google.com with SMTP id f4so103624810ioh.6 for ; Fri, 26 Jul 2019 02:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ucZUVr9htMGEuT8dR+BYf2Wirn02SNU1+9/vFmg02m8=; b=rIJO1Q71ORXi11mw2omAAFT2p8o/9hcSohKLcjcyMKuB0iGUkpjPEPlfnSo7SflhH+ 7xK4LX5hKJ13lLS97eb2ZXE+nIS+izwRnZVcS5UcvnksadHhgJM+Mk/sTfPY1pePBsn+ cz3jun5HnSJBq3e62Y/dLMjWhHmABsBHk7CNV+cZibZGMS3N8nEtuSmsi5FS1QLwfuN4 1G3UdJwNQXKco8VrE8xCSKi9vI+ggKiuy3rltnaQnrqPPG76kUJAf8bJ7VODoMQs8VHD sLtUAOEgsHMZDbQrJCDYNct+t269HXITVfisHjSGOMhxc4G8Df0lyFP/d0kSByxMwC/2 rB+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ucZUVr9htMGEuT8dR+BYf2Wirn02SNU1+9/vFmg02m8=; b=K2TY8C22HcyLSHeRvKVUnwDUUwM2HN6tlMXEa43W/HRvv09pIlK3aXxbEqHOsBp111 sE1CPlYUT0XAqrOtgEH4+dTTLvnzv4o+1oIfzhbZ97NyNmpzK16MN5EZmvlRotvjNA5F /5S/5VvqIaJEmLuL4V99LpsM2FR9cdKgfQx/gwhv/efn47nau1pDiNoTwgSYY1uuuVA6 ueeddgsQcMDDh/H018xfg18OF8yBNsHQiC7wle/5y+1mjDL/B+pYyrJOxwBN68pcqWEy l0jcrjkjKbsoqgiTxMu5MCEa8Bum/bjVMXocjB1uX9MoACfB7o0lY//tm0in92c/qz8m 2jmQ== X-Gm-Message-State: APjAAAXdn+l+koaMh6MZ7J8EoL4y+2VnKh04IIofcmXHtRZjIgx97hgD 9eSJsfs3lkJQ6zFPDetp5s76nxTluDpCZLIi/uhFSrY2 X-Google-Smtp-Source: APXvYqx/5er+I0wbv2EF1W/3yQN5xG2tPRlcvBWnXp9YPRNN0mO+jICPZtpNCHhRs2mQbnF8dgFPz2mo/kPrHSAst/8= X-Received: by 2002:a05:6638:52:: with SMTP id a18mr97611863jap.75.1564135150363; Fri, 26 Jul 2019 02:59:10 -0700 (PDT) MIME-Version: 1.0 References: <20190720024214.GA56812@bluezbox.com> <20190720055421.GB41013@dendrobates> In-Reply-To: From: Vijay Kumar Banerjee Date: Fri, 26 Jul 2019 15:28:59 +0530 Message-ID: Subject: Re: Question regarding framebuffer driver. To: Sergey Manucharian Cc: Oleksandr Tymoshenko , freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 27E2688792 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=rIJO1Q71; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vijaykumar9597@gmail.com designates 2607:f8b0:4864:20::d2b as permitted sender) smtp.mailfrom=vijaykumar9597@gmail.com X-Spamd-Result: default: False [-5.81 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[b.2.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_SHORT(-0.84)[-0.839,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-1.96)[ip: (-4.21), ipnet: 2607:f8b0::/32(-3.09), asn: 15169(-2.44), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" 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: Fri, 26 Jul 2019 09:59:11 -0000 Hello all! Just wanted to mention that the problem I was facing was related to pinmuxing and it's solved now and the drivers are working. Thanks to Gonzo and Sergey for being so helpful. Thanks and Regards, Vijay