Haiku USB in BeOS R5

[nutela]

version is from mlotz "Using the Haiku usb stack" on Haiku-os.org. 1st R5.03 Pro boots very long, about 1 min, 1,5 min, the impressions is it hangs at the 'monitor with lightening'-icon with continues after the long period.

I have tested it on a variety of devices. 1st is a logitech mx 3200 wireless keyb and mouse combination with usb receiver. The PC is a p3 coppermine I believe @ 800 with Asus Cubx mobo, so should by UHCI. The keyboard works, mouse doesn't. Unplugged receiver; KDL. I have another wired usb mouse HP branded, this works but scrolling does not as in plain R5. I tried plugging in my mobile phone Sony Ericson K750i (USB 2.0), I could not mount it (didn't appear) but KDL when I unplugged it. (screenshot) I mounted an USB stick (USB 2.0 capeability) it works but mount menu appears to refresh much slower then R5 usb stack, must be a blocking problem. When I unpugged the stick Tracker thought it was still mounted, unmounted it->KDL (screenshot).

[nutela]

It KDLs when I do a input_server -q. Need KDL info?

[nutela]

I think the boot time increase causes this;

(from syslog)

KERN 'sysinit2'[3]: scsi_cam: path 0 slack... KERN 'sysinit2'[3]: scsi_cam: path 1 slack... KERN 'sysinit2'[3]: get_checksum(...,0,32256) KERN 'sysinit2'[3]: SCSI DISK -- get_checksum: problem reading block 0 KERN 'sysinit2'[3]: get_checksum(...,0,32256) KERN 'sysinit2'[3]: SCSI DISK -- get_checksum: problem reading block 0 KERN 'sysinit2'[3]: get_checksum(...,0,32256) KERN 'sysinit2'[3]: SCSI DISK -- get_checksum: problem reading block 0 KERN 'sysinit2'[3]: get_checksum(...,0,32256) KERN 'sysinit2'[3]: SCSI DISK -- get_checksum: problem reading block 0 KERN 'sysinit2'[3]: get_checksum(...,0,32256) KERN 'sysinit2'[3]: SCSI DISK -- get_checksum: problem reading block 0 KERN 'sysinit2'[3]: get_checksum(...,0,32256)

etc.

[nutela]

syslog zipped

[mmlr]

Good news first: The KDL on unplugging devices should be fixed. The KDL on unmount probably too. The Tracker by the way cannot know when you unplug the device. It won't unmount it therefore.

That the mount menu refreshes slower is caused by the usb_scsi module. Happens the same if you install it with the R5 stack. It's probable that you just didn't have it installed before.

Scrolling is dependent on the hid module in use. The plain R5 hid module doesn't support scrolling, but the one from Dano does.

Yes, the long booting is probably caused by errors in communicating with a plugged in mass storage device. You could check if the boot is quicker when you don't have it plugged in. The boot time will increase when you have usb_scsi installed, this is simply because the USB stack has to be loaded and all the controllers have to be initialized.

From the syslog I take it that you run more or less plain R5 with only UHCI and no EHCI (USB 2.0) controller? A stack crawl ("sc") from the KDL on input_server killing would be helpful, thanks for all the infos!

[nutela]

Thanks for the reply mmlr, tell me if your on IRC or BeShare or elsewhere, I could ask and test much better IMHO. I haven't plugged in any mass storage usb device but the booting is stil very slow, several minutes instead of 20 seconds. By HID module you mean usb_hid driver? I could use the one from Haiku and test that as well. I have another weird problem, beside multimedia keys, I have an key not working; the backslash key, it doesn't get visually pressed in the keymap pref app as well. I downloaded some HexKeyCode program the key did not appear! The code must be > 0x7F (127) You are right about the syslog, plain R5 with only UHCI controller. I will get you an SC later. Thanks for making it work :-)!

[nutela]

Replying to nutela

So this was BS (about the keyboard); I installed the usb_hid driver from the Haiku tree and this \| -key works.

Then I updated the tree half an hour ago that's 31.8.2007 around 21:00 (forgot to note the revision), jammed all usb stuff (Where do I install USBkit.a? or do I need it to just for building my own stuff and linking my own SW to it?) Installed everything in ~/config/.... etc. First I noticed that the long boot time is gone, not more KERN 'sysinit2'[3]: SCSI DISK -- get_checksum: problem reading block 0 KERN 'sysinit2'[3]: get_checksum(...,0,32256)

