Skip site navigation (1)Skip section navigation (2)
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>