USB OHCI support

[wkornewald]

Implement a kernel module for the OHCI protocol.

[tigerdog]

added myself to the cc list on this, as I'm hoping appropriate USB support will get my mouse and KB working with Haiku.

[mmu_man]

There seem to be a skeleton already in, what is missing exactly ?

[nielx]

The guts :-)

Either Salvatore Benedetto will look at it this summer as part of his Google Summer of Code task, or I will in a month when I get back to the Netherlands where my trustworthy haiku computer is.

Though my knowledge still hasn´t improved terribly on the workings of kernels and driver development, so for now I would bet on Salvatore.

[mmlr]

Yes, the actual transfers are the biggest missing part. Salvatore will look at it as a part of GSoC.

[mmlr]

Reassigning to Salvatore as he will work on it.

[tigerdog]

Just a note to request any updated status on this. OHCI support is the only thing keeping me from running Haiku on a daily basis.

[emitrax]

Still working on it, sorry. I didn't have much time lately.

[mmlr]

Working on it. This is a blocker for R1/alpha.

[tigerdog]

Still standing by to test but it's now more difficult since Haiku doesn't boot properly on my hardware (unless I use video safe mode - see bug 2071)

[mmlr]

Commited fix for currently last known bug in hrev25565 and also added OHCI to the image.

Please feel invited to extensively test it out. It should work for all devices that do not need isochronous transfers which means mice, keyboards, hubs, memory sticks, usb network adapters, usb serial adapters... should work now (but only if a driver is present of course). Note however that some of these devices might use EHCI and not OHCI (which should have made them work even before OHCI was implemented).

You can verify what devices are present by looking through "/dev/bus/usb" (with "find /dev/bus/usb" for example) and read out device infos with the usb_dev_info command. Check the output of "usb_dev_info /dev/bus/usb/x/hub" of the "x" where your device is listed under to see if it is attached to a OHCI or EHCI roothub. If you want to really stress test you could also remove the "/boot/beos/system/add-ons/kernel/busses/usb/ehci" so all devices are forced to use OHCI.

Please report back here if you encounter errors. Syslogs and output of usb_dev_info will be helpful in those cases. I can guide you for further debugging if necessary.

[tigerdog]

Excellent! I'll pick up the next nightly, install and test. Thanks for your efforts!

[j_freeman]

Replying to mmlr:

Please report back here if you encounter errors. Syslogs and output of usb_dev_info will be helpful in those cases. I can guide you for further debugging if necessary.

Thanks for working on this! We really appreciate your efforts.

Anyway, I tested hrev25566, but it never gets past the leaf-disk icon on the boot screen. hrev25564, on the other hand, boots successfully. I'll attach the serial log for both revisions. I can probably get the syslog too if that will help as well.

[j_freeman]

Serial log for hrev25564

[j_freeman]

Serial log for hrev25566

[j_freeman]

syslog for hrev25564

[mmlr]

