Date: Tue, 6 Aug 1996 21:34:39 +0000 () From: James Raynard <fqueries@jraynard.demon.co.uk> To: Paul Manuel <paul8@cs.mun.ca> Cc: questions@freebsd.org Subject: Re: kernel fails to compile with 64MB RAM Message-ID: <199608062134.VAA04676@jraynard.demon.co.uk> In-Reply-To: <XFMail.960806110328.paul8@garfield.cs.mun.ca> from "Paul Manuel" at Aug 6, 96 10:48:07 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Is there a known problem with machines have 64MB or more of memory? No, except that you need to specify the amount of memory in the kernel config file if you want more than the first 64MB of RAM to be used. > I just purchased two P166 machines with 64MB EDO RAM and both fail with the > same errors when trying to compile the kernel. > > A couple of the errors are: > > ------------- > /kernel: pid 1009 (cc1), uid 0: exited on signal 6 > cc: Internal compiler error: program cc1 got fatal signal 6 > ------------- > > ------------- > assertion "(fragP->ft_next == 0) || ((fregP->fr_next-fr_address - fragP->fr_addr > ess) == fragP->fr_fix)" failed: file "/usr/src/gnu/usr.bin/as/write.c", line 354 > > /kernel: pid 1058 (as), uid 0: exited on signal 6 > cc: Internal compiler error: program as got fatal signal 6 > ------------- Hmm. Not sure what I can say here, except that signal 6 is SIGABRT and an assertion failure normally signifies a "can't happen" situation. Something is getting really screwed up here. > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x88f1163d > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf018ad9c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1277 (make) > interrupt mask = > panic: page fault > > syncing disks... etc > ------------- Was this with version 2.1.5? If so, do 'nm /kernel -n | more' and use send-pr to post the area around f018ad9c to the bugs list, together with the above description and your kernel config file (if you've customised the kernel) and someone *may* be able to track down the problem. If it was 2.1.0 or earlier, it's probably better to upgrade to 2.1.5, as quite a few bugs in the VM system (which is what this appears to be) were fixed in the last release.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608062134.VAA04676>