Das System hat ein Problem mit dem USB XHCI Treiber vielleicht auch nur mit dem USB 3.0 Hub.
Teste den Tuner erst mal direkt am Rechner - ohne Hub, am Besten direkt an einen USB 2.0 Port um an dieser Maschine alle möglichen Probleme zu vermeiden (sofern vorhanden). Wir hatten schon Kunden wo USB 3.0 Hubs Probleme bereitet haben.
USB 3.0 Ports sind heutzutage üblicherweise eigentlich kein Grund mehr für Probleme, vereinzelt mag es aber dennoch Systeme geben die etwas mehr Aufmerksamkeit benötigen.
Es ist kein Bug von uns und auch kein Bug vom Tuner.
Der USB Core/USB-Controller Treiber scheint bei hardened_usercopy=y nicht für den Userspace bestimmte Daten durchreichen zu wollen. Das ist dann ein Kernel Bug der jeweiligen Version - Als Abhilfe eventuell eine andere Kernelversion verwenden.
Der Crash von unserem Treiber ist dann ein Folgefehler, der Treiber bedient sich einer generischen USB Schnittstelle vom Kernel, wir machen überhaupt nichts im Kernel. Sobald ein Fehler im Kernel auftritt wird der Treiber auch mehr oder weniger gekillt.
Grundsätzlich wenn die USB Unterstützung des Systems in Ordnung ist darf in dmesg keine Fehlermeldung bezüglich USB stehen!
Auf unserem Testsystem läuft:
"Linux sundtek-All-Series 5.4.0-135-generic #152~18.04.2-Ubuntu SMP Tue Nov 29 08:23:49 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux"
lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
# lspci
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H81 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
ehci = USB 2.0
xhci = USB 3.0
Was zeigt lsusb -t an?
Ein paar Minuten vorher in dmesg (evtl. nicht relevant):
diese Info ist relevant und ein Indikator dass etwas nicht passt mit dem USB 3.0 Port.
- VM unter Proxmox V7 mit durchgereichtem Endgerät (nicht Port)
Der Tuner an sich wurde durchgereicht? Viele VMs greifen über usbdevicefs auf USB Geräte zu, das Problem ist dass man in einer VM dadurch ordentlich Overhead erzeugt. Der Tuner kann über 200 mbit, da macht man dann daraus 400mbit. Besser wäre es z.B den Controller an sich durchzureichen. Einen Port alleine kann man auch nicht ohne massiven Overhead durchreichen.
Ich verstehe dass es frustrierend sein kann wenn solche Probleme auftreten, das Problem liegt in dem Fall leider eine Stufe über dem Tuner.