OSDev.org

I don't know if this is relevant or not, but I had an buffer error in my XHCI driver, and it resulted in the event ring stopping too. The USB status register indicated halted and controller error. That's the only scenario I've seen that results in commands on the command ring not resulting in activity on the primary event ring.

I also had problems with multiple MSI vectors. One of my XHCI controllers failed to send the IRQ when the second interrupter was used. I could pin-down this problem to the IRQ itself, because if I sent an IPI to the same vector then all the chains in the event ring happened as expected. I don't know if this is a bug in XHCI or how I setup MSI interrupts. Still, I do use multiple MSI interrupts with AHCI, and it seems to work there, so I don't know.

Progress report: I allocated the scratchpad buffers. Contexts are already proper sizes, either 32-bit or 64-bit. Now everything works on my laptop, including the initialization of xHC, ports, slots, and endpoints. Port Status Change TRB is issued after a new USB device is plugged.
Still, this OS cannot receive any TRBs on my desktop.

I found that Haiku iterated over the xHCI capabilities to move the ownership of the xHC: https://github.com/haiku/haiku/blob/mas ... i.cpp#L293
I'll do the same and check if it is the cause.

tokusan wrote:I found that Haiku iterated over the xHCI capabilities to move the ownership of the xHC: https://github.com/haiku/haiku/blob/mas ... i.cpp#L293
I'll do the same and check if it is the cause.

Yes, it was the cause. I just misunderstood the spec. Now this OS can find the connected ports.

Thank you for taking your time, nullplan, rdos, and iman.