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.