Date: Fri, 1 Aug 2003 13:32:05 +0000 From: Bosko Milekic <bmilekic@technokratis.com> To: Harti Brandt <brandt@fokus.fraunhofer.de> Cc: hackers@freebsd.org Subject: Re: panic in uma_zdestroy Message-ID: <20030801133205.GA8961@technokratis.com> In-Reply-To: <20030801185611.E4685@beagle.fokus.fraunhofer.de> References: <20030801185611.E4685@beagle.fokus.fraunhofer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
I screwed up... fix coming shortly. Sorry! On Fri, Aug 01, 2003 at 07:00:19PM +0200, Harti Brandt wrote: > > 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 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Bosko Milekic * bmilekic@technokratis.com * bmilekic@FreeBSD.org TECHNOkRATIS Consulting Services * http://www.technokratis.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030801133205.GA8961>