Hi all,

This is a problem I read about a lot in the forums but nobody seems to have found a solution yet. I could limit the problem to a few items and now I am looking for an idea how to compensate it.

I have a mixture of a 10 MBit and 100 MBit network here, some clients being connected to 10 MBit Hubs and four of them connected to a 100 MBit Hub. These Hubs are all connected with a switch that makes the line to the server.

I set up a server on an ASUS board with an onboard gigabit Intel controller, the module loaded for it is e1000. It adjusts to 100 MBit fullduplex on the switch if you do not give it any options.

Now the problem is that with such a configuration, all the terminals that have 10 MBit connections will get a DHCP answer, load up their kernels and then hang when it comes to "pivot_root". After a while they will note they are "still looking for a server".

The four clients connected to the 100 MBit Hub will go through without any problems.

I tried to adjust some settings on the server's gigabit network adapter and found that with setting it to 10 MBit halfduplex all clients will connect as desired.

Of course, this is just ok for testing, not for a real working state.

Before setting up this server I tried everything with an old machine having a cheap 100 MBit fullduplex Realtek card. Here everything just worked fine, never had a problem with it.

So what I found out in searching through the forums was that this might be a problem of false packets or falsely expected packets in the communication between nfs and the network card module. It might be a problem of the switch as well, as this might be a switching hub rather than a real switch.

Yes, I could disable the onboard controller and use this Realtek card, but it wouldn't satisfy completely as the Intel controller is way better for the server than the cheap one as far as I know.

Isn't there anyone who could find a solution to tweak the communication between nfs and the network so it runs fine? After all, this is Linux...

Thx for all ideas!

Rolf



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net

Reply via email to