USB-Bus Probleme

Hallo,

//Scheinbar kam meine Mail gestern nicht auf der Liste an, deshalb
//nochmal.

ich kämpfe gerade mit dem USB-Bus.
Effekt: der komplette Bus ist nach einiger Zeit tot, bis auf
angeschlossene Geräte.
FreeBSD 9.0-p5, eigener Kernel (USB-Treiber als Module)

Auslöser:
==========
Ich betreibe einen USB-DVB-S Receiver (PCTV Systems S2) mit dem vdr
1.7, über webcamd. Funktioniert soweit auch. Ich kann den VDR aber
nur max. 1 Tag (bzw. mehrere Stunden) laufen lassen, bis dieser den
Dienst einstellt da er nicht mehr "tunen" (Senderwechsel) kann. Das
passiert immer nach/während einem EPG-Scan laut Logfiles:
--------------
Nov 29 06:09:12 bsd vdr: [50361344] cleaning up schedules data
Nov 29 07:09:13 bsd vdr: [50361344] cleaning up schedules data
Nov 29 08:09:14 bsd vdr: [50361344] cleaning up schedules data
Nov 29 09:09:15 bsd vdr: [50361344] cleaning up schedules data
Nov 29 09:15:58 bsd vdr: [50361344] info: Starting EPG scan
Nov 29 09:15:58 bsd vdr: [50364416] TS buffer on device 1 thread ended (pid=1876, tid=50364416)
Nov 29 09:15:58 bsd vdr: [50363392] buffer stats: 6768 (0%) used
Nov 29 09:15:58 bsd vdr: [50363392] receiver on device 1 thread ended (pid=1876, tid=50363392)
Nov 29 09:16:01 bsd root: Unknown USB device: vendor 0x2013 product 0x024c bus uhub5
Nov 29 09:16:30 bsd vdr: [50366464] frontend 0/0 timed out while tuning to channel 902, tp 110773
Nov 29 09:16:47 bsd root: Unknown USB device: vendor 0x2013 product 0x024c bus uhub5
Nov 29 09:16:47 bsd vdr: [50366464] frontend 0/0 lost lock on channel 1330, tp 110802
Nov 29 09:16:49 bsd vdr: [50366464] frontend 0/0 regained lock on channel 1330, tp 110802
Nov 29 09:16:49 bsd vdr: [50366464] frontend 0/0 lost lock on channel 1330, tp 110802
Nov 29 09:16:51 bsd vdr: [50366464] frontend 0/0 timed out while tuning to channel 1330, tp 110802
Nov 29 09:17:00 bsd vdr: [50366464] frontend 0/0 regained lock on channel 1330, tp 110802
Nov 29 09:17:00 bsd vdr: [50366464] frontend 0/0 lost lock on channel 1330, tp 110802
Nov 29 09:17:02 bsd vdr: [50366464] frontend 0/0 timed out while tuning to channel 1330, tp 110802
Nov 29 09:17:03 bsd vdr: [50366464] frontend 0/0 regained lock on channel 482, tp 110832

(Hier kommen noch div. VDR-Meldugen zu geänderten Kanälen etc., arbeitet noch, bis:)

