Sign in with
Sign up | Sign in
Your question

data corruption

Tags:
Last response: in Storage
Share
Anonymous
a b G Storage
July 12, 2004 10:06:44 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

hi there.
For some time now I have been experiencing some data corruption
problems, perhaps intermittently. With large files, I now always get
at least one error when copying large files. E.g. this file is about
1Gbyte:
F:\>copy disk.gz copy.gz /v
ERROR Verify - copy.gz
1 file(s) copied.

F:\>fc disk.gz copy.gz /b
Comparing files tivodisk.gz and COPY.GZ
1A742DCD: D5 C5
1AA95DCD: 1B 0B
208C5DCD: 5A 4A
2D9B3DCD: FD ED
40BE5DCD: 5E 4E
40F49DCD: 47 57

Curiously, they are always single bit errors (always bit 4 in fact),
while the number of errors varies from 2 to 6 or so.
The same sort of thing happens in XP as in Win98 (it is dual booted)
It seems to be the hard drive -- but is there anything else i should
look at or try?
The disk is a Seagate ST340014A, 80G.
I ran Seagates diagnostic but that didn't turn up anything.

Related question -- Is there a way to make Windows do the equivalent
of the /v switch, e.g. when dropping/dragging in explorer?
Apparently, by default anyway, windows does NOT do a verify after
writing. This problem seems to have taken me forever to track down
because I believed that windows was verifying when in fact it appears
it does not.

Thanks.

More about : data corruption

Anonymous
a b G Storage
July 12, 2004 1:30:54 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Have you looked in Event Viewer for any error messages ?

Do a chkdsk /f (reboot if necessary).

Plan on replacing your disk


In article <199470de.0407120506.64d4b165@posting.google.com>,
Geek Junk <ebeighe@msn.com> wrote:
>hi there.
>For some time now I have been experiencing some data corruption
>problems, perhaps intermittently. With large files, I now always get
>at least one error when copying large files. E.g. this file is about
>1Gbyte:
> F:\>copy disk.gz copy.gz /v
> ERROR Verify - copy.gz
> 1 file(s) copied.
>
> F:\>fc disk.gz copy.gz /b
> Comparing files tivodisk.gz and COPY.GZ
> 1A742DCD: D5 C5
> 1AA95DCD: 1B 0B
> 208C5DCD: 5A 4A
> 2D9B3DCD: FD ED
> 40BE5DCD: 5E 4E
> 40F49DCD: 47 57
>
>Curiously, they are always single bit errors (always bit 4 in fact),
>while the number of errors varies from 2 to 6 or so.
>The same sort of thing happens in XP as in Win98 (it is dual booted)
>It seems to be the hard drive -- but is there anything else i should
>look at or try?
>The disk is a Seagate ST340014A, 80G.
>I ran Seagates diagnostic but that didn't turn up anything.
>
>Related question -- Is there a way to make Windows do the equivalent
>of the /v switch, e.g. when dropping/dragging in explorer?
>Apparently, by default anyway, windows does NOT do a verify after
>writing. This problem seems to have taken me forever to track down
>because I believed that windows was verifying when in fact it appears
>it does not.
>
>Thanks.


--
Al Dykes
-----------
adykes at p a n i x . c o m
Anonymous
a b G Storage
July 12, 2004 7:23:12 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 12 Jul 2004 06:06:44 -0700, ebeighe@msn.com (Geek Junk):

> but is there anything else i should
>look at or try?

The RAM.
Try memtest386. The official site doesn't seem to exist anymore, but
it's part of the Timo Rescue CD <http://rescuecd.sourceforge.net/&gt;.
D/l and burn the ISO image, reboot on the CD, and choose "memtest386"
on the boot menu.
Related resources
Can't find your answer ? Ask !
Anonymous
a b G Storage
July 13, 2004 12:10:23 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously Fabien LE LEZ <gramster@gramster.com> wrote:
> On 12 Jul 2004 06:06:44 -0700, ebeighe@msn.com (Geek Junk):

>> but is there anything else i should
>>look at or try?

> The RAM.

Yes, the error is _very_ characteristic for a weak bit in RAM.
Als the addresses it turns up in.

> Try memtest386. The official site doesn't seem to exist anymore, but

Huh? It is here: http://www.memtest86.com/

> it's part of the Timo Rescue CD <http://rescuecd.sourceforge.net/&gt;.
> D/l and burn the ISO image, reboot on the CD, and choose "memtest386"
> on the boot menu.

Or get the floppy image, copy it onto a floppy disk and just boot from
it. Probably the best software-only memory tester around. I usually
run it for some hours on new PC's or after changing/upgrading RAM.
Saves a lot of trouble.

Arno

--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
Anonymous
a b G Storage
July 13, 2004 2:17:12 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 12 Jul 2004 20:10:23 GMT, Arno Wagner <me@privacy.net>:

>> Try memtest386. The official site doesn't seem to exist anymore, but
>
>Huh? It is here: http://www.memtest86.com/

