cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
6,284 Views
Registered: ‎02-25-2009

Kernel 2.6 fail in NFS with xps_ethernetlite

My system on a ML 410 board (V4FX60) is very basic: 256M ddr with MPMC, xps_ethernetlite ... build with BSB in EDK 11.1. The cable into the Marvell ethernet Phy is from a 100M switch (so xps_ethernetliet should work).

 

My kernel (version 2..6.29 got from git tree at http://git.xilinx.com) boot up command is:  "root=/dev/nfs nfsaddrs=10.0.10.1:10.0.1.16:10.0.0.1:255.255.0.0 rw nfsroot=/exports/rootfs console=ttyS0,38400" with which I have no problem in booting up a 2.4 Kernel using NFS (with plb_ethernet though, the 2.4 kernel I get, as in the BYU project, does not support xps_ethernetlite ip).

 

I get the message:

  xilinx_emaclite 81000000.ethernet: Device Tree Probing 'ethernet'
  xilinx_emaclite 81000000.ethernet: MAC address is now  2: 0: 0: 0: 0: 0
  xilinx_emaclite 81000000.ethernet: using fifo mode.
  eth0 (): not using net_device_ops yet
  xilinx_emaclite 81000000.ethernet: Xilinx EMACLite at 0x81000000 mapped to 0xD1020000, irq=17
  mice: PS/2 mouse device common for all mice
  TCP cubic registered
  NET: Registered protocol family 17
  RPC: Registered udp transport module.
  RPC: Registered tcp transport module.
  IP-Config: Complete:
       device=eth0, addr=10.0.10.1, mask=255.255.0.0, gw=10.0.0.1,
       host=10.0.10.1, domain=, nis-domain=(none),
       bootserver=10.0.1.16, rootserver=10.0.1.16, rootpath=

  Looking up port of RPC 100003/2 on 10.0.1.16
  Looking up port of RPC 100005/1 on 10.0.1.16
  rpcbind: server 10.0.1.16 not responding, timed out
  Root-NFS: Unable to get mountd port number from server, using default

  Root-NFS: Server returned error -5 while mounting /exports/rootfs
  VFS: Unable to mount root fs via NFS, trying floppy.

  VFS: Cannot open root device "nfs" or unknown-block(2,0)
  Please append a correct "root=" boot option;

 

(With Kernel 2.4 and PLB_Ethernet, NFS can be mounted after "looking up port")

 

Then I tried downloading a ime file which contains  a RamDisk but has the same boot command. Again, NFS fail, but the kernel boots up on the root file system provided by the RamDisk, with the message:

  IP-Config: Complete:
       device=eth0, addr=10.0.10.1, mask=255.255.0.0, gw=10.0.0.1,
       host=10.0.10.1, domain=, nis-domain=(none),
       bootserver=10.0.1.16, rootserver=10.0.1.16, rootpath=

 

Since the IP-Config seems to be complete, I try to "ping" the IP of the board (10.0.10.1) from another machine A (10.0.1.16) in the domain - the board can not be pinged by A with the error "Destination Host Unreachable". Then I use the board to ping another machine B (10.0.1.18) in the domian. It turned out B can be pinged by the board. After board get response from B, wiredly A is able to get response from the board suddenly.

 

Why initially no machine can ping the board, but after the board pings a machie, other machines can ping the board? Does the command "ping" do something like resetting Phy?

 

Given that "ping" has a problem, I should not be supprised that NFS fail. But how should I solve it? Am I using the wrong boot up command for NFS? Is the kernel compilation missing something? Is it a bug with regard to the 2.6 kernel drivers for xps_ethernetlite?

 

 

 

Message Edited by wenweizha on 07-13-2009 02:50 PM
0 Kudos
3 Replies
Highlighted
Xilinx Employee
Xilinx Employee
6,276 Views
Registered: ‎09-10-2008

I haven't seen this behavior as I'm testing with NFS root right now with emaclite and 11.2 h/w.  If I remember right, the ML410 has a bad phy interface as I don't think it supports GMII if I remember right. It seems like it had to be RGMII.  I test on the ML507 which uses GMII.

 

I'll watch for this problem to see if I can replicate it.

 

There is a new flat driver in the develpment branch of the kernel tree.  I haven't been testing with it much lately, but did before I put it into the branch. I plan to replace the old driver with this one soon.

 

This driver doesn't do anything with the emac PHY as the h/w didn't have a PHY interface til recently and the driver's not using it yet.

 

Thanks,

John

0 Kudos
Highlighted
Contributor
Contributor
6,268 Views
Registered: ‎02-25-2009

I can replicate the problem with a smaller board, Digilent's FX12 evaulation board.

 

Here is one more experiment:

  1) Initially, after the board boots up, a machine A can not ping the board;

  2) Rather than pinging the machine A from the board, I execute "rdate -sp 206.246.118.250" (weirdly, the system date is not updated ...). Then the machine A is able to ping the board.

 

 

I try to mount NFS after booting up with RamDisk. I can ping 10.0.1.16 but I can not mount the directory (the settings on 10.0.1.16 is good since I'm always able to boot Kernel 2.4 with NFS).

1)  if I do "mount 10.0.1.16:/exports/rootfs /mnt/temp", I get error

      rpcbind: server localhost not responding, timed out

       RPC: failed to contact local rpcbind server (errno 5).

2) if I do "mount -o nolock 10.0.1.16:/exports/rootfs /mnt/temp", I get no error message,

Then I enter /mnt/temp to do a "ls", I get error:  "nfs: server 10.0.1.16 not responding, still trying".

 

It seems that although I can ping the machine, there is still something wrong ...

0 Kudos
Highlighted
Contributor
Contributor
6,244 Views
Registered: ‎02-25-2009

Well, I do not know whether the failure of mouting an NFS after booting up on RamDisk is due to the issue "the EmacLite driver fails above a certain size of packet". This shows up in a few web pages and posts, for example, http://www.gdargaud.net/Hack/Embedded.html.

0 Kudos