open All Channels
seplocked Out of Pod Experience
blankseplocked md5sum
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: [1] 2

Author Topic

Brennivargur
Posted - 2010.11.05 01:47:00 - [1]
 

Righty, here goes a whine.
copied the eve setup file 6 times now from my server, on the same network as I am on, md5 never sums up.
used sftp, samba, nfs, ftp, bittorrent.

all failed, md5 is never the same.

memory problem?
network problem?

will be running a memtest tomorrow while at school
any other suggestions?

Barakkus
Posted - 2010.11.05 14:44:00 - [2]
 

Are you going from a linux server to windows?

We had/have a problem with linux messing crap up when going to windows with samba.

Brennivargur
Posted - 2010.11.05 15:12:00 - [3]
 

Yes, CentOS 5.5 running samba, to Windows 7 64bit, but as I mentioned, i tried samba, sftp, bitTorrent, and more, but all failed

Vogue
Short Bus Pole Dancers
Posted - 2010.11.05 15:17:00 - [4]
 

Windows 7 and Vista use 128-bit encryption for file sharing. XP, 2000, NT4 and Samba AFAIK use 40 and 56 bit encryption. You can set Windows 7 to use 40\56 bit in Network And Sharing Centre -> 'Change Advanced Sharing settings'.

Brennivargur
Posted - 2010.11.05 15:43:00 - [5]
 

As I said, I doub't its SAMBA's fail, running a memtest now on the machine to see if the memory might be corrupted, 1 pass done with 0 errors, suspecting the network...

Barakkus
Posted - 2010.11.05 20:26:00 - [6]
 

Edited by: Barakkus on 05/11/2010 20:30:54
Originally by: Brennivargur
Yes, CentOS 5.5 running samba, to Windows 7 64bit, but as I mentioned, i tried samba, sftp, bitTorrent, and more, but all failed


This is EXACTLY what he had going on, but moving data to 2008 server.

There's something wrong with moving large amounts of data between the platforms, we never did figure it out, we even had consultants look at it and couldn't figure it out. It is defintely a problem with SAMBA, we just can't figure out why though. It's only a problem with large amounts of date (in excess of a gig). Going from windows to the linux machines was no problem. The consultants we had come look at it confirmed it was a problem with SAMBA, we tried some other stuff and that didn't work either. Ended up just having our client dump their data via VPN to the windows server.

Sturmwolke
Posted - 2010.11.05 21:29:00 - [7]
 

Disable disk caching on the Windows and see if that makes a difference.

Brennivargur
Posted - 2010.11.05 21:33:00 - [8]
 

It seems to be windows and my computer, works on all other PC's on the network, but they all have linux installs...
and its not samba, for the x'th time. Fails again and again using sftp/ftp/bitTorrent, and samba too... will try http now

Brennivargur
Posted - 2010.11.05 21:37:00 - [9]
 

Originally by: Sturmwolke
Disable disk caching on the Windows and see if that makes a difference.


Gave up on disabling it, computer freezes every time I try it, besides, I tried transferring it to 2 hard drives, one SSD and one normal HDD, fails in both cases.

Brennivargur
Posted - 2010.11.05 21:49:00 - [10]
 

Yeah, this is really wired, I't freezes when disabling write caching on both of the hard drives Crying or Very sad

Barakkus
Posted - 2010.11.05 22:25:00 - [11]
 

Edited by: Barakkus on 05/11/2010 22:30:15
I asked our linux guy what he found when researching that problem, he said whenever things were pushed from the ftp server on the linux box to the mounted windows share he was seeing all kinds of cifs errors.

Probably is something wrong with windows 7 since we never had a problem with 2000/2003 server and I wouldn't doubt windows 7 and 2008 server are probably handling network communications similarly.

Sturmwolke
Posted - 2010.11.05 22:31:00 - [12]
 

There's really no reason why Windows should freeze up when you disable disk caching.
Does it freeze the moment you disable disk caching or does it freeze during file transfer?

In any case, you should narrow down whats causing the freeze.

For windows corrupt data usual suspect would be the disk caching - hence why I disable caching on my XP system. It's a noticeably slower during file transfer/write, but at least I'm sure the chances of data corruption is almost zero in any event whatsoever. Makes for a rock solid platform (zero issues), better reliability, if you don't mind the sacrifice.

Brennivargur
Posted - 2010.11.05 22:41:00 - [13]
 

It freezes when I click 'OK' after unchecking the write caching option

Brennivargur
Posted - 2010.11.05 22:43:00 - [14]
 

I did switch the disk mode to IDE from AHCI after installing windows...

Sturmwolke
Posted - 2010.11.05 22:57:00 - [15]
 

Originally by: Brennivargur
I did switch the disk mode to IDE from AHCI after installing windows...


Errgg .. I know XP will barf if I do that, the HAL will just BSOD it at boot. I've had limited experience with Win 7 (and cba to replace my XP just yet), but that may look a the cause from where I'm sitting atm. You could try reverting it back to what it was .... or failing that, repair/re-install your Win 7 Wink

