From owner-freebsd-arm@freebsd.org Fri Jan 31 13:48:45 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 0C3C224092F for ; Fri, 31 Jan 2020 13:48:45 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 488JTm6fDnz4dH8 for ; Fri, 31 Jan 2020 13:48:44 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id D2EA71C9EC for ; Fri, 31 Jan 2020 13:48:44 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f178.google.com with SMTP id c24so5417309qtp.5 for ; Fri, 31 Jan 2020 05:48:44 -0800 (PST) X-Gm-Message-State: APjAAAVakv40+0fHK9Nao6tpDcw11r2y8E5xTXX9V+jCs/WVD8yXqnu8 lDbQUAwvL6EGKOOBr/c1/on+vTHoIb1A/uZzPPE= X-Google-Smtp-Source: APXvYqxtCKyI9b3t4BOwRg6MaNvkcucMptvCeRJzu2VogWvseaSBqyNMsaqv+IowrR6Dzf4s6+J9yiDANJGL5Rquj0U= X-Received: by 2002:ac8:544f:: with SMTP id d15mr10774730qtq.53.1580478524082; Fri, 31 Jan 2020 05:48:44 -0800 (PST) MIME-Version: 1.0 References: <20200123164419.GA81833@www.zefox.net> <20200125153229.GA3768@www.zefox.net> <20200126164211.GB7312@www.zefox.net> <20200130162055.GA21879@www.zefox.net> In-Reply-To: From: Kyle Evans Date: Fri, 31 Jan 2020 07:48:32 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: panic: deadlres_td_sleep_q: possible deadlock detected on RPI3 To: Ralf Wenk Cc: bob prohaska , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" 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 13:48:45 -0000 On Fri, Jan 31, 2020 at 6:26 AM Ralf Wenk wrote: > > 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. > These results should no longer be reproducible in recent loaders -- the effect you're seeing is an extraordinarily long redraw times as that's roughly in the range where serial console in loader was effectively borked. Things were later hashed out such that we use the old console driver for serial in many (most? all?) situations. Thanks, Kyle Evans