From owner-freebsd-hackers Mon Mar 27 9:34:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 32E6237B60F for ; Mon, 27 Mar 2000 09:34:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA41640; Mon, 27 Mar 2000 09:34:27 -0800 (PST) (envelope-from dillon) Date: Mon, 27 Mar 2000 09:34:27 -0800 (PST) From: Matthew Dillon Message-Id: <200003271734.JAA41640@apollo.backplane.com> To: Cc: hackers@FreeBSD.ORG Subject: Re: figuring out were an spl lock isn't being freed References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I'm playing with a third party kernel module under 4.0. : :Occasionally the box locks up during extended access to the device it :supports, though the box will respond to pings and other hardware driven :interupts, but will not let loggins happen, and open telnet sessions from :remote hosts freeze. I'm guessing an spltty isn't being freed. What's :the best way to go about figuring out what function isn't freeing the lock :or returning? : :Thanks for any help, : :Joe Orthoefer Enable DDB in the kernel config and when the machine locks up, assuming you aren't running X on the console (or if you are that you can ctl-alt-F? to get back to the a character screen), type ctl-alt-esc to get the DDB prompt. Then do a 'ps' to see what things are hanging on. It probably isn't an spl*() issue. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message