Is ethaddr set to a reasonable value in bootargs?
From: Chuck Meade [mailto:[email protected]] Sent: Wednesday, December 07, 2011 06:57 PM To: Timothy Bean <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: NFS boot help On 12/07/2011 08:51 PM, Timothy Bean wrote: Here is capture. Thanks for anyone that can look at it and maybe point me in the right direction. I exported as text file and compressed. Thanks Tim On Wed, Dec 7, 2011 at 9:47 AM, Chuck Meade <[email protected]<mailto:[email protected]>> wrote: On 12/07/2011 10:39 AM, Steve Chen wrote: On Wed, Dec 7, 2011 at 9:23 AM, Timothy Bean <[email protected]<mailto:[email protected]>> wrote: ... IP-Config: Complete: device=eth0, addr=192.168.0.100, mask=255.25 5.255.0, gw=192.168.0.1, host=192.168.0.100, domain=, nis-domain=(none), bootserver=192.168.0.50, rootserver=192.168.0.50, rootpath= Waiting 5sec before mounting root device... Looking up port of RPC 100003/2 on 192.168.0.50 Looking up port of RPC 100005/1 on 192.168.0.50 VFS: Mounted root (nfs filesystem). Freeing init memory: 172K INIT: version 2.86 booting Starting the hotplug events dispatcher: udevd . Synthesizing the initial hotplug events... done. Waiting for /dev to be fully populated... done. Activating swap... done. Remounting root filesystem...done. Calculating module dependencies nfs: server 192.168.0.50 not responding, still trying nfs: server 192.168.0.50 not responding, still trying nfs: server 192.168.0.50 not responding, still trying Do you have any other pointers? I hopefully have attached a wireshark catpure. Maybe someone can look at that and determine what I am doing wrong. This is what I put for my interfaces file: Yes, your analysis is correct that NFS was connected and dropped shortly after. I have seen similar issues when the target board shared the same IP address as another device on the network. You may want to try replacing the kernel command line ... ip=192.168.0.100:192.168.0.50:192.168.0.1:255.255.255.0:::off ... with ... ip=dhcp ... to see if that makes a difference. Or just unplug your board and ping 192.168.0.100 to make sure no-one answers. Regards, Steve Your wireshark capture was not attached (at least I did not get it). The Linux Ethernet driver was working, since NFS mounted successfully. Without seeing the wireshark info I can't tell, but you should check to be sure that some other bootup logic has not changed the target's IP address or Eth MAC address. You mention that the wireshark packets go from looking fine to looking like fragments. Do this same boot sequence, but reduce what is being loaded and run at bootup. Especially reduce the list of modules being loaded, one by one. Then reduce what is being done by the sysv init logic. Boot up after each small change you make. If you can find a point at which you stop seeing the problem, then you have likely found what is causing it. Chuck I don't see NFS necessarily failing there. Something is causing a read of a large file at the end, and that is after a lot of reads of *.ko files. You can "grep LOOKUP nfs_capture.txt" to see what files were read in that capture. I still suggest that you simplify your boot process. If you cut back on the large number of modules being loaded and strip down your startup sequence, then you may be able to find out what in the startup sequence is causing the problem. The fact that NFS works fine and allows you to read in so many files means that it is at least functional. Chuck This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
