RE: Debugging kernel semaphore contention and priority inversion

[Davda, Bhavesh P (Bhavesh)]

> From: Keith Mannthey [mailto:kmannth@xxxxxxxxx] 
> Sent: Wednesday, August 17, 2005 5:33 PM
> 
> On 8/17/05, Davda, Bhavesh P (Bhavesh) <bhavesh@xxxxxxxxx> wrote:
> > Is there a way to know which task has a particular (struct 
> semaphore 
> > *) down()ed, leading to another task's down() blocking on it?
> 
> I would add a field to struct semaphore that tracks the 
> current process.
> In your various up and downs have that field tracks the 
> "current" process. 

Yeah, I thought about that. Unfortunately, it doesn't meet my need for
not Heisenberg'ing the system. I can't instrument the struct semaphore
{} in a running system.

> 
> Do you know what semaphore it is?

Yes. It is an inode->i_sem semaphore for a file being written to by the
high-priority SCHED_FIFO task.

> 
> This way you dump the semaphore you can see what task it is 
> holding it.  Have the module dump the semaphore and you can 
> id the task
>  
> > It would be helpful to get a kernel stacktrace for the culprit too.
> 
> Have you tried sysrq t?  See the Documentation/sysrq.txt file.

This is a headless system.

>  
> How stuck is the system? 
> 
> Keith

Very. Only pingable, but can't login via telnet/ssh/anything. Reason is
the same reason the low priority mystery task is unable to run and
release the held semaphore.

Thanks

- Bhavesh


Bhavesh P. Davda | Distinguished Member of Technical Staff | Avaya |
1300 West 120th Avenue | B3-B03 | Westminster, CO 80234 | U.S.A. |
Voice/Fax: 303.538.4438 | bhavesh@xxxxxxxxx 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/