XHCI driver on Pi4

At present the XHCI driver on the Pi 4 (13-Sep-2020 daily build) does not support a USB hub plugged in to one of the four sockets.

The symptoms are that with a hub plugged in, to which is attached a SATA drive, then:
(1) Director hangs, stiffing the machine – remove either Director or the hub and all is fine.
(2) if the hub is unplugged and plugged in to a different USB socket there is an AODT at offset +416C in the XHCI module and the machine is stiffed.

Also some brands of USB pen drive are marginal with XHCI (on Pi4 and Titanium) but that is a separate thing that is not worth pursuing.

Hi Chris,

I have a Aukru USB 3.0 hub plugged to to my Pi4 running the latest RC16 and Beta Rom and don’t see any issues when plugging/unplugging the Hub in to different sockets.

I have the Hub powered and have also tried usb sticks in it and they work with no issues when plugging/unplugging as well.

I however do not use Director.

Hub details:
New USB Device found:

Hope this helps.

I am not so concerned over whether a particular hub works or not. However it should not stiff the machine. Errors should be handled correctly.

I am not so concerned over whether a particular hub works or not. However it should not stiff the machine. Errors should be handled correctly

Agreed but you also need to look at the whole picture hence why I gave my hub details including the class etc as that gives granularity of information that may be useful.

Is your hub powered or non powered.
If as you say you take Director out of the equation it works fine then is it an interaction with that application and what is it configuration and what does it look at.

All this will give greater information to help diagnose any issue in the OS elements.

However it should not stiff the machine.

There’s what should and there’s what does and sometimes they ain’t at all similar.

Errors should be handled correctly.

In my (limited) experience with keyboards (they can stiff the machine too), there’s a bunch of protocols that these things are supposed to support, and then you get the outliers that want to handle fifty key rollover and gestures and stuff, and so they splat out a much larger wodge of data than is expected and it all goes wrong.
Linux doesn’t handle these sorts of things terribly well either, the driver usually crashing.
Which is more or less what RISC OS does, but when your code, buffers, and stack are the same ones (and same privilege) as the kernel, screwing up the stack doesn’t mean the process gets terminated, it means the entire OS poops itself.

As to Director showing up an issue with a hub… That’s a bit weird. I wonder if Director is doing something that is the real issue, and when Director isn’t being used the problem hasn’t gone away, there’s just nothing performing the steps that trigger it.
I say this because hubs are supposed to be largely invisible to anything other than the USB subsystem…

In the interests of pursuing this further I picked up the nearest memory stick to hand, a USB3 SanDisk Ultra 128GB, plugged it directly into a USB2 port on the RPi4. It connected without issue revealing itself to be Fat32 but it readily stiffed the RPi4 on read operations. It did the same to the Titanium. Using Raspberry Pi OS to see what the pen had previously been used for showed it to be an Ubuntu 19.10 installer. The stick had previously used with the Pi for performance tests but with the OTG port, it had RISC OS speed tests on it.

Reformatting it on the Pi to be either SCSI or Fat32 and there were no further issues.

Not that this is very helpful but it does illustrate a pen stiffing RISC OS in use as opposed to stiffing it on plug in.

No external hubs involved in this case.

when Director isn’t being used the problem hasn’t gone away, there’s just nothing performing the steps that trigger it.

When the (presumably same) problem occurs without Director running it is an AODT at +416C in module XHCI.

Are the usb3 sockets on the pi supposed to be working in usb3 mode?

This is my setup

Computer
  | 
  +-1.USB1: , Synopsys DWC OTG root hub
  |     
  +-2.USB2: VIA, XHCI root hub
      | 
      +-1.USB3: USB2.0 Hub
          | 
          +-1.USB17: Western Digital, Passport AV 107B
          |     
          +-2.USB10: GenesysLogic, USB2.0 Hub
              | 
              +-2.USB11: Hub
              |   | 
              |   +-1.USB14: Logitech, USB Receiver
              |   |     
              |   +-2.USB12: EIZO, EIZO USB HID Monitor
              |   |     
              |   +-3.USB15: Majestouch Convertible 2
              |         
              +-4.USB13: CSR8510 A10

USB3 is internal to the pi.
USB10 is a usb3.x hub plugged into a usb3.x port on the pi.
USB17 is a usb3.x hdd plugged into a usb3.x port on the pi.

As you can see both usb3.x devices are connected to the internal USB2.0 Hub.

Are the usb3 sockets on the pi supposed to be working in usb3 mode?

No. USB3 may be part of the USB bounty.

