From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <215c4028dc0c6d0cdcda7fd23830bc70@proxima.alt.za>
To: 9fans@9fans.net
From: Lucio De Re <lucio@proxima.alt.za>
Date: Thu, 18 Nov 2010 07:50:49 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] That deadlock, again
Topicbox-Message-UUID: 843ff0d0-ead6-11e9-9d60-3106f5b1d025

> 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().


Cinap, I tried your debugging code and got an odd panic at boot time.
Consistently:

	panic: kernel fault: no user process pc=0xf01e739e addr=0x000009e8

Having a look with acid, this seems to be caused by an attempt at
setting the debug PC (your "up->qpctry") at a time when "up" has no
value yet.

Strangely, later in the qlock() code "up" is checked and a panic
issued if zero.  I'm missing something here: it is possible to execute
this code

/sys/src/9/port/qlock.c:29,37 (more or less)
	lock(&q->use);
	rwstats.qlock++;
	if(!q->locked) {
		q->locked = 1;
		unlock(&q->use);
		return;
	}

which is immediately followed by

	if(up == 0)
		panic("qlock");

If "up" is nil, but it looks like a bit of a one-way operation.

Anyway, I have moved the assignment to "qpctry" to after "up" is
tested.  Let's see what happens.  I'll have to get back to you once
the system is back up.

++L