The entire thing reads like a bug -- for each platform critical_exit
can venture into mi_switch with interrupts disabled. On amd64 it just
happens to do it after the count was updated, but still before they
got-reenabled. Other platform also do critical enter/exit dance on
each call instead of
On Mon, 16 Dec 2019, Ryan Libby wrote:
On Mon, Dec 16, 2019 at 7:30 AM Ed Maste wrote:
On Sun, 15 Dec 2019 at 16:27, Jeff Roberson wrote:
Author: jeff
Date: Sun Dec 15 21:26:50 2019
New Revision: 355784
URL: https://svnweb.freebsd.org/changeset/base/355784
Log:
schedlock 4/4
FYI
On Mon, Dec 16, 2019 at 7:30 AM Ed Maste wrote:
>
> On Sun, 15 Dec 2019 at 16:27, Jeff Roberson wrote:
> >
> > Author: jeff
> > Date: Sun Dec 15 21:26:50 2019
> > New Revision: 355784
> > URL: https://svnweb.freebsd.org/changeset/base/355784
> >
> > Log:
> > schedlock 4/4
>
> FYI i386, arm,
On Sun, 15 Dec 2019 at 16:27, Jeff Roberson wrote:
>
> Author: jeff
> Date: Sun Dec 15 21:26:50 2019
> New Revision: 355784
> URL: https://svnweb.freebsd.org/changeset/base/355784
>
> Log:
> schedlock 4/4
FYI i386, arm, arm64, riscv fail to boot now, with "panic: invalid count 2"
Boot logs:
Author: jeff
Date: Sun Dec 15 21:26:50 2019
New Revision: 355784
URL: https://svnweb.freebsd.org/changeset/base/355784
Log:
schedlock 4/4
Don't hold the scheduler lock while doing context switches. Instead we
unlock after selecting the new thread and switch within a spinlock
section
