[Christian_renamed]

@sledge0303

stellst du den patch online?

Patch ist online.

http://download.netzwerkdienst-witte...00/e1000.patch

Thomas hat dazu noch ein paar Bemerkungen hinterlassen.

mfg
Christian

[paul_panzer]

@sledge0303

stellst du den patch online?

[paul_panzer]

naja... man kanns ja auch so machen wie ich es geschriebn hab wenn man unbedingt einen bestimmten kernel haben möchte ... mit den patches ist das ja immer sone sache...

mein kernel läuft auf den HG-Servern und auf den EG-Servern. Nur das nötigste ist drin... also 1a eigentlich

dieser patch dürfte immer funktionieren, da nur der inteltreiber gepatcht wird. glaube nicht das die kerneltreiber von heute auf morgen umbenannt werden

[sledge0303]

naja... man kanns ja auch so machen wie ich es geschriebn hab wenn man unbedingt einen bestimmten kernel haben möchte ... mit den patches ist das ja immer sone sache...

mein kernel läuft auf den HG-Servern und auf den EG-Servern. Nur das nötigste ist drin... also 1a eigentlich

Ob mit Patch oder reinkopiert, solange unter dem Strich ein brauchbares Ergebnis rausspringt ist die Vorgehensweise vollkommen legal-illegal-schei*egal

Die Kernel die ich veröffentliche kommen bei mir auch nicht zum Einsatz, hab neben grsec oder Xen-Patches noch andere selbstentwickelte 'Kleinigkeiten' drin.

[nebuzer]

naja... man kanns ja auch so machen wie ich es geschriebn hab wenn man unbedingt einen bestimmten kernel haben möchte ... mit den patches ist das ja immer sone sache...

mein kernel läuft auf den HG-Servern und auf den EG-Servern. Nur das nötigste ist drin... also 1a eigentlich

[sledge0303]

is der patch dann auch kompatibel mit den späteren kerneln?

Jein.

Ich werde in meinem Wiki ein kleines Tutorial zum Thema 'Wie ein Patchfile erstellt wird' schreiben
Wenn nichts dazwischen kommt, wird es am Wochenende online sein.

[larifari]

wie macht man sowas, is der patch dann auch kompatibel mit den späteren kerneln?

[sledge0303]

OK, du bist dann der 3.
Bin zwar etwas anders vorgegangen als nebuzer (mit erstelltem 'e1000.patch'), Resultat eindeutig und hab den Kernel Online gestellt.

Patche noch den 2.6.22.6-grsec und werde diesen dann ersetzen.

[larifari]

jop, klappt bei mir auch danke

[sledge0303]

Hab ebend die Bestätigung bekommen, der 1. Server fährt mit meinem gepatchten Kernel hoch. Stelle ihn dann online nachher ein, will noch den 2. Test abwarten.

[sledge0303]

obs bei euch auch geht weiß ich nicht, bei mir baut er jetzt aber ne netzwerkverbindung auf... vorher nicht! selbst techniker war ratlos was damit los ist

Hättest das ganze nicht 1 Stunde eher posten können?
Hab fast genau das selbe Ergebnis vorliegen und hoffe die Jungs kommen klar damit.

[larifari]

hab die .config mit make menuconfig erstellt, das sah so aus:

  │ │       Intel(R) PRO/1000 Gigabit Ethernet support
  │ │[*]       Use Rx Polling (NAPI)

das NAPI war ein unterpunkt von dem gigabit treiber, und eckige klammern bedeuten das M nicht geht

es wundert mich auch das das ding dort e100 reinschreibt, ich hatte in /etc/modules ganz unten noch eepro100 stehen, aber habs eben ohne gebootet, kommt genau das selbe...
habe jetz das in der /etc/modules stehen:

e1000
usb-uhci
usb-storage
input
usbkbd
keybdev

in der syslog steht bei mir nix, was auf e1000 hinweist.. hoffe du hast mehr glück, ich bin für heute durch, keine zeit mehr, drücke dir aber die daumen, bis moin

mfg

ps: das was nebuzer gemacht hat, habich gestern auch probiert, hatte aber die orginal makefile net angepasst hmm :O wenn das die lösung ist, dann platz ich ne andere frage ist, obs auch stabil läuft... "er baut eine verbindung auf" kann auch bedeuten das das ding mit 10mbit läuft

