From owner-freebsd-arm@freebsd.org Fri Jan 31 12:26:23 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0A97123EB0B for ; Fri, 31 Jan 2020 12:26:23 +0000 (UTC) (envelope-from wera0003@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (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 488Gfk0074z4XdJ for ; Fri, 31 Jan 2020 12:26:21 +0000 (UTC) (envelope-from wera0003@hs-karlsruhe.de) Received: from iz-wera-new.hs-karlsruhe.de ([193.196.65.47]) by smtp.hs-karlsruhe.de with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1ixVNM-001b76-FI; Fri, 31 Jan 2020 13:26:20 +0100 Received: from wera0003 (helo=iz-wera-new.HS-Karlsruhe.DE) by iz-wera-new.HS-Karlsruhe.DE with local-esmtp (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1ixVNL-0004Px-Be; Fri, 31 Jan 2020 13:26:19 +0100 X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.6 From: Ralf Wenk To: bob prohaska cc: freebsd-arm@freebsd.org Subject: Re: panic: deadlres_td_sleep_q: possible deadlock detected on RPI3 In-reply-to: <20200130162055.GA21879@www.zefox.net> References: <20200123164419.GA81833@www.zefox.net> <20200125153229.GA3768@www.zefox.net> <20200126164211.GB7312@www.zefox.net> <20200130162055.GA21879@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Jan 2020 13:26:19 +0100 Message-Id: X-Rspamd-Queue-Id: 488Gfk0074z4XdJ X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of wera0003@hs-karlsruhe.de has no SPF policy when checking 193.196.64.25) smtp.mailfrom=wera0003@hs-karlsruhe.de X-Spamd-Result: default: False [5.40 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; IP_SCORE(0.09)[asn: 553(0.48), country: EU(-0.01)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[hs-karlsruhe.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.66)[0.664,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[25.64.196.193.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(0.94)[0.940,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[iz-rpi03@hs-karlsruhe.de,wera0003@hs-karlsruhe.de]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:553, ipnet:193.196.64.0/18, country:EU]; FROM_NEQ_ENVFROM(0.00)[iz-rpi03@hs-karlsruhe.de,wera0003@hs-karlsruhe.de]; RBL_SENDERSCORE(2.00)[25.64.196.193.bl.score.senderscore.com] 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, 31 Jan 2020 12:26:23 -0000 On 2020-01-30 at 8:20 -0800 bob prohaska wrote: > On Sun, Jan 26, 2020 at 08:42:11AM -0800, bob prohaska wrote: > > On Sun, Jan 26, 2020 at 11:31:47AM +0100, Ralf Wenk wrote: > > > > > > I got this panic two times in a row with a r357112 kernel during > > > make installworld at the same place. So it looks like I am able to > > > reproduce it. > > > > > > # panic: deadlres_td_sleep_q: possible deadlock detected for > > > 0xfffffd0000f33560, blocked for 1802833 ticks > > > > > > But I think it is just a symptom of the r356776 changes. > > > > > > > Attempts to reboot are also rebuffed with > > > > cpu_reset failed > > > > leaving a power cycle as the only option, which is new to me. > > > > > > > > Does this give any hints as to what's going on? > > > > > > After doing the update from r356767 to r356776 my system began to > > > show the "cpu_reset failed" message as well. > > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243464 > > > > > > My Pi3 still panics at r357204, but ntp seems to work fine. > One other oddity: During the loader countdown to boot, time > seems to run about 5x slower than it should, each second > on the screen taking about five seconds. The string > deadlres_td_sleep_q turns up in sys/kern/kern_clock.c, > might there be a connection between the panic and the > very slow boot countdown? In my experience this behavior depends on /boot/msdos/EFI/BOOT/bootaa64.efi. How "fast" time is ticking in the loader also depends here if the beastie menu is disabled or not. With bootaa64.efi from 5 of December and disabled beastie menu, time is ticking like realtime. With enabled beastie menu time is jumping. Frequently from -6 seconds to immediately boot. Currently I have three different versions in /boot/msdos/EFI/BOOT. # ls -l /boot/msdos/EFI/BOOT/ total 2592 -rwxr-xr-x 1 root wheel 678200 Dec 5 08:57 bootaa64.efi -rwxr-xr-x 1 root wheel 679064 Nov 27 08:40 bootaa64.efi-new-and-fast -rwxr-xr-x 1 root wheel 645904 Aug 15 16:20 bootaa64.efi-o -rwxr-xr-x 1 root wheel 645904 Aug 15 16:20 bootaa64.efi-old-and-fast # sha256 /boot/msdos/EFI/BOOT/* SHA256 (/boot/msdos/EFI/BOOT/bootaa64.efi) = b8c51a746e9b548a6aaa4918562de95276cea1885d9aa44c5f4384424471802f SHA256 (/boot/msdos/EFI/BOOT/bootaa64.efi-new-and-fast) = 7cf52ccb780f3f61d4cdb3c79e7d769aa60f55508d59ed9e5efab685267355f1 SHA256 (/boot/msdos/EFI/BOOT/bootaa64.efi-o) = ee598fc6e7736f3e26aa3fd30dc3845d4b9e56f74a58d935ff68de1e1ebcc74c SHA256 (/boot/msdos/EFI/BOOT/bootaa64.efi-old-and-fast) = ee598fc6e7736f3e26aa3fd30dc3845d4b9e56f74a58d935ff68de1e1ebcc74c # Ralf