Kernel 2.6.18-6-amd64 etch

[helsch]

Moin moin.

Nach viel Sucherei hier im Forum und im Netz weis ich mir langsam nicht mehr zu helfen.
Hatte bis vor kurzem einen Debian Etch Server auf einem älteren K7 am laufen.
Da durch den Umbau von ein paar Desktops Hardware über geblieben ist, hab ich diese dem Server gegönnt. Dieser hat nun ein ASROCK 945G-DVI mit einem Intel Core Duo 2GHz und 2GB DDRII bekommen.
HDD aus dem alten PC raus, Hardware getauscht und HDD wieder rein.
Zuerst mit einem 2.6.18-4-486 wieder gestartet und alles (fast alles) lief wieder.
Die alten IDEs raus und 2x 500GB SATAII rein, System kopiert und mit Aptitude 2.6.18-6-amd64 installiert.
ISDN Karte, PIO Karte, vmware usw. wieder neu eingerichtet und kompiliert. Dann hatte es den Anschein, dass alle
einwandfrei läuft. Linux hatte allerdings den Realtek R8111/R8168 als R8169 erkannt. Der Treiber läuft aber nicht stabil und flott mit der Onboardkarte. Also hab ich versucht den neuen Treiber 8.006 von Realtek einzurichten.
rmmod r8169, depmod -a und den neuen wieder rein.
Nur läst sich in keinster Weise der r8169 deaktivieren. Bei einem Reboot ist er immer wieder da, sogar parallel zum r8168.
blacklist r8169 hilft genauso wenig wie das Löschen von r8169.ko. Das sagt aus, dass der Treiber nicht als Modul sondern im Kernel geladen wird. Aber die Blacklist hilft auch nicht weiter.
Hab nun ein startscript eingerichtet in dem der r8169 entladen und der r8168 geladen wird.

Das nächste Problem: Die USB-HDD wird zwar erkannt aber kann nicht über die fstab eingebungen, gemountet, werden. Wenn Linux an dem Punkt in der fstab angekommen ist steht laut dmesg das USB-Interface noch nicht zur Verfügung und daher kommt dort der Fehler, dass das Gerät nicht gefunden wurde.
Auch dies erledige ich nun mit dem startscript.

Es läuft jetzt problemlos, es sei denn, ich bin auf weitere Probleme noch nicht gestoßen.

Eine Neuinstallation kommt für mich nicht in frage, ist ja kein Astalavista von Benny.
Zudem wird das eine lange Angelegenheit da dort mittlerweile einige eingerichtet ist:
dateiserver, emailserver, proxy, webserver, isdn, vbox, hylafx, vmwareserver, usw.

Kurz zur Hardware:
ASROCK 945G-DVI
R8111/R8168B onboard
VGA onboard
Audio und andere Schnittstellen im BIOS deaktiviert
AVM PCI Fritzcard, Hylafax, vbox, Power-ISDN-Monitor
PIO 2x LPTs (Relaiskarten)
Intel Core Duo E2180 2GHz
2x 1GB DDRII 666
2x 500GB SATAII (bootpartition sda1)
2x 500GB IDE
1x 500GB USB
Kernel 2.6.18-6-amd64
trotz der vielen HDDs kein LVM oder Raid, macht er alles mit rsync
PS/2 Tastatur, 640x480 VGA Monitor

Ansonsten läuft alles recht gut. Samba könnte ein wenig mehr aus den Puschen kommen.
Die Platten machen alle 80-100MB/sec. Das Netzwerk gibt beim erstmaligen Zugriff nur 35-40MB/sec her.
Beim zweiten Zugriff, dann ist es ja im Puffer, kommen da schon mal 60-70MB/sec rüber.
Aber da beschwere ich mich ja nicht, vista hängt da auch hin und wieder.

Gruß
Helmut

[cirrussc]

Hallo Helmut und willkommen im debianforum!

zum Treiber: er ist definitiv als Modul vorhanden, sonst könntest du ihn nicht entladen. Apropos, gibt er denn eine Fehlermeldung dabei aus?

Code: Alles auswählen

modprobe -r r8169

Zur USB HDD: Ich denke mal, das blockdevice stimmt einfach nicht, das kann sich gerade bei SATA Geräten im System mit USB verheddern. Die Treiber sollten alle schon geladen sein, der Standardkernel hat ausserdem eine initrd. Am einfachsten ist, du verpasst der Platte ein Label und trägst dies in die fstab ein (bitte Forensuche benutzen).
Alternativ aber schlechter zu lesen, ist die Verwendung von UUID's.
Zur Sicherheit, auch wenn es jetzt gut zu funktionieren scheint, kannst du die /boot/grub/menu.lst auch auf uuid umstellen.

Ansonsten bekommen ich solche Übertragungsraten mit samba nicht hin (gut 100mbit).

btw. was war jetzt eigentlich deine Frage?

[helsch]

Hallo cirrussc.