[nebuzer]

gelöscht

[sledge0303]

Dein dmesg sagt mir das hier:

#
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k4-NAPI
#
e100: Copyright(c) 1999-2006 Intel Corporation

Hast du rein zufällig e100 statt e1000 in /etc/modules eingetragen?

Was mir noch aufgefallen ist, ohne es bis jetzt selbst getestet zu haben:

CONFIG_E1000_NAPI=y

Sollte es nicht auch ein Modul (M) sein???

Schau mal in die Syslog rein

grep eth /var/log/syslog

Ich mach mich dann mal an die Arbeit

[larifari]

rescue:/mnt/var/log# find /mnt/lib/modules -name e1000.ko
/mnt/lib/modules/2.6.22.9/kernel/drivers/net/e1000/e1000.ko


rescue:/mnt/boot# grep E1000 /mnt/boot/config-2.6.22.9
CONFIG_E1000=m
CONFIG_E1000_NAPI=y
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set

in /proc ist nix drin (hab rescue laufen also /mnt/proc)

in meinem letzten post istn link zu meiner /var/log/dmesg

[sledge0303]

Was sagen denn folgende Ausgaben:

find /lib/modules -name e1000.ko

Dazu noch

grep E1000 /boot/config-2.6.22.X
zgrep E1000 /proc/config.gz

X=deine Kernelversion!

[larifari]

okay, hab den neuen kernel mit dem integrierten e1000 treiber als modul kompiliert, und dann restartet um den neuen e1000 treiber zu kompilieren. es hat auch geklappt, hab den treiber nun da, hab auch in /etc/modules "e1000" an die erste stelle gesetzt, restartet, und nix geht...

edit:
das steht in /var/log/dmesg:
http://paste-it.net/yced84c

[larifari]

so, den treiber halte ich nun in meinen händen! leider ging die kiste net hoch, ich schätze mal weil ich vergessen habe, den alten treiber vor dem kompilieren des kernels rauszuhauen... der ist jetz fest im kernel drinne, netmal als modul, wodurch er wohl bevorzugt wird. ich teste es gleich nochmal

[sledge0303]

hab mir mal etwas gedanken gemacht. man könnte den neuen kernel fertig zum starten machen (aber ohne netzwerktreiber kompilieren!), dann ein skript einbinden, welches beim start ausgeführt wird, und den treiber kompiliert. dann könnte man rescue booten, den treiber manuell in /lib/modules/xxx... verschieben, /etc/modules anpassen, und testen ob das teil hochfährt...

wäre das eine option? hat die schon jemand probiert?
einpatchen klingt für mich sehr nach fehleranfälligkeit, die fehler könnten sich sofort zeigen, aber auch erst später im laufenden betrieb...

Du kannst auch ein bestehendes Image installieren, der bestehende Treiber wird überschrieben. Das Skript nach /etc/int.d ausführbar schreiben, es in den Runlevel 2 verlinken als S91skript.sh, e1000 in /etc/modules eintragen und anschließend die Kiste einen reboot verpassen oder '/etc/init.d/notworking restart' ausführen lassen.
Wenn du jetzt Zeit hast, kannst es ausprobieren und hast u.U. die Lösung parat bevor ich nach Hause komme und erst anfange.

[larifari]

hab mir mal etwas gedanken gemacht. man könnte den neuen kernel fertig zum starten machen (aber ohne netzwerktreiber kompilieren!), dann ein skript einbinden, welches beim start ausgeführt wird, und den treiber kompiliert. dann könnte man rescue booten, den treiber manuell in /lib/modules/xxx... verschieben, /etc/modules anpassen, und testen ob das teil hochfährt...

wäre das eine option? hat die schon jemand probiert?
einpatchen klingt für mich sehr nach fehleranfälligkeit, die fehler könnten sich sofort zeigen, aber auch erst später im laufenden betrieb...

[sledge0303]

Hoffe wir mal das du eine Lösung hast heute abend ich kann mein Server seit dem 21.9.07 nicht nutzen wegen dieses problem

@angie
wieso wird der kernel einfach nicht offen gelegt für jeden mit config,so könnten viel mehr leute helfen ( also zum downloaden )

