From owner-freebsd-hackers  Mon Feb 15 11:44:30 1999
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA21023
          for freebsd-hackers-outgoing; Mon, 15 Feb 1999 11:44:30 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20977
          for <freebsd-hackers@freebsd.org>; Mon, 15 Feb 1999 11:44:25 -0800 (PST)
          (envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id LAA18828;
	Mon, 15 Feb 1999 11:44:24 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 15 Feb 1999 11:44:24 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199902151944.LAA18828@apollo.backplane.com>
To: freebsd-hackers@FreeBSD.ORG
Subject: inode / exec_map interlock ?
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    I found an interesting interlock situation between what I believe to
    be a program binaries inode and the exec_map.  The machine locked up
    trying to exec new programs.

    This was running a make -j10 buildworld on a machine with 16MB of ram
    configured, while testing my new VM system.  I don't think the lockup is 
    due to my VM system, though.  It took it 7 hours of extremely heavy
    paging before it locked up.

    When I broke the machine out into DDB and did a ps, all of the cc's
    were stuck in 'inode' wait, while a single ld program was stuck in
    'thrd_sleep'.

    I tracked 'thrd_sleep' down to a vm_map lock and the map down to
    the exec_map.  I tracked down the inode lock to the 'cc' program binary.
    The inode had one shared lock and 7 waiters.  The exec_map appears to
    own one shared lock with 6 waiters ( but most of the waiters are due to
    me trying to run other programs before breaking into the DDB ).

    I am guessing that there is an interlock situation with exec_map and
    a program inode where one process locks exec_map followed by the program
    inode, and another locks the program inode followed by exec_map.  But 
    I'm not familiar with that section of the code so I would appreciate
    any help.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message