> From: Bruce Evans <b...@optusnet.com.au>
> Sent: Tuesday, April 10, 2018 13:09
> > Here the bug is that UP FreeBSD VM hangs on reboot or power-off, and
> > I'm sure this recent patch (which was committed by Jeff on Mar 26) caused
> > this bug:
> > r331561:Fix a bug introduced in r329612 that slowly invalidates all clean
> > bufs.
> > However, SMP VM with 2 or more CPUs doesn't hang on reboot/power-off
> > according to our tests.
> Actually, r329612 is what causes this bug. I already did the bisection
> to find almost this bug a couple of weeks ago. The hang occurs on amd64
> with 4 CPUs but not on amd64 with 8 CPUs or i386 with 4 or 8 CPUS. I
> just checked that it occurs on i386 with 1 CPU. All on the same machine.
> But r329611 doesn't hang for any of these cases.
So, it looks to me that: r329612 introduced a hang issue, so Jeff made r331561,
trying to fix the issue, but it looks the issue is not completely fixed (at
least for me).
I didn't test r329612.
We noticed our amd64 VM (which has a single CPU) hung . The VM kernel was
built with yesterday's latest kernel code + the default GENERIC kernel config.
However, using the same kernel binary, if we configure 2 or more CPUs
to the VM, the VM doesn't hang on reboot.
If I use the latest code but manually remove the changes made by r331561,
the hang issue with our single-CPU VM will go away.
I hope the info is helpful.
> I still think there is an older bug, but now think it is related. I
> only tested with SCHED_4BSD. For SCHED_4BSD, I suspect that the bug
> is from pinning a thread to a CPU and then stopping that CPU. Pure
> UP has no problems since pinning is null for it. SCHED_4BSD has especially
> special handing for SMP (a separate runq for each CPU. I have been
> SCHED_4BSD and the separate queues mostly get in the way).
I always use the default GENERIC kernel options, so I guess I'm using
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"