Den Patch kannst du nur installieren wenn der zu patchende Kernel rennt und wenn die Kiste keine Netzwerkverbindung aufbauen kann...
Daher muss eine andere Lösung her.
Daher lautet das Ziel, den Patch entweder direkt in die Sourcen einzupatchen oder eine es gilt eine andere Möglichkeit zu finden den Patch beim ersten hochfahren des Servers mit dem verwendeten Kernel installieren zu lassen.

Wenn man physikalischen Zugang zum Server hätte, wäre es kein Problem!
Aber wir haben keinen physikalischen Zugang, da müssen wir uns was einfallen lassen

In 2 Stunden bin ich in etwa zu Hause und dann wird geplant wie es am saubersten umsetzbar ist. Keine Panik!

[Betaman2k]

Genau aus dem Grund muss auch die Kernelsource gepatcht werden, sonst wird es höchstwahrscheinlich auch nicht klappen.
Ich hoffe, wenn es die Zeit zulässt, heute Abend dafür eine Lösung präsentieren zu können.

Hoffe wir mal das du eine Lösung hast heute abend ich kann mein Server seit dem 21.9.07 nicht nutzen wegen dieses problem

@angie
wieso wird der kernel einfach nicht offen gelegt für jeden mit config,so könnten viel mehr leute helfen ( also zum downloaden )

[erazorlll]

Vielen Dank an OVH!
Gestern Nacht wurde das Mainboard noch von einem Techniker getauscht. Hab natürlich gleich das etch from scratch HowTo ausprobiert und lief alles ohne Probleme. Netboot ging ... Reboot ging ... Kiste läuft

Danke an OVH für den super Support und an sledge für seine Hilfe!

[sledge0303]

wieso stellt ovh nicht eine anleitung in ihr wiki rein. die kennen doch schon den lösungsweg...

gruß larifari

Ich kenne auch den Lösungsweg, doch zwischen lösen und dessen Umsetzung liegt noch eine (kleine) Barriere.
Erstmal muss der Kernel stehen, ein Tester dafür gefunden werden und wenn der sagt klappt 1a, dann wird die Lösung für alle zugänglich gemacht.

[larifari]

alles klar, dann drück ich mal die daumen für dich
ich bräuchte, und da bin ich wohl nicht der einzige, dann eine kleine anleitung, damit ich es selber patchen kann, um mir meinen eigenen, nach meinen wünschen gestalteten, kernel zu kompilieren.
wieso stellt ovh nicht eine anleitung in ihr wiki rein. die kennen doch schon den lösungsweg...

gruß larifari

[sledge0303]

laut README des treibers soll der laufende kernel auch der kernel sein, für den dieser treiber kompiliert werden soll, dann kann man das ding als modul kompilieren, und es dann wohl über /etc/modules beim hochfahren einbinden.
aber kann mir einer erklären, wie ich meinen kernel, für den dieser treiber sein soll, zum starten kriege, und zwar mit NIC, damit ich DANN den treiber kompilieren kann? mein kernel startet ja quasi ohne NIC, somit komm ich garnich zum kompilieren!

Genau aus dem Grund muss auch die Kernelsource gepatcht werden, sonst wird es höchstwahrscheinlich auch nicht klappen.
Ich hoffe, wenn es die Zeit zulässt, heute Abend dafür eine Lösung präsentieren zu können.

[larifari]

hi, habe auch das problem mit der e1000, mein kernel lässt sich einfach nicht booten. hab schon heute morgen daran gedacht, den aktuellen e1000 treiber zu kompilieren wie es angie nun auch schrieb:

Für die Server EG/MG die kernel selbst backen wollen:
http://e1000.sf.net die letzte Version: e1000-7.6.5 muss in den Kernel rein.
[B]

laut README des treibers soll der laufende kernel auch der kernel sein, für den dieser treiber kompiliert werden soll, dann kann man das ding als modul kompilieren, und es dann wohl über /etc/modules beim hochfahren einbinden.
aber kann mir einer erklären, wie ich meinen kernel, für den dieser treiber sein soll, zum starten kriege, und zwar mit NIC, damit ich DANN den treiber kompilieren kann? mein kernel startet ja quasi ohne NIC, somit komm ich garnich zum kompilieren!
falls es mit vkvm gehen sollte, wirds sowieso scheitern, denn ich hab vkvm bis jetzt noch nie zum starten gebracht, immer "connection refused" oder was für ne fehlermeldung da auch immer kam, weiß nichmehr genau.

wenn ich den neuesten kernel auf meinen alten root, mit anderer hardware kompiliere, und dort dann den e1000 treiber kompiliere, und ihn später auf den EG L werfe, würde er dann laufen?

Gruß larifari

[sledge0303]

Hi Angie,

genau das hab ich ja gemacht mit dem Patchen, nur meinen Kernel 2.6.22.8 mit dem e1000-7.6.5 Patch hat offensichtlich noch niemand getestet bzw hat noch niemand eine Rückmeldung geliefert...

Will den Patch noch etwas anpassen und stelle ihn dann zum download für alle bereit. Vielen Dank wenigstens an Dich für die Rückmeldung
Wenn der Netbootkernel in Roubaix nicht upgraded wurde ist es auch kein Wunder dass das nicht klappen konnte.

Jetzt nehm ich erstmal meine Kiste vom Netz, der Test mit XeN ist erfolgreich abgeschlossen worden. Für das Wiki-Projekt, hatte es dir ja in einer Mail angekündigt, wird dann der volle Speicher benötigt.
Es wird demnächst hier ein kleinen Erfahrungsthread diesbezüglich geben.

Gruss Thomas

[Angie]

Re,

also jetzt sind wir schon mal ein Stück weiter.
Das Problem der EG/MG die Server müssten jetzt auf jeden Fall mal netbooten können. Einer unser Kernelmaster hat wohl vergessen die Kernel von Bootserver in Roubaix upzudaten. Das ist nun getan.


Für die Server EG/MG die kernel selbst backen wollen:
http://e1000.sf.net die letzte Version: e1000-7.6.5 muss in den Kernel rein.

Für die Server mit Unknown device im lspci

wget http://pciids.sourceforge.net/pci.ids
 lspci -i pci.ids

das dürfte dann die fehlenden Infos anzeigen.

Server die Probleme mit der Netzwerkkarte haben:
diese cmd ausführen:

dmidecode | grep P5

Sollte hier dieses Resultat erscheinen:

Version: ASUS P5VD2-VM ACPI BIOS Revision 1105
Product Name: P5VD2-VM

dann bitte Support anschreiben. Wir wechseln die Karte aus.


So und jetzt sehen wir mal ob wir ein Stück weiter kommen.

Sledge: zur Info das Stecker rausziehen hat geklappt ... nur blieb der Server dann am Netboot hängen : wegen dem Bootserver der nicht uptodate war.


Gruss,
Angie

[Betaman2k]

Hoffe das bald der Bug weg ist,weil ich kann mein Server nicht nutzen seit den 21.9.2007 ( bin neukunde ) wegen der Netwerkkarte
Wie wird es iegendlich gemaged bekommt man die zeit gutgeschrieben wenn man den server nicht nutzen kann ?

[mathias]

Hallo,

ich habe einen MG Server mit einer 1 GBIT Anbindung, kriege per Apache aber nur maximal 300kB/s liegt das Problem bei mir oder an der Netzwerkkarte ?

Genau, wir benötigen einen =>FTP<= Downloadlink, Traceroutes von Server zu PC und umgekehrt und die Info, ob wir den Server down nehmen können. Ein Backup sollte natürlich auch vorhanden sein, man weiß ja nie. Einfach per Mail an den Support schicken.

Mathias

[sledge0303]

Hallo,

ich habe einen MG Server mit einer 1 GBIT Anbindung, kriege per Apache aber nur maximal 300kB/s liegt das Problem bei mir oder an der Netzwerkkarte ?

Am besten stell mal ein File zum downloaden bereit --> etwa 100MB.

[flosoft]

wohl eher nicht an der Netzwerkkarte. Da hat man hier andere symptome.

[RalfW]

Hallo,

ich habe einen MG Server mit einer 1 GBIT Anbindung, kriege per Apache aber nur maximal 300kB/s liegt das Problem bei mir oder an der Netzwerkkarte ?

[sledge0303]

Hallo,

gerade live aus dem Rechenzenter:

