From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 1 10:00:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35EE837B401 for ; Fri, 1 Aug 2003 10:00:22 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B0BC43F3F for ; Fri, 1 Aug 2003 10:00:21 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h71H0Jv26616 for ; Fri, 1 Aug 2003 19:00:19 +0200 (MEST) Date: Fri, 1 Aug 2003 19:00:19 +0200 (CEST) From: Harti Brandt To: hackers@freebsd.org Message-ID: <20030801185611.E4685@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: panic in uma_zdestroy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2003 17:00:22 -0000 Hi, with a kernel from yesterday I get a panic on an SMP system when I destroy a zone immediately after creating it. It have a driver (with the probe routine set to return ENXIO) and the following module event function: /* * Module loaded/unloaded */ int en_modevent(module_t mod __unused, int event, void *arg __unused) { switch (event) { case MOD_LOAD: en_vcc_zone = uma_zcreate("EN vccs", sizeof(struct en_vcc), NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); if (en_vcc_zone == NULL) return (ENOMEM); break; case MOD_UNLOAD: uma_zdestroy(en_vcc_zone); break; } return (0); } When I load the module and unload it I get a panic with the following trace: db> trace uma_zfree_internal(c083a200,0,0,0,c627b3c4) at uma_zfree_internal+0xb0 cache_drain(c627b300,1,c030547c,245,c0369740) at cache_drain+0xe3 zone_drain_common(c627b300,1,c030547c,461,0) at zone_drain_common+0x62 zone_dtor(c627b300,f4,0,dad4fc40,c01b0255) at zone_dtor+0x55 uma_zfree_internal(c0369660,c627b300,0,0,dad4fc60) at uma_zfree_internal+0x35 uma_zdestroy(c627b300,dad4fc84,c01adce0,c6302c40,1) at uma_zdestroy+0x2a en_modevent(c6302c40,1,0,c5ea2000,c632c700) at en_modevent+0x4b driver_module_handler(c6302c40,1,c658a804,dad4fcc0,c0183f61) at driver_module_handler+0x120 module_unload(c6302c40,c02f00d9,1f1,0,0) at module_unload+0x1e linker_file_unload(c632c700,0,c02f00d9,31b,c632f250) at linker_file_unload+0x81 kldunload(c6046ab0,dad4fd10,c0309978,3ee,1) at kldunload+0x9b syscall(2f,2f,2f,bfbffd03,bfbffc1c) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (305, FreeBSD ELF32, kldunload), eip = 0x80485b3, esp = 0xbfbff76c, ebp = 0xbfbffbcc --- db> The uma_zfree_internal call is the first one in cache_drain (the one that frees uc_allocbucket). The seconds argument to uma_zfree_internal in the trace above seems rather strange to me. What is the problem here? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org