Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Jan 2018 22:33:52 -0800
From:      Mark Millard <markmi@dsl-only.net>
To:        bob prohaska <fbsd@www.zefox.net>
Cc:        Freebsd-arm <freebsd-arm@freebsd.org>, Ian Lepore <ian@freebsd.org>
Subject:   Re: RPI2 boot hangs with red light on
Message-ID:  <585E8553-E290-4E6F-B05F-43A58E98F076@dsl-only.net>
In-Reply-To: <2F956676-D79F-473B-88FE-43E452F11B83@dsl-only.net>
References:  <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net> <1515039689.1759.27.camel@freebsd.org> <20180104054236.GA15764@www.zefox.net> <2F956676-D79F-473B-88FE-43E452F11B83@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Jan-3, at 10:08 PM, Mark Millard <markmi@dsl-only.net> wrote:

> On 2018-Jan-3, at 9:42 PM, bob prohaska <fbsd at www.zefox.net> wrote:
>=20
>> On Wed, Jan 03, 2018 at 09:21:29PM -0700, Ian Lepore wrote:
>> . . .
>>=20
>> It looks as if /boot/kernel loads but won't run, and =
/boot/kernel.spare, which
>> formerly ran, no longer does. Curiously, an intermediate kernel, =
which didn't
>> run, now loads and starts but halts with
>>=20
>> ugen0.8: <vendor 0x067b product 0x2303> at usbus0
>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>> da0: <SanDisk Extreme 0001> Removable Direct Access SPC-4 SCSI device
>> da0: Serial Number AA010509160727180727
>> da0: 40.000MB/s transfers
>> da0: 59836MB (122544516 512 byte sectors)
>> da0: quirks=3D0x2<NO_6_BYTE>
>> Release APs
>> WARNING: WITNESS option enabled, expect reduced performance.
>> random: unblocking device.
>> arc4random: no preloaded entropy cache
>> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
>> arc4random: no preloaded entropy cache
>> arc4random: no preloaded entropy cache
>=20
> I've seen this "hang point" on a Pine64+ 2GB
> in the past.
>=20
> Hanging here is something addressed by the
> "UMA limit" part of head -r327485 . Bugzilla
> 224330 has material about it. As I understand
> -r326347 is what broke that specific aspect
> of things. (It had other issues as well,
> and apparently causes some other problem to
> show up that was previous hidden.)
>=20
> As for -r327485:
>=20
> Author: jeff
> Date: Tue Jan  2 04:35:56 2018
> New Revision: 327485
> URL:=20
> https://svnweb.freebsd.org/changeset/base/327485
>=20
>=20
> Log:
>  Fix arc after r326347 broke various memory limit queries.  Use UMA =
features
>  rather than kmem arena size to determine available memory.
>=20
>  Initialize the UMA limit to LONG_MAX to avoid spurious wakeups on =
boot before
>  the real limit is set.
>=20
>  PR:		224330 (partial), 224080
>  Reviewed by:	markj, avg
>  Sponsored by:	Netflix / Dell EMC Isilon
>  Differential Revision:=09
> https://reviews.freebsd.org/D13494
> . . .
>=20
>=20
> The "arc" reference is a ZFS file system handling issue.
>=20
>=20
>=20
> Note: I've no clue for "Timeout poll on interrupt endpoint".
> I've never seen such before.

I found the error message text for "Timeout poll . . ."
in (for example) u-boot/blob/master/drivers/usb/host/dwc2.c
in a routine named submit_int_msg (sometimes with a leading
"_").

I did not find the message in a "grep -r" of /user/src/ .
The above was from web searching.

All I can conclude from these it is it appears that u-boot
code might be generating the messages. I'm not familiar
with any of this material.


=3D=3D=3D
Mark Millard
markmi at dsl-only.net




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?585E8553-E290-4E6F-B05F-43A58E98F076>