From owner-freebsd-hackers Sun Feb 15 15:20:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA11145 for freebsd-hackers-outgoing; Sun, 15 Feb 1998 15:20:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA11133 for ; Sun, 15 Feb 1998 15:20:41 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 6071 invoked by uid 1001); 15 Feb 1998 23:20:35 +0000 (GMT) To: tlambert@primenet.com Cc: roberto@keltia.freenix.fr, hackers@FreeBSD.ORG Subject: Re: VM messed: vm_page_free panic problem In-Reply-To: Your message of "Sun, 15 Feb 1998 22:08:49 +0000 (GMT)" References: <199802152208.PAA04157@usr01.primenet.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 16 Feb 1998 00:20:35 +0100 Message-ID: <6069.887584835@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Many other people (myself included) are seeing the exact same problem. > > I had it on a machine with 64 M. Also, I highly doubt that we're all > > having problems with our floppies, caches etc. > > What about cache interaction and the decompression algortihm on > the disk? > > Are you using a processor that writes back or doesn't write back > the cache as a result of changes in the instruction stream? Older > processors do not write back. Newer processors do. This problem > could easily be specific to newer processors and/or newer MMU > chipsets (for example, on my "old" P90's and my Neptune chipset, > I do *not* see this problem). I'm using a PPro-200, 256k cache. The BIOS allows me to set normal (write back) cache, write through cache, and cache disabled. I have just now tried it in all three modes, with the same result: vm_page_free: pindex(12), busy(0), PG_BUSY(0), hold(0) > We need more specific information about the hardware in the damage > path, and not just all the specific information in the world (ie: > 4000 lines of boot messages times 20 people is too much to wade > through). Okay, below I have included the original report I sent. Note that the boot floppy from 3.0-980204-SNAP is okay, while 980206 is not. Also, this happens long after kernel decompression, after I have used the kernel configuration menu to remove various drivers, and after all the hardware has been recognized. The machine has one IBM 6.5 GB EIDE disk, and one IBM 2 GB SCSI disk on NCR 810 controller. The last "device" that is recognized before the panic is npx0. Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- To: toor@dyson.iquest.net Cc: current@FreeBSD.ORG Subject: Re: Any feedback on my recent kernel 'fixes' From: sthaug@nethelp.no Date: Sat, 07 Feb 1998 22:48:07 +0100 Message-ID: <13588.886888087@verdi.nethelp.no> This may or may not be related to the the recent kernel changes, but I'll report them here anyways: boot.flp from 3.0-980206-SNAP (from releng22.freebsd.org) panics at the end of the boot process, with: changing root device to fd0c rootfs is 1440 KByte compiled in MFS vm_page_free: pindex(12), busy(0), PG_BUSY(0), hold(0) panic: vm_page_free: freeing free page boot.flp from 3.0-980204-SNAP works okay. It's very much reproducible - the panic occurs every time :-). The numbers in the parentheses are the same every time. I've tried it on a PPro-200 with 64 mByte memory, and an AMD 5x86-133 with 24 MByte memory. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message