Then after boot I noticed when I type real fast keys get virtually stuck; it is as if the key is pressed and held and after another key press this ceases.

My USB stick doesn't appear in the mount menu and neither the Sony Ericson K750i with mass storage but it never did appear yet so no change in that respect.

Plugin and plug out of the USB receiver and Wacom tablet gave a KDL. I hooked up an PS/2 keyb when in KDL but I couldn't get any enter key from it the keys were mapped all weird; eg. F2 == @ on screen. So I couldn't type sc. See screenshot.

Last but not least, the mouse which came with the keyboard (explained above) still doesn't get trough the USB receiver or something, it just doesn't work just the keyboard alone.

[nutela]

DSC00356.JPG show the stack crawl which I could do with a PS/2 keyboard plugged in from boot time. This KDL and identical sc output happen when I plug in the Wacom Graphire 4 tablet or have it plugged in before boot and boot R5.

Side note: when I plug in a USB mouse it speed is much more slow then when this same mouse is plugged in through an USB to PS/2 adapter.

[mmlr]

This stack trace is not really useful as it doesn't contain symbols. Please enable them in the kernel settings file ("/boot/home/config/settings/kernel/drivers/kernel") by uncommenting the line "load_symbols enabled".

You seem to have replaced the usb_scsi module with one compiled from the Haiku tree. This is _not_ supported anymore. The usb_scsi module is in the process of being rewritten to work with the Haiku SCSI subsystem and driver model. This causes the usb_scsi module not to be found when installed under R5 and you will loose it's functionality.

Can you please get me the symbol enabled stack traces then I will look into those issues (again...).

[nutela]

KDL sc with symbols loaded

[nutela]

I added a screenshot now with symbols.

I got this KDL by unpluggin and replugging USB HID devices like Wacom tablet and keyboard described above.

PS: I hope the screenshot is right because I uploaded a diff one by accident and then let it replace with the right one.

[nutela]

KDL sc with symbols loaded

[nutela]

OK there's a bug in Trac or MS IE, please ignore screenshot attachment DSC00435.2.JPG (a copy)

[mmlr]

I was able to reproduce this one (the one with the screeshot) over here. The cause though is not a bug in the USB stack. Usually when you have installed a module in the user add-ons ("/boot/home/config/add-ons/...") it will override the ones present in the system ("/boot/beos/system/add-ons/...") so the USB bus_manager for example is loaded from the user add-ons. The problem is that the bus_manager iterates over available bus modules (UHCI, OHCI, EHCI) and loads them. If you have two versions of them, one in the system add-ons and one in the user add-ons, it will try to load both. This can cause all sorts of bad things to happen as a UHCI driver is loaded twice, it fights over the hardware. Also this exact stack trace happens when it tries to execute an explore on the module that is incompatible with the stack. Can you check if you have two versions of the bus modules installed and if so try to move the system add-ons out of there and see if you can still reproduce this? They should be in "/boot/beos/system/add-ons/kernel/busses/usb".

[nutela]

@mmu_man : Using what version?

I see mmlr commited this; "Commit by mmlr :: hrev22929 /haiku/trunk/src/add-ons/kernel/ (13 files in 2 dirs): Completely redesign the USB explore process. Replaces the scary race conditions of the previous locking mechanism and simplifies handling of device changes by a more centralized approach. Changes are now collected during explore and notifications as well as rescans are done at once. Through this a driver is also not rescanned multiple times anymore. "

I'm rather busy atm, must hook up PC to test.

[mmlr]

Have you been able to test this again? I'd like to close this bug if it was fixed by mentioned revisions. Especially after BeGeistert the combination with usb_hid from Haiku should be pretty solid.

[nutela]

We only have wireless networking (from an access point in the street) and I don't have a wifi card in the beos box. Can you send me a package for R5?

[nutela]

OK tested now in Haiku rev 24195 on real hw and keys are still virtually stuck when I type 1 or more key fast after the other (fast typing), the last key is stuck. This is a wireless keyboard (logitech mx 3200 keyb and mouse). The mouse won't get recognized (no change thus far). Any ideas which I can test/get more output?

[nutela]

