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.htmlReceived on Thu May 08 2003 - 02:15:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:07 UTC