Heavy network activity (eg: torrent/nfs file transfers) causes Hard System Locks and/or Network Freezes.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Won't Fix
|
High
|
Unassigned | ||
nfs-utils (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Bug Description
Simply downloading a torrent at high speed (speed caps mitigate this somewhat) or transferring large files at high data rates over a network (for instance transfering files to NFS mounts as some users have reported) for any period of time longer than a few minutes may cause one of two conditions to occur:
1) The system Hard Locks (no i/o response from keyboard or mouse and the display manager freezes) and needs a hard reboot.
2) The network connection freezes, but still identifies itself as having a signal and being connected. The only way I could determine to fix this was to soft-reboot the system.
This is basically a complete show-stopper bug as these are common activities.
More information:
Processor: Athlon XP 2000+
#RAM: 1GB
Video: Nvidia Geforce 6600GT using driver 100.14.19
Network: DWL-520+ run using ndiswrapper
Kernel: linux-image-rt (linux-
This occurs even when downloading to an EXT3 partition (and thus is related to networking in general and not specifically NFS). Capping torrent bandwidth will sometimes allow hours of activity of this kind, but normally it's 15 minutes or less. The system can be frozen quickly as a test by simply opening up all available bandwidth and filling it with file transfers/downloads (hence torrents causing the crash). There are three threads (possibly more) on the Gutsy Development forums.
http://
http://
http://
It would appear the common factor is wireless networking.
description: | updated |
Changed in nfs-utils: | |
status: | New → Invalid |
Changed in linux: | |
status: | Confirmed → New |
tags: | removed: bittorrent freeze gutsy hang lock network nfs wireless |
tags: | added: lucid |
I have tested this with both the -rt and -generic kernels and with and without Nvidia as the display driver (in case it was some kernel module craziness). The result is the same in both, although turning off Nvidia causes the length of timeof contiguous high network activity needed before a hang to increase.
Tomorrow I will attempt to boot with an older kernel and see if I have the same result.
Beyond that I have no idea how to trace this further.