public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Michal Simek <monstr@monstr.eu>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: netdev@vger.kernel.org, linux-nfs@vger.kernel.org,
	David Miller <davem@davemloft.net>,
	"ltp-list@lists.sourceforge.net" <ltp-list@lists.sourceforge.net>
Subject: Re: [LTP] NFS on little-endian platform - Microblaze
Date: Thu, 17 Feb 2011 13:01:38 +0100	[thread overview]
Message-ID: <4D5D0E22.3050701@monstr.eu> (raw)
In-Reply-To: <1297865074.6596.10.camel@heimdal.trondhjem.org>

Trond Myklebust wrote:
> On Wed, 2011-02-16 at 14:53 +0100, Michal Simek wrote: 
>> Trond Myklebust wrote:
>>> On Wed, 2011-02-16 at 14:16 +0100, Michal Simek wrote: 
>>>> Hi again,
>>>>
>>>> I forget to cc linux-nfs mailing list.
>>>>
>>>> Michal
>>>>
>>>> P.S.: Tested on kernels 2.6.38-rc4, 2.6.37 and 2.6.36
>>>>
>>>> Michal Simek wrote:
>>>>> Hi All,
>>>>>
>>>>> I am trying to understand one problem which we have found.
>>>>> The problem is that I can't on Microblaze little-endian platform
>>>>> mount nfs without -o nolock options. (Log below)
>>>>> Selecting tcp or udp has no effect.
>>>>> I am using emaclite driver and there is no problem on big endian 
>>>>> microblaze.
>>>>>
>>>>> ping, telnet, http, ftp, iperf, netperf work well.
>>>>>
>>>>> That's why I have a question if there is any endian specific option for 
>>>>> NFS?
>>>>>
>>>>> Thanks,
>>>>> Michal
>>>>>
>>>>> ~ # mount -t nfs 192.168.0.101:/tftpboot/nfs /mnt
>>>>> svc: failed to register lockdv1 RPC service (errno 13).
>>>>> lockd_up: makesock failed, error=-13
>>>>> svc: failed to register lockdv1 RPC service (errno 13).
>>>>> ~ # mount -t nfs -o nolock 192.168.0.101:/tftpboot/nfs /mnt
>>>>> ~ # mount
>>>>> rootfs on / type rootfs (rw)
>>>>> proc on /proc type proc (rw,relatime)
>>>>> none on /var type ramfs (rw,relatime)
>>>>> none on /sys type sysfs (rw,relatime)
>>>>> none on /etc/config type ramfs (rw,relatime)
>>>>> none on /dev/pts type devpts (rw,relatime,mode=600)
>>>>> 192.168.0.101:/tftpboot/nfs on /mnt type nfs 
>>>>> (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=all,addr=192.168.0.101) 
>>>>>
>>>>> ~ #
>>>>> ~ # ps
>>>>> PID   USER     TIME   COMMAND
>>>>>     1 root       0:02 init
>>>>>     2 root       0:00 [kthreadd]
>>>>>     3 root       0:00 [ksoftirqd/0]
>>>>>     4 root       0:00 [kworker/0:0]
>>>>>     5 root       0:00 [kworker/u:0]
>>>>>     6 root       0:00 [khelper]
>>>>>     7 root       0:00 [sync_supers]
>>>>>     8 root       0:00 [bdi-default]
>>>>>     9 root       0:00 [kblockd]
>>>>>    10 root       0:00 [rpciod]
>>>>>    11 root       0:00 [kworker/0:1]
>>>>>    12 root       0:00 [kswapd0]
>>>>>    13 root       0:00 [fsnotify_mark]
>>>>>    14 root       0:00 [aio]
>>>>>    15 root       0:00 [nfsiod]
>>>>>    16 root       0:00 [kworker/u:1]
>>>>>    58 root       0:00 udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i eth0
>>>>>    62 1          0:00 /bin/portmap
>>>>>    64 root       0:00 /bin/inetd /etc/inetd.conf
>>>>>    65 root       0:01 -sh
>>>>>    66 root       0:00 /bin/syslogd -n
>>>>>    67 root       0:00 /bin/flatfsd
>>>>>    68 root       0:00 [kworker/0:2]
>>>>>    91 root       0:00 ps
>>> Where is rpc.statd? Without it, the above behaviour is 100% expected.
>> I see on BE that lockd is used but it is enabled on little endian too but hasn't started.
>>
>> Enabled options:
>> CONFIG_NETWORK_FILESYSTEMS=y
>> CONFIG_NFS_FS=y
>> CONFIG_NFS_V3=y
>> CONFIG_LOCKD=y
>> CONFIG_LOCKD_V4=y
>> CONFIG_NFS_COMMON=y
>> CONFIG_SUNRPC=y
>>
>> On Be lockd is up.
>>     69 root       0:00 /bin/flatfsd
>>     71 root       0:00 [lockd]
>>     73 root       0:00 ps
>>
>> I have to look why.
>> How is it started?
> 
> Either rpc.bind or rpc.portmap and then rpc.statd need to be started
> manually (in that order) before you may mount the NFS partition without
> '-onolock'. The lockd daemon itself will be started by the kernel
> whenever there is a need for it.
> 
> Please check your 'init' boot scripts to find out why they are not being
> started as expected.
> 

It seems to me that the problem is with sunrpc in connection to endian.
I am looking for any package which can test sunrpc on embedded systems.
Can you recommend me any package?

I have found RPC tests in LTP but it is designed for desktops not embedded.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

           reply	other threads:[~2011-02-17 12:31 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <1297865074.6596.10.camel@heimdal.trondhjem.org>]

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=4D5D0E22.3050701@monstr.eu \
    --to=monstr@monstr.eu \
    --cc=Trond.Myklebust@netapp.com \
    --cc=davem@davemloft.net \
    --cc=linux-nfs@vger.kernel.org \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    /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