Most recent kernel where this bug did not occur:2.6.14
Distribution:Ubuntu Dapper, Ubuntu Edgy, SUSE 10.1
Hardware Environment: Dell Dimension E521, nVidia nForce 430 chipset, AMD64 X2,
various USB mice.
Distribution and mainline kernels above 2.16.14. Compiled for i386 and K7, with
and without SMP.
Problem Description: The USB mouse pointer freezes, while using it, after a
while. The keyboard keeps working, screen output is unaffected. Happens in X,
but also in a text console when running gpm. Unplugging the mouse, then plugging
it back regains control of the pointer, but only for a while.
Steps to reproduce:
load gpm -m /dev/psaux -t imps2 in a TTY
move around for a while
the pointer eventually freezes
use it for a while
the pointer eventually freezes
unplug and replug the mouse
the pointer works again
The freezing of the pointer is not detected
Unplugging and replugging is detected
Upon replugging, a new USB device is added, with a higher number than before.
I have a cabled USB mouse AND a wireles USB/mouse combo. The combo mouse was
frozen. The wired mouse freezes. I unplug and replug the wired mouse, and these
lines are added to dmesg output:
[17227523.580000] usb 1-7: USB disconnect, address 15
[17227527.904000] ohci_hcd 0000:00:0b.0: IRQ INTR_SF lossage
[17227528.336000] usb 1-8: new low speed USB device using ohci_hcd and address 16
[17227528.564000] input: Logitech USB Mouse as /class/input/input19
[17227528.564000] input: USB HID v1.10 Mouse [Logitech USB Mouse] on
The wired mouse works again. After a while, it freezes, so I now choose to
unplug the wireless combo:
[17229037.284000] usb 1-5: USB disconnect, address 8
[17229041.612000] ohci_hcd 0000:00:0b.0: IRQ INTR_SF lossage
[17229041.916000] usb 1-5: new full speed USB device using ohci_hcd and address 17
[17229042.148000] input: Logitech USB Receiver as /class/input/input20
[17229042.148000] input: USB HID v1.11 Keyboard [Logitech USB Receiver] on
[17229042.156000] input: Logitech USB Receiver as /class/input/input21
[17229042.156000] input,hiddev96: USB HID v1.11 Mouse [Logitech USB Receiver] on
Now I can move the pointer again with the wireless mouse, but not with the wired
unit. Let's unplug/replug the wired mouse too; these lines are added
[17229621.532000] usb 1-8: USB disconnect, address 16
[17229625.532000] ohci_hcd 0000:00:0b.0: IRQ INTR_SF lossage
[17229626.148000] usb 1-8: new low speed USB device using ohci_hcd and address 18
[17229626.376000] input: Logitech USB Mouse as /class/input/input22
[17229626.376000] input: USB HID v1.10 Mouse [Logitech USB Mouse] on
Created attachment 9368 [details]
Several users on DELL forum confirm the bug on E521 and C521 systems with many major distros
Shows it is widely experinced...
Ubuntu Edgy with its kernel 2.6.17 boots up with the mouse pointer AND KEYBOARD
already frozen, and unplugging/replugging does not free them. However, if the
mouse and keyboard are plugged into a hub, instead of directly into the PC, then
they work OK when the system boots.
I have not had the chance to test this but for a very short period of time, so I
cannot say that they won't lock later on, but I'll test more and then report my
If anybody listening would like me to do any concrete tests and post any
concrete results, please, ask me.
I have given it more testing, and as far as I've seen, both 2.6.15 and 2.6.17
work OK when the mouse and keyboard are plugged into a USB hub.
Plugging kbd and mouse into a hub did not work for me with 2.6.16 or with (from
the SuSE 10.2 beta) Linux knossos 18.104.22.168-8-default #1 SMP Fri Oct 20 12:25:45
UTC 2006 i686 athlon i386 GNU/Linux -- if anything the symptoms seemed more
There are reports (see http://ubuntuforums.org/showthread.php?t=279626 comment
39) that this has to do with the way power is managed, that when the processor
takes a lot of power the USB ports are given less... or something. The poster
indicated that this was managed by the kernel, which seems fishy to me.
Supposedly this is confirmed by plugging the mouse into external, powered USB
hubs. Since they have their own power source the lockups don't occur.
That is nonsense. Power is definitely not the problem. With just a keyboard and
a mouse plugged in the USB ports (or even with just a receiver from a combo),
the problem happens, and the system does not have to be doing anything intensive
at all -- unless moving the pointer about is too much work for an Athlon X2 to
Also, if there was too little power, how come in the combined wireles
mouse/keyboard the keyboard kept working all the time but the mouse died? And
how come when the keyboard and the mouse were two different USB devices the
keyboard keept working and only the mouse freezed, and then came back to life
Well yes, *I* would question the power drain theory on the grounds that I would
expect the hardware to handle power levels. But then, I know next to nothing
about the inner workings of USB. For all I know some particular work of the
machine causes it (through software or hardware) to lower power delivered to the
Whatever the reason, though, I have verified the suggested workaround of
operating through a powered USB hub. Others have claimed that unpowered hubs
don't fix the problem, which lends support to the whole power management theory.
But again, I'm not in any way claiming that to be the actual cause. I'm only
repeating a theory suggested elsewhere.
Maybe I didn't make myself clear: my mouse and keyboard are a Logitech wireless
combo with just ONE device, the receiver, plugged into jus ONE port. There is no
way that power could fail to the mouse but not to the keyboard, but still the
mouse pointer freezes while the keyboard keeps working. And, as you say, if I
plug the receiver into a hub, then there is no mouse lockup.
And If I plug a second mouse when the first one freezes, the second mouse works
perfectly for a while, which would indicate it is receiving enough power. And if
the two mice are plugged in since the beginning, only the one in actual use
freezes, and the other keeps working for a while after the first one has locked up.
If you know nothing about the internal workings of the USB, rest assured that it
provides far more power than enough for one mouse and one keyboard. If you don't
trust me, google for the specs.
I have the same issue, Dell Dimension C521n with Athlon64 X2 3800+.
Plugging the mouse on a powered USB hub did NOT resolve it for me. Plugging it
in the from USB slots didn't either.
Sometimes USB my keyboard also locks up / freezes. But it is less frequent.
Running Mandriva 2007 x86_64 version kernel package
- ACPI DISabled
- APIC ENabled
- Local APIC ENabled.
My hardware list states the USB controller is a:
Vendor: ‎nVidia Corp.
Description: ‎MCP51 USB Controller
Media class: ‎SERIAL_USB
Bus PCI #: ‎0
PCI device #: ‎11
PCI function #: ‎0
Vendor ID: ‎0x10de
Device ID: ‎0x026d
Sub vendor ID: ‎0x1028
Sub device ID: ‎0x01f4
And a second one listed as:
Vendor: ‎nVidia Corp.
Description: ‎MCP51 USB Controller
Media class: ‎SERIAL_USB
Bus PCI #: ‎0
PCI device #: ‎11
PCI function #: ‎1
Vendor ID: ‎0x10de
Device ID: ‎0x026e
Sub vendor ID: ‎0x1028
Sub device ID: ‎0x01f4
Kernel folk please give this bug/issue attention, for it is extremely annoying
I have a C521 from Dell with AMD Athalon X2 3800+ and the nvidia chipset.
I found that if I boot w/o argsI get error messages of "MP-BIOS bug: 8254
..." and I get only 1 CPU on-line. If I boot with "nolapic" I get other
messages and only one CPU on-line. However, my mouse seems to work reliably.
If I boot with "acpi=off" I get two CPUs but the mouse hangs. I have been
running Fedora Core 6 with 2.6.18-1.2798.fc6 (i386). Today I upgraded to
2.6.18-1.2849.fc6 but have not tried with "acpi=off".
This is looking like hardware configuration issue.
Dell released an "urgent" patch for the nVidia SMBus driver.
Also, someone on the Dell forums was able to get a stable
system by recompiling the kernel with Athalon optimizations.
I compiled a pristine 22.214.171.124 kernel using the config file used by Ubuntu Edgy
2.6.17 kernel; the only option I changed in the config menu was selecting
optimisation for Athlon. There were no nasty surprises during compilation, and
everything worked fine the first time.
I unplugged the USB hub and plugged my wireless mouse/keyboard combo directly
into a USB port and rebooted. My computer booted the new kernel just fine, and
unlike Edgy's 2.6.17, it reached GDM with a fully functional mouse and keyboard,
which was already an improvement on the previous situation (reaching GDM with
BOTH already locked).
I have not given it very extended use, but have used it for about 45 minutes
with no apparent problems, which I don't think I ever could with Dapper's kernel.
What I don't know is what functionality have I given up by not running Ubuntu's
kernel. What patches have they added to 2.6.17 that are absent from 126.96.36.199?
I'll give it more testing and report my findings. If 188.8.131.52 is really solid,
then the problem might be already cured in the kernel, and what would be missing
would be identifying and backporting the changes to whatever previous kernel
version the distributions are using.
184.108.40.206 has run in my system for a whole day, and I've been actively using it
for about three hours, with no mouse or keyboard lockups.
With the vanilla 220.127.116.11 kernel compiled myself on FC5 my USB devices freezed,
too. However, they don't with an external powered USB-hub.
Furthermore, my PCI wifi device (D-Link DWL-G520, driver madwifi 0.9.2)
sometimes just lost the connection to the access point without any error message
in dmesg and I couldn't reestablish it until a reboot, after which it worked as
usual until the next freeze. Meanwhile, the onboard ethernet chip (Broadcom
4401) works ok.
I have a Dell C521, AMD 64 3200+ (single processor) and have installed SUSE
linux 10.1, X86_64, Kernel 18.104.22.168-0.25.
The mouse froze constantly in this distribution as well as Ubuntu and Fedora
6.0. I was going to try a PCI Serial/PS2 card, but have not been able to find
one. As an alternative, I connected a Belkin USB hub (powered) between the
keyboard/mouse and the usb port on the back of the computer. That appears to
have solved the problem for me. I installed the Gnome desktop in Suse 10.1 and
have played lots of games including breakout which is very mouse intensive.
There is no evidence of any mouse problem or keyboard problem with the USB hub
between my mouse and keyboard, and the C521.
The actual hub installed is a Belkin powered hub made for the Mac Mini (Apple)
but I'm sure its electronically the same as any of their current hubs.
This will have to be the bandaid I use until the original problem with the Dell
hardware is solved. (Either through a Bios update, or a Linux kernel fix.
Same problem with dell c521 - nvidia 430 chipset. AMD athlon64 3200
more info here -
I have the problem on gentoo kernel: 2.6.18-gentoo-r2
Same here, on a Dell Precision E521 with Debian Etch 64 bits. The only way to
boot the box was to use noapic.
Linux epona 2.6.17-2-amd64 #1 SMP Wed Sep 13 17:49:33 CEST 2006 x86_64 GNU/Linux
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
03:00.0 VGA compatible controller: nVidia Corporation GeForce 7300 LE (rev a1)
04:07.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
Same here, Dell E521, 2.6.18, 2.6.19, 2.6.20-rc1
I can confirm this as being an issue across the board on n430 USB, even on HP
In my experience, kernels 22.214.171.124 and 126.96.36.199 compiled from pristine
kernel.org sources with the default options in the Ubuntu Edgy setup files for
their 2.6.17 don't show the problem at all.
The kernel in OpenSuse 10.2, which is 188.8.131.52-plus-their-own-sauce also works
fine for me.
However, Ubuntu's own current compilation for 2.6.20 (available from the Feisty
Fawn repo) also has problems with USB mice locking up, although in this case
unplugging and replugging does not unlock the pointer.
It seems that whatever it is that fixes the problem was added to the incremental
changes to 2.6.18.x, but somehow it is not in 2.6.20.
Hello, there are people reporting that upgrading to Dell BIOS 1.1.4 solves the
Does anyone confirm?!
The file to upgrade the bios is avaiable here:
I have installed BIOS version 1.1.4 on my Dell C521. It has been
running 2.6.18-1.2868.fc6 i686 "acpi=noirq" for over a day without
mouse freeze. I was also able to install Ubuntu 6.10; before this
was constantly locking during the install.
I have updated the BIOS to 1.1.4 in my computer and the problems seem to have
vanished. I have installed Ubuntu 6.10 (it previously locked up during
installation), and have used it for a few hours with no problems.
I did not need to use any ACPI, APIC or LAPIC magic options in the command line.
By the way, both processors come up too (not only one, as before).
My E521 has been stable after applying the cited BIOS update.
HELLO, ADAM, what distro are you using?
FWIW, my e521 running 2.6.18-gentoo-r6 doesn't seem to have benefited from this
BIOS update. I still have only one core and the same USB issues. In fact, the
update seems to have added some annoyances with how it initializes USB devices
and my computer just completely locked up for the first time (coincidence, perhaps).
In short, this BIOS update isn't necessarily the answer...
My report.. E521 -- Success with updated BIOS and SuSE 10.1 (original and
updated 2.6.16 kernels).
Bios update fixed the problem, but now my USB hub (which I purchased to work
around the original problem) is not working anymore before the boot procedure
starts. So in order to use the keyboard for the boot menu or entering setup, I
had to plug it directly into the PC.
I am experiencing that the mouse stop working with my Sony Vaio SZ340 on a
debian etch using kernel 184.108.40.206 and also ubuntu dapper drake.
On this setup the mouse still moves around the screen, but left key clicks has
no apparent effect. The detailed information about my system is:
Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express
Memory Controller Hub (rev 03)
VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express
Integrated Graphics Controller (rev 03)
Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated
Graphics Controller (rev 03)
USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
This is odd... My bios says it's version 1.1.5, but the latest available on the
dell website is 1.1.4. Also, everyone says version 1.1.4 fixes thier problem,
but I am still experiencing it...
Also, I can't find out how to install this bios... I don't have windows
installed, and I can't get it to run on a FreeDOS disk -- says something about
Isaac Freeman: Hello, try this out:
Just wanted say this is still a problem here with my C521. I've tried bios
versions 1.1.4, 1.1.6, & 1.1.8 and all show the same problems. I've also tried
passing the different kernel parameters mentioned here and in other threads
around the net.
Additionally, once the mouse stop responding I cannot unplug it and plug it back
in like others say they can. Also, if I continue to use the computer with just
the keyboard it will lock up itself after a short while. The computer is still
responsive as I can ssh to it, but the usb ports (all 6) are totally unusable.
I'm using kernel 2.6.20 on Gentoo. If you need any additional information just ask.
I know this is a very pressing issue, only happens to some: two people next to each other with similar systems and configuration - and one has a problem and another one never does. I have similar problem except it's the keyboard that freezes and mouse never does. I can even press keyboard key but it takes "double pressure". Something to do with X too, because when my keyboard is half dead, the text console is OK, I can type just fine.
Anyway, pinging USB gods...
I have had this problem continually on a Gateway GT5056, with kernels all the way from 2.6.16 - 2.6.23, on Ubuntu Feisty / Gutsy, and Gentoo. I have a Gateway GT5056 with a custom Foxconn built for it, and they have no BIOS updates.
Once the mouse is lost, it is lost in both X & GPM. Like others, I am using a Logitech wireless mouse/keyboard combo, and the keyboard continues to work fine. Unplugging and then plugging back in simply loses me the keyboard as well, rather than restoring the mouse. Restarting XDM causes me to lose keyboard as well. No messages logged in dmesg or /var/log/messages. I have not been able to debug with usbmon as sometimes I can go a day or two without experiencing this bug.
It does seem to involve power management somehow though. This always happens right after I hear the fans start to spin up faster. Compiling the Kernel with no ACPI/APM/cpufreq support makes no difference. Starting with noapic, acpi=off, acpi=noirq etc. makes no difference.
Is there anybody listed on this bug who is willing & able to try out various kernel patches and do some serious testing?
There are so many different and conflicting reports above that it's impossible to sort them out. Any real work will have to be some with only a single person, somebody who can reproduce the problem fairly reliably and quickly.
What's involved in the testing?
I can build a kernel.
Any heavy lifting here, or just capturing log files and applying patches and building kernels?
Just FYI: Same problem here, Randomly mouse & keyboard freezes. Just waiting some seconds unfreezes both.
ASUS P4PE motherboard, Intel 845PE chipset
CPU: Pentium(4) 2.4 GHz
microsoft kbd/mouse combo over wireless USB tranceiver stick
Interesting is, that these "keyboard freezes" even when no OS is loaded!
Just enter Bios-Setup by pressing <DEL> while POST. Then move around the setup menus with the cursor keys. After 10 to 20 seconds the kbd freezes.
That "frozen" state "thaws" again after a few seconds.
Same behavior when Linux & KDE is up. Kbd+Mouse freeze every 20 to 60 seconds.
If interrupt mode in Bios is set to PIC, the problem is as described above.
If mode in Bios is set to APIC, the system is nearly unuseable. Mouse & kbd is frozen almost all the time.
If wired PS/2 kbd + mouse are plugged in too, they are both useable while the wireless ones are frozen.
I get the most "stable" system with BIOS set to PIC and boot kernel with noapic parameter.
acpi=off parameter doesn't seem to have any influence.
Norbert, your problem is in hardware/BIOS if the mouse freezes with no OS loaded.
To all reporters:
If you still experiences problems with mouse, and you have different hardware than Nacho de las Rios, please open a separate bug.
For those who have Dell Dimension E521 - is the problem still there? There were probably updates to X server, and your distros, can you update the status on this problem please.
after upgrading to a recent BIOS version (1.1.6+) the problem seems to be no longer existant. My server is running now for about four month, whenever I use the windows system (even for hours), keyboard and mouse doesn't create any problems (except for typos, but this seems to be PLBKAC :-)).
thanks, am closing out.