start_discovery called continuously after stop_discovery failed due to "in progress" |
|
Issue descriptionEve Chrome Version: CHROMEOS_RELEASE_BUILDER_PATH=eve-release/R62-9901.54.0 Intel firmware: 0xF3 The problem: sometimes, chrome called stop_discovery prior to the completion of the previous start_discovery operation. This would result in "start/stop discovery in progress" busy error. It looks that chrome might not handle the busy error properly such that chrome would then try to call start_discovery continuously without calling stop_discovery again. What is the expected behavior of chrome: when stop_discovery failed due to busy error, chrome is expected to call stop_discovery again after a while before issuing any start_discovery afterwards. About the "start/stop discovery in progress" error, refer to Sonny's Related CL: Fix race condition in bluez discovery operations (https://chromium-review.googlesource.com/#/c/chromiumos/third_party/bluez/+/677467/) - This CL makes bluetoothd send a busy error ("start/stop discovery in progress") back to chrome. - However, it looks that chrome might not handle the busy error properly yet. ----- more explanation below ----- The correct cycles of start_discovery and stop_discovery should look something like (1) calling start_discovery -> (2) receiving start_discovery_complete -> (3) calling stop_discovery -> (4) receiving stop_discovery_complete -> (and the above operations loop over and over....) In /var/log/messages, the correct logs look something like (1) 2017-10-28T01:23:36.550111+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery() sender :1.13 (2) 2017-10-28T01:23:36.646617+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery_complete() status 0x00 (3) 2017-10-28T01:23:37.357681+08:00 DEBUG bluetoothd[2286]: src/adapter.c:stop_discovery() sender :1.13 (4) 2017-10-28T01:23:37.376830+08:00 DEBUG bluetoothd[2286]: src/adapter.c:stop_discovery_complete() status 0x00 However, if chrome called stop_discovery before start_discovery_complete was received, something bad occurred. In the /var/log/messages, 2017-10-28T02:20:27.674491+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery() sender :1.13 2017-10-28T02:20:28.355394+08:00 DEBUG bluetoothd[2286]: src/adapter.c:stop_discovery() sender :1.13 2017-10-28T02:20:28.355419+08:00 DEBUG bluetoothd[2286]: src/adapter.c:stop_discovery() error: start discovery in progress <-- should call stop_discovery() after a while 2017-10-28T02:20:28.356134+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery_complete() status 0x00 2017-10-28T02:20:28.762814+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery() sender :1.13 <-- start_discovery() would not succeed since it was still discovering. 2017-10-28T02:20:32.210088+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery() sender :1.13 2017-10-28T02:20:32.625131+08:00 DEBUG bluetoothd[2286]: src/adapter.c:start_discovery() sender :1.13 ... chrome kept calling start_discovery() ... When calling stop_discovery(), the error "start discovery in progress" was expected because start_discovery_complete was not received yet. This was fine. However, one would expect chrome to call stop_discovery() again after a while to actually stop discovery. However, chromes kept calling start_discovery() continuously. It would fail since the adapter had already been discovering. The corresponding ui.LATEST log: [1282:1282:1028/022028.358746:ERROR:device_event_log_impl.cc(156)] [02:20:28.358] Bluetooth: bluetooth_adapter_bluez.cc:1604 /org/bluez/hci0: Failed to stop discovery: org.bluez.Error.InProgress: Operation already in progress [1282:1282:1028/022028.359294:ERROR:ble_scanner.cc(266)] Error stopping discovery session. [1282:1282:1028/022028.763710:ERROR:device_event_log_impl.cc(156)] [02:20:28.763] Bluetooth: bluetooth_adapter_bluez.cc:1570 /org/bluez/hci0: Failed to start discovery: org.bluez.Error.InProgress: Operation already in progress [1282:1282:1028/022028.764610:ERROR:ble_scanner.cc(233)] Error starting discovery session. Initialization failed. ... more such errors repeated ... The tarball of the logs: https://drive.google.com/a/google.com/file/d/1oTjucGns16tXEss2ChLD5P8cx8OKlsg2/view?usp=sharing
,
Oct 31 2017
Sonny, thanks for looking into and triage the issue! |
|
►
Sign in to add a comment |
|
Comment 1 by sonnysasaka@chromium.org
, Oct 30 2017