And here are the following comments.

#8
Hello Ethan,

Sorry for the confusion I made in #3. When I mentioned "The change of setting will power down adapter", I meant that the adapter(the virtual one) in BlueZ userspace was destroyed after receiving the event on new setting(powering down in this case) coming from kernel space. During the adapter bring-down, all connections were removed, so the first thing users noticed is device disconnection. So the question is why USB device disconnected in the first place?

2016-11-01T16:26:44.011699-07:00 INFO kernel: [ 3272.870144] usb 1-8: USB disconnect, device number 4                                                                                                                                                                               12394 2016-11-01T16:26:44.011781-07:00 DEBUG bluetoothd[4829]: src/adapter.c:dev_class_changed_callback() Class: 0x000000                                                                                                                                                                 
12395 2016-11-01T16:26:44.011905-07:00 DEBUG bluetoothd[4829]: src/adapter.c:new_settings_callback() Settings: 0x00000ad0                                                                                                                                                                 12396 2016-11-01T16:26:44.011923-07:00 DEBUG bluetoothd[4829]: src/adapter.c:settings_changed() Changed settings: 0x00000001
Nov 9, 2016

#9 matt.chen@intel.com
Hi Miao,

I　am testing on it with my Samus. But so far hasn't yet seen the issue reproduced.
I left my BT mouse and keyboard connecting. And sometimes get back to move or click the mouse or press the keyboard. Not seen the issue.

I will keep testing the issue here.

The BT devices I am testing on are:
1) Mouse : Dell WM527 Mouse
2) Keyboard : Dell WK717Keyboard.

#10 matt.chen@intel.com
After keeping connecting to both BT mouse and keyboard, the issue is not reproduced by my side around 10 ours. I do not see the same symptom.
But I do see some of "USB disconnect" from the system.

#11 matt.chen@intel.com
Hi Miao,

How easy do reproduce this issue in your samus ?
I keep running my samus as the same image but I did not find the issue was reproduced.

How is the failed rate ?

#12 mcchou@google.com
+Vladimir

Hello Matt,

It took me 50 minutes to reproduced it last time, so it is not that easy to repro. Vladimir is the reporter of this issue, he can give us a better description on the symptom he saw.

Vladimir, can you provide more info about the repro step and the repro rate? Thanks!

#13 weiv@google.com
Hello,

This is my experience. I started using this machine in October 2015. Ever since I got it, I would try to use BT keyboard and mouse at home. Machine would be also connected to a monitor through a usb-c to DP connector.

From October 2015 through late September 2016, keyboard and mouse would stop working every few minutes. The light on keyboard would start blinking as if it was reconnecting. After 20-30 seconds, they would start working again. This has been repeated with several different keyboards and mice (Apple, Logitech, Microsoft). I know that at least one other person had a similar problem, but they just exchanged their Samus for a new one.

Starting in late September (or early October), after a disconnect Bluetooth would get disabled on Samus. That is when I reported this.

Please let me know if you have any further questions.

#14 mcchou@google.com
Hello Matt,

Is there any update on this issue?
Dec 5, 2016

#15 matt.chen@intel.com
Hi Goolers,

Sorry for the late update, I was away for another wifi critical issue in last 2 weeks.

Re#13
That repo looks bit intermittent, I think I never keep using BT keyboard and mouse in that long time.

I think it would be good to provide the BT device model so I may have a chance catch up for trying.

If the issue is not quite easy to reproduce, we will get to evaluate the failed rate, say how many DUT are affected. Also if the issue is reproduced, we would count on the logs like /var/log/messages, I think that is helpful.

I will also get to run my Samus once it is available here.

