Ticket #1253 (new defect)

Opened 2 years ago

Last modified 4 months ago

ffalarms does not wake up from suspend

Reported by: robin Owned by: mrmoku
Priority: major Milestone:
Component: SHR Image Version: SHR-core
Keywords: Cc:

Description

setting an alarm with ffalarms and suspending the phone results in nothing :< the alarm does not go off until one manually "unsuspends" the phone = which means the current shr-u has no alarm

Change History

comment:1 Changed 2 years ago by lupan

This is caused by fsotdld aborting during startup

# time /usr/sbin/fsotdld
BUG: cache_mngt.c:195
fsotdld: cache_mngt.c:195: nl_cache_mngt_provide: Assertion `0' failed.
Aborted

real	0m0.301s
user	0m0.150s
sys	0m0.080s

and thus org.freesmartphone.otimed is not available and so atd-over-fso is not working and thus ffalarms is not working.

As a temporary workaround one can enable otimed subsystem in /etc/frameworkd.conf:

[otimed]
disable = 0

comment:2 Changed 2 years ago by raul

fsotdld is working since last upgrade and so it's waking up correctly.

But there's another issue, which i guess is related to the "time upgrade problem": If the FR is waking up, the alarm takes far too much time to start playing and so in most cases the phone will suspend before playing started.

fsotdld.log:

2011-03-02T10:55:41.165321Z [INFO]  AlarmController </org/freesmartphone/Time/Alarm>: Programming mainloop & rtc alarm for org.openmoko.projects.ffalarms.atd at 1299063600 in 259 seconds from now
2011-03-02T11:00:02.026932Z [INFO]  SourceGsm <>: Received GSM network status signal
2011-03-02T11:00:02.187713Z [INFO]  SourceGsm <>: Resolved provider 26201 to country 'de' w/ 1 timezone(s)
[...]
2011-03-02T11:08:16.440943Z [INFO]  AlarmController </org/freesmartphone/Time/Alarm>: Notifying org.openmoko.projects.ffalarms.atd about an alarm on 1299063600
2011-03-02T11:08:16.553521Z [INFO]  AlarmController </org/freesmartphone/Time/Alarm>: No more alarms. Clearing all timers.

1299063600 -> 2011-03-02T11:00:00
woke up at 11:00 by rtc but gone to suspend again. Then manually woken up at ~11:07 and prevented from suspending till alarm started playing.

comment:3 Changed 12 months ago by iwdy23

comment:4 Changed 4 months ago by Thamos0815

  • Version changed from SHR-unstable to SHR-core

i can still confirm this bug in shr-core-staging 109

Note: See TracTickets for help on using tickets.