sched_pin() versus PCPU_GET

mdf at FreeBSD.org mdf at FreeBSD.org
Thu Aug 5 20:14:39 UTC 2010


>> (gdb) p panic_cpu
>> $9 = 2
>> (gdb) p dumptid
>> $12 = 100751
>> (gdb) p cpuhead.slh_first->pc_allcpu.sle_next->pc_curthread->td_tid
>> $14 = 100751
>>
>> (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next
>> $6 = {
>>   pc_curthread = 0xffffff00716d6960,
>>   pc_cpuid = 2,
>>   pc_spinlocks = 0xffffffff80803198,
>>
>> (gdb) p lock_list
>> $2 = (struct lock_list_entry *) 0xffffffff80803fb0
>>
>> (gdb) p *cpuhead.slh_first->pc_allcpu.sle_next->pc_allcpu.sle_next-
>>pc_allcpu.sle_next
>> $8 = {
>>   pc_curthread = 0xffffff0005479960,
>>   pc_cpuid = 0,
>>   pc_spinlocks = 0xffffffff80803fb0,
>>
>> I.e. we're dumping on CPU 2, but the lock_list pointer that was saved
>> in the dump matches that of CPU 0.
>
> Can you print out the tid's for the two curthreads?  It's not impossible that
> the thread migrated after calling panic.  In fact we force threads to CPU 0
> during shutdown.

dumptid matches the pc_curthread for CPU 2 and is printed above.

The lock_list local variable matches the PCPU for CPU 0, which has tid:

(gdb) p cpuhead.slh_first->pc_allcpu.sle_next->pc_allcpu.sle_next->pc_allcpu.sle_next->pc_curthread->td_tid
$2 = 100005

(gdb) p cpuhead.slh_first->pc_allcpu.sle_next->pc_allcpu.sle_next->pc_allcpu.sle_next->pc_curthread->td_proc->p_comm
$3 = "idle: cpu0\000\000\000\000\000\000\000\000\000"

Note that lock_list->ll_count is now 0, but of course wasn't when we
panic'd.  Also, the panic message showed "exclusive spin mutex sched
lock 0 (sched lock) r = 0 (0xffffffff806cf640) locked @
/build/mnt/src/sys/kern/sys_generic.c:826"; i.e. the lock was for CPU
0 as well.  If we truly were returning to user space with that lock
held it would still be held and we'd still be on CPU 0.

Cheers,
matthew


More information about the freebsd-hackers mailing list