there is a bug in twe driver or disk subsystem for sure

Vinod Kashyap vkashyap at
Fri Apr 2 12:45:42 PST 2004

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 at]
Sent: Friday, April 02, 2004 12:09 PM
To: Vinod Kashyap
Cc: 'Artem Koutchine'; freebsd-current at;
freebsd-bugs at
Subject: Re: there is a bug in twe driver or disk subsystem for sure 

In message <A1964EDB64C8094DA12D2271C04B812601532143 at>, Vinod
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 at 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 

More information about the freebsd-current mailing list