Opened 12 years ago

Closed 11 years ago

#1044 closed enhancement (fixed)

USB OHCI support

Reported by: wkornewald Owned by: mmlr
Priority: blocker Milestone: R1/alpha1
Component: Drivers/USB Version: R1/pre-alpha1
Keywords: Cc: niels.reedijk@…, doug@…, siarzhuk, andreasf, j_freeman, alaricx@…, euan, scottmc, pieter@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Implement a kernel module for the OHCI protocol.

Attachments (15)

r25564.log (116.5 KB) - added by j_freeman 11 years ago.
Serial log for hrev25564
r25566.log (108.5 KB) - added by j_freeman 11 years ago.
Serial log for hrev25566
syslog (70.0 KB) - added by j_freeman 11 years ago.
syslog for hrev25564
r25573.log (108.2 KB) - added by j_freeman 11 years ago.
Serial log for hrev25573
syslog.txt (307.2 KB) - added by jackburton 11 years ago.
syslog with hrev25573
r25573_usb_trace.log (108.3 KB) - added by j_freeman 11 years ago.
Serial log for hrev25573 with USB tracing enabled
r25573_af_mouse.log (39.5 KB) - added by andreasf 11 years ago.
serial log for hrev25573
syslog.log (174.9 KB) - added by oco 11 years ago.
DSC00699.JPG (85.2 KB) - added by euan 11 years ago.
hrev25653 usb busmanager kdl with usb sd card inserted at boot (ohci, AMD X2 / ATI chipset)
DSC00698.JPG (132.2 KB) - added by euan 11 years ago.
syslog of hp6715 kdl
usb-serial-debug.txt (157.1 KB) - added by scottmc 11 years ago.
Serial Debug output from the AMD Geode nano motherboard - with hrev25892
usb_dev_info-amd-geode.txt (3.3 KB) - added by scottmc 11 years ago.
Here's my usb_dev_info output with the USB flash device running and a USB mouse attached as well
DSC_8530.JPG (260.0 KB) - added by pieterpan 11 years ago.
Last debug output of boot attempt
DSC_8532.JPG (262.2 KB) - added by pieterpan 11 years ago.
another occurrance. A while later after this the screen went blank, no response to F12
AMD-Geode-r26560-serial-debug.txt (134.8 KB) - added by scottmc 11 years ago.

Change History (72)

comment:1 Changed 12 years ago by nielx

Cc: niels.reedijk@… added

comment:2 Changed 12 years ago by tigerdog

Cc: doug@… added

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

comment:4 Changed 12 years ago by siarzhuk

Cc: siarzhuk added

comment:5 Changed 12 years ago by mmu_man

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

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

comment:7 Changed 12 years ago by mmlr

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

comment:8 Changed 12 years ago by mmlr

Milestone: R1R1/alpha
Status: newassigned

comment:9 Changed 12 years ago by mmlr

Owner: changed from mmlr to emitrax
Status: assignednew

Reassigning to Salvatore as he will work on it.

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

comment:11 Changed 11 years ago by emitrax

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

comment:12 Changed 11 years ago by andreasf

Cc: andreasf added

comment:13 Changed 11 years ago by j_freeman

Cc: j_freeman added

comment:14 Changed 11 years ago by dustin howett

Cc: alaricx@… added

comment:15 Changed 11 years ago by mmlr

Owner: changed from emitrax to mmlr
Priority: normalblocker
Status: newassigned

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

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

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

comment:18 Changed 11 years ago by tigerdog

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

comment:19 in reply to:  17 Changed 11 years ago by 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.

Changed 11 years ago by j_freeman

Attachment: r25564.log added

Serial log for hrev25564

Changed 11 years ago by j_freeman

Attachment: r25566.log added

Serial log for hrev25566

Changed 11 years ago by j_freeman

Attachment: syslog added

syslog for hrev25564

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

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

Changed 11 years ago by j_freeman

Attachment: r25573.log added

Serial log for hrev25573

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

Changed 11 years ago by jackburton

Attachment: syslog.txt added

syslog with hrev25573

comment:23 in reply to:  21 ; Changed 11 years ago by 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.

comment:24 in reply to:  23 Changed 11 years ago by 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.

Changed 11 years ago by j_freeman

Attachment: r25573_usb_trace.log added

Serial log for hrev25573 with USB tracing enabled

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

Changed 11 years ago by andreasf

Attachment: r25573_af_mouse.log added

serial log for hrev25573

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

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

comment:28 in reply to:  27 ; Changed 11 years ago by 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                                                              

comment:29 in reply to:  28 Changed 11 years ago by 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> 

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

comment:31 Changed 11 years ago by mmlr

Bootup hangs should be fixed in hrev25578. Please verify.

comment:32 in reply to:  31 ; Changed 11 years ago by 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!

comment:33 in reply to:  32 ; Changed 11 years ago by 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 ;-).

comment:34 in reply to:  33 Changed 11 years ago by 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

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

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

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

comment:38 in reply to:  37 Changed 11 years ago by 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.

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

Changed 11 years ago by oco

Attachment: syslog.log added

comment:40 in reply to:  22 Changed 11 years ago by 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!

Changed 11 years ago by euan

Attachment: DSC00699.JPG added

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

comment:41 Changed 11 years ago by euan

Cc: euan added

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.

Changed 11 years ago by euan

Attachment: DSC00698.JPG added

syslog of hp6715 kdl

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

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

comment:44 Changed 11 years ago by euan

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

comment:45 in reply to:  37 ; Changed 11 years ago by 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.

comment:46 in reply to:  44 Changed 11 years ago by 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?

comment:47 in reply to:  45 ; Changed 11 years ago by 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!

comment:48 in reply to:  47 Changed 11 years ago by 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. :)

comment:49 Changed 11 years ago by scottmc

Cc: scottmc added

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.

Changed 11 years ago by scottmc

Attachment: usb-serial-debug.txt added

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

Changed 11 years ago by scottmc

Attachment: usb_dev_info-amd-geode.txt added

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

Changed 11 years ago by pieterpan

Attachment: DSC_8530.JPG added

Last debug output of boot attempt

comment:50 Changed 11 years ago by pieterpan

Cc: pieter@… added

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.

Changed 11 years ago by pieterpan

Attachment: DSC_8532.JPG added

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

comment:51 in reply to:  50 Changed 11 years ago by 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?

comment:52 in reply to:  47 Changed 11 years ago by 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!

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

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

comment:55 Changed 11 years ago by scottmc

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

Changed 11 years ago by scottmc

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

comment:57 Changed 11 years ago by mmlr

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.