From owner-freebsd-alpha Sun Jun 27 9:32: 6 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 1AF5A14EC6 for ; Sun, 27 Jun 1999 09:32:02 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id RAA26440; Sun, 27 Jun 1999 17:03:47 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 27 Jun 1999 17:03:46 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: alpha@freebsd.org Subject: Re: Hmm!! In-Reply-To: <19990627155406.CCF9181@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 27 Jun 1999, Peter Wemm wrote: > Peter Wemm wrote: > > Doug Rabson wrote: > > > On Sun, 27 Jun 1999, Peter Wemm wrote: > > [..] > > > > Anybody got any bright ideas about this? (apart from run the memory test > er > > > > in SRM that is..) > > > > > > Maybe the kernel doesn't fit in its memory region? You could try enabling > > > the debug printfs in alpha_init() where it reads the memory cluster > > > information. > > > > Another datapoint: > > > > # /bin/cat > > Jun 27 22:01:19 ashburton /kernel: pid 23490 (cat), uid 0: exited on signal 1 > 1 (core dumped) > > Segmentation fault - core dumped > > # /bin/cat > > foo > > foo > > # > > > > The interesting thing is that according to the coredumps, it consistantly > > appears to die in the first getenv() inside setlocale() when walking the > > environ list. It's being a damn nuisance to check because the slightest > > change makes it work.. ie: under truss or ktrace, gdb, etc, it works fine. > > Multiple different cat binaries all do this - including one I compiled with > > -g - but they only misbehave under /bin/sh. Something funny about the > > environment passing perhaps? > > > > This is on the small kernel BTW, so the size of the kernel seems to affect > > things, but not eliminate the problems. > > > > Cheers, > > -Peter > > This is getting stranger by the minute... > > If I do this to cat.c: > main() { > ... > write(1, "A", 1); > setlocale(LC_CTYPE, ""); > write(1, "A", 1); > ... > Then it works. If I take away either added write() syscall, it fails. > If I change it to this, it works too: > setlocale(LC_CTYPE, ""); > write(1, "A", 1); > > while ((ch = getopt(argc, argv, "benstuv")) != -1) { > write(1, "A", 1); > switch (ch) { > .. even though the second write() is never executed. > > If I compile without optimization, cat seems to work always. This is > bizzare. Why cat? Why with the different kernels does it pick mount_nfs > or sysctl to screw up, and only then when called from /bin/sh. > > I have saved a copy of the (-O) assembler code from a working and non-working > version of cat.c. (reminder: it only fails when run from sh, eg in /etc/rc > or under make.) > > Oh, also, according to the console: > pal VMS PALcode V1.20-5, OSF PALcode V1.22-6 > version V5.1-4 Feb 12 1998 15:40:06 > > If I look at the firmware updates directory, the current 5_4 release is > labelled: > > +++++++++++++++++++++++++++++++++++++++ April 1999 > + AlphaPC 164SX Firmware + > + README-FIRST + > +++++++++++++++++++++++++++++++++++++++ > 1. Latest Firmware Update Revisions > SRM V5.4-1 > VMS PALcode V1.20-6 > Unix PALcode V1.22-6 > > The Unix palcode is the same version, but the SRM release is a newer. Does > it seem worthwhile to try to update SRM? Its worth a try. You should be able to just put the relavent fwupdate.exe onto a floppy and use SRM's fwupdate command. It will read the floppy (extremely slowly) then ask you some silly question about option disks which you should ignore. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message