Ob ich nun mit modprobe -r oder rmmod den r8169 entlade, geht dies einwandfrei ohne irgend welche Fehler. Es kommt die Meldung, das der IRQ wieder freigeben ist und der Treiber disabled wurde. Wie bei vielen anderen Modulen eben auch.
Ich kann danach auch einwandfrei den r8168 laden. Danach ein networking restart und es läuft.
Mach ich jetzt ein Reboot hat er jetzt beide Module geladen. Bei einem lsmod erscheint der r8169 und r8168. Das scheint mir halt auch ein wenig seltsam zu sein.

Der Tip mit dem USB Laufwerk ist auch gut. Er erklärt auch das Phänomen, dass ich zwischen durch hatte, dass die Reihenfolge von den beiden SATAs und dem USB nicht stimmte. Das USB hatte sda und die SATAs sdb und sdc. Aber ich hab die USB jetzt aus der fstab genommen und mounte das USB ganz zum Schluß des Bootvorganges über ein Script.

Zu dem Netzwerkdatendurchsatz muß ich auch hinzu fügen, dass es sich um ein Gigabitnetzwerk handelt. Bin auch noch auf der Suche nach einer aktiven Karte für den Server. Für HDTV Livestreaming brauch ich den Durchsatz eben und einmal CasinoRoyal in HDTV sind schon mehr als 25GB (ohne Komprimierung).

Hatte die Tage schon angefangen mir den Kernel 2.6.18-6-amd64 neu zu kompilieren. Mit make menuconfig hatte alle Netzwerkmodule ausgeschaltet. Nach dem ich aber die Kompilierung starten wollte (make-kpkg kern...) fragt er noch ein dutzend Dinger ab von denen ich eigendlich dachte, daß er sie aus der Konfiguration nimmt die ich aus /boot kopiert hatte und da werd ich wohl oder übel nicht alles richtig angegeben haben da der neue Kernel beim Booten hängen bleibt.

Gruß
Helmut

[_Chrisu]

Hallo cirrussc.

Ob ich nun mit modprobe -r oder rmmod den r8169 entlade, geht dies einwandfrei ohne irgend welche Fehler. Es kommt die Meldung, das der IRQ wieder freigeben ist und der Treiber disabled wurde. Wie bei vielen anderen Modulen eben auch.
Ich kann danach auch einwandfrei den r8168 laden. Danach ein networking restart und es läuft.
Mach ich jetzt ein Reboot hat er jetzt beide Module geladen. Bei einem lsmod erscheint der r8169 und r8168. Das scheint mir halt auch ein wenig seltsam zu sein.

...

Gruß
Helmut

Hallo Helmut,

ich habe derzeit genau das selbe Problem.
Wollte meinen Servers mittels WOL wecken, mit dem r6169 klappt das nicht, angeblich soll es aber mit dem r8168 gehen. Ich kämpfe derzeit auch damit das alte Modul r8169 rauszubekommen, jedoch bisher ohne Erfolg.
Hast du eine Lösung für das Problem gefunden? Wie bereits erwähnt rmmod r8169 bzw blacklisten hilft alles nichts - nach einem Reboot läuft der r8169 wieder - parallel zum r8168. Habe den selben Kernel am laufen ...

Code: Alles auswählen

SERVER:~# lsmod | grep r816
r8168                  45200  0
r8169                  36872  0

Gruß
_chriu

[KBDCALLS]

Moin moin.
Nur läst sich in keinster Weise der r8169 deaktivieren. Bei einem Reboot ist er immer wieder da, sogar parallel zum r8168.
blacklist r8169 hilft genauso wenig wie das Löschen von r8169.ko. Das sagt aus, dass der Treiber nicht als Modul sondern im Kernel geladen wird. Aber die Blacklist hilft auch nicht weiter.
Hab nun ein startscript eingerichtet in dem der r8169 entladen und der r8168 geladen wird.

Wenn du den Treiber loswerden willst hilft nur eine neue Initrd. Denn das was du beschreibst deutet darauf hin das der da geladen wird. Dazu muß man aber verhindern das dieser Treiber in der Intrd wieder landet. Wenn du den einen Original Debiankernel hast , dann wäre der einfachste Weg über dpkg-reconfigure um eine neue Initrd zu erstellen. Weiter gehe ich davon aus das du mkinitramfs zum erstellen der initrd nimmst. Dazu müßtest du dann aber die Konfig von mkinitrd verändern

Die sieht im Original folgendermaßen aus.

Code: Alles auswählen

  1 # /etc/mkinitrd/mkinitrd.conf:
  2 #  Configuration file for mkinitrd(8).  See mkinitrd.conf(5).
  3 #
  4 # This file is meant to be parsed as a shell script.
  5
  6 # What modules to install.
  7 MODULES=most

In Zeile sieben müßtest du das most in dep abändern.

Wie man sich die Initrd im cpio Format von innen ansieht ist hier beschrieben.

[_Chrisu]

Danke für die Hinweise - ich habe es jetzt hinbekommen. Habe den Treiber nochmal rausgeschmissen und neu reingenommen. Denk aber dass der entscheidende Befehlt

Code: Alles auswählen

update-initramfs -u

war - hab ich vorher nicht gemacht. Was ja auch den Beschreibungen von KBDCALLS entspricht. Dennoch vielen Dank

Gruß
_chrisu