Seems that I misspelled it (memtest386) and, since I saw several
references to <http://www.memtest386.com&gt; on Google, I didn't notice
the typo.
Anonymous
a b G Storage
July 13, 2004 8:51:40 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

I'd suspect the disk buffer memory.

Check whether last digits of the error location are always the same, across
reboots, and with copy command and copy by Windows Explorer. If it's DCD, as
in your example, the disk buffer is definitely flaky (one particular bit).
You have to replace the whole disk, unfortunately.

"Geek Junk" <ebeighe@msn.com> wrote in message
news:199470de.0407120506.64d4b165@posting.google.com...
> hi there.
> For some time now I have been experiencing some data corruption
> problems, perhaps intermittently. With large files, I now always get
> at least one error when copying large files. E.g. this file is about
> 1Gbyte:
> F:\>copy disk.gz copy.gz /v
> ERROR Verify - copy.gz
> 1 file(s) copied.
>
> F:\>fc disk.gz copy.gz /b
> Comparing files tivodisk.gz and COPY.GZ
> 1A742DCD: D5 C5
> 1AA95DCD: 1B 0B
> 208C5DCD: 5A 4A
> 2D9B3DCD: FD ED
> 40BE5DCD: 5E 4E
> 40F49DCD: 47 57
>
> Curiously, they are always single bit errors (always bit 4 in fact),
> while the number of errors varies from 2 to 6 or so.
> The same sort of thing happens in XP as in Win98 (it is dual booted)
> It seems to be the hard drive -- but is there anything else i should
> look at or try?
> The disk is a Seagate ST340014A, 80G.
> I ran Seagates diagnostic but that didn't turn up anything.
>
> Related question -- Is there a way to make Windows do the equivalent
> of the /v switch, e.g. when dropping/dragging in explorer?
> Apparently, by default anyway, windows does NOT do a verify after
> writing. This problem seems to have taken me forever to track down
> because I believed that windows was verifying when in fact it appears
> it does not.
>
> Thanks.
Anonymous
a b G Storage
July 13, 2004 6:26:23 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message news:wTJIc.894$mL5.215@newsread1.news.pas.earthlink.net...
> I'd suspect the disk buffer memory.

Nonsense.

>
> Check whether last digits of the error location are always the same, across
> reboots, and with copy command and copy by Windows Explorer. If it's DCD, as
> in your example, the disk buffer is definitely flaky (one particular bit).

Ah, diskdrives with 1GB buffers. What next can we expect from you.

If it was the buffer he would see errors at most a (few) megabyte apart,
so in their thousands, not just 6. Even if the 256kB disk buffer rotates
through the cache when the previous diskbuffer converts to a cache
segment you will still find them every 2 or 8 MB, so in their hundreds.

> You have to replace the whole disk, unfortunately.

And even that is false as the buffer sits on the EC assembly.
But that's obviously a moot point.

>
> "Geek Junk" <ebeighe@msn.com> wrote in message news:199470de.0407120506.64d4b165@posting.google.com...
> > hi there.
> > For some time now I have been experiencing some data corruption
> > problems, perhaps intermittently. With large files, I now always get
> > at least one error when copying large files. E.g. this file is about
> > 1Gbyte:
> > F:\>copy disk.gz copy.gz /v
> > ERROR Verify - copy.gz
> > 1 file(s) copied.
> >
> > F:\>fc disk.gz copy.gz /b
> > Comparing files tivodisk.gz and COPY.GZ
> > 1A742DCD: D5 C5
> > 1AA95DCD: 1B 0B
> > 208C5DCD: 5A 4A
> > 2D9B3DCD: FD ED
> > 40BE5DCD: 5E 4E
> > 40F49DCD: 47 57
> >
> > Curiously, they are always single bit errors (always bit 4 in fact),
> > while the number of errors varies from 2 to 6 or so.
> > The same sort of thing happens in XP as in Win98 (it is dual booted)
> > It seems to be the hard drive -- but is there anything else i should
> > look at or try?
> > The disk is a Seagate ST340014A, 80G.
> > I ran Seagates diagnostic but that didn't turn up anything.
> >
> > Related question -- Is there a way to make Windows do the equivalent
> > of the /v switch, e.g. when dropping/dragging in explorer?
> > Apparently, by default anyway, windows does NOT do a verify after
> > writing. This problem seems to have taken me forever to track down
> > because I believed that windows was verifying when in fact it appears
> > it does not.
> >
> > Thanks.
>
>
Anonymous
a b G Storage
July 14, 2004 1:24:45 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Fabien LE LEZ <gramster@gramster.com> wrote in message news:<r045f0hd59in1e2pqd0fg82dbg27m4vcqr@4ax.com>...
> On 12 Jul 2004 06:06:44 -0700, ebeighe@msn.com (Geek Junk):
>
> > but is there anything else i should
> >look at or try?
>
> The RAM.
> Try memtest386. The official site doesn't seem to exist anymore, but
> it's part of the Timo Rescue CD <http://rescuecd.sourceforge.net/&gt;.
> D/l and burn the ISO image, reboot on the CD, and choose "memtest386"
> on the boot menu.

