panic in uma_zdestroy

[Bosko Milekic]

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 at fokus.fraunhofer.de, harti at freebsd.org
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 

-- 
Bosko Milekic  *  bmilekic at technokratis.com  *  bmilekic at FreeBSD.org
TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/