Nov 29 09:41:46 bsd vdr: [50366464] frontend 0/0 timed out while tuning to channel 184, tp 211656
Nov 29 09:41:59 bsd root: Unknown USB device: vendor 0x2013 product 0x024c bus uhub5
Nov 29 09:42:20 bsd root: Unknown USB device: vendor 0x2013 product 0x024c bus uhub5
Nov 29 09:44:27 bsd last message repeated 6 times
Nov 29 09:44:47 bsd root: Unknown USB device: vendor 0x2013 product 0x024c bus uhub5
Nov 29 09:44:47 bsd vdr: [50367488] changing caids of channel 1254 from 0 to 1811,500,1863,100
Nov 29 09:44:48 bsd vdr: [50367488] changing caids of channel 1255 from 0 to 1811,500,1863,100
Nov 29 09:44:51 bsd vdr: [50367488] changing caids of channel 1261 from 0 to 1811,500,1863,100
Nov 29 09:44:52 bsd vdr: [50367488] changing caids of channel 1262 from 0 to 1811,500,1863,100
Nov 29 09:44:54 bsd vdr: [50367488] changing caids of channel 1267 from 0 to 1811,500,1863,100
Nov 29 09:44:56 bsd vdr: [50367488] changing caids of channel 1269 from 0 to 1811,500,1863,100
Nov 29 09:45:08 bsd root: Unknown USB device: vendor 0x2013 product 0x024c bus uhub5
Nov 29 09:45:50 bsd last message repeated 2 times
Nov 29 09:45:55 bsd vdr: [50367488] changing pids of channel 1064 from 163+163=2:92=fra(at)4,93=eng(at)4:0:41 to 163+163=2:92=fra(at)4,93=eng(at)4:0:0
Nov 29 09:45:55 bsd vdr: [50367488] changing caids of channel 1064 from 1811,100 to 0
Nov 29 09:46:11 bsd root: Unknown USB device: vendor 0x2013 product 0x024c bus uhub5
Nov 29 09:46:53 bsd last message repeated 2 times
Nov 29 09:48:38 bsd last message repeated 5 times
Nov 29 09:51:48 bsd last message repeated 9 times
Nov 29 09:52:17 bsd vdr: [50366464] frontend 0/0 timed out while tuning to channel 0, tp 112663
-------------------
(Diese Unkown USB-Device Meldung kommt immer, daß dürfte der
IR-Receiver an dem DVB-Stick sein)

Und ab hier ist dann endgültig Schluß. Während er oben nach dem
Tuning/Locking-Timeout(regained) noch weiter machen kann ist ab ca.
9:52 nur noch "timed out.. channel 0" zu finden. Es werden aber
weiterhin PIDs von Kanälen geändert, d.h. irgendetwas passiert da
schon noch Nur im Empfänger (vdr-sxfe über xinelibout-Plugin) kommt
nichts mehr ("No Signal").
In der channels.conf sind momentan noch jede Menge Kanäle drin, die
ich garnicht empfangen kann (HD+ z.B). Der vdr ist auch so
eingestellt (default) daß er neue Transpoder automatisch anfügt,
wobei natürlich viel Mist in die Kanalliste kommt. Richtig produktiv
werde ich das wohl so einstellen, daß die bereiigte channels.conf
vom vdr nicht verändert wird. Er also auch nur Kanäle beim z.B.
EPG-Scan vorfindet, die auch wirklich tuneable sind.
Soweit die ewig lange Vorgeschichte...

Auswirkung
============
Nun aber zum eigentlichen Grund der Mail. Wenn der obige Zustand
eingetreten ist, dann ist an meinem PC der USB-Bus nahezu
"gestorben":

a) neu angesteckte Geräte werden nicht mehr registriert (dmesg)
Egal ob Low- oder High-Speed (2. Maus und USB-Daten-Stick z.B.)
Am Datenstick leuchtet noch die LED.

b) Maus und Tastatur funktionieren auch weiterhin, am ebenfalls
angesteckten USB2-Hub brennen die Lichter für die 4 Zusatzports.

c) Wenn ich den DVB-Stick abziehe wird das Abziehen in dmesg noch
registriert (disconnected). Weitere Geräte (auch der DVB-Stick)
werden danach weiterhin nicht registriert, am Datenstick brennt
jetzt aber nichtmal mehr die LED-Leuchte.
Ziehe ich den USB2-Hub ab wird dessen Abziehen ebenfalls noch
registriert(disconnect), aber ein wiederanstecken ebenfalls nicht
mehr. Auch hier sind die Port-LEDs danach tot.

d) Ein usbconfig bleibt ohne Ausgaben in der Shell hängen, läßt sich
auch nicht terminieren(STRG+C). Ein Versuch ohci oder ehci Modul zu
entladen hängt ebenfalls.

