From owner-freebsd-current Wed Apr 24 3: 8:59 2002 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 98ED037B420; Wed, 24 Apr 2002 03:08:52 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA16676; Wed, 24 Apr 2002 20:08:24 +1000 Date: Wed, 24 Apr 2002 20:09:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson Cc: current@FreeBSD.ORG Subject: Re: panic: clist reservation botch In-Reply-To: Message-ID: <20020424194640.P15424-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 23 Apr 2002, Robert Watson wrote: > This was from the TrustedBSD MAC branch, but it's not clear to me that > this relates to the MAC patches. Have't seen this before; this box is > a pxe-booted NFS-mounted system. Kernel and userland may be out of sync, > but all modules should be in sync. System is on a serial console. This panic was last reported for a USB modem in -RELENG_4.x. I think it is just a missing spltty() in usb there. > Configuring syscons: blanktimepanic: clist reservation botch > cpuid = 1; lapic.id = 01000000 > Debugger("panic") > Stopped at Debugger+0x41: xorl %eax,%eax > db> trace > Debugger(c03de45a) at Debugger+0x41 > panic(c03e429f,c0445620,c8e3f200,c8e3f200,c982ab08) at panic+0xd8 > cblock_free_cblocks(b,c8e3f200,c982ab28,c0274fd8,c8e3f200) at cblock_free_cblocks+0x29 > clist_free_cblocks(c8e3f200,c8e3f238,c8e3f21c,c8e3f200,3) at clist_free_cblocks+0x20 > ttyclose(c8e3f200,c8e3f200,1,c98315a0,c939ca48) at ttyclose+0x44 > ttyclose(c8e3f200,c8e3f200,1,c98315a0,c939ca48) at ttyclose+0x44 > scclose(c049a518,1,2000,c939ca48,c049a518) at scclose+0xd6 > spec_close(c982ab94,c982aba8,c02995ec,c982ab94,c93ab03c) at spec_close+0x11a > spec_vnoperate(c982ab94,c93ab03c,c93ab03c,c0417ee0,c98315a0) at spec_vnoperate+0x15 > vn_close(c98315a0,1,c3f76a00,c939ca48,c982ac08) at vn_close+0x40 > vn_closefile(c93ab03c,c939ca48,c93ab03c,c939ca48,0) at vn_closefile+0x1f > fdrop_locked(c93ab03c,c939ca48,c049cc00,0,c03daa33) at fdrop_locked+0x12c > fdrop(c93ab03c,c939ca48,1,c984b974,8) at fdrop+0x26 > closef(c93ab03c,c939ca48) at closef+0xa0 > fdfree(c939ca48,c982ad20,c939ca48,c982ad20,c939c948) at fdfree+0x80 > exit1(c939ca48,0,c0441740,0,c03db00e) at exit1+0x2af > sys_exit(c939ca48,c982ad20,2813c3f8,2805173c,0) at sys_exit+0x2a > syscall(2f,2f,2f,0,2805173c) at syscall+0x223 > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b > --- syscall (1, FreeBSD ELF, sys_exit), eip = 0x280bb48b, esp = 0xbfbffd5c, ebp = 0xbfbffd88 --- The most important part of the trace is missing here. The panic is in clock_alloc(), which isn't in the trace. In -current, there is only the Giant lock to lock clist allocation. I can't see anywhere where it is missing (exit(2) is not MPSAFE, so Giant should be held in most of the above. Similarly for read(2) and write(2). The upper layer of tty interrupt handlers are not MPSAFE, so Giant should be held in them too. It is also important that free(9) doesn't block or otherwise release Giant. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message