Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Sep 2015 08:08:36 +0300
From:      Jukka Ukkonen <jau789@gmail.com>
To:        freebsd-arm@FreeBSD.org
Subject:   Root mount on arm
Message-ID:  <560A1CD4.9030600@gmail.com>

next in thread | raw e-mail | index | archive | help

Hello all,

Is there something different in how various actions are ordered
at boot time on ARM and other architectures? In particular is
there a difference in when and how the root file system gets
mounted?

On 10-stable I have been using a patch which allows the stat()
calls to report the true media size of a block device, the true
block count, and true block size for device entries. The whole
thing only requires a few more extra lines in devfs_getattr().
Find the patch here...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197876

Without the patch the media size and the block count are
reported by stat() as zero, and the block size comes out as
4k for all devices no matter what the actual block size is.
The original setup has been much like yet another Volkswagen
cheating during the inspection.

The patch has worked just fine independent of the architecture.
During the last few months I have been using this modification
on amd64 and ppc only, though.

When I decided to test the same modification on arm I used
11-current instead of 10-stable. To my surprise the boot was
interrupted with a complaint that the SD card device from which
the root file system should have been mounted was locked/held
by some other part of the kernel. Apparently this unexpected
reaction was triggered by g_topology_assert() which is called
from within g_dev_getprovider().

Now I am not quite sure whether this happens only on arm or
is it 11-current in general. I will be able to test with
11-current on another architecture only after a week from
now or so. Because I cannot do anything else to solve this
mystery at the time I decided to try the swarm intelligence.
Maybe someone on the list remembers the details of boot time
actions on arm well enough to tell whether the interrupted
boot could be due to some arm specific differences in how
things are ordered during the boot.

Cheers,
--jau



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?560A1CD4.9030600>