BBB boot failure between r366365 and r366386
Emmanuel Vadot
manu at bidouilliste.com
Wed Oct 7 15:57:49 UTC 2020
On Wed, 7 Oct 2020 15:53:51 +0000 (UTC)
Oskar Holmlund via freebsd-arm <freebsd-arm at freebsd.org> wrote:
> Hello Ed,
>
> > Den onsdag 7 oktober 2020 03:11:55 CEST, Ed Maste <emaste at freebsd.org> skrev:
> > On Tue, 6 Oct 2020 at 14:59, Ed Maste <emaste at freebsd.org> wrote:
> > >
> > > On Mon, 5 Oct 2020 at 15:56, Ed Maste <emaste at freebsd.org> wrote:
> > > >
> > > > On Mon, 5 Oct 2020 at 09:53, Ed Maste <emaste at freebsd.org> 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)...
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>
>
> 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 at .
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 <manu at bidouilliste.com> <manu at freebsd.org>
More information about the freebsd-arm
mailing list