Request Help with NFS Client Test

[Joel Sherrill]

Till Straumann wrote:
> How do you use qemu/PPC with RTEMS?
> What BSP do you use and how do you boot it?
I wish we could use qemu/ppc with RTEMS. :(

I recompiled for pc386 and used the regular old Fedora
qemu RPM binary.

qemu -M isapc -m 8 -boot a -fda /home/joel/qemu/pc386_fda \
   -hda fat:/home/joel/qemu/hd -serial stdio \
   -net nic,vlan=0,macaddr=00:80:7F:22:61:77,model=ne2k_isa \
   -net tap,vlan=0

/etc/qemu-ifup is:

#!/bin/sh
   TUN_DEV=$1
   TUN_HOST=10.0.2.2
/sbin/ifconfig $TUN_DEV $TUN_HOST

I am using the same old qemu specific networkconfig.h but I had
to switch the static IP to 10.0.2.5 to make it work.  As best I can
tell, 10.0.2.4 is used by a virtual SMB server now.  I have attached
this file.

I didn't have any luck getting the RTEMS application to use DHCP
inside of qemu.

I can ping, run the netdemo, run httpd and run nfsclient.  But nfsclient
doesn't successfully mount the remote filesystem.  It could easily
be a routing problem on qemu. 

I appreciate the help.  Ralf is finishing up merging the NFS client and
I want to have a test of it in the network demos.

--joel
>
> T.
>
> Joel Sherrill wrote:
>> Joel Sherrill wrote:
>>>> In order to make the information provided more useful
>>>> you should:
>>>>
>>>> a) change your BSP so it produces a stack trace
>>>>     from the exception handler (try
>>>>     libcpu/powerpc/shared/src/stack.c: CPU_print_stack())
>>>>
>>>> b) post your binary (elf file) along with the register
>>>>     and stack dump.
>>>>
>>>>       
>>> Wouldn't it be easier to run my test and see if
>>> it works for you with the NFS mounts changed
>>> or is horribly broken?
>>>
>>> The back track shows it is a NULL jump in the
>>> network driver.
>>> 0x00053EA8--> 0x0004E080--> 0x0004E164--> 0x00000006--> 0x0004B5D8
>>> 0x0004C2E0--> 0x00069458--> 0x00098A24--> 0x0009899C
>>>
>>> 0x00053EA8--> CPU_print_stack
>>> 0x0004E080--> C_exception_handler
>>> 0x0004E164--> push_normalized_frame
>>> 0x00000006--> ?????
>>> 0x0004B5D8--> mpc5200_eth_mii_read
>>> 0x0004C2E0--> mpc5200_fec_txDaemon
>>> 0x00069458--> soconnsleep
>>> 0x00098A24--> _Thread_Handler
>>> 0x0009899C--> _Thread_Handler
>>>
>>> Thomas .. can you try this test on your hardware.  I
>>> will commit the NFS client test to the network demos
>>> and hopefully you can track it down.
>>>   
>> Doesn't crash on qemu.  I can't mount a filesystem
>> on the host OS yet but I suspect that I need to
>> add a route.
>> Till could you try to get this working on qemu and
>> see what magic I am missing?  I have to be close.
>>
>> Please.
>>
>>>> That said -- looking at your source code it seems
>>>> that (at least on the 4.7 branch) using a NULL pointer
>>>> for the first argument to RTEMS 'mount' is illegal.
>>>>       
>>> I saw your comment (gripe?) in the README
>>> and fixed it Friday in CVS.  :)
>>>  
>>>> You could also use the convenience wrapper 'nfsMount()'
>>>> which does a DNS lookup (non thread-safe gethostbyname!)
>>>> and creates a mount-point (not nested directories, though)
>>>> if necessary:
>>>>
>>>> nfsMount("server","/export","/home")
>>>>
>>>> both methods are explained in the rtemsNFS README.
>>>>       
>>> I was trying hard to follow that to create
>>> the example.
>>> I tried the nfsMount call and it didn't even change
>>> the behavior.  Maybe this is just tripping a bug in
>>> the NIC driver. <sigh>
>>>
>>> I am going to try this on another BSP and see what happens.
>>>
>>> --joel
>>>  
>>>> HTH
>>>> T.
>>>>     
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>   
>>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: networkconfig-qemu.h
Type: text/x-chdr
Size: 4116 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20070716/7ca0c84b/attachment-0001.bin>