Kinesis USB Keyboard is removed after first key is pressed.

[mmadia]

hrev31375-x86gcc2 native. A Kinesis USB keyboard (model: KB500USB-blk, serial: 82179ub) does not work as expected. After booting Haiku and waiting for syslog to stop growing, I'll plug in the keyboard. Shortly after that, the keyboard will go non-responsive, typically with the last pressed key auto-repeating. The auto-repeat is very odd, it seems to stick with the initial window, even if focus is given to another program.

output of listdev and listusb -v are attached.

relevant snippet of syslog:

KERN: usb hub 7: port 3: new device connected
KERN: usb ehci 1: fullspeed device connected, giving up port ownership
KERN: usb hub 2: port 3: new device connected
KERN: usb hub 13: port 1: new device connected
KERN: usb hub 7: port 3: device removed
KERN: void AddOnManager::MessageReceived(BMessage *) what: NMP_
Last message repeated 1 time
KERN: error when KB_SET_KEY_REPEAT_RATE, fd:12
KERN: error when KB_SET_KEY_REPEAT_DELAY, fd:-1
MMADIA: syslog stops growing. after pressing a single key, the next few lines display.
KERN: usb hub 13: port 1: device removed
KERN: usb hub 13: KERN: port 1 disabled
KERN: usb hub 13: port 1 is not suspended
KERN: void AddOnManager::MessageReceived(BMessage *) what: NMP_
MMADIA: At this point, the keyboard is non-responsive

[mmlr]

Can you please retest with the reworked usb_hid driver?

[mmadia]

Replying to mmlr:

Can you please retest with the reworked usb_hid driver?

Still persistent at hrev31839.

[mmadia]

Attached a syslog from hrev31990-x86gcc2. Still persistant.

syslog snippet

KERN: usb hub 7: port 3: new device connected
KERN: usb ehci 1: KERN: fullspeed device connected, giving up port ownership
KERN: usb hub 2: port 3: new device connected
KERN: usb hub 19: port 1: new device connected
KERN: usb hub 7: port 3: device removed
KERN: usb_hid: no handlers for hid device
KERN: void AddOnManager::MessageReceived(BMessage *) what: NMP_
Last message repeated 1 time
KERN: usb error ohci 0: td error: 0x00000003
KERN: usb_hid: error waiting for report: Device check-sum error
KERN: usb hub 2: port 3: device removed
KERN: usb hub 2: KERN: port 3 disabled
KERN: void AddOnManager::MessageReceived(BMessage *) what: NMP_
KERN: register_domain(9, unix)
KERN: heap_add_area: area 4746 added to large heap 0x81c57ccc - usable range 0x88001000 - 0x88400000

[mmlr]

You could add #define TRACE_USB at the top of src/add-ons/kernel/busses/usb/ohci.cpp (before the includes). This will enable verbose (maybe a bit too verbose) output for OHCI and might turn something up.

[mmlr]

Ah I see it now: there's a OHCI_TD_CONDITION_TOGGLE_MISMATCH after the first transfer. I guess that's an error in toggle maintenance in the OHCI code. Will review after getting some sleep.

[mmlr]

Replying to mmlr:

Will review after getting some sleep.

Ah who needs sleep anyway? Can you please check with hrev32510?

[anevilyak]

With this rev I'm seeing extreme system sluggishness, even with just a USB mouse on the OHCI controller. No messages on syslog. Anything I can do to help debug?

[mmadia]

with the change from 32531, this still persists. After booting, I'll plug the Kinesis in. Shortly there after, it'll get stuck in auto-repeat mode. Here's the snippet from syslog starting at inserting the keyboard:

KERN: usb hub 7: port 3: new device connected
KERN: usb ehci 1: KERN: fullspeed device connected, giving up port ownership
KERN: usb hub 2: port 3: new device connected
KERN: usb hub 26: port 1: new device connected
KERN: usb hub 7: KERN: port 3: device removed
KERN: usb_hid: no handlers for hid device
KERN: void AddOnManager::MessageReceived(BMessage *) what: NMP_
Last message repeated 1 time
KERN: error when KB_SET_KEY_REPEAT_RATE, fd:-1
KERN: error when KB_SET_KEY_REPEAT_DELAY, fd:-1
KERN: usb error ohci 0: td error: 0x00000003
KERN: usb_hid: error waiting for report: Device check-sum error
KERN: usb hub 2: port 3: device removed
KERN: usb hub 2: KERN: port 3 disabled
KERN: void AddOnManager::MessageReceived(BMessage *) what: NMP_

[mmlr]

I am able to reproduce this issue over here with my OHCI add-on card and my normal keyboard. It will start repeating random keys because usb_hid gets bogus (uninitialized) data from OHCI. I do not quite understand the problem yet, as everything seems to work fine as far as the driver is concerned. The transfers are scheduled and then return without errors, still the buffer they are supposed to have filled haven't been touched. Even though it will repeat randomly the keyboard stays usable for me as long as I keep typing stuff at a certain rate. This hints at a communication/timing problem which I will try to understand later today.

[mmlr]

Please try hrev33129. It fixes a race condition that could very well explain this issue (as well as the failing port status updates reported on irc). I'm hopeful anyway.

[mmadia]

Works as expected with hrev39952. Thank you and thanks coverity!