[Eisfair_dev] [e1] eiskernel 2.0.25 (Status 'testing') verfügbar - 2.6er Kernel für eisfair-1

Mi Aug 29 22:45:49 CEST 2012

Am 29.08.2012 15:07, schrieb Thomas Bork:
> Am 29.08.2012 12:01, schrieb Thomas Kienemund:
> 
>> Nein, der ist dafür nicht geeignet, deshalb ja das andere Modul.
> 
> Das glaube ich nicht. Welchen Netzwerk-Chip setzt Du ein?

Ich benutze ein Intel D945GCLF Board, was eben genau bei der
Onboardnetzwerkkarte für Probleme sorgt bzw. diese nicht nutzbar ist:

01:00.0 Class [0200]: Device [10ec:8136] (rev 02)
        Subsystem: Device [8086:0001]
        Flags: bus master, fast devsel, latency 0, IRQ 16
        I/O ports at 2000 [size=256]
        Memory at 88200000 (64-bit, non-prefetchable) [size=4K]
        Memory at 88000000 (64-bit, prefetchable) [size=64K]
        [virtual] Expansion ROM at 88020000 [disabled] [size=128K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 01
        Capabilities: [ac] MSI-X: Enable- Count=2 Masked-
        Capabilities: [cc] Vital Product Data
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 01-00-00-00-36-4c-e0-00
        Kernel driver in use: r8101
        Kernel modules: r8101

Ich hatte bereits dazu um Hilfe gebeten gehabt, mir wurde auch sofort
geholfen, aber das Problem besteht seitdem immer noch, so dass ich
seitdem eine 3com 3c509B Netzwerkkarte verwende, die bereits vorher
schon immer zuverlässig lief.

>> Bei der
>> Installation vom Treiberpaket wird der r8169 auch deaktiviert und das
>> r8101 Modul ist derzeit auch nicht enthalten (2.6er Kernel), deshalb
>> macht es schon Sinn, dieses Modul zu integrieren.
> 
> ...Da der r8169 im Kernel 2.6 sowohl r1000, r8101 sowie r8168 ersetzt.
> 
> Unsere base nimmt deshalb auch ein Mapping von diesen Modulen auf r8169
> vor, damit man nach einem Update von unserem 2.4.35-wt1 nicht plötzlich
> ohne Netz da steht, weil man den Treiber-Namen in der base nicht
> angepasst hat (müsste man ja ständig, wenn man zwischen 2.4 und 2.6 hin-
> und herbootet...).
> 
> Hattest Du in der base mit Kernel 2.4.35-wt1 also r8101 als
> Netzwerk-Treiber zu stehen und machst ein Kernel-Update auf
> 2.6.32-eisfair-1, dann steht zwar immer noch r8101 in der base, geladen
> wird aber r8169...

Sowohl unter dem 2.4.35-wt1 als auch unter dem aktuellen
Entwicklerkernel besteht die gleiche Problematik. Ich habe gestern
zunächst versucht, die Onboardkarte mit dem eisfaireigenen Kernelmodul
zum laufen zu bekommen (r8169), leider erfolglos. Daraufhin habe ich mir
das besagte r8101-Treibermodul von Realtek besorgt, kompiliert,
installiert und daraufhin lief die Karte zumindest anfangs mit 10
Mbit/s. Kurioserweise bliebt dabei die Status-LED der Onboardkarte aus,
was bei der Bandbreite laut Handbuch aber auch gewollt ist. Bei dem
Testlauf habe ich zunächst die bisherige 3com Karte aktiv gelassen und
via modprobe und ifconfig die Onboardkarte im laufenden Betrieb
eingebunden. Dann bin ich hingegangen und habe einfach eine große
iso-Datei via FTP vom Server auf meinen Desktoprechner kopiert, um zu
schauen, ob die Verbindung stabil ist oder Pakete verworfen bzw.
fehlerhaft übertragen werden. Laut ifconfig sah alles gut aus (keinerlei
Fehler), aber die Verbindung stockte ab und zu und die Geschwindigkeit
stabilisierte sich auf etwa 5-6 MB/s (Megabyte). Der alte Fehler von
damals ist dabei leider immer noch präsent, d.h. die Onboardkarte
(RTL8102EL) wird immer noch als "RTL8101E" erkannt und dies stellt
meiner Meinung nach ein eindeutiges Treiberproblem dar:

r8101 Fast Ethernet driver 1.022.00-NAPI loaded
r8101 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
r8101 0000:01:00.0: setting latency timer to 64
r8101: This product is covered by one or more of the following patents:
US5,307,459, US5,434,872, US5,732,094, US6,570,884, US6,115,776, and
US6,327,625.
eth0: Identified chip type is 'RTL8102E'.
eth0: RTL8101E at 0xf804a000, <MAC-Adresse-unkenntlich-gemacht>, IRQ 16
r8101  Copyright (C) 2012  Realtek NIC software team <nicfae at realtek.com>
 This program comes with ABSOLUTELY NO WARRANTY; for details, please see
<http://www.gnu.org/licenses/>.
 This is free software, and you are welcome to redistribute it under
certain conditions; see <http://www.gnu.org/licenses/>.

Wie erkennbar ist, wird als Chiptyp "RTL8102E" richtig erkannt, aber der
Treiber verwendet trotzdem ein "RTL8101E" Gerät und das führt dazu, dass
die Netzwerkkarte nach ein Paar Minuten nicht mehr erreichbar ist.
Kernelseitig funktionieren tut aber z.B. die Verbindungserkennung:

kernel: r8101: eth0: link down
kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
kernel: r8101: eth0: link up
kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Also alles nicht so einfach wie man sieht :) Unter Windows funktioniert
die Karte tadellos und auch die Geschwindigkeit ist absolut in Ordnung
für eine 100 MBit/s-Onboard-Lankarte.

Was mir allerdings aufgefallen ist, ist die verwendete "Base address",
die bei beiden Karten jeweils 0x4000 ist und eventuell ein Problem sein
könnte. Ich werde daher testweise die PCI-Karte am Wochenende ausbauen
und nochmals beide Kernelmodule mit dem eis-System und mit der System
rescue CD testen.

Aus diesem Grund dachte ich mir, Du könntest da eventuell noch an der
einen oder anderen Stellschraube drehen, um das gute Stück trotz aller
Rückschläge zum laufen zu bekommen, denn wie gesagt, unter Windows tut
die Lankarte das was sie soll.

Gruß

Thomas