desktop-packages team mailing list archive

[Tony Espy <1480877@xxxxxxxxxxxxxxxxxx>]

So re-testing with krillin ( rc-proposed, #162 ).

Confirmed that using a patched version of dbus 1.8, the match rule
limits aren't enforced, so each of the loc processes slowly grows its
number of match rules till they cap out at 5000 each.

So, WiFi enabled & connected, with the HERE app running *or* the Nearby
or Today scopes currently selected.

The scan interval of the phone is controlled by time in a particular
state.  If "disconnected", the scan interval starts low, and eventually
tops out at ~60s.  Likewise, if "connected" ( to an AP ), it'll top out
at 2m.

What's odd, is how location-services seems to be influencing scanning.
If I bring the HERE app, or the Today or Nearby scopes to the
foreground, the phone starts to do WiFi scans every 15s.  If I bring
another app to the foreground, this behavior stops, most of the time.
I've able to get the phone into a state where the interval stays at 15s,
no matter what app/scope is visible.  Perhaps the location-service is
losing state?  Confirming scan interval is a matter or running wpa_cli
and watching the events output as scan occur.

Note, to mimic normal usage, I usually start fix or six apps ( camera, system settings, clock, term, messages, music ).
Also, my confirmation of whether or not the the bug is occurring is *not* based on top, it's based on observation of the UI.

I see UI freezes that occur in sync with WiFi scans, that can last
anywhere from 1-6s when:

 - using the switcher, animation ( horizontal or vertical ) freezes
 - edges stop responding
 - app scrolling freezes

I also began to see the Shutdown menu displayed every so often when I
let the screen go off, and then woke via the power button.

Freezes start at around 1s when the match rules for the loc services
hits ~1000.  As the match rules continue to increase, the lockups do
seem to last a bit longer over time.  When they've maxed out, the
lockups might be as long as 3-5s.

When I disabled WiFi, the UI freezes disappeared.  This also reset the
counts...  so I let the phone run overnight and the counts rose back up
again, and the freezes returned.  Note, overnight all of the running
apps appear to have been killed.

Finally, I left WiFi on, but instead stopped the location services
process per comment #56.  At this point the freezes go away almost
completely ( note by disabling location services, the scan interval goes
back up to 60s ).   I say *almost* go away as there's still the
slightest tick whenever a scan occurs, but it's orders of magnitude
smaller than when the rule counts have been max'd out.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1480877

Title:
  Access points' "PropertiesChanged" dbus signals freeze UI on mobile
  devices

Status in Canonical System Image:
  Confirmed
Status in indicator-network package in Ubuntu:
  Incomplete
Status in network-manager package in Ubuntu:
  Incomplete
Status in location-service package in Ubuntu RTM:
  New
Status in network-manager package in Ubuntu RTM:
  Incomplete

Bug description:
  Krillin, rc-proposed, r83

  
  DESCRIPTION:
  I've been trying to track down the cause of the occasional UI freezes on my Krillin device, and I noticed that whenever the UI freezes for 2-4 seconds, I get a burst of "PropertiesChanged" signals in dbus-monitor

  Here's a log of what's shown in dbus-monitor:
  http://pastebin.ubuntu.com/11992322/

  I'd guess the problem is in the code that actually catches the signals
  and acts accordingly.

  HOW TO REPRODUCE: 
  1) Move to a place where many wifi hotspots are available
  2) Connect the device via USB and run "phablet-shell" and then "dbus-monitor"
  3) Use the device while keeping an eye on dbus-monitor output

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1480877/+subscriptions