Crochet produces boom-boom build

[Karl Denninger]

On 2/8/2017 12:38, Karl Denninger wrote:
> So now I have more questions:
>
> 1. What got broken between 313109 and 313441?  There has to be more than
> one problem for the Pi3 because -HEAD not only blows up in
> /boot/loader.efi but *also* the running system that is produced (since
> if I replace /boot/loader.efi with a working copy I wind up with a panic
> before the system finishes starting up, so the damage isn't limited to
> sys/boot/efi).
>
> 2. I assume the patch on the previous is responsible for silencing the
> lock-order-reversal complaint in the uploaded image.  Maybe.  Probably,
> actually, since I get a complaint after signing in even after the first
> boot (where growfs runs) but don't on the pre-built image.
>
> There isn't much that's been changed in the loader that looks like it
> could bear on this -- the interesting change might be in r313442
> although I don't see why a test for NULL (which is the only change in
> there) would result in the problem.  I'm going to start stepping forward
> in the loader until I get the crash, and take it from there unless one
> of the committers knows what went wrong.
>
BTW whatever it is that is causing this is local to the RPI3 (or at
least machines of the same architecture); I just completed a Crochet
build for the Pi2 from -HEAD and it boots and runs fine, other than
emitting "lock order reversal" warnings.

I'm going to revert JUST the loader directory to 313109, rebuild for the
Pi3, and see what happens.  There are not many revs to the arm64
CPU-dependent code between 313109 and 313441; if I get panics out of the
kernel with the loader reverted, but not the rest of the tree, then I'll
revert the arm64 code back to 313109 and see if it stops them.

This may take a while since I've yet to figure out the magic to get just
the kernel to rebuild on changes (without wiping the entire work
directory) so it's ~1 hour or so a crack per test.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2993 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20170208/619283ab/attachment.bin>