Red Hat Bugzilla – Bug 163327
Mouse input causes change in network data tranfer rate
Last modified: 2007-11-30 17:11:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4
Description of problem:
I'm on a 10Mb/s LAN, I don't know which component causes this- I use gnome, and I've tried in KDE only to find the following...
Somehow my network data tranfer speed -downloads and surfing the web, using yum- is dependent on my mouse input. If I use my usb mouse and download something the download sustains at 200KB/s IF I do not touch my usb mouse. IF I move my usb mouse fast, I can get the transfer rate up to 1100KB/s. I've tried unplugging usb mouse, restarting and using touchpad... If I donload something the sustained tranfer rate is only 50KB/s if I do not touch the pad. If I drag my finger fast across the pad, I can get it up to 70KB/s
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Plug in USB optical mouse
2.Start computer-Fedora 4
4.Dowload a file- http://redhat.secsup.org/fedora/core/4/i386/iso/FC4-i386-disc1.iso
5.Do not move USB mouse
6.Watch tranfer rate fall to 200KB/s
7.Move usb mouse as fast as I can for 30 seconds
8.Watch as transfer rate rises to 1100KB/s, stop moving usb mouse
9.Watch for 1 minute as the transfer rate falls back to 200KB/s
10. And so forth, I can goback to step 7 and repeat...
Actual Results: As stated above.
Expected Results: Network data transfer rate should not be dependant on mouse input. I should be able to get sustained transfer rates of 1100KB/s or higher without having to move my usb mouse super fast.
I don't get any error messages.
I am using an updated kernel, version: 2.6.12-1.1390_FC4
[This comment has been added as a mass update for all FC4 kernel bugs.
If you have migrated this bug from an FC3 bug today, ignore this comment.]
Please retest your problem with todays 2.6.12-1.1398_FC4 update.
If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..
mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
I upgraded to the new kernel: 2.6.12-1.1398_FC4
I still have the same problem, the speed I move my mouse somehow changes my
transerfer rate. The faster I move my mouse, my transfer speed will increase.
I'm compiling the 184.108.40.206 kernel from kernel.org and am tweaking out my laptop,
I've noticed the Broadcom 4400 support is experimental for my Broadcom BCM4401
network card. Could this be a reason why I have the problem? I don't know what
the Fedora Kernel 2.6.12-1.1398_FC4 support has for the network card, but if it
also experimential I would think it may be the problem.
FIX (sort of):
I may have discovered that my network problem was tied to my partitioning setup.
I've installed Fedora 4 many times all to this point without LVM. However, I
cleanly installed Fedora 4 and have a 25MB boot, and 40GB LVM (39 GB root, 1GB
swap). My page loads are fast and I get sustained downloads of 1MB/s - what I
should get. So the mouse input/network speed is some weird anomoly that happens
I honestly can't think of any possible connection between the use of LVM and
the behaviour you describe. That definitely is wierd.
The earlier description sounded like a case of a mismatch between what
hardware interrupt line is in use and what line the driver is monitoring. In
a case like that, if the mouse was using the same interrupt line as the driver
was monitoring, then moving the mouse might cause the driver to respond to
incoming network traffic that it might otherwise not see.
If you install FC4 (or later) again and see the network/mouse behaviour, I'd
recommend that you try adding "acpi=noirq" or "acpi=off" to the kernel command
line. Sometimes broken ACPI BIOSen can cause interrupt mapping failures like
I described above.
In the meantime, I'm not sure what to do with this entry. I think I will
close it for the time being. Please reopen it if/when the problem comes back.