Re: Patches to use local APIC timer cause SCHED_ULE panic at boot

On Monday 21 February 2005 03:35 pm, Arjan Van Leeuwen wrote:
> Hey,
>
> The recently committed patches to use the local APIC timer to drive
> the various kernel clocks on SMP machines (by jhb) panic my SMP system
> at boot when
> 1) SCHED_ULE is used instead of SCHED_4BSD
> 2) INVARIANTS_* and WITNESS_* are disabled (I don't know which one is
> the culprit, but if I enable them all the system doesn't panic).
>
> I can't provide a dump, since (I assume) the hard drive isn't
> initialized yet, but I have a debug kernel if that's useful.
>
> Here is the panic:
> Timecounters tick every 1.000 msec
> panic: Thread not on runq.
> cpuid = 0
> KDB: enter: panic
> [thread pid 0 tid 0]
> Stopped at	kdb_enter+0x30: leave
> db> trace
> Tracing pid 0 tid 0 td 0xc0769020
> kdb_enter(c071398d,0,c07147a2,c0c207d4,c1a12f60) at kdb_enter+0x30
> panic(c07147a2,369e99,c0769020,1,c0746120) at panic+0x14e
> sched_switch(c0769020,0,2,b43e27c0,87c7fc) at sched_switch+0x85
> mi_switch(2,0,ffffffff,7fff0000,ffffffff) at mi_switch+0x1d9
> critical_exit(c0c20888,c0c20890,c06e8dfe) at critical_exit+0xbf
> lapic_handle_timer(0) at lapic_handle_timer+0xf5
> Xtimerint(c0c20938,c0714fc7,a,61c2091c,c05c4000) at Xtimerint+0x30
> vsscanf(c0886103,c0714fb3,c0c20a70,c0c20b50,c0564312) at vsscanf+0x1fc
> sscanf(c0886103,c0714fb3,c0c20b24,c0c20a80,c0c20b04) at sscanf+0x1f
> res_find(c0c20bf8,c0c20bd0,c0719124,0,0) at res_find+0x262
> resource_find(c0c20bf8,c0c20bd0,c0719124,0,0) at resource_find+0x67
> resource_find_dev(c0c20bf8,c0719124,c0c20bfc,0,0) at resource_find_dev+0x6a
> if_findindex(c1c1ec00,0,0,0,c0703b9c) at if_findindex+0x126
> if_attach(c1c1ec00,c07044a6,0,0,c074cea0) at if_attach+0x1ac
> lo_clone_create(c074cea0,0,d,0,c074ce88) at lo_create+0x79
> ifc_simple_create(c074cea0,c0c20cf8,10,c07044a6,0) at
> ifc_simple_create+0x66 ifc_simple_attach(c074cea0,c0718afd,0,0,c0777a20) at
> ifc_simple_attach+0x55 if_clone_attach(c074cea0,c0718d90,0,0,c0c20d80) at
> if_clone_attach+0x1cf loop_modevent(c198b8c0,0,0,c28000,c0c20d80) at
> loop_modevent+0x6a
> module_register_init(c074cef4,c1e000,c1ec00,c1e000,0) at
> module_register_init+0x81
> mi_startup() at mi_startup+0xb5
> begin() at begin+0x2c
>
> > addr2line -f -e kernel.debug 0xC055AA15
>
> sched_switch
> /usr/src/sys/kern/sched_ule.c:1362
>
> > addr2line -f -e kernel.debug 0xC054C7A9
>
> mi_switch
> /usr/src/sys/kern/kern_synch.c:366
>
> > addr2line -f -e kernel.debug 0xC055BF9F
>
> critical_exit
> /usr/src/sys/kern/kern_switch.c:596
>
> > addr2line -f -e kernel.debug 0xC06C9E15
>
> lapic_handle_timer
> /usr/src/sys/i386/i386/local_apic.c:657
>
> > addr2line -f -e kernel.debug 0xC06C3180
>
> Xtimerint
> /usr/src/sys/i386/i386/apic_vector.s:138

This doesn't look to be specific to the local APIC timer.  The softclock 
thread should be on a run queue since it was being preempted to via 
critical_exit().  KTR_SCHED traces would probably be helpful.

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org