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