From: Tupshin Harper <tupshin@tupshin.com>
To: netdev@oss.sgi.com
Subject: FW: gigabit ethernet, nfsroot, jumbo packets, questions, and bugs (2.6.0-test9)
Date: Fri, 14 Nov 2003 13:20:07 -0800 [thread overview]
Message-ID: <3FB54707.5030102@tupshin.com> (raw)
Forwarded from lkml by request:
I'm trying to set up a diskless testbed using gigabit ethernet, and I'm
running into a few issues. First, the scenario:
One client, and one server each with an smc EZCard 1000.
Kernel 2.6.0-test9 with the sk98lin driver on both sides
Client has kernel compiled with sk98lin built in, and nfsroot and dhcp
autoconfig built in.
Client is getting bootstrapped off a hard drive (for now, since
etherboot doesn't support the driver yet) with grub loading the nfsroot
kernel from disk, and then mounting nfsroot by adding root=/dev/nfs
What works:
Everything basic.
What doesn't:
Above scenario with Jumbo packets (MTU = 9000 or anything above 1500)
For performance reasons, I'm wanting to use large packets(the switch
between the devices supports it, and jumbo packet communication works
fine in the non-diskless scenario).
Questions:
1) Is there a good way to set the MTU of the client via dhcp or by
passing a parameter to the kernel?
2) If server is set to 9000 MTU and client is set to 1500 MTU, should
complete failure ensue(e.g. nfs times out indefinitely), or should some
autonegotiation take place? If there should be autonegotiation, then it
isn't working.
Definite Bug:
If the server is set to 9000 MTU, ifconfig down, and ifconfig up with
default MTU doesn't work. Ifconfig then claims that the card is set to
1500 MTU, but it is unable to communicate with the client until module
is unloaded and reloaded, even though MTU is an ifconfig parameter and
not a module parameter. I'm presuming that MTU has not actually been set
back to 1500, but I don't know of an easy way to tell if that's the case
when ifconfig appears to be lying to me.
-Thanks
-Tupshin
reply other threads:[~2003-11-14 21:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FB54707.5030102@tupshin.com \
--to=tupshin@tupshin.com \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).