raspberry pi 5 usb 2.5g NIC and OMV 7 - USB NIC is not persistent

Barney · Apr 18th 2024

Quote from Soma

If you can revert to PRIOR those updates, maybe it's possible to check a diff somewhere/somehow, specially the first one

I thought about doing this but unsure how to go about it, especially since I have installed additional updates since Mar 11th. I continued to update in case one of them fixed the issue.. Is there some sort of tool or plugin that enabled one to pick and choose which items to revert? I guess that wouldn't be possible without having some sort of imaging built into OMV that stores prior releases.

I will volunteer to break one of my NAS to get this sorted out. It's considered a test bed anyway.

Soma · Apr 18th 2024

Quote from Barney

Is there some sort of tool or plugin that enabled one to pick and choose which items to revert?

I was thinking more if you had a OS backup before that date.

Force install prior versions might not be the best way to test it.

Ghazzawi · Apr 18th 2024

Quote from chente

That scheduled task should reboot the USB NIC a minute after starting the server, that should avoid the manual disconnect and reconnect dance.

ok after testing i could not get the PI 5 to unbind the device because it could not see it ,, although i am connected to the ssh through that USB NIC and it shows in the command below ...

long story short i targeted the whole port 4 ( in my case usb4) and it worked , now in the GUI scheduler i have the command below .. and i managed to reboot multiple times with no problem ( decreased the sleep time to 10 seconds )

Code

sleep 10;  echo 'usb4' | tee /sys/bus/usb/drivers/usb/unbind; echo 'usb4' | tee /sys/bus/usb/drivers/usb/bind

Code

root@OMV7:~# lsusb
Bus 004 Device 004: ID 0b05:1976 ASUSTek Computer, Inc. USB 10/100/1G/2.5G LAN
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@OMV7:~#
root@OMV7:~#
root@OMV7:~# lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
root@OMV7:~#
root@OMV7:~#
root@OMV7:~# ethtool eth0
Settings for eth0:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
                                2500baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
                                             2500baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 2500Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: yes
root@OMV7:~#

Display More

Soma · Apr 18th 2024

Quote from Ghazzawi

long story short i targeted the whole port 4 ( in my case usb4) and it worked , now in the GUI scheduler i have the command below .. and i managed to reboot multiple times with no problem ( decreased the sleep time to 10 seconds )

OK it seems, we have a winner,

Barney · Apr 18th 2024

Can the "winner" be put into a release that does this automatically? Otherwise there will need to be some sort of documented process that people with USB NICs will have to follow.

ryecoaaron · Apr 18th 2024

Quote from Barney

Can the "winner" be put into a release that does this automatically?

Release of what? While it may "work", this is not an optimal fix. It sounds like a driver issue that should be fixed in the RPi kernel. But I need one to try first.

Soma · Apr 18th 2024

Quote from Barney

Can the "winner" be put into a release that does this automatically? Otherwise there will need to be some sort of documented process that people with USB NICs will have to follow.

If this was a general case, I would agree.

But this was only mentioned by you both and with a Pi 5 which not many people are using.

This is a "winner" for the current situation.

If you can deal with it, there's no harm in having that job running. OMV won't delete it in any update.

IMHO, using a USB NIC (even if 2.5G) on a Pi is a waiste of a USB port.

The internal 1G NIC will always be able to be saturated. Don't know if the 2.5G will

Barney · Apr 18th 2024

Quote from ryecoaaron

Release of what? While it may "work", this is not an optimal fix. It sounds like a driver issue that should be fixed in the RPi kernel. But I need one to try first.

How would a driver lead to the need for a delayed NIC initialization? The driver itself wasn't updated when something broke the NIC boot.

chente · Apr 18th 2024

Quote from Ghazzawi

long story short i targeted the whole port 4 ( in my case usb4) and it worked , now in the GUI scheduler i have the command below .. and i managed to reboot multiple times with no problem ( decreased the sleep time to 10 seconds )

Well, at least it seems that there is already a provisional solution until the definitive one arrives. I celebrate it.

Barney · Apr 18th 2024

