Input server dies on AT keyboard keymap IsDeadKey()

[jonas.kirilla]

vm_soft_fault: va 0x404 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x404, ip 0x69effc, write 0, user 1, thread 0x7a
vm_page_fault: sending team "/boot/beos/system/servers/input" 0x32 SIGSEGV, ip 0x69effc ("keyboard_seg0ro" +0x8ffc)
stack trace:
  0x0069debc (keyboard_seg0ro + 0x7ebc)
  0x004fd2c0 (libroot.so_seg0ro + 0x222c0)
  0x70102fec (AT Keyboard 1 watcher_7a_stack + 0x3ffec)
vm_soft_fault: va 0x0 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x0, ip 0x80082b65, write 0, user 0, thread 0x7a
debug_server: Thread 122 entered the debugger: Segment violation
stack trace, current PC 0x69effc  IsDeadKey__6KeymapUlUl + 0x260:
  (0x70102eec)  0x69debc  _DeviceWatcher__19KeyboardInputDevicePv + 0x444
  (0x70102fac)  0x4fd2c0  _get_next_team_info + 0x68 (closest symbol)

I've got 3 input devices currently, a USB mouse, a USB keyboard, both working, and a PS/2 keyboard which is in some state between working and not working. (In Haiku. It's always fine in BeOS.) It's never operational on startup, even though the device node is there and bootup serial output looks okay AFAIK, however it's always possible to coerce into working, by typing "keymap -r", running the Keymap preferences or DeskCalc (in turn calling set_keyboard_locks(), I think). When I use DeskCalc some amount of buffered up keystrokes spill out in DeskCalc's input view. Some of the times I use DeskCalc this way, input_server dies in Keymap::IsDeadKey().

[korli]

Did you use a keymap other than default ?

[jonas.kirilla]

Replying to korli:

Did you use a keymap other than default ?

No, I'm using the default keymap. Any fresh install will show this behaviour on my hardware. I think the issue has been there for quite some time. I don't know if I've ever had it work, on this specific combination of hardware.

Adding a PS2 mouse to the mix makes the PS2 keyboard also work, but I don't have one now, and it -should- work without one.

[marcusoverhagen]

ps2 bus manager hrev20828 with enabled debug output

[marcusoverhagen]

Please install the ps2 bus manager with debug output and provide a syslog of boot, also including the "keymap -r" actions.

[jonas.kirilla]

syslog, hrev20839 + ps2 debug, keymap -r, then ps2 key 'a' pressed

[jonas.kirilla]

syslog, hrev20839 + ps2 debug, some ps2 keypresses, then keymap -r

[jonas.kirilla]

syslog, hrev20839 + ps2 debug, open Keymap preferences, press 'Use', type a single 'a' with ps2 keyboard

[jonas.kirilla]

syslog, "hey input_server quit" -> ps2: keyboard_close

[marcusoverhagen]

According to the log files, these is no PS/2 mouse attached. Is this correct?

The PS/2 keyboard appears to work with this bus manager, as the keypresses are read by (deliverd to) the input_server.

A PS/2 keyboard bug was fixed with hrev20828. Is the PS/2 keyboard now working for you? (Does typing generate characters in terminal or StyledEdit)

What did you mean by "PS/2 keyboard which is in some state between working and not working"

[jonas.kirilla]

Replying to marcusoverhagen:

According to the log files, these is no PS/2 mouse attached. Is this correct?

Yes. There is no PS/2 mouse attached.

The keyboard leds flash, I believe, ON->OFF, around the syslog time where the devfs unpublishes the mouse. I read somewhere that PS/2 mice and keyboards share PS/2 resources somehow. Could that be it? That would explain why adding a PS/2 mouse helps the PS/2 keyboard also work.

Replying to marcusoverhagen:

The PS/2 keyboard appears to work with this bus manager, as the keypresses are read by (deliverd to) the input_server.

In syslog2.txt, the PS/2 keyboard keys pressed before running 'keymap -r' seem to be delivered after keymap has done whatever it does. That's what I see happening on-screen, and the syslog output timing is consistent with that.

Replying to marcusoverhagen:

A PS/2 keyboard bug was fixed with hrev20828. Is the PS/2 keyboard now working for you? (Does typing generate characters in terminal or StyledEdit)

My latest tests, and the syslogs, are from hrev20839. The PS/2 keyboard is not working. No characters, no F12 to enter KDL. The PS/2 keyboard works though if KDL happens for some other reason.

Replying to marcusoverhagen:

What did you mean by "PS/2 keyboard which is in some state between working and not working"

I can't say where it fails. It's there, leds flash on startup, there's a device node, key presses are buffered up, it can be coerced into releasing the key presses (by using keymap -r, etc), it will always work in KDL if KDL happens to be entered. It looks to me like it's mostly working, except it's not working at boot up.

[jonas.kirilla]

I wrote that "The keyboard leds flash, I believe, ON->OFF, around the serial output time where the devfs unpublishes the mouse." But I must admit that I'm very unsure of the timing of these events, in what part of the serial output the physical keyboard led flashing happens.

Is this speculation interesting at all?

[marcusoverhagen]

Can you please do one additional test?

Start Haiku, wait about one minute after the cursor appears, then type a few keys on PS/2, and kill/quit input server.

