From owner-freebsd-mips@FreeBSD.ORG Mon Jul 9 17:46:24 2007 Return-Path: X-Original-To: freebsd-mips@freebsd.org Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50AD716A46B for ; Mon, 9 Jul 2007 17:46:24 +0000 (UTC) (envelope-from gonzo@univ.kiev.ua) Received: from bugor.portaone.com (bugor.portaone.com [65.61.203.147]) by mx1.freebsd.org (Postfix) with ESMTP id 1012413C489 for ; Mon, 9 Jul 2007 17:46:23 +0000 (UTC) (envelope-from gonzo@univ.kiev.ua) Received: from mail.pbxpress.com ([65.61.203.142] helo=leaf.pbxpress.com) by bugor.portaone.com (8.11.3/8.11.3) with ESMTP (TLSv1:AES256-SHA:256)id 1I7x8S-0005Io-IZ; Mon, 09 Jul 2007 10:34:56 -0700 Received: from [192.168.0.64] (k3-gw.portaone.com [193.28.87.193]) (authenticated bits=0) by leaf.pbxpress.com (8.13.3/8.13.3) with ESMTP id l69HYYac040354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jul 2007 10:34:43 -0700 (PDT) (envelope-from gonzo@univ.kiev.ua) Message-ID: <469271B0.6080800@univ.kiev.ua> Date: Mon, 09 Jul 2007 20:34:40 +0300 From: Oleksandr Tymoshenko User-Agent: Thunderbird 1.5.0.9 (X11/20070115) MIME-Version: 1.0 To: freebsd-mips@freebsd.org References: <755925.61959.qm@web34414.mail.mud.yahoo.com> In-Reply-To: <755925.61959.qm@web34414.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, recieved from customer server pbxpress.com or rt.portaone.com Cc: Subject: Re: Fwd: p4-projects Digest, Vol 209, Issue 11 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 17:46:24 -0000 Neelkanth Natu wrote: > Hi Oleksandr, > > When do you see this Address Error exception? > > I would not expect this to happen as a result of a fork() called from userland because the status > register you restore will have the EXL bit set (since you inherited it from the parent's trap > frame). And as long as the EXL bit is set you are still in the kernel mode irrespective of the > KSU field. > > One place where you might see this is when init is going into usermode for the very first time. > If that is where you get the exception then the right way to fix is to set the EXL bit in > exec_setregs() in machdep.c. That way you don't need duplicate code in fork_trampoline() and > exception_restore_registers(). Thanks for pointing out. You're right it was when init was about to go to user mode for the first time. -- gonzo