This was probably caused by enabling interrupts before the handler was installed (this looked suspicious to me from the start, but didn't trigger problems with my only test card). I've fixed that in hrev25571 so this should not happen anymore.

[j_freeman]

Just tested hrev25573, and it still hangs at the same spot. I'll attach the serial log. If there's anything else I can provide or do, just ask.

[j_freeman]

Serial log for hrev25573

[jackburton]

If I connect the external USB mouse on my laptop (OHCI), the system hangs. There is no output in the syslog when this happens.

I can provide the complete syslog (with the mouse disconnected) if needed.

[jackburton]

syslog with hrev25573

[mmlr]

Replying to j_freeman:

Just tested hrev25573, and it still hangs at the same spot. I'll attach the serial log. If there's anything else I can provide or do, just ask.

In fact it isn't the same spot. In the first syslog you attached the OHCI didn't seem to be installed at all. Now in the new one it seems to be present. It's interesting though that it hangs with and also without at around the same stage.

Replying to jackburton:

If I connect the external USB mouse on my laptop (OHCI), the system hangs.

Is that if you boot with the mouse connected it hangs, or as soon as you hot-plug the mouse in it hangs?

What you both could do is enable complete logging of all things USB by adding "#define TRACE_USB" at the top of "/haiku/trunk/src/add-ons/kernel/bus_managers/usb/usb_p.h". This should give much more details into the processes and might reveal where it actually hangs.

[j_freeman]

Replying to mmlr:

Replying to j_freeman:

Just tested hrev25573, and it still hangs at the same spot. I'll attach the serial log. If there's anything else I can provide or do, just ask.

In fact it isn't the same spot. In the first syslog you attached the OHCI didn't seem to be installed at all. Now in the new one it seems to be present.

Hmm, are you referring to the file I attached called "syslog" because if so you can ignore that one. It was late last night, and that was actually from a different machine which in fact does not have OHCI.

The last two serial logs seem to end exactly at the same place, the only difference (toward the end) is the lack of "More than 99% interrupts of vector 10 are unhandled" line.

What you both could do is enable complete logging of all things USB by adding "#define TRACE_USB" at the top of "/haiku/trunk/src/add-ons/kernel/bus_managers/usb/usb_p.h". This should give much more details into the processes and might reveal where it actually hangs.

Will do.

[j_freeman]

Serial log for hrev25573 with USB tracing enabled

[andreasf]

I have successfully booted Haiku, used a hot-plugged IntelliMouse Explorer 4.0 and mounted a FAT partition from a hot-plugged no-name flash stick. Everything working fine, except the mouse too fast for my taste. ;-)

If you'd like me to test anything in particular or want serial logs for comparison, let me know.

[andreasf]

serial log for hrev25573

[andreasf]

With mouse attached, same boot issue here. Serial log attached.

When it appears to hang, the last things were the entries about usb_disk followed by uhci: no devices found; then after some time, the IDE errors start pouring in.

[mmlr]

j_freeman: I suppose you do have something attached to the ports when booting too? If so could you try if booting without a device works for you? Also when it hangs at boot could you try getting into KDL by pressing f12 and then run the "ints" command and see if there is some insanely high number on any of the interrupts line (in the handled count column most probably).

Andreas: That's interesting. Could you also check the "ints" command in KDL and look for high numbers? I suppose that it is still an interrupt flood that is triggered. Probably due to the roothub change notification when a device is already plugged in.

Thanks for testing!

[andreasf]

Replying to mmlr:

Could you also check the "ints" command in KDL and look for high numbers? I suppose that it is still an interrupt flood that is triggered.

This is after waiting a couple of seconds:

KDiskDeviceManager::_Scan(/dev/disk/usb)                                        
usb_uhci: no devices found                                                      
CPU 1 halted!                                                                   
PANIC: Keyboard Requested Halt                                                  
                                                                                
Welcome to Kernel Debugging Land...                                             
Running on CPU 0                                                                
kdebug> ints                                                                    
int   0, enabled 1, handled        0, unhandled        0                        
        0x8009fc74                                                              
int   1, enabled 1, handled        0, unhandled        0, ACTIVE                
        0x8009d6b0                                                              
int   6, enabled 1, handled        0, unhandled        0                        
        0x80277b30                                                              
int  10, enabled 1, handled        0, unhandled        0                        
        0x80277b30                                                              
int  11, enabled 3, handled  1566713, unhandled        0                        
        0x80277b30      0x805c3aa0      0x805c3aa0                              
int  14, enabled 1, handled      217, unhandled        0                        
        0x805c3aa0                                                              
int  15, enabled 1, handled       32, unhandled        0                        
        0x805c3aa0                                                              
int 219, enabled 1, handled    12017, unhandled        0                        
        0x8009ecb8                                                              
int 221, enabled 1, handled      603, unhandled        0                        
        0x8009eccc                                                              
int 222, enabled 1, handled        0, unhandled        0                        
        0x8009ecf4                                                              
int 223, enabled 1, handled        0, unhandled        0                        
        0x8009ece0                                                              

[j_freeman]

Replying to mmlr:

