Closed Bug 985281 Opened 10 years ago Closed 6 years ago

[DSDS] It takes about 6 seconds after entering correct PIN 2 code to have accurate FDN enabled UI displayed.

Categories

(Firefox OS Graveyard :: Vendcom, defect, P3)

Product:
Firefox OS Graveyard
Component:
Vendcom
Platform:
x86_64
Gonk (Firefox OS)
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: echu, Unassigned)

Details

(Keywords: perf, Whiteboard: [c=progress p= s= u=] dsdsrun1.4, [POVB])

Attachments

(4 files)

VIDEO0001.mp4
2.56 MB, video/mp4
Details
timestamp: 7:19, 3/18
455.75 KB, text/plain
Details
fugu_fdnslow_radio.txt
890.65 KB, text/plain
Details
modem_update.tar
5.78 MB, application/x-tar
Details
Attached video VIDEO0001.mp4 — 
After press okay button in PIN 2 code page when trying to enable FDN, it takes 6 second to have final FDN enable UI shown. From the video you can see after pressing okay button, it stayed in PIN 2 enter page for a while, then back to FDN setting page but FDN item is still "Disabled" even toggle switch was on, after anther couple seconds, it became "Enabled".

Disable FDN has no such problem. And Buri has no such bug as well.

* Build Number
Fugur  
Gaia      d2651c13d6370d62bf833b31c7e2e5f054510136
Gecko     c8a17e25111585c0eebb829f8208190ea432c71e
BuildID   20140318053055
Version   30.0a1

* Reproduce Steps
1. Enable FDN, check the UI.

* Expected Result
Like Disable FDN process, it should right go back to FDN setting page and show "Enable" immediately under FDN item.

* Actual Result
Overall about 6 seconds to complete the process.

* Occurrence rate
100%
Not sure if this is a good time to nominate the bug. The impact I can see is 6 seconds is a huge delay which makes users think that the OS is really unresponsive. Moreover, the inconsistency between switch toggle and "Enabled/Disabled" information below FDN item is also another bad user experience.
blocking-b2g: --- → 1.4?
Attached file timestamp: 7:19, 3/18 — 

    
    

    
  
Hi Enpei, I wonder if other device has sample problem. After enabling FDN, device need time to read the FDN phonebook from SIM.

    
    

    
  