I was so convinced the problem was the hard drive i ran out and bought
a replacement -- but that didn't fix the problem (that will learn me!)

Yup. It was the memory.
I ended up troubleshooting the problem by pulling SIMMs in and out,
and that
isolated the problem to one of the three SIMMs.

Thanks.
--Ed
Anonymous
a b G Storage
July 14, 2004 10:39:12 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 13 Jul 2004 21:24:45 -0700, ebeighe@msn.com (Geek Junk):

>Yup. It was the memory.

At work, we bought 6 new (quite low-end) PCs last January. Out of six,
three had slightly defective RAM.
[Decreasing the frequency by a few % was enough to repair the problem
though.]
Anonymous
a b G Storage
July 14, 2004 2:21:12 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously Geek Junk <ebeighe@msn.com> wrote:
> Fabien LE LEZ <gramster@gramster.com> wrote in message news:<r045f0hd59in1e2pqd0fg82dbg27m4vcqr@4ax.com>...
>> On 12 Jul 2004 06:06:44 -0700, ebeighe@msn.com (Geek Junk):
>>
>> > but is there anything else i should
>> >look at or try?
>>
>> The RAM.
>> Try memtest386. The official site doesn't seem to exist anymore, but
>> it's part of the Timo Rescue CD <http://rescuecd.sourceforge.net/&gt;.
>> D/l and burn the ISO image, reboot on the CD, and choose "memtest386"
>> on the boot menu.

> I was so convinced the problem was the hard drive i ran out and bought
> a replacement -- but that didn't fix the problem (that will learn me!)

> Yup. It was the memory.
> I ended up troubleshooting the problem by pulling SIMMs in and out,
> and that
> isolated the problem to one of the three SIMMs.

That is exactly the right approach. Cons!

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
July 17, 2004 8:22:34 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 13 Jul 2004 21:24:45 -0700, ebeighe@msn.com (Geek Junk) wrote:


>Yup. It was the memory.
>I ended up troubleshooting the problem by pulling SIMMs in and out,
>and that
>isolated the problem to one of the three SIMMs.

Although motherboards vary, I think you might be wise to stick with
two sticks instead of three.
Anonymous
a b G Storage
July 18, 2004 2:20:34 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On Sat, 17 Jul 2004 04:22:34 -0700, <..> wrote:

> On 13 Jul 2004 21:24:45 -0700, ebeighe@msn.com (Geek Junk) wrote:
>
>
>> Yup. It was the memory.
>> I ended up troubleshooting the problem by pulling SIMMs in and out,
>> and that
>> isolated the problem to one of the three SIMMs.
>
> Although motherboards vary, I think you might be wise to stick with
> two sticks instead of three.

I've had to reduce to two, as they are so damn hot I need huge heatsinks on them. I really don't want to use a fan!

Memory shouldn't be too hot to touch right? It burns my finger after 1 second.


--
*****TWO BABY CONURES***** 15 parrots and increasing http://www.petersparrots.com
93 silly video clips http://www.insanevideoclips.com
1259 digital photos http://www.petersphotos.com
Served from a pentawatercooled dual silent Athlon 2.8 with terrabyte raid

Beyond a critical point within a finite space, freedom diminishes as numbers increase...the human question is not how many can possibly survive within the system, but what kind of existence is possible for those who do survive. -- Frank Herbert (Dune)
Anonymous
a b G Storage
July 18, 2004 5:48:06 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Q: Is this an Asus board?

o Some of them run their memory at a high voltage as I recall - test voltage
o That will obviously increase their thermal dissipation. Check the config


Memory VRM demands limit the number of slots, with BTX that will
change and allow more memory slots - altho few people need >4GB.
(Dbase people do, but they are insatiable with any amount of RAM).

Burning your finger after 1 second tends to suggest they are >>69oC,
which is the general "too hot to hold without discomfort" temperature.

Check the board configuration if applicable - although 1GB DDR can
dissipate over 10W, the typical future design load is 30W for RAM.

Also, check your case cooling isn't short-circuited:
o Your rear-top fan ports have a fan in them or are closed off
o If they are open without a fan, they can short-circuit the airflow path
---- airflow should be in at the bottom-front, out at the top-rear
---- short-circuiting that airflow path will increase component temps

A test for case cooling would be case temperatures as reported by the
m/b, or checking around the CPU area re CPU-VRM temperatures.
On latest P4 processes the CPU-VRM system is very heavily loaded,
and cooling there required re regulators & capacitors in particular. The
VRM caps tend to be 105oC, but that temperature can be exceeded.
Even top Panasonic Extended Life 105oC capacitors are just 3,000hrs
at that temperature - so clearly not exceeding it is A Good Idea. More
an issue for P4-Prescott, but an issue with any CPU if poor case cooling.
--
Dorothy Bradbury
www.stores.ebay.co.uk/panaflofan for quiet Panaflo fans & other items
http://homepage.ntlworld.com/dorothy.bradbury/panaflo.h... (Direct)
!