Bumping up the priority due to high risk and the fact that 70 is going to stable so soon. Joseph, did they repro this with Gio's fix in place? I know that the logs look a bit different, but I just want to make sure we're looking at the most recent state.

Also, can we request some logs from them that also include the chrome user logs? That would help us see what tether/unlock are doing.

Re: comment #1: Their build did *not* have Gio's fix included.

Right, it was clear that the first repro Joseph mentioned didn't have that fix. I'm asking whether the second one (which produced the logs attached here) was on the same build, or if they flashed to a new build that included Gio's fix.

It's possible that there is a race somewhere in Chrome's scanning code, but it's impossible to say without any chrome-side logs :/

josephsih: Would it be possible to get chrome-side logs? From Jeremy's logs last time, user_chrome.log and bt_messages where the most useful to me.

Both logs mentioned in C#0 were generated with R71-11117.0.0 without Gio's fix.

I know that user_chrome.log is important to investigate what happened on chrome side. But it happened that it was not saved in the tarball. The machine had been updated with another build since then such that there was no way to get the user_chrome.log.

The only way is to try to repro this issue again and save all logs for investigation. I will do this on my side. At the same time, would you please also conduct tests on your side? (Since I will be on duty of chrome os sheriff for the whole next week, I will have less time on this.)

One thing maybe worth noting is that there was only 1 pixel phone available when the logs were generated in the test. The issue was not related with abnormal behavior triggered by connection attempts. The issue seemed to be more related with MT managing to discover devices with the same login account and somehow triggered something abnormal. Hence, when conducting the test on your side, you may try 1 Eve with 1 phone (instead of multiple phones) test setup.

By searching around the existing logs that we had, I just found another two log tarballs that Intel sent in b/116758940: [EVE StpD1] Host scan stopped during long run LE test

One of the tarballs attached below exhibited the same symptom -- chrome did not start discovery suddenly. Luckily, Intel had saved user_chrome.log in the tarball.

The logs showed that there were pause/unpause discovery calls going on. The last set of them looked like this

  2018-10-05T11:03:15.304032+00:00 DEBUG bluetoothd[2331]: src/adapter.c:start_discovery() sender :1.17
  2018-10-05T11:03:30.854338+00:00 DEBUG bluetoothd[2331]: src/adapter.c:pause_discovery() sender :1.17
  2018-10-05T11:03:31.513991+00:00 DEBUG bluetoothd[2331]: src/adapter.c:unpause_discovery() sender :1.17
  2018-10-05T11:03:44.253481+00:00 DEBUG bluetoothd[2331]: src/adapter.c:stop_discovery() sender :1.17

And then no more start_discovery() was observed. 3 minutes later, all temporary devices were purged

  2018-10-05T11:06:44.864855+00:00 DEBUG bluetoothd[2331]: src/adapter.c:remove_temp_devices() /org/bluez/hci0

Looking up the user_chrome.log, it showed that (the hour below = the hour above + 8 due to timezone conversion)

  [1382:1382:1005/190344.271901:INFO:ble_scanner_impl.cc(259)] Stopped discovery session successfully.
  [1382:1382:1005/190344.479833:VERBOSE1:lock_state_controller.cc(490)] PreLockAnimationFinished
  [1382:1382:1005/190344.512403:VERBOSE1:lock_state_controller.cc(523)] PostLockAnimationFinished
  [1382:1382:1005/190345.862107:VERBOSE1:device_event_log_impl.cc(161)] [19:03:45.862] Network: USER: network_state_handler.cc:979 RequestScan: wifi-tether
  [1382:1382:1005/190345.862180:VERBOSE1:device_event_log_impl.cc(161)] [19:03:45.862] Network: EVENT: network_state_handler.cc:1830 NOTIFY:ScanRequested
  [1382:1382:1005/190345.863733:INFO:host_scan_scheduler_impl.cc(183)] Skipping scan attempt because the screen is locked.
  
Did this mean that the screen was locked at this time such that all following scan attempts were skipped?

As the machine was placed in Google Taipei office to conduct the MT test, the screen lock was not done manually by anyone. There was no such symptom caused by screen lock before. Is this expected? How could we prevent this from occurring when conducting MT test? Thanks!

Deleted: 1005_1855_mt_0x38_Run2_Intel_Eve_clean_Issue_no_start_discovery.tbz2 3.7 MB

1005_1855_mt_0x38_Run2_Intel_Eve_clean_Issue_no_start_discovery.tbz2 3.7 MB Download

Yes, it does appear that the screen became locked. Perhaps your device went to sleep by itself?

Yeah, it actually is a new thing that we don't scan while on the lock screen. One option is to keep the screen on my going to Settings > Power and changing the "when idle" dropdown to "Keep Display on".

Jeremy, thank you for the tips about keeping display on! I am testing with this setting. If it works, I will close this issue.

This seems to work! I do not hear complaints from Intel so let me close this issue. Thanks Jeremy for the tips!