CLS Realtek Gigabit Ethernet Adapter not Working with Vero 4k

[mgc8]

Hello,

I have just purchased a Vero4K and am quite happy with it – wonderful little device! – apart from the pain of the 100Mbps Ethernet (which I was aware of). No problem though, this thread provided hope with the use of an USB adapter!

I therefore also got one of the recommended, known working adapters from this page – the CSL Realtek-based one mentioned above; even came from Amazon in the little blue box, assorted with the OSMC

Alas, it does not work at all; the experience was anything but plug-and-play. I tried plugging it in before and after booting the Vero4k, with and without a cable, while in the console as well as in Kodi. Nothing works to get it running. Looking at the logs, it seems that there is a problem with the USB3 (xhci-hcd) support on the OSMC, the driver keeps dying and restarts permanently (see below for logs example). Basically, it’s stuck in a loop of detect → configure → crash → die → detect → …

I also tried another USB3/Gigabit adapter I had around the house, a Surecom one based on the ASIX 88xxxx, and with that one it’s not even detected by the kernel – nothing appears in the logs, nothing in lsusb, it’s as if it doesn’t exist.

Needless to say, both adapters work just fine and fast when connected to other machines.

So, here I am asking for your kind help. Is there any magical incantation that one has to do to get USB3 working on this device? I tried plugging in a keyboard and mouse combo (using USB2/slow speed) and they both worked fine; seems that USB3 is the problem. Since there is no USB3 support anyway, can we disable the driver? I tried rmmod-ing it but unfortunately it’s built-in :-/

[====================== dmesg ==========================]

[ 74.013471] usb 1-1: new full-speed USB device number 2 using xhci-hcd
[ 84.023091] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
[ 84.023139] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting host.
[ 84.047263] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000 microseconds.
[ 84.047297] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not halting.
[ 84.047323] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
[ 84.047407] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
[ 89.042875] xhci-hcd xhci-hcd.0.auto: Timeout while waiting for a slot
[ 89.042890] xhci-hcd xhci-hcd.0.auto: Abort the command ring, but the xHCI is dead.
[ 89.062895] amlogic_xhci_work lock
[ 89.062954] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 89.062972] usb usb2: USB disconnect, device number 1
[ 89.064617] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[ 89.064633] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 89.064646] usb usb1: USB disconnect, device number 1
[ 94.042796] xhci-hcd xhci-hcd.0.auto: Timeout while waiting for a slot
[ 94.042825] xhci-hcd xhci-hcd.0.auto: Abort the command ring, but the xHCI is dead.
[ 99.042620] xhci-hcd xhci-hcd.0.auto: Timeout while waiting for a slot
[ 99.042635] xhci-hcd xhci-hcd.0.auto: Abort the command ring, but the xHCI is dead.
[ 99.044121] xhci-hcd xhci-hcd.0.auto: USB bus 1 deregistered
[ 99.152683] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 99.152720] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[ 99.153541] xhci-hcd xhci-hcd.0.auto: irq 62, io mem 0xc9000000
[ 99.153680] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 99.153687] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 99.153692] usb usb1: Product: xHCI Host Controller
[ 99.153697] usb usb1: Manufacturer: Linux 3.14.29-55-osmc xhci-hcd
[ 99.153702] usb usb1: SerialNumber: xhci-hcd.0.auto
[ 99.155095] hub 1-0:1.0: USB hub found
[ 99.155538] hub 1-0:1.0: 2 ports detected
[ 99.155755] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 99.155772] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[ 99.155897] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 99.155904] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 99.155909] usb usb2: Product: xHCI Host Controller
[ 99.155914] usb usb2: Manufacturer: Linux 3.14.29-55-osmc xhci-hcd
[ 99.155919] usb usb2: SerialNumber: xhci-hcd.0.auto
[ 99.157351] hub 2-0:1.0: USB hub found
[ 99.157402] hub 2-0:1.0: config failed, hub doesn’t have any ports! (err -19)
[ 99.157548] amlogic_xhci_work unlock
[ 99.472681] usb 1-1: new full-speed USB device number 2 using xhci-hcd
[ 109.482742] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.

