Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Another problem



On 11/23/10 15:44, Johnny Billquist wrote:
On 11/23/10 15:34, der Mouse wrote:
Looking at top: [...]

Anything I could look at to find out more?

I'd probably start by breaking into ddb on the console and getting a
stack trace of those processes. I'd guess they probably are stuck
waiting for a lock of one sort or another and this should point you
towards which lock is in question. Alternatively, they could be in
userland, in which case the problem is most likely that they're not
getting scheduled, and you should turn your attention to the scheduler
(most likely its locking, since that's what you've been messing with).

Hmm. Well, my locking code is not running here, so this is more or less
pure stock NetBSD-current.

Breaking in to ddb is easy, though. But I'll have to be careful there,
since ddb is very sensitive to any kind of error happening inside ddb,
which will break everything for good. Getting a stack trace is usually
one of those things, so I only get one shot at a stack trace before I
need to reboot.

But I'll see what I can figure out that way. Thanks.
(Oh, and mouse, your MTA is broken. It don't accept mail from me. ;-) )

Hmm. Looking at one of these threads:


db> trace/t 0t22077
Process 22077.1
         PCB contents:
 KSP = 0x86bc6a34
 ESP = 0x86bc5064
 SSP = 0x8220b540
 USP = 0x7fffec1c
 R[00] = 0x00000001       R[06] = 0x80d960b8
 R[01] = 0x00000008       R[07] = 0x00000000
 R[02] = 0x00000000       R[08] = 0x86bc6b08
 R[03] = 0x8220b540       R[09] = 0x84456000
 R[04] = 0x8035793c       R[10] = 0x858b8000
 R[05] = 0x86bc6b18       R[11] = 0x00000000
 AP = 0x86bc6a68
 FP = 0x86bc6a48
 PC = 0x80000733
 PSL = 0x1f0000
 Trap frame pointer: 0x803577b4
Stack traceback :


Nothing on the stack. PC = 0x80000733 is interesting. That's where softint_exit starts (the entry mask is there).
Smells like the process is still in the creation phase.
PSL suggest that all interrupts are locked out for the process as well.

Look at ps in ddb shows:
22077    1 3   0         0           8220b7e0               cron vm_map

vm_map? That would suggest that it's related to a condition variable. Would make sense if it get stuck if that is out of sync though.

More ideas?

        Johnny


Home | Main Index | Thread Index | Old Index