Description of problem:
Very often, and with this i mean every few hours, my keyboard and mouse, which
are both connected thru USB, stop responding ..mouse cursor is gone, keyboard is
nothing but a dead slab of plastic, completely no input accepted from them at all.
Version-Release number of selected component (if applicable):
I'm not sure if the kernel is the right place to file this bug, but it was my
best guess of where the problem could be..
Every few hours, or more often
Steps to Reproduce:
1. Login to fedora
2. type, surf, mail
3. *goodbye mouse and keyboard*
The system is a (stock) Dell XPS600, it has a nVidia Intel SLI motherboard, with
its standard usb keyboard and mouse.
This problem has existed, well ever since i got the system about 6 months ago,
and i've never been without it..
Unfortunatly sometimes it doesn't happen for hours, and another time in a few
minutes since logging on .. and i haven't been able to put my finger on it just
yet what set of circumstances triggers it, if you have any information on how i
could gather more information, i'd gladly do so.
Machine it self is not frozen, all running processes keep running, only keyboard
and mouse are lost.
lspci gives me the following information:
00:00.0 Host bridge: nVidia Corporation Unknown device 0071 (rev a3)
00:00.1 RAM memory: nVidia Corporation Unknown device 007f (rev a1)
00:00.2 RAM memory: nVidia Corporation Unknown device 0075 (rev a1)
00:00.3 RAM memory: nVidia Corporation Unknown device 006f (rev a1)
00:00.4 RAM memory: nVidia Corporation Unknown device 00b4 (rev a1)
00:01.0 RAM memory: nVidia Corporation Unknown device 0076 (rev a1)
00:01.1 RAM memory: nVidia Corporation Unknown device 0078 (rev a1)
00:01.2 RAM memory: nVidia Corporation Unknown device 0079 (rev a1)
00:01.3 RAM memory: nVidia Corporation Unknown device 007a (rev a1)
00:01.4 RAM memory: nVidia Corporation Unknown device 007b (rev a1)
00:01.5 RAM memory: nVidia Corporation Unknown device 007c (rev a1)
00:01.6 RAM memory: nVidia Corporation Unknown device 007d (rev a1)
00:02.0 PCI bridge: nVidia Corporation Unknown device 007e (rev a2)
00:04.0 PCI bridge: nVidia Corporation Unknown device 007e (rev a2)
00:09.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a4)
00:0a.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a4)
00:0a.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:0b.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:0b.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a4)
00:0d.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio
Controller (rev a2)
00:0f.0 IDE interface: nVidia Corporation CK804 IDE (rev f3)
00:10.0 RAID bus controller: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:11.0 RAID bus controller: nVidia Corporation CK804 Serial ATA Controller (rev f4)
00:12.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:13.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:17.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7800 GTX]
03:04.0 Multimedia audio controller: Creative Labs SB X-Fi
03:0a.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000
04:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7800 GTX]
i'll attach a lspci -v and boot dmesg, to long to include in the bug
Created attachment 133680 [details]
lspci -v output
lspci -v output
Created attachment 133681 [details]
Created attachment 133682 [details]
Does the system remain operating otherwise, e.g. can you log in over the network?
Is this dmesg in comment #2 taken after the problem occured or before?
I need the one after the problem.
The computer is otherwise still fully functional.
unfortunatly the dmesg attached is before the event, and doesn't include the
error messages (if any?)
I've added ssh to my startup, and next time it happens i'll save the dmesg and
attach it to the bug.
Lets hope it 'freezes' soon! :-)
It took a day for it to freeze, i guess it was feeling somewhat shy..
However when i happily fired up ssh, i got a 'connection reset by peer', and
To make sure the box was alive i tried the old
# DISPLAY=mybotherbox:0 xeyes
and indeed both network and X were still working perfectly (aka got the xeyes on
the 'froozen' computer)
Hmm might have to make a cronjob that saves dmesg every minute to a temp file or
something .. Any other clever sugestions how to get the required debugging
information in this situation?
Created attachment 133988 [details]
Created attachment 133989 [details]
Created attachment 133990 [details]
My usb mouse never works. I can see from the dmesg output that it gets
recognized, but it still doesn't work.
I have tried plugging it into both the docking station and directly into the
laopt (a dell latitude d810).
I have attached the output of lsmod, lspci, and dmesg.
Another small thing: The usb mouse works perfectly fine from the terminals
(ctrl-alt-f1). So gpm seems to find it.
And it isn't just the mouse. My usb memory stick doesn't work either. I haven't
tried so sync my palm over usb yet, but I will try that later.
My usb mouse problems have been fixed. I found out that it was simply because
xorg.conf lacked an entry for my mouse.
I have similar problem with mouse cursor disappearing on boot after the nVidia
splash screen. Hitting reset and going through cycle again usually brings cursor
back. Once on it stays on. This works with PS-2 mouse. USB mouse more
problemetic, may not work after reset, halting at text type login. Checked
xorg.conf and mouse entry missing. What would be the parameters for a Logitech
USB optical mouse? Thx
I'm having the exact same problem as the original poster, so I'll include my
hardware and log files. Let me know if there is anything else I can provide or
The keyboard and mouse are recognized properly and work for awhile. Then, after
5 minutes to an hour or two, one or the other or both cease to function.
Unplugging the offending device and moving it to another USB port gets it
working until the problem happens again. The rest of the machine usually
continues to function normally (even finishing a yum update a few times),
although I have had two complete freezes requiring me to cut the power.
I get "drivers/usb/input/hid-input.c: event field not found" errors in
/var/log/messages that seem to coincide with a failure.
Occurs in runlevels 1, 3, and 5. The machine is a Dell Dimension E521 with an
AMD Dual Core Processor (thus SMP). It has no PS/2 ports. The keyboard and
mouse work fine under Windows XP.
This ocurred under FC5 and now with a newly installed (not upgraded) FC6 (kernel
Created attachment 140954 [details]
Output of lsusb -v
Created attachment 140955 [details]
Contents of /var/log/messages from failure to finish of subsequent reboot
This would appear to be an instance of
I have successfully used the workaround of plugging the
keyboard and monitor into an external USB hub.
Note that there is a link to the Dell support forums
which point out that there is a WindowsXP patch which
fixes the same problem on that platform. Thus, it would
appear to be a quirk or flaw in the USB chipset that can
be fixed in the Linux driver too.
Hello. This problem is HUGE!
It happens with all Dell using nvidia nforce 430 chipset (Dimension C521 and
E521), as reported by many people.
Here is the Dell forum thread about this issue. Lot of info:
I´m not an expert in linux or anything, but I love fedora core. After some
struggle, I´ve converted a friend of mine into switching to fedora core. He has
a Dell Dimension C521 with nforce 430 chipset (AMD 64 3500+). It was very
frustrating... I couldn´t get the mouse to work properly and alsa support for
the onboard soundcard. Impossible to work. Mouse freezes a lot. And then you
have to unplug and plug it back in order to get it running again.
I know it´s not a Fedora specific issue, but I´m very sorry to say I had to
listen something like: "If it was Windows, it would be working already...").
Urgh, what a sad thing to hear... And I had to remain in silence, because, as
mentioned above, yes, Dell has put a driver update for windows in their website.
It´s very sad they don´t pay the same attention to linux users. Anyway, I hope
developers get it working soon! Because once I´ve used fedora I just cannot go
back. It´s a one way trip!!! And I was just recruiting another soldier...
Here is also a lot of useful info about this problem:
Please, I´m not an expert in linux or anything, so if you could please tell me
what info I should post here (from the Dell C521) to help solve the problem, I´d
grateful and happy to help.
Try booting with 'acpi=noirq', I have not seen any mouse problems yet when using
tried it but... mouse still freezes in some time
Someone on the Dell Forums reported solving problem with the following boot args:
On my Dell E521 "acpi=noirq" causes the kernel to hang very early in its
initialisation, just after the "NET: Registered protocol family 2" message.
This is with the current FC6 kernel (2.6.18-1.2849.fc6). The previous kernel
(build 2798) seems to work okay, although I haven't tested it for long.
The "usb-handoff i8042.nomux" argument also seems to work, but I haven't tested
for lenghly periods either.
Actually, it doesn´t work, as reported later in the same forum:
"YES! It works like a charm... Very good hint, no further hardware needed.
Perfect solution. After one hour without mouse/keyboard hanging and no
registered side effects I will take this as permanent solution.
Thanks in advance
EDIT: Sorry, but after writing this post, Murphi's law occured here. Mouse hangs
and keyboard after a while, too.
My Linux distribution is Fedora Core 6, Kernel 2.6.18-1.2849. I also noticed,
that keyboard hangs, if there is heavy hdd access like makewhatis.cron-weekly...
Message Edited by noisefan on 12-11-200602:55 AM"
"This "usb-handoff i8042.nomux" failed also for me.
But I use now a USB hub, externally powered. And everything works fine : SMP,
sound, CD burning. Moreover the mouse and keyboard are recognized at the
beginning and I can switch between Linux and XP with no problem."
I'm seeing the same kind of behaviour of erratic/total-failure of my
USB connectivity (Logitech USB mouse) with RHEL5 Beta 2.
I will give the "usb-handoff i8042.nomux" option a go in grub.conf
I also think, another path to look at this issue, is that we are nearly
all experiencing this problem on laptops, that have integrated USB Storage
(SD/MC/CF/etc...). What if the kernel tries to access these USB storages
and fails after a while and crashes the USB connectivity ?
*** Bug 215539 has been marked as a duplicate of this bug. ***
I am having the same USB mouse and keyboard issues:
Turion 64 x2
USB mouse and keyboard
I am suspecting this is a BIOS issue related to USB hardware power management.
(In reply to comment #27)
> I am suspecting this is a BIOS issue related to USB hardware power management.
I think it has something to do with it.
But the point is: it was happening with Windows XP also, but DELL has put a <a
update</a> in their website that solves the problem...
So it makes you wonder wheter it´s a BIOS problem or a OS problem...
This appears to be primarily a Dell E521/C521 issue.
I to have a Dell E521 running 2.6.18-1(.2868.fc6) which I have to boot with
noapic. I have disabled the integrated NIC, using a PCI card; but my mouse still
However, when I navigate to a different virtual desktop using the keyboard
(ctrl-alt-arrow) and come back again the mouse works again (everytime).
When I look at /proc/interrupts it seems the keyboard (ehci_hcd:usb2 ??) and
eth0 are on the same IRQ:
5: 515 61 XT-PIC ehci_hcd:usb2, eth0
15: 735 142 XT-PIC ohci_hcd:usb1
This guy experience at DELL forum shows it´s not as issue of IRQ sharing:
I have a C521 with AMD X2 3800+. I am running FC6 (1.2868) i686.
I haven experiementing with this issue. Right now I am booted
maxcpus=1. My mouse locked up and I found that I could get it back
by unplugging and reinserting the usb mouse connector. The following
is from /var/log/messages:
Dec 24 07:10:42 bluefin kernel: usb 1-4: USB disconnect, address 4
Dec 24 07:10:43 bluefin kernel: ohci_hcd 0000:00:0b.0: IRQ INTR_SF lossage
Dec 24 07:10:45 bluefin kernel: usb 1-4: new low speed USB device using ohci_hcd
and address 5
Dec 24 07:10:45 bluefin kernel: usb 1-4: configuration #1 chosen from 1 choice
Dec 24 07:10:45 bluefin kernel: input: USB Optical Mouse as /class/input/input3
Dec 24 07:10:45 bluefin kernel: input: USB HID v1.11 Mouse [USB Optical Mouse]
Hello, I think there's interesting info here:
Note: There has been a release (1/1/07) by Dell of BIOS version 1.1.4 which has
been reported to fix the problem with mouse/keyboard problems. I have installed
and will report if problems occur.
Thanks, Matt. However, it's unusual for Dell to name releases in this way.
Is there an A-number for it?
Hello, guys! Does it solve the problem?? Any info??? How long did the mouse
stand solid and up?
In dell's page there´s this information about the bios update:
Fixes and Enhancements
The following changes were made to BIOS revision 1.1.3 to create 1.1.4:
1. Fixed issue where the USB keyboard would not work in the front ports when a
USB 2.0 hub was connected in rear USB port 2.
2. Reverted back to Nvidia integrated video BIOS from version 220.127.116.11.18 to
18.104.22.168.00. Video BIOS version 22.214.171.124.18 caused a Dell Diagnostics video
3. Updated AMD Agesa code from revision 2.6.11 to 2.8.00
Still testing but I experienced no USB disconnects so far (flashed my bios
yesterday in the morning, worked for 6-7 hours without problems). I think there
is a good chance that this bug can be closed as CANTFIX soon.
I'm sorry I don't agree with the bug can be closed.
This issue does not affect only Dell laptops. I'm using SAGER 9750 (AMD Athlon
64 X2). And I don't expect this company SAGER or CLEVO to release a BIOS fix
like Dell does.
This bug belongs to Chris. He has a specific failure case. Everyone else just
creates noise here, which may be helpful, but most often not. In 95% cases
random USB keyboard lockup is a BIOS bug.
If Erik has a specific failure case, he needs his own bug, which almost certainly
will get tracked to a different root cause than this bug.
I'm new at trying to load linux. Been working with
RedHat version RHDesktop-U4-x86_64 for my Dell Dimension E521 (AMD dual core
3800). Vista runs fine (as Vista goes). For RedHat I get a kernel panic (- not
syncing: PCI-DMA: high address but no IOMMU) if eth0 is enabled and a lockup
after login prompt if it is not. Got the "Bios Bug 8254 time not connected to
IO-APIC" at boot time. I'm having trouble understanding RedHats nomenclature.
Should I load version 5? Should I load Fedora? Any help would be appreciated.
As it stands now, I can't even do an "ls".
Jeff, have you tried to boot with noapic option in the kernel line?
Been away from my Linux box for awhile. With latest batch of updates (April 6 +)
my issues have been resolved
The noapic option worked for me. Finally got Grub working on a dual boot system
after a Dell Utility wiped out linux and erased the boot OS of Vista. I.E. on a
Dell Dimension E521, don't set Grub to boot from the 1st partition on the Vista
disk because the Dell Utility will make both OS's unbootable.
Chris, what is the situation now at the original requestor's end?
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.