From owner-freebsd-current@FreeBSD.ORG Wed Apr 14 13:26:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AC9E16A4CE for ; Wed, 14 Apr 2004 13:26:55 -0700 (PDT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 331A043D41 for ; Wed, 14 Apr 2004 13:26:55 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465 for ; Wed, 14 Apr 2004 13:26:54 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 503995D07 for ; Wed, 14 Apr 2004 13:26:54 -0700 (PDT) To: current@freebsd.org Date: Wed, 14 Apr 2004 13:26:54 -0700 From: "Kevin Oberman" Message-Id: <20040414202654.503995D07@ptavv.es.net> Subject: More odd behavior with the new PCI code (and, maybe, ata) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 20:26:55 -0000 I have noticed a very odd behavior since the new PCI code went into CVS. I have virtually no real data on the problem and no idea if it's really serious. It's only happened three time, always in single-user mode. 1. boot -s 2. to start sh 3. fsck -p 4. adjkerntz -i 5. swapon -a 6. mount -a -t ufs 7. cd /usr/src These are the only things I am sure of as common. After this, an attempt to run something will simply hang. In mergemaster I had it happen when I tried to do an edit (e b) in a merge. Another time 'make installworld' hung in 'mktemp'. Interrupting the operation (^C) and restarting does not seem to help, but doing some other operation that accesses the disk seems to clear the problem. (E.g. ls /usr/src). Once cleared, the problem never seems to recur. I have not seen it in multi-user mode. I can't imagine what could be causing it, but loss of interrupts from the ata MIGHT explain it. Any suggestions on where to look? /tmp is on real disk, not RAM. (I've seen reports of problems with md's elsewhere.) This is probably not enough information to be useful, but I'll try to collect more information when/if I see it again. I am hoping to find out if it's just me or a more common issue. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634