[Gelöst] Netzwerkkarten nicht konfigurierbar

tasskaff · 4 März 2009

Hallo Gemeinde,

kennt jemand das Problem, dass diverse Netzwerkkarten zwar unter Hardware-Informationen auftauchen, dann aber von YaST nicht konfiguriert werden können?
Diese Situation habe ich momentan unter openSuse 10.3 auf einem MSI P6NGM Board mit der onboard-Netzwerk-Schnittstelle, sowie einer "Wald und Wiesen"-PCI Karte mit Realtek 8139 Chip.
Der Onboard-Chip meldet sich als "Micro-Star International Ethernet-Controller",
als Hersteller wird "nVidia Corporation" genannt.
In den Netzwerkeinstellungen von YaST werden beide Karten mit ihrer jeweiligen BusID aufgelistet,
lassen sich jedoch nicht konfigurieren (die Buttons "Konfigurieren" und "Löschen" sind disabled).

Der Versuch das rtl8139-Modul manuell zu laden, bringt den Fehler:

Code:

pc01:~ # modprobe rtl8139  
FATAL: Module rtl8139 not found.

und

Code:

pc01:~ # ifconfig -a

listet nur das lo-device.

Wie kann ich das Problem näher einkreisen, bzw. was fehlt mir noch, um wenigstens eine der beiden Karten zum laufen zu bringen?

Danke für Eure Aufmerksamkeit
Gruß

Anonymous · 4 März 2009

tasskaff schrieb:
Der Versuch das rtl8139-Modul manuell zu laden, bringt den Fehler:

Code:

pc01:~ # modprobe rtl8139 FATAL: Module rtl8139 not found.

und

Code:

pc01:~ # ifconfig -a

listet nur das lo-device.

Das Modul dürfte auch etwas anders heißen probier mal die beiden folgenden, oder schau mal ob eines davon
schon geladen ist.

Code:

8139cp             RealTek RTL-8139C+ series 10/100 PCI Ethernet driver
8139too            RealTek RTL-8139 Fast Ethernet driver

wahrscheinlich je nach dem ob jetzt Wald oder doch Wiese.

robi

tasskaff · 4 März 2009

danke für Deine Antwort.
jetzt habe ich

Code:

pc01:~ # modprobe 8139cp
pc01:~ # hwinfo --network
(kein Erfolg)
pc01:~ # modprobe 8139too
pc01:~ # hwinfo --network
(kein Erfolg)

eingegeben.
Ok, keine Fehlermeldung, aber die Karte lässt sich immer noch nicht ansprechen. Wie schalte ich das Ding bloß ein?

Fürs die onboard-LAN habe ich einen Treiber gefunden, der sich "forcedeth" nennt.

Code:

pc01:~ # modprobe forcedeth

wird scheinbar angenommen. Zumindest wird der NIC jetzt von

Code:

pc01:~ # hwinfo --network

und von

Code:

pc01:~ # ifconfig -a

gelistet.

da die Kiste aber routen soll, brauche ich beide Interfaces. Und die Realtek will nicht. Seltsam. :???:
irgendwelche Vorschläge?

[edit]
Und einen Reboot überlebt die nVidia-Konfiguration auch nicht. D.h. ich muss nach dem Neustart wieder auf die Konsole,
"modprobe forcedeth" eingeben und anschließend die LAN-Einstellungen neu vornehmen.
Irgendwas liegt da noch im Argen.
[/edit]

Gruß

tasskaff · 5 März 2009

Nachtrag:
Das Problem mit dem reboot habe ich gelöst, indem ich in der Datei
/etc/sysconfig/kernel

Code:

 # ...
MODULES_LOADED_ON_BOOT="forcedeth"
# ...

das Modul "forcedeth" eingetragen habe.
Aber vielleicht geht das auch noch eleganter. Was meint Ihr?

spoensche · 5 März 2009

tasskaff schrieb:
Aber vielleicht geht das auch noch eleganter. Was meint Ihr?

Eleganter geht es definitiv nicht. Dafür gibt es die Variable ja.

Anonymous · 5 März 2009

Wegen der Wald und Wiesenkarte, zeig mal den Abschnitt der HW-Info (Befehl hwinfo und dann in der Ausgabe den entsprechenden Abschnitt für diese Karte suchen)
die Ausgabe von lspci -nn. Da müssen wir mal nachschauen was Linux da auf PCI-Seite überhaupt sieht.
und rein informativ was bei dir los im HW-Umfeld los geht und was im Rechner so zusammenkonfiguriert ist. cat /proc/interrupts

Irgendwie scheint beim Laden der beiden Treibermodule die in Frage kommen könnten, die Karte nicht mit autoprobe gefunden zu werden.

robi

tasskaff · 5 März 2009

Danke erstmal für Eure rege Teilnahme.

