[opensuse] systems see same file differently
I have a 1GB tar.gz file sitting on a windows share and have 3 systems connected via samba to that share. System A & B see the file just fine, and both report the same md5sum info. System C sees the file as corrupt and with a different md5sum. My problem, I need the file on system C and am puzzled about why it sees this file differently than the other two. All systems are running SuSE 9.3 32-bit, however, system C is an intel core 2 duo 64-bit processor. System A & B are older P3 systems. Has anyone every had anything like this and can offer suggestions as to why this might be happening. Thank you for your time -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
At 07:58 PM 12/7/2006 -0500, Coach-X wrote:
I have a 1GB tar.gz file sitting on a windows share and have 3 systems connected via samba to that share.
System A & B see the file just fine, and both report the same md5sum info. System C sees the file as corrupt and with a different md5sum.
My problem, I need the file on system C and am puzzled about why it sees this file differently than the other two. All systems are running SuSE 9.3 32-bit, however, system C is an intel core 2 duo 64-bit processor. System A & B are older P3 systems.
Has anyone every had anything like this and can offer suggestions as to why this might be happening.
Thank you for your time
--
Maybe sneaker mail is your answer--copy the file to a disk and sneaker it over to the recalcitrant machine. I know this is crude, but it just might work. --doug -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
I have a 1GB tar.gz file sitting on a windows share and have 3 systems connected via samba to that share.
System A & B see the file just fine, and both report the same md5sum info. System C sees the file as corrupt and with a different md5sum.
My problem, I need the file on system C and am puzzled about why it sees this file differently than the other two. All systems are running SuSE 9.3 32-bit, however, system C is an intel core 2 duo 64-bit processor. System A & B are older P3 systems.
Has anyone every had anything like this and can offer suggestions as to why this might be happening.
Thank you for your time
Maybe sneaker mail is your answer--copy the file to a disk and sneaker it over to the recalcitrant machine. I know this is crude, but it just might work.
--doug
Thanks for the reply, but the problem is not getting the file to system C, but rather it always sees the file as corrupt. In further testing it may be a hardware issue. The first time I ran md5sum on the file (on the share) was: a72c2c415a81cd7722319004987679f1 backup_ams_1.tar.gz I rebooted the system, and this time it was: 2a93d60a45712595b6edbbfad5075de3 backup_ams_1.tar.gz Testing the file with gzip gives this: gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: gzip: backup_ams_1.tar.gz: invalid compressed data--crc error gzip: backup_ams_1.tar.gz: invalid compressed data--length error The other two systems show the file is ok (file still on share) gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: OK -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 07 December 2006 16:44, Coach-X wrote:
I have a 1GB tar.gz file sitting on a windows share and have 3 systems connected via samba to that share.
System A & B see the file just fine, and both report the same md5sum info. System C sees the file as corrupt and with a different md5sum.
My problem, I need the file on system C and am puzzled about why it sees this file differently than the other two. All systems are running SuSE 9.3 32-bit, however, system C is an intel core 2 duo 64-bit processor. System A & B are older P3 systems.
Has anyone every had anything like this and can offer suggestions as to why this might be happening.
Thank you for your time
Maybe sneaker mail is your answer--copy the file to a disk and sneaker it over to the recalcitrant machine. I know this is crude, but it just might work.
--doug
Thanks for the reply, but the problem is not getting the file to system C, but rather it always sees the file as corrupt. In further testing it may be a hardware issue.
The first time I ran md5sum on the file (on the share) was: a72c2c415a81cd7722319004987679f1 backup_ams_1.tar.gz
I rebooted the system, and this time it was: 2a93d60a45712595b6edbbfad5075de3 backup_ams_1.tar.gz
Testing the file with gzip gives this:
gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: gzip: backup_ams_1.tar.gz: invalid compressed data--crc error
gzip: backup_ams_1.tar.gz: invalid compressed data--length error
The other two systems show the file is ok (file still on share)
gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: OK
On the Core 2 Duo machine is the kernel seeing it as two processors or one. cat /proc/cpuinfo It it is seeing it as two, try taskset 0x00000001 gzip -t -v backup_ams_1.tar.gz It would be interesting it was a core 2 duo problem with 9.3 I have seen one other very minor error when 9.3 could sense two cores but it only exhibited itself in some video processing (MythTV stuff). -- _____________________________________ John Andersen
John Andersen wrote:
On Thursday 07 December 2006 16:44, Coach-X wrote:
I have a 1GB tar.gz file sitting on a windows share and have 3 systems connected via samba to that share.
System A & B see the file just fine, and both report the same md5sum info. System C sees the file as corrupt and with a different md5sum.
My problem, I need the file on system C and am puzzled about why it sees this file differently than the other two. All systems are running SuSE 9.3 32-bit, however, system C is an intel core 2 duo 64-bit processor. System A & B are older P3 systems.
Has anyone every had anything like this and can offer suggestions as to why this might be happening.
Thank you for your time
Maybe sneaker mail is your answer--copy the file to a disk and sneaker it over to the recalcitrant machine. I know this is crude, but it just might work.
--doug
Thanks for the reply, but the problem is not getting the file to system C, but rather it always sees the file as corrupt. In further testing it may be a hardware issue.
The first time I ran md5sum on the file (on the share) was: a72c2c415a81cd7722319004987679f1 backup_ams_1.tar.gz
I rebooted the system, and this time it was: 2a93d60a45712595b6edbbfad5075de3 backup_ams_1.tar.gz
Testing the file with gzip gives this:
gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: gzip: backup_ams_1.tar.gz: invalid compressed data--crc error
gzip: backup_ams_1.tar.gz: invalid compressed data--length error
The other two systems show the file is ok (file still on share)
gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: OK
On the Core 2 Duo machine is the kernel seeing it as two processors or one. cat /proc/cpuinfo
It it is seeing it as two, try taskset 0x00000001 gzip -t -v backup_ams_1.tar.gz
It would be interesting it was a core 2 duo problem with 9.3 I have seen one other very minor error when 9.3 could sense two cores but it only exhibited itself in some video processing (MythTV stuff).
I had a similar issue using NFS with a machine not too long ago... turned out to be a bad Broadcom based NIC on the MoBo. Switching the NIC to an Intel based port fixed the problem. - herman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 12/8/2006 12:48 AM, John Andersen wrote:
The first time I ran md5sum on the file (on the share) was: a72c2c415a81cd7722319004987679f1 backup_ams_1.tar.gz
I rebooted the system, and this time it was: 2a93d60a45712595b6edbbfad5075de3 backup_ams_1.tar.gz
Testing the file with gzip gives this:
gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: gzip: backup_ams_1.tar.gz: invalid compressed data--crc error
gzip: backup_ams_1.tar.gz: invalid compressed data--length error
The other two systems show the file is ok (file still on share)
gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: OK
On the Core 2 Duo machine is the kernel seeing it as two processors or one. cat /proc/cpuinfo
It it is seeing it as two, try taskset 0x00000001 gzip -t -v backup_ams_1.tar.gz
It would be interesting it was a core 2 duo problem with 9.3 I have seen one other very minor error when 9.3 could sense two cores but it only exhibited itself in some video processing (MythTV stuff).
I have smp running: orbit:~ # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) D CPU 3.20GHz processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) D CPU 3.20GHz orbit:~ # taskset 0x00000001 gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: gzip: backup_ams_1.tar.gz: invalid compressed data--crc error Herman Knief mentioned a similar problem with a nic, I am going to swap it and see if that makes a difference. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 12/8/2006 9:02 AM, Coach-X wrote:
On 12/8/2006 12:48 AM, John Andersen wrote:
The first time I ran md5sum on the file (on the share) was: a72c2c415a81cd7722319004987679f1 backup_ams_1.tar.gz
I rebooted the system, and this time it was: 2a93d60a45712595b6edbbfad5075de3 backup_ams_1.tar.gz
Testing the file with gzip gives this:
gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: gzip: backup_ams_1.tar.gz: invalid compressed data--crc error
gzip: backup_ams_1.tar.gz: invalid compressed data--length error
The other two systems show the file is ok (file still on share)
gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: OK On the Core 2 Duo machine is the kernel seeing it as two processors or one. cat /proc/cpuinfo
It it is seeing it as two, try taskset 0x00000001 gzip -t -v backup_ams_1.tar.gz
It would be interesting it was a core 2 duo problem with 9.3 I have seen one other very minor error when 9.3 could sense two cores but it only exhibited itself in some video processing (MythTV stuff).
I have smp running:
orbit:~ # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) D CPU 3.20GHz
processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) D CPU 3.20GHz
orbit:~ # taskset 0x00000001 gzip -t -v backup_ams_1.tar.gz backup_ams_1.tar.gz: gzip: backup_ams_1.tar.gz: invalid compressed data--crc error
Herman Knief mentioned a similar problem with a nic, I am going to swap it and see if that makes a difference.
Ok, swapped the nic and that solved the problem of bad md5sum/file corruption. However, whey trying to copy the file from the network the system locked up, could still ping, but no access to the box. System console had this error: ata1(0) WARNING: zero len r/w req Could this be another issue, hard drive as well? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday December 8 2006 9:33 am, Coach-X wrote:
Ok, swapped the nic and that solved the problem of bad md5sum/file corruption. However, whey trying to copy the file from the network the system locked up, could still ping, but no access to the box. System console had this error:
ata1(0) WARNING: zero len r/w req
Could this be another issue, hard drive as well?
There was another thread about hard drive data corruption and that turned out to be inferior quality memory. Rated at DDR2 800 but BIOS only allowed it to run at 667. Swapped out for better quality and data corruption problems disappeared. Stan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (5)
-
Coach-X -
Doug McGarrett -
Herman Knief -
John Andersen -
Stan Glasoe