Re: INVARIANTS panic in -stable
From: Mike Tancsa (mike_at_sentex.net)
Date: 08/29/03
- Previous message: Maxim Konovalov: "INVARIANTS panic in -stable"
- In reply to: Maxim Konovalov: "INVARIANTS panic in -stable"
- Next in thread: Maxim Konovalov: "Re: INVARIANTS panic in -stable"
- Reply: Maxim Konovalov: "Re: INVARIANTS panic in -stable"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 29 Aug 2003 09:28:23 -0400 To: Maxim Konovalov <maxim@macomnet.ru>, ken@freebsd.org
Are you using tegge's patch from yesterday ? If so he wrote to me saying,
<tegge-quote>
If you use INVARIANTS then you'll have to comment out the check for
malloc(.., M_WAITOK) being called from interrupts since the latest cam
MFC introduces that kinds of calls. You might want to apply the
enclosed kludge patch to kern_sysctl.c (which changes some M_WAITOK
parameters to M_NOWAIT to allow the kernel to boot with INVARIANTS).
That kludge should not be used on production systems, since it might
cause a panic if you don't have free physical memory when adding nodes
to the sysctl tree.
Running with INVARIANTS is best to trap errors as early as possible,
and for the pmap.c changes, detect some kinds of incorrect use of
pmap_pte() and pmap_pte_quick().
- Tor Egge
Index: kern_sysctl.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.92.2.9
diff -u -r1.92.2.9 kern_sysctl.c
--- kern_sysctl.c 1 May 2003 22:48:09 -0000 1.92.2.9
+++ kern_sysctl.c 28 Aug 2003 20:08:12 -0000
@@ -213,7 +213,7 @@
if (clist == NULL || oidp == NULL)
return(NULL);
- e = malloc(sizeof(struct sysctl_ctx_entry), M_SYSCTLOID, M_WAITOK);
+ e = malloc(sizeof(struct sysctl_ctx_entry), M_SYSCTLOID, M_NOWAIT);
e->entry = oidp;
TAILQ_INSERT_HEAD(clist, e, link);
return (e);
@@ -343,14 +343,14 @@
return (NULL);
}
}
- oidp = malloc(sizeof(struct sysctl_oid), M_SYSCTLOID, M_WAITOK);
+ oidp = malloc(sizeof(struct sysctl_oid), M_SYSCTLOID, M_NOWAIT);
bzero(oidp, sizeof(struct sysctl_oid));
oidp->oid_parent = parent;
SLIST_NEXT(oidp, oid_link) = NULL;
oidp->oid_number = number;
oidp->oid_refcnt = 1;
len = strlen(name);
- newname = malloc(len + 1, M_SYSCTLOID, M_WAITOK);
+ newname = malloc(len + 1, M_SYSCTLOID, M_NOWAIT);
bcopy(name, newname, len + 1);
newname[len] = '\0';
oidp->oid_name = newname;
@@ -359,7 +359,7 @@
if ((kind & CTLTYPE) == CTLTYPE_NODE) {
/* Allocate space for children */
SYSCTL_CHILDREN(oidp) = malloc(sizeof(struct sysctl_oid_list),
- M_SYSCTLOID, M_WAITOK);
+ M_SYSCTLOID, M_NOWAIT);
SLIST_INIT(SYSCTL_CHILDREN(oidp));
} else {
oidp->oid_arg1 = arg1;
@@ -368,7 +368,7 @@
oidp->oid_fmt = fmt;
if (descr) {
int len = strlen(descr) + 1;
- oidp->oid_descr = malloc(len, M_SYSCTLOID, M_WAITOK);
+ oidp->oid_descr = malloc(len, M_SYSCTLOID, M_NOWAIT);
if (oidp->oid_descr)
strcpy((char *)(uintptr_t)(const void
*)oidp->oid_descr, descr);
};
--------------------------------------------------
</tegge-quote>
At 05:21 PM 29/08/2003 +0400, Maxim Konovalov wrote:
>Something committed between 2003.08.24.00.00.00 and
>2003.08.25.00.00.00 GMT triggers a panic:
>
>...
>lpt0: <Printer> on ppbus0
>lpt0: Interrupt-driven port
>ppi0: <Parallel I/O> on ppbus0
>Waiting 10 seconds for SCSI devices to settle
>panic: malloc(M_WAITOK) in interrupt context
>Debugger("panic")
>Stopped at Debugger+0x34: movb $0,in_Debugger.429
>
>db> trace
>Debugger(c0250f5b) at Debugger+0x34
>panic(c024f6a0,c02b2bc8,c1383470,c1383000,80286) at panic+0x70
>malloc(2c,c0286100,0,c0279888,c1383470) at malloc+0x27
>sysctl_add_oid(c1383470,c02b2bc8,ffffffff,c0279838,80000001) at
>sysctl_add_oid+0x7e
>daregister(c1382b80,c0279a9c,6c0800,c0279a9c,80) at daregister+0x18a
>cam_periph_alloc(c0127220,c0126f10,c0127058,c01275bc,c02409fe,0,c1362aa0,c01270e0,80,c0279a9c)
>at cam_periph_alloc+0x1de
>daasync(0,80,c0279cfc,c0279a9c,c0279a9c) at daasync+0x77
>xptsetasyncfunc(c1386e00,c1362ee0,c0279d38,c011f9a6,c1386e00) at
>xptsetasyncfunc+0x66
>xptdefdevicefunc(c1386e00,c0279db4,c1358940,c0279db4,c011fac4) at
>xptdefdevicefunc+0x29
>xptdevicetraverse(c1358980,0,c011faf0,c0279db4,c0279d6c) at
>xptdevicetraverse+0x2a
>xptdeftargetfunc(c1358980,c0279db4,c1341280,c0279db4,c011fa98) at
>xptdeftargetfunc+0x1c
>xpttargettraverse(c1346700,0,c011fac4,c0279db4,c0279da0) at
>xpttargettraverse+0x2b
>xptdefbusfunc(c1346700,c0279db4) at xptdefbusfunc+0x1c
>xptbustraverse(0,c011fa98,c0279db4,2,c011fb88) at xptbustraverse+0x2b
>xpt_for_all_devices(c011fb88,c1362ee0) at xpt_for_all_devices+0x29
>xpt_action(c0279e20,c0279e20,c1362f30,5,2) at xpt_action+0x791
>dainit(c1379800,c138d400,680000,c0279ec0,c01234cf) at dainit+0x7b
>xpt_finishconfig(c1344300,c1379800,0,0,ffffffff) at
>xpt_finishconfig+0x67
>camisr(c029aa70,c0279f18,c0219143,0,10) at camisr+0x1eb
>swi_cambio(0,10,10,10,ffffffff) at swi_cambio+0xd
>doreti_swi(5,52c,1,1bf,0) at doreti_swi+0xf
>idle_loop() at idle_loop+0x1d
>
>I suspect this commit:
>
>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2731799+0+archive/2003/cvs-all/20030824.cvs-all
>
>--
>Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org
>_______________________________________________
>freebsd-stable@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
- Previous message: Maxim Konovalov: "INVARIANTS panic in -stable"
- In reply to: Maxim Konovalov: "INVARIANTS panic in -stable"
- Next in thread: Maxim Konovalov: "Re: INVARIANTS panic in -stable"
- Reply: Maxim Konovalov: "Re: INVARIANTS panic in -stable"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
