Date: Mon, 19 Mar 2018 16:08:53 -0700 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Ian Lepore <ian@freebsd.org> Cc: Nicola Mingotti <nmingotti@gmail.com>, freebsd-arm@freebsd.org, Udit agarwal <dev.madaari@gmail.com> Subject: Re: 15-march.img hangs at boot on BB-Green Message-ID: <20180319230853.GE1917@FreeBSD.org> In-Reply-To: <1521499996.99081.109.camel@freebsd.org> References: <869c43be-b380-cf06-1b50-cff933d20abe@gmail.com> <1521499996.99081.109.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian, On Mon, Mar 19, 2018 at 04:53:16PM -0600, Ian Lepore wrote: I> Today I finally found some time to do some testing with this. It I> appears to have broken with r328916 on Feb 6. From then through r328981 I> the kernel page faults early in boot. Starting with r328982 the fault I don't think boot pages calculation may affect anything after early boot. I> is fixed but we get this new problem with the "Unable to fill RX queue" I> followed by a hang. The "unable to fill" is caused by an I> m_getcl(M_NOWAIT) returning NULL. The hang is caused by a I> malloc(M_WAITOK) in if_alloc() hanging forever. I> I> The only other useful info I have so far is that this only happens with I> the GENERIC kernel. If you build a kernel using the BEAGLEBONE config I> it boots normally. I> I> I don't really know what to do next to debug further. I can insert a I> kdb_enter() right before the if_alloc() call that hangs, but I don't I> know what to look for in the debugger. Better send panic sequence on console once it already entered if_alloc and started sleeping, and then obtain core. -- Gleb Smirnoff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180319230853.GE1917>