Only "usb: (mac)" is displayed.
The realtek devices (8152 Fast Ethernet and 8153 GigaBit Ethernet) are also missing with lsusb. Others are listed. [root@NanoPi-R1 ~]# lsusb Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub But in tree mode the device is there [root@NanoPi-R1 ~]# lsusb -t /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M This bug is introduced with core158.
I have tracked down to the last libusb update https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=937d8dbcb19fcfbdfc0d914b769c93b5cffdba65
What can we do here? Is there a bug fix for libusb available or do we need to downgrade?
Archlinux has this patch: > https://github.com/libusb/libusb/commit/f6d2cb561402c3b6d3627c0eb89e009b503d9067 Could we try it?
Or this from Fedora: > https://src.fedoraproject.org/rpms/libusb1/tree/rawhide
Resetting this back to ASSIGNED since nothing was merged, yet. Since I already handed in a faulty libusb (or usbutils?) update in the past, I can also have a look at this one if that's fine with everybody.
(In reply to Peter Müller from comment #6) > Since I already handed in a faulty libusb (or usbutils?) update in the past, > I can also have a look at this one if that's fine with everybody. Yes, please.
These patches went into libusb 1.0.24 (https://github.com/libusb/libusb/releases); I will update that package.
https://patchwork.ipfire.org/project/ipfire/patch/4d8432e9-20c2-6516-8228-77fcf5f2e04c@ipfire.org/
https://git.ipfire.org/?p=people/pmueller/ipfire-2.x.git;a=commit;h=64ecba3f57f3ccce170edf8e5a80468d5390d54a I took the liberty... :-) Not bumping to MODIFIED, since this is only my personal temporary branch.
This bug is again present in core164 next tree IPFire v2.27 - www.ipfire.org =============================== ipfire.localdomain running on Linux 5.15.16-ipfire aarch64 ipfire login: root Password: No mail. [root@ipfire ~]# lsusb Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub [root@ipfire ~]# lsusb -t /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M [root@ipfire ~]# Realtek 8152 and 8153 is not displayed by lsusb but found with lsusb -t Other manufacturers like asix or moschip works.
(In reply to Arne.F from comment #11) > This bug is again present in core164 next tree What do you suggest we do here? Ignore this and declare all those Realtek devices as "broken" or do we revert the update again? No matter what way we chose, we should notify upstream about this.
In the RC for libusb 1.0.25, there are three commits that might be of interest for this problem: - https://github.com/libusb/libusb/commit/f6d2cb561402c3b6d3627c0eb89e009b503d9067 - https://github.com/libusb/libusb/commit/c486d01297a366aae8dcd3f715d0bfd8b995949b - https://github.com/libusb/libusb/commit/f38f09da98acc63966b65b72029b1f7f81166bef The latter one is especially interesting, but was reported as a regression in version 1.0.24 - however, we face this problem since version 1.0.23, so it might be unrelated. Not being a USB expert: Is there any sense in shipping these patches in advance?
I think there is no harm in trying the RC.
See also: https://patchwork.ipfire.org/project/ipfire/patch/20220209212916.2754129-1-adolf.belka@ipfire.org/
I can confirm that 1.0.25 fix the issue.
Yay. Finally.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=20e71c0eb029bf5e549dcd9970a64d0a53bf62bf
https://blog.ipfire.org/post/ipfire-2-27-core-update-164-is-available-for-testing
https://blog.ipfire.org/post/ipfire-2-27-core-update-164-released
*** Bug 11810 has been marked as a duplicate of this bug. ***