Date: Thu, 05 Feb 1998 07:16:50 -0800 From: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> To: "evanc-freebsd-stable@freebsd.org"@synapse.net Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Instant trap on make installworld Message-ID: <199802051517.HAA04554@cwsys.cwsent.com> In-Reply-To: Your message of "01 Feb 1998 21:16:17 GMT." <19980201211617.2653.qmail@piano.synapse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> (apologies if this goes out twice; I originally sent this this morning
> but haven't seen it come through yet...)
>
> Configuration:
>
> 2.2.5-STABLE client mounts /usr/obj and /usr/src off a 2.2.5-STABLE server.
> On the server, these directories are on /exports, and are loopback-mounted
> to /usr/obj and /usr/src via NULLFS so that make won't get confused about
> the pathname differences.
>
> The client's make world works great. The problem comes when I go to the
> server, and try to make installworld based on the client's build. During
> the first line of the make, the server panics:
>
> cd /usr/src &&
> PATH=/usr/obj/usr/src/tmp/sbin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/sr
> c/tmp/bin:/usr/obj/usr/src/tmp/usr/bin
> BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple
> COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin
> GCC_EXEC_PREFIX=/usr/obj/usr/src/tmp/usr/lib/
> LD_LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib
> LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib
> CC='cc -nostdinc' /usr/obj/usr/src/tmp/usr/bin/make reinstall
>
> Fatal trap 18: integer divide fault while in kernel mode
> instruction pointer = 0x8:0xf01b00b8
> stack pointer = 0x10:0xefbffdfc
> frame pointer = 0x10:0xefbffe48
> 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 = 196 (make)
> interrupt mask =
> panic: integer divide fault
>
> (IIRC, it isn't always this panic, but it always panics instantly...)
>
> The loopback filesystems seem to work fine for all other purposes, so I'm at
> a loss to explain why the server fails. The only thing I can see is that it
> points all the
>
> FYI, there are a couple reasons why I am not building this on the server.
> The first is that I am forcing myself to treat that box like a NetApp or
> somesuch -- it's just a big disk on the net which I'm not allowed to play
> around with. The other is that for some reason if I do too much on that
> box, it will also panic. I think that the particular -STABLE I put on there
> originally isn't particularly stable :-) but as long as the box is left
> alone, it runs just great as an NFS server. We've verified the RAM and are
> quite sure it isn't a hardware fault. This panic is always something like:
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0x0
> stack pointer = 0x10:0xefbffb48
> frame pointer = 0x10:0xefbffb84
> 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 = 1304 (install)
> interrupt mask =
> panic: page fault
>
> As a side note, is there a way to get this to work with symlinks instead of
> NULLFS?
>
> Attached is my kernel config. The only "odd" thing is that I'm running the
> latest dpt drivers for 2.2.5-STABLE (version 1.2.4). This box was installed
> using January 22's 2.2.5-STABLE snap, and has never successfully been
> updated, due to the above problems.
>
> Evan
There is a bug in nullfs/umapfs or VM (depending on your point of view)
which causes the panic you're describing when the mmap() system call is
used. I put together a patch (kludge) and submitted it as a PR. This
has caused a fair bit of discussion among various develpers and members
of the Core Team.
Bruce Evans subsequently sent me a patch, however this patch was
designed for -current, which is too different in this area of VM to
even attempt to retrofit it into -stable. I suspect that -current will
fix this problem once the VM rewrite is complete.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
UNIX Support OV/VM: BCSC02(CSCHUBER)
ITSD BITNET: CSCHUBER@BCSC02.BITNET
Government of BC Internet: cschuber@uumail.gov.bc.ca
Cy.Schubert@gems8.gov.bc.ca
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802051517.HAA04554>