Do you know if the XHCI driver is the same as the one on the Titanium and if so does the Titanium support USB3?

The Titanium uses the same XHCI module as the RPi4. USB3 is not supported.

The Titanium has USB3 hardware, but, like the rest of RISC OS, no driver support (yet).

In light of this thread and the other one thought it might be useful to post my observation here. Unplugging my USB hub (mouse and keyboard) causes the following:

 *where
Address &FC22D150 is at offset &00004178 in module 'XHCIDriver' 

Error block: 80000002 Internal error: abort on data transfer at &FC22D144
R0 = 20033618
R1 = 20033594
R2 = 36146800
R3 = 00018d00
R4 = 60000193
R5 = fc02849c
R6 = 23f794b4
R7 = 23d925e4
R8 = 00000000
R9 = 2001d170
R10 = fa20021c
R11 = fa207f4c
R12 = fa207f50
R13 = fa207f40
R14 = fc22d454
R15 = fc22d14c
CPSR = a0000193
R13_usr = 2022d76c
R14_usr = fc3d2430
R13_svc = fa207f40
R14_svc = fc22d454
SPSR_svc = 40000193
R13_irq = fa101fd0
R14_irq = fc012d74
SPSR_irq = a0000113
R13_abt = fa301fa8
R14_abt = fc22d14c
SPSR_abt = a0000193
R13_und = fa402000
R14_und = fc16f9d0
SPSR_und = 60000113
OSMem16: 2 = fa100000, 00002000, 00002000
OSMem16: 3 = fa200000, 00008000, 00008000
OSMem16: 4 = fa300000, 00002000, 00002000
OSMem16: 5 = fa400000, 00002000, 00002000
Memory: fa100000 - fa102000
Memory: fa200000 - fa208000
Memory: fa300000 - fa302000
Memory: fa400000 - fa402000
Memory: ffff0108 - ffff010c
OSRSI6: 69 = ffff0108

R15 = fc22d14c = XHCIDriver +4174 = xhci_intr +248c
R14_irq = fc012d74 = +12d74 in the Kernel
          Function call to fc028464 = UtilityModule +7eec = ProcessTickEventChain +0

IRQ stack:
fa101fd0 : fc012d74 : - fc028464 return to fc012d74?
         :          : | fc028464 = UtilityModule +7eec
         :          : | = ProcessTickEventChain +0
         :          : | fc012d74 = +12d74 in the Kernel
fa101fd4 : fc2006b8 : - Return to fc2006b8?
         :          : | = Portable +2ac
         :          : | = SWIEntry +0
fa101fd8 : fc0128e8 : - Return to fc0128e8?
         :          : | = +128e8 in the Kernel
fa101fdc : 00000000 : - IRQsema link
fa101fe0 : 000000ff : | R1
fa101fe4 : 0000414e : | R2
fa101fe8 : 00000000 : | R3
fa101fec : 00000006 : | R11
fa101ff0 : 2005ba14 : | R12
fa101ff4 : a0000113 : | PSR
fa101ff8 : 60000110 : | R0
fa101ffc : fc200894 : | R14: fc200894
         :          : | = Portable +488
         :          : | = Idle_WFI +4

R14_svc = fc22d454 = XHCIDriver +447c = kmem_free +24

SVC stack:
fa207f40 : 00000000 : - R11
fa207f44 : fa207f50 : | R12
fa207f48 : fc2293f4 : | R14: fc2293f4
         :          : | = XHCIDriver +41c
         :          : | = _callx__veneer +78
fa207f4c : fc22d440 : | APCS function: fc22d438
         :          : | = XHCIDriver +4460
         :          : | = kmem_free +8
fa207f50 : 00000000 :
fa207f54 : 30000bac :
fa207f58 : 30000aa4 :
fa207f5c : ffff0ad0 :
fa207f60 : 20218ab8 :
fa207f64 : 20057f58 :
fa207f68 : 00000000 :
fa207f6c : 20058134 :
fa207f70 : 00000000 :
fa207f74 : 000008f2 :
fa207f78 : 00000000 :
fa207f7c : fc22937c : - Return to fc22937c?
         :          : | = XHCIDriver +3a4
         :          : | = _callx__veneer +0
fa207f80 : fc02849c : - Return to fc02849c?
         :          : | = UtilityModule +7f24
         :          : | = ProcessTickEventChain +38
fa207f84 : fc200890 : - Return to fc200890?
         :          : | = Portable +484
         :          : | = Idle_WFI +0
