Bug 6130

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.