We often get reports of the form `system is hung with processes stuck in tstile again, must be the same problem as <umpteen zillion issues with symptoms matching that description>'.
Unfortunately, these are usually _not_ the same problem, or even related in more than a superficial way, because `processes stuck in tstile' just means `waiting for a lock'. And there are myriad ways the system might deadlock in that state -- totally independent locking bugs in any subsystem can manifest that way. Fortunately, there's a new ddb command to help track this down and tease apart _which_ subsystems have locking bugs causing the tstiles: show all tstiles show all tstiles/t This goes through each thread (lwp) that's waiting for a lock and prints (a) the lock address, (b) if the lock is owned by another lwp, who owns it, and (c) with the `/t' modifier, a stack trace of the owner. And, unlike `show all locks', it works in non-LOCKDEBUG kernels, so if a production system locks up, `show all tstiles' may still be useful. So next time the system locks up with processes stuck in tstile, try `show all tstiles/t' and see if that helps identify the deadlock!
