Partway through the analysis of this system, it became apparent that this crash dump was going to present a bit of a puzzle. Sensing this, we resorted to a little-known trade secret among the kernel gurus. Yes, we grabbed a pad of paper and a pencil and started recording what we were finding. The initial result is the table below. Thread Mutex Symbol Name Owner e18c9ec0 e00ecb34 poll_lock f66d2800 e1bd8ec0 e00ecb34 poll_lock f66d2800 f5ab7400 e00ecb34 poll_lock f66d2800 f5a3ce00 e00ecb34 poll_lock f66d2800 f6756000 e00ecb34 poll_lock f66d2800 f57a1c00 e00ecb34 poll_lock f66d2800 e1b6bec0 e00ecb34 poll_lock f66d2800 f66d2800 f6080f4c (none) e190cec0 e190cec0 f5fbbcf4 (none) f600ec00 f600ec00 f5fde918 abc_top_mutex f66d2800 e18d2ec0 f5fde910 abc_last_mutex f66d2800 f6226e00 f5490308 (none) f572ee00 After we stared at this for a few minutes, it seemed that this Dragon was stuck in what is called a "deadlock condition" or "deadlock chain." To confirm this, we went right back to the pad of paper and started drawing lines and circles, tracking the dependencies. In other words, we needed to see which processes were waiting for which locks which were owned by which processes which were waiting for which locks, and so on. In the end, it turns out that the deadlock involved only three of the processes shown in the table, as drawn here. However, the nine other processes were "hung," waiting around for the deadlock to be resolved. Figure 34-1. Deadlock Condition
How this deadlock condition was created is anyone 's guess. If the system administrator was patient, would the deadlock eventually be resolved? The answer is to that question is "No," thus the name deadlock . |