Re: BBB boot failure between r366365 and r366386

On Wed, 7 Oct 2020 15:53:51 +0000 (UTC)
Oskar Holmlund via freebsd-arm <[email protected]> wrote:

> Hello Ed,
> 
> > Den onsdag 7 oktober 2020 03:11:55 CEST, Ed Maste <[email protected]> skrev: 
> > On Tue, 6 Oct 2020 at 14:59, Ed Maste <[email protected]> wrote:
> > >
> > > On Mon, 5 Oct 2020 at 15:56, Ed Maste <[email protected]> wrote:
> > > >
> > > >  On Mon, 5 Oct 2020 at 09:53, Ed Maste <[email protected]> wrote:
> > > > >
> > > > > Sometime after r366365 and up to r366365 BBB stopped booting in the HW
> > > > > test environment.
> > > >
> > > > That should of course be after r366365 and up to (and including)
> > > > r366386.
> > >
> > > Discussed on IRC; the second U-Boot banner comes out ~60s after the
> > > first, which might suggest a watchdog timeout.
> > >
> > > We seem to get stuck after
> > > > random: unblocking device.
> >
> > kevans points out that std.armv7 includes VERBOSE_SYSINIT=0, so
> > verbose sysinits are available with a loader tunable. We get this far:
> > 
> > subsystem 2140000
> >  init_hwpmc(0)... done.
> >  init_dtrace(0)... done.
> >  pmc_soft_ev_register(&pmc___lock_failed)... done.
> >  pmc_soft_ev_register(&pmc___clock_prof)... done.
> >  pmc_soft_ev_register(&pmc___clock_hard)... done.
> >  pmc_soft_ev_register(&pmc___clock_stat)... done.
> > subsystem 2160000
> >   random_fortuna_init_alg(0)... done.
> >   random_harvestq_init(0)... done.
> >   random_harvestq_prime(0)... done.
> >   __stack_chk_init(0)... random: unblocking device.
> > done.
> > subsystem 2180000
> >   mac_init(0)... done.
> > subsystem 21d0000
> >   mac_late_init(0)... done.
> > subsystem 21e0000
> >   vnet0_init(0)... done.
> > subsystem 2200000
> >   proc0_init(0)... done.
> >   shutdown_conf(0)... done.
> > subsystem 2300000
> >   vm_stats_init(0)... done.
> >   uma_startup3(0)... done.
> >   vm_page_init_cache_zones(0)... done.
> > subsystem 2380000
> >   db_capture_sysinit(0)... done.
> > subsystem 2400000
> >   sched_setup(0)... done.
> > subsystem 2480000
> >   ktrace_init(0)...
> > _______________________________________________
> > [email protected] mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "[email protected]"
> 
> 
> I can not reproduce the problem - I have tested r366366 - r366386 and as of today r366515 and all works fine. U-boot is same as yours 2020.07. But i have not tested to netboot the BBB, i have only tested from SD card and from eMMC.
> I can try the kernel and base from the CI builds later.
> 
> //Oskar

 I manage to find the problem with a lot of help from markj@.
 This is due to r364819 (and maybe the -O2 recent switch).
 
This patch fixes it :
diff --git a/sys/kern/subr_vmem.c b/sys/kern/subr_vmem.c
index b99b895233a4..b48ff7f29b63 100644
--- a/sys/kern/subr_vmem.c
+++ b/sys/kern/subr_vmem.c
@@ -697,7 +697,7 @@ vmem_startup(void)
         * arena, which may involve importing a range from the kernel
arena,
         * so we need to keep at least 2 * BT_MAXALLOC tags reserved.
         */
-       uma_zone_reserve(vmem_bt_zone, 2 * BT_MAXALLOC * mp_ncpus);
+       uma_zone_reserve(vmem_bt_zone, 64);
        uma_zone_set_allocf(vmem_bt_zone, vmem_bt_alloc);
 #endif
 }

 Mark is now aware of the issue and I'm sure he will find a correct
patch soon :)

 Cheers,

-- 
Emmanuel Vadot <[email protected]> <[email protected]>
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"