Am Samstag, den 12.12.2009, 18:27 +0100 schrieb arne anka:
> > Here's the patch that we're using in OE for over a year now:
> > http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/dbus/dbus-1.3.0/0001-Make-the-default-DBus-reply-timeout-configurable.patch
>
> looking at it, it does not
Here's the patch that we're using in OE for over a year now:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/dbus/dbus-1.3.0/0001-Make-the-default-DBus-reply-timeout-configurable.patch
looking at it, it does nothing but provide a configure option to use at
_build_ time -- nothi
2009/12/9 Michael 'Mickey' Lauer :
>> dbus-send --type=method_call --system --dest=org.freesmartphone.ogsmd
>> /org/freesmartphone/GSM/Device org.freesmartphone.Resource.Resume
>
> Is there any compelling reason why you don't use the recommended way to
> suspend an FSO-based software stack... such
Am Mittwoch, den 09.12.2009, 10:41 +0200 schrieb Timo Jyrinki:
> 2009/12/9 Timo Jyrinki :
> > is for some reason waking up by itself quite often
>
> Silly me, and thanks lindi. I forgot and forgot to say power button
> stopped working for me on upgrade, so I bound suspend with keylaunch
> to power
2009/12/9 Timo Jyrinki :
> is for some reason waking up by itself quite often
Silly me, and thanks lindi. I forgot and forgot to say power button
stopped working for me on upgrade, so I bound suspend with keylaunch
to power button. Obviously I used too straight suspend mechanism.
Looks like worki
2009/12/7 Timo Jyrinki :
> It still needed a second run of zhone to ask for the PIN code. But now
> GSM + GPS seem all functional, and using the Hot New stuff ie.
> fso-usaged and fso-abyss..
With pkg-fso's fso-frameworkd, fso-config-gta02 and fso-abyss my phone
is for some reason waking up by its
2009/12/4 Gilles Filippini :
> # This one is OK
> log_level = INFO
Thanks. I've (semi)working configuration now, changing the following
from pkg-fso shipped:
- log_level = INFO
- ti_calypso_muxer = fso-abyss
- opimd disabled=1
- log_to = file (/tmp is tmpfs)
Additionally I've set deep_sleep to ne
Can you recap the actual error? I didn't understand what effect
increasing the verbosity should have to the framework other than making
it slower.
here's the part from frameworkd.log:
2009.12.06 17:57:38.9 odeviced.idlenotifier INFO odeviced.idlenotifier
state change to idle
2009.12.06 17
Can you recap the actual error? I didn't understand what effect
increasing the verbosity should have to the framework other than making
it slower.
not fully. it always boild down to a message saying "resource gsm could
not be enabled, status is enabling" or soemthing to that effect.
i always
Am Samstag, den 05.12.2009, 17:08 +0100 schrieb arne anka:
> > Without knowing exactly what problems you have, let me remind you of one
> > major difference of those using Debian vs. those using OE-derived
> > distributions on the FreeRunner. Debian insists on not patching DBus,
> > which leads to
Am Samstag, den 05.12.2009, 17:14 +0100 schrieb arne anka:
> > is actually the implementation of a feature wish, since developers
> > wanted to have a way to express
> > the startup order of subsystems and plugins -- now they do.
>
> to quote mr fischer: "i am not convinced."
> the order should
is actually the implementation of a feature wish, since developers
wanted to have a way to express
the startup order of subsystems and plugins -- now they do.
to quote mr fischer: "i am not convinced."
the order should be determined by maybe a specifiy section like
[order]
# set order of subss
Without knowing exactly what problems you have, let me remind you of one
major difference of those using Debian vs. those using OE-derived
distributions on the FreeRunner. Debian insists on not patching DBus,
which leads to broken behaviour for calls that take a bit longer than a
couple of seconds
Without knowing exactly what problems you have, let me remind you of one
major difference of those using Debian vs. those using OE-derived
distributions on the FreeRunner. Debian insists on not patching DBus,
which leads to broken behaviour for calls that take a bit longer than a
couple of seconds.
arne anka a écrit , Le 04/12/2009 23:29:
# This one is OK
log_level = INFO
# This one isn't
log_level = WARNING
>>>
>>> sounds certainly like one of those beloved race conditions.
>>
>> Please explain.
>
> well, race condition means two (or more) operations racing each oth
# This one is OK
log_level = INFO
# This one isn't
log_level = WARNING
sounds certainly like one of those beloved race conditions.
Please explain.
well, race condition means two (or more) operations racing each other for
a bit of code -- ie non-determinitsic outcome.
so, using INFO means,
arne anka a écrit , Le 04/12/2009 23:02:
>> # This one is OK
>> log_level = INFO
>>
>> # This one isn't
>> log_level = WARNING
>
> sounds certainly like one of those beloved race conditions.
Please explain.
Thanks,
_Gilles.
signature.asc
Description: OpenPGP digital signature
___
I also see this behaviour, but it varies depending on the SIM, or maybe
depending on the telco. With some cards it works reliably on the first
try, with others, I have to keep re-trying until it eventually works.
arne anka wrote:
# This one is OK
log_level = INFO
# This one isn't
log_level =
# This one is OK
log_level = INFO
# This one isn't
log_level = WARNING
sounds certainly like one of those beloved race conditions.
___
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/lis
Gilles Filippini a écrit , Le 04/12/2009 21:46:
> I'll try again to narrow the problem this evening.
OK. I think I have something consistent enough now.
*The* difference that makes reproducibly my config to work or not with
zhone is the log_level set in the [frameworkd] section:
# This one is OK
arne anka a écrit , Le 04/12/2009 11:44:
> looking at you config, it does not look like the one included.
Sure.
> i am still shocked to learn, fso needs a certain order of sections (fso
> should be able to read the whole thing and order internally if necessary).
>
> anyway, after learning baout
Am 04.12.2009 um 11:44 schrieb arne anka:
> looking at you config, it does not look like the one included.
> i am still shocked to learn, fso needs a certain order of sections (fso
> should be able to read the whole thing and order internally if necessary).
First off, the order is only relevant
looking at you config, it does not look like the one included.
i am still shocked to learn, fso needs a certain order of sections (fso
should be able to read the whole thing and order internally if necessary).
anyway, after learning baout the order of the two fsousafed sections, i
strongly a
btw: any issues with #1024?
___
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Sebastian Reichel a écrit , Le 04/12/2009 00:59:
> On Fri, Dec 04, 2009 at 12:38:03AM +0100, Gilles Filippini wrote:
>> arne anka a écrit , Le 03/12/2009 23:03:
Doesn't work out of the box here. Zhone says:
Failed to read authentication status
>>> yeah, common issue.
>>> just start zhone
On Fri, Dec 04, 2009 at 12:38:03AM +0100, Gilles Filippini wrote:
> arne anka a écrit , Le 03/12/2009 23:03:
> >> Doesn't work out of the box here. Zhone says:
> >> Failed to read authentication status
> >
> > yeah, common issue.
> > just start zhone over again. and again. after a while it will c
arne anka a écrit , Le 03/12/2009 23:03:
>> Doesn't work out of the box here. Zhone says:
>> Failed to read authentication status
>
> yeah, common issue.
> just start zhone over again. and again. after a while it will catch on.
> my personal best is 5 times so far.
It's even worse. I need to res
Doesn't work out of the box here. Zhone says:
Failed to read authentication status
yeah, common issue.
just start zhone over again. and again. after a while it will catch on.
my personal best is 5 times so far.
i somehow got the idea it may be related to #1024 -- does your fr suffer
from it?
Hi,
Sebastian Reichel a écrit , Le 01/12/2009 11:28:
> On Tue, Dec 01, 2009 at 12:00:57PM +1100, Jonathan Schultz wrote:
>>> The latest version has been in use by SHR for quite a while now and
>>> seems pretty stable.
>> Yes and it works well for me too so far. The only problem is this
>> is the
On Tue, Dec 01, 2009 at 11:28:19AM +0100, Sebastian Reichel wrote:
> On Tue, Dec 01, 2009 at 12:00:57PM +1100, Jonathan Schultz wrote:
> > >The latest version has been in use by SHR for quite a while now and
> > >seems pretty stable.
> >
> > Yes and it works well for me too so far. The only probl
On Tue, Dec 01, 2009 at 12:00:57PM +1100, Jonathan Schultz wrote:
> >The latest version has been in use by SHR for quite a while now and
> >seems pretty stable.
>
> Yes and it works well for me too so far. The only problem is this
> is the first I've heard about it. Would it be possible for
> fs
2009/11/30 Gilles Filippini :
>>> [fsousage]
>>> lowlevel_type = openmoko
>>>
>>> [fsousage.lowlevel_openmoko]
>>> [fsousage.dbus_service]
>
> It works fine this way.
Likewise, though required starting Zhone twice since the first round
gave "couldn't get authentication" or something, ie. didn't as
The latest version has been in use by SHR for quite a while now and
seems pretty stable.
Yes and it works well for me too so far. The only problem is this is
the first I've heard about it. Would it be possible for
fso-config-gta02 to be kept updated?
Jonathan
_
Dr. Michael Lauer a écrit :
>> [fsousage]
>> lowlevel_type = openmoko
>>
>> [fsousage.controller]
>> [fsousage.lowlevel_openmoko]
>
> This is the wrong order. lowlevel_openmoko is being used by the controller,
> hence you need to
>
>> [fsousage.lowlevel_openmoko]
>> [fsousage.controller]
>
> Al
> Am Sonntag 29 November 2009 09:19:05 schrieb Timo Jyrinki:
>> 2009/11/29 Nikita V. Youshchenko :
tried changing to fso-usaged by putting something like:
> [ousaged]
> disable = 1
log file shows lines like this:
> 2009.11.29 11:22:12.536 frameworkd.resource WARNING Ca
Hi,
Jonathan Schultz a écrit :
>> [fsousage]
>> lowlevel_type = openmoko
>>
>> [fsousage.controller]
>> [fsousage.lowlevel_openmoko]
>
> I have precise settings, and still get the problems I described.
Same here.
fsousaged has stopped working after an update last week. It worked
reliably for ab
[fsousage]
lowlevel_type = openmoko
[fsousage.controller]
[fsousage.lowlevel_openmoko]
I have precise settings, and still get the problems I described.
Jonathan
___
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.li
Am Sonntag 29 November 2009 09:19:05 schrieb Timo Jyrinki:
> 2009/11/29 Nikita V. Youshchenko :
> >> tried changing to fso-usaged by putting something like:
> >> > [ousaged]
> >> > disable = 1
> >>
> >> log file shows lines like this:
> >> > 2009.11.29 11:22:12.536 frameworkd.resource WARNING Can
Do you have fso-usaged package installed ?
Yes - just confirmed I have version 0.9.1+git20091016-2
Jonathan
___
Smartphones-userland mailing list
Smartphones-userland@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-user
2009/11/29 Nikita V. Youshchenko :
>> tried changing to fso-usaged by putting something like:
>> > [ousaged]
>> > disable = 1
>>
>> log file shows lines like this:
>> > 2009.11.29 11:22:12.536 frameworkd.resource WARNING Can't register
>> > resource GSM since ousaged is not present. Enabling devi
> tried changing to fso-usaged by putting something like:
> > [ousaged]
> > disable = 1
>
> into /etc/frameworkd.conf but then things get even worse. The framework
>
> log file shows lines like this:
> > 2009.11.29 11:22:12.536 frameworkd.resource WARNING Can't register
> > resource GSM since ou
Hello again,
Still trying to get zhone reasonably stable under debian, I'm finding
that about 4 times out of 5 fso-abyss fails to allocate a channel. I'm
not sure whether restarting framework makes a difference or whether it's
just persistence that does the trick but just trying over and agai
42 matches
Mail list logo
