Description of problem: Usb stops working well when using SMP kernel. Only happens after a couple of days of use. Mouse would be very choppy as if the system was under extreme load. We determined the system was not under extreme load because the applications would respond quickly and top should nominal CPU and memory usage. Catting /dev/input/mouse{0,1,2} would give output at approximately 1 second intervals. Problem has not occurred on non-smp kernel. Version-Release number of selected component (if applicable): Has happened on FC4 kernel-smp releases from 1656-2069, have not extensivly tested on older releases. How reproducible: Happens reliably after 2-3 days of continued use. Steps to Reproduce: 1. Install smp kernel 2. Boot smp kernel 3. Use regularly with several USB devices (in our case 3 mice, 3 keyboards) Actual results: Mouse movement unexpectedly become erratic. To our knowledge Expected results: Computer should continue working normally even after several days of use. Additional info: While problem occurring, we plugged in a USB audio headset and noticed there was intermittent sound (cat /boot/vmlinuz > /dev/dsp) Plugged in a PS/2 mouse and found it worked well (by cat'ing /dev/mice) CPU is Athlon X2 Dual Core 4200+.
Just had the problem on smp kernel 2.6.17-2139. It had been up for 9 days.
USB is my area, but I didn't take this bug because I have no clue what it might be. The USB stack has no 1 to 2 second periodic activity. Also, there are no other reports of similar symptoms. Laurie, why don't you attach a dmesg? Maybe something would click after seeing it. Please do not drop it into the comments box.
Ok. We're using the normal kernel right now because the problem was driving us crazy. We'll reboot into smp-2.6.17-1.2142 when we get a chance.
Created attachment 133437 [details] the output of dmesg from while the problem was occuring with smp kernel 2.6.17-2142 Ok, this time it look only about 1 day for the problem to happen. There is absolutely nothing to indicate what happened in dmesg, but I'm attaching it anyway. The very last line is from yesterday. Please let me know what other debug information I can provide.
Created attachment 134349 [details] Dmesg from machine with problem occuring An SMP kernel accidentally got installed on a UP machine. The problem appeared almost instantly. Kernel is 2.6.15-1833smp. Athlon 64 3200+ on a Asus A8V. Dmesg attached.
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
We have never deployed FC5, we're still using FC4 here. We still use the UP kernel because the SMP is unusable. We're getting ready to deploy with FC6 and that kernel works well. We will still have a lot of deployed FC4 machines out there well into 2007, so we'd love to see this problem fixed but we're not holding our breath ;-)
For FC4, this is never going to be fixed, as it's now in the hands of the Fedora legacy project, who only do security updates. As it's working in FC6, and the latest FC5 update kernel is very similar, this should be fixed in current releases.