• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 330 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

NFS not working on DM365

Hank Magnuski
Prodigy 100 points

Just received the DM365 EVM and am trying to mount another directory.

I get this error:

# ./mount 192.168.1.10:/home/davinci/target /mnt/disk
mount: wrong fs type, bad option, bad superblock on 192.168.1.10:/home/davinci/target,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

and it never works. The IP address is from dhcp and I can ping the server. Another machine on the same LAN mounts the directory fine.

rpcinfo works fine.

Is the NFS module in the kernel broken?

  • 0
    TI__Mastermind 41665 points

    Generally I just boot the device's root filesystem off of the NFS, and this certainly works on the DM365 so the NFS functionality is there, though using a mount command after it has booted through some other file system is not something I have tried out, though I believe someone has done that around here before I cannot find it. Have you tried booting the board with the NFS as the root filesystem as discussed in the getting started guide?

    Looking at the error you are getting, have you tried adding the '-t nfs' flag to the mount command?

  • 0 in reply to Bernie Thompson TI
    Prodigy 100 points

    The problem has been resolved. I don't think mounting the root file system is much different than mounting a directory later. Both should work about the same way. You should be able to mount, for example, another "/" tree and then do a "chroot" to try out another root filesystem. I was getting the same error with or without "-t nfs".

    There were several problems that needed fixing. First, it would be helpful if the TI getting started documentation on setting up NFS also mentioned that "portmap" is subject to tcpd wrappers, and an entry in /etc/hosts.allow may be needed, even if the firewall is completely turned off. An entry like this will work:

    portmap :192.168.1.

    If you are getting errors such as this:

    Looking up port of RPC 100003/2 on 192.168.1.10
    Root-NFS: Unable to get nfsd port number from server, using default
    Looking up port of RPC 100005/1 on 192.168.1.10
    Root-NFS: Unable to get mountd port number from server, using default

    it's likely a portmap being blocked problem, and the "using default" is a lie because NFS didn't work at all.

    Once I got past that, NFS kept timing out completely. It turns out that the ethernet driver implementation is broken and doesn't work successfully with a standard ethernet hub. As soon as I put the board on a switch NFS came up quickly. All my other computers & devices work with the Netgear hubs used, so I think this is a serious driver problem.

    The full MV root is now running and I can continue my debugging.

  • 0 in reply to Hank Magnuski
    TI__Mastermind 41665 points

    I am glad to hear that you got your NFS working.

    Hank Magnuski said:
    it's likely a portmap being blocked problem, and the "using default" is a lie because NFS didn't work at all.

    This depends on the Linux distribution you are using, the 'default' has worked for me in both the Red Hat Enterprise Linux v4 that the DVSDK software stack is tested on and Ubuntu 9.04 that I typically use, as I never had to do any portmap modifications (I believe the default portmap setup in these distros is all open). What Linux distribution are you using?

    Hank Magnuski said:
    Once I got past that, NFS kept timing out completely. It turns out that the ethernet driver implementation is broken and doesn't work successfully with a standard ethernet hub. As soon as I put the board on a switch NFS came up quickly. All my other computers & devices work with the Netgear hubs used, so I think this is a serious driver problem.

    This is interesting, I have not seen this reported before but it is possible, I have never used these boards with a hub before, all the Ethernet equipment we have around my office is comprised of switches these days, I have not used a hub in years. I believe I may have one somewhere, if I can find it I will give this a try.

  • 0 in reply to Bernie Thompson TI
    Prodigy 100 points

    The NFS server in this case was an older Fedora distribution running a 2.6.20-1 kernel. When the portmap was being blocked and running under the default conditions, a TCPDUMP trace did not show any NFS packets being emitted by the DM365. I would assume that if the defaults were being used I would see some NFS packets, but the trace was empty.

    There was an earlier report about a driver problem:

    http://linux.omap.com/pipermail/davinci-linux-open-source/2006-December/001861.html

    which suggested that I swap out the hub.

    Thank you for your responses.

  • 0 in reply to Hank Magnuski
    Prodigy 180 points

    So, from all my reading above, I think I have the same problem. I know this worked on the DM6446, but now I can't nfs mount a directory on the 365. I have a netgear hub, will a different hub work?

  • 0 in reply to Julia Elbert
    Prodigy 100 points

    Try a switch rather than a hub. I think it's the kind of device rather than a problem with a specific manufacturer.

  • 0 in reply to Hank Magnuski
    Prodigy 180 points

    thanks, I will go get a switch, uughghghg