bttv-Modul mit Options beim Systemstart laden

[kreol]

Bis Debian Squeeze konnte ich meine TV-Karte (BT 878 Chipsatz) mit einem Eintrag in der selbsterstellten Datei "tv" in /etc/modprobe.d/ dazu bringen, den Tuner und die Card beim Systemstart mitzugeben.

Bei Wheezy schlägt das fehl. Die Karte ist laut dmesg "unknown". Log reiche ich bei Bedarf gerne nach.

Nach
modprobe -r bttv && modprobe bttv card=54 tuner=5geht alles.

Nachdem eine vom Squeeze übernommene /etc/modprobe.d/tv und auch ein Eintrag in /etc/modules mit passenden Options nichts an dem "unknown" ändern, habe ich als Workaround die Befehle in die /etc/rc.local eingetragen. Das geht, erscheint mir aber unelegant. Hat Wheezy da was anderes in Petto?

Langer Frage kurzer Sinn: Wie gebe ich Wheezy beim Starten des Moduls die Options mit?

Falls euch dazu auch nichts einfällt werde ich wohl den Bugreport bemühen (wg. fehlender Verarbeitung der Options in der /etc/modules, die /etc/modprobe.d/$foobar ist wohl deprecated). Bislang steht darüber nichts drin, ebensowenig wie sonst im Netz :/

Dank und Gruß

Kreol

[HirschHeisseIch]

man modprobe.d meint:

All files underneath the /etc/modprobe.d directory which end with the .conf extension specify those options as required.

Vielleicht ist modprobe in der aktuelleren Version einfach nur zickiger, und möchte eine "tv.conf" statt eine "tv" sehen.
In eine /etc/modprobe.conf könnte man auch noch Optionen eintragen.

Ich gehe jetzt einfach mal davon aus, dass Deine "tv" das richtige Format hat. ;)

[tictactux]

Hallo,

hast du mit "modinfo bttv" geprüft ob die optionen/parameter sich nicht vielleicht geändert haben seit vorheriger Debian Version?

Ansonsten könntest Du in Deiner config-Datei unter /etc/modprobe.d/ versuchen das Modul bttv über install mit den richtigen Optionen zu laden, als Alternative zu rc.local.

Beispiele für diese Methode gibts z.b. in /etc/modprobe.d/alsa-base.conf
(siehe auch : man modprobe.conf (5))

[kreol]

Danke euch beiden.

Peinlich für mich, in beiden Antworten der Hinweis auf manpages... :rolleyes:

Tatsächlich wars die Endung in /etc/modprobe.d/. Mit "tv.conf" gehts.

Der Vollständigkeit halber die (unveränderte) Datei:
alias char-major-81 videodev
options i2c-algo-bit bit_test=1
alias char-major-81-0 bttv
alias char-major-81-1 off
alias char-major-81-2 off
alias char-major-81-3 off
options bttv card=54 tuner=5It's not a bug, it's a feature, auch wenn ich nicht weiss, wo da der Mehrwert liegen soll :D

Zumindest hätte imho aber der Eintrag in /etc/modules funktionieren sollen. Naja, jetzt gehts.

Kreol

[tictactux]

Peinlich, in beiden Antworten der Hinweis auf manpages... :rolleyes:

ojeh, tut mir schrecklich Leid wenn ich angenommen habe daß die Methode "install" nicht unbedingt jedem geläufig ist (mir z.b. auch nur vom Durchlesen xD).

Aber schön daß das Problem nun behoben ist auch wenn manpages so belanglose Dinge sagen wie
All files underneath the /etc/modprobe.d directory which end with the .conf extension specify those options as required. scnr, und HF:)

[HirschHeisseIch]

So Kleinigkeiten kann man schonmal übersehen. ;)

Ich schätze, die Einschränkung ist wegen "Special Files" wie der blacklist.

[kreol]

Hab das einsame "Peinlich" in #4 für etwaig Nachlesende mal klarstellend um "für mich" ergänzt. Shame on me.

Ihr seid die besten :)

Kreol

[Rain_maker]

It's not a bug, it's a feature, auch wenn ich nicht weiss, wo da der Mehrwert liegen soll :D