I tested my Wacom Graphire 4, works, although I did notice the cursor was trembling (high sensitivity) when I used it in Zeta it didn't but maybe it was my hand this time :) They keyboard however stopped working when I had the wacom plugged in and resumed again when I unplugged the wacom and plugged in an usb mouse.

[stippi]

Yes, the jittering is a known issue. I can reproduce that with my Graphire. Seems like the driver is currently tweaked for the Intuos typical jitter...

[nutela]

This was/is getting messy, sorry for messing this up. I changed the summary this should reflect issues using USB from Haiku on R5.

I'll open a new bug for USB issues on Haiku. And copy paste the Haiku related ones to that.

[nutela]

old syslog

[nutela]

NEW: revision 24493; I build and installed USB on R5 according to the instructions from Michael Lotz on Haiku-os.org "Using the Haiku USB stack". Deleted all USB related things from R5 from /boot/beos/system/... except some kodak_usb, usb_printer and USB Port

1. Boot to R5, R5 hangs on the Desktop background, no cursor, no icons, no Deskbar.

This is with #define TRACE_USB and TRACE_USB_RAW and without it. Tested this also with usb_hid renamed to hid (which seems Be to have done - name the usb_hid "hid"). Also deleted usb_scsi -> always same result (1.)

Must "disable user addons" to boot fully.

Note1 that this didn't happen with the older stack revision 22130 (see above). Note2 I tested multiple Haiku images r 24195 IIRC with functional USB but with bugs (will create new ticket just for my wireless Logitech mx3200) Note3 the instructions in "Using the Haiku USB stack" or no longer valid for usb_raw, it resides in another folder then "objects/...." Note4: I hope I understood correctly USBKit.a is just for developing purposes, didn't install USBKit.a

[nutela]

Something amazing happened when I wrote the above bug (still same session!);

The USB-wireless mx3200 combo works quite correctly, without sticky-key problem, after I had to "disable user addons" with revision 24493.

Will rename "usb_hid" to "hid" to test scroll wheel which doesn't work. Later I will test if this has anything to do with having a ps/2 keyboard and mouse (usb->ps/2) connected to the ps/2 ports.

[nutela]

Tested with unplugged ps/2 keyboard and mouse, but has no effect, the mx3200 works ok except that the scroll wheel's horizontal abilities seems to be mapped differently, and vertical scrolling does not seem to work at all.

The question remains how is this possible with the user addons disabled!? Because really my sound and video won't work when they are in ~/config/... (I have video since I put the driver in /boot/beos/system/... the echo24 however won't because of echo.settings probably)

Should it matter if the usb_hid is called "usb_hid" or "hid"? Shall I test more with the usb_hid driver?

[nutela]

