First post here on this forum. Having a little trouble with my first home server, hope somebody here can help me out. When trying to transfer files from my server to my desktop, the files never get fully transfered. I have windows cmd running a ping to my server, and all is fine until i try to transfer files. Some will transfer fine, and then out of nowhere the server will stop replying. I then have to restart the server to gain access to it. A 2 GB file will transfer about halfway, and then the server will not be able to be pinged. I have static IP on the server and my desktop. Running XP x64 and Ubuntu server 32-bit 9.04. Tried using Samba and NFS Exports. I have both my desktop and server connected to the same gigabit switch, and then my switch connected to my router. Any ideas?

[SOLVED]

Updated my kernel to 2.6.31-8 and everything works! Big thanks to GrapefruiTgirl (Sasha) for helping me out!

Some food for thought, but no guarantees:

I run an FTP server on my home LAN/Firewall machine (an old PII 333MHz) and it serves 2 desktop machines: my Slack64 box, and my roommates WinXP machine.

When I first set it all up, I could transfer most files by FTP to/from my Slack machine, however transferring stuff by FTP to/from the WIn machine (mostly TO it) would hang the server, requiring a reboot.

I'm not sure if or why WinXP had anything to do with the problem -- maybe it was just coincidence that the transfers hung when sending to that machine -- BUT: though I never did 100% nail down an exact cause, I found that upgrading the kernel on the FTP machine fixed the problem completely. The original kernel on the FTP machine (which was hanging) was 2.6.24.4 and I upgraded it to something like 2.6.29.x and the problem disappeared totally.

My guess: the older kernel lacked some bug-fixes or something, which were contributing to hangups of the NIC driver(s) under high load.

What kernel does your Ubuntu server run, and what is/are the NIC in the machine and the NIC driver? An upgrade *might* help.

For the record, some data about my server machine:

Old kernel: 2.6.24.4
New kernel: 2.6.29.x
NICs: 2x ADMtek Comet 10/100 cards
NIC Driver(s): Tulip
FTP server: ProFTPd
FTP server OS: Slackware 11

Just something to think about -- good luck
Sasha

Thanks Sasha, going to check my kernel tomorrow when i get home. I haven't upgraded it since i installed it, but it's more then likely the default kernel for Ubuntu Server 9.04. Not sure how to install a driver for a headless system, will have to do a little research. Thanks again Sasha!

Is the server in the same room/house? Can you log into the server at the local console, or is it completely locked up/frozen?

Another thing to try... have you tried running MemTest86 on the server box? Worth a shot, to verify you don't have bad RAM locking up the box.

Hope this helps.

Box is located right next to my desktop. I have the server connected to a monitor, and when it disconnects, I can still gain control of it locally, just not remotely through the network. I even run ifconfig to see if its losing it's IP, but it stays the same. Server doesn't lock up, so i don't think thats the problem.

Kernel is the up-to-date 2.6.28-11 server. Looking to update the network adapter, but MSI only offers drivers for SuSe, is that ok?

Myself, I'm not sure what to make of that statement.

If you're saying that the motherboard or NIC is from MSI, that's fine; but in order to figure out what driver(s) you would need, we'd need to know the chipset of the NIC. For example, my MSI board uses a Realtek 8211BL NIC, which uses the in-kernel forcedeth driver.

As for whether a driver works on one distro but not another, that's not usually the case. However, if you did download a driver specifically FOR a particular distro, it would very likely need some re-configging to install it on another distro (like say, Ubuntu).

So, if you're considering a new NIC, the best thing to do first is make sure that there are good-working drivers for it in the Linux kernel. If there's not, you're at the mercy of whatever source provides what they claim to be a working driver.

Sasha

PS - hopefully I've understood what you said; if not, please do clarify for me

The computer is a barebones MSI Wind PC, didn't clarify that in the opening post. I followed the instructions on installing the driver through the readme file, but had a lot of trouble. Just for the heck of it I took a look at my bios to see if there were any weird settings. Found one that pertained to LAN booting. For some reason when the server starts up it runs DHCP from the bios. So i disabled this setting, and now my transfers are working correctly. I'm going to keep an eye on it, but hopefully this has solved my problem. Thanks for your help Sasha, I will post back here if there are anymore problems. As usual for computers, it comes down to user error

