On Wed, Oct 04, 2006 at 04:37:15PM -0400, Kris Kennaway wrote: > When running stress2 I got an unkillable process stuck in the aioprn > state: > > #0 sched_switch (td=0xc5652bd0, newtd=0xc4916a20, flags=1) at atomic.h:265 > #1 0xc0549b96 in mi_switch (flags=1, newtd=0x0) at ../../../kern/kern_synch.c:425 > #2 0xc056baa6 in sleepq_switch (wchan=0x0) at ../../../kern/subr_sleepqueue.c:450 > #3 0xc056bc9b in sleepq_timedwait (wchan=0xc5668c80) at ../../../kern/subr_sleepqueue.c:567 > #4 0xc054959e in msleep (ident=0xc5668c80, mtx=0xc5c6ee0c, priority=76, wmesg=0xc0763914 "aioprn", timo=100) > at ../../../kern/kern_synch.c:207 > #5 0xc05a0597 in aio_proc_rundown (arg=0x0, p=0xc5668b04) at ../../../kern/vfs_aio.c:699 > #6 0xc0524769 in exit1 (td=0xc5652bd0, rv=9) at ../../../kern/kern_exit.c:237 > #7 0xc0545eab in sigexit (td=0xc5652bd0, sig=9) at ../../../kern/kern_sig.c:2883 > #8 0xc0546c3b in postsig (sig=9) at ../../../kern/kern_sig.c:2765 > #9 0xc056e503 in ast (framep=0xed16dd38) at ../../../kern/subr_trap.c:270 > #10 0xc06ff61d in doreti_ast () at ../../../i386/i386/exception.s:284 > > This was from the 'random syscall' test, so chances are there is some > insufficient error handling of invalid data here. FYI, this has recurred, so it seems to be an easy problem to trigger. Kris
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC