Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Nov 2017 23:16:31 +0100
From:      "Hartmann, O." <ohartmann@walstatt.org>
To:        Hans Petter Selasky <hselasky@FreeBSD.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r326376 - head/sys/kern
Message-ID:  <20171130231627.2eecc273@hermann>
In-Reply-To: <201711292328.vATNSeOM046518@repo.freebsd.org>
References:  <201711292328.vATNSeOM046518@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Nov 2017 23:28:40 +0000 (UTC)
Hans Petter Selasky <hselasky@FreeBSD.org> wrote:

> Author: hselasky
> Date: Wed Nov 29 23:28:40 2017
> New Revision: 326376
> URL: https://svnweb.freebsd.org/changeset/base/326376
> 
> Log:
>   The sched_add() function is not only used when the thread is
> initially started, but also by the turnstiles to mark a thread as
> runnable for all locks, for instance sleepqueues do:
>   setrunnable()->sched_wakeup()->sched_add()
>   
>   In r326218 code was added to allow booting from non-zero CPU numbers
>   by setting the ts_cpu field inside the ULE scheduler's sched_add()
>   function. This had an undesired side-effect that prior sched_pin()
> and sched_bind() calls got disregarded. This patch fixes the
>   initialization of the ts_cpu field for the ULE scheduler to only
>   happen once when the initial thread is constructed during system
>   init. Forking will then later on ensure that a valid ts_cpu value
> gets copied to all children.
>   
>   Reviewed by:	jhb, kib
>   Discussed with:	nwhitehorn
>   MFC after:	1 month
>   Differential revision:	https://reviews.freebsd.org/D13298
>   Sponsored by:	Mellanox Technologies
> 
> Modified:
>   head/sys/kern/sched_ule.c
> 
> Modified: head/sys/kern/sched_ule.c
> ==============================================================================
> --- head/sys/kern/sched_ule.c	Wed Nov 29 21:16:14 2017
> (r326375) +++ head/sys/kern/sched_ule.c	Wed Nov 29 23:28:40
> 2017	(r326376) @@ -1405,7 +1405,6 @@ sched_setup(void *dummy)
>  
>  	/* Add thread0's load since it's running. */
>  	TDQ_LOCK(tdq);
> -	td_get_sched(&thread0)->ts_cpu = curcpu; /* Something valid
> to start */ thread0.td_lock = TDQ_LOCKPTR(TDQ_SELF());
>  	tdq_load_add(tdq, &thread0);
>  	tdq->tdq_lowpri = thread0.td_priority;
> @@ -1642,6 +1641,7 @@ schedinit(void)
>  	ts0->ts_ltick = ticks;
>  	ts0->ts_ftick = ticks;
>  	ts0->ts_slice = 0;
> +	ts0->ts_cpu = curcpu;	/* set valid CPU number */
>  }
>  
>  /*
> @@ -2453,7 +2453,6 @@ sched_add(struct thread *td, int flags)
>  	 * Pick the destination cpu and if it isn't ours transfer to
> the
>  	 * target cpu.
>  	 */
> -	td_get_sched(td)->ts_cpu = curcpu; /* Pick something valid
> to start */ cpu = sched_pickcpu(td, flags);
>  	tdq = sched_setcpu(td, cpu, flags);
>  	tdq_add(tdq, td, flags);
> _______________________________________________
> svn-src-head@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to
> "svn-src-head-unsubscribe@freebsd.org"

The patch doesn't solve problems for me when either tmpfs is used as a
loaded kernel module or compiled into the kernel and the filesystem
contains mount points comprised from tempfs, like /tmp or /var/run.

Any kernel with tmpfs compiled in seems to crash, any kernel, including
GENERIC, seems also to crash when any tempfs is involved.

After nearly two days I managed to boot one box again, figuring that
tempfs triggers a kernel panic.

oh



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171130231627.2eecc273>