I used a ax59pro as my main box for a year but got a bit annoyed with a slight bug the it had
somewhere in the ide controller. With a 20 gig HDD, I never had problems with corrupt files,
but I ~was~getting discrepancies in the md5sums! When I looked into it,
Somewhere along the line a bit or two was getting dropped amongst large quantities of
0xFF. i.e. very seldomnly, instead of "255,255,255..255"" after copying a large file and comparing it to the original, I'd find "255,255,253... 255". It never affected the operation of the PC, which I don't think ever crashed, but It *did* mess up my md5sums.
Any ideas 'bout what was wrong ?
Ax59pro dropped bits in file transactions
- stevenaaus
- K6'er
- Posts: 66
- Joined: Mon Aug 30, 2004 6:09 am
- Location: Australia
- Contact:
Ax59pro dropped bits in file transactions
p54-166/p55-200 - ga586
k6/2-380@412 - txp4
k75-750 slot a - pcchips 800LMR (rock solid)
compaq C2.4Ghz - U8668grand (cheap)
Sempron 3400+ (754) - K8VM800M, FX5600, Fedora 7
E5200 - Asrock 4CoreDual-Sata2
Core 2 Quad 9400 - Asus P5G41-M
k6/2-380@412 - txp4
k75-750 slot a - pcchips 800LMR (rock solid)
compaq C2.4Ghz - U8668grand (cheap)
Sempron 3400+ (754) - K8VM800M, FX5600, Fedora 7
E5200 - Asrock 4CoreDual-Sata2
Core 2 Quad 9400 - Asus P5G41-M
- KachiWachi
- K6'er Elite
- Posts: 507
- Joined: Wed Sep 21, 2005 10:53 am
- Location: Pennsylvania, USA
OS?
Any overclocking, etc...??
Any overclocking, etc...??
Moderator - Wim's BIOS
PC #1 - DFI 586IPVG, K6-2/+ 450 (Cyrix MII 433), 128 MB EDO. BIOS patched by Jan Steunebrink.
PC #2 - Amptron PM-7900 (M520), i200 non-MMX, 128 MB EDO
PC #3 - HP8766C, PIII-667, 768 MB SDRAM
PC #4 - ASUS P3V4X, PIII-733, 256 MB SDRAM
PC #5 - Gateway 700X, P4-2.0 GHz, 768 MB PC800 RDRAM
PC #6 - COMPAQ Evo N1020v laptop, P4-2.4 GHz, 1 GB PC2700 DDR
PC #7 - Dell Dimension 4600i, P4-2.8 GHz, 512 MB PC2700 DDR
PC #8 - Acer EeePC netbook, Atom N270 @ 1.60 GHz, 1 GB RAM
PC #9 - ???
PC #1 - DFI 586IPVG, K6-2/+ 450 (Cyrix MII 433), 128 MB EDO. BIOS patched by Jan Steunebrink.
PC #2 - Amptron PM-7900 (M520), i200 non-MMX, 128 MB EDO
PC #3 - HP8766C, PIII-667, 768 MB SDRAM
PC #4 - ASUS P3V4X, PIII-733, 256 MB SDRAM
PC #5 - Gateway 700X, P4-2.0 GHz, 768 MB PC800 RDRAM
PC #6 - COMPAQ Evo N1020v laptop, P4-2.4 GHz, 1 GB PC2700 DDR
PC #7 - Dell Dimension 4600i, P4-2.8 GHz, 512 MB PC2700 DDR
PC #8 - Acer EeePC netbook, Atom N270 @ 1.60 GHz, 1 GB RAM
PC #9 - ???
I am a bit confused: what md5sum are you talking about?
the only thing I can link to md5-checksums are files that are to be downloaded from the internet where the source provides a md5-checksum to check if they a) were not changed before download (viruses, trojans) and/or b) became corrupt during download.
the only thing I can link to md5-checksums are files that are to be downloaded from the internet where the source provides a md5-checksum to check if they a) were not changed before download (viruses, trojans) and/or b) became corrupt during download.
> Any overclocking, etc...??
No overclocking on this box - I could never get the k6-2 to overclock stably over 100FSB or upping the
multiplier, but it was very stable at 5*100=500.
> OS?
II wouldn't have tested the md5sums in windows, but did do file copies in this OS. Generating the
md5sums would have been linux 2.4.18, but the results were the same with files copied by either OS. Using the "cmp -l" command I could see where the files were differring, and it was only in large stretches of 0xFFh.
At the time my feelings were that it was definately a harddisk hardware/driver issue.
I had udma33 enabled as I never had any other problems, and generally found that the ax59pro/mvp3 is
the fastest SS7 chipset I've seen. Whether the issue was the mvp3 disk controller or the linux driver
running it too hard I guess I can't say. The problem was the same even with a udma66 IDE cable, though
IIRC the mp3 is only udma33.
> I am a bit confused: what md5sum are you talking about?
I download a large file, then type "md5sum FILENAME" to check the result is the same as the author's
md5sum (which ensures the file is exactly the same as the one the author put up for download). Even a
single bit difference in a file will mean the md5sums are totally different.
My problem is not that the downloaded file was corrupt (it worked fine), but successively running the
command "md5sum FILENAME" would give different results on large files with lots of consectutive
0xFFH bytes. This should not happen.
No overclocking on this box - I could never get the k6-2 to overclock stably over 100FSB or upping the
multiplier, but it was very stable at 5*100=500.
> OS?
II wouldn't have tested the md5sums in windows, but did do file copies in this OS. Generating the
md5sums would have been linux 2.4.18, but the results were the same with files copied by either OS. Using the "cmp -l" command I could see where the files were differring, and it was only in large stretches of 0xFFh.
At the time my feelings were that it was definately a harddisk hardware/driver issue.
I had udma33 enabled as I never had any other problems, and generally found that the ax59pro/mvp3 is
the fastest SS7 chipset I've seen. Whether the issue was the mvp3 disk controller or the linux driver
running it too hard I guess I can't say. The problem was the same even with a udma66 IDE cable, though
IIRC the mp3 is only udma33.
> I am a bit confused: what md5sum are you talking about?
I download a large file, then type "md5sum FILENAME" to check the result is the same as the author's
md5sum (which ensures the file is exactly the same as the one the author put up for download). Even a
single bit difference in a file will mean the md5sums are totally different.
My problem is not that the downloaded file was corrupt (it worked fine), but successively running the
command "md5sum FILENAME" would give different results on large files with lots of consectutive
0xFFH bytes. This should not happen.
so the downloaded file is ok but the md5-checksums don't match. worse, with each additional md5-run you get another different checksum. very strange.
try this (for comparison): download a file in question. once downloaded make a copy of it in the directory. name it as you like. then go to the command-lind (run .... cmd (command in win9x), go to the directory where you placed the two copies of the same file. at the prompt you then type (without quotes): "fc /b filename1 filename2"
if this gives no difference but you get two different md5-checksums then I would suggest your md5-program has a problem.
try this (for comparison): download a file in question. once downloaded make a copy of it in the directory. name it as you like. then go to the command-lind (run .... cmd (command in win9x), go to the directory where you placed the two copies of the same file. at the prompt you then type (without quotes): "fc /b filename1 filename2"
if this gives no difference but you get two different md5-checksums then I would suggest your md5-program has a problem.
- stevenaaus
- K6'er
- Posts: 66
- Joined: Mon Aug 30, 2004 6:09 am
- Location: Australia
- Contact:
Hmm.. USB problems might be another issue I think. In my experience
some boards/usb-disks/drivers just aren't compatible. And the actual disks
don't last forever.
some boards/usb-disks/drivers just aren't compatible. And the actual disks
don't last forever.
p54-166/p55-200 - ga586
k6/2-380@412 - txp4
k75-750 slot a - pcchips 800LMR (rock solid)
compaq C2.4Ghz - U8668grand (cheap)
Sempron 3400+ (754) - K8VM800M, FX5600, Fedora 7
E5200 - Asrock 4CoreDual-Sata2
Core 2 Quad 9400 - Asus P5G41-M
k6/2-380@412 - txp4
k75-750 slot a - pcchips 800LMR (rock solid)
compaq C2.4Ghz - U8668grand (cheap)
Sempron 3400+ (754) - K8VM800M, FX5600, Fedora 7
E5200 - Asrock 4CoreDual-Sata2
Core 2 Quad 9400 - Asus P5G41-M