(In reply to Ken Chang[:ken] from comment #3)
> Hi Enpei, I wonder if other device has sample problem. After enabling FDN,
> device need time to read the FDN phonebook from SIM.

Hi Ken, Tarako has the same problem while Buri doesn't which is single SIM though. Hope this can clarify your question.

    
    

    
  
QA,

Can we please test with tiling disabled?
blocking-b2g: 1.4? → 1.4+
Keywords: qawanted
Keywords: perf

    
    

    
  
(In reply to Preeti Raghunath(:Preeti) from comment #5)
> QA,
> 
> Can we please test with tiling disabled?

I really doubt that tiling is responsible for this.

    
    

    
  
(In reply to Preeti Raghunath(:Preeti) from comment #5)
> QA,
> 
> Can we please test with tiling disabled?

What is tiling? How to disable it?

    
    

    
  
(In reply to Enpei from comment #7)
> (In reply to Preeti Raghunath(:Preeti) from comment #5)
> > QA,
> > 
> > Can we please test with tiling disabled?
> 
> What is tiling? How to disable it?

It's in the developer settings:

Layers: Enable Tiles

Uncheck that & restart the phone. Then, try to reproduce the bug.
Priority: -- → P1
Whiteboard: dsdsrun1.4 → [c=progress p= s= u=1.4] dsdsrun1.4

    
    

    
  
(In reply to Preeti Raghunath(:Preeti) from comment #5)
> QA,
> 
> Can we please test with tiling disabled?

No differences even do so.
Keywords: qawanted

    
    

    
  
(In reply to Enpei from comment #4)
> Hi Ken, Tarako has the same problem while Buri doesn't which is single SIM
> though. Hope this can clarify your question.

Ken, is this a platform issue, or POVB issue?
Flags: needinfo?(kchang)

    
    

    
  
I will check this.
Flags: needinfo?(kchang) → needinfo?(echen)

    
    

    
  
Thanks, edgar. Here are what I find.
*Disabling flow takes 260ms to finish in RadioInterfaceLayer.
//RadioInterfaceLayer receives RIL:SetCardLock and tries to send to rilc at 07:18:41.330
03-18 07:18:41.330 I/Gecko   (  107): -*- RadioInterfaceLayer: Received 'RIL:SetCardLock' message from content process
03-18 07:18:41.330 I/Gecko  (  107): RIL Worker: [0] Received chrome message {"lockType":"fdn"..."enabled":false
...
03-18 07:18:41.330 I/Gecko   (  107): RIL Worker: [0] New outgoing parcel of type 43

//RadioInterfaceLayer get response from rilc at 07:18:41.470
03-18 07:18:41.590 I/Gecko   (  107): -*- RadioInterface[0]: Received message from worker: {"lockType":"fdn",

*But enabling flow takes about 3s to finish.
//RadioInterfaceLayer receives RIL:SetCardLock and tries to send to rilc at 07:18:53.690
03-18 07:18:53.690 I/Gecko   (  107): RIL Worker: [0] Received chrome message {"lockType":"fdn".."enabled":true,
....
//RadioInterfaceLayer  get response from rilc at 03-18 07:18:56.690
03-18 07:18:56.690 I/Gecko   (  107): -*- RadioInterface[0]: Received message from worker: {"lockType":"fdn","pin2":"1234","enabled":true,

I think partner needs to check this problem as well. ni?sam.
But we still need to find out where the remaining 3 seconds come form.
Flags: needinfo?(sam.hua)

    
    

    
  
(In reply to Ken Chang[:ken] from comment #12)
> Thanks, edgar. Here are what I find.
> *Disabling flow takes 260ms to finish in RadioInterfaceLayer.
> //RadioInterfaceLayer receives RIL:SetCardLock and tries to send to rilc at
> 07:18:41.330
> 03-18 07:18:41.330 I/Gecko   (  107): -*- RadioInterfaceLayer: Received
> 'RIL:SetCardLock' message from content process
> 03-18 07:18:41.330 I/Gecko  (  107): RIL Worker: [0] Received chrome message
> {"lockType":"fdn"..."enabled":false
> ...
> 03-18 07:18:41.330 I/Gecko   (  107): RIL Worker: [0] New outgoing parcel of
> type 43
> 
> //RadioInterfaceLayer get response from rilc at 07:18:41.470
> 03-18 07:18:41.590 I/Gecko   (  107): -*- RadioInterface[0]: Received
> message from worker: {"lockType":"fdn",
> 
> *But enabling flow takes about 3s to finish.
> //RadioInterfaceLayer receives RIL:SetCardLock and tries to send to rilc at
> 07:18:53.690
> 03-18 07:18:53.690 I/Gecko   (  107): RIL Worker: [0] Received chrome
> message {"lockType":"fdn".."enabled":true,
> ....
> //RadioInterfaceLayer  get response from rilc at 03-18 07:18:56.690
> 03-18 07:18:56.690 I/Gecko   (  107): -*- RadioInterface[0]: Received
> message from worker: {"lockType":"fdn","pin2":"1234","enabled":true,
> 
> I think partner needs to check this problem as well. ni?sam.
> But we still need to find out where the remaining 3 seconds come form.

I think the remaining 3 seconds comes from the following query request.
It seems FDN page will query fdn status after enabling process is finished.
And it also takes almost 3 seconds to finish.

--
03-18 07:18:56.700 I/Gecko   (  107): -*- RadioInterfaceLayer: Received 'RIL:GetCardLockState' message from content process
03-18 07:18:56.710 I/Gecko   (  107): RIL Worker: [0] Received chrome message {"lockType":"fdn","requestId":"id{283ce368-bee7-475c-a582-c140fd963452}","rilMessageClientId":0,"rilMessageToken":44,"rilMessageType":"iccGetCardLockState"}

// It takes almost 3 sec to finish the request.

03-18 07:18:58.980 I/Gecko   (  107): -*- RadioInterface[0]: Received message from worker: {"lockType":"fdn","requestId":"id{283ce368-bee7-475c-a582-c140fd963452}","rilMessageClientId":0,"rilMessageToken":44,"rilMessageType":"iccGetCardLockState","facility":"FD","password":"","serviceClass":7,"rilRequestType":42,"rilRequestError":0,"success":true,"enabled":true}
03-18 07:18:59.020 I/Gecko   (  610): -*- RILContentHelper: Received message 'RIL:CardLockResult': {"clientId":0,"data":{"lockType":"fdn","requestId":"id{283ce368-bee7-475c-a582-c140fd963452}","rilMessageClientId":0,"rilMessageToken":44,"rilMessageType":"iccGetCardLockState","facility":"FD","password":"","serviceClass":7,"rilRequestType":42,"rilRequestError":0,"success":true,"enabled":true}}
--
Flags: needinfo?(echen)

    
    

    
  

      
      
      
      

        Attached file
          
        fugu_fdnslow_radio.txt
        — 
      

    


  
Attach log with radio log.

--
// Try to enable fdn

03-20 20:26:18.800   106   106 I Gecko   : -*- RadioInterfaceLayer: Received 'RIL:SetCardLock' message from content process
03-20 20:26:18.800   106   227 I Gecko   : RIL Worker: [0] Received chrome message {"lockType":"fdn","pin2":"1111","enabled":true,"requestId":"id{e8e36aa6-4b1e-4985-9ea5-9093b72521db}","rilMessageClientId":0,"rilMessageToken":30,"rilMessageType":"iccSetCardLock"}

// REQUEST_SET_FACILITY_LOCK takes 2 sec to finish.

03-20 20:26:20.690   100   134 D RILC    : [w] [0105]< SET_FACILITY_LOCK {1}
03-20 20:26:20.700   106   106 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"lockType":"fdn","pin2":"1111","enabled":true,"requestId":"id{e8e36aa6-4b1e-4985-9ea5-9093b72521db}","rilMessageClientId":0,"rilMessageToken":30,"rilMessageType":"iccSetCardLock","facility":"FD","password":"1111","serviceClass":7,"rilRequestType":43,"rilRequestError":0,"success":true,"retryCount":1}
03-20 20:26:20.700   408   408 I Gecko   : -*- RILContentHelper: Received message 'RIL:CardLockResult': {"clientId":0,"data":{"lockType":"fdn","pin2":"1111","enabled":true,"requestId":"id{e8e36aa6-4b1e-4985-9ea5-9093b72521db}","rilMessageClientId":0,"rilMessageToken":30,"rilMessageType":"iccSetCardLock","facility":"FD","password":"1111","serviceClass":7,"rilRequestType":43,"rilRequestError":0,"success":true,"retryCount":1}}

// Try to get fdn status

03-20 20:26:20.710   106   106 I Gecko   : -*- RadioInterfaceLayer: Received 'RIL:GetCardLockState' message from content process
03-20 20:26:20.720   106   227 I Gecko   : RIL Worker: [0] Received chrome message {"lockType":"fdn","requestId":"id{2cc80b3a-5b2b-4e96-932c-bc37eb9fb5a0}","rilMessageClientId":0,"rilMessageToken":32,"rilMessageType":"iccGetCardLockState"}

// REQUEST_QUERY_FACILITY_LOCK takes 3 sec to finish

03-20 20:26:23.610   100   134 D RILC    : [w] [0107]< QUERY_FACILITY_LOCK {1,7}
03-20 20:26:23.620   106   106 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"lockType":"fdn","requestId":"id{2cc80b3a-5b2b-4e96-932c-bc37eb9fb5a0}","rilMessageClientId":0,"rilMessageToken":32,"rilMessageType":"iccGetCardLockState","facility":"FD","password":"","serviceClass":7,"rilRequestType":42,"rilRequestError":0,"success":true,"enabled":true}
03-20 20:26:23.630   408   408 I Gecko   : -*- RILContentHelper: Received message 'RIL:CardLockResult': {"clientId":0,"data":{"lockType":"fdn","requestId":"id{2cc80b3a-5b2b-4e96-932c-bc37eb9fb5a0}","rilMessageClientId":0,"rilMessageToken":32,"rilMessageType":"iccGetCardLockState","facility":"FD","password":"","serviceClass":7,"rilRequestType":42,"rilRequestError":0,"success":true,"enabled":true}}
--
Component: Gaia::Settings → Vendcom
Whiteboard: [c=progress p= s= u=1.4] dsdsrun1.4 → [c=progress p= s= u=1.4] dsdsrun1.4, [POVB]

    
    

    
  
Enpei - Can you check if this happens on 1.3? Just curious if this is a regression or not.
Flags: needinfo?(echu)

    
    

    
  
DSDS 1.3 do not support FDN officially.
Flags: needinfo?(echu)

    
    

    
  
However, I've commented that Tarako also has the problem. That should be the answer you are looking for.

    
    

    
  
Hi Enpei & echen,

we just updated our modem, could u check the newest PAC in the FTP? 
I just tried in our latest build,but it is very quick!

03-21 15:59:53.640    94   122 I RILC    : enter processCommandsCallback
03-21 15:59:53.640    94   126 D RILC    : PCB request code 43 token 185
03-21 15:59:53.640    94   126 D RILC    : [0185]> SET_FACILITY_LOCK (FD,1,1234,7,(null))
03-21 15:59:53.640    94   126 D RIL     : onRequest: SET_FACILITY_LOCK sState=4
03-21 15:59:53.640    94   126 D RIL     : channel1 state: '0' 
03-21 15:59:53.640    94   126 D RIL     : get Channel ID '1'
03-21 15:59:53.640    94   126 D RIL     : requestFacilityLock: AT+CLCK="FD",1,"1234",7
03-21 15:59:53.640    94   126 D AT      : Channel1: AT> AT+CLCK="FD",1,"1234",7
03-21 15:59:53.780    94   220 D AT      : Channel0: AT< +ECIND: 3,3,0,0,1
03-21 15:59:53.780    94   220 D AT      : Channel1: AT< OK
03-21 15:59:53.790    94   126 D RILC    : [0185]< SET_FACILITY_LOCK {1}
03-21 15:59:53.790    94   126 D RIL     : put Channel ID '1'
03-21 15:59:53.790    94   126 I RILC    : -->SmsDispatch [126] free one command
03-21 15:59:54.030    94   122 I RILC    : enter processCommandsCallback
03-21 15:59:54.030    94   126 D RILC    : PCB request code 42 token 186
03-21 15:59:54.030    94   126 D RILC    : [0186]> QUERY_FACILITY_LOCK (FD,,7,(null))
03-21 15:59:54.030    94   126 D RIL     : onRequest: QUERY_FACILITY_LOCK sState=4
03-21 15:59:54.030    94   126 D RIL     : channel1 state: '0' 
03-21 15:59:54.030    94   126 D RIL     : get Channel ID '1'
03-21 15:59:54.030    94   126 D RIL     : requestFacilityLock: AT+CLCK="FD",2,"",7
03-21 15:59:54.030    94   126 D AT      : Channel1: AT> AT+CLCK="FD",2,"",7
03-21 15:59:54.030    94   220 D AT      : Channel1: AT< +CLCK: 1
03-21 15:59:54.030    94   220 D AT      : Channel1: AT< OK
03-21 15:59:54.030    94   126 D RILC    : [0186]< QUERY_FACILITY_LOCK {1,0}
03-21 15:59:54.030    94   126 D RIL     : put Channel ID '1'
03-21 15:59:54.030    94   126 I RILC    : -->SmsDispatch [126] free one command
03-21 15:59:58.030    94   220 D AT      : Channel0: AT< +CSQ: 8,6
03-21 15:59:58.030    94   220 D RILC    : [UNSL]< UNSOL_SIGNAL_STRENGTH

    
    

    
  
Hi Sam,

The majority of our colleagues can only update base image from https://github.com/sprd-ffos/B2G.git. If newest PAC works, is it possible we can still build the latest image with the fix included?

Thanks.

    
    

    
  

      
      
      
      

        Attached file
          
        modem_update.tar
        — 
      

    


  
modem image.
Flags: needinfo?(sam.hua)

    
    

    
  
Hi Enpei,

We can't build modem image. it is provided by modem team of SPRD and is packaged into PAC.
You can use modem_update.tar to update modem.

    
    

    
  
Remove flag since it's a POVB bug.
blocking-b2g: 1.4+ → ---
Priority: P1 → P3
Whiteboard: [c=progress p= s= u=1.4] dsdsrun1.4, [POVB] → [c=progress p= s= u=] dsdsrun1.4, [POVB]

    
    

    
  
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: