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 12 years ago.
Serial Debug Output T61

Download all attachments as: .zip

Change History (18)

by koki, 12 years ago

Attachment: syslog_1 added

syslog for permanent mouse freeze

by koki, 12 years ago

Attachment: syslog_2 added

syslog for intermittent mouse freeze

comment:1 by axeld, 12 years ago

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 by koki, 12 years ago

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 by axeld, 12 years ago

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 by koki, 12 years ago

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 by axeld, 12 years ago

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

comment:6 by marcusoverhagen, 12 years ago

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 by koki, 12 years ago

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 by koki, 12 years ago

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.

by bonefish, 12 years ago

Attachment: serial_T61 added

Serial Debug Output T61

comment:9 by bonefish, 12 years ago

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 by mmlr, 12 years ago

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 by koki, 11 years ago

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 by koki, 11 years ago

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

comment:13 by mmlr, 11 years ago

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 by koki, 11 years ago

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 by mmlr, 11 years ago

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.