In message [off-list ref] you wrote:
I don't believe the "neighbour table overflow" errors are the problem. I
get them frequently but otherwise have success.
I have never seen such errors when the ethernet inrface is working
correclty.
It looks like a problem on your nfs server. The "unable to get nfsd port
number from server" and "unable to get mountd port number from server"
messages indicate that at minimum, the portmapper is not running on your
server. Perhaps mountd and/or nfsd are also not running.
Well, IMHO it's more likely that no packets were ever sent to the
ethernet at all. This type of problemppens for instance when the
Transmit Enable signal is not asserted.
It might be useful to check with a sniffer if the box is transmitting
at all...
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Don't put off for tomorrow what you can do today, because if you
enjoy it today you can do it again tomorrow.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Tue, 21 Mar 2000, Wolfgang Denk wrote:
In message [off-list ref] you wrote:
quoted
I don't believe the "neighbour table overflow" errors are the problem. I
get them frequently but otherwise have success.
I have never seen such errors when the ethernet inrface is working
correclty.
From a boot this morning on an MVME-2307:
eth0: DC21140 at 0x11000 (PCI bus 0, device 14), h/w address 08:00:3e:2a:1d:42,
and requires IRQ18 (provided by PCI BIOS).
de4x5.c:V0.544 1999/5/8 davies@maniac.ultranet.com
Looking up port of RPC 100003/2 on 131.225.84.99
neighbour table overflow
eth0: media is TP.
Looking up port of RPC 100005/1 on 131.225.84.99
VFS: Mounted root (NFS filesystem) readonly.
. . .
I almost always get this single "neighbour table overflow" message, but
subsequently no ethernet problems.
quoted
It looks like a problem on your nfs server. The "unable to get nfsd port
number from server" and "unable to get mountd port number from server"
messages indicate that at minimum, the portmapper is not running on your
server. Perhaps mountd and/or nfsd are also not running.
Well, IMHO it's more likely that no packets were ever sent to the
ethernet at all. This type of problemppens for instance when the
Transmit Enable signal is not asserted.
It might be useful to check with a sniffer if the box is transmitting
at all...
Wolfgang Denk
I definitely agree. tcpdump on the nfs server (or strace on
rpc.mountd/rpc.nfsd tasks) would do the trick.
Don Holmgren
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
The tcpdump during the boot sequence shows me the error. I see at the
host the packets during tftp download of the zImage file. As the NFS
client try to connect i see nothing. So i changed the default setting
for ethernet from SCC2 to SCC1 (as described in the manual for the board
:-) and it
works.
Wolfgang Denk wrote:
In message [off-list ref] you wrote:
quoted
I don't believe the "neighbour table overflow" errors are the problem. I
get them frequently but otherwise have success.
I have never seen such errors when the ethernet inrface is working
correclty.
quoted
It looks like a problem on your nfs server. The "unable to get nfsd port
number from server" and "unable to get mountd port number from server"
messages indicate that at minimum, the portmapper is not running on your
server. Perhaps mountd and/or nfsd are also not running.
Well, IMHO it's more likely that no packets were ever sent to the
ethernet at all. This type of problemppens for instance when the
Transmit Enable signal is not asserted.
It might be useful to check with a sniffer if the box is transmitting
at all...
Thanks,
Stephan Ruettiger
------------------------
Stephan Ruettiger
Motorola Munich
r0337c@email.sps.mot.com
------------------------
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/