j_freeman: I suppose you do have something attached to the ports when booting too? If so could you try if booting without a device works for you? Also when it hangs at boot could you try getting into KDL by pressing f12 and then run the "ints" command and see if there is some insanely high number on any of the interrupts line (in the handled count column most probably).

Yes, I had a webcam and a Microsoft mouse connected. It boots fine with them disconnected, but about every second this is output over the serial debug:

usb_ohci_roothub: request: 0
usb_ohci: port 0 status 0x0100 change 0x0000
usb_ohci_roothub: request: 0
usb_ohci: port 1 status 0x0100 change 0x0000
usb_ohci_roothub: request: 0
usb_ohci: port 2 status 0x0100 change 0x0000
usb_ohci_roothub: request: 0
usb_ohci: port 3 status 0x0100 change 0x0000
usb_ohci_roothub: request: 0
usb_ohci: port 4 status 0x0100 change 0x0000
usb_ohci_roothub: request: 0
usb_ohci: port 5 status 0x0100 change 0x0000
usb_ohci_roothub: request: 0
usb_ohci: port 6 status 0x0100 change 0x0000
usb_ohci_roothub: request: 0
usb_ohci: port 7 status 0x0100 change 0x0000
usb_ohci_roothub: request: 0
usb_ohci: port 8 status 0x0100 change 0x0000
usb_ohci_roothub: request: 0
usb_ohci: port 9 status 0x0100 change 0x0000

It just keeps printing that out over and over, even after Tracker and the Deskbar have been loaded.

Then I tried booting with the mouse connected, and I went into KDL and gave an "ints" command as you instructed:

usb_ohci: version 1.0, legacy support
USB Stack: allocating 256 bytes for USB OHCI Host Controller Communication Area
USB Stack: area = 0x000000dc, size = 4096, log = 0x802ae000, phy = 0x03e4a000
usb_ohci: cold started
usb_ohci: port count is 10
usb_ohci: installing interrupt handler
usb_ohci: OHCI Host Controller Driver constructed
usb_ohci: root hub status change
Last message repeated 2416715 times.
CPU 0 halted!
PANIC: Keyboard Requested Halt

Welcome to Kernel Debugging Land...
Running on CPU 1
kdebug> ints
int   0, enabled 1, handled        0, unhandled        0
0x8009fc74
int   1, enabled 1, handled        0, unhandled        0, ACTIVE
0x8009d6b0
int   5, enabled 2, handled        8, unhandled        0
0x805c4aa00x805c4aa0
int  10, enabled 3, handled  2416716, unhandled        0
0x802a239c0x805c4aa00x805c4aa0
int  11, enabled 2, handled       12, unhandled        4
0x805c4aa00x805c4aa0
int  14, enabled 1, handled      398, unhandled        0
0x805c4aa0
int  15, enabled 1, handled        0, unhandled        0
0x805c4aa0
int 219, enabled 1, handled    11417, unhandled        0
0x8009ecb8
int 221, enabled 1, handled      736, unhandled        0
0x8009eccc
int 222, enabled 1, handled        0, unhandled        0
0x8009ecf4
int 223, enabled 1, handled        0, unhandled        0
0x8009ece0
kdebug> 

[mmlr]

That's perfect, it's exactly what I expected. When booting with devices plugged in it will cause the roothub change interrupt to be triggered pretty much right away. This is not a problem, and it does in fact get handled (otherwise the unhandled count would be a huge number instead). The problem is that these interrupts do not seem to get acknowledged for some reason, so that as soon as the interrupt is handled, another one is generated right away and so on, which brings the system to a halt.

usb_ohci_roothub: request: 0
usb_ohci: port 0 status 0x0100 change 0x0000

That's normal behaviour. The hubs are polled for status changes every second to detect changes on connection status and handle them correctly. Once you plug something in the, change and status field will first get different, then the change will be cleared and the device becomes usable. This could be further optimized by instead of polling using the notification mechanisms to only do on demand bus exploration. USB hubs support that with a dedicated interrupt endpoint, OHCI and EHCI provide an interrupt (the very same one that probably causes the hangs in this case). These could be leveraged to remove the need for polling. Sadly UHCI does not provide such a mechanism so the polling cannot be completely removed (although it could be moved into the UHCI driver). However as it is not really an expensive thing (as the roothubs are short-circuited and do pretty direct register reads to get the status) this enhancement is not urgent at all.

