From owner-freebsd-stable@FreeBSD.ORG Fri Apr 22 20:34:44 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09D4016A4CE; Fri, 22 Apr 2005 20:34:44 +0000 (GMT) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53B1743D4C; Fri, 22 Apr 2005 20:34:43 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j3MKYerm003528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 23 Apr 2005 06:34:41 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3MKYd7l020848; Sat, 23 Apr 2005 06:34:40 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3MKYdeW020847; Sat, 23 Apr 2005 06:34:39 +1000 (EST) (envelope-from pjeremy) Date: Sat, 23 Apr 2005 06:34:39 +1000 From: Peter Jeremy To: Kris Kennaway Message-ID: <20050422203439.GH12673@cirb503493.alcatel.com.au> References: <20050422050401.GA57677@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050422050401.GA57677@xor.obsecurity.org> User-Agent: Mutt/1.4.2i cc: stable@freebsd.org cc: sparc64@freebsd.org Subject: Re: Preposterous errno values from kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 20:34:44 -0000 On Thu, 2005-Apr-21 22:04:01 -0700, Kris Kennaway wrote: >I'm getting this on a RELENG_5_4 sparc64 system (e4500): > ># rm -rf * >/bin/rm: Unknown error: 7283. Cute. Does it affect anything other than /bin/rm? Is /bin/rm sane (not some random junk that's confusing the ELF loader)? Is this an SMP system (which might point to locking problems)? If this seems consistent (other than the actual errno reported), the quickest solution would seem to be to use DDB (or kernel GDB) to follow the execution path from execve() until it goes off the rails. -- Peter Jeremy