Bug: XHCI (usb 3.0) issues


#1

As we work to stabilize Haiku and move closer to the R1 beta releases, USB driver issues are becomming more apparent.


This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/kallisti5/2017-07-17_bug_xhci_usb_30_issues/

#2

I started looking at the isochronous streams stuff a few months back but it was hard going - there was a lot to learn and I couldn’t dedicate enough time to it to get anywhere useful.

Whoever takes this on, I recommend looking at maybe one of the BSD XHCI drivers to get an idea of how that implements the specifications above, and only when you feel you fully understand it, go for it. In my experience, it’s easy to get started on something and “run out of bricks” because it’s hard to see the full picture from the get-go.


#3

I’m not sure anyone else is actively working on this, but this is what I have found so far.

I’ve been doing all my development on real hardware. By chance, all computers that I have access to happen to have the NEC/Renesas USB chipset, uPD720200 series. None of the computers ever had any success what so ever with the xhci driver.

I added a bunch of debug code, and found that the Noop() works consistently, so Command Transfers are working fine.
However, the driver would always fail trying to get the device descriptors.
I found a bug, and now the driver is able to complete getting the device descriptors for connected devices.
There’s still a problem with the buffer and TRB completion handling that causes transfers to stop at some point after.

I had no previous USB experience, but since you posted this a few months ago, I’ve been digging in and learning. I’m going to continue working on it and hopefully get it working.


#4

Thanks for digging in! Never be afraid to take a look at an issue, you’ll likely not be stepping on anyones toes and the community will appreciate the help more than anything. Everyone has to start somewhere :slight_smile:


#5

great work so far…
try and learn…
and you will make us all happy too… thx


#6

Thanks for investigating this. If you found bugs, don’t forget to submit patches for review at http://dev.haiku-os.org .


#7

So I was formatting a patch to submit, and I thought I would update my source to the latest HREV, using the command
git pull --rebase
So, it wouldn’t build, so I then did a
jam clean
Still no luck same error.
So I renamed my source directory and did a complete fresh clone of ‘haiku’. I ran configure again, and I still got the same errors trying to build.

command_checksum.cpp:(.text+0x35c): undefined reference to BPrivate::SHA256::SHA256(void)' command_checksum.cpp:(.text+0x36e): undefined reference toBPrivate::SHA256::Init(void)‘
command_checksum.cpp:(.text+0x3a1): undefined reference to BPrivate::SHA256::~SHA256(void)' ... /boot/home/haiku/generated/objects/haiku_host/x86_gcc2/release/tools/package/command_checksum.o: In functionChecksumIO::~ChecksumIO(void)’:
command_checksum.cpp:(.gnu.linkonce.t._._10ChecksumIO+0x25): undefined reference to `BPrivate::SHA256::~SHA256(void)’

I know the SHA256 was changed, but I thought it was working. Also, I know that there was an ABI change, but I didn’t think that would actually impact the build process on my machine.
I also can’t seem to do a clone of an earlier HREV. I saw the note in UserBuildConfig, but that didn’t help, and I’m not sure how it would because the latest source is already on my machine.
Any suggestions??


#8

You need to update your running system to match the sources you are working with. This is a limitation of building Haiku within Haiku: you are in a grey area between cross-compiling and compiling native binaries, so, strange things happen. In this particular case, we compile some tools for the host Haiku system and assume the API is compatible with the target system. But in your case, it is not.


#9

So here’s my status update. I am attaching a PATCH to the first ticket 13343 that you reference, but I didn’t actually work in QEMU. Actually, it may impact all those tickets. I’ve been looking at the code trying to find bugs in general.

I’ve been investigating the xhci (usb3) driver and found a few things.
All of my hardware that I have access to happens to have the NEC/Renesas chipset. Previously,
none of the hardware was even recognized, and it would fail at getting the device descriptors.
With the patch that I have submitted and attached, things are starting to work, and the attached
devices are reported, and even working.

What I’ve found though, is that early rev. chips, 0.96 seem to have an issue and interrupts seem
to stop being generated. I believe it is related to an errata for missing interrupts on partial
transfers. I haven’t been able to come up with a solution yet.

Now the same chipsets that are later revisons work much better for me. I was able to mount
drives, watch videos, and even boot from a USB3 port. Although, sometimes it was tough to even
get the bios to recognize the thumbdrive attached. I don’t believe it’s stable yet though.

Back to the early rev. chipsets, it may be a regression in system performance until a solution is found.
If a device is connected to the xhci port, and you right click in Tracker to ‘Mount’ it takes some
time to respond while the system tries to query the device, but receives no response. And I did get an occasional KDL on boot, so I think there is still a memory allocation or access issue.

I’m not sure how the project wants to proceed with the patch, but I wanted to get it out there and
hopefully some others can help debugging. I am still working on it, but maybe those with more
USB knowledge will have some ideas.


#10

Great job Greg! You definitely solved #13343!
We’re one step closer to R1!!


#11

Thanks a bunch, Greg! You also fixed #12883 - “Laggy mouse” and #12895 - “PANIC: did not find any boot partitions!” when booting from USB3 port.
:clap: :clap: :clap:


#12

Good job!

I have a USB3 controller card with Renesas chipset too, will try it out on the weekend.


#13

Wow! That’s great to hear! Closing bugs is good. I don’t have any USB 3.1 devices yet. I’m curious how those will behave.


#14

Great job thank you very much…


#15

Add https://dev.haiku-os.org/ticket/13062 to that list, so finally I can use these two other USB ports on my laptop and don’t need to carry a hub everywhere. Thanks!


#16

aaaaaaaa this is great