Network card freezes while copying large files over samba

[agnul]

When copying somewhat large files (say around 100Mb) from my linux laptop to a windows share on the lan (either using nautilus or mounting the share) the copying stops after a couple of seconds and the network card becomes unusable. ifconfig reports the device is up, but trying to ping some host on the LAN I get "destination unreachable". Doing an ifconfig down up brings the interface back. Not sure if the issue is samba or the nic driver.

I'm running a fully updated jaunty on an hp nc6320 laptop, the network card is a broadcom using the tg3 driver.
Does anyone have any idea on what may be wrong?

[Jeff (parkejr)]

Have two systems, a server running intrepid, and a pc which dual boots into windows and linux. Last week I did a distribution upgrade from intrepid to jaunty on the pc, but haven't yet changed the server.

Getting the same problem as above. Fully wired system, and I've changed out all the cables and the router - problem remains.

was just about to install a new network card in the PC when I noticed this bug. Prompted me to reboot into windows, where I can move large files around with no problems.

Next step, try and downgrade to intrepid and retest, but given the problem occurred just after the jaunty upgrade, and the hardware all seems to work with a different OS, i strongly suspect it's a jaunty issue.

Jeff.

[Brian Murray (brian-murray)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage. I have classified this bug as a bug in linux.
For future reference you might be interested to know that a lot of applications have bug reporting functionality built in to them. This can be accessed via the Report a Problem option in the Help menu for the application with which you are having an issue. You can learn more about this feature at https://wiki.ubuntu.com/ReportingBugs.

[Brian Murray (brian-murray)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it without more information.
Please include the following additional information, if you have not already done so (pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:

1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" after a fresh boot and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "sudo lspci -vnvn > lspci-vnvn.log" and attach the resulting file "lspci-vnvn.log" to this bug report.

For your reference, the full description of procedures for kernel-related bug reports is available at https://wiki.ubuntu.com/KernelTeamBugPolicies Thanks in advance!

[agnul (sucrabu)]

Here goes:

Linux duck 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

[agnul (sucrabu)]

... and lspci output

[Jeff (parkejr)]

Unfortunately I reinstalled intrepid, so can't supply the specific diagnostics.

However, when I went back to intrepid, I had the same problem.

When my network stopped during file transfer I took a look at dmesg, and it had a message regarding clocksource tsc being unstable.

Not clear why this should affect the NIC, but after a quick search on the web, it seems that the fix is to either stick a new battery in the motherboard, or put clocksource=hpet into the boot parameters.

not having a battery handy, I tried the clocksource=hpet option, and everything has been fine for the last day or two.

I'm going to keep an eye on it, and if it is still fine, will reinstall jaunty at the weekend, and test.

Perhaps I've always had an unstable clocksource, and there is something in the recent kernel that is more sensitive to it?

Jeff.

[agnul (sucrabu)]

Looks like file size doesn't matter after all, it just froze copying a 4.2Mb pfd file. Steps to reproduce?

* open a windows share with Nautilus ("open location", "smb://some-windows-share-on-the-lan")
* paste a file into it
* wait for the error dialog (it says "connection timed out")
* try to ping something on the lan (it says "destination unreachable")
* restart the network card ("ifcfg eth0 down up")

No errors in /var/log/messages, nothing in dmesg, nothing in the /var/log/samba folder

[agnul (sucrabu)]

Interestingly enough, doing things the other way round (scp from windows desktop to linux laptop, 200 meg file) works flawlessly, so the nic driver maybe is not the culprit.

[Marcel (ubuntu-no-network)]

Since "dmesg" shows the network card to be run by the "tg3" kernel module, maybe this is the same bug as bug #544390, but on a different kernel version. If so, should it be marked as a duplicate (I'm new to the lauchpad bugtracker)?

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]