Bug 97921
| Summary: | iwlwifi: 7260: 1080p Rx is stuck with Bluetooth A2DP source (high ping latency) - MWG100235369 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | sheksis (myspecialids-kernel) |
| Component: | Watchdog | Assignee: | DO NOT USE - assign "network-wireless-intel" component instead (linuxwifi) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | bluespring, linuxwifi, luca, myspecialids-kernel, soeffing |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 3.19 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
Core9 firmware with uSniffer
bt_notif output iwl dump with the uSniffer firmware provided above logs: kernel 4.1, ucode-14 uSniffer Core10 firmware -13.ucode with fix for 100C 1080p + Bluetooth On + Last ucode-13 uSniffer firmware attached with this bug More Microcode errors :( cnn.com + Bluetooth OFF + ucode-13 uSniffer Logs for Bluetooth OFF case with only cnn.com opened. |
||
Please check the value of the bt_coex_active module parameter. You can check it in /sys/module/iwlwifi/parameters # cat /sys/module/iwlwifi/parameters/bt_coex_active Y This link https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi talks about disabling it. However, when I try to do $ sudo modprobe iwlwifi bt_coex_active=0 $ sudo cat /sys/module/iwlwifi/parameters/bt_coex_active Y Why isn't it changing? Also, # modinfo iwlwifi | grep power_level parm: power_level:default power save level (range from 1 - 5, default: 1) (int) This gives the range of values from 1-5. Yet, # cat /sys/module/iwlwifi/parameters/power_level 0 Is something wrong somewhere? (In reply to sheksis from comment #2) > # cat /sys/module/iwlwifi/parameters/bt_coex_active > Y > > This link https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi talks > about disabling it. > That's for older devices. On 7260, BT coexist should work well. Clearly there is a bug here... > However, when I try to do > $ sudo modprobe iwlwifi bt_coex_active=0 > $ sudo cat /sys/module/iwlwifi/parameters/bt_coex_active > Y > > > Why isn't it changing? > You'd first need to unload the module. > > Also, > # modinfo iwlwifi | grep power_level > parm: power_level:default power save level (range from 1 - 5, > default: 1) (int) > > This gives the range of values from 1-5. Yet, > # cat /sys/module/iwlwifi/parameters/power_level > 0 > > > Is something wrong somewhere? This is irrelevant for iwlmvm anyway. We can't remove them because of backward compatibility. Can you please check the output of: cat /sys//kernel/debug/iwlwifi/0000\:0X\:00.0/iwlmvm/bt_notif (replace X with the right number for your system). I'd like you to dump that when you are running your video and BT is connected. thank you. Created attachment 176321 [details] Core9 firmware with uSniffer On top of what I requested in the previous comment, please use the firmware attached and load iwlwifi with fw_monitor=1 as a module parameter. Then, please crash the firmware: echo 1 > /sys/kernel/debug/iwlwifi/0000\:04\:00.0/iwlmvm/fw_restart And collect the data: cat /sys/devices/virtual/devcoredump/devcdY/data > iwl.dump echo 1 > /sys/devices/virtual/devcoredump/devcdY/data I'd need iwl.dump. It should weigh around 4.2MB. Please take the time to read the privacy note here: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#privacy_aspects thanks. Created attachment 176331 [details]
bt_notif output
Created attachment 176341 [details]
iwl dump with the uSniffer firmware provided above
I thought I'd add, I'm still using the new BT firmware that Tedd provided in bug97291. the data has been transferred to the WiFi firmware team. Thank you. 1. All along, I was thinking that with -12 ucode, the out of buffer error would be gone. However, with bluetooth on, this is what I got today. Do note that earlier the ping latencies used to go to seconds before getting the buffer error. Today, it was all of a sudden after the 365 ms ping at the bottom. 2. I have started training myself on rationing my bluetooth luxuries while working but once during the past day, I got ping latencies in seconds with bluetooth *OFF*. So theres more to my woes than this bug, clearly. Couldn't collect the crash because I wasn't running the sniffer version of the firmware. firmware version ------------------- May 12 20:57:59 shatrupa kernel: iwlwifi 0000:04:00.0: loaded firmware version 25.17.12.0 op_mode iwlmvm Ping with bluetooth on -------------------------- 64 bytes from 192.168.1.1: icmp_seq=46 ttl=254 time=270 ms 64 bytes from 192.168.1.1: icmp_seq=47 ttl=254 time=32.2 ms 64 bytes from 192.168.1.1: icmp_seq=48 ttl=254 time=610 ms 64 bytes from 192.168.1.1: icmp_seq=49 ttl=254 time=79.4 ms 64 bytes from 192.168.1.1: icmp_seq=50 ttl=254 time=694 ms 64 bytes from 192.168.1.1: icmp_seq=51 ttl=254 time=210 ms 64 bytes from 192.168.1.1: icmp_seq=52 ttl=254 time=742 ms 64 bytes from 192.168.1.1: icmp_seq=53 ttl=254 time=510 ms 64 bytes from 192.168.1.1: icmp_seq=54 ttl=254 time=126 ms 64 bytes from 192.168.1.1: icmp_seq=55 ttl=254 time=2.73 ms 64 bytes from 192.168.1.1: icmp_seq=56 ttl=254 time=13.8 ms 64 bytes from 192.168.1.1: icmp_seq=57 ttl=254 time=1.62 ms 64 bytes from 192.168.1.1: icmp_seq=58 ttl=254 time=15.3 ms 64 bytes from 192.168.1.1: icmp_seq=59 ttl=254 time=1.80 ms 64 bytes from 192.168.1.1: icmp_seq=60 ttl=254 time=1.70 ms 64 bytes from 192.168.1.1: icmp_seq=61 ttl=254 time=8.42 ms 64 bytes from 192.168.1.1: icmp_seq=62 ttl=254 time=149 ms 64 bytes from 192.168.1.1: icmp_seq=63 ttl=254 time=35.1 ms 64 bytes from 192.168.1.1: icmp_seq=64 ttl=254 time=2.94 ms 64 bytes from 192.168.1.1: icmp_seq=65 ttl=254 time=2.11 ms 64 bytes from 192.168.1.1: icmp_seq=66 ttl=254 time=1.93 ms 64 bytes from 192.168.1.1: icmp_seq=67 ttl=254 time=1.30 ms 64 bytes from 192.168.1.1: icmp_seq=68 ttl=254 time=1.60 ms 64 bytes from 192.168.1.1: icmp_seq=69 ttl=254 time=107 ms 64 bytes from 192.168.1.1: icmp_seq=70 ttl=254 time=15.4 ms 64 bytes from 192.168.1.1: icmp_seq=71 ttl=254 time=365 ms ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available ping: sendmsg: No buffer space available Yes - there is bug in the -12.ucode that causes high latency even when BT is OFF. But you clearly saw that BT on made the situation much worse. I know a bit about BT Coex, and it can cause such things, hence I decided to have two tickets opened on the firmware and two bugs in bugzilla. Can you try the -13.ucode? It is available here: https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/ You'll need 4.1 to run it. You can also use the backport based driver from here: https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/ thanks. Have installed it but will be able to test it only after 10 days as I'm travelling. Will let you know how it is after that. Any news? Stuck. 64 bytes from 192.168.1.1: icmp_seq=403 ttl=254 time=10073 ms 64 bytes from 192.168.1.1: icmp_seq=404 ttl=254 time=9075 ms 64 bytes from 192.168.1.1: icmp_seq=405 ttl=254 time=8077 ms 64 bytes from 192.168.1.1: icmp_seq=406 ttl=254 time=7078 ms 64 bytes from 192.168.1.1: icmp_seq=407 ttl=254 time=6080 ms 64 bytes from 192.168.1.1: icmp_seq=408 ttl=254 time=5082 ms 64 bytes from 192.168.1.1: icmp_seq=409 ttl=254 time=4083 ms 64 bytes from 192.168.1.1: icmp_seq=410 ttl=254 time=3099 ms 64 bytes from 192.168.1.1: icmp_seq=411 ttl=254 time=2101 ms 64 bytes from 192.168.1.1: icmp_seq=412 ttl=254 time=2805 ms 64 bytes from 192.168.1.1: icmp_seq=413 ttl=254 time=17368 ms 64 bytes from 192.168.1.1: icmp_seq=414 ttl=254 time=17842 ms 64 bytes from 192.168.1.1: icmp_seq=415 ttl=254 time=16843 ms 64 bytes from 192.168.1.1: icmp_seq=416 ttl=254 time=15846 ms 64 bytes from 192.168.1.1: icmp_seq=417 ttl=254 time=17014 ms 64 bytes from 192.168.1.1: icmp_seq=418 ttl=254 time=16163 ms 64 bytes from 192.168.1.1: icmp_seq=419 ttl=254 time=15165 ms 64 bytes from 192.168.1.1: icmp_seq=420 ttl=254 time=14167 ms 64 bytes from 192.168.1.1: icmp_seq=421 ttl=254 time=13168 ms 64 bytes from 192.168.1.1: icmp_seq=422 ttl=254 time=12341 ms 64 bytes from 192.168.1.1: icmp_seq=423 ttl=254 time=11422 ms 64 bytes from 192.168.1.1: icmp_seq=424 ttl=254 time=10597 ms 64 bytes from 192.168.1.1: icmp_seq=425 ttl=254 time=3769 ms However, for a change it did not happen the moment I started playing the 1080p video. It was 7 minutes into the video. However, this might just be anecdotal. More Info =========== Kernel: 4.1rc7 ---------------- # uname -r 4.1.0-0.rc7.git1.1.fc23.x86_64 Firmware --------- # ls -l /usr/lib/firmware/iwlwifi-7260* -rw-r--r--. 1 root root 672352 May 21 19:12 /usr/lib/firmware/iwlwifi-7260-10.ucode -rw-r--r--. 1 root root 782300 May 21 19:12 /usr/lib/firmware/iwlwifi-7260-12.ucode -rw-r--r-- 1 root root 786920 May 30 08:45 /usr/lib/firmware/iwlwifi-7260-13.ucode -rw-r--r-- 1 root root 1049152 Jun 16 07:12 /usr/lib/firmware/iwlwifi-7260-14.ucode -rw-r--r--. 1 root root 683236 May 21 19:12 /usr/lib/firmware/iwlwifi-7260-7.ucode -rw-r--r--. 1 root root 679780 May 21 19:12 /usr/lib/firmware/iwlwifi-7260-8.ucode -rw-r--r--. 1 root root 680508 May 21 19:12 /usr/lib/firmware/iwlwifi-7260-9.ucode Log ----- Attached. I noticed a microcode error and some dump inside it. Created attachment 180041 [details]
logs: kernel 4.1, ucode-14
Logs from "journalctl -b 0 | grep iwlwifi"
Also, I am relatively free to test now and can provide you all the logs you need. So you can fire as many log collection requests/experiments as you want if it expedites this bug. You are using -13.ucode and not -14 because 4.1 can't use -14.ucode. However the bug you see (assert 100c) has been fixed already by the firmware team. I will check when I can share a version that includes this fix. Thanks for testing. Weird, I am not even playing a video and this is happening. 64 bytes from 192.168.1.1: icmp_seq=2742 ttl=254 time=18499 ms 64 bytes from 192.168.1.1: icmp_seq=2743 ttl=254 time=17788 ms 64 bytes from 192.168.1.1: icmp_seq=2744 ttl=254 time=20300 ms 64 bytes from 192.168.1.1: icmp_seq=2745 ttl=254 time=20380 ms 64 bytes from 192.168.1.1: icmp_seq=2746 ttl=254 time=22271 ms 64 bytes from 192.168.1.1: icmp_seq=2747 ttl=254 time=24455 ms 64 bytes from 192.168.1.1: icmp_seq=2748 ttl=254 time=24475 ms 64 bytes from 192.168.1.1: icmp_seq=2749 ttl=254 time=23777 ms 64 bytes from 192.168.1.1: icmp_seq=2750 ttl=254 time=23689 ms 64 bytes from 192.168.1.1: icmp_seq=2751 ttl=254 time=24108 ms 64 bytes from 192.168.1.1: icmp_seq=2752 ttl=254 time=25688 ms 64 bytes from 192.168.1.1: icmp_seq=2753 ttl=254 time=26859 ms 64 bytes from 192.168.1.1: icmp_seq=2754 ttl=254 time=25884 ms 64 bytes from 192.168.1.1: icmp_seq=2755 ttl=254 time=25176 ms 64 bytes from 192.168.1.1: icmp_seq=2756 ttl=254 time=24245 ms 64 bytes from 192.168.1.1: icmp_seq=2757 ttl=254 time=23377 ms 64 bytes from 192.168.1.1: icmp_seq=2758 ttl=254 time=22481 ms 64 bytes from 192.168.1.1: icmp_seq=2759 ttl=254 time=21627 ms 64 bytes from 192.168.1.1: icmp_seq=2760 ttl=254 time=21253 ms 64 bytes from 192.168.1.1: icmp_seq=2761 ttl=254 time=20602 ms 64 bytes from 192.168.1.1: icmp_seq=2762 ttl=254 time=19648 ms 64 bytes from 192.168.1.1: icmp_seq=2763 ttl=254 time=18704 ms Maybe this is part of the bug97291. Can't collect a dump because I am not running a uSniffer ucode. The config is the same as above. Also no new log messages are there for iwlwifi. (I haven't rebooted) Restarting from Network Manager (wireless OFF and then ON) also did not fix the issue 64 bytes from 192.168.1.1: icmp_seq=2878 ttl=254 time=733 ms 64 bytes from 192.168.1.1: icmp_seq=2879 ttl=254 time=781 ms 64 bytes from 192.168.1.1: icmp_seq=2880 ttl=254 time=686 ms 64 bytes from 192.168.1.1: icmp_seq=2881 ttl=254 time=770 ms 64 bytes from 192.168.1.1: icmp_seq=2882 ttl=254 time=714 ms 64 bytes from 192.168.1.1: icmp_seq=2883 ttl=254 time=276 ms 64 bytes from 192.168.1.1: icmp_seq=2884 ttl=254 time=214 ms 64 bytes from 192.168.1.1: icmp_seq=2885 ttl=254 time=212 ms 64 bytes from 192.168.1.1: icmp_seq=2886 ttl=254 time=4279 ms 64 bytes from 192.168.1.1: icmp_seq=2887 ttl=254 time=3348 ms 64 bytes from 192.168.1.1: icmp_seq=2888 ttl=254 time=2628 ms 64 bytes from 192.168.1.1: icmp_seq=2889 ttl=254 time=1906 ms 64 bytes from 192.168.1.1: icmp_seq=2890 ttl=254 time=998 ms 64 bytes from 192.168.1.1: icmp_seq=2891 ttl=254 time=75.1 ms 64 bytes from 192.168.1.1: icmp_seq=2892 ttl=254 time=178 ms 64 bytes from 192.168.1.1: icmp_seq=2893 ttl=254 time=12.1 ms 64 bytes from 192.168.1.1: icmp_seq=2894 ttl=254 time=2.74 ms 64 bytes from 192.168.1.1: icmp_seq=2895 ttl=254 time=2.40 ms 64 bytes from 192.168.1.1: icmp_seq=2896 ttl=254 time=3.13 ms 64 bytes from 192.168.1.1: icmp_seq=2897 ttl=254 time=1983 ms 64 bytes from 192.168.1.1: icmp_seq=2898 ttl=254 time=1048 ms 64 bytes from 192.168.1.1: icmp_seq=2900 ttl=254 time=94.2 ms 64 bytes from 192.168.1.1: icmp_seq=2901 ttl=254 time=163 ms Created attachment 180051 [details]
uSniffer Core10 firmware -13.ucode with fix for 100C
Here you go.
Thank you.
Created attachment 180071 [details]
1080p + Bluetooth On + Last ucode-13 uSniffer firmware attached with this bug
Created attachment 180081 [details]
More Microcode errors :(
This one was also with bluetooth on. I'll try to collect iwl.dump for the case where latencies spike with bluetooth off.
Created attachment 180091 [details]
cnn.com + Bluetooth OFF + ucode-13 uSniffer
Created attachment 180101 [details]
Logs for Bluetooth OFF case with only cnn.com opened.
The Microcode errors you are seeing are just because you force a firmware reset to trigger the log collection. These are perfectly normal. I am now forwarding your dumps to the firmware team. Thank you. Any word about the problem? I'm still yearning to switch on my bluetooth speakers. Unfortunately, I have no news from the firmware team. This is getting really annoying now :( Youtube videos are one thing, but WiFi tanking in the midst of ongoing important work is serious. I understand that you guys are working hard on it, but surely I can do something to expedite it. Will sending me custom firmwares with enough debugging help? - so that you all are not blocked on anything. We have some news. The bug seems to be related to the BT side. I don't have more for the moment... I am just a proxy here... :( Thank you for this information!! I hope I'll soon be getting bluetooth firmwares to test run :) Lots of time has passed since the last update on this bug. Given that the problem is reproducible at the drop of a dime... and that many Linux users might be facing it without even realizing whats going on - I do hope that some people are working on resolving it. Sorry for the delay. This issue is being handled by our Bluetooth team and is apparently not reproducible on newer releases. We are following up with them to see if/when we can release a fix to the community. @Luca - Thanks! I will wait for it. Do let us know when it is released. I am still doing inquiries about the BT firmware, but the WiFi firmware that has been used to validate the fix is Core14. You can find it here: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release#core_release You'll need 4.3-rcX or the backport based Core14 driver to be able to use the Core14 WiFi firmware. Still checking for BT firmware... @Emmanuel - Thanks for providing the new firmware. I'll check it out and let you know. Both this and for bug97291 thanks. If the -13.ucode I provided is better, I'll upstream it, but I doubt it. Let me know for the newer firmware versions as well. ah no - sorry. -13.ucode is only for bug 97291. sorry. I got the data from the BT team. The latest firmware in linux-firmware.git (upstream, not iwlwifi's clone) should include the fixes. At least, we couldn't reproduce the issue on that version: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain/intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain/intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain/intel/ibt-hw-37.7.bseq Please copy these 3 files under /lib/firmware/intel and reboot. Thanks. Sorry for the spam, but to be sure that I give the information in one piece: You need to update your WiFi driver to a WiFi driver that know how to handle -17.ucode and the WiFi firmware -17.ucode. You can find this here: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release#core_release Along with that, you need to update the BT firmware with the firmware stated in comment #37. Let us know! Thanks for summarizing it. I'll update with the results in a couple of days. @Emmanuel Just to confirm, heres my setup. Please go through it and let me know if anything is amiss. Kernel ------- $ uname -r 4.3.0-0.rc4.git3.1.fc24.x86_64 journalctl logs ----------------- $ journalctl -b 0 --no-pager | grep iwlwifi Oct 14 00:14:58 shatrupa kernel: iwlwifi 0000:04:00.0: loaded firmware version 17.228510.0 op_mode iwlmvm Oct 14 00:14:58 shatrupa kernel: iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144 Oct 14 00:14:58 shatrupa kernel: iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled Oct 14 00:14:58 shatrupa kernel: iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled Oct 14 00:14:58 shatrupa kernel: iwlwifi 0000:04:00.0: Allocated 0x00400000 bytes (order 10) for firmware monitor. Oct 14 00:14:58 shatrupa kernel: iwlwifi 0000:04:00.0: Sorry - debug buffer is only 4096K while you requested 65536K Oct 14 00:14:58 shatrupa kernel: iwlwifi 0000:04:00.0 wlp4s0: renamed from wlan0 Oct 14 00:15:00 shatrupa NetworkManager[989]: <info> rfkill2: found WiFi radio killswitch (at /sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0/ieee80211/phy0/rfkill2) (driver iwlwifi) Oct 14 00:15:01 shatrupa NetworkManager[989]: <info> (wlp4s0): new 802.11 WiFi device (carrier: UNKNOWN, driver: 'iwlwifi', ifindex: 3) Oct 14 00:15:01 shatrupa kernel: iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled Oct 14 00:15:01 shatrupa kernel: iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled Oct 14 00:15:01 shatrupa kernel: iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled Oct 14 00:15:01 shatrupa kernel: iwlwifi 0000:04:00.0: L1 Enabled - LTR Enabled Oct 14 00:15:03 shatrupa kernel: iwlwifi 0000:04:00.0 wlp4s0: disabling HT/VHT due to WEP/TKIP use Oct 14 00:15:03 shatrupa kernel: iwlwifi 0000:04:00.0 wlp4s0: disabling HT as WMM/QoS is not supported by the AP Oct 14 00:15:03 shatrupa kernel: iwlwifi 0000:04:00.0 wlp4s0: disabling VHT as WMM/QoS is not supported by the AP iwlwifi firmware ------------------ $ ls -l /lib/firmware/iwlwifi-7260* -rw-r--r-- 1 root root 672352 Sep 4 18:00 /lib/firmware/iwlwifi-7260-10.ucode -rw-r--r-- 1 root root 782300 Sep 4 18:00 /lib/firmware/iwlwifi-7260-12.ucode -rw-r--r-- 1 root root 786920 Sep 4 18:00 /lib/firmware/iwlwifi-7260-13.ucode -rw-r--r-- 1 root root 1049324 Oct 14 00:01 /lib/firmware/iwlwifi-7260-17.ucode -rw-r--r-- 1 root root 683236 Sep 4 18:00 /lib/firmware/iwlwifi-7260-7.ucode -rw-r--r-- 1 root root 679780 Sep 4 18:00 /lib/firmware/iwlwifi-7260-8.ucode -rw-r--r-- 1 root root 680508 Sep 4 18:00 /lib/firmware/iwlwifi-7260-9.ucode $ ls -l /lib/firmware/intel/ total 2556 -rw-r--r-- 1 root root 647078 Sep 4 18:01 fw_sst_0f28.bin -rw-r--r-- 1 root root 265684 Sep 4 18:01 fw_sst_0f28.bin-48kHz_i2s_master -rw-r--r-- 1 root root 701614 Sep 4 18:01 fw_sst_22a8.bin -rw-r--r-- 1 root root 9 Sep 4 18:01 ibt-11-5.ddc -rw-r--r-- 1 root root 570160 Sep 4 18:01 ibt-11-5.sfi -rw-r--r-- 1 root root 17508 Sep 4 18:01 ibt-hw-37.7.10-fw-1.0.1.2d.d.bseq -rw-r--r-- 1 root root 25575 Sep 4 18:01 ibt-hw-37.7.10-fw-1.0.2.3.d.bseq -rw-r--r-- 1 root root 20997 Oct 13 23:29 ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq -rw-r--r-- 1 root root 25117 Oct 13 23:29 ibt-hw-37.7.10-fw-1.80.2.3.d.bseq -rw-r--r-- 1 root root 96 Oct 13 23:29 ibt-hw-37.7.bseq -rw-r--r-- 1 root root 24121 Sep 4 18:01 ibt-hw-37.8.10-fw-1.10.2.27.d.bseq -rw-r--r-- 1 root root 24486 Sep 4 18:01 ibt-hw-37.8.10-fw-1.10.3.11.e.bseq -rw-r--r-- 1 root root 96 Sep 4 18:01 ibt-hw-37.8.bseq -rw-r--r-- 1 root root 260320 Sep 4 18:01 IntcSST2.bin I played 1080p videos and nothing untoward happened. But I guess that given past experience, I'd keep this setup under observation for 2-3 days before giving a verdict. Everything seems to be in place. You can remove the fw_monitor=1 module parameter now I guess :) Removed it now :) It worked for a day or so. (bluetooth + video streaming). Today I saw 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=6740 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=6078 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=5424 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=255 time=4938 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=255 time=5263 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=255 time=4815 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=255 time=3843 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=255 time=3361 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=255 time=3528 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=255 time=2535 ms 64 bytes from 192.168.1.1: icmp_seq=11 ttl=255 time=2886 ms 64 bytes from 192.168.1.1: icmp_seq=12 ttl=255 time=2365 ms 64 bytes from 192.168.1.1: icmp_seq=13 ttl=255 time=2941 ms 64 bytes from 192.168.1.1: icmp_seq=14 ttl=255 time=4193 ms 64 bytes from 192.168.1.1: icmp_seq=15 ttl=255 time=4530 ms 64 bytes from 192.168.1.1: icmp_seq=16 ttl=255 time=4102 ms 64 bytes from 192.168.1.1: icmp_seq=17 ttl=255 time=4007 ms 64 bytes from 192.168.1.1: icmp_seq=18 ttl=255 time=3692 ms 64 bytes from 192.168.1.1: icmp_seq=19 ttl=255 time=2886 ms 64 bytes from 192.168.1.1: icmp_seq=20 ttl=255 time=1988 ms 64 bytes from 192.168.1.1: icmp_seq=21 ttl=255 time=1504 ms 64 bytes from 192.168.1.1: icmp_seq=22 ttl=255 time=1880 ms 64 bytes from 192.168.1.1: icmp_seq=23 ttl=255 time=2187 ms 64 bytes from 192.168.1.1: icmp_seq=24 ttl=255 time=3103 ms 64 bytes from 192.168.1.1: icmp_seq=26 ttl=255 time=3876 ms 64 bytes from 192.168.1.1: icmp_seq=31 ttl=255 time=1925 ms 64 bytes from 192.168.1.1: icmp_seq=32 ttl=255 time=1183 ms However, it happened only once or twice after a lot of streaming and the good thing was that it recovered. I dont know whether this happened because of bluetooth(this bug) or bug97291 But overall I think that the streamings are more smooth, not only on youtube but on CNN too. So thanks(!) for all the effort. Maybe a few minor quirks remain to be ironed out. Let me know if you want to collect more data to kill and bury it forever :) Thanks. Let's close this one. Open a new bug if you have issues again. Thanks for your cooperation and your patience. Sure. I'm okay with CLOSING this one. I'll open another one if I start hitting something recurrent. |
Heres my setup 1. Intel 7260AC card 2. Intel Bluetooth 3. Fedora 21 $ uname -r 3.19.5-200.fc21.x86_64 This is a follow up from bug97291 The ping latency increases all of a sudden on switching on a bluetooth speaker. Excerpts from the bug: ---8X--- I made a discovery. I listen to music through a bluetooth speaker. So the speaker is invariably on when I run a youtube video. Today it was off... and the moment I turned it on, see the jump in latency... 64 bytes from 192.168.1.1: icmp_seq=2729 ttl=254 time=1.75 ms 64 bytes from 192.168.1.1: icmp_seq=2730 ttl=254 time=3.98 ms 64 bytes from 192.168.1.1: icmp_seq=2731 ttl=254 time=5.22 ms 64 bytes from 192.168.1.1: icmp_seq=2732 ttl=254 time=1.74 ms 64 bytes from 192.168.1.1: icmp_seq=2733 ttl=254 time=443 ms 64 bytes from 192.168.1.1: icmp_seq=2734 ttl=254 time=157 ms 64 bytes from 192.168.1.1: icmp_seq=2735 ttl=254 time=2163 ms 64 bytes from 192.168.1.1: icmp_seq=2736 ttl=254 time=2463 ms 64 bytes from 192.168.1.1: icmp_seq=2737 ttl=254 time=2198 ms 64 bytes from 192.168.1.1: icmp_seq=2738 ttl=254 time=1228 ms 64 bytes from 192.168.1.1: icmp_seq=2739 ttl=254 time=1008 ms 64 bytes from 192.168.1.1: icmp_seq=2740 ttl=254 time=187 ms Now with this latency, the video was about to get stuck when I immediately switched it off. The latency took some time to recover but when it did, it did not climb back again 64 bytes from 192.168.1.1: icmp_seq=2802 ttl=254 time=3154 ms 64 bytes from 192.168.1.1: icmp_seq=2803 ttl=254 time=2950 ms 64 bytes from 192.168.1.1: icmp_seq=2804 ttl=254 time=2908 ms 64 bytes from 192.168.1.1: icmp_seq=2805 ttl=254 time=2287 ms 64 bytes from 192.168.1.1: icmp_seq=2806 ttl=254 time=1335 ms 64 bytes from 192.168.1.1: icmp_seq=2807 ttl=254 time=475 ms 64 bytes from 192.168.1.1: icmp_seq=2808 ttl=254 time=11.4 ms 64 bytes from 192.168.1.1: icmp_seq=2809 ttl=254 time=2.19 ms 64 bytes from 192.168.1.1: icmp_seq=2810 ttl=254 time=3.35 ms 64 bytes from 192.168.1.1: icmp_seq=2811 ttl=254 time=1.71 ms 64 bytes from 192.168.1.1: icmp_seq=2812 ttl=254 time=3.62 ms 64 bytes from 192.168.1.1: icmp_seq=2813 ttl=254 time=1.21 ms I again switched on the speaker and the latency jumped yet again 64 bytes from 192.168.1.1: icmp_seq=2980 ttl=254 time=5.37 ms 64 bytes from 192.168.1.1: icmp_seq=2981 ttl=254 time=1.06 ms 64 bytes from 192.168.1.1: icmp_seq=2982 ttl=254 time=5.96 ms 64 bytes from 192.168.1.1: icmp_seq=2983 ttl=254 time=1.45 ms 64 bytes from 192.168.1.1: icmp_seq=2984 ttl=254 time=39.4 ms 64 bytes from 192.168.1.1: icmp_seq=2985 ttl=254 time=906 ms 64 bytes from 192.168.1.1: icmp_seq=2986 ttl=254 time=869 ms 64 bytes from 192.168.1.1: icmp_seq=2987 ttl=254 time=1271 ms 64 bytes from 192.168.1.1: icmp_seq=2988 ttl=254 time=1554 ms I repeated the process many times with repeatable results. ---X8---