PCI-Express

Software besorgen und anwenden
Antworten
Nachricht
Autor
brum

PCI-Express

#1 Beitrag von brum » 10. Aug 2009 20:31

Hallo,

ich nutze eine PCI-Express-Karte, um z.B. für ein mini-Notebook eine FW-Schnittstelle zu nutzen.

Bisher war der Treiber als Modul verfügbar.
Den konnte ich laden wie folgt:

Code: Alles auswählen

modprobe pciehp pciehp_force=1

und erhilt daraufhin auch automatisch das notwendige Device /dev/raw1394.

Nun habe ich einen neuen Kernel und dieser Treiber ist fest einkompilliert und es zuckt nix beim Einstecken der Karte... ;(

Wer weiß eine guten Rat? (Ausser Kernel neu übersetzen )

Gruß
brum

Benutzeravatar
Janka
Beiträge: 3579
Registriert: 11. Feb 2006 19:10

#2 Beitrag von Janka » 11. Aug 2009 10:58

Auf der Kernel-Kommandzeile

Code: Alles auswählen

pciehp.pciehp_force=1
anzugeben hast du schon versucht?

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

brum

pcie hotplug

#3 Beitrag von brum » 11. Aug 2009 14:06

Hallo,

danke für den Tip..., aber ich habe gerade festgestellt, meine Behauptung war nicht ganz richtig:

Wenn ich mit eingesteckter Karte boote, ist das Gerät vorhanden.
Wenn ich diese Karte nach dem booten einstecke, passiert nix.

Auch nicht, wenn ich den Kernelaufruf beim Booten mitgebe.
Von wegen hotplug. Oder muß nun hotplug noch extra aktiviert werden?

Ein anders Problemchen ist noch, dass /dev/raw1394 die Gruppenrechte root (750) hat,
da kann ich ja erstmal nicht darauf zugreifen. Dann man das beim Erzeugen manipulieren?

Gruß
brum

Benutzeravatar
Janka
Beiträge: 3579
Registriert: 11. Feb 2006 19:10

#4 Beitrag von Janka » 11. Aug 2009 14:47

Also: Coldplug geht, Hotplug nicht. Löst die Karte beim Einstecken denn überhaupt einen Hotplug-Event aus? Dein bisheriges Laden des Moduls mittels force-Option spricht eigentlich dagegen. Gucke mal nach, ob Udev irgendwas macht, wenn du die Karte einsteckst:

Code: Alles auswählen

# udevcontrol --log_priority=debug
# tail -f /var/log/messages
...Karte einstecken, gucken...
# udevcontrol --log_priority=err
Janka
Zuletzt geändert von Janka am 11. Aug 2009 15:01, insgesamt 1-mal geändert.
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

brum

#5 Beitrag von brum » 11. Aug 2009 14:57

Nö, die Karte löst keine Ereignisse aus,
weder udvadmin monitor, noch bei den Kernelmeldungen.

(udevcontrol habe ich nicht an Bord...).

Da muß ich wohl den Kernel doch noch übersetzen, möchte ich bei angeschalteten Gerät die Karte aktivieren...


Hast Du eine Idee, wie das Device mit der richtigen Gruppenzugehörigkeit erzeugt wird?

Gruß
brum

Benutzeravatar
Janka
Beiträge: 3579
Registriert: 11. Feb 2006 19:10

#6 Beitrag von Janka » 11. Aug 2009 15:06

brum hat geschrieben:Nö, die Karte löst keine Ereignisse aus,
weder udvadmin monitor, noch bei den Kernelmeldungen.

(udevcontrol habe ich nicht an Bord...).
Ein echter Mangel. Hmm. Vermutlich kommt nicht mal ein Hotplug-Event. Ich vermute, dass der Treiber für die Cardbus-Bridge (meist ist das "yenta_socket") gar nicht geladen ist. Dann kann er natürlich auch keine eingesteckte Karte erkennen.
Da muß ich wohl den Kernel doch noch übersetzen, möchte ich bei angeschalteten Gerät die Karte aktivieren...

Hast Du eine Idee, wie das Device mit der richtigen Gruppenzugehörigkeit erzeugt wird?
Auch per Udev. Wenn du aber ohnehin modprobe machst spricht doch nichts gegen ein Skript, das nach dem modprobe die Gruppe einfach ändert.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

brum

moprobe

#7 Beitrag von brum » 11. Aug 2009 15:25

Ja, aber wenn ich modprbe einsetzen will muß ich den Kernel doch neu bauen ;(

Bei meinem aktuellen Kernel ist das Teil fet drinn...

LG
brum

Benutzeravatar
Janka
Beiträge: 3579
Registriert: 11. Feb 2006 19:10

#8 Beitrag von Janka » 11. Aug 2009 18:38

Ist denn yenta_socket (oder der zu deinem Board passende CardBus-Bridge-Treiber) ebenfalls fest eingebunden?

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

brum

yenta

#9 Beitrag von brum » 11. Aug 2009 18:53

Ich deute das jetzt so als Modul:

Code: Alles auswählen

cat /boot/config-2.6.28-14-generic|grep YENTA
CONFIG_YENTA=m
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_TOSHIBA=y
So isses sicherer:

Code: Alles auswählen

$ find /lib/modules/2.6.28-14-generic/ -name "yenta*"
/lib/modules/2.6.28-14-generic/kernel/drivers/pcmcia/yenta_socket.ko
Also als Modul...

Gruß

Benutzeravatar
Janka
Beiträge: 3579
Registriert: 11. Feb 2006 19:10

#10 Beitrag von Janka » 11. Aug 2009 20:25

Ändere das mal, oder lade yenta-socket. Danach derselbe Spaß mit udev oben.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

brum

yanta

#11 Beitrag von brum » 11. Aug 2009 22:04

Hhm, yanta-socket, hier fehlt es mir an dem Wissen der Wirkungsweise...

Also geladen:

Code: Alles auswählen

# lsmod |grep yenta
yenta_socket           32396  0          
rsrc_nonstatic         19328  1 yenta_socket
pcmcia_core            43540  2 yenta_socket,rsrc_nonstatic
.. aber keine Kernelmessageraktion auf Stecken der Karte.

Antworten