1
Treiber / mediasrv 100% CPU: poll-Busy-Loop mit POLLNVAL (net_poll) nach USB-Device-Verlus
« am: Heute um 10:02:43 Vormittag »
Hallo,
ich betreibe einen Dual S2 (Serial: U220618155849, Bus 3-2.3.4.1) an einem
Linux-Host (Kernel 7.0, Docker, linuxserver/tvheadend, Treiber-Build
2026-06-25 04:01:17, gestartet mit
mediasrv -d --wait-for-devices --config=... --pluginpath=...).
Symptom:
Ein mediasrv-Thread läuft dauerhaft auf 100% (1 Kern, Container in
docker stats bei ~101%). Der Zustand ist reproduzierbar und kehrt nach
Neustart nach einiger Zeit zurück.
Analyse mit strace (heißer Thread):
strace -c -p <TID> (8 s):
788584 x poll, 370 x open (Fehler), je 74 x recvfrom/stat (Fehler)
poll([{fd=1630364978, events=...}, {fd=24, ...}, {fd=23, ...}], 3, -1)
= 1 ([{fd=1630364978, revents=POLLNVAL}])
~98.000 poll-Calls/s. Der erste FD (1630364978) ist ungültig (echte FDs
gehen nur bis ~29), poll mit Timeout -1 kehrt dadurch sofort mit POLLNVAL
zurück — klassischer Busy-Loop ohne Backoff.
Begleitbefunde:
- /var/log/mediasrv.log: 1123x "TS Sync byte not aligned, realigning
stream", 91x "There have been 10 ts errors within 1 second", jeweils
nach "Frontend has locked" -> "Starting transfer".
- /proc/<pid>/fd: ein Handle zeigt auf /dev/sundtek/usb/003/015 (deleted),
in dmesg USB-Disconnects auf Bus 3/4 sowie
"usbfs: process mediasrv did not claim interface 0 before use" für
3-2.3.4.1.
- Tvheadend-Epggrabber tuned beide Tuner laufend durch (alle paar Sekunden
neuer Mux).
Analyse mit Ghidra (headless):
- Hauptbinary (642 Funktionen): poll wird als roher syscall(7) (= SYS_poll)
aufgerufen. Heißer Kandidat: net_poll @ 0042fd20 — prüft nach poll nur
Bits wie POLLIN/POLLHUP, ein POLLNVAL-Handling habe ich im Decompilat
nicht gefunden; nonzero revents wird als "bereit" gewertet, der Aufrufer
pollt sofort erneut.
- libdrv_em28xx.so (2409 Funktionen): nur 3 Poll-Stellen (Audio-/DTV-
Client-Helper mit Timeout 0, accelerated-USB-Loop mit Timeout 10 ms) —
keine passt zum beobachteten poll(3 FDs, -1).
Bitte:
Könnt ihr prüfen, ob net_poll defekte FDs (CLOSE/use-after-close nach
USB-Reconnect) aus dem Poll-Set entfernen und POLLNVAL/POLLERR mit Backoff
behandeln kann? Aktuell hilft nur ein Neustart von mediasrv (habe ich per
Healthcheck automatisiert). Falls ihr weitere Logs/Befunde braucht (usbmon,
mediaclient --tsscan, Core-Dumps — es liegen auch ältere core.* im
Treiberverzeichnis), liefere ich sie gerne nach.
Danke und viele Grüße!
ich betreibe einen Dual S2 (Serial: U220618155849, Bus 3-2.3.4.1) an einem
Linux-Host (Kernel 7.0, Docker, linuxserver/tvheadend, Treiber-Build
2026-06-25 04:01:17, gestartet mit
mediasrv -d --wait-for-devices --config=... --pluginpath=...).
Symptom:
Ein mediasrv-Thread läuft dauerhaft auf 100% (1 Kern, Container in
docker stats bei ~101%). Der Zustand ist reproduzierbar und kehrt nach
Neustart nach einiger Zeit zurück.
Analyse mit strace (heißer Thread):
strace -c -p <TID> (8 s):
788584 x poll, 370 x open (Fehler), je 74 x recvfrom/stat (Fehler)
poll([{fd=1630364978, events=...}, {fd=24, ...}, {fd=23, ...}], 3, -1)
= 1 ([{fd=1630364978, revents=POLLNVAL}])
~98.000 poll-Calls/s. Der erste FD (1630364978) ist ungültig (echte FDs
gehen nur bis ~29), poll mit Timeout -1 kehrt dadurch sofort mit POLLNVAL
zurück — klassischer Busy-Loop ohne Backoff.
Begleitbefunde:
- /var/log/mediasrv.log: 1123x "TS Sync byte not aligned, realigning
stream", 91x "There have been 10 ts errors within 1 second", jeweils
nach "Frontend has locked" -> "Starting transfer".
- /proc/<pid>/fd: ein Handle zeigt auf /dev/sundtek/usb/003/015 (deleted),
in dmesg USB-Disconnects auf Bus 3/4 sowie
"usbfs: process mediasrv did not claim interface 0 before use" für
3-2.3.4.1.
- Tvheadend-Epggrabber tuned beide Tuner laufend durch (alle paar Sekunden
neuer Mux).
Analyse mit Ghidra (headless):
- Hauptbinary (642 Funktionen): poll wird als roher syscall(7) (= SYS_poll)
aufgerufen. Heißer Kandidat: net_poll @ 0042fd20 — prüft nach poll nur
Bits wie POLLIN/POLLHUP, ein POLLNVAL-Handling habe ich im Decompilat
nicht gefunden; nonzero revents wird als "bereit" gewertet, der Aufrufer
pollt sofort erneut.
- libdrv_em28xx.so (2409 Funktionen): nur 3 Poll-Stellen (Audio-/DTV-
Client-Helper mit Timeout 0, accelerated-USB-Loop mit Timeout 10 ms) —
keine passt zum beobachteten poll(3 FDs, -1).
Bitte:
Könnt ihr prüfen, ob net_poll defekte FDs (CLOSE/use-after-close nach
USB-Reconnect) aus dem Poll-Set entfernen und POLLNVAL/POLLERR mit Backoff
behandeln kann? Aktuell hilft nur ein Neustart von mediasrv (habe ich per
Healthcheck automatisiert). Falls ihr weitere Logs/Befunde braucht (usbmon,
mediaclient --tsscan, Core-Dumps — es liegen auch ältere core.* im
Treiberverzeichnis), liefere ich sie gerne nach.
Danke und viele Grüße!