XHCI driver on Pi4
Pages: 1 2
Chris Hall (132) 3554 posts |
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: 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. |
Doug Webb (190) 1158 posts |
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: Hope this helps. |
Chris Hall (132) 3554 posts |
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. |
Doug Webb (190) 1158 posts |
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. All this will give greater information to help diagnose any issue in the OS elements. |
Rick Murray (539) 13805 posts |
There’s what should and there’s what does and sometimes they ain’t at all similar.
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. 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. |
David Pitt (3386) 1248 posts |
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. |
Chris Hall (132) 3554 posts |
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. |
Colin (478) 2433 posts |
Are the usb3 sockets on the pi supposed to be working in usb3 mode? This is my setup
USB3 is internal to the pi. As you can see both usb3.x devices are connected to the internal USB2.0 Hub. |
David Pitt (3386) 1248 posts |
No. USB3 may be part of the USB bounty. |
Colin (478) 2433 posts |
Do you know if the XHCI driver is the same as the one on the Titanium and if so does the Titanium support USB3? |
David Pitt (3386) 1248 posts |
The Titanium uses the same XHCI module as the RPi4. USB3 is not supported. |
Martin Avison (27) 1491 posts |
The Titanium has USB3 hardware, but, like the rest of RISC OS, no driver support (yet). |
Andrew McCarthy (3688) 605 posts |
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:
XHCIDriver 0.30 – RISC OS Beta ROM 2022-05-08 07:10:12 on a Pi 4. |
Chris Johnson (125) 825 posts |
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. |
Rick Murray (539) 13805 posts |
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 I just think having a short disassembly would greatly assist in the usefulness of the dump. |
Jon Abbott (1421) 2641 posts |
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. |
David Pitt (3386) 1248 posts |
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 * |
Steffen Huber (91) 1948 posts |
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. |
Jon Abbott (1421) 2641 posts |
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. |
Steffen Huber (91) 1948 posts |
The bounty is open. Not taken, not in-progress. So it could take years, or decades, or forever. |
Ralph Barrett (1603) 153 posts |
The XHCIdriver bug(s) remain in the latest Risc OS build. Note that the version of the XHCIDriver module has been bumped from above, but the crash dumps are almost identical. ARM instruction is the same… This dump was triggered by switching my USB2.0 switchbox between an RPi4 and an RPi2. Dump is from the RPi4. Do not get this issue on the RPi2 (hmmm wonder if this issue is timing related and only occurs on the faster RPi4 ?).
|
David Pitt (9872) 362 posts |
This unaccepted merge request is of interest a Pi ROM incorporating it was here. (Removed. It did stop the abort but then went on to an unrecoverable crash. See below.) *FX0 RISC OS 5.31 (16 Oct 2024) *help XHCIDriver ==> Help on keyword XHCIDriver Module is: XHCIDriver 0.31 (11 May 2024) Disconnect_Abort_Fix.1 The only device I have to test this is a two way USB switch that does the show the fault with the default XHCIDriver, it is OK with the test ROM on an RPi4B. HTH. |
David J. Ruck (33) 1629 posts |
We really need this merged, this keeps taking my Pi 4B down. It’s very annoying as I’m normally using VNC from my Linux laptop and not even switching to it, but my soft switch automatically selects which ever device has just booted, and I have to cycle past the RISC OS Pi to get back to the laptop. Upgrading to 5.30 didn’t change anything, it still hangs or crashes about 1 in every 3 switches. |
Ralph Barrett (1603) 153 posts |
Bad news. I suspect that this merge request was not accepted because this ‘fix’ was not 100% successful. I loaded the suggested 5.31 ROM into my RPi4 on 5.31. I was not able to get an abort (as before). However, after a few switch-box switches, the USB keyboard and mouse became totally unresponsive. The RPi4 had to be rebooted to recover. Better to have the previous abort and associated dead dump I guess… Ralph |
Steve Fryatt (216) 2103 posts |
The Pi 2 doesn’t use XHCI, does it? |
Pages: 1 2