On Thu, Aug 09, 2007 at 06:48:42AM +0300, Kostik Belousov wrote: > On Wed, Aug 08, 2007 at 03:59:55PM -0400, Kris Kennaway wrote: > > From stress2's random syscall test: > > > > db> wh > > Tracing pid 45777 tid 100465 td 0xc61b7000 > > kdb_enter(c077f50d,2,c0782352,ed0fab84,2,...) at kdb_enter+0x33 > > panic(c0782352,c0788b88,c5e1107c,20000,0,...) at panic+0xed > > lock_init(c5e1107c,c07c67c4,c0788b88,0,20000) at lock_init+0x8c > > mtx_init(c5e1107c,c0788b88,0,0,79400d31,...) at mtx_init+0x9f > > aio_init_aioinfo(c61c4ab0,c057d463,c07e6520,9579c960,31a964,...) at aio_init_aioinfo+0x4b > > aio_aqueue(c61b7000,79400d31,0,2,1,...) at aio_aqueue+0x8d > > oaio_read(c61b7000,ed0facf8,4,c078503a,c07c2250,...) at oaio_read+0x32 > > syscall(ed0fad38) at syscall+0x14f > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > --- syscall (318, FreeBSD ELF32, oaio_read), eip = 0x280c0969, esp = 0xbfbfe5f0, ebp = 0xbfbfe638 --- > > db> x/s 0xc0782352 > > 0xc0782352: lock "%s" %p already initialized > > db> x/s 0xc0788b88 > > 0xc0788b88: aiomtx > > db> show lock 0xc5e1107c > > class: sleep mutex > > name: aiomtx > > flags: {DEF} > > state: {UNOWNED} > > > > This patch should fix the problem: > > diff --git a/sys/kern/vfs_aio.c b/sys/kern/vfs_aio.c > index 7610da8..47580b6 100644 > --- a/sys/kern/vfs_aio.c > +++ b/sys/kern/vfs_aio.c > _at__at_ -719,6 +719,7 _at__at_ restart: > } > AIO_UNLOCK(ki); > taskqueue_drain(taskqueue_aiod_bio, &ki->kaio_task); > + mtx_destroy(&ki->kaio_mtx); > uma_zfree(kaio_zone, ki); > p->p_aioinfo = NULL; > } > > It seems that you shall use a lot of quickly exit()ing processes all of > them using aio to reliable reproduce the problem. I'll try to see if I can reproduce the panic, later on today. - PeterReceived on Thu Aug 09 2007 - 03:27:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:16 UTC