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.. How reproducible: 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: # lspci 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] (rev a1) 03:04.0 Multimedia audio controller: Creative Labs SB X-Fi 03:0a.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) 04:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7800 GTX] (rev a1) 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] dmesg output dmesg output
Created attachment 133682 [details] lsmod output lsmod output
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 couldn't login. 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] lsmod output
Created attachment 133989 [details] lspci output
Created attachment 133990 [details] dmesg output
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 test. 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 2.6.18-1.2798.fc6).
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 http://bugzilla.kernel.org/show_bug.cgi?id=7397 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: http://forums.us.dell.com/supportforums/board/message?board.id=sw_other&message.id=54328&view=by_date_ascending&page=1 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: http://forums.fedoraforum.org/showthread.php?t=136879&page=1&pp=15 And here: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/67734 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 this option.
tried it but... mouse still freezes in some time
Someone on the Dell Forums reported solving problem with the following boot args: usb-handoff i8042.nomux
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 Mike 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." http://forums.us.dell.com/supportforums/board/message?board.id=sw_other&message.id=54328&view=by_date_ascending&page=12
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: HP dv6110us Turion 64 x2 Nvidia graphics USB mouse and keyboard I am suspecting this is a BIOS issue related to USB hardware power management. http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1083861
(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 href="http://support.dell.com/support/downloads/download.aspx?c=br&l=pt&s=gen&releaseid=R132919&SystemID=DIM_P4_C521&os=WW1&osl=EN&deviceid=9843&devlib=0&typecnt=1&vercnt=1&formatcnt=1&libid=27&fileid=176721">driver 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 freezes regularly. 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: CPU0 CPU1 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: http://forums.us.dell.com/supportforums/board/message?board.id=sw_other&message.id=54942#M54942
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] on usb-0000:00:0b.0-4
Hello, I think there's interesting info here: http://www.talkshopbot.com/forum/show.cgi?tpc=26&post=43074#POST43074
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 5.51.28.50.18 to 5.51.28.42.00. Video BIOS version 5.51.28.50.18 caused a Dell Diagnostics video test failure. 3. Updated AMD Agesa code from revision 2.6.11 to 2.8.00 http://support.dell.com/support/downloads/download.aspx?c=br&l=pt&s=gen&releaseid=R142795&SystemID=DIM_P4_C521&os=BIOSA&osl=EN&deviceid=308&devlib=0&typecnt=1&vercnt=4&formatcnt=1&libid=1&fileid=190570 Thanks!
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. http://fedoraproject.org/wiki/LifeCycle/EOL 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 the change. 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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.