Most long-standing XHCI (USB 3.0+) issues resolved! | Haiku Project


#1

Last month, I sat down and decided to at the very least attempt to fix our XHCI (USB 3 host controller) bus driver. Issues with it have been the most significant problem users have been facing, as most hardware made post-2012 has an XHCI chip as the system’s primary USB chip, and most hardware made post-2014 (or so) has exclusively an XHCI chip and no EHCI (USB 2.0) or prior chipsets (which we do support very well.)


This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/waddlesplash/2019-03-08_most_long-standing_xhci_usb3_issues_resolved/

#2

Don’t forget to donate to say thanks, https://www.haiku-inc.org/donate/

Hopefully we can get enough donations to sponsor some work on things like 3d drivers, on going network driver support, Ryzen Support, media kit improvments etc…


#3

Haiku’s USB stack doesn’t support USB attached SCSI yet right? That’d be another nice to have feature.


#4

Don’t most UAS devices support operating in standard “USB Storage” mode (i.e. with just the limited set of SCSI commands those usually use?) I think I recall attaching some large hard disks to Haiku via USB and they worked.


#5

Yes, UAS just allows command queuing etc… since BOT is sort of a limited subset of SCSI anyway. It apparently also opens the potential for TRIM support on USB devices.

I think in real world it ends up being something like 250-300MB/s vs 300-400MB/s or so for a UAS device basically due to elimination of overhead in the BOT protocol.


#6

Awesome work! Obviously you are becoming quite a USB expert. Thanks for the effort, as I think this was a huge issue for a lot of people trying Haiku on newer hardware.


#7

Amazing work well done and thumbs up.
How to test it the best way to make it even better?


#8

Fixing usb3 drive means new Haiku beta, as I understand…


#9

The second beta is still scheduled for this September. I’d like to fix the remaining boot failures I mentioned in this post (well, @Greg.Crain is looking into those, for now) and then maybe get isochronous transfers for USB audio (though I already have a WIP of this, it’s stalled because @Barrett never fixed the media_server crashes related to using a second audio device.)


#10

because no one fixed the crashes. It’s not just one single dev fault.


#11

I still get a kernel panic whenever an application tries to use my USB gamepad (Logitech F310).


#12

The fixes are only in master, not in the beta branch. But if you are on the hrev mentioned in the blog post (or higher) and still get kernel panics, please open a new ticket.


#13

Uh? Is this person serious?


#14

He’s a seriously hard working developer and member of the community. I don’t know if that excuses the above comment though. Perhaps he was just having a bad day. I don’t see that as his normal tone and demeanor.


#15

Please stop insulting other developers. You have already been warned about this.


#16

…but you could fix the media_server crashes?
…if you don’t like to work on it… some other dev is in need!

It would be a great step forward to support him to get those isochronous transfers for USB audio to work!


#17

I am actually the person insulted.


#18

Yes, it wasn’t nice of waddlesplash to put the blame on you alone.


#19

Teamwork makes the dream work.


#20

Unfortunately, I think these changes broke my USB3 Ethernet adapter. I need to gather the information for a bug report.