Hi Amit, On Mon, Oct 8, 2018 at 1:36 PM Amit K Bag <amit.k.bag@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Scan_Stop.7z > Hello all, > > I am running some stress test on chromebook with 5.44 bluez version > and 4.4 kernel version. > In this test it will scan for device connect to device do some data > transfer enable disable advertisement and repeat this in a loop. But > after hours of test scan request never sent to controller. From the > log I can see last time kernel sent the scan stop request to > controller and the scan stooped from controller side. > > In this log mgmt discovering stop callback event at some point is > not received at Bluez adapter .So that > Kernel and bluez host lost the sync on the discovery state .And > further Discovery_start() request has been ignored . > > In previous success case I can see the below 2 logs > Line 79243: 2018-09-11T11:50:41.724644+05:30 DEBUG kernel: [ > 105.371680] mgmt.c:mgmt_discovering() hci0 discovering 0 > Line 79284: 2018-09-11T11:50:41.725959+05:30 DEBUG bluetoothd[2265]: > src/adapter.c:discovering_callback() hci0 type 6 discovering 0 method > 0 > > But in issue case only kernel debug message is seen in messag log as > below but bluez log is not seen. > Line 4048575: 2018-09-11T12:03:59.350884+05:30 DEBUG kernel: [ > 634.306257] mgmt.c:mgmt_discovering() hci0 discovering 0 Somewhere the message is dropped then, do you have btmon logs? That should be able to decoce mgmt event nowadays so we can least know if the message reached userspace and was dropped by bluetoothd or not. > Further when bluez try to start scanning in kernel its always called > stop_discovery(). > > please suggest how to fix this issue. > > Thanks & Regards, > Amit Bag -- Luiz Augusto von Dentz
