[haiku-commits] Re: haiku: hrev52885 - src/add-ons/kernel/busses/usb
- From: Greg Crain <gsc70@xxxxxxxxxxx>
- To: waddlesplash <waddlesplash@xxxxxxxxx>, haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 18 Feb 2019 11:40:52 -0500 (EST)
----------------------------------------------------------------------------
6554cc220fbc: XHCI: Fix the build of tracing code.
a881209f38d9: XHCI: Minor tweaks and other changes.
* Cap fSlotCount at the hardware level, not just at the software
level.
* Clear interrupts in init routine.
* Write high DMA address of DCBAAP.
Found by cross-comparing with DragonFlyBSD and OpenBSD.
eae896c7aeff: XHCI: Print command code in "unsuccessful command" log message.
This should help with debugging #13772.
[ Augustin Cavalier <waddlesplash@xxxxxxxxx> ]
I'm trying to get back into the XHCI stuff.. I ran into the tracing problem you
fixed here, but didn't investigate deeper. I've been having trouble compiling
on my x64 machine.. It hard locks, and freezes with no debug messages or
anything.. It only happen while compiling Haiku!?
Anyway, I see your doing a lot of investigation of the XHCI, and I wanted to
tell you about something I found a little while ago that doesn't seem right.
I have an older version of the XHCI chip and it seems that the IRQ's stop
responding to SubmitNormalRequest's, after a few transfers. Actually, after it
seems right after getting the device name from usb_disk.
When this happens, I added some debug code, and a Noop call, and then I get an
IRQ immediately for a Noop.. so interrupts are still working, and it seemed
like something like the endpoint not responding. But I checked and it seemed
ok, not halted or stalled it seemed.
I added an 'endpoint status dump', looping the endpoint status, and this is
what I got (with my notes):
xhci: endpoint[0] context = EP 0
0: 0x00000001 :Running
1:0x02000026 bits 5:3 ‘100’ = Control Bi-Directional
2:0x000000000e1e4001
4:0x00000008
xhci: endpoint[1] context = EP 1 OUT (Direction = 0)
0: 0x00000000 :Disabled !!
1:0x00000000
2:0x0000000000000000
4:0x00000000
xhci: endpoint[2] context = EP 1 IN (Direction = 1)
0: 0x00000001 :Running
1:0x04000036 bits:5:3 '110' = BULK-IN = 6
2:0x000000000e1e4101
4:0x00001000
xhci: endpoint[3] context = EP 2 OUT (Direction = 0)
0: 0x00000001 :Running
1:0x04000016 bits:5:3 '010' = BULK-OUT = 2
2:0x000000000e1e4181
4:0x00001000
xhci: endpoint[4] context
0: 0x00000000
1:0x00000000
2:0x0000000000000000
4:0x00000000
xhci: endpoint[5] context
0: 0x00000000
1:0x00000000
2:0x0000000000000000
4:0x00000000
While the endpoint[0] is a control endpoint and running, but endpoint[1] is
not, nor configured. endpoint[2] and endpoint[3] seem to be configured
correctly, but they are not matched pairs.
Looking at Figure 6-1 in the spec, and how the endpoints are numbered, is can
be confusing since the Index 0, is used as the Slot Context. There are
several places in the code where there could be a mixup of the endpoint index,
whether or not the Slot context is included.. It looks like from the spec,
that EP Context 0, is correct, while endpoint[1] and endpoint[2] should be the
EP Context for 1, but it seems to be shifted.
Maybe the EP offset is something that is not important to the controller, but I
can't figure out why there were no interrupts when the doorbell register is
rang.. it just stops responding. But a Noop IRQ, still worked.
Greg
Other related posts: