[Buri] Wifi freezes after toggling on

RESOLVED DUPLICATE of bug 880617

Status

RESOLVED DUPLICATE of bug 880617
6 years ago
6 years ago

People

(Reporter: jhammink, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(b2g18+)

Details

(Reporter)

Description

6 years ago
Seen while running:Buri, with 5/6 himachi build and Mozilla RIL

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/499c3627e89a
Gaia   495c46489eb256be598a19ea54d7837ce4fc385b
BuildID 20130502070205
Version 18.0

STR:
1. Go to settings=>Wifi and toggle wifi on

Actual:
No networks are scanned, wifi toggle is frozen and can't be switched off.

The following appears in logcat:
01-01 01:31:12.939: INFO/IdleService(143): next timeout 1000 msec from now
01-01 01:31:12.939: INFO/IdleService(143): SetTimerExpiryIfBefore: next timeout 1000 msec from now
01-01 01:31:12.939: INFO/IdleService(143): reset timer expiry to 1007 msec from now
01-01 01:31:12.939: INFO/IdleService(143): Reset idle timeout: tell observer 483d3350 user is back
01-01 01:31:13.949: INFO/IdleService(143): Get idle time: time since reset 913 msec
01-01 01:31:13.949: INFO/IdleService(143): Idle timer callback: current idle time 913 msec
01-01 01:31:13.949: INFO/IdleService(143): next timeout 86 msec from now
01-01 01:31:13.949: INFO/IdleService(143): SetTimerExpiryIfBefore: next timeout 86 msec from now
01-01 01:31:13.949: INFO/IdleService(143): reset timer expiry to 96 msec from now
01-01 01:31:14.039: INFO/IdleService(143): Get idle time: time since reset 1010 msec
01-01 01:31:14.039: INFO/IdleService(143): Idle timer callback: current idle time 1010 msec
01-01 01:31:14.039: INFO/IdleService(143): next timeout 4294967293989 msec from now
01-01 01:31:14.049: INFO/IdleService(143): SetTimerExpiryIfBefore: next timeout 4294967293987 msec from now
01-01 01:31:14.049: INFO/IdleService(143): reset timer expiry to 4294967293996 msec from now
01-01 01:31:14.049: INFO/IdleService(143): Idle timer callback: tell observer 483d3350 user is idle
01-01 01:31:14.049: INFO/IdleService(143): Get idle time: time since reset 1014 msec


Expected:
Wifi networks are scanned, and wifi can be toggled off.
(Reporter)

Updated

6 years ago
Blocks: 869250
I synced with the same gaia/gecko version and couldn't reproduce this issue. Maybe we need help from QA team to confirm the STR and fail rate.
Keywords: smoketest → qawanted
blocking-b2g: leo+ → leo?
Duplicate of this bug: 869250
This should be tef? because its on buri with hamachi build?
renoming for tef.
blocking-b2g: leo? → tef?

Updated

6 years ago
See Also: → bug 869020
Running the Partner Build on Buri device from 5-3, I am not able to reproduce this issue.
Keywords: qawanted
5/7 commercial ril for buri doesn't show this either.

Not seeing this w/ 
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/af99cb91eec0
Gaia   89a9c5de7313dfd1095d0ff46988bc91a35cbe9c
BuildID 20130508104236
Version 18.0

Having said that I think he may have reached the same condition as bug 860972
John, if this is still happening can you check to see if you're getting a MAC address please?

Easiest way to check is if you go to settings -> device info -> more info =>  mac address section

If you can report what's listed there, that would help.
Flags: needinfo?(jhammink)

Comment 8

6 years ago
This issue still reproduces on Buri device using Mozilla RIL
Build ID: 20130508104236
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/af99cb91eec0
Gaia: 89a9c5de7313dfd1095d0ff46988bc91a35cbe9c
Version 18.0

After toggling wifi button on, no networks are scanned. Wifi toggle is frozen and can't be switched off.

Comment 9

6 years ago
ip6tnl0   Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          NOARP  MTU:1452  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          [NO FLAGS]  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet1    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          [NO FLAGS]  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet2    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          [NO FLAGS]  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet3    Link encap:Ethernet  HWaddr BE:E2:14:38:92:93
          BROADCAST MULTICAST  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet4    Link encap:Ethernet  HWaddr 46:7F:92:2C:63:4F
          BROADCAST MULTICAST  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet5    Link encap:Ethernet  HWaddr A2:14:16:A1:AC:B0
          BROADCAST MULTICAST  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet6    Link encap:Ethernet  HWaddr B6:BC:9F:67:6A:DF
          BROADCAST MULTICAST  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

rmnet7    Link encap:Ethernet  HWaddr 8E:54:6D:33:42:BF
          BROADCAST MULTICAST  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

sit0      Link encap:UNSPEC  HWaddr 00-00-00-00-09-00-04-37-00-00-00-00-00-00-00-00
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
Comment 0 and comment 8 both suggest this is Mozilla RIL only, not a blocker.
blocking-b2g: tef? → -
Duplicate of this bug: 872510
RIL has nothing to do with the Wifi getting a MAC address, AFAIK.  I'm seeing a very similar thing where the MAC address is not being shown correctly on the Inari.
blocking-b2g: - → tef?
Possibly a Gonk issue in our builds.  Sorry.  Misunderstood the intent of comment 10.  Still asking for blocking because it hinders automation.
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #13)
> Possibly a Gonk issue in our builds.  Sorry.  Misunderstood the intent of
> comment 10.  Still asking for blocking because it hinders automation.

Can we ask partner to provide tool to update MAC address for verifying this bug?
Based on previous comments I don't think this should be a 1.0.1 blocker
Whiteboard: [tef-triage]
(In reply to Ken Chang from comment #14)
> (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from
> comment #13)
> > Possibly a Gonk issue in our builds.  Sorry.  Misunderstood the intent of
> > comment 10.  Still asking for blocking because it hinders automation.
> 
> Can we ask partner to provide tool to update MAC address for verifying this
> bug?

Ken, it is provided over email to you
blocking-b2g: tef? → -
tracking-b2g18: --- → +
Whiteboard: [tef-triage]
Tracking but not blocking - can be worked around (although annoying).

Comment 18

6 years ago
This issue no longer reproduces on the v11/v101 comm/moz RILs:
Build ID:20130523070210
Gecko:047b7010c99a
Gaia:09299399500b50de72cdd3b4365fc6455bbbb145

Comment 19

6 years ago
Didn't see it happens again in recent builds. Close it as WFM. Please reopen it if it's still happened.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: needinfo?(jhammink)
Resolution: --- → WORKSFORME
Still seeing this issue on 1.1 and not on Partner builds. 2013-06-24-07-02-24
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Sigh.  This was closed off incorrectly.  The bug tracking this is now bug 880617; 
This has been ongoing for a while.

Please ask the people that are experiencing this issue rather than closing it off completely.
Status: REOPENED → RESOLVED
blocking-b2g: - → ---
Last Resolved: 6 years ago6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 880617
You need to log in before you can comment on or make changes to this bug.