From owner-freebsd-current Thu Feb 5 00:12:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA09209 for current-outgoing; Thu, 5 Feb 1998 00:12:30 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from home.dragondata.com (toasty@home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA09204 for ; Thu, 5 Feb 1998 00:12:28 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.5/8.8.5) id CAA16013; Thu, 5 Feb 1998 02:11:12 -0600 (CST) From: Kevin Day Message-Id: <199802050811.CAA16013@home.dragondata.com> Subject: Re: Any feedback on my recent kernel 'fixes' In-Reply-To: <199802031320.IAA01433@dyson.iquest.net> from "John S. Dyson" at "Feb 3, 98 08:20:17 am" To: toor@dyson.iquest.net (John S. Dyson) Date: Thu, 5 Feb 1998 02:11:12 -0600 (CST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe current" > Is paging more stable? > > Thanks for any feedback (either way.) > -- > John | Never try to teach a pig to sing, > dyson@freebsd.org | it just makes you look stupid, > jdyson@nc.com | and it irritates the pig. > Things seem a lot better here... I've been rebuilding things here about every 2 days. Still having trouble with identd though. Posted below is the only problem we've had... (note, the nfs server 'home' mentioned below was running just fine, and other clients reported nothing odd during this period. Ditto with the NIS server) It looks like something caused it to go through a long and painful death. :) Also, I didn't touch it. I though that they system should have stopped at the page fault notice, but it kept on going.... The system has 128MB of ram, and averages around 48MB free. More than 200MB of swap, so the 'suggest more swap space' message seems a bit confusing. This kernel was from early on Feb 1st. Feb 1 16:08:27 shell ypbind[128]: NIS server [204.137.237.2] for domain "dragondata.com" not responding Feb 1 16:08:36 shell ypbind[128]: NIS server [204.137.237.2] for domain "dragondata.com" OK Feb 1 16:33:29 shell ypbind[128]: NIS server [204.137.237.2] for domain "dragondata.com" not responding Feb 1 16:33:33 shell ypbind[128]: NIS server [204.137.237.2] for domain "dragondata.com" OK Feb 1 16:34:22 shell /kernel: swap_pager: suggest more swap space: 157 MB Feb 1 16:42:49 shell /kernel: Feb 1 16:42:49 shell /kernel: Feb 1 16:42:49 shell /kernel: Fatal trap 12: page fault while in kernel mode Feb 1 16:42:49 shell /kernel: mp_lock = 00000003; cpuid = 0; lapic.id = 00000000 Feb 1 16:42:49 shell /kernel: fault virtual address = 0x60 Feb 1 16:42:49 shell /kernel: fault code = supervisor read, page not present Feb 1 16:42:49 shell /kernel: instruction pointer = 0x8:0xf01aad9e Feb 1 16:42:49 shell /kernel: stack pointer = 0x10:0xff804e08 Feb 1 16:42:49 shell /kernel: frame pointer = 0x10:0xff804e0c Feb 1 16:42:49 shell /kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Feb 1 16:42:49 shell /kernel: = DPL 0, pres 1, def32 1, gran 1 Feb 1 16:42:49 shell /kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Feb 1 16:42:49 shell /kernel: current process = Idle Feb 1 16:42:49 shell /kernel: interrupt mask = net tty <- SMP: XXX Feb 1 16:43:09 shell ypbind[128]: NIS server [204.137.237.2] for domain "dragondata.com" not responding Feb 1 16:43:15 shell ypbind[128]: NIS server [204.137.237.2] for domain "dragondata.com" OK Feb 1 16:41:15 shell /kernel: nfs server home:/home: not responding Feb 1 16:41:18 shell /kernel: nfs server home:/home: not responding Feb 1 16:41:26 shell ypbind[128]: NIS server [204.137.237.2] for domain "dragondata.com" OK Feb 1 16:42:59 shell ypbind[128]: NIS server [204.137.237.2] for domain "dragondata.com" not responding Feb 1 16:43:53 shell ypbind[128]: NIS server [204.137.237.2] for domain "dragondata.com" not responding Feb 1 16:45:42 shell last message repeated 2 times Feb 1 16:52:00 shell last message repeated 7 times Feb 1 16:52:18 shell /kernel: nfs server home:/home: not responding Feb 1 16:52:21 shell /kernel: vm_fault: pager input (probably hardware) error, PID 6319 failure Feb 1 16:48:05 shell /kernel: pid 4027 (eggdrop), uid 1039: exited on signal 11 (core dumped) Feb 1 17:00:01 shell /kernel: pid 5375 (eggdrop), uid 1039: exited on signal 10 (core dumped) Feb 1 17:00:53 shell /kernel: pid 10158 (irc-2.8.2-EPIC3.), uid 1016: exited on signal 6 (core dumped) Feb 1 17:01:48 shell /kernel: pid 10829 (irc-2.8.2-EPIC3.), uid 1018: exited on signal 4 (core dumped) Feb 1 17:01:49 shell inetd[167]: /usr/local/sbin/identd[14498]: exit status 0x9 Feb 1 17:05:45 shell identd[23155]: getbuf: bad address (00000000 not in f0100000-0xFFC00000) - ofiles Feb 1 17:05:46 shell last message repeated 19 times Feb 1 17:05:47 shell /kernel: nfs server home:/home: not responding Feb 1 17:05:49 shell /kernel: nfs server home:/home: is alive again Feb 1 17:05:44 shell /kernel: pid 26326 (irc-2.8.2-EPIC3.), uid 1087: exited on signal 4 (core dumped) Feb 1 17:05:46 shell identd[28841]: getbuf: bad address (00000000 not in f0100000-0xFFC00000) - ofiles Feb 1 17:05:49 shell last message repeated 19 times Feb 1 17:05:53 shell /kernel: pid 1480 (eggdrop), uid 1081: exited on signal 11 (core dumped) Feb 1 17:05:55 shell /kernel: pid 7319 (irc-2.8.2-EPIC3.), uid 1023: exited on signal 6 (core dumped) Feb 1 17:06:16 shell identd[13193]: k_getuid: ofiles malloc failed Feb 1 17:06:10 shell identd[3512]: k_getuid: ofiles malloc failed Feb 1 17:06:04 shell /kernel: pid 5296 (sh), uid 1049: exited on signal 11 (core dumped) Feb 1 17:06:05 shell /kernel: pid 5264 (sh), uid 1011: exited on signal 11 (core dumped) Feb 1 17:06:19 shell identd[12884]: k_getuid: ofiles malloc failed Feb 1 17:06:49 shell identd[23314]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Feb 1 17:06:49 shell last message repeated 19 times Feb 1 17:07:09 shell syslogd: exiting on signal 15 The NFS link was obviously still working, as certain logs across that link were still being updated up until 17:07. Kevin