[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NFS Mount-Problem -> Kernel rekompilieren



On Thu, 2005-04-21 14:30:02 +0200, pascal@kordt.net <pascal@kordt.net> wrote:

> Das Problem: Bei älteren Computern, die ich als ThinClients nutzen will,
> bricht der Bootvorgang mit folgender Meldung hab:
> 
> Doing the pivot_root
> nfs: server 192.168.0.254 not responding, still trying
> nfs: server 192.168.0.254 not responding, still trying
> nfs: task 82 can’t get a request slot
> 
> Unter
> http://wiki.ltsp.org/twiki/bin/view/Ltsp/Troubleshooting-mount-problems
> habe ich FAQs zu diesem Problem gefunden. Es kann u.a. auftreten, wenn
> man Netzwerkkarten mit verschiedenen Geschwindigkeiten benutzt.

Das habe ich so nicht auf der von Dir genannten Seite finden können. Wie
sieht denn Deine Verkabelung und Netzwerkkarten-Konfiguration aus?
Insbesondere interessiert mich:

	- Genauer Typ der Netzwerkkarte in Client und Server (hier
	  insbesondere die Beschriftung des größten Chips der Karte und
	  der Name des benutzten Treibers)
	- Wie sind die beiden Karten miteinander Verkabelt? Die
	  "verschiedenen Geschwindigkeiten" halte ich für wackelig.
	  Niemand wird erwarten, daß eine Karte, die fix auf 10MBit/sec
	  HD konfiguriert ist, mit einer spricht, die auf 100MBit/sec HD
	  eingestellt ist.  Sind die mit einem Hub oder Switch
	  verbunden? Was für einer?
	- Bekommen die Kartentreiber beim Laden als Modul irgendwelche
	  Parameter mit? Wenn ja, welche?
	- Wenn die Treiber dafür fest einkompiliert sind, welche
	  Kernel-Kommandozeile wird benutzt?
	- Benutzt Du immernoch diesen steinalten 2.4.16?  In 2.4.27 (die
	  Sourcen davon hab' ich gerade liegen) kann ich die "task xxx
	  can't get a request slot"-Meldung schon garnicht mehr finden.

> Mein Netzwerk besteht bei diesem Test nur aus einem kombinierten Main-
> plus ThinClient-Server sowie einem ThinClient. Die Bootdiskette von
> rom-o-matic ist okay, die (PCI-) Netzwerkkarte wird erkannt. Wenn ich
> die Netzwerkkarte in einen anderen (neueren) Computer einsetze,
> funktioniert alles einwandfrei.

Was für eine "PCI-Netzwerkkarte" ist denn das? Insbesondere, wenn auf
dem größten Chip darauf ein kleiner Krebs abgebildet ist, kann es sein,
daß Du mit 2.4.16 einfach zu alt bist...

Der Thin-Client hat ja schon eine IP-Adresse bekommen. Kannst Du den vom
Terminal-Server aus anpingen? Geht das auch mit großen Ping-Paketen
(ping -s ...)?

> Ich gehe deshalb davon aus, dass die älteren Computer, obwohl sie
> bereits PCI-Steckplätze haben, für diese Slots nicht die
> Geschwindigkeit unterstützen, wie die neuen.

Wenn die Karte erkannt wird, hat sie zu funktionieren. Das PCI-System
"schützt" sich gegen zu neue Karten; selbst, wenn (warum auch immer)
der PCI-Bus in den Client-Rechner urs-langsam angebunden ist und
100MBit/sec nicht bringt, würde die Verbindung nur langsam werden, aber
nicht derart zusammenbrechen.

> Entsprechend der o.g. FAQ wollte ich das Problem beheben. Eine
> Möglichkeit besteht darin, in der Datei /linuxrc im Abschnitt "Mounting
> root filesystem“ die Variablen rsize und wsize auf einen kleineren Wert
> zu setzen, sodass die UDP Paketgröße reduziert wird. Ich gehe davon

...was zu einer deftigen Performance-Einbuße führt.

> aus, dass diese Datei vom Server geladen wird, ist das richtig? Ich

Eher nicht; die ist vermutlich in einer kleinen initrd mit auf der
Floppy.

> wollte auch auf der Bottdiskette nach der Datei suchen, aber es ist mir
> nicht gelungen, die Diskette zu mounten. Auf der Festplatte des Servers
> konnte ich auch keine Datei finden, die den Text „Mounting root
> filesystem“ enthält. Wo finde ich die Datei?

Aller Wahrscheindlichkeit nach auf der Floppy.

> Da noch eine zweite Möglichkeit genannt war, wollte ich diese
> Möglichkeit ausprobieren. Dabei handelt es sich um eine Veränderung am
> Server. In der Datei include/linux/nfsd/const.h soll die Variable
> NFSSVC_MAXBLKSIZE auf einen kleineren Wert gesetzt werden. Da diese
> Datei in dem genannten Pfad auf meinem Server nicht existierte, habe
> ich die Fesplatte nach const.h durchsucht und die Datei unter dem Pfad
> /usr/include/linux/nfsd gefunden. Die beschriebene Änderung habe ich
> vorgenommen. Danach sollte ein rekompilieren des Kernels notwendig
> sein. Ist die Datei die richtige? Ist das rekompilieren notwendig, bzw.

Nein. (Die Erklärung dessen spare ich mir, das würde länger werden...)

> wird diese Datei beim rekompilieren eingebunden? (Ohne gibt es keine
> Änderung.)

Das _willst_ Du nicht. Wenn Du an der [rw]size rumschrauben möchtest,
dann, um _größere_ Werte einzutragen.

> Um den Kernel rezukompilieren bin ich dann mit Speicherstift ins
> Internetcafé gefahren um mir die kernel-source runterzuladen. Dabei bin
> ich auf einem Motorrad mitgenommen worden und der Zettel, auf dem ich
> mir die Version notiert hatte, ist weggeflogen. :-) Deswegen habe ich
> dann 2.4.16 statt 2.4.26 runtergeladen. Hat der in der letzten Mail
> beschriebene Fehler damit zu tun? Wenn nicht, woran kann es sonst
> liegen?

Ich habe folgende Vermutungen:

	- Kernel zu alt, Karte von Realtec mit schön vielen Bugs in der
	  Hardware, um die der Treiber (welcher eigentlich? Diese Karte
	  hat je nach Kernel-Version mehrere Treiber...) noch nicht
	  herumarbeitet.
	- Falsche (sprich: forcierte) Geschwindigkeits- oder
	  Duplex-Einstellungen
	- Falsche PCI-Konfiguration des Client-Rechners
	  (BIOS-Einstellungen prüfen, ev. aktuelles BIOS einflashen).

Deine Probleme liegen aber definitiv _nicht_ an einer schlecht
eingestellten rsize oder wsize. Diese Werte beeinflussen nur, nach
wieviel Daten die Gegenseite den erfolgreichen Empfang bestätigen muß.
Ich sehe hier eher Probleme, überhaupt Daten aus der Karte
herauszubekommen, daher auch mal mit ping (und ping -s) testen.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Attachment: signature.asc
Description: Digital signature


Reply to: