> 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