W dniu 22.01.2013 20:51, Zach Brown pisze:
It doesn't look like there's any easy answers in the code: no unbalanced
lock and unlocks and nothing scary done while holding the lock. (Some
list traversal, but the traces don't show another cpu stuck spinning on
a corrupt list).
If I had to guess, I'd guess that the lock got corrupted somehow. Maybe
a race that has delayed work run on a freed structure.
Would it be possible to enable some debugging options in the kernel
you're building? DEBUG_LIST, DEBUG_SPINLOCK, and the various lockdep
options (DEBUG_LOCKDEP, PROVE_LOCKING) might raise an alarm that would
shed some light. Hopefully they wouldn't be unusably slow.
- z
We will try to give it a shot. But it might be hard to reproduce. This
problem occurred only once, after one week of very heavy (over)stress
tests. Is it at least possible to confirm, that this is definitely the
BTRFS problem?
Piotr
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
