On Fri, 29 Jul 2016 13:17:42 -0700
John Baldwin <j...@freebsd.org> wrote:

> On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn wrote:
> > Well, now I know that ULE is a prerequiste for EARLY_AP_STARTUP!  I
> > wasn't aware of that.  I prefer BSD and that's the scheduler I did
> > the first tests with.
> > 
> > But with the ULE scheduler the system comes up all the way.
> > 
> > It would be nice if the BSD scheduler could also be modified to
> > work with EARLY_AP_STARTUP.  
> 
> I wasn't able to reproduce your hang with 4BSD, but I think I see a
> possible problem.  Try this:
> 
> diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> index 7de56b6..d53331a 100644
> --- a/sys/kern/sched_4bsd.c
> +++ b/sys/kern/sched_4bsd.c
> @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td)
>        *  - The current thread has a higher (numerically lower) or
>        *    equivalent priority.  Note that this prevents curthread from
>        *    trying to preempt to itself.
> -      *  - It is too early in the boot for context switches (cold is set).
>        *  - The current thread has an inhibitor set or is in the process of
>        *    exiting.  In this case, the current thread is about to switch
>        *    out anyways, so there's no point in preempting.  If we did,
> @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td)
>                       ("maybe_preempt: trying to run inhibited thread"));
>       pri = td->td_priority;
>       cpri = ctd->td_priority;
> -     if (panicstr != NULL || pri >= cpri || cold /* || dumping */ ||
> +     if (panicstr != NULL || pri >= cpri /* || dumping */ ||
>           TD_IS_INHIBITED(ctd))
>               return (0);
>  #ifndef FULL_PREEMPTION
> @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum)
>       if ((!forward_wakeup_enabled) ||
>            (forward_wakeup_use_mask == 0 && forward_wakeup_use_loop == 0))
>               return (0);
> -     if (!smp_started || cold || panicstr)
> +     if (!smp_started || panicstr)
>               return (0);
>  
>       forward_wakeups_requested++;
> 

Thanks, but with this patch the kernel hangs in exactly the same
place as before - after the HPET output.

Maybe I'm missing some kernel option which ULE works around, or
something like that.

-- 
Gary Jennejohn
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to