|
List Info
Thread: Re: yamt-idlelwp fallout for mips/cobalt?
|
|
| Re: yamt-idlelwp fallout for
mips/cobalt? |

|
2007-05-24 09:57:44 |
ad NetBSD.org wrote:
> > With options LOCKDEBUG:
> > ---
> > Setting date via ntp.
> > Starting rpcbind.
> > Starting ypbind.
> > Mounting all filesystems...
> > Mutex error: lockdebug_wantlock: locking against
myself
> >
> > lock address : 0x00000000802f35c0 type :
spin
> > shared holds : 0 exclusive:
1
> > shares wanted: 0 exclusive:
1
> > current cpu : 0 last held:
0
> > current lwp : 0x000000008fc95000 last held:
0x000000008fc95700
> > last locked : 0x0000000080171dbc unlocked :
0x000000008016b7d0
> > owner field : 000000000000000000 wait/spin:
0/1
> >
> > panic: LOCKDEBUG
> > Stopped in pid 249.1 (nfsio) at
netbsd:cpu_Debugger+0x4: jr ra
> > bdslot: nop
> > db>
> > ---
> > 0x80171dbc is in ltsleep() and 0x8016b7d0 is in
sleepq_wake().
>
> I wonder, is this is from an interrupt handler and are
the masks are being
> set up properly? E.g. IPL_STATCLOCK should also block
IPL_CLOCK.. I'll take
> a look when I have a moment. Another possibility is
that cpu_switchto is
> returning the wrong value, but it does work on MIPS1
and most of the code
> is common.
Here is (probably) a proper trace (with some ugly hacked
kernel):
---
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
Thu May 24 14:31:29 GMT 2007
swapctl: adding /dev/wd0b as swap device at priority 0
Checking for botched superblock upgrades:Mutex error:
lockdebug_wantlock: locking against myself
lock address : 0x00000000802f51e0 type :
spin
shared holds : 0 exclusive:
1
shares wanted: 0 exclusive:
1
current cpu : 0 last held:
0
current lwp : 0x000000008fc95540 last held:
0x000000008fc95700
last locked : 0x0000000080170bb4 unlocked :
0x0000000080170c4c
owner field : 000000000000000000 wait/spin:
0/1
panic: LOCKDEBUG
Stopped in pid 47.1 (sh) at netbsd:cpu_Debugger+0x4:
jr ra
bdslot: nop
db> tr
cpu_Debugger+4 (8fffe000,802ce630,d,0) ra 8018bde8 sz 0
panic+180 (8fffe000,802ce630,d,0) ra 80184344 sz 48
lockdebug_abort1+70 (8fffe000,802ce630,d,0) ra 80184e68 sz
32
lockdebug_wantlock+1dc (8fffe000,802ce630,d,0) ra 8015ddc8
sz 40
mutex_vector_enter+188 (8fffe000,802ce630,d,0) ra 8016b5ac
sz 48
sleepq_remove+114 (8fffe000,802ce630,d,0) ra 8016b8b0 sz 32
sleepq_unsleep+4c (8fffe000,802ce630,d,0) ra 80179dbc sz 32
softclock+30c (8fffe000,802ce630,d,0) ra 8020efd4 sz 40
softintr_dispatch+d4 (100,802ce630,d,0) ra 8020e304 sz 56
cpu_intr+98 (100,802ce630,d,0) ra 801f7bb4 sz 56
mips3_KernIntr+84 (cc6f0000,3edc9f,3edc5f,0) ra 801f81a0 sz
128
mips3_VCEI+10 (cc6f0000,3edc9f,3edc5f,0) ra 0 sz 0
User-level: pid 47.1
db>
---
I'll check softintr code on cobalt, or around
options MIPS3_ENABLE_CLOCK_INTR.
(BTW, it might be better to make all lockdebug_*()
functions non static for debugging..)
---
Izumi Tsutsui
|
|
| Re: yamt-idlelwp fallout for
mips/cobalt? |

