Opened 12 years ago

Closed 10 years ago

#1709 closed bug (fixed)

USB hid not working on gcc4 build

Reported by: mauricek Owned by: mmlr
Priority: normal Milestone: R1
Component: Servers/input_server Version: R1/pre-alpha1
Keywords: Cc: marcusoverhagen
Blocked By: Blocking:
Platform: x86


I'm trying to use haiku natively on a spare partition on my notebook. Using a USB mouse or keyboard does not work. Trying to enable legacy support in the BIOS resulted in unexpected behavior of sometimes one of them or even both working for around 10-20 seconds until the input devices hang again.

Unfortunately the syslog is not flushed onto the partition, so I cannot add one currently. Will try to tweak a little bit and then attach one to this report.

P.S.: As mentioned in the summary, this only applies for a gcc4 build, using the outdated gcc2 fixes these issues.

Attachments (2)

syslog (103.8 KB ) - added by mauricek 12 years ago.
syslog.2 (101.8 KB ) - added by mauricek 12 years ago.
New syslog

Download all attachments as: .zip

Change History (11)

comment:1 by mmlr, 12 years ago

Owner: changed from korli to mmlr
Status: newassigned

That's a bit strange. Does this happen only with the recent changes to usb_hid or did this happen before (like one week ago already)? Also are you sure that this is usb_hid failing and not the USB stack itself? Sadly without a syslog this is very hard to pinpoint. I will try with a GCC4 build at home, but I don't know if I'll be able to reproduce the issue.

comment:2 by mauricek, 12 years ago

To be honest, I am not sure, whether this is really related to usb_hid. It might also be the input_server by itself. I've recognized, that the input devices on my notebook do not work either and they are PS/2 if I remember correctly...

Anyway, with the legacy support, at least I got it partly to work. Thus, I assumed that this is caused by usb_hid.

Until now I considered this (PS/2 <-> USB input method) to be 2 different bugs and wanted to report the PS/2 issue as soon as I managed to get some syslog flushed.

I tried this first some weeks ago and last time in the middle of previous week. In case you want me to try this out with the latest change, feel free to ask.

comment:3 by mmlr, 12 years ago

To get the syslog flushed you could add "sync" to the bootscript (at "/boot/beos/system/boot"). It's sure possible that the input is not working, what I find strange is that this only happens with a GCC4 build. What hardware do you run Haiku on BTW?

in reply to:  3 comment:4 by mauricek, 12 years ago

I just tried out a recent (post-BG) build and the first time I boot into Haiku I have a working usb_mouse. Also the PS/2 keyboard is working. So it seems like this specific issue is resolved. Though the system is dead after a few seconds, I assume that this is something bfs_related as neither sync nor copying the syslog to another place really copies anything on the partition. It just vanishes after reboot or has never been written to disc.

On a second boot though, the system hangs at one point or the other. The input devices do not work at any time, but this might be related to something else.

I am using a Acer TravelMate 291, usually it doesn't have any weird configuration. Also BeOS and ZETA worked well with it.

In the end, as the input device is working until some point (I guess when it is trying to sync to disc and messes up) I think one can reject the task or keep it open until it's more stable in general...

by mauricek, 12 years ago

Attachment: syslog added

comment:5 by mauricek, 12 years ago

Hey, since the latest changes Haiku seems to run much better on a gcc4 build here. I am even capable of getting a syslog now.

As it states, the keyboard/mouse part in the keyboard_manager is not capable of resetting the device. For the keyboard this happens in src/add-ons/kernel/bus_managers/ps2 line 189.

I hope this helps in debugging. In case you need further assistance, feel free to tell me.

comment:6 by marcusoverhagen, 12 years ago

Cc: marcusoverhagen added

comment:7 by mmlr, 12 years ago

Have you retried with a current revision? Much has happened since, usb_hid has been pretty much rewritten and there have been a few GCC4 related changes. So it should be worth a try again, maybe now debugging this further is possible? I'd be interested in a new syslog at least.

by mauricek, 12 years ago

Attachment: syslog.2 added

New syslog

comment:8 by mmlr, 11 years ago

Did you retry recently? We've updated to a new GCC4 by now and many USB bugs have been resolved. If there are real problems with usb_hid I'd like to resolve them, if there are problems with PS2 though I'd like to reassign and change the summary.

comment:9 by mmlr, 10 years ago

Resolution: fixed
Status: in-progressclosed

I'm going to close this for lack of feedback and under the assumption that if it was a usb_hid problem it's resolved by now through the two rewrites. I haven't heared of any problems regarding usb_hid and GCC4 and also have run GCC4 builds with it with no problems. If this actually was a PS/2 problem then it might persist, in which case a new bug report should be opened with the correct component.

Note: See TracTickets for help on using tickets.