Barakkus
Posted - 2010.11.05 23:02:00 - [16]
 

You may end up having to manually enable the achi driver in the registry to re-enable it. I don't think it would cause a problem since the only thing you'll get out of achi is hot swap and command queuing. There is the potential of getting a blue screen when switching to/from achi after the OS is installed.

Try disabling write cache from safe mode, that sometimes works or download the diagnostics software from the drive manufacturer. You can sometimes disable write cache from there when windows fails to do so.

Brennivargur
Posted - 2010.11.06 00:11:00 - [17]
 

Edited by: Brennivargur on 06/11/2010 00:13:09
AHCI mode success, no issues.

Updated my SSD firmware, BSOD in the middle of the process, it is now effectively bricked.

****.

Edit:

****, this ****ing wordfilter.

Grez
Neo Spartans
Laconian Syndicate
Posted - 2010.11.06 00:30:00 - [18]
 

You need to change the disk mode in the registry on Windows when you change IDE > AHCI mode in bios.

Professor Tarantula
Hedion University
Posted - 2010.11.06 00:33:00 - [19]
 

Have you tried taking the cartridge out and blowing on it?

Brennivargur
Posted - 2010.11.06 00:42:00 - [20]
 

Originally by: Grez
You need to change the disk mode in the registry on Windows when you change IDE > AHCI mode in bios.


No, it was already on, I installed windows on it in AHCI mode, changed to IDE for a moment for some reason(can't remember), then back to AHCI.

and my SSD is working again Rolling Eyes, firmware upgrade BSOD's in the middle, but seems to have finished lol.
plugged the SSD in another sata port and it worked again.

Brennivargur
Posted - 2010.11.06 15:53:00 - [21]
 

Updated/replaced windows driver with the official realtek network driver, updated SSD firmware, problem still persists.
booted up a linux live cd and tried transferring the file, success on first try, md5's matched.

Sturmwolke
Posted - 2010.11.06 19:25:00 - [22]
 

Originally by: Brennivargur
Updated/replaced windows driver with the official realtek network driver, updated SSD firmware, problem still persists.
booted up a linux live cd and tried transferring the file, success on first try, md5's matched.



Interesting, that more or less rules out the hardware & router/hub and we also know that Win 7 writes are reliable (after disabling disk caching). It's pointing to something to do with how networking is handled by Win 7 or associated driver compatibility issues with the NIC. I'd usually want to rule out the NIC if you have a discrete PCI NIC or wired/wireless USB external as spare to test with.

Othe than the above, don't really have anything much to suggest except that you might want to consider this article on W7 network issues.

Brennivargur
Posted - 2010.11.06 21:42:00 - [23]
 

Edited by: Brennivargur on 06/11/2010 21:44:20
Originally by: Sturmwolke
Originally by: Brennivargur
Updated/replaced windows driver with the official realtek network driver, updated SSD firmware, problem still persists.
booted up a linux live cd and tried transferring the file, success on first try, md5's matched.



Interesting, that more or less rules out the hardware & router/hub and we also know that Win 7 writes are reliable (after disabling disk caching). It's pointing to something to do with how networking is handled by Win 7 or associated driver compatibility issues with the NIC. I'd usually want to rule out the NIC if you have a discrete PCI NIC or wired/wireless USB external as spare to test with.

Othe than the above, don't really have anything much to suggest except that you might want to consider this article on W7 network issues.



That's the thing, I can't disable write caching. Computer freezes every time I try to.

Sturmwolke
Posted - 2010.11.06 21:55:00 - [24]
 

Lol ok, then try to solve that problem first Very Happy

Brennivargur
Posted - 2010.11.06 22:18:00 - [25]
 

Solved! managed to disable write caching, and now the md5sum matches Very Happy
gonna do some more testing on this.

Brennivargur
Posted - 2010.11.06 23:14:00 - [26]
 

Edited by: Brennivargur on 06/11/2010 23:18:12
Edited by: Brennivargur on 06/11/2010 23:16:20
Problem still persists Rolling Eyes... but doesn't seem as serious now.

http://i.imgur.com/aWLrg.jpg
That's me.

Edit: Someone remind me why i'm still using Windows?

N Ano
Caldari
Templars of Space
Posted - 2010.11.07 00:45:00 - [27]
 

Because Windows > Mac

Brennivargur
Posted - 2010.11.07 01:02:00 - [28]
 

Originally by: N Ano
Because Windows > Mac


you just had to show up didnt you

Jim McGregor
Posted - 2010.11.07 13:46:00 - [29]
 


I remember reading about similar issues a couple of months and years ago. A google search confirms there are other people having the same problem. Always seems to involve Samba and Linux/Windows combination. I found problems dating back to Windows NT servers and Samba even.

Brennivargur
Posted - 2010.11.07 16:34:00 - [30]
 

just DD'd my SSD(yes, I know), setting up windows again, hope the problem will be resolved.


Pages: [1] 2

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only