Okay, looks like I might have a *good* one here ... inode hang

[David Schultz]

On Wed, Jul 02, 2003, Marc G. Fournier wrote:
> On Wed, 2 Jul 2003, David Schultz wrote:
> 
> > On Tue, Jul 01, 2003, Marc G. Fournier wrote:
> > [...]
> > > and I have a vmcore to work on here !! :)
> >
> > Yes, this does look promising.  Can you look at
> > *(struct lock *)0x8a4ef300 (the lock the second
> > process is trying to acquire) also?
> 
> (kgdb) print *(struct lock *)0x8a4ef300
> $2 = {lk_interlock = {lock_data = 0}, lk_flags = 2098240, lk_sharecount = 0, lk_waitcount = 2, lk_exclusivecount = 1, lk_prio = 8, lk_wmesg = 0x80263d4a "inode", lk_timo = 6,
>   lk_lockholder = 75285}

Aha!  This points off to another process (pid 75285).  Can you
follow that one, too.  Maybe the trail will simply lead back to
unionfs...

> > It probably points back to the first process, but we might as well be
> > sure.  It might also be interesting to see the ndp arguments to the
> > namei calls, but the problem can probably be tracked down without them.
> 
> How do I do this one?

Just type 'frame N', where N is the number of the frame in which
some function was called with ndp as the argument.  Then 'print
*ndp'.  You only have to do this once for each trace.

BTW, to answer your earlier question, you can ignore the '??'
lines; they have nothing to do with loading modules.  gdb isn't
smart enough to trace across the system call and back into
userland (which is what those frames are), but that doesn't really
matter anyway.