Naja, da gibt es schon etwas, aber das ".conf" ist nicht das Entscheidende, sondern etwas Anderes.

Wenn man sich mal in "/etc/modprobe.d" auf meinem System umsieht, dann haben alle Dateien eine Zahl zwischen 00 und 99 als prefix. Woher kennt man das auch? Richtig, bei udev-Regeln und da hat es Einfluss auf die Reihenfolge der Anwendung.

Nehmen wir also an $DISTRIBUTOR setzt in einer Datei unter modprobe.d für $MODUL als Standard $PARAMETER mit $WERT=foo, in etwa so


options $MODULE $PARAMETER=foo

... bei meiner Hardware will/muss ich aber aus $GRÜNDEN bei $MODUL den $PARAMTER mit $WERT=bar laden, also so in etwa


options $MODULE $PARAMETER=bar

dann kann ich das jetzt tun, ohne in der vom Distributor installierten Datei herumfummeln zu müssen (und das dümmstenfalls nach jedem Update des entsprechenden Paketes).

Kleines Beispiel, gerade auf die Schnelle getestet:

Nehmen wir an, wir haben die Datei

/etc/modprobe.d/50-r8101.conf

mit


options r8101 eee_enable=1

Das ergibt -wie zu erwarten-


cat /sys/module/r8101/parameters/eee_enable
1das hier.

Erzeuge ich eine Datei

/etc/modprobe.d/60-r8101.conf

mit


options r8101 eee_enable=0dann


modprobe -r r8101 && modprobe r8101 && cat /sys/module/r8101/parameters/eee_enable
0passiert das hier.

I think you get the idea.......

Greetz,

RM

[kreol]

...
I think you get the idea.......Das ist alles wahr, aber ob die massgebliche Datei in /etc/modprobe.d/ jetzt 50-r8101.conf oder nur 50-r801 heisst bringt imho keinen Vorteil. Das ist bloss Kosmetik.

Aber sei's drum. Wenn man es weiss, kann man damit leben.

Kreol

[Rain_maker]

Das ist alles wahr, aber ob die massgebliche Datei in /etc/modprobe.d/ jetzt 50-r8101.conf oder nur 50-r801 heisst bringt imho keinen Vorteil. Das ist bloss Kosmetik.

In dem Fall schon, hatte ich ja auch explizit geschrieben, daß es da nicht um die Dateiendung geht. Diese Änderungen (kein modprobe.conf mehr, Dateien haben Prefix und Suffix) wurden in einem Rutsch eingeführt.

Aber mir ist dann doch ein praktisches Beispiel eingefallen, wo das sinnvoll genutzt wird.


ls /etc/modprobe.d/50-sound*

/etc/modprobe.d/50-sound.conf
/etc/modprobe.d/50-sound.conf.YaST2saveIn a nutshell, ein Konfigurationswerkzeug (muss ja nicht YaST sein, dpkg-reconfigure $DINGENSKIRCHEN könnte das genau so machen) kann die letzte Version der Datei im selben Ordner inhaltlich unverändert aber mit anderem Suffix als Backup speichern.

Gerade bei der Konfiguration der Soundkarte (snd-hda-intel ist da berühmt-berüchtigt), wo es gerne mal von Modulparametern abhängt, ob der Rechenknecht überhaupt Krach macht bzw. ob auch alle ein-/Ausgänge korrekt angesprochen werden oder nicht und man nicht selten ein paar verschiedene Parameter je nach (Laptop-)Modell ausprobieren muss.

Greetz,

RM

[kreol]

Vielen Dank für das Bemühen, mir die Änderung schmackhaft, oder besser: mir das Erfordernis der Änderung einsichtig machen zu wollen.

Aber zwischen 50-sound und 50-sound.conf erkenne ich einfach keinen praktischen Mehrwert. Auch eine 50-sound.YaSTsave oder 50-sound.wasauchimmer kann das ohne ein conf zwischendrin oder am Ende.

Kreol

[Rain_maker]

Tja, dann denke mal scharf nach, was ohne die Anforderung eines expliziten Suffix mit den Backupdateien im selben Verzeichnis passieren würde.

Greetz,

RM

[spychodelics]

Es würden alle gelesen :D