(… rinse and repeat …)

[====================== dmesg ==========================]

Thank you in advance for any information,
Regards,
Mihnea

[sam_nazarko]

Vero 4K doesn’t support USB 3.0, but USB 3.0 is backwards compatible.
Have you verified the stick in another machine?

Sam

[JimKnopf]

@mgc8: Is there anything else connected to the USB ports of the Vero4k? My Anker adapter requires in peaks 150 mA.

Perhaps, it is helpful to collect a full log set like described here.
So,

• activate logging
• reboot the Vero 4k
• upload the log set by either grab-logs -A or the MyOSMC GUI method and provide the URL, here

[mgc8]

Hello @sam_nazarko, @JimKnopf,

Thank you for the quick reply and for looking into this!

I have enabled debugging and generated the log, it is available here:
https://paste.osmc.tv/evoyihijiw
(please note that I am one of those “certain people” who don’t like their private information and passwords to be posted on the public Internet; I had to redact it to remove a lot of sensitive information which had otherwise nothing to do with this bug, like my SMB passwords(!) )

To answer your questions:

1. Yes, I have tried the adapter in other machines and it works perfectly, achieving around 900 Mbps on USB 3 – I actually mentioned this in the initial message
2. The power usage is a good hint, I actually thought of that as well but I don’t have a powered USB hub to test with; I can confirm that the adapter was the only USB device connected to the Vero4k while performing these tests – apart from the HDMI and Audio/Toslink there was nothing else.

I actually did try connecting a USB keyboard in order to investigate, and interestingly it also intermittently stopped working when the adapter was plugged in, in line with the logs complaining about XHCI “dying”; when I unplugged the adapter, it started working fine again after a delay.

If I can provide more information or do some more testing, please let me know.

Thank you,
Regards,
Mihnea

[sam_nazarko]

@mgc8

I actually did try connecting a USB keyboard in order to investigate, and interestingly it also intermittently stopped working when the adapter was plugged in, in line with the logs complaining about XHCI “dying”; when I unplugged the adapter, it started working fine again after a delay.

Was this on the Vero 4K as well?
We use the dwc_otg module; which is a bit of a mystery (there’s a lot of history behind this).

Sam

[mgc8]

Hello @sam_nazarko ,

All of this conversation pertains to the Vero 4K, I am not using or testing on any other devices. From what you’re saying, does it mean we might be able to test using another USB support module to see if it alleviates the issues? Happy to try various tests if it helps.

Thank you,
Regards,
Mihnea

[dillthedog]

Your sustem journal shows essentially the same kind of information as I see on my Vero4K. Here’s what I get when I grep for xhci:

osmc@osmc:~$ sudo journalctl|grep xhci
Feb 14 13:54:48 osmc kernel: xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
Feb 14 13:54:48 osmc kernel: xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
Feb 14 13:54:48 osmc kernel: xhci-hcd xhci-hcd.0.auto: irq 62, io mem 0xc9000000
Feb 14 13:54:48 osmc kernel: usb usb1: Manufacturer: Linux 3.14.29-56-osmc xhci-hcd
Feb 14 13:54:48 osmc kernel: usb usb1: SerialNumber: xhci-hcd.0.auto
Feb 14 13:54:48 osmc kernel: xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
Feb 14 13:54:48 osmc kernel: xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
Feb 14 13:54:48 osmc kernel: usb usb2: Manufacturer: Linux 3.14.29-56-osmc xhci-hcd
Feb 14 13:54:48 osmc kernel: usb usb2: SerialNumber: xhci-hcd.0.auto
Feb 14 13:54:48 osmc kernel: usb 1-2: new high-speed USB device number 2 using xhci-hcd
Feb 14 13:54:53 osmc kernel: usb 1-1: new high-speed USB device number 3 using xhci-hcd

Interestingly, there is no xhci-hcd module on the V4K (though there is a dwc_otg, like on the Pi).

On the Vero4K, running lsusb -t produces:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
    |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M

whereas on a Pi3, I see:

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
        |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M

@sam_nazarko

We use the dwc_otg module;