Quote from Soma

If this was a general case, I would agree.
But this was only mentioned by you both and with a Pi 5 which not many people are using.

This is a "winner" for the current situation.
If you can deal with it, there's no harm in having that job running. OMV won't delete it in any update.

IMHO, using a USB NIC (even if 2.5G) on a Pi is a waiste of a USB port.
The internal 1G NIC will always be able to be saturated. Don't know if the 2.5G will

I am running RPI4. Not that it really matters.

"Waste" is in the eyes of the beholder. I am not using the second USB3 port for anything else and I am getting the full 2.5 Ghz BW when transferring files (280 MB/s) so the USB is clearly not handicapping it.

Barney · Apr 18th 2024

Quote from chente

Well, at least it seems that there is already a provisional solution until the definitive one arrives. I celebrate it.

Yes, thanks to the both of you for the workaround! Didn't mean to get ahead of this and it's best to still figure out what changed.

Soma · Apr 18th 2024

OP said Pi5 on the topic.

The bypass was found.

Just use it,

Ghazzawi · Apr 18th 2024

Quote from ryecoaaron

I just ordered the Asus version. I will get it tomorrow and can try to figure out how to fix this.

I would still be interested to see your view once your ASUS NC arrives tomorrow ")

ryecoaaron · Apr 18th 2024

Quote from Barney

How would a driver lead to the need for a delayed NIC initialization? The driver itself wasn't updated when something broke the NIC boot.

It doesn't have to be the usb nic driver necessarily. It could be firmware causing another driver to have a conflict with the usb nic driver. It was just a guess. My main point was that the fix is not a fix. It is workaround and not something that I would implement in OMV.

chente · Apr 18th 2024

A simple comment related to the topic for anyone reading this thread. If you can choose, always prioritize a PCIe NIC over a USB NIC. This doesn't work for a Raspberry PI4, of course, but it does for a PI5.

I've been reading on the OpenWRT forum for a few days now (for an idea that's been on my mind) and everything they say there about USB NICs is that they are little more than garbage.

ryecoaaron · Apr 18th 2024

Quote from chente

everything they say there about USB NICs is that they are little more than garbage.

I agree 100%. I avoid them whenever possible.

Barney · Apr 18th 2024

Quote from chente

I've been reading on the OpenWRT forum for a few days now (for an idea that's been on my mind) and everything they say there about USB NICs is that they are little more than garbage.

Well up until Bookworm/OMV7, I can agree mostly with this. The 2.5G just didn't work right but 1G did just fine. Once I did get them working with the Bookworm/OMV7, I ran a file compare on 10 Terabytes between the two NAS running the USB NICs to check robustness and they passed. I figured if they didn't have any errors over the 3-4 days it took to compare the 10T, they are fine. Now this is with RPI4 so I can't speak for any other host equipment. BTW, they are both ASUS USB-C2500 and I cannot speak for any other NIC.

Soma · Apr 18th 2024

Barney

Did you try the "bypass" (better not call it a solution) from Ghazzawi and does it work?
Wonder if it work's the same on the Pi4 since that's what you're running

Barney · Apr 18th 2024

Quote from Soma

Barney
Did you try the "bypass" (better not call it a solution) from Ghazzawi and does it work?
Wonder if it work's the same on the Pi4 since that's what you're running

Not yet. I'm still at my day job, will try it this evening.

OBTW, this will be my first exposure to Task Scheduler. I'm sure it's intuitive just like the rest of OMV, but there is a chance I'll be spinning my wheels on something dumb (of my making.)

Barney · Apr 19th 2024

I am please to report that Chente's suggestion to unbind/bind the NIC worked on one my RPI4s (haven't tried the second yet)! I feel better knowing there is now a second person who experienced the exact issue. I am noticing it's taking 4-5 minutes to get to the UI. Ordinarily it takes 1-2 minutes. I have the SLEEP set to 10 seconds. But at least I don't need to get off the recliner so much.

raspberry pi 5 usb 2.5g NIC and OMV 7 - USB NIC is not persistent

Participate now!

Tags