From owner-freebsd-hackers Mon Jan 4 20:16:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA24377 for freebsd-hackers-outgoing; Mon, 4 Jan 1999 20:16:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA24371 for ; Mon, 4 Jan 1999 20:16:29 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id UAA91177; Mon, 4 Jan 1999 20:15:58 -0800 (PST) (envelope-from dillon) Date: Mon, 4 Jan 1999 20:15:58 -0800 (PST) From: Matthew Dillon Message-Id: <199901050415.UAA91177@apollo.backplane.com> To: Terry Lambert Cc: eivind@yes.no (Eivind Eklund), kaleb@ics.com, hackers@FreeBSD.ORG Subject: Re: inetd in realloc(): warning: junk pointer, too low to make sense. References: <199901050401.VAA04572@usr05.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > My 3.0-RELEASE system, up some 17 days, is now doing this when I telnet :> > (or ping, or anything else that uses inetd) to it. (I don't know how long :> > it's been like this, perhaps it explains why my outgoing email seem to :> > be being dropped on the floor. :> > :> > Do I remember correctly that there was some fix for this made shortly :> > before 3.0-RELEASE? Did the fix not make it into 3.0-RELEASE? Before :> > I go snag the LaG inetd sources, will that fix the problem? :> :> This has been fixed recently (last week, I think). Not fixed for :> 3.0-RELEASE. : :This fixes the inetd problem, but doesn't fix the mmap "page corruption" :due to a stale page reference not being revoked properly after a low :swap condition causes clean pages in an mmap'ed image to be reaped out. : : Terry Lambert : terry@lambert.org Dmitrij Tejblum commited a patch to vm/swap_pager.c on December 29th that should fix that problem. Neither David Greenman nor I could quite figure out why it seemed to fix the problem but we speculated that something in vm/vm_fault.c is clearing the vm_page_t dirty bits after the swap code re-set them, resulting in a page incorrectly marked clean. Have you updated your kernel since then? Is the problem still there? If that doesn't fix, my new swap code hopefully will but I don't intend to commit it into the new -stable branch for at least a few months... it will only be in the new -current branch. We'd want to find a solution for the new -stable branch sooner then that. -Matt :--- :Any opinions in this posting are my own and not those of my present :or previous employers. : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message