Autor Thema: mediasrv 100% CPU: poll-Busy-Loop mit POLLNVAL (net_poll) nach USB-Device-Verlus  (Gelesen 8 mal)

DocMAX

  • Newbie
  • *
  • Beiträge: 1
    • Profil anzeigen
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!