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.