1013066 - [FFOS_OPEN2_1.3]Sometimes we couldn't wake up device immediately by power key

Status: RESOLVED DUPLICATE of bug 932698

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[Duan Xiaodong]

Attachment: adb log and kernel log for 37# and 39# device

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C; .NET4.0E; Zune 4.7; Tablet PC 2.0; TCO_20140520081245)

Steps to reproduce:

1.flash FFOS_US_ZTE_P821A20V1.0.0B06 build to device.
2.make device boot up to Homescreen and let it turn off lcd automatically and go to power collapse.
3.wait for at least 10 minutes and press power key to wake up device
4.device can't wake up and turn on lcd immediately but you need press 2-4 times power key to achieve.


Actual results:

The device can't wake up immediately via power key but you need press 2-4 times to achieve. 38% repetition rate on product line test.


Expected results:

The device should wake up immediately via power key under power collapse state.

Comment 1

[Duan Xiaodong]

Dear Mozilla team,

I have analyzed the logcat_main3.log from 37# and logcat_main1.log from 39# device. There are below coding exception on two devices(aIDsApp is undefined). Exception code is at 308 line in gecko\dom\apps\src\OperatorApps.jsm. It seems that this._getSingleVariantApps(aMcc, aMnc) sentence return the undefined value. Can mozilla team help us with this issue together?

01-01 07:00:20.029 I/Gecko   (  282): *************************
01-01 07:00:20.029 I/Gecko   (  282): A coding exception was thrown and uncaught in a Task.
01-01 07:00:20.029 I/Gecko   (  282): 
01-01 07:00:20.029 I/Gecko   (  282): Full message: TypeError: aIdsApp is undefined
01-01 07:00:20.029 I/Gecko   (  282): Full stack: this.OperatorAppsRegistry._installOperatorApps/<@resource://gre/modules/OperatorApps.jsm:308
01-01 07:00:20.029 I/Gecko   (  282): TaskImpl_run@resource://gre/modules/Task.jsm:233
01-01 07:00:20.029 I/Gecko   (  282): resolve@resource://gre/modules/commonjs/sdk/core/promise.js:118
01-01 07:00:20.029 I/Gecko   (  282): then@resource://gre/modules/commonjs/sdk/core/promise.js:43
01-01 07:00:20.029 I/Gecko   (  282): resolve@resource://gre/modules/commonjs/sdk/core/promise.js:185
01-01 07:00:20.029 I/Gecko   (  282): TaskImpl_run@resource://gre/modules/Task.jsm:242
01-01 07:00:20.029 I/Gecko   (  282): resolve@resource://gre/modules/commonjs/sdk/core/promise.js:118
01-01 07:00:20.029 I/Gecko   (  282): then@resource://gre/modules/commonjs/sdk/core/promise.js:43
01-01 07:00:20.029 I/Gecko   (  282): resolve@resource://gre/modules/commonjs/sdk/core/promise.js:185
01-01 07:00:20.029 I/Gecko   (  282): TaskImpl_run@resource://gre/modules/Task.jsm:239
01-01 07:00:20.029 I/Gecko   (  282): Handler.prototype.process@resource://gre/modules/Promise.jsm:767
01-01 07:00:20.029 I/Gecko   (  282): this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm:531
01-01 07:00:20.029 I/Gecko   (  282): 
01-01 07:00:20.029 I/Gecko   (  282): *************************

 _installOperatorApps: function(aMcc, aMnc) {
    Task.spawn(function() {
      debug("Install operator apps ---> mcc:"+ aMcc + ", mnc:" + aMnc);
      if (!isFirstRunWithSIM()) {
        debug("Operator apps already installed.");
        return;
      }

      let aIdsApp = yield this._getSingleVariantApps(aMcc, aMnc);
      debug("installOperatorApps --> aIdsApp:" + JSON.stringify(aIdsApp));
      for (let i = 0; i < aIdsApp.length; i++) {  // line 308
        let aId = aIdsApp[i];
        let aMetadata = yield AppsUtils.loadJSONAsync(
                           OS.Path.join(this.appsDir.path, aId, METADATA));
        debug("metadata:" + JSON.stringify(aMetadata));
        let isPackage = true;
        let manifest;
        let manifests = [UPDATEMANIFEST, MANIFEST];
        for (let j = 0; j < manifests.length; j++) {
          try {
            manifest = yield AppsUtils.loadJSONAsync(
                          OS.Path.join(this.appsDir.path, aId, manifests[j]));
            break;
          } catch (e) {
            isPackage = false;
          }
        }
        if (manifest) {
          this._launchInstall(isPackage, aId, aMetadata, manifest);
        } else {
          debug ("Error. Neither " + UPDATEMANIFEST + " file nor " + MANIFEST +
                 " file for " + aId + " app.");
        }
      }
      this.eraseVariantAppsNotInList(aIdsApp);
      Services.prefs.setBoolPref(PREF_FIRST_RUN_WITH_SIM, false);
      Services.prefs.savePrefFile(null);
    }.bind(this)).then(null, function(aError) {
        debug("Error: " + aError);
    });
  },

