Beiträge von S:oren

    Leider wurde der UAS- (USB-attached SCSI) Treiber aus dem Linux-Kernel wieder entfernt. Hatte wohl nie richtig funktioniert. Das UAS-Protokoll braucht man aber, um ueber USB3.0 beim Plattenzugriff auf Speed zu kommen, der normale usb-storage-Treiber bringt ueber USB3.0 nicht viel mehr als ueber USB2.0.


    Ausserdem scheinst Du wieder beide Platten ueber einen Hub am selben XHCI-Controller zu betreiben. Das ist (mit usb-storage) eigentlich immer langsamer, als beide Platten an verschiedene XHCI/EHCI-Controller zu haengen.


    Hast Du die Platten neu partitioniert, oder das originale WD-Partitionslayout behalten? Sind ja sicher Platten mit 4k-Sektoren, aber bei WD gibt es manchmal Jumper oder spezielle Plattenfirmware, die die (emulierten 512Byte-) Sektornummern verschieben. Misalignte Partitionen wuerden die extreme Langsamkeit erklaeren.


    Gruss,
    S:oren

    Da bin ich dann schon am Überlegen, ob ich - bevor ich da noch viel Mühen reinstecke - nicht lieber gleich ne Schüssel an die Wand schraube.

    Wie waere es denn erstmal mit einer vernuenftigen Masseverbindung vom Antennenschirm zum Rechner und einem kurzen USB-Kabel? Wenn Du direkt neben dem Sender wohnst, kannst Du doch vermutlich mit einer Glimmlampe am Antennenkabel Licht machen...


    Ansonsten kann es natuerlich immer auch ein Hardwaredefekt am Strick sein. Die dib0700-Treiber sind (bis auf das Diversity-Problem, Patch oben) recht ausgereift und stabil.


    Gruss,
    S:oren

    Allerdings: Das Dings und der Server stehen im Keller, die Zimmerantenne am Dachboden. Da sind also drei Stockwerke dazwischen, mit einer entsprechend langen Antennenleitung. Dämpft die nicht eh schon heftig genug?!

    Wahrscheinlich schon. Allerdings faengt die Leitung vermutlich auch ziemlich viel Dreck ein. Habe auch eine Antenne auf dem Dachboden, seit ich eine Antennenbuchse gut leitend ins Rechnergehaeuse eingebaut und den Stick ins Gehaeuse gelegt habe, gibts keine Probleme mehr. Vorher auch immer mal seltsame Effekte...


    Gruss,
    S:oren

    Wenn es periodisch auf beiden Tunern zu Empfangsstörungen kommt, die eine 7-stellige BER auslösen (sowas hab ich noch nicht gesehen!) dann ist da was faul.

    Diese Stoerungen gibts bei diesem Stick immer, wenn auf dem einen Tuner eine Aufnahme oder LiveTV laeuft und auf dem anderen Tuner (z.B. fuer EPG-Scan) umgeschaltet wird. Dagegen hilft ein Treiber-Patch (siehe hier).


    Ansonsten hat dieser Stick gelegentlich Probleme mit zu viel Hitzeentwicklung (2 Platinen uebereinander), es hilft dann, den Stick mit der langen schmalen Seite nach unten/oben auszurichten, so dass die Lueftungsloecher uebereinander (und nicht nebeneinander oder gar auf der Unterseite) sind.


    Als dritten Tipp haette ich, die mitgelieferten Stummelantennen zu benutzen (moeglichst auf einer Metallunterlage, z.B. Heizung/Fensterbrett anbringen), gerade wenn der Sender in Sichtweite ist. Der Stick hat Probleme mit zu starkem Signal und mit Masseschleifen zwischen Antenne und USB.


    Als Treibermodule fuer diesen Nova-TD-Stick (altes Design mit einer Antennenbuchse hinten und einer an der Seite) werden mt2266 (Tuner), dib7000p+dibx000_common (Demodulator) und dvb_usb_dib0700 (USB-Bridge) gebraucht (+DVB-Core-Module), der Rest (dib*) schadet aber nicht.


    Gruss,
    S:oren

    Nein, überhaupt nicht, offen gestanden ist Dein Thread mit der S2-6400 in ARM Basis, der einzige der aktuell in die Kategorie passt. Alle anderen ARM Threads sind doch eher Server Anwendungen, oder?

    Das spricht dann doch aber gegen ein (ARM-)Server-Forum. Sonst findet sich doch niemend mehr zurecht!?
    Ich persoenlich kann auch nicht erkennen, warum man in den Foren unbedingt zwischen vdr-Server, vdr-Client und Standalone-vdr unterscheiden sollte. Ich habe mich aber - ehrlich gesagt - mit dieser Frage nicht ausfuehrlich beschaeftigt.


    Hmm, Rasperry im Prinzip auch, wo ziehst Du also die Grenze?

    Ein fuer stationaeren Einsatz vorgesehenes Platinchen ohne Netzteil und ohne Gehaeuse wuerde ich nicht als "Fertiges Geraet" bezeichnen. Den Raspi eher als Mainboard, aehnlich wie nanoITX-Platinen.


    Wahlfreiheit wird es nur mit x86/x64 HW geben

    Gerade fuer Linux ist doch die Prozessorarchitektur ziemlich egal. Vielleicht gibt es ja mal ein normales miniITX-Board mit einem ARM-Server-Prozessor (z.B. Marvell ArmadaXP)...


    Gruss,
    S:oren

    Deine Umsetzung bleibt der einzige Thread für dieses neue Unterforum?

    Oh, das ist wohl ein Missverstaendnis. Ich will kein neues Unterforum, das ist auch kein Server, nur ein vdr auf arm. Und ja, nur auf arm, nicht einem speziellen ARM-SoC mit Video. Da kenne ich auch nichts, was (bis jetzt) vernuenftig laeuft.
    Wuerde ein AppleTV nicht eher zu VDR-Hardware/Fertige Geraete gehoeren?


    Gruss,
    S:oren

    Nur aktuell sind zwei PCI-Karten betroffen. Es wird ja wohl keiner bei laufendem PC die ddbridge- oder ffhd-Karte permanent ziehen bzw. wieder reinstecken wollen.

    Fuer den Kernel sind alle PCI-Geraete hotplug-faehig. Der PCI(e)-Standard erlaubt das, es gibt Industriekarten, die tatsaechlich im Betrieb gewechselt werden duerfen. Auch die hier in Frage stehenden Karten koennten z.B. in einem externen Gehaeuse stecken, das ueber eine PCI-Bridge auf einer PCMCIA-Karte hot-pluggable z.B. an einem Laptop angeschlossen ist. (Ich kenne persönlich einen Entwickler solcher Boxen.)


    Die ddbridge-Karte benutzt sowohl __xxxx als auch __devxxxx Attribute. Die __devxxxx Attribute kann man entfallen lassen, die anderen werden nicht angetastet. Irgendwie paßt das nicht zusammen.

    Die __init-Attribute gibt es weiterhin auch in linux-3.8. Module-Init-Code wird z.B. tatsaechlich nur beim Laden des Moduls ausgefuehrt, der im Modul enthaltene probe-Code fuer Geraete aber ggf. jedesmal beim Anschliessen eines Geraetes. Ich habe keine Ahnung, ob in diesem speziellen Treiber die Attribute evt. inkorrekt benutzt werden.


    Gruss,
    S:oren

    Nachdem es sich bei media-experimental aber um ein Patchset für einen älteren Kernel handelt, können wir das nicht so einfach angreifen und die Attribute löschen.

    Ich halte des komplette Löschen der __devinit (and friends) für absolut ungefährlich (und heutzutage ohne jede Nebenwirkung).


    Es scheint mir, dass hier die Bedeutung dieser Attribute nicht so recht klar ist. Deshalb mal der Versuch einer Erklärung:
    Es war einmal eine Zeit, als Linux auf Rechnern lief, bei denen der Hauptspeicher in einzelnen Megabytes gezählt wurde. Da kamen findige Programmierer auf die Idee, Code, der nur einmal beim Start des Kernels zur Initialisierung der Hardware ausgeführt wird, in eine eigene init-Codesection auszulagern, die nach dem Hochfahren des Kernels aus dem Hauptspeicher gelöscht wird. Mit der Zeit wurden die Hauptspeicher größer und es wurden Geräte entwickelt, die man zur Laufzeit des Systems einfach so an- und abstecken konnte (z.B. USB). Dumm war nun, dass der Kernel den Code zur Initialisierung dieser Geräte bereits gelöscht hatte, diese Geräte waren also nicht verwendbar. Um nun diesen Init-Code wahlweise behalten zu können, führte man konfigurierbaren Hotplug-Support im Kernel ein. Code zur Initialisierung von solchen Geräten wurde statt __init mit __devinit (entsprechend für Daten) gekennzeichnet. Ist nun Hotplug nicht konfiguriert, wird _devinit wie __init behandelt, ist Hotplug konfiguriert, wird __devinit wie normaler Code ohne Attribut behandelt (entsprechend fuer Daten). Die Zeit vergeht und mittlerweile haben auch kleine embedded Computer Hauptspeicher von einem halben Gigabyte oder mehr und USB-Controller. Somit baut schon jahrelang niemand mehr Kernel ohne Hotplug-Support.


    Bei linux-3.8 hat man nun etwas aufgeräumt, z.B. Support für den alten i386 entfernt, und auch das konfigurierbare Hotplugging nun per default immer eingeschaltet. __devinit hat nun keine Bedeutung mehr und wurde vollständig entfernt. Bei älteren Kerneln könnte man ein paar Byte Hauptspeicher mit __devinit sparen, aber nur dann, wenn Hotplugging deaktiviert ist. Verwendet irgendjemand hier einen Kernel ohne Hotplug-Support?


    Entschuldigung an UFO für diese off-topic-Diskussion.


    Gruß,
    Sören

    Dem Handbuch meines Boards (Foxconn A7GM-S 2.0) lässt sich leider nicht entnehmen, ob die 4 externen Ports alle am gleichen Controller hängen oder ob es mehrere Controller gibt.

    Ein lsusb sollte Klarheit bringen, wieviele USB-Busse (mit 2.0 root hub) es gibt. Sollten es mehrere sein, kann man dann ja probieren, welcher Port zu welchem Controller gehoert.


    Gruss,
    S:oren