From owner-freebsd-hackers Mon Mar 3 13:50:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA00603 for hackers-outgoing; Mon, 3 Mar 1997 13:50:49 -0800 (PST) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA00594 for ; Mon, 3 Mar 1997 13:50:44 -0800 (PST) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA19076; Mon, 3 Mar 1997 16:50:11 -0500 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 3 Mar 1997 16:50 EST Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id QAA21228 for ; Mon, 3 Mar 1997 16:34:56 -0500 (EST) Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id QAA24012 for freebsd-hackers@freefall.cdrom.com; Mon, 3 Mar 1997 16:40:31 -0500 (EST) Date: Mon, 3 Mar 1997 16:40:31 -0500 (EST) From: Thomas David Rivers Message-Id: <199703032140.QAA24012@lakes.water.net> To: ponds!freefall.cdrom.com!freebsd-hackers Subject: Follow-up on Terry's suggestion for "dup alloc" problem. Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just to follow-up. Terry suggested I rebuild a kernel without BOUNCE_BUFFERS defined. This sounded like a plausible avenue of investigation, especially since I'm wondering, myself, if something has gone wrong with buffer management. So, I commented out the BOUNCE_BUFFERS from the GENERIC definition. (GENERIC is used by the release makefile to produce the BOOTMFS definition; which is what builds the installation kernel) and rebuilt my kernel. Here's an example compile line. I've cut machdep.c from the log of this build; since it's so dependent on BOUNCE_BUFFERS. You'll notice some reformating to fit in 80 columns: cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -nostdinc -I. -I../.. -I../../sys -I../../../include -DBOOTMFS -DI586_CPU -DI486_CPU -DI386_CPU -DMFS_ROOT=1450 -DUSERCONFIG_BOOT -DMAXCONS=4 -DNFS_NOSERVER -DMFS -DATAPI -DVISUAL_USERCONFIG -DUSERCONFIG -DUCONSOLE -DSCSI_DELAY=15 -DCOMPAT_43 -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DMATH_EMULATE -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000 ../../i386/i386/machdep.c When I ran my test case against this, I still got the corrupted disk block... so, it doesn't appear that BOUNCE_BUFFERS are the problem here. By the way, I did some checking around and did discover BOUNCE_BUFFERS could change things for non-SCSI devices; but the changes would basically be where some buffers are allocated. See machdep.c and vm_machdep.c. The device driver is responsible for "bouncing" a buffer when the situation warrants... Someone else in private mail had suggested removing the -DI586_CPU and -DI486_CPU. I don't think it will matter since the CPU is probed correctly... but I'm willing to give it a shot. Again, for those who are reading this for the first time; this is a 2.1.6.1 install kernel, running on a 386dx with 12 meg of memory. The problem I'm trying to debug is causing a daily "dup alloc" panic on my news server, and it has occurred since 2.1.0... The recent mail archives will have a summary of my current thoughts. Look for "dup alloc" and "daily panic" in the Subject:... - Thanks - - Dave Rivers -