Date: Fri, 29 Aug 2003 09:28:23 -0400 From: Mike Tancsa <mike@sentex.net> To: Maxim Konovalov <maxim@macomnet.ru>, ken@freebsd.org Cc: stable@freebsd.org Subject: Re: INVARIANTS panic in -stable Message-ID: <5.2.0.9.0.20030829092645.07ceeb40@209.112.4.2> In-Reply-To: <20030829163808.B93371@news1.macomnet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.2.0.9.0.20030829092645.07ceeb40>