It seems Gavin Atkinson wrote: This looks like a problem in the sound system, as the ATA driver prints the last 'done' line it has finished its resume code, and the trace points at the mixer_reinit func... That the ATA driver then locks in the dump code can have lots of reasons, difficult to tell from the info provided....
> Another panic. Kernel from 19th Dec. Laptop suspended itself (for no > reason), and upon resume got this: (again, laptop could not manage to do > the dump, so this is hand transcribed) > > wakeup from sleeping state (slept 00:02:53) > ata0: resetting devices .. > done > ata1: resetting devices .. > done > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01fb093 > stack pointer = 0x10:0xc874db48 > frame pointer = 0x10:0xc874db68 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 13 (swi6: tty:sio clock) > > Stopped at _mtx_lock_flags + 0x43 cmpl $0xc03d16a0, 0(ebx) > > _mtx_lock_flags() at _mtx_lock_flags+0x43 > mixer_reinit() at > ds_ps_resume() > bus_generic_resume() > bus_generic_resume() > bus_generic_resume() > bus_generic_resume() > bus_generic_resume() > apm_resume() > apm_processevent() > apm_do_suspend() > apm_timeout() > softclock() > ithread_loop() > fork_exit() > fork_trampoline() > > _mtx_lock_flags+0x43 corresponds to the compare of the line > KASSERT(m->mtx_object.lo_class == &lock_class_mtx_sleep, .... > in kern_mutex.c. It looks like m == NULL. > > I can't get any more information sadly, again the machine hung while > trying to reset ther ATA channel for the dump. > > Gavin > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