habe jemanden der Debian installieren wollte.
Festplatte booten: geht nicht
Netboot geht auch nicht
Hardware boot gemacht: strom unterbrechung, geht auch nicht.
Ich bin 100 % sicher wenn ich jetzt dem Technicker sage er soll den Stecker ziehen und dann nochmal anschliessen: dann fährt die Kiste hoch.

Ich werd mal testen.

Angie

Und... hat es so funktioniert? Wenn ja wäre man wieder ein riesenstück weiter gekommen.
So ähnlich war es mal bei meinem alten Desktoprechner gewesen, der wollte manchmal nach einem soft-reboot auch nicht so richtig. Da war ein Fehler im BIOS die Ursache gewesen. Gibt es für dieses BIOS ein Update?

Gruss Thomas

Nachtrag: hast du zufällig die Bezeichnung des Boards zur Hand?

[Angie]

Hallo,

gerade live aus dem Rechenzenter:

habe jemanden der Debian installieren wollte.
Festplatte booten: geht nicht
Netboot geht auch nicht
Hardware boot gemacht: strom unterbrechung, geht auch nicht.
Ich bin 100 % sicher wenn ich jetzt dem Technicker sage er soll den Stecker ziehen und dann nochmal anschliessen: dann fährt die Kiste hoch.

Ich werd mal testen.

Angie

[sledge0303]

Hallo,

das Problem ist das wir hunderte solcher Server haben und das nicht alle das machen. Deshalb wurden schon jede Menge dieser Karten verbaut.
Wir haben also mal 20 Server aus der Prodution direkt testgefahren und siehe da: es scheint am Strom zu liegen. Immer wenn wir den Strom richtig kappen, dann funktionieren diesen doofen Dinger.
Machst du zum Beispeil Softboot auf Rescue oder neuem Kernel: geht nix mehr.
Dann kommen auch noch welche dazu die einfach ausgehen und andere die garkeine Probleme haben.

Intel hat die ganzen Informationen und wir warten jetzt auf Antwort.

Gruss,
Angie

Hi Angie,

die Theorie mit der Stromversorgung hab ich auch schon im Hinterkopf gehabt.
Wobei ich eher schon dazu tendiere zu sagen, wenn es schon nicht am Kernel liegt, diese Mainboardserie von Intel könnte Ausschuss sein. Ja ich weiss, zwischen Theorie und Praxis liegen meistens Welten.
Jedenfalls hab ich die Kernel mit den letzten Intelpatches versorgt, Makefiles angepasst und anschließend gebetet keinen Fipptehler im Make drin zu haben.

Die Kernel erkennen auch die Hardware nur wird die NIC offensichtlich nach Lust und Laune gestartet.
Der andere User mit dem ich Kontakt stehe hat wirklich die Kiste komplett runtergefahren, euer Techiker wieder eingeschaltet und siehe da - Kiste war sofort online!
Spricht für deinen Beitrag betreffs Stromversorgung.

Leider kriegt man diese Informationen immer nur 'kleckerweise' und das Ende vom Lied ist: es hat trotz neuer 'Lernerfolge im Umgang mit solchen Problemen' am Ende evtl. doch nicht viel weiter gebracht
Trotzdem nochmal meinen Dank an alle für die Unterstützung..

Gruss Thomas

[Angie]

Hallo,

das Problem ist das wir hunderte solcher Server haben und das nicht alle das machen. Deshalb wurden schon jede Menge dieser Karten verbaut.
Wir haben also mal 20 Server aus der Prodution direkt testgefahren und siehe da: es scheint am Strom zu liegen. Immer wenn wir den Strom richtig kappen, dann funktionieren diesen doofen Dinger.
Machst du zum Beispeil Softboot auf Rescue oder neuem Kernel: geht nix mehr.
Dann kommen auch noch welche dazu die einfach ausgehen und andere die garkeine Probleme haben.

Intel hat die ganzen Informationen und wir warten jetzt auf Antwort.

Gruss,
Angie

[sledge0303]

8169 gibt es onboard sowie als karte.

Die ganze Geschichte ist eh etwas merkwürdig. Siehe hier und wenn ich nicht selbst gesehen hätte...
Bei mir wurden trotz der ständig absaufenden Realtekkarten diese erkannt. Schau dir mal die lspci Ausgaben an die in letzter Zeit gepostet wurden:

