Most recent kernel where this bug did not occur: 2.6.15-git10 Distribution: Gentoo, mainline kernel.org kernel Hardware Environment: amd64, dual Opteron 242 on Tyan s2885, ps2 mouse and keyboard (MS Wireless Comfort keyboard and wireless optical mouse combo -- hey, it's hardware, not software) onboard SilImage 3114 quad SATA RAID (in-kernel md driver, RAID-0/1/6 assembled from kernel command line parameters, 0 is non-partitioned, 1/6 are both partitioned RAID, LVM hosting non-root/non-usr/non-var volumes on one of the RAID-6 partitions), Primary IDE disabled, secondary hosting 1 each CD/DVD burners, 1 gig memory (NUMA, 1x512M/cpu), Radeon 9200SE AGP (rv280) dual-output card, second non-active Radeon 9250 PCI, SoundBlaster Live! sound card (onboard i810 disabled), tg3 onboard NIC Software Environment: Gentoo ~amd64 2006.0 profile, kernel compiled with gcc-4.1.0 snapshots. glibc-2.3.6-r3. binutils-2.16.91.0.1. All critical drivers including input/ps2-mouse/ps2-keyboard built-in, non-modular. Problem Description: Booting kernel 2.6.15-git11 onward, no keyboard at all. The system boots to the default runlevel without issue -- except that there's no keyboard response. Magic SysRq naturally unresponsive. However, mouse works just fine. In fact, I have one of gpm's triple-click buttons configured to shutdown, and I use it to shutdown safely. Steps to reproduce: Boot with 2.6.15-git11 onward with the above configuration. ... Traced down to the line, thanks to the BUG-HUNTING doc. Between 2.6.15-git10 and git11 the mouse polling behavior changed. If I kill the line in drivers/input/mouse/psmouse-base.c (1022 if I didn't screw up the vertical spacing): psmouse->poll = psmouse_poll; both the keyboard and the mouse work fine. None of the 2.6.16-rc's have worked for me due to this. Duncan
I meant to mention but forgot. I have legacy USB mode disabled in BIOS. I did try turning it on just to see... but no change. Duncan
Hmm, that is very weird that mouse would affect keyboard... I am also confused that killing the line you mention allows both keyboard and mouse work, because later we do: if (psmouse->resync_time && psmouse->poll(psmouse)) psmouse->resync_time = 0; and with psmouse->poll being NULL is surely oops... What if you leave the code alone and boot with psmouse.resync_time = 0? I would also like to see full boot log (/var/log/messages or /var/log/kernel - wherever you distribution stores kernel messages in) of unpatched 2.6.15-git11+ with booted i8042.debug=1. Please do not touch the mouse at all until you make sure that keyboard does not work. Thanks!
Well, the thing wasn't where I expected to find it either (I expected it'd be one of the i8042 changes, based on the changelog, but narrowed it down to the psmouse file and then the line, so... Here's the diff -C3 between git10.5 (what I call the work version) and git11, for that file: *** /usr/src/kernel/linux-2.6.15-git11/drivers/input/mouse/psmouse-base.c Sun Feb 19 09:08:32 2006 --- /usr/src/kernel/linux-2.6.15-git10.5/drivers/input/mouse/psmouse-base.c Tue Feb 21 08:59:39 2006 *************** *** 1019,1025 **** --- 1019,1027 ---- psmouse->set_rate = psmouse_set_rate; psmouse->set_resolution = psmouse_set_resolution; + #ifdef VER11 psmouse->poll = psmouse_poll; + #endif psmouse->protocol_handler = psmouse_process_byte; psmouse->pktsize = 3; If VER11 is defined, it fails. If not, it works, so it's that line... I setup a script to capture the logging info, and will be attaching the log from a regular boot (2.6.15.4), the failed git11 regular, the failed git11 with the requested i8042 debugging, and one from your resync=0 suggestion, which SUCCEEDED. Note that I'm not clear if you wanted dmesg, or the entire boot log including the kernel messages from userland init. I opted for the latter, figuring the extra info can't hurt.
Created attachment 7476 [details] bootlog with git11, psmouse.resync_time=0, works I always get those unrecognized key entries. The range for the wireless isn't that good (crap compared to a Logitech I had previously, I /had/ thought MS had good hardware, but I've NOT been impressed!), and I've always attributed it to poor reception. The Logitech didn't have the unrecognized keys issue.
Created attachment 7477 [details] bootlog with normal git11 and commandline, fails
Created attachment 7479 [details] bootlog with 15.4, normal boot, works of course. Hmm... Looks like I gotta recompile with a bigger kernel log buffer to capture the i8042 logged one. The size 15 buffer I normally run ran out of room, with all that extra logging.
The 'unknown key pressed 0xd9' and 'released 0x81' (in 2.6.15.4 log) looks very suspicious. When do they appear? If you pres specific keys, work with the mouse, or just without any outside action? Check the 'dmesg' to see when more get added.
Created attachment 7481 [details] bootlog with git11, i8042.debug=1, fails OK, the failing git11 withh i8042.debug=1. As I said, those unrecognized keys on the working ones are normal. I've attributed them to a weak wireless connection between keyboard and receiver. They started when I first plugged in this keyboard, and didn't occur before. They aren't associated with mouse movement, and seem to be connected to keyboard activity -- movement of the keyboard itself in space possibly more than actual key activity. Again, direct evidence that it's due to the weakness of the wireless signal. The keyboard and mouse both seem physically well made, as opposed to the Logitech they replaced (same pricepoint), but the Logitech's wireless connection was extremely reliable, while the MS wireless connection is crap! Maybe the MS driver for the thing implements gain control, making the connection work better on an MS software platform? <shrug> In any case, I'll not buy it again -- I'll be back to Logitech, due to the poor wireless connection with the MS kit. Meanwhile, I'm forced to cope, and that means coping with both the lost and doubled keys on the keyboard and lost clicks on the mouse, in addition to the log spam noted. Anyway, I don't believe the unrecognized key events have anything to do with this issue. They don't happen if I just leave the keyboard be, not touching it at all, yet a keyboard and mouse free boot, untouched, unmoved, is as solidly no-keyboard on 15-git11 plus, as it is recognizing a keyboard, unrecognized key events and all, on previous kernels. Duncan
According to the log, the SETLEDS command sent to the keyboard in atkbd_activate() fails, causing the function to bail out without sending the ENABLE command to the keyboard. This normally shouldn't be needed, but considering this is a rather unusual keyboard it could - SETLEDS can't normally fail either. Possibly the keyboard is out of range for PC->keyboard communication. Can you attach a similar log with the 2.6.15.4 kernel? Can you check whether removing the return -1; (and replacing it with just a ;) in atkbd_activate() helps? A log of the result would be useful, too.
Created attachment 7484 [details] bootlog with 15.4, i8042.debug=1, works Slept yesterday. Two hours in two days doesn't cut it! Here's the 15.4/working log, with i8042 debugging. Glad you guys can make sense of those numbers! atkbd_activate return -1 hacked out test coming.
Created attachment 7485 [details] bootlog with git10.5.1 (git11 modified), i8042.debug=1, fails OK, here's the debug log from the hacked out return -1 in atkbd_activate under SETLEDS. Still fails.
I also noticed taht you have an OHCI USB controller... Please amuse me and, after applying the following patch: http://bugzilla.kernel.org/attachment.cgi?id=7220&action=view reboot with usb_delay_handoff=1 kernel parameter. Thanks!
Re: comment #12: I "amused you" and tried it, on a fresh copy of 2.6.15-git11. The patch took, but unfortunately, it didn't help. You want a log, perhaps with something.debug in addition to the usb_delay_handoff=1? The only thing I have hanging off the USB is the scanner, and it's seldom on, so I could easily try disabling USB in both the BIOS and the kernel config entirely, if such a test might prove useful. I'm not sure about that handoff, but would the BIOS even handle it at all since I have legacy USB turned off in the BIOS? (I long ago read that it could complicate things and switched it from auto to off, since I'm using the ps/2 port anyway, altho I wasn't having any issues at the time, either before or after doing so.) Might I actually need to turn it /on/? I did try that before reporting the bug, as I'd seen mention of usb-handoff and decided to try it, but I didn't have the patch in at that time and wasn't exactly sure what the kernel command line parameter should look like either, so if it could help, I can try it. I could also /try/ the keyboard as USB, turning on legacy of course to do so. I've tried the mouse as USB and know it works (or worked, several kernels ago) that way, but switched back to ps/2 out of convenience and familiarity. I've never actually tried a USB keyboard, on this or previous machines, so it might be interesting trying to get it setup, but assuming I don't run into any issues with that, I could try both on USB, or easier since I've tried it before, mouse on USB, leaving the keyboard on ps/2, and disable ps/2 mouse, to see if that changes things, if the results would provide useful info. Duncan
OK, .16-rc6 boots with a working keyboard now, as I expected it would after reading the psmouse disable autoresync changelog entry. Should this be closed now or wait for a "proper" fix with .17 or whatever? If we're still going for a "proper" fix, do my suggestions for further testing in the previous comment look reasonable, or are they obviously headed the wrong way. Besides being busy, I've been sort of waiting for a helpful or not hint on that. Duncan
I have FC5 kernel 2.6.16.2. I downloaded that kernel removed psmouse->poll = psmouse_poll; from rivers/input/mouse/psmouse-base.c and i still can not use my PS/2 keyboard. Can you please advise me further. I will send to you any file you want Thank you
Please boot with i8042.debug on unpatched kernel and post your full dmesg.
Created attachment 7836 [details] Dmesg after booting with i8042.debug Hello, i did as ou told me. I booted only with PS/2 keyboard. I get to login screen and then i can not write any thing, with my PS/2 keyboard. So i attached an usb keyboard Dell. You will see that at the end of the dmesg file.
Hmm, i8042.debug did not work for some reason... Could you please repeat with i8042.debug=1 (this is a bool parameter so the first form should have worked, I wonder if we broke bools at some point).
Created attachment 7843 [details] this file was generated with 'dmesg more > dmesg1.txt' Hi, i did as you told me. I also checked the file documentation/kernel-paramters.txt and i found no option i8042.debug. Thx
hi guys, any thing new in this bug. I today installed kernel 2.6.16.5 and still the same problem. I would like to point out that when i strated the installation process of FC5, i come to do you want to test the DVD and there a can not (with PS/2) change to skip nor advance. Now my FC5 comes to login screen and there i can not write anything.So i can not login. I tried with i8042.debug=1 it gives no difference
So here is the reason why keyboard does not work - the kernel can't talk to the keyboard controller at all: PNP: PS/2 Controller [PNP0303:KBD] at 0x60,0x64 irq 1 PNP: PS/2 controller doesn't have AUX irq; using default 12 drivers/input/serio/i8042.c: 20 -> i8042 (command) [0] i8042.c: Can't read CTR while initializing i8042. Disabling ACPI might help but I don't think it's a good solution ;) Hmm, try commenting out "DECLARE_PCI_FIXUP_FINAL" line at the very end of drivers/usb/host/pci-quirks.c Has this box ever worked with 2.6 kernel?
Man zou are the best. That actualz worked. Now i am writing you this message with the PS/2 keyboard. Hey i would like to get involved in writing dirvers for linux kernel. If you have some good starting point just tell me. I say the best way of learning is trying see you man
I think i spook to fasf. I have my PS/2 keyboard now but i have no sound. Can you tell me what to do. I hope this bug is not one of those."You can't have your cake and eat it." Everything boots up good, only no sound. I tried with alsamixer nothing is muted there. I tried with soundcard-detection, it does not work.
Ok. sound is worknig now. I had to reinstall alsa.
Hi, I had just a simillar Problem. Since 2.6.15 mouse and keyboard would not work anymore (used to work fine with 2.6.14). As for new udev I needed a Kernel >= 2.6.15. I read this discussion so far and after removing the "DECLARE_PCI_FIXUP_FINAL" line at the very end of drivers/usb/host/pci-quirks.c it just works fine again. But I wonder whether I'm running in some other trouble because of this. I don't really think this line was there for no reason. Any hints? Chris
I've been having the same problem with my Microsoft Natural Keyboard Elite ever since the first release of 2.6.x. I boot with the i8042.dumbkbd option to get around the problem. It's a workaround though, not a solution. Is there any plan for a more permenant solution that doesn't require rebuilding the kernel?
Cristian, Do you still have to disable the USB quirks to get your keyboard to work with 2.6.18-rc4?
Update: With 2.6.18-rc1, things started going haywire again, only in the opposite direction -- keyboard worked, but mouse was screwing up. The mouse would work in general, but move it around, especially up and left, and it would periodically jump back down and to the right. However, for a wireless device, the range was always extremely poor (perhaps the MS drivers had power control and it defaulted to low gain without them on Linux? I'm all freedomware here and couldn't legally run most slaveryware if I wished to as I can't agree to the EULAs, so I've never run it on MS slaveryware), and with the kernel hassles and the fact that I didn't particularly like the mouse (trackballs or trackpads are more my style), when the new kernel started having issues with it again, I found it a good excuse to switch back to Logitech. =8^) That means that I have a still-working but unused MS wireless keyboard/mouse set here, known to have issues with the kernel at times. Could some kernel dev use it for testing? It retails for US$100 so domestic US shipping might be worth it, anyway. I suspect getting one into a kernel input driver hacker's hands is about the only way you guys will ever be able to figure out this thing's quirks, why changes to the mouse driver affect keyboard and etc, and here's a chance to do it. Otherwise, it'll eventually be trashed, the result of yet another poor choice $100 investment in an MS product. =8^( ... Alternatively, I could hook it up temporarily again and at least report whether it's fixed in the latest .18-rc (I'm running rc4 as I write this), and maybe test a couple patches and/or command line options and send a few kernel boot logs. However, I'm not willing to invest a lot of time troubleshooting it any more, pinpointing the git release and beyond, as I've moved on to better hardware, Logitech! =8^)
Duncan, I think the mouse jumpinnes started with 2.6.18-rc1 is caused by Intellimouse 4.0 horizontal scroll support and will be cured by the following patch: http://marc.theaimsgroup.com/?l=linux-kernel&m=115615066515150&q=raw If you are truly going to trash the keyboard you could send it my way but I can't guarantee that I will be able to work out all its quirks. Dmitry
The mentioned patch is in 2.6.19-rc.