[mmlr]

Bootup hangs should be fixed in hrev25578. Please verify.

[j_freeman]

Replying to mmlr:

Bootup hangs should be fixed in hrev25578. Please verify.

The mouse isn't as smooth as PS/2 (kind of jittery), but no more boot hanging! Thanks for your work!

[mmlr]

Replying to j_freeman:

The mouse isn't as smooth as PS/2 (kind of jittery), but no more boot hanging! Thanks for your work!

If you still have the debug output turned on this would be expected. Otherwise it's a bug ;-).

[j_freeman]

Replying to mmlr:

Replying to j_freeman:

The mouse isn't as smooth as PS/2 (kind of jittery), but no more boot hanging! Thanks for your work!

If you still have the debug output turned on this would be expected. Otherwise it's a bug ;-).

Ah, indeed that was why. :p

[mmlr]

Any other feedback? If there are no remaining issues I'd like to close this enhancement as fixed. The functionality blocking R1/alpha has been implemented and the isochronous support is tracked in the isochronous enhancement #1045.

[tigerdog]

I've been unable to test until today, when the last change made it into a nightly build. I'll test this morning (California time) and post any issues I find.

[tigerdog]

Tested on system with nVidia chipset. Logitech G7 (wireless) mouse works well; not even jittery as described by j_freeman. Mouse also works when hot-plugged. USB Flash drive works.

HOWEVER, I also have a separate Logitech S510 wireless USB Keyboard/mouse combo. Mouse does not work at all; keyboard is jerky, dropping characters and/or repeating them. The receiver is plugged into a KVM switch, but because they work fine under Windows XP, Windows 2000 and Ubuntu 8.04, the combination is at least known to work under other circumstances. I've tried with and without PS2 KB attached, with and without PS2 emulation in BIOS. No change in any case.

I don't have serial debug capability at the moment; is there another way to provide useful information?

[mmlr]

Replying to tigerdog:

HOWEVER, I also have a separate Logitech S510 wireless USB Keyboard/mouse combo. Mouse does not work at all; keyboard is jerky, dropping characters and/or repeating them. The receiver is plugged into a KVM switch, but because they work fine under Windows XP, Windows 2000 and Ubuntu 8.04, the combination is at least known to work under other circumstances. I've tried with and without PS2 KB attached, with and without PS2 emulation in BIOS. No change in any case.

Both of these are issues with usb_hid. Composite hid devices are not currently supported by our usb_hid meaning that for devices that combine two devices in one USB plug one of them won't work. That's simply because usb_hid looks for the first usable interface and uses that. The keyboard issues you mention are reproducible with one system I have. I will look into those but suspect they are also caused by usb_hid (might be OHCI though).

In any case I'm going to work on the usb_hid driver as one of the next things. Will open a corresponding ticket for it.

[oco]

Here is the end of the console output when i boot hrev25614 with USB trace on my laptop (ACER Aspire 1513 LMI). The boot process stop when booting without a card in the flash reader (internally connected through USB) :

