[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: