panic from May
I get the following panic on a GENERIC kernel from around May 23: (copied by hand) /usr/src/sys/kern/kern_synch.c:385: sleeping with vm locked from /usr/src/sys/vm/vm_pager.c:428 panic: sleeping process owns a mutext Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db trace Debugger() panic() propagate_priority() _mtx_lock_sleep() obreak() syscall() syscall_with_err_pushd() this looks a lot like... my system cvsupped around May 25 reliably causes a panic when I $ cp /cdrom/distfiles/somefiles /tmp I've written down the message from the debugger: /usr/src/sys/kern_synch.c:385: sleeping with vm locked from /usr/src/sys/vm/vm_pager.c: 428 panic: sleeping process owns a mutex Debugger(panic) trace Debugger(...) panic() propagate_priority() _mtx_lock_sleep() ffs_write() vn_write() writev() syscall() syscall_with_err_pushed() from the current archives. What can I do get this thing through a make world? Would a recent kernel over the existing userland have any hope between then and now? Thanks. Chad To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from May
On Saturday, 16 June 2001 at 15:22:39 -0600, Chad David wrote: I get the following panic on a GENERIC kernel from around May 23: (copied by hand) /usr/src/sys/kern/kern_synch.c:385: sleeping with vm locked from /usr/src/sys/vm/vm_pager.c:428 panic: sleeping process owns a mutext Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db trace Debugger() panic() propagate_priority() _mtx_lock_sleep() obreak() syscall() syscall_with_err_pushd() this looks a lot like... my system cvsupped around May 25 reliably causes a panic when I $ cp /cdrom/distfiles/somefiles /tmp I've written down the message from the debugger: /usr/src/sys/kern_synch.c:385: sleeping with vm locked from /usr/src/sys/vm/vm_pager.c: 428 panic: sleeping process owns a mutex Debugger(panic) trace Debugger(...) panic() propagate_priority() _mtx_lock_sleep() ffs_write() vn_write() writev() syscall() syscall_with_err_pushed() from the current archives. What can I do get this thing through a make world? Sorry, I don't understand that. Would a recent kernel over the existing userland have any hope between then and now? Maybe. If you're using -CURRENT, you should expect this kind of problem. And we expect that you try to solve it yourself. There are very few people who are interested in problems you might have with a month old -CURRENT. The first thing you should do is update to real -CURRENT sources. Try again. If it still happens, climb into the dump and have a good look round. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from May
A current world with a May 23 kernel works ok, so you may be lucky :) I get the following panic on a GENERIC kernel from around May 23: (copied by hand) /usr/src/sys/kern/kern_synch.c:385: sleeping with vm locked from /usr/src/sys/vm/vm_pager.c:428 panic: sleeping process owns a mutext Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db trace Debugger() panic() propagate_priority() _mtx_lock_sleep() obreak() syscall() syscall_with_err_pushd() this looks a lot like... my system cvsupped around May 25 reliably causes a panic when I $ cp /cdrom/distfiles/somefiles /tmp I've written down the message from the debugger: /usr/src/sys/kern_synch.c:385: sleeping with vm locked from /usr/src/sys/vm/vm_pager.c: 428 panic: sleeping process owns a mutex Debugger(panic) trace Debugger(...) panic() propagate_priority() _mtx_lock_sleep() ffs_write() vn_write() writev() syscall() syscall_with_err_pushed() from the current archives. What can I do get this thing through a make world? Would a recent kernel over the existing userland have any hope between then and now? Thanks. Chad -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