[jonas.kirilla]

boot, wait a minute or two, type some, then quit input_server

[jonas.kirilla]

Replying to marcusoverhagen:

Can you please do one additional test?

Start Haiku, wait about one minute after the cursor appears, then type a few keys on PS/2, and kill/quit input server.

Certainly!

See log5.txt. I've tested five or so times, quitting, killing and varying the waiting between 1 and 3 minutes. The single line "ps2: keyboard_close" is the only thing I've noticed happening. No sign of key presses as far as I can tell. (Using the debug PS/2 bus manager you provided, dropped in a hrev20861 build.)

[marcusoverhagen]

Please retest with hrev20883, enable TRACE-ing in ps2_common.h before compiling, and provide a syslog. Note that I don't expect this revision to fix your problem, but it should provide better debug output.

1st test: enter BIOS during boot and lookup (and report here) the current USB keyboard/mouse legacy support setting, but don't change it. boot into haiku and type a few (around 20) keys about 30 seconds after the desktop appeared

2nd test: remove usb keyboard and mouse and reboot. does the ps2 keyboard work? (ctrl+tab, etc)

3nd test: reattach usb keyboard + mouse, reboot and enter change bios setting of usb legacy support, boot and repeat test 1.

4th test: remove/delete the usb bus manager from /boot/beos/system/add-ons/kernel/bus_managers (or a similar path, can't verify right now) and repeat test 1.

thanks

[marcusoverhagen]

oh i forgot this one:

5th test: revert usb legacy setting in BIOS to the initial value from 1st test, and repeat first test (with usb bus maanger still removed, as in test 4)

[jonas.kirilla]

hrev20883, ps2 TRACE - TEST 1 - BIOS USB Legacy Support: AUTO (enabled)

[jonas.kirilla]

hrev20883, ps2 TRACE - TEST 2 - no USB mouse/keyboard attached

[jonas.kirilla]

hrev20883, ps2 TRACE - TEST 3 - Legacy: disabled - ps2 keyb + USB keyb and mouse

[jonas.kirilla]

hrev20883, ps2 TRACE - TEST 4 - Legacy: disabled - USB bus manager removed

[jonas.kirilla]

hrev20883, ps2 TRACE - TEST 5.1 - Legacy: auto - USB bus manager removed

[jonas.kirilla]

TEST 5.2 - I think it works!

[jonas.kirilla]

TEST 5.3 -- Keys 1,2,3 on PS2, then on USB, then some tiny mouse movement

[jonas.kirilla]

5.3 is probably the best. I went overboard with input in 5.1, I was just so happy to see HID activity in the serial output.

Let me know if you want me to double-check any of the tests, or do additional ones!

[jonas.kirilla]

Looking at 6 and 7, I get strengthened in my belief that, with my hardware, the PS/2 keyboard somehow depends on the presence of PS/2 mouse, regardless of them being "real" PS/2 or USB fakes. But I'm just guessing.

[marcusoverhagen]

Regarding your last comment, does Linux, Windows or BeOS support all three (USB Keyb/Mouse + PS2 Keyb) devices simultanous on this machine, when no ps2 mouse is connected?

[jonas.kirilla]

I'm working on an overview of how the devices work with a collection of operating systems, with the USB Legacy support set to disabled/auto/enabled. I will not be able to present the results tomorrow, but hopefully the day after tomorrow.

[korli]

I added some range checks in Keymap::IsDeadKey(), revision 20918.

[jonas.kirilla]

2 Devices -- PS2 keyboard, USB keyboard -- StyledEdit format text, zipped

[jonas.kirilla]

StyledEdit format text, zipped

[jonas.kirilla]

Replying to marcusoverhagen:

does Linux, Windows or BeOS support all three (USB Keyb/Mouse + PS2 Keyb) devices simultanous on this machine, when no ps2 mouse is connected?

Yes. Have a look at the test results I posted. (Sorry about the .png image. It looked fine here.)

I haven't had Windows in a while, but as far as I recall I never had any problems with it. I've never had to change the BIOS USB Legacy support setting from auto to something else.

I added the USB keyboard to have a working keyboard in Haiku. The devices seem to all work fine except in Haiku and in Zeta. They work great in BeOS and Linux, AFAIK, but Zeta has never worked right on this hardware.

Feel free to suggest more tests and logging.

I don't know if this page is useful at all, but FWIW:

"Support for USB and Legacy Keyboards and Mouse Devices" ​http://www.microsoft.com/whdc/device/input/usbhost.mspx

[jonas.kirilla]

With hrev20984, my PS/2 keyboard simply works. :) Thank you so much!

About Keymap::IsDeadKey(), I've found that I can make it crash by typing "keymap -r" in Terminal, and repeat that fast enough, by using up-arrow, entering the same line over and over.

[korli]

I can't reproduce the IsDeadKey() crash, could you elaborate a bit ?

[jonas.kirilla]

Replying to korli:

I can't reproduce the IsDeadKey() crash, could you elaborate a bit ?

I can reproduce the crash easily, manually or via script. See keymap_loop.sh.

I will also upload another syslog + crash, FWIW.

[korli]

Fixed in hrev21881. The keymap was reloaded in the middle of the key code process.

[jonas.kirilla]

Fix confirmed. Thanks!