Date: Mon, 07 Mar 2016 08:48:10 -0700 From: Ian Lepore <ian@freebsd.org> To: Jukka Ukkonen <jau789@gmail.com>, Hans Petter Selasky <hps@selasky.org> Cc: freebsd-arm <freebsd-arm@FreeBSD.org> Subject: Re: Odd hang during boot on RPI2 for 2 days now Message-ID: <1457365690.13785.179.camel@freebsd.org> In-Reply-To: <56DD9F60.7010509@gmail.com> References: <56D99C2E.4020301@gmail.com> <56DD5DF8.9090700@gmail.com> <56DD6476.80603@selasky.org> <56DD9F60.7010509@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2016-03-07 at 17:33 +0200, Jukka Ukkonen wrote: > On 03/07/16 13:22, Hans Petter Selasky wrote: > > On 03/07/16 11:54, Jukka Ukkonen wrote: > > > > > > Continuing where I previously left with this problem... > > > When I set boot_verbose=1 in loader.conf I got a little > > > more information before the poor RPI2 simply froze. > > > Now the last shown line was... > > > > > > random: harvesting attach, 8 bytes (4 bits) from ukbd0 > > > > > > If I disconnect the USB keyboard and then reconnect it, > > > the kernel prints the normal detach and attach messages, > > > once again returns back to printing the "random: ..." > > > line shown above, and freezes again. > > > > > > > Then I think the init process is waiting for something. Would you > > manage > > to press CTRL+T in the console and see what is printed? > > The ctrl-T trick might work with a keyboard connected via > the serial line pins. With my USB keyboard and HDMI display > combo it doesn't do anything at all. > Surely the system must be waiting for something. Of that I > am quite certain. It does not panic and it keeps reacting to > the USB keyboard being disconnected and connected. Obviously > it is still otherwise fine, at least sort of, but also firmly > stuck waiting an event which either never happens or which > goes undetected for some reason. Part of what's needed to diagnose this problem is dmesg output from a failed boot that is more than 1 or 2 lines snipped out of context. It sounds to me like this has nothing to do with the usb keyboard except for the random coincidence that it is the last usb device to be enumerated. It seems like the system is hung waiting for an interrupt, and there's no reason to think it's necessarily a usb interrupt that's missing. Also, it seems unlikely that ^T will produce any output, because it sounds like init hasn't even started yet, and the low-level console used during boot doesn't respond to ^T/SIGINFO. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1457365690.13785.179.camel>