Comment 2

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

This issue is similiar to Bug#917261, Bug#904544 and Bug#898707. The solution of Bug#904544 has already included in 1.3 branch. Now Mozilla is discussing with partner regarding how to implement the solution of Bug#917261 in 8x10 platform.

More information can be found here : https://bugzilla.mozilla.org/show_bug.cgi?id=898707#c22

Thanks

Comment 3

[Jason Smith [:jsmith]]

Vance - I'm confused here. If this is already fixed, why is a bug on file here? Triage is confused.

Comment 4

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

There are two patches of the cannot-wake-up-by-pressing-powerkey issue, one is done in the Mozilla side(The fix of Bug#904544 is in the EventHub.cpp). So our 1.3 branch already has this patch

However the fix of Bug#917261 is done in the vendor side(by modifying the kernel code), hence for Open II, we are helping vendor here to see how to leverage the patch from 7x26a platform to 8x10. 

Thanks

Comment 5

[Jason Smith [:jsmith]]

So this is POVB then, right?

Comment 6

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

No, Mozilla/ZTE/QCT are still discussing what is the best approach to fix this one, either to prolong the awake time in kernel or to hold a wakelock in user space.

Also ni Thomas and Viral to find a way for Mozilla to hold the wake lock in user space on a timer?

Comment 7

[viral [:viralwang]]

The open2 in my hand is broken since I flash P821A20_TME-ENG_20140508.zip few weeks ago.
There's a mail discussion about the touch panel firmware issue make my device can not work.
I didn't get any information about how to fix it even I sent few mails for help after that.
Not sure the image FFOS_US_ZTE_P821A20V1.0.0B06 can fix the touch panel firmware issue or make it worse.

I think I can provide more useful information if I can reproduce it in my open2.

Comment 8

[Andreas Gal :gal]

This should be fixed in user space. Thats how Android fixes it. Otherwise we will run into this with every device. Please fix in our code.

Comment 9

[Michael Vines [:m1] [:evilmachines]]

We can probably grab another wakelock during the time that the "KeyEvents" lock is held for a little while.

http://dxr.mozilla.org/mozilla-central/source/widget/gonk/libui/EventHub.cpp#916

Comment 10

[Duan Xiaodong]

Hi all,

We do the following patch in power key driver (kernel\drivers\platform\msm\qpnp-power-on.c) and test 10 devices but still one device can reproduce this issue.
It seems that below modification reduce the repetition rate but not being solved completely. Please Qualcomm and Mozilla team help us to review if you have any comments.
----------------------------------------------------------------------------------------------------------
/// M: Patch for issue that power key can't wake up device immediately
#include <linux/pm_wakeup.h> 

/// M: Patch for issue that power key can't wake up device immediately @{
#define UNKNOWN_WS_DELAY 500 // in ms
#define KEYCODE_KPDPWR 0x74

static struct wakeup_source unknown_ws;  
const char *unknown_ws_name = "unknown_wakeup";
/// M: Patch for issue that power key can't wake up device immediately @}

static int
qpnp_pon_input_dispatch(struct qpnp_pon *pon, u32 pon_type)
{
    int rc;
    struct qpnp_pon_config *cfg = NULL;
    u8 pon_rt_sts = 0, pon_rt_bit = 0;

    cfg = qpnp_get_cfg(pon, pon_type);
    if (!cfg)
        return -EINVAL;

    /* Check if key reporting is supported */
    if (!cfg->key_code)
        return 0;

    /* check the RT status to get the current status of the line */
    rc = spmi_ext_register_readl(pon->spmi->ctrl, pon->spmi->sid,
                                QPNP_PON_RT_STS(pon->base), &pon_rt_sts, 1);
    if (rc) {
        dev_err(&pon->spmi->dev, "Unable to read PON RT status\n");
        return rc;
    }

    switch (cfg->pon_type) {
    case PON_KPDPWR:
        pon_rt_bit = QPNP_PON_KPDPWR_N_SET;
        printk(KERN_ERR "%s[1]: pon_rt_bit = %0x\n", __func__, pon_rt_bit);
        break;
    case PON_RESIN:
        pon_rt_bit = QPNP_PON_RESIN_N_SET;
        break;
    case PON_CBLPWR:
        pon_rt_bit = QPNP_PON_CBLPWR_N_SET;
        break;
    case PON_KPDPWR_RESIN:
        pon_rt_bit = QPNP_PON_KPDPWR_RESIN_BARK_N_SET;
        printk(KERN_ERR "%s[2]: pon_rt_bit = %0x\n", __func__, pon_rt_bit);
        break;
    default:
        return -EINVAL;
    }
    
    printk(KERN_ERR "%s[3]: input_report_keycfg->pon_type = %d \n", __func__, cfg->pon_type);
        input_report_key(pon->pon_input, cfg->key_code,
                                        (pon_rt_sts & pon_rt_bit));
    printk(KERN_ERR "%s[4]: input_report_key cfg->key_code=%d status=%0x\n", __func__, cfg->key_code, (pon_rt_sts & pon_rt_bit));
        input_sync(pon->pon_input);

    /// M: Patch for issue that power key can't wake up device immediately @{
    if (cfg->key_code == KEYCODE_KPDPWR && cfg->pon_type == PON_KPDPWR) { 
        /** 
         * Keep the kernel awake for a little bit longer such that 
         * userspace can finish handling power key event and wake up the device.
         */    
        __pm_wakeup_event(&unknown_ws, UNKNOWN_WS_DELAY);                
    }
    /// M: Patch for issue that power key can't wake up device immediately @}
    return 0;
}

static int __init qpnp_pon_init(void)
{
    /// M: Patch for issue that power key can't wake up device immediately
    wakeup_source_init(&unknown_ws, unknown_ws_name);
    return spmi_driver_register(&qpnp_pon_driver);
}
module_init(qpnp_pon_init);

static void __exit qpnp_pon_exit(void)
{
   /// M: Patch for issue that power key can't wake up device immediately
    wakeup_source_trash(&unknown_ws); 
    return spmi_driver_unregister(&qpnp_pon_driver);
}

Thanks,
Xiaoodng

Comment 11

[viral [:viralwang]]

Attachment: hold a wakelock when power key is pressed

Here's a quick solution to hold a wakelock in userspace.
But still need kernel space to make sure we can receive the power key event in EventHub before device suspend again.

Need partner's help to verify since failed rate is low.

Comment 12

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi XiaoDong, Chen Cong, please help to verify the patch in comment#11. Also in order to further ensure that the whole wake up mechanism is flawless(both in kernel side and in user space), we need your help to add trace and get logs for:

kernel log

   a. The timestamp of each power key press and release 
   b. The timestamp of each wake lock obtain and release
   c. The timestamp of early suspend, suspend, resume, late resume

We these logs we can figure out the average elapsed time from user presses the power key to the eventhub receives the power key event in user space. Then we can decide the proper timer for the wake lock in the kernel side.

However, we are suspecting since in the current design, the kernel will only hold the wake lock for a fixed period of time, it might be possible that if certain drivers/modules behave abnormally and take longer to wake up, the kernel wake lock will expire and the system will sleep again before it pass the power key event to the user space. ni? Micheal here to comment if that is possible or not

Comment 13

[viral [:viralwang]]

Hi ZTE partner,

Any feedback we can have?
I'm looking forward to the testing results and no any update for over a week.
Thanks.

Comment 14

[Gabriele Svelto [:gsvelto]]

FYI we have a bunch of similar bugs, shall we dup all of them to this one? See bug 919903, bug 937288, bug 1020885 and bug 1026026. There's probably more since this is a recurring problem. IIRC we already worked on this on another bug but I cannot seem to be able to dig it out.

Comment 15

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Viral -

Per discussion with partner, turns out they didn't verify our patch. They just use the kernel side patch to solve this problem. So if you still want to move this bug forward, how about we start the review process for your gaia side patch and see what feedback we get?

Thanks

vance

Comment 16

[viral [:viralwang]]

I already send the patch in bug 932698.
It's r- so far.

Comment 17

[Duan Xiaodong]

HI viral,

The patch in bug 932698 has been merged to ZTE source code today and it will be tested carefully later by our QA.

Thanks,
Xiaodong

Comment 18

[Keven Kuo [:kkuo]]

Assign this case to Viral, since he is working on it.

Hi! Xiaodong,

Any update from your side? Thanks

--
Keven

Comment 19

[Duan Xiaodong]

Hi Keven & Viral,

As far as I know, no issue has been reported by QA after merging patch in bug 932698.

Thanks,
Xiaodong

Comment 20

[Kai-Chih Hu [:khu]]

No follow up updates anymore. Remove the blocking-b2g flag for now, and please nominate it back if it's required. Thank you.

Comment 21

[Gabriele Svelto [:gsvelto]]

Shouldn't we close this as a dup of bug 932698? Comment 19 seems to confirm this.

Comment 22

[viral [:viralwang]]

close this bug