panic: Assertion td->td_lock == TDQ_LOCKPTR(tdq) failed at /usr/src/sys/kern/sched_ule.c:2137

[Ronald Klop]

On Sat, 02 Jun 2018 23:04:50 +0200, Konstantin Belousov  
<kostikbel at gmail.com> wrote:

> On Sat, Jun 02, 2018 at 02:39:00PM -0600, Warner Losh wrote:
>> On Sat, Jun 2, 2018, 1:32 PM bob prohaska <fbsd at www.zefox.net> wrote:
>>
>> > On Sat, Jun 02, 2018 at 09:14:18AM -0600, Warner Losh wrote:
>> > >
>> > > Do you have r334508? It fixes the OOM falsely triggering.
>> > >
>> > At the moment sources are at 334456, world and kernel are at
>> > 334276.
>> >
>> > Might it be feasible to stop the present buildworld, update
>> > sources and then try to build a new kernel before building
>> > world?
>> >
>>
>> That's recent enough that you should be fine. There might be an lld vs
>> binutils ld issue. There was on i386 recently, but I think it was i386
>> specific. It's a good risk.
>
> This happens on arm64 ?  In fact, try this.
> I did not even compiled the change.
>
> diff --git a/sys/arm64/arm64/swtch.S b/sys/arm64/arm64/swtch.S
> index c9843303b1d..4c2c3aca583 100644
> --- a/sys/arm64/arm64/swtch.S
> +++ b/sys/arm64/arm64/swtch.S
> @@ -165,10 +165,9 @@ ENTRY(cpu_switch)
>  	mov	x0, x19
> 	/*
> -	 * Release the old thread. This doesn't need to be a store-release
> -	 * as the above dsb instruction will provide release semantics.
> +	 * Release the old thread.
>  	 */
> -	str	x2, [x0, #TD_LOCK]
> +	stlr	x2, [x0, #TD_LOCK]
>  #if defined(SCHED_ULE) && defined(SMP)
>  	/* Spin if TD_LOCK points to a blocked_lock */
>  	ldr	x2, =_C_LABEL(blocked_lock)



Thanks, I will try. Is this patch for the TDQ_LOCKPTR assert in the  
subject? Or for the OOM message which hijacked this thread a little bit?
As a data point: my RPI3 paniced again on the TDQ_LOCKPTR this night.

Regards,
Ronald.