I may be wrong here, but as the child never returns control to the parent a
timeout in the parent would have no effect on the problem that I'm having.
My suggestion would be to put the timeout in the child where it's waiting
for an interrupt as this is where it seems to be hanging.

Would this work or have I not understood what's going on? Sorry, my C isn't
very good!

James Wells

----- Original Message -----
From: "Edouard Gomez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 24, 2002 12:37 AM
Subject: [speedtouch] Re: modem_run hanging with FreeBSD


>
> James Wells ([EMAIL PROTECTED]) wrote:
> > By messing around with the c-code of 1.1rc1 a bit I found out that the
> > program gets to the while loop at line 443 of modem_run.c, calls pause()
> > once but never returns from it. I understand that pause() allows another
> > process to carry on but not knowing which one it might be, I stopped my
> > investigations (i.e. hacking!) there.
> >
>
> Here's an explaination of "how modem_run works"
>
> 1 - start
> 2 - find the modem
> 3 - Upload the code
> 4 - forks
>
>        Parent Instance          |             Child instance
> --------------------------------+-----------------------------------------
---
> 5 - enters into pause           | 5' - open a special endpoint of the
modem
>                                 |      called interrupt endpoint
(interrupts
>                                 |      sent by the modem)
>                                 | 6' - Waits until an interupt is read
>                                 | 7' - if interrupt == "up"
string/constant
> <-------------------------------+      then wakeup the parent process else
> 6 - The child has set the up    |      loop to 6'.
>     variable through the signal |
>     USR2                        | We wake up the parent only once, other
>     handler.                    | interrupts are just logged in order to
> 7 - Get the connection speed and| get some infos that could help us to
>     log it                      | understand the modem's internals.
> 8 - quit                        | This child is the backgrounded modem_run
> --------------------------------+-----------------------------------------
--
>
> > The last three lines of modem_run.log are:
> >
> > May 10 14:59:27 ein modem_run[106]: Modem reference : 3EC18607CAAB05
> > May 10 14:59:27 ein modem_run[106]: modem_start_synchro :
> > May 10 14:59:27 ein modem_run[106]: 00 00
> >
>
> I think we should add a timemout value in the parent process setting up
> an alarm event on USR2 signal. No ? It's just a work around but as
> modem interrupts are generated by the alcatel's firmware, we can not
> reasonably solve this problem.
>
> > This is where it stops.
> >
> > Any help would be appreciated,
> >
> > Thanks
> >
> > James Wells
>
> Any objections for this "new" feature/woraround ?
> Source code is suposed to be frozen in rc :( else i can post a temporary
patch
> and release a 1.1.1 a few days after the 1.1 ?
>
> What do you guys think about this ?
>
> (1.1 final is planned for Friday 24th around 10pm GMT+1)
>
> --
> Edouard Gomez
>
>
> Liste de diffusion modem ALCATEL SpeedTouch USB
> Pour se d�sinscrire :
mailto:[EMAIL PROTECTED]?subject=unsubscribe
>
>
>



Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se d�sinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe

        

Reply via email to