Pete: any ideas ?

I tried booting into single user mode.  Linux came up normally and gave me a
shell prompt.  Again the keyboard was dead.  Had to power off to force a
reboot.  This seems to rule out X/KDE as possible problems.  Here is my
/etc/modules.conf file:

pre-install pcmcia_core /etc/rc.d/init.d/pcmcia start

# For ethernet support
alias eth0 8139too
alias eth1 tulip
# For parallel port support
alias parport_lowlevel parport_pc
below parport_pc ppdev parport #     load ppdev and parport modules
# Added for IP tunnel support
alias tunl0 ipip
alias mytunnel ipip
# Added for CD-RW support
options ide-cd ignore=hdc #     tell the ide-cd module to ignore hdc
alias scd0 sr_mod #     load sr_mod upon access of scd0
below sg        ide-scsi #     load ide-scsi before sg
below sr_mod    ide-scsi #     load ide-scsi before sr_mod
below ide-scsi  ide-cd #     load ide-cd before ide-scsi
alias usb-controller usb-uhci
# Added for installation of OSS sound support
alias sound-slot-0 off
alias char-major-14 off

I need a dmesg output to tell why it died.
If the box has network, it should be easy to let it boot
then use ssh or telnet to log in and run "dmesg > /tmp/xxx".
If that is not feasible, the next best thing would be
to borrow a PS/2 keyboard somewhere and use that to
the same effect.

As the last backup, getting /var/log/messages may be
sufficient (it has problems with ordering, but may work
as a last resort)

Created attachment 36941 [details]
dmesg output

I just noticed that /usr/src/linux-2.4.9-13/drivers/usb/usbkbd.c is included in
kernel-source-2.4.9-13.i386.rpm, but kernel-2.4.9-13.i686.rpm does not contain
the corresponding driver usbkbd.o (in /lib/modules/2.4.9-13/kernel/drivers/usb).

/sbin/lsmod shows the usbkbd module has loaded when I run kernel 2.4.9-7:
usbkbd                  3424   0 (unused)
input                   3840   0 [keybdev hid usbkbd]
usbcore                51808   1 [hid usbkbd usb-uhci]

What is the exact make and model of your keyboard?

I think contents of /proc/bus/usb/devices
may be of more use than the marketing name.

Created attachment 37061 [details]
/proc/bus/usb/devices under kernel-2.4.9-7

Pete, is this something that can be fixed by adding something to the hid 
driver, or does this keyboard require the boot protocol usbkbd driver.

I recompiled kernel from kernel-source-2.4.9-13.i386.rpm.  Used RedHat config
file kernel-2.4.9-i686.config, but I set CONFIG_USB_KBD=m.  Keyboard now works
fine.  dmesg now shows:
  usb.c: registered new driver keyboard
  input0: HP Multimedia Keyboard Hub on usb1:3.0
  usbkbd.c: :USB HID Boot Protocol keyboard driver
  usb.c: registered new driver hid
  hiddev0: USB HID v1.00 Device [HP Multimedia Keyboard Hub] on usb1:3.1
instead of
  usb.c: registered new driver hid
  input0: USB HID v1.00 Keyboard [HP Multimedia Keyboard Hub] on usb1:3.0
  hiddev0: USB HID v1.00 Device [HP Multimedia Keyboard Hub] on usb1:3.1

