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): How reproducible: Always Steps to Reproduce: 1.Plug in USB optical mouse 2.Start computer-Fedora 4 3.Open Firefox 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. Additional info: 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 kudzu Thank you.
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 2.6.12.3 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 without LVM.
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. Thanks!