Jim Rees wrote: > You may want to read the mailing list thread from the earlier patch. I > don't remember the details but lowering the panic timeout from 110 to 41 > seconds may re-introduce the problem that patch was trying to solve. You > could increase the retry count to compensate. > >From commit 43717c7d, "NFS: Retry mounting NFSROOT" log. Original problems looks exactly same as the one I encountered. First operation was an rpcbind request to determine which port the NFS server was listening on timeout in 2-3 seconds, by this time Switch was ready. which was then followed by default nfs port 2049 selection at this time the nfs mount was successful. In my case the PHY became ready just before the second attempt, same as LAN switch in the original issue. I think most of the cases fall in this category. So there was no delay before this patch except the timeout from rpcbind was sufficient delay to get the Switch/PHY(in my case) in working state. I think introduction of timeout actually was not necessary for the second attempt. If user want to have more delay than 41 secs, he will be able to increase the retry count from my mount-retry kernel param patch. Thanks, srini -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
