From owner-freebsd-stable Sun Feb 1 06:37:08 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA14860 for stable-outgoing; Sun, 1 Feb 1998 06:37:08 -0800 (PST) (envelope-from owner-freebsd-stable) Received: from conductor.synapse.net (conductor.synapse.net [199.84.54.18]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA14851 for ; Sun, 1 Feb 1998 06:37:02 -0800 (PST) (envelope-from evanc@synapse.net) Received: (qmail 943 invoked from network); 1 Feb 1998 14:36:57 -0000 Received: from cello.synapse.net (HELO cello) (199.84.54.81) by conductor.synapse.net with SMTP; 1 Feb 1998 14:36:57 -0000 Message-ID: <017601bd2f1e$d4ef0340$2844c00a@cello.synapse.net> From: "Evan Champion" To: Subject: Instant trap on make installworld Date: Sun, 1 Feb 1998 09:36:49 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0173_01BD2EF4.EBC50EE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0173_01BD2EF4.EBC50EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0173_01BD2EF4.EBC50EE0 Content-Type: application/octet-stream; name="Timpani" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Timpani" # piano machine "i386" cpu "I586_CPU" ident PIANO maxusers 256 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options DEVFS #devices filesystem options NULLFS #NULL filesystem options SHOW_BUSYBUFS #List buffers that prevent root unmount config kernel root on sd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. controller dpt0 options DPT_MEASURE_PERFORMANCE options DPT_TIMEOUT_FACTOR=4 # This one is MANDATORY. controller scbus0 device sd0 device st0 # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Mandatory, don't remove device npx0 at isa? port "IO_NPX" flags 0x1 irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device de0 device fxp0 pseudo-device loop pseudo-device ether pseudo-device bpfilter 4 pseudo-device log pseudo-device pty 16 # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing # These three options provide support for System V Interface # Definition-style interprocess communication, in the form of shared # memory, semaphores, and message queues, respectively. # options SYSVSHM options SYSVSEM options SYSVMSG ------=_NextPart_000_0173_01BD2EF4.EBC50EE0--