On Wed, Nov 17, 2010 at 06:22:33AM +0100, cinap_len...@gmx.de wrote: > > qpc is the just the caller of the last successfull *acquired* qlock. > what we know is that the exportfs proc spins in the q->use taslock > called by qlock() right? this already seems wired... q->use is held > just long enougth to test q->locked and manipulate the queue. also > sched() will avoid switching to another proc while we are holding tas > locks. > I think I'm with you, probably not quite to the same depth of understanding.
> i would like to know which qlock is the kernel is trying to acquire > on behalf of exportfs that is also reachable from the etherread4 > code. > ... and from whatever the other proc is that also contributes to this jam. I don't have the name right in front of me, but I will post it separately. As far as I know it's always those two that interfere with exportfs and usually together, only a short time apart. > one could move: > > up->qpc = getcallerpc(&q); > > from qlock() before the lock(&q->use); so we can see from where that > qlock gets called that hangs the exportfs call, or add another magic > debug pointer (qpctry) to the proc stucture and print it in dumpaproc(). > I think I'll do the latter; even though it's more complex, it can be a useful debugging tool in future. I wouldn't leave in the kernel code, but it would be worth being able to refer to it when the occasion arises. How do you expect this qpctry to be initialised/set? ++L