Are you sure you aren't reaching the limit at 2GB? That is the filesize limit for fat32 IIRC. If you are trying to write to a fat32 filesystem, you may be reaching the limit. Using Samba, the smb protocol may have a file size limit as well.

jschiwal's suggestion seems very reasonable -- and is something that had not occurred to me.

Also, for the record I too have a BIOS option regarding the "LAN Option ROM" as it's called in my MSI desktop BIOS, which if I understand as I believe you do, is for booting via a network (like BootP ??) and I haven't found that enabling OR disabling it ever made any difference for me. That said, if it help in your case, that's good!

Sasha

Running the server with NFS now and its connected. Tried to run VirtualBox grabbing the .iso from the server. The OS (Windows 7) was installing, then all of a sudden I lost connection after about 10 minutes of OS installation. As soon as I killed VirtualBox it connected again. I hate this MSI Wind!!!!

Note to self : do not get an MSI Wind

Heh, any chance there's much of a BIOS on that thing, and if so, could you maybe see if you can set interrupts for things, such as the NIC ?

And make sure your kernel has optimal stuff set, such as IRQ sharing (if applicable), and maybe any other kernel options relating to the networking subsystem or your driver?

Also, check in dmesg, /var/log/messages, /var/log/kernel, and /var/log/syslog for any evidence of what's happening. Maybe it's an IRQ conflict, or as someone else on here mentioned somewhere recently, they had a NIC that under high load, it heated up and got sketchy; they added a fan(s) aiming at the NIC and it never acted up again (which I realize you can't do with this little laptop thing )

To follow the logs, open a console as root, and issue a command like:

shell# tail -f /var/log/kernel

and this will follow the kernel log-file, printing every new message on the console. This can be a lot of stuff, depending on how much logging you have configured.

Best of luck,
Sasha

Both my dmesg and kern.log from /var/log are attached. I had to cut down my kern.log b/c it was about 2 MB big!!! See if you can make sense of it Sasha. I'm offering a $5 reward to anyone who can get this to work!!! Thanks everyone!

GriFF

Attached Files

	dmesg.txt (36.0 KB, 7 views)
	kern.log.txt (100.4 KB, 5 views)

OK, the dmesg you provided is from the dmesg file created during bootup. However, after that bootup, the file does not get added to while the system is running. Therefore, there's nothing in there that will relate to the problem, when it occurs. This is why it would be helpful if you do the following:

1-- do some large file transfer that you expect will hang.
2-- the instant it hangs, kill the transfer process immediately, and execute dmesg > some_filename.txt
3-- that will save all the last dmesg data to a text file, which may be more useful than the default dmesg file.
4-- similarly, save the last 50 lines or so, or 100 lines, of syslog & kernel.log (whatever their exact names are on your system) and provide them too.

I haven't looked at the kernel.log you already gave, yet.

NOW; the 3 lines I pasted at the top of this thread, ARE from your bootup dmesg. It shows us that you are using the r8169 device/driver, and we also see that in interrupt has been assigned for MSI/MSI-x. THAT might be part of the problem (MIGHT) because MSI/MSI-X (message signaled interrupts) are not always supported completely by all drivers/software/hardware. Let's check something, and maybe give your NIC some options to chew on, and see if we can fix it up; please do:

shell# lsmod

to see what modules are loaded. Identify the r8169 module in the list, just to make sure we have the exact name of the module (r8169). Now, do:

shell# modinfo <module-name>

.. where <module-name> is the name of the r8169 thing in the lsmod output.

Now paste us the results of the modinfo command you just did.

Sasha

No disconnects yet after transferring around 8 GB of data, so we'll have to wait for the dmesg file. Here is the lsmod info though. Thanks again for all your help so far Sasha, I really do appreciate it. Hopefully we can get this problem fixed

Attached Files

modinfo.txt (1.1 KB, 12 views)