e) Versuche, den vdr vor den obigen Aktionen (oder auch danach) zu
beenden schlägt ebenfalls fehl, selbst ein kill -s KILL auf die
vdr-PID fruchtet nichts, der Prozeß bleibt im Status TNs hängen.

Wenn ich in dem Zustand nun die och funktionierende Maus+Tastatur
abziehe, dann funktionieren auch diese nachher nicht mehr.
Der komplette USB-Bus scheint tot zu sein, v.a. scheint er stromlos
zu sein (keine LEDs mehr an Datenstick und USB-Hub). Natürlich sind
haben alle Devices soweit möglich (Hub und DVB-Stick) ihre eigene
Stromversorgung.
Das habe ich mit diesem PC und mit noch keinem anderem System bisher
erlebt. Weder dmesg noch messages bringen während dieser Aktionen
oder diesem Zustand irgendwelche Meldungen die sich als "Fehler"
interpretieren lassen.

Beim VDR und dem DVB-Stick bin ich mir nun auch nicht wirklich
sicher, ob das Verlieren des SAT-Signals oben nun der Auslöser
dieses Zustandes ist oder ggf, doch nur auch eine Auswirkung...

Ich habe noch einen VDR an meinem Server, mit einem USB-DVB-T-Stick
unter Linux. Auch dort "hängt" der Empfang/Tuning manchmal, was sich
aber in 99% der Fälle durch Ab-/Wiederanstecken des Sticks und
neustart des vdr beheben läßt.
Auf diesen Server soll eigentlich FreeBSD mit eben jenem DVB-S
Stick, aber ehrlicherweise traue ich mich momentan nicht. Dieser
Server hat den gleichen USB-Chipsatz wie meine Desktop hier, und ich
möchte wg. eines toten USB-Busses nicht jeden Tag den Server booten
müssen.

Hardware:
ASUS Hauptplatie M3A78
letzets/aktuelles BIOS
USB-Chipsatz:
    vendor = 'ATI Technologies Inc'
    device = 'SB7x0/SB8x0/SB9x0 USB OHCI0 Controller'

Gut, es ist auch noch Firmware im Spiel, aber wie kann ein (ggf.
amoklaufendes) USB-Device den kompletten Bus töten, bzw. "stromlos"
setzen? Das riecht doch nach einem (Kernel) Bug, oder? Evtl. nur mit
den ATI/AMD-Chipsätzen?
Ich würde auch einen Bugreport schreiben, aber evtl. hat hier noch
jemand Ideen was so einen Report aussagekräftiger machen kann bzw.
Tips was ich vorher noch ausprobieren kann.
Ach so: Ohne den Zustand daß Sender nicht mehr getunt werden können
(oben) kann ich problemlos den VDR stoppen, den Stick ab-/anstecken
und webcamd und vdr wieder starten. Es passiert scheinbar nur wenn
der Stick (samt dem Bus und dem Rest) in diesem "Amok-Zustand" ist.

Das ist übrigens der gleiche PC, mit dem ich in früheren Mails nach
Suspend/Resume auch Probleme mit den (USB)-Eingabegeräte habe. Hier
muß ich ohci explizit entladen, 10s warten und das ohci-Modul wieder
laden (alles per ssh!) um nach dem Resume wieder Maus+Tatstur zu
haben. Evtl. hat daß die gleiche Ursache...

Eigentlich würde gerne "Nägel mit Köpfen" machen und diesen
Desktop-PC und auch den Heimserver auf BSD umstellen, aber diese
leidigen "Kleinigkeiten" (USB, Eingabegeräte und Suspend) halten
mich momentan eher davon ab.

Hat jemand Ideen, Ansatzpunkte? Ich liefere auch gerne Configs und
Logfiles etc. ;-)

Gruß
        Gerhard

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 30 Nov 2012 - 13:47:18 CET