From owner-freebsd-current Thu Jul 8 11:29:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0B980152F9; Thu, 8 Jul 1999 11:29:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA41802; Thu, 8 Jul 1999 11:28:10 -0700 (PDT) (envelope-from dillon) Date: Thu, 8 Jul 1999 11:28:10 -0700 (PDT) From: Matthew Dillon Message-Id: <199907081828.LAA41802@apollo.backplane.com> To: Jerry Bell Cc: "Brian F. Feldman" , Andrew Gallatin , Stephen McKay , alc@cs.rice.edu, freebsd-current@FreeBSD.ORG Subject: Re: Stuck in "objtrm" - live kernel test to run Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I've traced the code down and I think that there is a good chance that the OBJ_DEAD fix that Alan described may solve the problem. What I think is happening is that a process context is holding a PIP count on the object, then deallocating the object and creating an interlock situation. There is a way we can find out for sure. For any of you with processes stuck in objtrm, see if you can gdb the kernel and get a backtrace of that process to see if it might be in a state where a previous call context is holding a PIP count on the object. gdb -k /kernel /dev/mem ^^ works better if this is a debug kernel but it doesn't have to be. It does have to be the kernel that is currently running. proc (e.g. proc 222) ^^^^ gdb's default radix is 10, but sometimes people change it to 16 so if it complains, you may be typing the number in in the wrong radix. back Note: the process cannot be swapped out, so if you've had a process stuck in objtrm for a long time try doing as "ps axfl" to force it's upages in and then gdb should be able to backtrace it. The 'f' in the ps does that. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message