It seems that the Vero4K is using Driver=xhci-hcd whereas the Pi3 uses Driver=dwc_otg.

Perhaps Sam can explain what’s happening here - and whether the different choice of drivers between the two devices is relevant to your problem.

If you haven’t already done so, please install usbutils and show the output from running lsusb and lsusb -t with the device plugged in.

[sam_nazarko]

We used dwc_otg on the Vero 2 and this had the same problems that Raspberry Pi’s Synopsis USB implementation does.

• High number of IRQs
• ARM expected to service these in near-realtime or dropped packets.
• Lower than desirable performance

This led to some problems. The most commonly exhibited one was repeat presses when using the RF remote. This would occur because the stop frame could be dropped. We resolved this by dropping a singe port to USB1.1 when the dongle was present.

Pi worked on a FIQ implementation and we tested this with meson timers; but still found problems with this approach. It severely impacted hard disk performance and could lead to corruption.

We now use the xchi module; but dwc_otg is still there for host.

I experienced a similar problem earlier last year when backing up to an old USB 2.0 caddy with USB 3.0 enabled on a Dell PowerEdge. Same kernel module. Disabling USB3 in the UEFI did the trick.

I’ll ticket this, see if I can reproduce it with the crappy caddy and fix it.

Sam

[mgc8]

Hello,

Thank you for your help. I did install usbutils, here is the normal output:
$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M

The problem with trying to catch this when the Ethernet dongle is connected is that the bus keeps “dying” and resetting, thus lsusb actually locks up as well while that is happening; otherwise, it shows nothing just like above. If I connect the Surecom dongle, it never comes up in lsusb and the kernel is completely ignoring it.

@sam_nazarko It seems that the xhci-hcd module is compiled into the kernel, is there any way we can disable this on boot? I’d love to try ehci-hcd instead, or any other module, I’ve had countless problems with xhci on various devices in Linux.

Also you mention disabing USB3 in the UEFI – yes please, how can I access that as well?

Thank you,
Regards,
Mihnea

[sam_nazarko]

@mgc8

@sam_nazarko It seems that the xhci-hcd module is compiled into the kernel, is there any way we can disable this on boot? I’d love to try ehci-hcd instead, or any other module, I’ve had countless problems with xhci on various devices in Linux.

Also you mention disabing USB3 in the UEFI – yes please, how can I access that as well?

Vero 4K isn’t a UEFI system.

Strangely @Nickelig seems to have the same adapter and not experience this problem?

[JimKnopf]

Hi @mgc8,

I connected an Anker USB-Ethernet gigabit adapter to my vero 4k and compared journals from your and my machine:

Your journal:

Feb 23 17:51:14 osmc fsck: E2fsck run: /bin/e2fsck -p -C 0 /dev/vero-nand/root
Feb 23 17:51:14 osmc fsck: Filesystem UUID: 0c34753a-742b-4199-8271-403d23145374
Feb 23 17:51:14 osmc fsck: /dev/vero-nand/root: clean, 46159/930240 files, 531811/3716096 blocks
Feb 23 17:51:14 osmc kernel: usb 1-1: new full-speed USB device number 2 using xhci-hcd

My journal:

Feb 28 07:25:43 osmc-vero4k fsck: E2fsck run: /bin/e2fsck -p -C 0 /dev/vero-nand/root
Feb 28 07:25:43 osmc-vero4k fsck: Filesystem UUID: c8272dd9-e1d8-429b-b3d6-1ff0b856ee67
Feb 28 07:25:43 osmc-vero4k fsck: /dev/vero-nand/root: clean, 59825/930240 files, 829450/3716096 blocks
Feb 28 07:25:43 osmc-vero4k kernel: usb 1-1: new high-speed USB device number 2 using xhci-hcd

So, from the negotiation your adapter is only recognized as full speed USB device (12 Mbit/s), that’s totally sick.

The only ideas I have that this device has a defect or the provided power from the Vero is insufficient, a self-powered hub would be great now to verify this.
BTW: You’re using the original power supply for the OSMC Vero 4k, right?

[mgc8]

Hi @JimKnopf,

That’s an interesting catch, and indeed a sign that something is not quite right with the device.