fa207f88 : 60000110 :
fa207f8c : fc0106a8 : - fc0176c0 return to fc0106a8?
         :          : | fc0176c0 = +176c0 in the Kernel
         :          : | fc0106a8 = +106a8 in the Kernel
fa207f90 : 00000113 : - PSR?
fa207f94 : 00062fc6 : | SWI XPortable_Idle
fa207f98 : fc1631e0 : | R14: fc1631e0
         :          : | = WindowManager +aac0
         :          : | = powersave_tick +20
fa207f9c : 2058ddb8 : | R10
fa207fa0 : 2022dbc4 : | R11
fa207fa4 : 20054574 : | R12
fa207fa8 : 60000110 : - R0
fa207fac : fc162f80 : | R14: fc162f80 (ASM call to fc1631c0)
         :          : | fc162f80 = WindowManager +a860
         :          : | = repollwimp +4
         :          : | fc1631c0 = WindowManager +aaa0
         :          : | = powersave_tick +0
fa207fb0 : 2022dbc4 :
fa207fb4 : 0000414e :
fa207fb8 : 2022dbc4 :
fa207fbc : 201e5530 :
fa207fc0 : 00000000 :
fa207fc4 : 201e4cf4 :
fa207fc8 : 0000414e :
fa207fcc : 201e55d0 :
fa207fd0 : 00000000 :
fa207fd4 : fc15a608 : - Return to fc15a608?
         :          : | = WindowManager +1ee8
         :          : | = Wimp_SWIdecode +0
fa207fd8 : 00000021 :
fa207fdc : 00000000 :
fa207fe0 : 00000000 :
fa207fe4 : fc0106a8 : - fc0176c0 return to fc0106a8?
         :          : | fc0176c0 = +176c0 in the Kernel
         :          : | fc0106a8 = +106a8 in the Kernel
fa207fe8 : 40000110 : - PSR?
fa207fec : 000600e1 : | SWI XWimp_PollIdle
fa207ff0 : fc192298 : | R14: fc192298
         :          : | = SharedCLibrary +14390
         :          : | = _swix +58
fa207ff4 : 2022bf30 : | R10
fa207ff8 : 2022dd10 : | R11
fa207ffc : 000600e1 : | R12

R14_usr = fc3d2430 = ShareFS +5eb0
          Function call to fc192240 = SharedCLibrary +14338 = _swix +0

USR stack:
2022d76c : 2022dd10 :
2022d770 : 2022d7ac :
2022d774 : 2022dd10 :
2022d778 : 2022d7a8 :
2022d77c : 20000110 :
2022d780 : 80000007 :
2022d784 : 201e5530 :
2022d788 : 00000000 :
2022d78c : 201e4cf4 :
2022d790 : 0000414e :
2022d794 : 201e55d0 :
2022d798 : 00000000 :
2022d79c : fc3d2430 : - fc192240 return to fc3d2430?
         :          : | fc192240 = SharedCLibrary +14338
         :          : | = _swix +0
         :          : | fc3d2430 = ShareFS +5eb0
2022d7a0 : 00000000 :
2022d7a4 : 2022dbc4 :
<cut>
2022db68 : 160c0cf0 :

End of dump

XHCIDriver 0.30 – RISC OS Beta ROM 2022-05-08 07:10:12 on a Pi 4.

We come back to this. There is also a long-standing problem with the Titanium. It will not play ball with a KVM switch, freezing completely when you switch away and back. This has happened with three different KVM switches, all of which are completely OK on other RISC OS hardware, and of course, PC laptop. The RISC OS hardware has included a Pi3 and an ARMBook, an IGEPv5 and an ARMX6.

Unfortunately the Titanium has to be used with a separate keyboard and mouse, or by VNC, both options introducing inconvenience.

Just a small thought…

 *where
Address &FC22D150 is at offset &00004178 in module 'XHCIDriver'

…

Error block: 80000002 Internal error: abort on data transfer at &FC22D144
[...etc...]

It might be useful to have *Where, or more usefully the debugger dump, present a short disassembly around the error point. As we know that it’s an abort, we know all the registers, we have a good trace of how we got there…but we don’t know the actually faulty instruction.

