From owner-freebsd-alpha Mon May 28 11:44:44 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 00D9037B422 for ; Mon, 28 May 2001 11:44:41 -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 OAA02021; Mon, 28 May 2001 14:44:25 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f4SIhtE34208; Mon, 28 May 2001 14:43:55 -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: <15122.40043.23892.164757@grasshopper.cs.duke.edu> Date: Mon, 28 May 2001 14:43:55 -0400 (EDT) To: mjacob@feral.com Cc: "Daniel C. Sobral" , alpha@FreeBSD.ORG Subject: Re: Latest on ' HEADS UP: loader broken' In-Reply-To: References: <3B11B706.E8032F96@newsguy.com> 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 Matthew Jacob writes: > > Matthew Jacob wrote: > > > > > > Your surmise about loader.4th is correct, I believe. > > > > > > The alpha's boot1/loader from after your commits seems to boot my PC164 just > > > fine with the older loader.4th, but chokes on the new one. > > > > > > The relevant diffs in loader.4th are: > > > -------- > > > 49a50,52 > > > > > > > > 256 dictthreshold ! \ 256 cells minimum free space > > > > 2048 dictincrease ! \ 2048 additional cells each time > > > -------- > > > > Oh... This is *NOT* what I expected! > > > > Well, this is now more interesting. > > I gave the loader half again as much heap space *and* doubled the stack > But still, the two dict lines below cause the system to die in > the loader with a bad kernel stack. A bad KSP in the loader may not mean a stack problem. Unless you're using the patches I mailed yesterday, then there is no entry point for memory management faults. This means that you may overflow the stack by jumping to a non-existant entMM trap handler on a memory management trap and you ma end up faulting again when you get there, etc. Another way to workaround this is to avoid the problem altogether by not running any of the forth nonsense. /boot/loader.rc's which are left over from 4.0-RELEASE saved my ass on both of my -current boxes. set isp_no_fwload=0xff set isp_mem_map=0xff set kern.ipc.nmbclusters=8192 set hw.ata.wc=1 autoboot 3 Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message