Yes, I am using the original power supply, and am also starting to think there is something wrong with the voltage/power supplied by the Vero4K. Unfortunately, I don’t have a powered USB hub to test with (never needed one so far)… I’ll try to borrow one from someone, but in the meantime, is there anything else that I can check, perhaps with a multimeter?

Thank you,
Regards,
Mihnea

[JimKnopf]

For the pinouts look here: USB - Wikipedia

Best would be to measure the Voltage if the adapter is connected with such tool http://amzn.eu/4e20JNm. With your multimeter you could only measure the idle voltage between the outer pins with the risk of damaging the Vero.

[mgc8]

Hi @JimKnopf,

Thank you for the suggestion, I wasn’t even aware those devices existed; that looks quite handy indeed. I’ve ordered one, as well as a powered USB hub from Amazon, and I’ll avoid any multimeter investigation in the meantime, pending them arriving next week.

Regards,
Mihnea

[mgc8]

Hello @JimKnopf,

Thank you for the assistance so far. I have purchased both a USB multimeter such as the one you recommended (very useful tool that!) as well as a powered USB 3 hub. Unfortunately, the results are disappointing – after some initial success, I’m back at the same failed result with all of my USB Ethernet adapters; I am strating to thing there is a hardware problem with the USB ports on my device.

Here are some details:

1. USB multimeter plugged in Vero4K, nothing else:
   

   

2. USB multimeter plugged in Vero4K, with the Ethernet adapter & cable:
   

   

3. USB multimeter plugged into powered USB 3 hub, plugged into Vero4K, nothing else:
   

   

4. USB multimeter plugged into powered USB 3 hub, plugged into Vero4K, with the Ethernet adapter & cable:
   

   

It’s clear from these measurements that the voltage is lower when directly connected to the Vero4K, but not significantly so. When I first did this and plugged in the Ethernet adapter, I had a moment of happiness, as I could see it being recognised in Linux, and I could even assign it an IP address. Alas, no traffic would flow over the wire. Then I attempted to reboot the Vero4K and try again, it was back to the old nasty behaviour, with the “XHCI died” errors in the logs. The powered hub makes no difference whatsoever, and I can not get a connection on the Ethernet adapter no matter what I try. The OSMC has been updated to latest version in the meantime, no difference.

Interestingly, I have been watching the kernel messages based on your note above – it seems that the USB 3 hub is detected as a “high speed device”, but then when I plugged in the Ethernet adapter, it comes up as “full speed” again… For the brief period when it was recognised, I could run ethtool on it as well and it was fully seen as a 1000Mbit adapter with the correct RTL8153 chipset, etc. But after reboot, it’s all dead again.

What else can I try in order to test this? As I said above, looks to me that USB is broken on this device

Thank you,
Regards,
Mihnea

[sam_nazarko]

Have you tried other peripherals on the Vero 4K, like a USB hard drive?

Can you send the full logs again so I can check?

Sam

[JimKnopf]

Hi, I splitted the issue with the CLS Realtek adapter from the original topic.

@mgc8:

1. please, provide again full logs from the Vero with the failing gigabit Ethernet adapter as requested by Sam means: Enable logging, reboot Vero, since it does not to appear in the network, switch the Ethernet cable to the Vero LAN port and wait some time; upload the logs using MyOSMC or grab-logs -A and provide the URL here
2. install package usbutils if not already done, reboot Vero with ethernet cable in Vero’s LAN port but connected gigabit adapter WITHOUT a LAN cable and provide URLs from:

• sudo lsusb -t | paste-log
• sudo lsusb -v | paste-log

3. if possible, connect the Vero 4k with a second LAN cable to your router OR connect it to your WLAN using the menu MyOSMC->network, so wired and wireless are enabled the same time. Reboot the Vero with gigabit adapter plugged in and Ethernet cable connected to the adapter. Again, provide the URLs from

• sudo lsusb -t | paste-log
• sudo lsusb -v | paste-log

Summary to have a common understanding:

• you bought the same CSL Realtek Gigabit Ethernet adapter the user @Nickelig reported here to be working with the Vero 4k but it don’t with your Vero 4k
• on the Vero 4k it will be discovered as USB full-speed device but not a high-speed one; unclear here is whether behavior is valid for both scenarios either with Ethernet cable connected or without
• the adapter seems to work with other devices
• with an USB safety tester power consumption of the adapter shows to be 320 mA (which is quite high for such adapter) and on the Vero 4k’s USB port you can see voltage below 5 V by that

My brain storming to this besides the data still missing:

• you should contact the user @Nickelig to verify this is really the SAME adapter model he /she’s using with the Vero 4k; all actions here base on his/her statement and reported information that this combination should work
• the LAN cable should be exchanged to eliminate such trivial root cause of problem
• if the MaxPower of lsusb -v output is below 320 mA, something is wrong with this adapter or it is not USB conform since taking a higher current power than reported to the USB host
• in any case we should consider this adapter to have a defect as one possible explanation
• some general USB power issue of the Vero could be possible but this could easily verified connecting a USB device like an SSD or small HDD with guaranteed power current below 500 mA. If this works, this can’t be the root cause

[Nickelig]

All I can say is that I use the adapter every day with 4k movies and I have zero issue whatsoever. It is working steady and stable. Another user also bought it and has it running without problems.

The only thing I can imagine is that it is indeed another adapter. CSL does not produce any hardware to my knowledge but rather relables existing hardware and sells it under the CSL brand. It might be that different adapters are sold under the same name.

[mgc8]

Hello @JimKnopf, @sam_nazarko,

First of all, thank for your continued support on this. I have performed more tests and collected the logs as requested, here are the results (logs scrubbed for personal data):

1. Vero4K rebooted, with the cable connected only to the CSL Ethernet Adapter:
   a) Logs: https://paste.osmc.tv/qokopozuxe
   b) lsusb: https://paste.osmc.tv/ivicikosod

2. Vero4K rebooted, with a second (new) Ethernet cable connected to the CSL Ethernet Adapter and the normal cable into the 100Mbps port:
   a) Logs: https://paste.osmc.tv/ijorigiqal
   b) lsusb: https://paste.osmc.tv/mibusoboxa

Pleas note that there are no significant differences between these two cases – in the second one, the device can mount remote shares and does not complain of a lack of networking like in the first, but otherwise all is the same, especially the USB driver dying repeatedly. Note that this also makes “lsusb” a particularly difficult command to run, as it keeps locking up while the driver resets; the results are also random based on what state of USB reset is taking place – you can see that in the first log output, where not even all the hubs are being enumerated properly.

Given that the lsusb results are impossible to get on the Vero4K, I went ahead and plugged the adapters into a proper laptop running Linux (Kubuntu 16.04) and grabbed the information there:

1. CSL Realtek Adapter: https://paste.osmc.tv/kowixulisi
2. SITECOM AX88179: https://paste.osmc.tv/girumohusu

Please keep in mind that these are the exact same devices I am trying on the Vero4K; both of them work flawlessly on the laptop and are detected immediately – actually, I’m writing this through the SITECOM one right now, so Linux compatibility is not even an issue. They even use different chipsets and are manufactured by different companies, so again that can not be an issue (and the AX88179 is reported to work on these very forums). On my Vero4K, the Realtek one exhibits the behaviour we discuss here, while the Sitecom is not even recognised for a second, it is as if it didn’t exist.

One interesting fact is that the adapters do turn on when plugged into the Vero4K, and there is even traffic on the line (as seen via my managed switch); so they do seem to get enough power for that, yet the USB hub is not seeing them. I also tried other devices into the Vero4K and they do seem to function – a USB keyboard (albeit that’s very low power) and a 256GiB USB stick; both of them had no issues => this would indicate that power levels are good, but something else must be wrong.

Just for fun (pretty sure it has nothing to do with anything) – @Nickelig, I did purchase the exact same article from Amazon, but of course can’t vouch for what’s inside; could you perhaps compare the “lsusb -v” results with yours?

Any further information or directions of investigation will be appreciated.

Thank you,
Regards,
Mihnea

[JimKnopf]

@mgc8: Could you insert the USB stick again and provide logs after reboot and lsusb -v ?