Mouse freezes (permanently or intermittently) after brief movement

[koki]

The mouse freezes after moving the pointer briefly. Most of the time the mouse freeze is permanent, but in some cases it is intermittent. The keyboard remains functional, as does (at least apparently) the rest of the system.

This was on hrev22626 nightly build running on HP Pavillion ZV5000 laptop with builtin PS/2 mousepad. FWIW, Haiku has been running on this hardware flawlessly for a long time, until I noticed this problem with the above-mentioned nightly build.

Two syslogs attached:

1) Permanent freeze (syslog_1)

2) Intermittent mouse freeze (syslog_2)

[koki]

syslog for permanent mouse freeze

[koki]

syslog for intermittent mouse freeze

[axeld]

That could be caused by hrev22617 - I reverted an older change (hrev20883) in the PS/2 bus manager that caused many systems to lock up instead of reboot.

[koki]

FWIW, for testing purposes I replaced...

/system/add-ons/kernel/bus_managers/ps2 /system/add-ons/kernel/drivers/bin/ps2_hid

...with the files from hrev22614, but it did not seem to have any effect.

[axeld]

So it's likely caused by another change, and probably not related to the PS/2 driver at all, I suppose. Can you by any chance pin down the revision (at least more or less) since when you encounter these problems?

[koki]

Since I don't have the ability to build from source, I tested again with a fresh install of the oldest nightly build available on haikuhost.com. This was the same build that I had used for my previous test (hrev22614), so as expected, it did not work. :)

I am a bit at a lose as to whether there is anything else that I can do to help the devs figure out what the problem is. If there is, feel free to let me know.

[axeld]

Thanks for your help so far; this is just one more reason to finally get an image archive up and running.

[marcusoverhagen]

The syslog lists in both cases

KERN: ps2: hot removal of input/mouse/ps2/3

This is only printed on a very specific condition, as defined by the PS/2 active multiplexing specification, the error bit must be set, and data must match 0xfd.

if (dev->history[0].error && data == 0xfd) {
    INFO("ps2: hot removal of %s\n", dev->name);

In the intermittent mouse freeze case, the mouse appears to be reconnected and disconnected a lot of times.

Are you sure that you mouse and/or PS/2 connector is working correct?

[koki]

Hi Marcus. Thanks for looking into this bug.

This bug appears only in Haiku running in my laptop with a built-in mousepad. The mouse(pad) works just fine in ZETA/Win/Ubuntu, so I suppose that the hardware is not faulty.

[koki]

FWIW, if I disable the built-in mousepad (via an ON/OFF hardware button) and plug in a USB mouse, the mouse works just fine.

[bonefish]

Serial Debug Output T61

[bonefish]

I've a similar problem with my Lenovo T61: After a while of using the USB mouse, it freezes permanently. The touch pad continues to work. The line

Disabling unhandled io interrupt 11

appears at the output (attached) when that happens, so this might not be exactly the same problem, Koki reported. I can open a new ticket, if desired.

[mmlr]

Ingo, I think yours is a bit different. From the syslog it seems that there is a legacy support handoff issue. There seem to be two EHCI controllers, both in legacy mode at boot. Then one of them is correctly handed off by the BIOS (lines 2277-2281):

usb_ehci: the host controller is bios owned
usb_ehci: claiming ownership of the host controller
usb_ehci: controller is still bios owned, waiting
Last message repeated 2 times.
usb_ehci: successfully took ownership of the host controller

But the other one is not freed by the BIOS (lines 2282-2291):

usb_ehci: the host controller is bios owned
usb_ehci: claiming ownership of the host controller
usb_ehci: controller is still bios owned, waiting
usb_ehci: controller is still bios owned, waiting
bfs: ...
bfs: ...
usb_ehci: controller is still bios owned, waiting
Last message repeated 7 times.
usb_ehci: bios won't give up control over the host controller
usb_ehci: bus failed init check

It's possible that interrupt 11 belongs to this controller. Could you open a new bug for that and tell if you have anything plugged in at boot, you did a cold or warm boot and if you actually have legacy support enabled in the BIOS?

[koki]

FWIW, built-in mousepad works fine now with hrev25477. Which means this bug seems to be fixed, so I guess it is OK to close.

[koki]

Sorry, that was actually with hrev25566 (not hrev25477 as noted in previous comment). :)

[mmlr]

I suppose then you have an OHCI controller and this was a legacy emulation issue? Could you check what USB devices you have ("find /dev/bus/usb") and then check if the touchpad is actually attached to the system using USB (using usb_dev_info on the device and the hub to see if it's actually OHCI)?

[koki]

I believe the mousepad is PS/2; but here is the output of "find /dev/bus/usb" anyway:

/dev/bus/usb /dev/bus/usb/0 /dev/bus/usb/0/hub /dev/bus/usb/1 /dev/bus/usb/1/hub /dev/bus/usb/2 /dev/bus/usb/2/hub /dev/bus/usb/raw

HTH.

[mmlr]

Yeah, in that case it seems there are no USB devices attached at all. It still might very well have been a legacy support issue. The strangest things seem to be happening when legacy support is involved... The only thing you could try to further verify that would be to remove the OHCI driver ("/boot/beos/system/add-ons/kernel/busses/usb/ohci") again and see if the behaviour returns. In any case I will resolve this ticket as fixed per your report.