>> The ps instance which is spinning on kernel_flag in proc_root_lookup is
>> what's holding things up.
>> Or is it spinning in proc_lookup() or proc_pid_lookup()? I have a vague
>> feeling that I've seen these traces miss out the innermost stack slot...
>> a) Use CONFIG_SPINLINE, get a new sysrq-T trace
>> b) Enable spinlock debugging
>> c) Try disabling the sched_balance_exec() code.
> Moving that locking around as discussed last night didn't fix it.
> It did last 2.5 cycles of repeated SDET this time instead of 0.5,
> but that might just be coincidence, as the hang looks the same. Got
> a better backtrace out of her this time though ....
> Want me to back out the patch I was pointing fingers at? Or I can
> carry on with the path you suggested above if you think it'll help ...
OK, well backing out dcache_lock-vs-tasklist_lock-take-3.patch does
indeed seem to fix the problem. It's done 5.5 whole cycles now, and
still going strong.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:24 EST