thread_lock vs panic/trap

Can a current thread panic or receive a trap while some other thread holds its thread_lock (the same lock as pointed to by the td_lock)? And a related question, can there be a reason for a thread in panic or kdb context to try to get the thread_lock? Thank you! -- Andriy Gapon

Re: ZFS pool lost

Quoting Stefan Esser s...@freebsd.org (from Thu, 05 May 2011 13:04:59 +0200): Sorry for the follow-up to my own posting, but I noticed, that I left out significant information. The system is an Athlon64 (X2, but was running with SMP disabled at the time) in 32 bit mode (i386) with 4GB RAM

Re: [UPDATE] New Boot-Loader Menu -- version 1.4

On May 5, 2011, at 7:21 PM, Devin Teske wrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Ivan Voras Sent: Thursday, May 05, 2011 8:00 AM To: freebsd-hackers@freebsd.org Subject: Re: [UPDATE] New Boot-Loader

RE: [UPDATE] New Boot-Loader Menu -- version 1.4

-Original Message- From: Warner Losh [mailto:i...@bsdimp.com] Sent: Friday, May 06, 2011 8:31 AM To: Devin Teske Cc: 'Ivan Voras'; freebsd-hackers@FreeBSD.org Subject: Re: [UPDATE] New Boot-Loader Menu -- version 1.4 On May 5, 2011, at 7:21 PM, Devin Teske wrote:

Re: thread_lock vs panic/trap

On Friday, May 06, 2011 5:11:57 am Andriy Gapon wrote: Can a current thread panic or receive a trap while some other thread holds its thread_lock (the same lock as pointed to by the td_lock)? I'm sure it's theoretically possible. If the thread is running just about anywhere and another

function typo in xfs sources

hi there, while experimenting with 'gcc -Wmissing-declarations', i stumbled upon the following typo. it would be nice, if anybody could correct this. thanks in advance. alex -- a13x diff --git a/sys/gnu/fs/xfs/FreeBSD/support/kdb.c b/sys/gnu/fs/xfs/FreeBSD/support/kdb.c index 274f23d..b133dfe