> 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
