Date: Fri, 02 Apr 2004 22:08:49 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Vinod Kashyap <vkashyap@3WARE.com> Cc: freebsd-current@freebsd.org Subject: Re: there is a bug in twe driver or disk subsystem for sure Message-ID: <36769.1080936529@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 02 Apr 2004 11:10:46 -0800." <A1964EDB64C8094DA12D2271C04B812601532143@tabby.3ware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <A1964EDB64C8094DA12D2271C04B812601532143@tabby.3ware.com>, 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36769.1080936529>