Re: gsm modem daemon
On 9 February 2010 23:03, Petr Vanek van...@penguin.cz wrote: looking at the FSOSHRCON proposal, seems fsogsmd will still take some time befoe we see it in action ... :( , too bad for us who loose gsm after gprs... True, but it's not fair to put extra pressure on Mickey... And, even when fsogsmd is good for 80% stable operation, I'm sure it will have its own new issues in non-mainline scenarios. Therefore, perhaps we should also continue looking in parallel at the problem in ogsmd. It's well known by now (I think) that this is something to do with the internals of the ProcessGuard object, which uses Python's spawning and process monitoring primitives to manage a pppd process, and that somehow that all goes wrong when pppd is killed, causing frameworkd to hang. Would anyone be interested in investigating this further? Neil ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: gsm modem daemon
NJ looking at the FSOSHRCON proposal, seems fsogsmd will still take NJ some time befoe we see it in action ... :( , too bad for us who NJ loose gsm after gprs... NJ NJ True, but it's not fair to put extra pressure on Mickey... Sorry if it sounded that way. i know Mickey did a huge job to push fsogsmd before new year. I was hoping the gprs bug would go away with fsogsmd but after trying i can see that the fsogsmd is not running plus i get no replies on how to run it or what to do. Then i see the shr implementation being planned for sometimes in summer. Again, i cannot say more or less then too bad for us suffering the issue. NJ And, even when fsogsmd is good for 80% stable operation, I'm sure it NJ will have its own new issues in non-mainline scenarios. Not sure what you mean by non-mainline scenario. Another issues are quite likely but we will cross that bridge when it comes. NJ Therefore, perhaps we should also continue looking in parallel at NJ the problem in ogsmd. It's well known by now (I think) that this is NJ something to do with the internals of the ProcessGuard object, which NJ uses Python's spawning and process monitoring primitives to manage a NJ pppd process, and that somehow that all goes wrong when pppd is NJ killed, causing frameworkd to hang. Would anyone be interested in NJ investigating this further? IMHO no-one will spend their time as fso2 will replace it. i am lacking the expertize to investigate but have wanted to give it a try. From my understanding of the concept: The python implementation is the chance for getting the API right; the vala implementation is the chance of getting the right API fast. i gather that the API is right but the conditions are not perfect. So troubleshooting the good API in python is a step back, checking the fast right API should be the priority. my 2c Petr ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: gsm modem daemon
I have done a lot of work in the last 12 months on the reimplementation of our FSO daemons in Vala, which compiles to C -- but especially to fsogsmd. With everyone being at FOSDEM, i can imagine this post will get lost... anyways, will try: Trying to use fso-gsmd: disabling ogpsd in /etc/frameworkd.conf [ogsmd] disable = 1 rebooting then running fsogsmd. Resulting in: ** (process:1502): WARNING **: common.vala:31: FsoFramework.createLogger is DEPRECATED, please use Logger.createLogger 2010-02-07T16:36:23.786673Z [INFO] fsogsmd : fsogsmd starting up... ** (process:1502): DEBUG: plugin.vala:107: lowlevel_openmoko fso_factory_function 2010-02-07T16:36:24.846120Z [INFO] fsogsmd : loaded 3 plugins 2010-02-07T16:36:24.853996Z [INFO] fsogsmd : fsogsmd = mainloop 2010-02-07T16:36:24.974157Z [INFO] fsogsmd : received signal -11, exiting. Segmentation fault (failed) full output of fsogsmd in DEBUG mode is available here: http://pastebin.com/m15822b89 SHR unstable last image with last updates yesterday. thank you Petr ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: gsm modem daemon
Dear Ryan, sorry for the delay in answering. I have cc'ed this mail to smartphones-userland@linuxtogo.org, which is the best place to talk about these projects. I have done a lot of work in the last 12 months on the reimplementation of our FSO daemons in Vala, which compiles to C -- but especially to fsogsmd. These days, fsogsmd is almost ready for integration in distros, it's just missing some more modem specifics integration and the ppp handling, so I'd recommend using that for your project. fsogsmd is also using the library interface of libgsm0710mux, so we don't waste any performance by tunnelling data through ptys. Cheers, :M: ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
