1067219 - [Dialer] When user turn screen off using power key, AP(CPU) doesn't enter sleep mode because of audio interrupt

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect)

Description

[promise09th]

1. Title : When user turn screen off using power key, AP(CPU) doesn't enter sleep mode because of audio interrupt
2. Precondition : In call state
3. Tester's Action : Turn screen off using power key
4. Detailed Symptom : AP(CPU) doesn't enter sleep mode
5. Expected : AP(CPU) enter sleep mode
6. Reproducibility: Y
1) Frequency Rate : 100%


This issue is shown when Bug 1016277 patch is applied

Comment 1

[Rachelle Yang [:ryang][[e-mail]]]

Hi Fabrice, Could you please kindly spare some time to look into this?
It seemed this issue is introduced after Bug 1016277 patch is applied. May you please help on this ? 
Thank you very much!

Comment 2

[Rachelle Yang [:ryang][[e-mail]]]

Hi Shawn, Could you please find someone to check this ?

Thank you very much !

Comment 3

[Rachelle Yang [:ryang][[e-mail]]]

Hi, Could you please provide more details and STR, or any related log for investigation ?

Thank you very much!

Comment 4

[promise09th]

Reproduced steps :
1) In call
2) Press power key

We check kernel logs only when we find this issue
When you check kernel logs, we found below logs

<6>[  396.021658] PM: suspend entry 2014-09-25 09:18:12.205281224 UTC
<6>[  396.249049] PM: suspend exit 2014-09-25 09:18:17.274341171 UTC
<6>[  396.249250] PM: suspend entry 2014-09-25 09:18:17.274552733 UTC
<6>[  396.327557] PM: suspend exit 2014-09-25 09:18:17.352856223 UTC

Periodically, suspend entry / suspend exit log are shown in kernel logs.
When we test old version(20140627), device doesn't show these logs periodically.


Thank you

Comment 5

[Danny Liang [:dliang]]

I tried to profiling this cases and got some findings:

1. There is no wake lock was held during phone call.
2. By dmesg, system is waked up by interrupt irq 188 and 200
<6>[  151.067289 / 01-02 19:03:31.068] Disabling non-boot CPUs ...
<6>[  151.070375 / 01-02 19:03:31.089] CPU0: msm_cpu_pm_enter_sleep mode:3
....
<4>[  151.070375 / 01-02 19:03:31.089] gic_show_resume_irq: 188 triggered smd_dev
<4>[  151.070375 / 01-02 19:03:31.089] gic_show_resume_irq: 200 triggered smd_dev
<6>[  151.070685 / 01-02 19:03:31.098] Enabling non-boot CPUs ...
3. The status of irq 188 and 200 in /proc/interupts during 30s phone call
       before,   after
188:     2461     5009
200:     5962    22489

As I remember, smd_dev interrupt should be related to modem, so we might need partner's help to clarify it.

Comment 6

[Danny Liang [:dliang]]

Attachment: log.tar.gz

dmesg/wakelock/interrupts status before/after 30s phone call test.

Comment 7

[Doyun Kim]

Hi Danny,

188 is the interrupt related ADSP.
and smd_dev interrupt is added by "AudioCompetingHelper".

If we disabled "AudioCompetingHelper", issue is not reproduced.

Please give us some information what is the "AudioCompetingHelper" and whether interrupt is needed during call.

Comment 8

[shawn ku [:sku]]

Hi Wayne:
 Per comment 7, is there anything we can help answering?

Thanks!!
Shawn

Comment 9

[Wayne Chen [:xwaynec]]

Hi Steven

As offline talk, please help check it.

thanks

Comment 10

[StevenLee[:slee]]

Hi Maire

As comment 0, it's resulted from bug 1016277. Can you find someone to fix the problem?

Thanks.

Comment 11

[Maire Reavy [:mreavy]]

This issue is outside of WebRTC and Web Audio;  so no one on my team would be able to fix this.  However, Andrea may be able to -- or may know who can.

Hi Andrea -- Do you think you could take this bug?  Or do you know someone else who would be a good fit for fixing this?  Thanks!

Comment 12

[promise09th]

Dear all

Is this any updates on this bug?


Thank you

Comment 13

[Andrea Marchesini [:baku]]

> 188 is the interrupt related ADSP.
> and smd_dev interrupt is added by "AudioCompetingHelper".

What can generate this snd_dev interrupt? Events/Messages or just an active WebAudio AudioContext object?

What AudioCompteingHelper does is to play silent using a telephony AudioContext. Can it be that, having this element active, we generate smd_dev interruptions?

If this is the issue, we can easily fix this removing these lines from the compete() function:

+ _silenceBufferSource = _ac.createBufferSource();
+ _silenceBufferSource.buffer = _ac.createBuffer(1, 2048, _ac.sampleRate);
+ _silenceBufferSource.connect(_ac.destination);
+ _silenceBufferSource.loop = true;

and set to null _ac in leaveCompetition().
I can send a patch if this is the reason of this issue.

Comment 14

[Danny Liang [:dliang]]

(In reply to Andrea Marchesini (:baku) from comment #13)
> > 188 is the interrupt related ADSP.
> > and smd_dev interrupt is added by "AudioCompetingHelper".
> 
> What can generate this snd_dev interrupt? Events/Messages or just an active
> WebAudio AudioContext object?
> 
> What AudioCompteingHelper does is to play silent using a telephony
> AudioContext. Can it be that, having this element active, we generate
> smd_dev interruptions?
> 
> If this is the issue, we can easily fix this removing these lines from the
> compete() function:
> 
> + _silenceBufferSource = _ac.createBufferSource();
> + _silenceBufferSource.buffer = _ac.createBuffer(1, 2048, _ac.sampleRate);
> + _silenceBufferSource.connect(_ac.destination);
> + _silenceBufferSource.loop = true;
> 
> and set to null _ac in leaveCompetition().
> I can send a patch if this is the reason of this issue.

I am not a proper guy to answer Andrea's question.
Rachelle, could you help to find owner to answer the questions?

Comment 15

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

I try to dump media.audio_policy and found refCount of voice /system stream is 1. 
So that would cause system can't enter sleep stage.
This bug:1088668 may also affect this issue.

Comment 16

[Rachelle Yang [:ryang][[e-mail]]]

Based on comments from Randy, this bug could be solved when Bug1088668 is resolved which is planned on 2.1 or 2.2 release.

thanks!

Comment 17

[Gabriele Svelto [:gsvelto] (PTO)]

Bug 834530 now landed, it should provide a permanent fix for this issue. Could you re-test with the patch applied and confirm that the problem is gone? We'll close the bug only when it's confirmed to be fixed.

Comment 18

[Gabriele Svelto [:gsvelto] (PTO)]

Any updates here? After bug 834530 landed I've got multiple reports of the Flame's battery life greatly improving so I hope this should be fixed for good.

Comment 19

[Gabriele Svelto [:gsvelto] (PTO)]

Since there hasn't been any updates this I'm closing it as I'm pretty sure that this was fixed as part of bug 834530. Please reopen in case this is still a problem.