I have what seems to be the same problem.  After installing
kernel-2.4.9-13.i686.rpm, my USB keyboard is unresponsive from both X and text
mode.  It does work, however, on the grub menu screen.  Also, the USB mouse
attached to the keyboard works fine.  This same keyboard does work with
kernel-2.4.7-10 (maybe because this kernel seems to load the usbkbd driver
that's missing from 2.4.9-13?)


from dmesg:

usb-uhci.c: USB UHCI at I/O 0xdce0, IRQ 11
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: v1.251:USB Universal Host Controller Interface driver
hub.c: USB new device connect on bus1/2, assigned device number 2
hub.c: USB hub found
hub.c: 3 ports detected
hub.c: USB new device connect on bus1/2/1, assigned device number 3
usb.c: USB device 3 (vend/prod 0x566/0x2802) is not claimed by any active driver.
hub.c: USB new device connect on bus1/2/3, assigned device number 4
usb.c: USB device 4 (vend/prod 0x5fe/0x11) is not claimed by any active driver.
usb.c: registered new driver hid
input0: USB HID v1.00 Keyboard [ALCOR Monterey KBD HUB   ] on usb1:3.0
hiddev0: USB HID v1.00 Device [ALCOR Monterey KBD HUB   ] on usb1:3.1
usb-uhci.c: ENXIO 84000480, flags 0, urb c1a02d40, burb c1a02c40
usbdevfs: USBDEVFS_CONTROL failed dev 4 rqt 128 rq 6 len 18 ret -6
input1: USB HID v1.00 Mouse [Cypress Sem. PS2/USB Browser Combo Mouse] on usb1:4.0
usb.c: registered new driver hiddev
hid-core.c: v1.8 Andreas Gal, Vojtech Pavlik <vojtech>
hid-core.c: USB HID support drivers


cat /proc/bus/usb/devices:

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=121/900 us (13%), #Int=  3, #Iso=  0
D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB UHCI Root Hub
S:  SerialNumber=dce0
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  8 Spd=12  MxCh= 3
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=058f ProdID=9472 Rev= 0.01
S:  Manufacturer=ALCOR
S:  Product=Monterey KBD HUB   
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=255ms
T:  Bus=01 Lev=02 Prnt=08 Port=00 Cnt=01 Dev#=  9 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0566 ProdID=2802 Rev= 0.01
S:  Manufacturer=ALCOR
S:  Product=Monterey KBD HUB   
C:* #Ifs= 2 Cfg#= Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=hid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl= 10ms
I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=hid
E:  Ad=82(I) Atr=03(Int.) MxPS=   4 Ivl=255ms
T:  Bus=01 Lev=02 Prnt=08 Port=02 Cnt=02 Dev#= 10 Spd=1.5 MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=05fe ProdID=0011 Rev= 0.00
S:  Manufacturer=Cypress Sem.
S:  Product=PS2/USB Browser Combo Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=hid
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl= 10ms
tr=03(Int.) MxPS=   4 Ivl= 10ms

I have similar problem when install RH 7.2, my USB keyboard stops responding 
before the installation asks me to input grub's password... I then try to 
connect a PS/2 keyboard and it works (USB keyboard still does not, but pressing 
[NumLock], [CapLock] and [ScrollLock] key on PS/2 actually turns on both 
keyboards' LEDs).

After 7.2's successful installation and reboot the system, the USB keyboard 
dies right after the bootup message "USB Keyboard... [OK]".

Switch back to 7.1 now, it's back to normal.

to bd:
  Your problem appears to be unrelated to the problems above. If you install RH
7.2 and remove the files /lib/modules/*/kernel/drivers/usb/usbkbd.o, your
problem will likely go away. 

  It is the removal of this file in the errata 7.2 kernels that caused these
_other_ keyboards, mentioned above, to fail.

Pete,
  Do you see any solution to this problem that can get everybody to work
together nicely? This looks like a big hassle in that every fix appears to break
one person or another.

I am trying to get me one of those that "require" usbkbd.
I figure Dell does not ship such trash so Michael cannot help.
Currently I am looking for someone with HP multimedia keyboard
in the Bay Area or near Red Hat Meridian.

Yeah, I agree that lxl@ got it backwards, most probably.
Let's see if renaming usbkbd helps him or her.

Created attachment 39264 [details]
Vojtech's test program

Date: Thu, 15 Nov 2001 20:47:31 +0100
From: Vojtech Pavlik <vojtech>
To: Pete Zaitcev <zaitcev>
Cc: linux-kernel <linux-kernel.org>

[...]
Could you by any chance try to run the 'evtest' program (i
can send it to you if you don't have it handy) on the /dev/input/event
device created for this keyboard? And/or dmesg with DEBUG enabled in
hid-core.c? 

On my RedHat 7.1 Kernel 2.4.9-13 system if after boot up I ssh into the box 
and rmmod hid then I modprobe hid my keyboard (HP8676C computer HP USB 
internet keyboard) starts to work.

HP Keyboard data:

P/N 5184-4708
Model SK-2506U
Rev 1.1C
S/N C0003069883

The 5184-4708 is not available from HP parts finder anymore,
though its companion mouse 5184-4712 still is (hmm...).
Generic replacement keyboard 5065-6054 is tested to work OK.
The recommended replacement keyboard for HP-9680C is
5065-1389, and not tested yet.

  I think I may have found a fix for the Dell keyboard issue that won't conflict
with the various other keyboards out there. If you add the following line to
/etc/modules.conf, everything works ok:

   below usbkbd hid
This makes the HID driver load first, and it cures my problems. I need to know
if this works for anybody with the broken HP keyboard, specifically, does your
keyboard still work under 2.4.7-10 with the above line in /etc/modules.conf

On my RedHat 7.2 Kernel 2.4.9-13 kernel it did not work. 

HP 5183-9960 keyboard

Oh wonderful, 5183-9960 is not in the Partsurfer either.
Recommended replacement for HP-8676C is 5064-8886
(I bet it works too :(). Those HP people really roll
their part deprecation.

Michael pursues a different avenue: he tries to order modules.
We know that correct ordering between hid and usbkbd allows
mouse events to be received by hid, then usbkbd gets keyboard
events that hid did not understand. Personally, I think the
ordering is a fragile thing which is hard to get right.
Remember how it all started: we changed "nothing" between
7.1 and 7.2, but something caused them to be reordered and
suddenly Dell mice stopped working.
This is why I am trying to fix HID.
I am sorry to the delay that it causes.

Created attachment 44797 [details]
ATEN with broken GET_REPORT

I worked around my (and hopefuly Erik Troan's) adapter(s) in HID.
Now to the HP and Compaq equipment.

Unfortunately, a debugging on customer equipment seems to be in order.
I would be grateful if someone with the "usbkbd works, hid doesn't"
problem recompiled hid with debugging on. I am sorry to say, it
does require source code poking. In file drivers/usb/hid-core.c,
`#undef DEBUG' has to be replaced with `#define DEBUG 1'.
Then, do this:
 echo /bin/true > /proc/sys/kernel/hotplug
 rmmod usbkbd
 rmmod hid
 insmod /your/kernel/path/drivers/usb/hid.o
 dmesg > /tmp/1.d
 cp /var/log/messages > /tmp/1.m
Then, attach /tmp/1.* to this bug, but
PLEASE DO NOT DROP THEM INTO COMMENT BOX.
Thanks!

The GET_REPORT workaround is in CVS for >2.4.17-0.15.
Let us hold it in RawHide for the moment, because
it is strictly for testing.

The original requestor is willing to recompile kernels,
so we are pursuing custom debugging.

Created attachment 45160 [details]
dmesg output with hid-core debugging turned on

Created attachment 45161 [details]
/var/log/messages from run with hid-core debugging turned on

I attach debugging output as requested by Pete Zaitcev on 2002-02-06 20:49:44.
I started with kernel-2.4.9-13.src.rpm.
I did the %prep step, then proceed from there:
1. Edited drivers/usb/hid-core.c to turn on debugging.
2. Edited Makefile to set EXTRAVERSION=-13kbddbg.
3. make mrproper
4. Copied configs/kernel-2.4.9-i686.config to .config
5. make oldconfig
6. make dep
7. make bzImage (unnecessary?)
8. make bzdisk
9. make modules
10. make modules_install
11. Booted from floppy from step 8
12. HP USB keyboard didn't work, as expected.  Logged in remotely.
13. echo /bin/true > /proc/sys/kernel/hotplug
14. rmmod usbkbd (no driver loaded)
15. rmmod hid
16. insmod /lib/modules/2.4.9-13kbddbg/kernel/drivers/usb/hid.o
17. dmesg > 1.d
18. cp /var/log/messages 1.m
I deleted stuff from 1.m from before the reboot in step 11.  Files are attached.

Michael, thank you for the data. Unfortunately for us,
it is evidently not a problem similar to ATEN's.
No configuration requests fail.

Would you please re-do it with DEBUG_DATA enanbled in the same way?
You only need to do "make modules", then boot as you did before
(certainly don't clean with "make mrproper", or it'll take ages
to rebuild).

With DEBUG_DATA I am trying to find if hid_input_report is
getting anything.

Created attachment 45180 [details]
dmesg output with additional hid-core debugging turned on

Created attachment 45181 [details]
/var/log/messages from run with additional hid-core debugging turned on

Michael, did you hit any keys after loading the hid
with DEBUG_DATA? It should print one more of those
"report size N (unnumbered)" for every key hit.

I don't think I hit any more keys.  I hit some keys right after booting,
verifying that the keyboard didn't work.  Then I logged in remotely through
the network and ran the tests from the other machine.  I was in the next room
when I did the tests, so I'm sure I didn't touch the keyboard between doing
insmod of hid.o and capturing the dmesg and /var/log/messages output.
Do you want another test where I do hit some keys?

Ran experiments again, but this time hit some keys after insmod hid.o
but before capturing logs.  Results are attached in 3.d and 3.m.  Much to
my surprise, the keyboard then worked!  I also did lsmod right after the boot
(when the keyboard was not working) and again after insmod.  Results are
attached.  The only obvious differences are that hid moved up to the top
of the list, and the line for "input" changed from "[keybdev hid]" to
"[hid keybdev]".  I'll bet a line "below hid keybdev" in /etc/modules.conf
would make my problem go away!

Created attachment 45239 [details]
dmesg output with hid-core debugging after several keystrokes

Created attachment 45240 [details]
/var/log/messages with hid-core debugging after several keystrokes

Created attachment 45241 [details]
lsmod output after reboot (keyboard not working)

Created attachment 45242 [details]
lsmod output after rmmod hid; insmod hid (keyboard working)

Stellar job, Michael, but I am still in the dark.
I suspect a delay related to exessive printk's may have helped.

You can experiment with modure ordering on a stock system
by running rmmod/insmod. It it fixes the problem, it is
likely the ordering. If it does not, then it's the delay.

I added the line "below hid keybdev" to /etc/modules.conf and rebooted the
test system.  hid loaded just above keybdev rather than just below it,
but the keyboard still did not work!  rmmod hid; insmod hid started it working
again (and of course moved hid up to the very top of the module stack).

WORKAROUND:  Removing and reloading the hid module right after booting seems
to get the keyboard working.  For RedHat users, it's sufficient to add the
following lines to /etc/rc.d/rc.local:
    #
    # Reload hid driver to overcome bug with HP keyboard
    #
    /sbin/rmmod hid
    /sbin/insmod hid
I'm using this with the stock 2.4.9-21 kernel and have had no problems so far.

Apparently, Vojtech receives reports of devices that
refuse to work with hid when it is loaded upon boot, but
work fine if hid is reloaded afterwards. He promises
to look at it at a future date. Suuure...

Created attachment 66364 [details]
Itai's "hid reload" fix

Michael reports that Itai's fix works on his HP keyboard.

CVS release AFTER 2.4.18-5.78. Patch 1241.