@spoensche: Danke für Deine Bestätigung, das Thema "Konfigurationspersistenz" kann ich zu den Akten legen

@robi: Danke für Dein Angebot zur Hilfe. Na dann mal los (Ärmel hochkrempel und in die Hände spuck):

Code:

pc01:~ # hwinfo --netcard
32: PCI 0f.0: 0200 Ethernet controller
  [Created at pci.301]
  UDI: /org/freedesktop/Hal/devices/pci_10de_7dc
  Unique ID: rBUF.vr4WNiVmLOA
  SysFS ID: /devices/pci0000:00/0000:00:0f.0
  SysFS BusID: 0000:00:0f.0
  Hardware Class: network
  Model: "Micro-Star International Ethernet controller"
  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x07dc
  SubVendor: pci 0x1462 "Micro-Star International Co., Ltd."
  SubDevice: pci 0x366c
  Revision: 0xa2
  Driver: "forcedeth"
  Driver Modules: "forcedeth"
  Device File: eth0
  Memory Range: 0xfea7b000-0xfea7bfff (rw,non-prefetchable)
  I/O Ports: 0xc880-0xc887 (rw)
  Memory Range: 0xfea7e800-0xfea7e8ff (rw,non-prefetchable)
  Memory Range: 0xfea7e400-0xfea7e40f (rw,non-prefetchable)
  IRQ: 16 (13385 events)
  HW Address: 00:21:85:9b:99:8b
  Link detected: yes
  Module Alias: "pci:v000010DEd000007DCsv00001462sd0000366Cbc02sc00i00"
  Config Status: cfg=no, avail=yes, need=no, active=unknown

34: PCI 107.0: 0200 Ethernet controller
  [Created at pci.301]
  UDI: /org/freedesktop/Hal/devices/pci_ec_8139
  Unique ID: 2_DJ.obGY_0nn_DB
  Parent ID: bSAa.M2gbdOfB0S7
  SysFS ID: /devices/pci0000:00/0000:00:0a.0/0000:01:07.0
  SysFS BusID: 0000:01:07.0
  Hardware Class: network
  Model: "Ethernet controller"
  Vendor: pci 0x00ec
  Device: pci 0x8139
  SubVendor: pci 0x00ec
  SubDevice: pci 0x8139
  Revision: 0x10
  I/O Ports: 0xe800-0xe8ff (rw)
  Memory Range: 0xfebfec00-0xfebfecff (rw,non-prefetchable)
  Memory Range: 0xfeb00000-0xfeb0ffff (ro,prefetchable,disabled)
  IRQ: 7 (no events)
  Module Alias: "pci:v000000ECd00008139sv000000ECsd00008139bc02sc00i00"
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #27 (PCI bridge)

Code:

pc01:~ # lspci -nn|grep -i eth
00:0f.0 Ethernet controller [Class 0200]: nVidia Corporation Unknown device [10de:07dc] (rev a2)
01:07.0 Ethernet controller [Class 0200]: Unknown device [00ec:8139] (rev 10)

Code:

pc01:~ # cat /proc/interrupts
           CPU0       CPU1
  0:        125          0   IO-APIC-edge      timer
  1:         30         67   IO-APIC-edge      i8042
  8:          2          0   IO-APIC-edge      rtc
  9:          0          0   IO-APIC-fasteoi   acpi
 12:          4          0   IO-APIC-edge      i8042
 14:        239      10779   IO-APIC-edge      libata
 15:          0          0   IO-APIC-edge      libata
 16:         26      11975   IO-APIC-fasteoi   eth0
 17:         26        231   IO-APIC-fasteoi   ohci_hcd:usb1
 18:          2          0   IO-APIC-fasteoi   ehci_hcd:usb2
220:      82286          0   PCI-MSI-edge      ahci
NMI:          0          0
LOC:      58814      82414
ERR:          1
MIS:          0

.

ich bin mal gespannt, in welche Untiefen mich das jetzt wieder führt .

Gruß

Anonymous · 5 März 2009

tasskaff schrieb:
ich bin mal gespannt, in welche Untiefen mich das jetzt wieder führt .

In die allertiefsten natürlich

Also die PCI-ID die dein Gerät hochbringt kennt weder der Treiber noch die in Linux verwendetet Datenbank. Müssen wir eben versuchen selbst eine Verknüpfung zu erstellen damit er auf diesen PCI-Steckplatz einen Treiber versucht zu platzieren und eventuell den Chip findet.
1. Versuch
eine Datei anlegen

Code:

/etc/sysconfig/hardware/hwcfg-bus-pci-0000:01:07.0

anlegen mit folgendem Inhalt

Code:

MODULE='8139too'
MODULE_OPTIONS=''
STARTMODE='auto'

Rechte User und Gruppe

Code:

-rw-r--r-- 1 root root

danach Rechner mal durchstarten

robi

PS: hier gleich mal die letzte Möglichkeit wenn alles andere versagen sollte.

Wenn alle Sticke reißen

dann haben wir immer noch die letzte Möglichkeit die aber immer funktioniert. Treiber Quellcode im Kernel ändern.

Hast du schon mal einen Kernel selbst gebaut ?

Kernelquellcode (aktuelle Version deines Kernels) und Entwicklertools installiert.
Dann den Kernelcode configurieren.

Am Quellcode müssen folgende Änderungen gemacht werden.
Verzeichnis : /usr/src/linux/drivers/net
Datei : 8139too.c wenn das nicht !00% klappen sollte dann 8139cp.c leider kann ich auch nicht genau sagen welcher Treiber die Chiprevision D besser beherrscht, aber nicht beide Treiber gleichzeitig, sonst versuchen 2 Module gleichzeitig auf die Karte zuzugreifen, da müsstest du sonst dann immer über die /etc/modprobe.d/blacklist einen der beiden Treiber verbieten.

Abschnitt in dem geändert wird sieht so aus : müsste sich irgendwo im 1. Drittel der Dateien befinden

Code:

static struct pci_device_id rtl8139_pci_tbl[] = {
        {0x10ec, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
        {0x10ec, 0x8138, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
        {0x1113, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
.........

in der anderen Datei sieht er so aus

Code:

static struct pci_device_id cp_pci_tbl[] = {
        { PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139,
          PCI_ANY_ID, PCI_ANY_ID, 0, 0, },
        { PCI_VENDOR_ID_TTTECH, PCI_DEVICE_ID_TTTECH_MC322,
          PCI_ANY_ID, PCI_ANY_ID, 0, 0, },
        { },

hier fügst du jeweils eine Zeile ein (möglichst irgendwo in der Mitte, wegen dem Komma

aufpassen in der 2. Datei mit den geschweiften Klammern die über 2 Zeilen gehen. )

Code:

       {0x00ec, 0x8138, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },

Dann die Module oder den Kernel neu Kompilieren und installieren.

Hilfe zum Kernelbauen wirst du hier im LC oder auch in unserem Wiki finden.

robi

tasskaff · 5 März 2009

In die allertiefsten natürlich

ich hab's befürchtet.

Also die PCI-ID die dein Gerät hochbringt kennt weder der Treiber noch die in Linux verwendetet Datenbank.

Wie kriegt man sowas raus?

Also der 1. Versuch hat nur bedingt hingehauen. Die Karte lässt sich immer noch nicht ansprechen. Aber das Modul wird wohl geladen.

Code:

pc01:~ # lsmod|grep 8139
8139too                29184  0
mii                     9344  1 8139too

Also liegt es evtl. doch nicht am kernel.

Hast du schon mal einen Kernel selbst gebaut ?

Nein.

ps:

jetzt hab ich mir mal die Ausgabe von dmesg genauer angeschaut und folgendes entdeckt:

Code:

pc01:~ # dmesg|tail -n 10
8139too Fast Ethernet driver 0.9.28
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 19
ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [LNKB] -> GSI 19 (level, low) -> IRQ 20
8139too 0000:01:07.0: Chip not responding, ignoring board
ACPI: PCI interrupt for device 0000:01:07.0 disabled
8139too: probe of 0000:01:07.0 failed with error -5
Bridge firewalling registered
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
st: Version 20070203, fixed bufsize 32768, s/g segs 256

die Zeile
8139too 0000:01:07.0: Chip not responding, ignoring board
könnte auf eine defekte Karte hinweisen, oder? Mal schaun, ob ich noch irgendwo eine rumliegen hab. Aber für eine Bestätigung oder einen Einspruch wäre ich trotzdem dankbar.

Gruß

Anonymous · 5 März 2009

tasskaff schrieb:
die Zeile
8139too 0000:01:07.0: Chip not responding, ignoring board
könnte auf eine defekte Karte hinweisen, oder? Mal schaun, ob ich noch irgendwo eine rumliegen hab. Aber für eine Bestätigung oder einen

Wenn du eine andere Karte hast, dann ist das sicherlich der einfachste Weg, die Dinger sollten wohl nur noch ein paar Euro kosten.

Zur Erklärung:
in den Kernelmodulen ist eindeutig festgelegt auf welche PCI-ID der Treiber anspringen soll. Deine ist leider nicht dabei.

Vendor: pci 0x00ec
Device: pci 0x8139

Die Änderung am Kernel in den Modulen hätte genau das dort eingetragen. So das sich der Treiber dann für diese Karte als zuständig erkannt hätte.

Zwar gibt es prinzipiell auch andere Möglichkeiten wie die Treiber sich ihre Geräte aussuchen und so sich zT auch mal zwingen lassen ein bestimmtes Gerät zu benutzen, allerdings sind die anderen Methoden nicht mehr ganz so modern weil nicht ganz so ( um nicht zu sagen überhaupt nicht) flexibel im Kernel genutzt werden können, so das sie die Entwickler nur noch selten in ihren Modulen verwenden bzw unterstützen. Das hätte dann eventuell im ersten Versuch klappen können. Deine Karte ist nicht kaputt, der Treiber hat nur keine Einsicht, das er etwas bedienen soll, was ihm genau so nicht eindeutig ins "Aufgabenbuch" geschrieben ist. Der ist eben stur wie die deutsche Bürokratie.

Wenn du mal im Internet suchst, das Problem mit dieser Karte hatten schon andere vor Jahren.

zB hier
Ich würde sie aber nicht wegschmeißen, wenn du irgendwann mal auf Idee kommen solltest dich mit dem selberbauen eines Kernels zu befassen, ist das eine gute Übung, einen Kernel zu bauen der diese Karte unterstützt.

Wenn du eine andere Karte findest, dann bau die einfach ein. Lösche aber bitte die oben angelegte Datei wieder, sonst gibt es eventuell irgendwann Probleme wenn du eine andere Karte auf diesem PCI-Steckplatz hast.

robi

tasskaff · 6 März 2009

Deine Karte ist nicht kaputt, der Treiber hat nur keine Einsicht, das er etwas bedienen soll

das klingt doch vielversprechend!

das Problem mit dieser Karte hatten schon andere vor Jahren.

ist ja auch ne alte Karte. Danke für den Link.

Wenn du eine andere Karte findest, dann bau die einfach ein. Lösche aber bitte die oben angelegte Datei wieder, sonst gibt es eventuell irgendwann Probleme wenn du eine andere Karte auf diesem PCI-Steckplatz hast.

Danke auch für diese Warnung. Man kann die Notwendigkeit des Aufräumens nicht oft genug betonen. Ich hätte es glatt auch vergessen (schäm).

Melde mich wieder nach Karten- Austausch/Test.
Danke robi für Deine kompetente Hilfe.

PS. habe eben bemerkt, dass beim starten ne Menge Fehler mit udev... übern Bildschirm rauschen.
In der /var/log/messages wird dann folgendes protokolliert (Ausschnittsweise)

Code:

Mar  5 23:53:31 pc01 syslog-ng[2544]: syslog-ng version 1.6.12 starting
Mar  5 23:53:31 pc01 lsvpd[2647]: Warning: /proc/device-tree Not Found
Mar  5 23:53:31 pc01 lsvpd[2647]: VpdDbEnv.VpdDbEnv( /var/lib/lsvpd, db ): Must have read permission of /var/lib/lsvpd.  Details: DbEnv::open: No such file or directory
Mar  5 23:53:31 pc01 udevd-event[2644]: run_program: '/usr/sbin/vpdupdate' abnormal exit
Mar  5 23:53:31 pc01 lsvpd[2658]: VpdDbEnv.VpdDbEnv( /var/lib/lsvpd, db ): Must have read permission of /var/lib/lsvpd.  Details: DbEnv::open: No such file or directory
Mar  5 23:53:31 pc01 udevd-event[2657]: run_program: '/usr/sbin/vpdupdate' abnormal exit
Mar  5 23:53:31 pc01 lsvpd[2654]: Warning: /proc/device-tree Not Found

... usw. mit unregelmäßig aufsteigenden [Nummern].

Die inodes /proc/device-tree und /var/lib/lsvpd existieren nicht.
Das Paket lsvpd ist installiert und hat laut Beschreibung was mit HW-Managment zu tun.
was ist /proc/device-tree? Google ist da ziemlich zurückhaltend.

das wird ja immer komplizierter :???:

Gruß

tasskaff · 6 März 2009

Nachtrag:

Habe die "Wald" Realtek-karte mit dem Chip RTL8139C
gegen ne "Wiesen" Realtek mit RTL8139D-Chip ausgetauscht.
Und siehe da, die Karte wurde auf Anhieb erkannt, konfiguriert und läuft jetzt mit dem 8139too Modul.

Resümee:

wahrscheinlich je nach dem ob jetzt Wald oder doch Wiese.

Revision D läuft. Revision C will erst mühsam überredet werden.

Vielen Dank Euch allen mal wieder und ganz besonders an robi.

Gruß

[Gelöst] Netzwerkkarten nicht konfigurierbar

tasskaff

Member

Anonymous

Gast

tasskaff

Member

tasskaff

Member

spoensche

Moderator

Anonymous

Gast

tasskaff

Member

Anonymous

Gast

tasskaff

Member

Anonymous

Gast

tasskaff

Member

tasskaff

Member