|
2007-05-25 09:51:14 |
I wrote:
> Here is (probably) a proper trace (with some ugly
hacked kernel):
:
> softclock+30c (8fffe000,802ce630,d,0) ra 8020efd4 sz
40
> softintr_dispatch+d4 (100,802ce630,d,0) ra 8020e304 sz
56
> cpu_intr+98 (100,802ce630,d,0) ra 801f7bb4 sz 56
> mips3_KernIntr+84 (cc6f0000,3edc9f,3edc5f,0) ra
801f81a0 sz 128
> mips3_VCEI+10 (cc6f0000,3edc9f,3edc5f,0) ra 0 sz 0
This is not in mips3_VCEI() but at the first instruction of
mips3_lwp_trampoline().
The following patch makes a LOCKDEBUG kernel work,
but I don't know if it's really correct.
---
Izumi Tsutsui
Index: arch/mips/mips/vm_machdep.c
============================================================
=======
RCS file: /cvsroot/src/sys/arch/mips/mips/vm_machdep.c,v
retrieving revision 1.117
diff -u -r1.117 vm_machdep.c
--- arch/mips/mips/vm_machdep.c 17 May 2007 14:51:25
-0000 1.117
+++ arch/mips/mips/vm_machdep.c 25 May 2007 14:47:42 -0000
 -170,7
+170,9 
pcb->pcb_context[MIPS_CURLWP_CARD - 16] =
(intptr_t)l2;/* S? */
pcb->pcb_context[8] = (intptr_t)f; /* SP */
pcb->pcb_context[10] = (intptr_t)lwp_trampoline;/* RA
*/
+#if 0
pcb->pcb_context[11] |= PSL_LOWIPL; /* SR */
+#endif
#ifdef IPL_ICU_MASK
pcb->pcb_ppl = 0; /* machine dependent interrupt mask
*/
#endif
|
|
| mips ddb(4) trace fix |

|
2007-05-25 22:57:47 |
I wrote:
> Here is (probably) a proper trace (with some ugly
hacked kernel):
Is it okay to commit the attached patch to make trace
on ddb(4) work more properly?
Current code in arch/mips/mips/trap.c:stacktrace_subr()
scans "jr ra" (or "jr k0") instruction
to find the
beginning of the current subroutine, but it often fails
because gcc is so aggressive nowadays as to reorder
instruction blocks.
Furthermore, gcc doesn't emit "jr ra" if panic()
is called
at the end of function because it's declared as
__attribute__((__noreturn__)).
I just change it to use symbol table to get address of
functions.
I guess it's a bit ugly but works better than current one..
---
Izumi Tsutsui
---
Index: trap.c
============================================================
=======
RCS file: /cvsroot/src/sys/arch/mips/mips/trap.c,v
retrieving revision 1.211
diff -u -r1.211 trap.c
--- trap.c 25 May 2007 23:58:43 -0000 1.211
+++ trap.c 26 May 2007 03:53:21 -0000
 -772,6
+772,10 
int more, stksize;
unsigned int frames = 0;
int foundframesize = 0;
+#ifdef DDB
+ db_expr_t diff;
+ db_sym_t sym;
+#endif
/* Jump here when done with a frame, to start a new one */
loop:
 -798,9
+802,37 
goto done;
}
+#ifdef DDB
+ /*
+ * Check the kernel symbol table to see the beginning of
+ * the current subroutine.
+ */
+ diff = 0;
+ sym = db_search_symbol(pc, DB_STGY_ANY, &diff);
+ if (sym != DB_SYM_NULL && diff == 0) {
+ /* check func(foo) __attribute__((__noreturn__)) case */
+ instr = kdbpeek(pc - 2 * sizeof(int));
+ i.word = instr;
+ if (i.JType.op == OP_JAL) {
+ sym = db_search_symbol(pc - sizeof(int),
+ DB_STGY_ANY, &diff);
+ if (sym != DB_SYM_NULL && diff != 0)
+ diff += sizeof(int);
+ }
+ }
+ if (sym == DB_SYM_NULL) {
+ ra = 0;
+ goto done;
+ }
+ va = pc - diff;
+#else
/*
* Find the beginning of the current subroutine by
scanning backwards
* from the current PC for the end of the previous
subroutine.
+ *
+ * XXX This won't work well because nowadays gcc is so
aggressive
+ * as to reorder instruction blocks for
branch-predict.
+ * (i.e. 'jr ra' wouldn't indicate the end of
subroutine)
*/
va = pc;
do {
 -818,6
+850,7 
/* skip over nulls which might separate .o files */
while ((instr = kdbpeek(va)) == 0)
va += sizeof(int);
+#endif
subr = va;
/* scan forwards to find stack size and any saved
registers */
---
|
|
[1-3]
|
|