Posts by e9hack

    Habe Cine S2 V6.5 neu
    dmesg | grep ddb zeigt auf:
    - ASUS ngene-octopus-test: 4....7 ddbridge: Add ID of Digital Devices Octopus V3. Also voll OK.
    - Gigabyte gar nichts, d.h. Treiber werden nicht geladen.


    Vielleicht solltest Du den vollständigen Log vom Treiberstart als .gz anhängen, als nur die kümmerliche Zeile zu posten. Wenn im Log nichts auftaucht, kann auch udev eine Macke haben. Dann mal den Triber händisch starten:


    Die erste Zeile solle beim händischen Starten immer erscheinen, selbst wenn keine Karte verbaut ist.


    Gruß
    e9hack

    Muß man noch irgendwelche Compiler-Schalter zusätzlich setzen? softhddevice mit ffmpeg 1.2 und '--enable-vdpau' kackt bei HD immer ab:


    Gruß
    e9hack

    Vor einem Jahr habe ich von meinem Provider eine 7390 bekommen, zu der Zeit war das kein Auslaufmodell.


    An KabelBW-Kunden werden nur kastrierte 6330 geliefert und Congstar-Kunden bekommen Auslaufmodelle. Ca. 200€ (vor 3 Monaten ca. 270€) für eine aktuelle 7390 ist irgendwie teuer. Kannst Du Deine 7390 freezen, um z.B. DHCPv6 fahren zu können?


    Mein aktueller Provider ist die Telekom, da alle anderen nur 1,5MBit schalten können. Da kann ich nur einen SpeedPort für 5 bzw. 6€/Monat mieten oder eine überteuerte Fritzbox kaufen.


    Gruß
    e9hack

    Da vom Kernel getrennte Treiber immer als Modul kompiliert werden müssen, war HOTPLUG schon immer Voraussetzung. Insofern verliert man nichts. Habe das __dev*-Gedöns aus ddbridge und ngene entfernt.


    Wenn ddbridge HOTPLUG fähig sein soll, muß man das noch in ddb_device_create() und ddb_device_destroy() berücksichtigen. Aktuell wird der Treiber crashen, wenn man mehr als 32 ddbridge Karten verwendet oder wenn man die einzige Karte zum 32mal gezogen und wieder reingesteckt hat :D

    Für Kernel 3.8 sollte man DEFINE_PCI_DEVICE_TABLE aus compat.h entfernen, da sich die Definition geändert hat. Eigentlich ist es in compat.h komplett überflüssig, da es die Definition schon relativ lange gibt.


    Gruß
    e9hack

    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?


    Deine Erklärung scheint ja plausibel zu sein. 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. 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.


    Gruß
    e9hack

    Unfug!


    Hast natürlich recht. Wenn, dann so:


    Und da Du ja gerade am Ändern bist, kannst Du auch gleich alle Warnings mit abstellen:

    Code
    1. /usr/src/media_build_experimental/v4l/saa716x_rom.c: In function 'saa716x_eeprom_header':
    2. /usr/src/media_build_experimental/v4l/saa716x_rom.c:115: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
    3. /usr/src/media_build_experimental/v4l/saa716x_rom.c:115: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
    4. ...


    Gruß
    e9hack


    Du kannst einfach folgende Zeilen in "include/linux/init.h" vor der Zeile /* Used for HOTPLUG_CPU */ rein kopieren. Dann müssten alle Treiber in media-experimental wieder bauen:

    Code
    1. #define __devinit
    2. #define __devinitdata
    3. #define __devinitconst
    4. #define __devexit
    5. #define __devexitdata
    6. #define __devexitconst


    Patch mach ich dir keinen, weil der ev. in zukünftigen Versionen nicht mehr applied, weil media-experimental wird sicher noch eine Weile so bleiben, wie es ist, denke ich.
    Alternativ kannst du die Defines nur in den betroffenen Files am Beginn rein geben (nach der include Orgie), was aber mühsamer sein wird, weil sicher auch andere Files von media-experimantal betroffen sind.


    Eigentlich gehören die Module gerichtet. Wenn man es neu definiert, dann bitte so:

    Code
    1. #define __devinit __init
    2. ....


    Es gehört dann in compat.h rein.


    Gruß
    e9hack

    Ich vermute du hast das alte Makefile verwendet:



    Ich benutze ein altes Makefile (von vor 1.7.35). Ich habe kein 'CONFIG += -DUSE_SCREENSAVER' im Makefile. Muß das jetzt rein?


    Gruß
    e9hack

    Ich habe seit dem 9.2.13 (d31ff55) Probleme mit softhddevice. Nach ca. 20 Minuten gibt es kein Bild und keinen Ton mehr. Der Bildschirm wird schwarz. GrabImage liefert jedoch weitherhin Bilder. Im Log gibt es keine Anhaltspunkte. Die letzte funktionierende Version ist vom 26.1.13 (8b22585). Dazwischen habe ich keine Versionen gezogen. Ffmpeg ist 1.0:


    Nvidia-Treiber ist 318.18. Mit der Version von heute ist softhddevice wieder schwarz geworden. Laufzeit war genau 20 Minuten. Das Log sagt nichts. Es ist 16:41 passiert:


    Gruß
    e9hack

    Es gibt zwei Verzögerungen. Hier wird die Firmware geladen:

    Code
    1. 9 15:08:11 vdr kernel: [ 8178.596071] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
    2. 9 15:08:12 vdr kernel: [ 8179.005931] DRXK driver version 0.9.4300


    Hier wird der Tuner-Chip initialisiert:

    Code
    1. 9 15:08:12 vdr kernel: [ 8179.012464] drxk: frontend initialized.
    2. 9 15:08:12 vdr kernel: [ 8179.012472] (/usr/src/media_build_experimental/v4l/ddbridge-core.c:1250) dvb_input_attach
    3. -> call to tuner_attach_tda18271()
    4. 9 15:08:13 vdr kernel: [ 8180.423416] (/usr/src/media_build_experimental/v4l/ddbridge-core.c:1253) dvb_input_attach
    5. 9 15:08:13 vdr kernel: [ 8180.423435] DDBridge 0000:02:00.0: DVB: registering adapter 1 frontend 0 (DRXK DVB-C DVB-T).


    Gruß
    e9hack

    Hi,


    ich habe vor ein paar Tagen meiner alten Suse 11.2 Installation eine 3TB WD Platte untergeschoben. Das Bios sagt zwar, daß da nur 700GB wären. Der Kernel ist ein selber compilierter 3.7.4, da es für Suse 11.2 keine Updates mehr gibt. Util-linux scheint aktuell genug zu sein. Suse 11.2 bringt aber keine Tools mit, die eine GUID-Partitionstabelle erstellen oder bearbeiten können. Ich habe gptfdisk 0.8.6 compiliert. Hardware ist ein älters AMD board, was nur SATA mit 1,5MBit kann.


    Gruß
    e9hack


    Iss schon "relativ" alt und da produktiv genutzt, werde ich auch so schnell nix dran ändern.


    Der nvidia Installer jubelt einem immer neue ffmpeg Libraries unter. ffmpeg -version zeigt leider nur die zum kompilieren von ffmpeg verwendeten Libraries an. Was tatsächlich installiert ist, erfährt man nicht. Wenn man aus irgendwelchen Gründen ältere Libraries benötigt, muß man die Library-Links zurückverbiegen.


    Gruß
    e9hack