From owner-freebsd-alpha Mon May 21 11:12:23 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 2DE3B37B43F for ; Mon, 21 May 2001 11:12:16 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f4LIBeG45360; Mon, 21 May 2001 11:11:40 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15113.16250.74238.202983@grasshopper.cs.duke.edu> Date: Mon, 21 May 2001 11:11:46 -0700 (PDT) From: John Baldwin To: Andrew Gallatin Subject: RE: state of -current Cc: freebsd-alpha@FreeBSD.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 21-May-01 Andrew Gallatin wrote: > > I just committed some fixes which should get alpha booting again after > Alfred's vm_mtx introduction. Alpha has not been heavily tested with > the vm_mtx. > > Note that I did not remove Giant from the fault path in trap -- my > goal was to get the system to boot and be stable, not to improve > performance. If somebody else would like to do this, please go ahead. > > When doing this, I noticed that non-SMP alpha kernels will no longer > boot multi-user due to a recently forked process showing up a > 'curproc' during a hardclock intr. The process hasn't been fully > setup and accessing some fields in its proc struct causes a trap with > a stack like this: > > hardclock_process() at hardclock_process+0xc0 > hardclock() at hardclock+0x11c > handleclock() at handleclock+0x22c > alpha_clock_interrupt() at alpha_clock_interrupt+0x48 > interrupt() at interrupt+0xa8 > XentIntlgp() at XentIntlgp+0x14 > > The fault in hardclock_process is from accessing > &pstats->p_timer[ITIMER_PROF].it_value. Many fields in this proc are > null, including p->p_addr (which causes an essentially recursive fault > in trap, leading to a KSP not valid halt). > > This is almost certainly due to some of the SMP integration work. I > just noticed it yesterday and don't have time to track it down more > than this. So, if you're going to use alpha on -current, use an SMP > kernel for now :-( Well, my alpha is running a UP kernel that is after the last big SMP commmit where I shuffled things around to MI places and what not. Right now I'm still trying to review Alfred's patch. Once vm is back to working at all I'll try and look at this one as it may be my fault. > Drew -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message