Opened 12 years ago

Closed 11 years ago

#1580 closed bug (fixed)

Mouse freezes (permanently or intermittently) after brief movement

Reported by: koki Owned by: marcusoverhagen
Priority: normal Milestone: R1
Component: Drivers/Mouse/PS2 Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

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)

Attachments (3)

syslog_1 (102.9 KB) - added by koki 12 years ago.
syslog for permanent mouse freeze
syslog_2 (125.2 KB) - added by koki 12 years ago.
syslog for intermittent mouse freeze
serial_T61 (109.9 KB) - added by bonefish 11 years ago.
Serial Debug Output T61

Download all attachments as: .zip

Change History (18)

Changed 12 years ago by koki

Attachment: syslog_1 added

syslog for permanent mouse freeze

Changed 12 years ago by koki

Attachment: syslog_2 added

syslog for intermittent mouse freeze

comment:1 Changed 12 years ago by 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.

comment:2 Changed 12 years ago by 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.

comment:3 Changed 12 years ago by 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?

comment:4 Changed 12 years ago by 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.

comment:5 Changed 12 years ago by axeld

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

comment:6 Changed 12 years ago by 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?

comment:7 Changed 12 years ago by 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.

comment:8 Changed 12 years ago by 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.

Changed 11 years ago by bonefish

Attachment: serial_T61 added

Serial Debug Output T61

comment:9 Changed 11 years ago by 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.

comment:10 Changed 11 years ago by 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?

comment:11 Changed 11 years ago by 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.

comment:12 Changed 11 years ago by koki

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

comment:13 Changed 11 years ago by 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)?

comment:14 Changed 11 years ago by 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.

comment:15 Changed 11 years ago by mmlr

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.