Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2017 16:20:29 -0800
From:      Mark Millard <markmi@dsl-only.net>
To:        Andreas Schwarz <freebsd.asc@strcmp.org>, jeff@FreeBSD.org
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot
Message-ID:  <B15039CD-0266-429D-A602-9868774FFC09@dsl-only.net>
In-Reply-To: <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net>
References:  <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> <4b2420e8899.5992ee2b@mail.schwarzes.net> <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Dec-12, at 3:19 PM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2017-Dec-12, at 2:02 PM, Andreas Schwarz <freebsd.asc at =
strcmp.org> wrote:
>=20
>> On 12.12.17, Mark Millard wrote:
>>=20
>>> I initially jumped from -r326192 to -r326726 and
>>> ended up with a rpi2 that would normally hang
>>> somewhere around release APs being displayed.
>>> (I have had a couple of completed boots but many
>>> dozens of hung-up attempts.) Both a debug kernel
>>> and a non-debug kernel hang the same way.
>>>=20
>>> Bisecting the kernel (holding world -r326726
>>> constant) showed:
>>>=20
>>> -r326346 did not hang (nor did before)
>>> -r326347 and later hung.
>>=20
>> JFYI, the latest kernel (and world) running at one of my=20
>> RPI2-B is r326631, without any issues.
>=20
> Interesting. (By the way: My context
> is with a V1.1 Cortex-A7 based rpi2,
> not V1.2 and Cortex-A53.)
>=20
> I've almost always run the root file
> system being on a USB SSD instead of
> on mmcsd0 . I wonder if that is
> somehow involved since it may be
> unusual. UFS file system.
>=20
> The USB SSD is on a powered hub that
> is in turn plugged into the rpi2.
>=20
> [I had the hang problem before the
> following and after.]
>=20
> The mechanism for holding mmcsd0 in
> failed recently but the ejection
> mechanism still works. So I hold
> in mmcsd0 until after I get a USB
> SSD boot now. (Interrupt boot, unload,
> boot/autoboot, picks up the kernel
> from the USB SSD.)
>=20
> This means that I effectively can
> not avoid the USB SSD any more
> unless I get my hands on a different
> V1.1 rpi2.

Looks like I'll get my hands on a different
rpi2 V1.1 in a few days. So I should then
be able to do reasonable mmcsd0-only
experiments. At least once I find the time.

FYI, in case boot details are involved
in reproducing the problem. . .

On the mmcsd0 I have /boot/loader.conf with:

kern.cam.boot_delay=3D"10000"
vfs.mountroot.timeout=3D"10"

and /etc/fstab with:

/dev/ufs/RPI2rootfs     /               ufs     rw,noatime      1 1
/dev/label/RPI2Aswap    none            swap    sw              0 0
/dev/label/RPI2Aboot    /boot/msdos     msdosfs rw,noatime      0 0

where the /dev/ufs/RPI2rootfs was the USB SSD.

However, I interrupt the loader and unload and
then boot or autoboot. (But the hangs started
before this extra sequence was involved.)

On the USB SSD I have /boot/loader.conf with:

kern.cam.boot_delay=3D"10000"
vfs.mountroot.timeout=3D"10"

and /etc/fstab with:

/dev/da0p1      /               ufs     rw,noatime      1 1
/dev/da0p2      none            swap    sw              0 0


What db> showed does point to things that
-r326347 involve:

chain 32:
thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK
thread 100077 (pid 23, uma) is on a run queue

But for all I know -r326347 could be depending
on something required to be true but not correct
elsewhere in the rpi2 support. I'm not claiming
that -r326347 is wrong, just that it is involved.
I've way to little knowledge to claim to know
what is wrong on the evidence that I have.

I've not yet tried a bpi-m3 Cortex-A7 context or
a pine64+ 2GB or rpi3 Cortex-A53 context. Nor
powerpc64 nor powerpc. At some point I'll get the
time for one or more of these. I've not had amd64
problems in this area.

I may not be able to test the bpi-m3: its barrel
connector for power seems flaky and it is
difficult to keep the board powered for long
periods in recent times.

=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?B15039CD-0266-429D-A602-9868774FFC09>