From owner-freebsd-alpha Mon May 21 9:17:37 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id A6B8C37B422 for ; Mon, 21 May 2001 09:17:28 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA05821 for ; Mon, 21 May 2001 12:17:28 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f4LGGw002723; Mon, 21 May 2001 12:16:58 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15113.16250.74238.202983@grasshopper.cs.duke.edu> Date: Mon, 21 May 2001 12:16:58 -0400 (EDT) To: freebsd-alpha@freebsd.org Subject: state of -current X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 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 :-( Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message