[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Another problem
On 11/23/10 16:00, Johnny Billquist wrote:
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
KSP = 0x86bc6a34
ESP = 0x86bc5064
SSP = 0x8220b540
USP = 0x7fffec1c
R = 0x00000001 R = 0x80d960b8
R = 0x00000008 R = 0x00000000
R = 0x00000000 R = 0x86bc6b08
R = 0x8220b540 R = 0x84456000
R = 0x8035793c R = 0x858b8000
R = 0x86bc6b18 R = 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).
Correction: softint_exit is not a routine with an entry mask. The code
actually starts at that address.
Main Index |
Thread Index |