Date: Thu, 8 May 2003 13:15:25 +0200 (CEST) From: Heiko Schaefer <hschaefer@fto.de> To: current@freebsd.org Subject: Re: data corruption with current (maybe sis chipset related?) Message-ID: <20030508131508.M78057@daneel.foundation.hs>
next in thread | raw e-mail | index | archive | help
Hi Poul,
> >sorry to be pushy, but have you found anything - or been able to reproduce
> >anything since then ? i'm still confused how exactly you determined that
> >some data on your disk was corrupt.
>
> No, I'm not any further.
>
> What I saw was the stdout/stderr from a "make universe" that suddenly
> had a bunch of zero bytes in the middle.
if that is related, it would rule out anything that has to do with the
harddisk-subsystem, wouldn't it ?
> The thing we need, more than anything else, is a way to reproduce
> this on demand.
well, i can reproduce it pretty well. but only as a relatively
time-consuming process (a number of hours). if anyone has code to debug
this (which doesn't produce too much output :)), i can gladly run it and
very likely the corruption will occur sometime soon during my test.
it would appear to me that if your stdout/err null-bytes are related to my
data corruption while copying, the error must be somehow connected to
memory management.
if so, i imagine that code which moves data around in memory and checksums
it every once in a while (start with large chunk of data called a, {
malloc b, copy a to b, dealloc a, checksum b, use b as a now}, repeat - or
something like that) should lead to such results.
however, one thing i wonder about: shouldn't copying between ide disks
with udma go more or less around memory management (and even the cpu) ?
regards,
Heiko
--
Free Software. Why put up with inferior code and antisocial corporations?
http://www.gnu.org/philosophy/why-free.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030508131508.M78057>