#16 josephsih@chromium.org
(This comment is copied from Comment#6 of partner   issue 56377  .)

Hi Intel team:

It looks that the Intel 7260 still suffers from a disconnection problem as well as a controller reset issue.

For your reference, last time, we tracked a related issue in
-  Issue 472604 : Bluetooth mouse (Apple magic mouse) stops working after 2-3 minutes of use (https://bugs.chromium.org/p/chromium/issues/detail?id=472604)
- chrome-os-partner 53128: Intel WP2 BT FW update (Bluetooth mouse stops working after 2-3 minutes of use) (https://code.google.com/p/chrome-os-partner/issues/detail?id=53128)

With the previous firmware update, the disconnection would NOT occur within a few minutes. Instead, it appears to happen from time to time on a DAILY basis according to our internal user cwmorris@google.com. I myself am not able to reproduce the problem though. However, the problems have also been observed by a couple of users and our testers.

cwmorris@ carefully captured a number of logs which are very useful to show 3 strange behaviors. Note that all the strange behaviors might initially result from the same cause -- USB disconnection.

---------------------------------------------------------------------------------------
Problem 1: USB disconnect, and reconnection may take up to 90 seconds sometimes. This makes the reconnection of bluetooth peripherals quite slow. A BLE mouse takes about 3 seconds to reconnect. A classic keyboard might take 10 to 90 seconds to reconnect. A snippet of the log:

2016-12-10T19:31:29.396861+00:00 INFO kernel: [12317.417536] usb 1-8: USB disconnect, device number 7
2016-12-10T19:31:29.978379+00:00 INFO kernel: [12317.999500] usb 1-8: New USB device found, idVendor=8087, idProduct=07dc
2016-12-10T19:31:29.997845+00:00 INFO kernel: [12318.015815] Bluetooth: hci0: read Intel version: 3707100180012d0d25
2016-12-10T19:31:29.997858+00:00 INFO kernel: [12318.015825] Bluetooth: hci0: Intel device is already patched. patch num: 25
2016-12-10T19:31:32.880864+00:00 INFO kernel: [12320.904326] input: MX Anywhere 2 as /devices/virtual/misc/uhid/0005:046D:B013.0006/input/input16
2016-12-10T19:31:32.880880+00:00 INFO kernel: [12320.904648] hid-generic 0005:046D:B013.0006: input,hidraw0: BLUETOOTH HID v0.07 Keyboard [MX Anywhere 2] on 6C:29:95:42:CB:05
2016-12-10T19:32:54.845835+00:00 INFO kernel: [12402.935197] input: Logitech K810 as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/bluetooth/hci0/hci0:256:7/0005:046D:B319.0007/input/input17
2016-12-10T19:32:54.845840+00:00 INFO kernel: [12402.935347] hid-generic 0005:046D:B319.0007: input,hidraw1: BLUETOOTH HID v12.02 Keyboard [Logitech K810] on 6c:29:95:42:cb:05

---------------------------------------------------------------------------------------
Problem 2: USB disconnect, and fail to reconnect. This makes the bluetooth peripherals not usable once the controller is disconnected. A snippet of the log:

2016-12-10T19:33:09.646904+00:00 INFO kernel: [12417.748415] usb 1-8: USB disconnect, device number 9
2016-12-10T19:33:10.307165+00:00 INFO kernel: [12418.408686] usb 1-8: New USB device found, idVendor=8087, idProduct=07dc
2016-12-10T19:33:10.320991+00:00 INFO kernel: [12418.423797] Bluetooth: hci0: read Intel version: 3707100180012d0d25
2016-12-10T19:33:10.320999+00:00 INFO kernel: [12418.423806] Bluetooth: hci0: Intel device is already patched. patch num: 25
2016-12-10T19:34:03.781362+00:00 ERR bluetoothd[3569]: Can't get HIDP connection info
2016-12-10T19:34:03.783314+00:00 ERR bluetoothd[3569]: connect error: Device or resource busy (16)

The above two ERR messages repeated several times… The controller was not connected.

---------------------------------------------------------------------------------------
Problem 3: USB disconnect, and controller becomes dead. The controller times out and is dead after kernel tries to reset the controller. A user has to reboot the chromebook when this situation is encountered. A snippet of the log:

2016-12-10T20:21:40.884844+00:00 INFO kernel: [15331.337898] usb 1-8: USB disconnect, device number 11
2016-12-10T20:21:46.244957+00:00 INFO kernel: [15336.702549] usb 1-8: New USB device found, idVendor=8087, idProduct=07dc
2016-12-10T20:21:48.250967+00:00 ERR kernel: [15338.709804] Bluetooth: hci0 command 0x0c03 tx timeout
2016-12-10T20:21:56.247884+00:00 ERR kernel: [15346.713253] Bluetooth: hci0 sending initial HCI reset command failed (-110)

---------------------------------------------------------------------------------------
Please use "tar xvf cwmorris_logs.tbz2" to extract 3 log files from the attached tarball.

Refer to the log, messages_ cwmorris_2 (), for detailed messages about the 3 problems described above. 
Also refer to btmon_logitech_cwmorris_1.log for Problems 1 & 2,
and refer to btmon_logitech_cwmorris_2.log for Problem 3.

#18 josephsih@chromium.org
Thank vpalatin@ for providing important insight to Comment#16! His description about the possible causes of triggering "USB disconnect" is as follows:
----------------------------------------------------------------

For USB devices, a disconnection is initiated by the device (by removing its pull-up on D+), usually for one of the following reasons:
- the USB device thinks the host is gone and goes to a low power mode.
 (usually means we have an issue on the USB link)
- the USB device crashed and reboot 
(during boot, it usually has no pull-up to avoid  a race condition with the host enumeration)
-  the USB device lost power.

To answer your question, on Samus, as far as I know, the Bluetooth power is ganged with the WLAN power, so you can trigger the 3rd condition by using the following 'ectool' command (which is cutting off the WLAN power load switch):
# ectool wireless 0x0 0x8

then to turn it back on
# ectool wireless 0x8 0x8

this will likely also make your Wifi very unhappy ...
(by the way the first 2 conditions are more common and might be your actually user issue).

# ectool wireless 0x0 0x8
Now=0x1, suspend=0x9
# dmesg -c
[       781.802372] usb 1-8: USB disconnect, device number 5

# ectool wireless 0x8 0x8
Now=0x9, suspend=0x9
# dmesg -c
[       874.074696] usb 1-8: new full-speed USB device number 6 using xhci-hcd
[       874.240235] usb 1-8: New USB device found, idVendor=8087, idProduct=07dc
[       874.240260] usb 1-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0


#19 josephsih@chromium.org
Hi Intel team:

  Per comment 18, the reason 2 "the USB device crashed and reboot" is a potential suspect since we always saw the "new full-speed USB device ..." message immediately after "USB disconnect". Therefore, there are two issues to address here:

 Issue 1 : potential bluetooth controller crash and reboot.

  Issue 2  : The bluetooth controller fails to reset correctly.
              Per Comment#16 Problems 2 & 3, the results could be either 
              "connect error: Device or resource busy" or 
              "hci0 sending initial HCI reset command failed" which leads to bluetooth disappearance.

#20 matt.chen@intel.com
Hi Joseph,

OK, that really explain well.
I think it is much clear that we can trigger the USB disconnect and observe if the BT controller is dead or alive.

Deleted: cwmorris_logs.tbz2 1.6 MB

cwmorris_logs.tbz2 1.6 MB Download

Hi Miao, thanks for mirroring this issue!

Hi Goolers,

Thanks for the update. I will get our eng having a look at these repo logs.

Is it able to add jaya.p.g@intel.com in the CC ?

Hi,

This is latest FW available for WP2 B5 SKU which is merged.
https://chromium-review.googlesource.com/#/c/342760/

Please verify with this FW.

Thanks,
Jaya Praveen G

Hi Jaya, current firmware on Samus

localhost ~ # hcitool cmd 3f 05             
< HCI Command: ogf 0x3f, ocf 0x0005, plen 0
> HCI Event: 0x0e plen 13
  01 05 FC 00 37 07 10 01 80 01 2D 0D 25

I think this is already the firmware that you mentioned in Comment#7. Could you confirm? Thanks.

Hi Joseph,

Got it. Using Patch REL: 37 only. Will look into the issue.

From the dmesg/syslogs attached, as per the problem 1, which is the major one, which is a random disconnection after a period of time.
This issue seems to be a controller issue, which is also causing the other 2 issues of not able to find the HID or tx timeout for HCI reset.
For checking this, as the failure of the case happening before,

2016-12-10T19:31:29.396861+00:00 INFO kernel: [12317.417536] usb 1-8: USB disconnect, device number 7

And as stated by vpalatin.
when you do USB power off and on and then suspend, we see the USB device crashed and reboot which is the root cause for the complete issue and this is correct.

So now to look into the issue, why this is getting caused when we suspend, need more insight into the issue which can be taken from Ellisys USB Analyzer logs rather than syslogs or dmesg.

@Matt, So to get the proper logs, either we have to reproduce and get the USB logs for getting the root cause for suspend causing the Controller crash and reboot or please either provide us the defect unit/samus device with the setup.

Re#10

Please let us know if you need anything apart from the following info.

Here is the recap of the setting where we observed the issue.
[Settings]
Device:            Samus
Chrome version:    55.0.2883.33
Chrome OS version: 8872.31.0 (Official Build) dev-channel test image
Firmware:          Google_Samus.6300.174.0
Remote devices:    A BR/EDR keyboard and a BR/EDR mouse

And here is the way to mimic USB disconnection (quote from #18 of comment #2)

the Bluetooth power is ganged with the WLAN power, so you can trigger the 3rd condition by using the following 'ectool' command (which is cutting off the WLAN power load switch):
# ectool wireless 0x0 0x8

then to turn it back on
# ectool wireless 0x8 0x8

this will likely also make your Wifi very unhappy ...
(by the way the first 2 conditions are more common and might be your actually user issue).

# ectool wireless 0x0 0x8
Now=0x1, suspend=0x9
# dmesg -c
[       781.802372] usb 1-8: USB disconnect, device number 5

# ectool wireless 0x8 0x8
Now=0x9, suspend=0x9
# dmesg -c
[       874.074696] usb 1-8: new full-speed USB device number 6 using xhci-hcd
[       874.240235] usb 1-8: New USB device found, idVendor=8087, idProduct=07dc
[       874.240260] usb 1-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0 

Hello Intel,

We have been hearing lots of complaints about this issue. Is there any update? Please let us know if there is anything we can help to resolve this issue.

Hi Miao,

We have a possible fix in https://code.google.com/p/chrome-os-partner/issues/detail?id=58860#c26.
Can it get to be tested ?

+cwmorris who is helping us verifying Intel's firmware.

I felt there are two actual problems in this issue.

1. "USB disconnect" problem

  This problem happens from time to time on some machines. Like our user cwmorris who had experienced the problem on a daily basis on a Samus near the end of the year 2016. But I am not able to reproduce this problem at all on my Samus. One could just use the command, grep "USB disconnect" /var/log/messages*, to check if this problem has ever happened on a machine. 

  Is it possible that this problem is hardware specific? Could the problem lie in the usb hub circuit or the bluetooth controller?

  I also saw this problem once on a machine with Qualcomm/Atheros chip. But most of the time I am aware of, the problem is related with Intel's chips.


2. "bluetooth controller reset" problem.

  This problem is only triggered when problem 1 above happened. Whenever "USB disconnect" problem occurs, it will try to reconnect in a short time, possible within 0.2 ~ 0.5 seconds. If the controller could be reset smoothly and correctly, a user might not be able to notice the "USB disconnect" problem. However, on some machines, a bluetooth controller might suffer from the reset problem more significantly. As an example, taking a look at cwmorris_logs.tbz2 in Comment#2, a Samus was used for less than 5 hours. The "USB disconnect" problem occurred 4 times. For the previous 3 times, the bluetooth controller could be reset correctly and smoothly. A user probably did not notice the problem in this case. However, at the 4th time of "USB disconnect", the bluetooth controller reset failed. As a consequence, the bluetoothd daemon lost its connection with the bluetooth controller, and no bluetooth peripherals could be used since. And the bluetooth icon would also disappear in the system tray on the bottom right corner of chrome UI. A user would definitely notice the problem this time.

  I tested current bluetooth firmware with the ectool commands from vpalatin@ to turn off/on the chip:

    turn off: $ ectool wireless 0x0 0x8  --> causing "USB disconnect"
    turn on:  $ ectool wireless 0x8 0x8  --> causing USB to reconnect

  I wrote a simple script to turn off and then turn on the controller 1000 times with current firmware on my Samus. The controller could be reset correctly and smoothly on the firmware without any issue. The script is as follows:

    $ for i in {1..1000}; do ectool wireless 0x0 0x8; sleep 5; ectool wireless 0x8 0x8; sleep 5; done

  But our user cwmorris@ has a Samus that sees the problem at the 4th time of "USB disconnect". Both of our machines use the same firmware. Is it possible that there might be some hardware issue in the bluetooth controller? 

Hi Joseph,

As per the test verification done with the FW(Patch 39), you are not able to reproduce the issue and also I had tried on Cyan (With WP2 B5 FW:39) and don't see the issue, done the test 1000 times with the script that you had done and also Matt tried from his side, where he also didn't observe the issue.
So to conclude, what has causing the issue, can we get the HW details with cwmorris@
is using. 
1. To conclude on hardware issue with Intel SKU, can we change to another WP2 B5(Change to another SKU if you have) with the same FW and see?
2. And also to just verify, can we change the Intel SKU from WP2 B5 to STP D1 in the Samus Chromebook and see if the issue observed in that. (To conclude the HW defective with the Intel SKU issue for WP2 B5 Intel Controller)
3. And if this is not possible, this needs to be analyzed from HW point of view, we need to check the USB Analyzer logs only from the defect chromebook (Chromebook Samus), so if possible can this be provided to us or @Matt to get the logs.

Hi jaya, 

  I ran the test script 1000 times on current fw patch 37; it passed the 1000 times without problem. (I also ran the test script for only 100 times only on fw patch 39; and it passed without problem either.)

  Hence, I am not able to reproduce the controller reset failure on either of the fw patches. So it looks that we need the HW details of the Samus that cwmorris@ uses. We will discuss internally and see what we could provide. Thanks.

Another user reported the same issue. Refer to the following feedback:

https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=user:nhendin&lReport=51444130227

Important snippet of system logs:

2017-01-10T12:16:51.822000-08:00 INFO kernel: [60272.755156] usb 1-8: USB disconnect, device number 4
2017-01-10T12:16:52.229006-08:00 INFO kernel: [60273.161555] usb 1-8: new full-speed USB device number 26 using xhci_hcd
2017-01-10T12:16:52.393001-08:00 INFO kernel: [60273.326566] usb 1-8: New USB device found, idVendor=8087, idProduct=07dc
2017-01-10T12:16:52.393014-08:00 INFO kernel: [60273.326574] usb 1-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0
2017-01-10T12:16:52.407229-08:00 INFO kernel: [60273.340665] Bluetooth: hci0: read Intel version: 3707100180012d0d25
2017-01-10T12:16:52.407241-08:00 INFO kernel: [60273.340681] Bluetooth: hci0: Intel device is already patched. patch num: 25

2017-01-10T12:18:35.484999-08:00 ERR kernel: [60376.502003] hid-generic 0005:046D:B010.0007: unknown main item tag 0x0
2017-01-10T12:18:35.542068-08:00 INFO kernel: [60376.559161] input: Bluetooth Mouse M557 as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/bluetooth/hci0/hci0:256:2/0005:046D:B010.0007/input/input17
2017-01-10T12:18:35.543047-08:00 INFO kernel: [60376.560107] hid-generic 0005:046D:B010.0007: input,hidraw0: BLUETOOTH HID v10.01 Mouse [Bluetooth Mouse M557] on 6c:29:95:00:00:0a


And since we suspect hardware problems of different Samus SKUs, here is the hardware id of this user's Samus:

hwid                   = SAMUS TEST 8028                # Hardware ID


Note that my Samus which does not suffer of the "USB disconnct" problem at all has exactly the same hwid.

Hi Joseph,

OK, how would I check the hwid from my samus ?
If my samus is not with that hwid, is it possible getting a same DUT from Taipei Google office ?

Hi matt.chen, you could type

localhost ~ # crossystem | grep hwid


to get the hardware id.

We will get a Samus with that problem later. A user is going to send the machine to us. We will contact you after the machine arrives. This will take some time. Please also keep investigating this issue. More new users are complaining this issue. Thanks!

> since we suspect hardware problems of different Samus SKUs,
>  here is the hardware id of this user's Samus:
> hwid = SAMUS TEST 8028                # Hardware ID

Please note that's not a real hardware ID representing an hardware,
but the default value if the RO firmware of the machine was re-flashed, and no hwid was flashed afterwards.

This probably mean that the machine was fully re-flashed at some point after going out of the factory flow.
either it's not a mass production machine or it's used by a firmware developer

Hi Vincent, thank you for clarifying this out! 

In this case, is there a way for us to check what SKU a machine is? Thanks!

> is there a way for us to check what SKU a machine is? 

The exact SKU maybe not, but at least the hw revision to check whether this is pre-production hw.
The easiest one is asking Neil (who is a Googler in the HW/RF team) to check the stickers on the back. if they are no longer there, he can find the machine in go/chp using its asset tag, over there you will have at least the hardware revision.

Vincent, thank you for the detailed information! I will ask Neil. Thanks!

Neil's response:

Note, my MLB was swapped a while back so I'd prefer to give you the HWID and such from crossystem as that matches the electronics rather than the label on the D-Panel:

crossystem:
fwid                   = Google_Samus.6300.174.0        # Active firmware ID
hwid                   = SAMUS TEST 8028                # Hardware ID

localhost / # vpd -l
"mlb_serial_number"="SEL0C5V0BMKTC511600121"
"initial_locale"="en-US"
"initial_timezone"="America/Los_Angeles"
"keyboard_layout"="xkb:us::eng"
"region"="us"
"serial_number"="4C09000166"
"rlz_brand_code"="ZZAD"

I received a replacement Samus device from hennessywill@chromium.org, but it is exhibiting the same Bluetooth issues as my original device. I haven't yet seen the Bluetooth option entirely disappear from the Settings, but I have had the 'unable to reconnect' issue.

So either both devices have the same hardware bug or this is a more general bug that others just haven't been able to reproduce, perhaps.

Hi Chris, thank you for keeping track of this issue! As far as we know, this problem is across different platforms. If we use BLE device sufficient long, the probability of reproducing it is rather high.

So far I could reproduce this issue now on another platform, Squawks, with the same Intel wireless chip. Intel engineers are actively investigating this issue, and trying to clarify whether it is a wireless chip issue or our board issue. Thanks!

Ok, if it helps, I haven't experienced the issue on my HP 13 Chromebook.

has there been any progress on identifying the reasons for these issues? it's an extremely obnxious bug. I have to reboot my chromebook 3-5X daily as the bluetooth module crashes, disappears entirely from the lower right system tray menu and my mouse and external speaker stop working. It's so annoying I have ordered several new wireless mice that are not bluetooth so I can ignore the BT module crashing and the associated repeated reboots altogether. This is the only issue I have with ChromeOS however it dramatically affects the credibility of the OS as a mature stable platform. Unstable Bluetooth is ridiculous and the fact this is not moving urgently reflects poorly on your team. I suggest you prioritize this. It's lingered too long. Please have someone on your product management team reach out to me for a discussion of the UX and the root causes. jdsboston@gmail.com @jdsboston   

Deleted: IMG_20170330_173736.jpg 357 KB

	IMG_20170330_173736.jpg 357 KB View Download

PS apologies for not mentioning in my previous post that I am running on what is apparently google's flagship Pixel 2015 (i5) version. I am using a MSFT bluetooth mouse and a Bose speaker. I have order six Logitech wireless mice to try to isolate this as a mouse driver problem. It should not be that way; using customers as a hardware driver testing lab is a joke

> This is the only issue I have with ChromeOS however it dramatically affects the credibility of the OS as a mature stable platform. 

Certainly not an excuse and sorry to feed this off-topic conversation but... this issue seems specific to this model and not affecting ChromeOS as a whole. By the way I could never could get any Bluetooth device to work reliably on any Windows PC of mine, not even a basic headset - unlike with (other) Chromebooks. 

> Unstable Bluetooth is ridiculous...

Yes: far beyond ChromeOS. Bluetooth has much bigger certification and credibility issues than ChromeOS.

Hi guys, the investigating is ongoing with Intel at https://b.corp.google.com/issues/35581558.  I apologize that may not be accessible to everyone

@jdsboston - This is not a customer support forum. This is a developer issue tracker. Please post here if you have any data that would be helpful to us investigating this issue.

Expressing grievances against Chrome OS or expressing opinions about our engineering practices is not productive or helpful. This is not the forum for that.

I am not seeking customer support. 

​​The purpose of posting here, upon the advice of the support team, was to provide input, UX and possibly dialogue further to diagnose a frequent problem. This is the #1 issue I have with Samus as a platform.  Suggesting that blame lies with the bluetooth standard should not be an out.  

Re: Any data that would be helpful 

- Symptoms
4x+ Bluetooth crashes daily. I'm ​going to move to a USB ​2.4GhZ ​WiFi ​plugin -based mouse to ​avoid the hassles​.

- Platform Configuration
Standard i5 Samus. I stripped down all extensions to a minimal profile of less than seven including Addthis and Google Keep. Happy to share list if there's interest. Externally using Microsoft Sculpt mouse​ (for now)​ and Bose Soundlink II speaker. That's it. 

I will report back if switching away from the bluetooth mouse to WiFi mouse resolves the issue. 

Best of luck isolating these issues. 

> I'm ​going to move to a USB ​2.4GhZ ​WiFi ​plugin

Hi @jdsboston, please let us know if a wifi plugin mouse avoids the bluetooth problem. As far as we know, the issue occurred when USB channel interacted with the bluetooth controller and found something wrong. That led to the annoying disconnection/crash issues.

f a wifi mouse suffered from the disconnection/crash problem too, our vendor should also investigate wifi component too. Thanks for your valuable input!

hey guys, I have now moved to a simple logitech M320 wireless mouse which
relies upon a 2.4GHz trans/receiver in the USB port. Since migrating to
this unit the Operating System has had no issues. I have simultaneously
been playing music through a USB driven FiiO amplifier for my headphones.
The only thing I haven't tested extensively is using my Bose bluetooth
speaker.  My hope is that the mouse controller was the issue and that BT
and my speaker without the BT mouse will work fine.  I will report back
after I have tested this.  For now, the workaround for the BT issues we're
discussing here is to dump the BT mouse and get a 2.4GHz one that plugs in
USB. Cheers. /Josh

mouse specifications:
https://www.logitech.com/en-us/product/wireless-mouse-m320



[image: --]


Josh Sanderson
<https://about.me/jdsboston?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>
[image: https://]     www.jdsboston.me
<https://about.me/jdsboston?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>
+1 206 745 2656
@jdsboston

<http://www.linkedin.com/in/jdsboston>

Hi Josh, thank you for your feedback. We expect that a wireless mouse should work well.

As for Bose bluetooth speaker, if you play music continuously for hours, there should be no disconnection problem if we understand the problem correctly. AFAIK, the issue occurs when data is transmitted through bluetooth intermittently. For example, a bluetooth mouse or a bluetooth keyboard which sends input events from time to time would easily trigger the problem. A bluetooth speaker is expected to work more stably. Please let us know if this is not the case. Thanks!

bluetooth interactions with the bose speaker are perfectly stable. I have
been listening to music via BT for several hours.

this was while also using mouse on 2.4GHz via USB.  all good.  thanks!



[image: --]


Josh Sanderson
<https://about.me/jdsboston?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>
[image: https://]     www.jdsboston.me
<https://about.me/jdsboston?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>
+1 206 745 2656
@jdsboston

<http://www.linkedin.com/in/jdsboston>

Hi Josh, thank you for letting us know the stability of using bluetooth speakers!

The fix has landed at https://chromium-review.googlesource.com/c/538081/.

Thanks for the update. I will test a bt mouse and report back


/Josh

Josh Sanderson
http://jdsboston.me
+1.206.745.2656
@jdsboston

Sent from mobile. Please pardon typos