Beispiele:

Intelboard mit Realtek

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Unknown device 8168 (rev 01)

Asusboard mit Realtek

04:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Unknown device 8167 (rev 10)

Intelboard mit e1000 Treiber

00:19.0 Ethernet controller: Intel Corporation Unknown device 294c (rev 02)

Alle Ausgaben zufolge wurden die Kisten mit dem OVH Standardimages installiert, hochgefahren und die lspci Ausgaben erstellt.

Linux nsxxxxx.ovh.net 2.6.21.5-grsec-xxxx-grs-ipv4-32 #4 SMP Tue Aug 28 15:51:51 CEST 2007 i686 GNU/Linux

Jedenfalls, da bin ich mir sicher, wird sich OVH allen genannten Problemfällen annehmen und entsprechende Lösungen anbieten. Mir jedenfalls fehlt die Zeit/Lust mich vorerst weiter damit auseinanderzusetzen.
Sorry dafür, aber es ist besser so, glaubt mir

Außerdem macht es sich extrem schlecht nicht alles persönlich testen zu können.

[paul_panzer]

Ich besitze auch einen Server mit diesen Realtek Karten. Denke mal dass das keine OnBoard Chips sondern schon ne richtige Karte ist?! Wäre es möglich die Karte zu tauschen?

8169 gibt es onboard sowie als karte.

[erazorlll]

Ich besitze auch einen Server mit diesen Realtek Karten. Denke mal dass das keine OnBoard Chips sondern schon ne richtige Karte ist?! Wäre es möglich die Karte zu tauschen?

[sledge0303]

Hi Angie,

Die Kisten mit Intel 1Gbit fahren hoch, die NIC stürzt entweder unmotiviert ab oder wird gar nicht erst gestartet. Hab es live auf 2 Kisten visuell erleben können.
Mit den Netbootkerneln 2.6.21/2.6.22 sowie vKVM wird die NIC gar nicht erst gestartet. Mit den Kernel aus euren Images klappt es, aber die Ausgabe sieht dann so aus:

00:19.0 Ethernet controller: Intel Corporation Unknown device 294c (rev 02)

Das Problem mit den Realtekkarten 8168/8169 kann ich bestätigen. Bei mir sind die umgehend durch andere ersetzt worden.


Gruss Thomas

[Angie]

Hallo sledge,

ich bin nicht sicher ob hier jetzt nicht alles durcheinander gekommen ist, aber es gibt da ein Problem mit den Realtekkarten.

Liegt nicht am Kernel und kommt sporatisch vor.
Intel hat uns das Problem bestätigt und wir warten nun auf Feedback.

Gruss,
Angie

[sledge0303]

Hallo,

ich hab einen neuen Kernel erstellt mit gepatchten Treibern für die Intel Netzwerkkarte 1Gbit. Bezeichnung im Kernel: e1000
Wer diesen Kernel testen möchte (2.6.22.8):

DEB-File wie gewohnt installieren und Kernel in den Bootmanager eintragen.

Danach noch vorsichtshalber das zu ladene Modul eintragen in /etc/modules

echo 'e1000' >> /etc/modules

Danach reboot. Sollte die Kiste wider erwarten nicht hochkommen, im Rescue hochfahren und den alten Kernel wieder zum starten eintragen. Vor dem reboot bitte noch folgende Ausgabe der Befehle sichern (Rescuesystem) und hier posten:

grep eth /mnt/var/log/dmesg.0
zgrep eth /mnt/var/log/dmesg.1.gz

Ich hoffe, dass das nicht mehr erforderlich sein wird...

[sledge0303]

*** Funzt leider noch nicht wie gewünscht auf allen Systemen ***

Wieso das ganze? Der Intel 'e1000' enthält einen Bug!

Problem besteht darin, der Server muss zur Einspielung des Patches mit dem Kernel hochgefahren werden mit dem anschließend der Server permanent läuft.
Es werden noch Möglichkeiten getestet, die Treiber in den Kernel einzupatchen oder den Patch beim ersten Systemstart per Skript installieren zu lassen. Genau das schlug leider fehl und sollte hier vorgeschlagen werden als vorläufiges workaround


Thread dient als Platzhalter, bitte nicht löschen.