From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 12:45:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0E0E16A4D2; Fri, 2 Apr 2004 12:45:41 -0800 (PST) Received: from siamese.3ware.com (siamese.3ware.com [67.122.122.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6191443D39; Fri, 2 Apr 2004 12:45:41 -0800 (PST) (envelope-from vkashyap@3WARE.com) Received: by siamese with Internet Mail Service (5.5.2653.19) id <2DS0AAX4>; Fri, 2 Apr 2004 12:49:33 -0800 Message-ID: From: Vinod Kashyap To: 'Poul-Henning Kamp' Date: Fri, 2 Apr 2004 12:49:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" cc: freebsd-bugs@freebsd.org cc: 'Artem Koutchine' cc: freebsd-current@freebsd.org Subject: RE: there is a bug in twe driver or disk subsystem for sure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2004 20:45:42 -0000 I was wondering what, if anything, in the original message points at the 3ware driver! How is it being assumed that the 3ware driver is re-using freed memory? Any logs? -----Original Message----- From: Poul-Henning Kamp [mailto:phk@phk.freebsd.dk] Sent: Friday, April 02, 2004 12:09 PM To: Vinod Kashyap Cc: 'Artem Koutchine'; freebsd-current@freebsd.org; freebsd-bugs@freebsd.org Subject: Re: there is a bug in twe driver or disk subsystem for sure In message , Vinod Ka shyap writes: > >The 3ware (twe) driver is obviously not causing this panic. >It's something else (at line 128 in file /usr/src/sys/udm_dbg.c). >Memory modified after free 0x788f400(508) val=20202020 @ 0xe788f400 >panic: Most recently used by devbuf >at line 128 in file /usr/src/sys/udm_dbg.c You're wrong vinod, the bug _is_ most likely in the 3ware driver. What happens is that some piece of RAM is passed to free(9) and some code subsequently writes to it. We only discover this when we try to reuse it next time and it doesn't contain the correct "magic debug pattern". Please compile your kernel with DIAGNOSTICS to enable the extended malloc(9) debugging functions. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. DISCLAIMER: The information contained in this electronic mail transmission is intended by 3ware for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged and should not be disseminated without prior approval from 3ware