This can be important in the case of using a null pointer (not referring to this case) as it’s pretty easy to recognise LDR R0,[R10,#124] when looking to see that R10 is 0. Oh, okay, so it’s that again…
It can also be useful for picking up screwy things, like the base not being word aligned, etc etc.

I just think having a short disassembly would greatly assist in the usefulness of the dump.

If I’m reading that dump correctly, it crashed here when interrupted? I note that NetBSD code import is 7 years, does it need updating?

Power saving and USB are both involved in this crash, which were my two areas of focus on the other thread – could just be coincidence though.

Caught one on the Titanium on unplugging the wireless keyboard and mouse USB dongle. It was only an error, not a crash, that is the machine kept going after the error. Reported as here.

*FX0
RISC OS 5.29 (08 May 2022)
*help XHCIDriver
==> Help on keyword XHCIDriver
Module is: XHCIDriver      0.30 (12 Sep 2020)

*where
Address &FC1F5384 is at offset &0000417C in module 'XHCIDriver'

*showregs
Register dump (stored at &20072870) is:
R0  = 20030BB8 R1  = 20030B34 R2  = 36108200 R3  = 00008340
R4  = 60000193 R5  = FC02834C R6  = 2445212C R7  = FFFFC6A8
R8  = 00000000 R9  = 2000C050 R10 = FA20021C R11 = FA207F74
R12 = FA207F78 R13 = FA207F68 R14 = FC1F56AC R15 = FC1F5384
Mode SVC32 flags set: NzCvqjggggeAIft        PSR = A0000193

*MemoryI PC-20 + 40
FC1F5364 : ≠..Í : EA0001AD : B       &FC1F5A20
FC1F5368 : t¯ˇÍ : EAFFF874 : B       &FC1F3540
FC1F536C : . †· : E1A02000 : MOV     R2,R0
FC1F5370 : ..ê : E5900000 : LDR     R0,[R0,#0]
FC1F5374 : ..∞ : E5B01004 : LDR     R1,[R0,#4]!
FC1F5378 : .0ë : E5913000 : LDR     R3,[R1,#0]
FC1F537C : ,0ì : E593302C : LDR     R3,[R3,#44]
FC1F5380 : 5.” : E5D30335 : LDRB    R0,[R3,#821]
FC1F5384 < ..P„ : E3500000 : CMP     R0,#0
FC1F5388 : ..í. : 0592101C : LDREQ   R1,[R2,#28]
FC1F538C : ..Q. : 03510001 : CMPEQ   R1,#1
FC1F5390 : ..ü. : 059F1008 : LDREQ   R1,&FC1F53A0
FC1F5394 : `.Ç. : 02820060 : ADDEQ   R0,R2,#&60         ; ="`"
FC1F5398 : ‚... : 0A0000E2 : BEQ     &FC1F5728
FC1F539C : .†· : E1A0F00E : MOV     PC,R14
FC1F53A0 : §S.¸ : FC1F53A4 : Undefined instruction

*MemoryI R14-20 + 40
FC1F568C : .¿†· : E1A0C00D : MOV     R12,R13
FC1F5690 : .ÿ-È : E92DD800 : STMDB   R13!,{R11,R12,R14,PC}
FC1F5694 : ..†· : E1A00002 : MOV     R0,R2
FC1F5698 : .0≤ : E5B23008 : LDR     R3,[R2,#8]!
FC1F569C : .∞L‚ : E24CB004 : SUB     R11,R12,#4
FC1F56A0 : ..S„ : E3530000 : CMP     R3,#0
FC1F56A4 : ..ê. : 15900004 : LDRNE   R0,[R0,#4]
FC1F56A8 : 3ˇ/. : 112FFF33 : BLXNE   R3                 ; ARMv5 or later
FC1F56AC : ..†„ : E3A00000 : MOV     R0,#0
FC1F56B0 : .®.È : E91BA800 : LDMDB   R11,{R11,R13,PC}
FC1F56B4 : ..†„ : E3A01000 : MOV     R1,#0
FC1F56B8 : ..ÄÂ : E5801008 : STR     R1,[R0,#8]
FC1F56BC : ..†· : E1A01000 : MOV     R1,R0
FC1F56C0 : ..ü : E59F0000 : LDR     R0,&FC1F56C8
FC1F56C4 : 9..Í : EA000239 : B       &FC1F5FB0
FC1F56C8 : åV.¸ : FC1F568C : Undefined instruction
*

I note that NetBSD code import is 7 years, does it need updating?

There is an open “Update the USB stack” bounty that suggests exactly that.

On the other hand, NetBSD got a new USB stack a few years ago that is said to be much better than the old one. No idea if it would be easier or harder to port.

Probably a waste of time debugging if a new stack is in-progress..

I wondered if it was disposing of the USB elements in the wrong order, although I didn’t search the driver to see how it handled the tree structure.

Probably a waste of time debugging if a new stack is in-progress..

The bounty is open. Not taken, not in-progress. So it could take years, or decades, or forever.