Realtek Netzwerkkarte, udev und I/O-Bereich

[dora71]

Hallo Forum,

in meiner Verzweiflung wende ich mich mal wieder an Euer Expertenwissen.

Habe ein großes Problem mit meinem Debian Etch - Server, Kernel 2.6.18-6-k7: Nach (Zwangs-)Umzug auf ein neues Motherboard will meine o. g. Netzwerkkarte nicht mehr. Diese hat einen Realtek 8139 - Chip eingebaut.

Hatte bisher noch nie Probleme damit, ein Knoppix läuft (von CD gebootet) auf dem gleichen Rechner ohne zu murren und merkwürdigerweise funktioniert sie auch mit Kernel 2.6.7-1-k7 ohne Probleme

Daher tippe ich auf udev, was mir Probleme macht. Hier erst einmal einige Systemmeldungen:

dmesg

Code: Alles auswählen

8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
8139cp 0000:00:08.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
8139cp 0000:00:08.0: Try the "8139too" driver instead.
8139cp 0000:00:09.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
8139cp 0000:00:09.0: Try the "8139too" driver instead.
8139too Fast Ethernet driver 0.9.27
eth0: RealTek RTL8139 at 0xdc00, 00:00:1c:d9:71:fc, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8139B'
8139too: probe of 0000:00:09.0 failed with error -16

dmesg liefert an anderer Stelle:

Code: Alles auswählen

pnp: 00:01: ioport range 0xde00-0xde03 has been reserved

Das soll aber genau der Bereich sein, wo meine Netzwerkkarte liegt, daher kann sie auf diesem IO-Bereich nicht arbeiten.

Ein Auszug aus /var/log/messages liefert noch Folgendes:

Code: Alles auswählen

Sep 19 09:31:22 rechner kernel: PCI: Unable to reserve I/O region #1:100@de00 for device 0000:00:09.0
Sep 19 09:31:22 rechner kernel: Trying to free nonexistent resource <000000000000de00-000000000000deff>
Sep 19 09:31:22 rechner kernel: Trying to free nonexistent resource <00000000efffff00-00000000efffffff>
Sep 19 09:31:22 rechner kernel: 8139too: probe of 0000:00:09.0 failed with error -16

cat /proc/ioports liefert das:

Code: Alles auswählen

0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vesafb
03f6-03f6 : ide0
0778-077a : parport0
0cf8-0cff : PCI conf1
5000-5003 : ACPI PM1a_EVT_BLK
5004-5005 : ACPI PM1a_CNT_BLK
5008-500b : ACPI PM_TMR
5010-5015 : ACPI CPU throttle
5020-5023 : ACPI GPE0_BLK
50e0-50ef : amd756_smbus
b000-cfff : PCI Bus #01
  c800-c8ff : 0000:01:05.0
da00-da03 : 0000:00:00.0
  da00-da00 : ACPI PM2_CNT_BLK
dc00-dcff : 0000:00:08.0
  dc00-dcff : 8139too
de00-deff : 0000:00:09.0
  de00-de03 : motherboard
    de00-de03 : pnp 00:01
f000-f00f : 0000:00:07.1
  f000-f007 : ide0
  f008-f00f : ide1

Jetzt die alles entscheidende Frage: Kann ich irgendwo in den Tiefen von udev den io-Bereich ändern für die betreffende Netzwerkkarte?!? Oder gibt es eine andere Möglichkeit, die Karte wieder mit Leben zu versorgen. Es ist echt frustrierend, meine Suchanfragen im Forum bzw. Internet haben mir auch nicht wirklich viel geholfen.
Habe mir z. Zt. so beholfen, daß ich eine 2. Netzwerkkarte eingebaut habe. Diese benutzt einen anderen IO-Bereich und wird ohne Probleme akzeptiert (übrigens mit demselben Chipsatz).

Danke für Eure Hilfe.

Schönes Wochenende.

Gruß

Dora71

[nepos]

Damit hat udev nichts zu tun. Für IRQ und Co ist der Kernel zuständig. Bist du dir da eigentlich sicher, dass du den richtigen Treiber benutzt? Die Ausgabe von dmesg liest sich nämlich nicht so.

[rendegast]

Beide Treiber 8139cp und 8139too haben diese PCI-ID

Code: Alles auswählen

modinfo Treiber | grep -i 10ec.*8139
oder 
cat /lib/modules/KERNEL/modules.* | grep -i 10ec.*8139

Bsp:

Code: Alles auswählen

$ cat /lib/modules/2.6.26-1-686/modules.* | grep -i 10ec.*8139
alias pci:v000010ECd00008139sv*sd*bc*sc*i* 8139cp
alias pci:v*d00008139sv000010ECsd00008139bc*sc*i* 8139too
alias pci:v000010ECd00008129sv*sd*bc*sc*i* 8139too
alias pci:v000010ECd00008138sv*sd*bc*sc*i* 8139too
alias pci:v000010ECd00008139sv*sd*bc*sc*i* 8139too

Daher versucht udev wohl beide aus.

Möglich, daß der Ladeversuch des 8139cp das Gerät für den 8139too unzugänglich macht.
Dann wäre die einfachste Lösung ein blacklisten des 8139cp.
Der 8139cp sollte dann auch nicht in der initrd vorhanden sein -> diese gegebenenfalls neu erstellen.

8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)

8139too Fast Ethernet driver 0.9.27

Im 2.6.26-1 liegen die Versionen 1.3 und 0.9.28 vor,
welche im 2.6.24-etchnhalf ?
Den zusätzlich zu installieren ist vielleicht generell eine gute Idee?





bios-Einstellung bzgl PCI?
bios-upgrade flashen?

[dora71]

Hallo zusammen und danke für die bisherige Hilfe.

Hier der aktuelle Zwischenstand:

Das Blacklisten des Treibers 8139cp (inklusive neuer Initrd Erstellung) schmeißt das Modul zwar heraus, aber das o. g. Problem bleibt nach wie vor. Habe ich mir gedacht, da ja der Einbau einer weiteren Netzwerkkarte mit dem gleichen Chipsatz erfolgreich war.

Da ich ehrlich gesagt keine Ahnung von etch-n-half habe, werde ich mal probieren, mir den neuesten Kernel selber zu backen, vielleicht hilft das etwas.

Sonstige Lösungen sind jederzeit willkommen.

Gruß

Dora71