USB Stack: register driver "usb_disk" USB Stack: installing notify hooks for driver "usb_disk" USB Device 2: reporting device USB Device 3: reporting device usb_module: get_configuration(24) usb_module: send_request(24, 0xa1, 0xfe, 0x0000, 0x0000, 1, 0x80281d03, 0x80281d04) usb_disk: device reports a lun count of 1 usb_module: queue_bulk(28, 0x80281c68, 31, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(27, 0x80281cd4, 36, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(27, 0x80281c58, 13, 0x805236c4, 0x90cb3f80) usb_disk: vendor_identification "Generic " usb_disk: product_identification "Flash R/W " usb_disk: product_revision_level "2002" usb_module: queue_bulk(28, 0x80281ca8, 31, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(27, 0x80281c98, 13, 0x805236c4, 0x90cb3f80) usb_disk: operation 0x00 failed at the SCSI level usb_module: queue_bulk(28, 0x80281bc8, 31, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(27, 0x80281c34, 18, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(27, 0x80281bb8, 13, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(28, 0x802813f8, 31, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(27, 0x802813e8, 13, 0x805236c4, 0x90cb3f80) usb_disk: operation 0x00 failed at the SCSI level usb_module: queue_bulk(28, 0x80281318, 31, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(27, 0x80281384, 18, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(27, 0x80281308, 13, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(28, 0x80281408, 31, 0x805236c4, 0x90cb3f80) usb_module: queue_bulk(27, 0x8028146c, 13, 0x805236c4, 0x90cb3f80) usb_ohci: td error: 0x00000004 usb_module: clear_feature(27, 0) usb_module: queue_bulk(27, 0x802813f8, 13, 0x805236c4, 0x90cb3f80)

If i put a SD card in the reader, Haiku boot fine. And i can even write to the card. I have no serial port on this laptop but i have attached the syslog for the two boot sequences : the first is incomplete because of the freeze. The second (with the card) is ok.

[jackburton]

Replying to jackburton:

If I connect the external USB mouse on my laptop (OHCI), the system hangs. There is no output in the syslog when this happens.

I can provide the complete syslog (with the mouse disconnected) if needed.

With hrev25627 the external USB mouse works perfectly! Thanks!

[euan]

hrev25653 usb busmanager kdl with usb sd card inserted at boot (ohci, AMD X2 / ATI chipset)

[euan]

I've attached a screen dump of a KDL when booting on my HP 6715b laptop. Seems to be in the USB bus mananger. OHCI chipset, sdcard reader.

[euan]

syslog of hp6715 kdl

[mmlr]

The crash should be fixed in hrev25654. That the device does not fully initialize is because of a timeout. This is most probably caused by having full debug output enabled and the associated delays. Could you please try without TRACE_USB and see if the device still fails to init correctly?

[euan]

I've still to try the patch will do real soon (tm). I think this is the cause, as in several boots since reporting I've found that if i whirl the mousepad round and round whilst booting the issue doesn't occur. Remember when I said Haiku doesn't work unless a mouse / keyboard event occurs??? I also got the AHCI errors again, so I think it is due to this interrupt / hardware issue somewhere.

[euan]

tried the updated patch, seems more stable. I get mostly the ahci issue now. :)

[mmlr]

Replying to tigerdog:

HOWEVER, I also have a separate Logitech S510 wireless USB Keyboard/mouse combo. Mouse does not work at all; keyboard is jerky, dropping characters and/or repeating them. The receiver is plugged into a KVM switch, but because they work fine under Windows XP, Windows 2000 and Ubuntu 8.04, the combination is at least known to work under other circumstances.

I've implemented composite device support while rewriting usb_hid. Could you check if this works correctly now? HID issues are going to be handled as part of enhancement #2253, but if this helps verify that OHCI works fine on your hardware now I'd welcome that info.

[mmlr]

Replying to euan:

tried the updated patch, seems more stable. I get mostly the ahci issue now. :)

Does that mean that it is just more stable and there are still OHCI issues or does OHCI now work as expected?

[tigerdog]

Replying to mmlr: I've implemented composite device support while rewriting usb_hid. Could you check if this works correctly now? HID issues are going to be handled as part of enhancement #2253, but if this helps verify that OHCI works fine on your hardware now I'd welcome that info.

I can't build Haiku ATM, so I'll have to try after the next nightly build is posted. Thanks for the extra effort on composite devices!

[euan]

Replying to tigerdog:

Replying to mmlr: I've implemented composite device support while rewriting usb_hid. Could you check if this works correctly now? HID issues are going to be handled as part of enhancement #2253, but if this helps verify that OHCI works fine on your hardware now I'd welcome that info.

I can't build Haiku ATM, so I'll have to try after the next nightly build is posted. Thanks for the extra effort on composite devices!

As long as I keep moving the mouse round and round USB and everything else ticks along just fine. I can mount the usb memory cards now, and copy files. So I'd say it's working. :)

[scottmc]

With hrev25892 the ohci support is improving. I can now "sometimes" get it to see a USB Flash drive and be able to mount and use it. other times not. I am attaching a serial debug session that spans 4 or 5 reboots, sometimes seeing USB flash drives other times not. The debug shows lots of interesting things, maybe you can make heads or tails of it. As of the end of the serial debug I am still installing from the host onto the USB flash drive, I first initialized it as a BFS partition. It seems to be working but is taking a very long time, over an hour so far, but it's LED is still blinking and the Installing item list in installer is changing every so often so it's still doing something.

[scottmc]

Serial Debug output from the AMD Geode nano motherboard - with hrev25892

[scottmc]

Here's my usb_dev_info output with the USB flash device running and a USB mouse attached as well

[pieterpan]

Last debug output of boot attempt

[pieterpan]

I cannot boot Haiku, and it seems to be related to ohci.. It used to freeze at some of the middle icons, see ticket #2083 for the screenshots. However with the current revision (hrev26069) it freezes after all icons are lit up. With full usb tracing on, I end up with the screenshot I just attached. sometimes I can make it continue to the next page, but if I wait a while the whole screen will go black and even no response to F12.

I have no external USB devices attached. See the attachments to #2083 for my lspci and lsusb.

[pieterpan]

another occurrance. A while later after this the screen went blank, no response to F12

[mmlr]

Replying to pieterpan:

I cannot boot Haiku, and it seems to be related to ohci..

The debug output looks fine to me in fact. The root hub requests are just from the status polling. Those should show up once a second and be repeated for each roothub/controller that is present. Does it boot if you simply remove the UHCI, OHCI and EHCI drivers in /boot/beos/system/add-ons/kernel/busses/usb? Could you also take a look at the output of the "ints" command when you enter KDL when it doesn't get to the desktop?

[tigerdog]

Replying to tigerdog:

Replying to mmlr: I've implemented composite device support while rewriting usb_hid. Could you check if this works correctly now?

Sorry for the delayed reply. Composite device support works well now. Tested with Logitech S510 wireless keyboard/mouse sharing single USB wireless receiver. Thank you!

[pieterpan]

I removed ohci uhci and ehci from the haiku build script, and it still freezes after the last icon. It looks like it is related to #2337, I get a similar BT. So this is probably not related to this ticket.

[stippi]

Scott, so OHCI is not working for you reliably? Or do you think the problem may not be OHCI but one of the drivers using it. In the later case, we could close this bug.

[scottmc]

I'll put a fresh image on that board today and report back soon.

[scottmc]

Ok, progress, I can plug my USB-Compact flash card reader into the AMD Geode board and it sees my 2 Haiku partitions, and auto mounted them. But if I unplug the reader or the card from the reader it drops into KDL. I've attached serial debug from 3 boot sessions, look for the reboot command between them. Unmounting them first and then unplugging works as it's supposed to, so it seems just needs to handle the unplugging condition now. USB mouse works fine, as does USB keyboard.

[mmlr]

No, the KDLs you get this way are perfectly valid. What you do is actively destructive. When it says it could not write back blocks it actually means that you just lost data. A removed device will cause an unmount, as expected, but if there is still unflushed data, a KDL is fine (for now, later for a release it will probably just put the warnings into syslog or pop up an alert). The system cannot know when you are about to unplug the device and therefore it has no way to write the changes back in time (later on we will want to support aggressive write back for removable devices to minimize the impact, however it will never be safe to surprise remove a mounted media). As soon as you unplugged the device it is pretty much too late. Therefore always unmount your volumes (unless they are mounted read-only) before unplugging the media. Anyway this is not a USB or usb_disk issue as they seem to work as expected, that is the devices are working and the unplug triggers an unmount.

Closing this ticket as OHCI works now to the required level. Missing is the isochronous support, which is tracked for OHCI and EHCI in ticket #1045. If anyone encounters bugs in OHCI, please open new tickets for them.