On Thu, Apr 30, 2020 at 11:44 AM Surya prakash Verma
<surya.prak...@tataelxsi.co.in.invalid> wrote:
>
> Hello Alan,
>
> As you asked more detail about this issue. So I am sharing more details..
>
> Problem Statement:
> We are facing issue of hang when powering up RX65N-rsk2mb board and connected 
> router simultaneously.
>
> Test setup:
> RX65N-RSK2MB board is connected to router through Ethernet.
> Flash NuttX8.2 code to RX65N-RSK2MB
>
> Steps to Reproduce the issue:
> 1. Connect RX65N-RSK2MB board to Router though Ethernet Interface
> 2. Connect Serial to get NSH console
> 3. Connect power cable to router and power cable to RX65N-RSK2MB board
> 4. Give power simultaneously to RX65N-RSK2MB board and Router.
> 5. Check serial console
> Result:
> NSH console is not observed because of hangs
>
> Debugging and Analysis:
> 1.It is hanging at nxsem_wait(sem) during auto ip configuration by dhcp where 
> waiting for offer repsonse corresponding to dhcp_request at lock 
> nxsem_wait(sem). This lock is not getting released. So it is hanging.
>

Two config handle the timeout and retry:
1.CONFIG_NETUTILS_DHCPC_RECV_TIMEOUT: default is 3 seconds.
2.CONFIG_NETUTILS_DHCPC_RETRIES: defauil is 3 times.
so DHCP will try send request three times and wait the response for 3
seconds in each loop.

> 2.As per my understanding router may not be in UP state when discovery 
> message send from board.So router will not send any ip offer message. So the 
> above lock will keep waiting for IP offer from router which never will come 
> then it will keep waiting since this lock will wait as long as necessary to 
> get the lock.
>

DHCP will fail after nine seconds by default, as I state previously.
If you want NSH can still accept command, you need enable
CONFIG_NETINIT_THREAD as Greg suggest.

> 3. It is hanging at inet_udp_recvfrom()=>net_lockedwait=>net_timedwait(sem, 
> NULL)
> In net_timedwait(sem, abstime) , abstime is passed as NULL so lock is not 
> taken for timeout case mentioned in below code. The lock which taken in this 
> case is nxsem_wait(sem) that will wait as long as necessary to get the lock . 
> Which is causing the problem.
> int net_timedwait(sem_t *sem, FAR const struct timespec *abstime){
>   ...................................
>   if (abstime != NULL) {
>       /* Wait until we get the lock or until the timeout expires */
>       ret = nxsem_timedwait(sem, abstime);
>     } else {
>       /* Wait as long as necessary to get the lock */
>       ret = nxsem_wait(sem);
>     }.....................................
>
> }

your code is a little bit old, I can't find inet_udp_recvfrom in the
current coebase, here is the mainline code:
ssize_t psock_udp_recvfrom(FAR struct socket *psock, FAR void *buf,
                           size_t len, int flags, FAR struct sockaddr *from,
                           FAR socklen_t *fromlen)
{
......
          ret = net_timedwait(&state. ir_sem, _SO_TIMEOUT(psock->s_rcvtimeo));
          if (ret == -ETIMEDOUT)
            {
              ret = -EAGAIN;
            }
......
}
You can see net_timedwait get the correct timeout value.

>
> Thanks & Regards,
> Surya
> ________________________________
> From: Alan Carvalho de Assis <acas...@gmail.com>
> Sent: 29 April 2020 18:00
> To: dev@nuttx.apache.org <dev@nuttx.apache.org>
> Subject: Re: Hang issue when powering up board and target simultaneously
>
> ________________________________
>  **This is an external email. Please check the sender’s full email address 
> (not just the sender name) and exercise caution before you respond or click 
> any embedded link/attachment.**
> ________________________________
>
> Hi Surya,
>
> Could you please give us more details?
> It is hard to help when we don't know exactly what is your scenario
> and the way you are doing it.
>
> What debugger tool are you using?
>
> Are you using the mainline ethernet driver?
> (Please read your message again, I know you are using RX65 chip, but
> many people don't know it and you didn't say it).
>
> Which are the steps to reproduce this issue?
>
> Does this issue happen on other arch as well (i.e. STM32) ?
>
> BR,
>
> Alan
>
> On 4/29/20, Surya prakash Verma <surya.prak...@tataelxsi.co.in.invalid> wrote:
> > Hello Everyone,
> >
> > We are facing issue of hang when powering up board and target
> > simultaneously.
> >
> > We have debugged and observed that it is hanging at nxsem_wait(sem) during
> > auto ip configuration by dhcp where waiting for
> > offer repsonse corresponding to dhcp_request at lock nxsem_wait(sem). This
> > lock is not getting released. So it is hanging.
> >
> > As per my understanding router may not be in UP state when discovery message
> > send from board. So router will not send any IP offer message.
> > So the above lock will keep waiting as this lock will wait as long as
> > necessary to get the lock.
> >
> > Please let us know, if someone face similar issue.
> >
> > Regards
> > SURYA PRAKASH VERMA
> > MOB: +91 9916589237
> > TATA ELXSI
> > Tower B, 9th Floor, Prestige Shantiniketan
> > ITPB Road, Whitefield, Bangalore 560048 India
> >
> >
> > ________________________________
> > Disclaimer: This email and any files transmitted with it are confidential
> > and intended solely for the use of the individual or entity to whom they are
> > addressed. If you are not the intended recipient of this message , or if
> > this message has been addressed to you in error, please immediately alert
> > the sender by reply email and then delete this message and any attachments.
> > If you are not the intended recipient, you are hereby notified that any use,
> > dissemination, copying, or storage of this message or its attachments is
> > strictly prohibited. Email transmission cannot be guaranteed to be secure or
> > error-free, as information could be intercepted, corrupted, lost, destroyed,
> > arrive late or incomplete, or contain viruses. The sender, therefore, does
> > not accept liability for any errors, omissions or contaminations in the
> > contents of this message which might have occurred as a result of email
> > transmission. If verification is required, please request for a hard-copy
> > version.
> > ________________________________
> >

Reply via email to