So this is all BIOS USB legacy support :( didn't know. When I turn it off it doesn't work of course. Makes sense at last.

So R5 doesn't boot fully and hangs at the Desktop background with USB from Haiku.

[siarzhuk]

Have you any usb mass storage devices detached from this PC during boot? I've observed very long timeouts in such situation.

[nutela]

Replying to siarzhuk:

Have you any usb mass storage devices detached from this PC during boot? I've observed very long timeouts in such situation.

I have had no usb mass storage device *attached* during boot, so yes detached then, I shall try with an usb stick *attached*.

I have however, tried booting with deleted usb_scsi (and usb_hid) with the same result.

[nutela]

Booted with USB stick with same result.

[mmlr]

You should try a current version of the Haiku USB stack. It was broken for the BeOS target since hrev23820. I worked around that in hrev24894 so it should work again without hanging the system.

[nutela]

the script with wich I jam and install usb support in R5

[nutela]

None of my usb devices worked with revisions over hrev24894 but there is info in the syslog.

[mmlr]

I hope that you did not update using the attached script. If you did I'm surprised that you didn't get crashes. You must in any case update the EHCI driver too when you update the USB bus_manager. Then, as stated a few comments above, the usb_scsi driver is not compatible with R5 anymore. The old BeOS SCSI interface was removed, so this driver cannot work anymore if you compile it from a current tree. Then the usb_hid is apparently not copied after being built? Then you should of course also update the wacom driver as you've obviously have such a device.

TARGET_PLATFORM=r5 jam usb "<usb>uhci" "<usb>ehci" usb_raw usb_hid wacom
copyattr -d "generated..." "/boot/home..."

As in this example you could use a single line command to build all the stuff. Then do the corresponding copy for each of the targets.

[nutela]

I did use the script, it is according to your how-to on Haiku-os.org. Why do I need to build EHCI, I have only UHCI (old pc).

OK I will not build usb_scsi then.

Where should the wacom driver go to?

Thanks. I'll try and update.

[mmlr]

If there is no EHCI at all then you can leave it out of course, didn't assume you were running such an old box ;-). The wacom driver goes to the same place as the usb_hid one. The binary to bin and the link to dev/input. From the syslog it seems at the very beginning that there is a memory leak somewhere so that the USB internal memory allocator runs out of memory. In the rest of the log it doesn't show up again though. And with the very first part missing that lead to that condition it's difficult to track down. The rest seems like "just" unsupported device, which is strange as it leads up to the hub not reporting status either (and I assume they worked at one point). Anyway it's difficult to judge and I care more about the Haiku native version than supporting compatibility with BeOS (sorry). Do you know how these devices behave under a current Haiku installation?

[nutela]

I'll try jamming it when I get home, I would let the results of the syslog be for now. I understand your reluctance of supporting R5 but R5 is the only production stable BeOS compatible OS we have for now and it was a Haiku vision to be able to replace modules in R5 with better Haiku ones as they would get developed but that has somehow been lost. Please understand this is just my opinion and that I am very grateful to use any USB at all :-) Thanks :-)

[nutela]

new usb script to jam usb (according to mmlr's advice)

[nutela]

syslog with the newer partially working usb

[nutela]

Ok, jammed and installed according to usbscript_new. Now it is working but when I kill the input server the system hangs. I'll investigate more later.

The wacom tablet (graphire 4) does not seem to work, however making contact with the pen on the tablet does change the led colour from blue to green, teh tablet works in Haiku though (tested with older revisions, see bug #1949 ).

[mmlr]

That is good to hear. It would be most useful to compare the wacom state to Haiku with the same revision of the USB stack. If it doesn't work under Haiku anymore it would then be a regression introduced in the meantime, which is possible. BTW there is really no need to gzip up files like these before attaching them. The space saving effect does not outweigh the convenience to view the files nicely formated in the bug-tracker instead of having to download and extract them manually.

[stippi]

For the Wacom to work, you need the kernel driver wacom and the input device add-on <input>wacom. Did you install both?

[nutela]

I did now and it works. There is one problem however, the mouse stops working when the wacom tablet is plugged in. Then I unplugged the tablet, the mouse started moving the cursor again, the usb keyboard I have did not anymore, replugging did not resolve it. I bet when I kill the input_server the system will hang again. I'll attach the syslog and the modified usb script so you can see exactly what I have done.

[nutela]

gzipped and concatenated old-syslog and syslog (too much messages to fit in syslog? and too big for Trac sorry)

[nutela]

included jam and install of <input>wacom

[nutela]

I can verify that killing the input server hangs this system (R5 pro netserver).

Btw, ​http://dev.haiku-os.org/ticket/1599#comment:10 "we don't yet support composite hid devices (I'm rewriting this). "

does my logitech mx3200 belong to this group?

[nutela]

Hi I tested the new revision 25683 IIRC of the USB stack on R5, because building a new haiku image takes much more time, I don't know if this is still compatible with R5. It crashes into KDL on boot, only when no USB devices are attached will it boot fully. There is also a 2nd earlier bug still present, when I connect my wacom graphire the mouse and the wacom both seem to control the cursor which should be fine but after a while the mouse stops controlling the cursor and will only regain control after the wacom has been pulled out. I have a KDL pic of the version proir to this one but honestly I don't know exactly which one this is so I'll leave it at that for the moment, the bug manifest itself in this version on R5 as well so...

[nutela]

KDL rev. 25928

[nutela]

seems a similar problem occurs with rev 25928

[mmlr]

The current revision of usb_hid is not compatible with BeOS anymore. I might fix this later on, but right now I don't intend to look into it. I am going to close this bug as invalid, as BeOS compatibility is just a "bonus" that happens to be easily achieved right now. It will get more difficult with time due to architectural changes and taking advantage of new features not provided by BeOS R5. So BeOS R5 support will break at one point and this is not a bug, but simply moving forward. You can still use the usb_hid from before hrev25657 for now, but obviously will not get the composite device support with that. Watch the commits, I will mention it in the message if a commit fixes the R5 case.

[nutela]

Thanks for the info