Date: Mon, 22 Oct 2001 05:35:15 -0700 From: Peter Wemm <peter@wemm.org> To: Doug Rabson <dfr@nlsystems.com> Cc: Marcel Moolenaar <marcel@xcllnt.net>, ia64@FreeBSD.ORG Subject: Re: Hazards [was: Re: cvs commit: src/sys/ia64/ia64 sal.c] Message-ID: <20011022123515.4B9DE3808@overcee.netplex.com.au> In-Reply-To: <Pine.BSF.4.33.0110221100370.76250-100000@herring.nlsystems.com>
index | next in thread | previous in thread | raw e-mail
Doug Rabson wrote:
> On Mon, 22 Oct 2001, Peter Wemm wrote:
>
> > Doug Rabson wrote:
> > > I'm not too worried about performance here - this is just cleaning up the
> > > pointer so that we can do an aligned store in the main loop. I'm just
> > > going to add the stops as Peter suggested. We can revisit this (and all
> > > the other string code) and work on performance later. The whole lot
> > > probably needs rewriting. Perhaps Intel has some sample code...
> >
> > Heh. There was another one in vfork(). This might have been what broke
> > csh (a heavily dependent on vfork()).
>
> Hmm. Csh is a bit happier with the latest set of changes to exception.s
> but it still faults often. I thought there might still be a problem with
> signal delivery. The one case I examined this morning was due to a
> completely trashed set of registers - gp was pointing into the user stack.
>
> I'll try again with the modified vfork and see if it helps.
I didn't get much joy. It sort-of works, but still gets bus errors.
Does exception.s report the cause of the bus-errors? Or does it just
deliver them?
I may have a slightly older kernel than userland.. I've just rebuilt
my box running fully partitioned and everything.
I've just finished a manual world build, my results were:
libkvm - missing kvm_ia64.c (I added one that had stubs for crashdump reading)
savecore - no ok() macros
pnpinfo - no outb() routines
crunchide/exec_aout.h - it seems we dont define the a.out format
sufficiently for this to be happy on ia64. Oh dear, what a shame. :-)
sysinstall - wanted machine/uc_device.h (i386 only, will fix).
pam - all dlopen()'s still seem to be broken
gprof - fails to build
truss/kdump - the usual include file mixups. I didn't put much effort
into resolving this. It probably works with a DESTDIR=/ia64 at build.
libc_r - failed to find some atomic.S file
pppctl - needs libc_r
ppp - needs NOI4B due to the bogus placement of some MI headers in
sys/i386/include
perl - I didn't even try to cross build this.
Aside from perl, libc_r, gprof, pnpinfo, truss/kdump, and the cc/binutils
toolchain I managed to get a complete system build.. even the damn games. :-)
libpam error messages:
....
Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_setcred
Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_acct_mgmt
Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_open_session
Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_close_session
Oct 22 13:03:34 ia64 telnetd[309]: PAM unable to resolve symbol: pam_sm_chauthtok
Oct 22 13:03:34 ia64 telnetd[309]: auth_pam: Module is unknown
Even sshd etc are happy! :-)
peter@overcee[5:17am]~-133> ssh ia64 uname -a
FreeBSD ia64.wemm.org 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Mon Oct 22 01:14:37 PDT 2001 peter@overcee.netplex.com.au:/home/src/sys/ia64/compile/SMALL ia64
I could even run sysinstall on it! :-)
ntpdate causes a console complaint about not being able to set the TODR.
ps doesn't report arguments correctly (I can fix this).
# ps -ax
PID TT STAT TIME COMMAND
0 ?? DLs 0:00.02 (swapper)
1 ?? ILs 0:00.03 (init)
...
304 ?? Is 0:01.15 (sshd)
327 ?? S 0:00.29 (sshd)
335 ?? Is 0:00.02 (rwhod)
328 p0 Ss 0:00.09 (sh)
344 p0 R+ 0:00.01 (ps)
272 d0 Is+ 0:00.03 (getty)
I'd like to pick off a few pending minor commits from the process,
and then start tinkering with something like the EFI native partitioning
format.
Oh, It has been invaluable to have FreeBSD/i386 installed.. I've had
EFI and FreeBSD/i386 on the primary drive (Boot Legacy C:) and FreeBSD/ia64
on its own disk on da1. I've installed this build via writes over
NFS from my build box (eek!). This is very convenient since you can just
run fdisk / sysinstall / newfs etc and create filesystems that the ia64
kernel is quite happy with.
ONE CAVEAT!!! DO NOT INSTALL boot1 AS-IS ON ***ANY*** PARTITION. The
fake fdisk label for dangerously dedicated mode locks up EFI. The only
way to recover is to either blow away the boot1 on another machine, or
do a hot-plug after EFI has started and boot from CD or floppy and let
freebsd reprobe and find the drives.
You can make a working boot1 by zeroing out the bogus fdisk table.
Have I mentioned how much I **HATE** the dangerously dedicated boot support
crud lately? :-)
Also, dont bother installing RELENG_4 on it. It cannot enumerate the pci
busses, so it wont find the scsi controller etc unless it is moved to
the 5V pci slot closest to the cpu. (and then you wont see any other pci
cards). My SDV has a busted onboard ethernet, so I have to use a second
card.
> > I've modified my ia64-final gcc specs file to fix the -D__linux__ etc crap
> > and also put in -x into the asm flags so that gcc/gas will warn about
> > dependency violations. The relevant lines:
>
> Thats a really good idea - I'll do the same in my copy. Incidentally, I've
> experimented with using gcc 3.0.2 to build kernels and they work pretty
> well, at least in SKI. I haven't tried a gcc 3.0.2 kernel on the SDV yet.
And of course take out the overrides in sys/conf/Makefile.ia64.
Overall, I'm really pleased at how well it seems to be running.
We're getting to the point where the only showstopper for self-hosting
is lack of integrated compiler. (That is, aside from the other things
on your TODO list that you posted a few days ago)
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
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011022123515.4B9DE3808>