From owner-freebsd-ia64 Mon Sep 3 1:41: 0 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 00BB537B401; Mon, 3 Sep 2001 01:40:54 -0700 (PDT) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f838erM32345; Mon, 3 Sep 2001 01:40:53 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 9E998380A; Mon, 3 Sep 2001 01:40:53 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: ia64@FreeBSD.ORG Cc: jhb@FreeBSD.ORG, dfr@FreeBSD.ORG Subject: Re: ia64 + kse == not happy.. In-Reply-To: <20010902144915.2B512380A@overcee.netplex.com.au> Date: Mon, 03 Sep 2001 01:40:53 -0700 From: Peter Wemm Message-Id: <20010903084053.9E998380A@overcee.netplex.com.au> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I finally solved it. I did a s/proc0/thread0/ in locore.s, forgetting that proc0 is a structure, and thread0 is a pointer that requires indirection. Can somebody explain "rnatloc |= 0x1f8;" in vm_machdep.c:cpu_fork()? Anyway, ia64 + kse is happy so far. Some things I have noticed are missing: setjmp/longjmp() (these look non-trivial given the register stack :-( ) lots and lots and lots of minor things. :-) I have been considering taking a shot at porting loader(8) to run under ski, and have *it* load the kernel via reading via sscdisk style operations.. This should enable us to have better control of our boot environment, symbol tables, etc. I think. :-] Peter Wemm wrote: > After doing an alpha-style conversion of the ia64 code in the kse > tree to get it to build/run, I have run into a brick wall. :-( > > loading kernel.kse... > starting kernel... > Memory descriptor count: 1 > MD 0: type 7 pa 0x200000 cnt 0x4000 > Descriptor 0 contains kernel > Loading chunk before kernel: 0x200 / 0x500 > Loading chunk after kernel: 0x819 / 0x4200 > step 1: > proc0uarea = 0xe000000000200000 > proc0kstack = 0xe000000000201000 > td_pcb = 0xe000000000204920 > td_frame = 0xe0000000002046d0 > pcb_sp = 0xe0000000002046c0 > pcb_bspstore = 0xe000000000201000 > made it to the end of ia64_init > Copyright (c) 1992-2001 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.0-CURRENT #4: Sun Sep 2 07:28:56 PDT 2001 > peter@overcee.netplex.com.au:/home/peter/fbp4/kse/sys/ia64/compile/SIM > real memory = 67108864 (65536K bytes) > Physical memory chunk(s): > 0x00209000 - 0x004fffff, 3108864 bytes (759 pages) > 0x00819000 - 0x041f7fff, 60682240 bytes (14815 pages) > avail memory = 60399616 (58984K bytes) > made it to the end of cpu_startup > linker_preload: in > linker_preload: out > mem: > Calibrating clock(s) ... failed, using firmware default of 0 Hz > > fatal kernel trap: > > trap vector = 0x18 (General Exception) > cr.iip = 0x0 > cr.ipsr = 0x0 > cr.isr = 0x0 > cr.ifa = 0x0 > cr.iim = 0x0 > curthread = 0xe000000000815c20 > pid = 0, comm = swapper > > Stopped at > db> 20000e > ? > > The actual change is at: > http://people.freebsd.org/~peter/p4db/chv.cgi?CH=1344 > > And you can see any other changes at: > http://people.freebsd.org/~peter/p4db/chb.cgi?FSPC=//depot/projects/kse/... > http://people.freebsd.org/~peter/p4db/chb.cgi?FSPC=//depot/projects/kse/sys/i a64/... > > And, as announced elsewhere, the source can be had either from p4 if you > have a freefall account, or from cvsup10.freebsd.org (collection=p4-cvs-all, > release=cvs). > > Key questions and changes: > > Under KSE, the U area is split into two entities. One contains struct user, > and the other contains the kernel stack + pcb. We have been putting > the pcb at the *top* of the kernel stack on alpha / i386 since we have > a grow-down stack and we slip in a guard page underneath it. I did this > on the ia64 as well, but I think it may be a mistake as it looks like the > grow-up and grow-down stacks will collide before then and cause a bigger mess . > This can be easily backed out for testing, I'll try that soon. > > The old code did some odd things like subtracting 16 from the trapframe > for various stack pointers. I'm not quite sure what is going on here > but I tried to preserve it. I'd appreciate it if somebody could look over > the changes to machdep.c / vm_machdep.c etc in this area. > > I would really appreciate it if somebody could look over my *.s changes. > > Any ideas? I'm falling asleep. :-) > > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ia64" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message