Bug 96931

Summary: iwlmvm 7265 frequent disconnect and poor performance
Product: Drivers Reporter: Enrico Tagliavini (enrico.tagliavini)
Component: network-wirelessAssignee: drivers_network-wireless (drivers_network-wireless)
Status: CLOSED INVALID    
Severity: normal CC: ilw
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 3.19.3 Subsystem:
Regression: No Bisected commit-id:
Attachments: wpa_supplicant -dd kernel 3.19.3 firmware 25.17.12.0

Description Enrico Tagliavini 2015-04-20 19:00:20 UTC 
Created attachment 174591 [details]
wpa_supplicant -dd kernel 3.19.3 firmware 25.17.12.0

Related to bug #93431 (see also my dmesg attachment on that bug)

[root@gnuc ~]# lspci -nn | grep Wireless
02:00.0 Network controller [0280]: Intel Corporation Wireless 7265 [8086:095a] (rev 59)

I suspect I got two issues at once, since I was affected by the same problems also described in bug #93431 like ping returning error "No buffer space available". This was with firmware version 25.15.12.0 as provided by fedora 21. 

Updating the firmware to version 25.17.12.0 make situation better, but still disconnections are way to common when trying to use the wireless with loads > 100 KB/s.

Tried to downgrade to firmware version 23.15.10.0 and after 36 minutes of though trying it doesn't disconnect. It cannot go fast, it rarely goes over 200 KB/s and it becomes a little big "laggy" (ping reply takes seconds, not milliseconds), but the disconnected in dmesg are gone and wpa_supplicant -dd is way more quiet than when using firmware version 25.17. This is not a proof, it is extremely hard to have the same behaviour two days in a row, so forgive my confusion.

Today, while writing this bug report, my father found an interesting fact: by putting his hand over the NUC, but *without touching it*, the wireless connection was dying instantly. This is 100% reproducible. He removes the hand from over the NUC and the wireless reconnects. This sounded very weird so I asked to open the NUC and check the antennas. Compared to most pictures I can find on the internet the color of the cables is reversed, with the gray one near the border. I asked him to swap the two antennas. The wireless works like a charm with both the old 23.15.10.0 and the new 25.17.12.0 firmware. With the two antennas in the new position we still lose somthing like 8db of signal strength, but the connection looks rock solid. The signal without the hand over the NUC doesn't change much. Maybe just few DB, but it is hard to tell with the fluctuation happening.

I'm still writing this since it can potentially be useful for others and to ask you if this is a software bug or an assembly issue. TBO I was thinking the antenna wiring was not important and the driver can reconfigure it dynamically, or it simply doesn't really matter. Also the shop where my father bought the NUC said that with Windows it works as expected and the issue is reproducible with Linux only. I didn't performed the Windows test myself, nor did my father, so take this with a grain of salt.

Or maybe just two lucky shots in row....

Will let you know if we discover something more.
Comment 1 Emmanuel Grumbach 2015-04-23 19:16:53 UTC 
That is really weird.

I don't expect any differences between windows and Linux when it comes to physical layer stuff.

In any case, are you still having issues or can this bug be closed?
Comment 2 Emmanuel Grumbach 2015-05-01 05:34:14 UTC 
Ping?
Comment 3 Enrico Tagliavini 2015-05-01 10:50:15 UTC 
Hi Emmanuel, sorry for the delay but, as you said, this is really weird and it is difficult to understand what's the matter. Since we swapped the antennas everything worked as expected. Still we have no idea if this is an assembly problem or not. I think that everything boils down to: are the antenna supposed to be mounted in a very well define position? If the answer is positive then it was an assembly issue (likely with bug #93431 on top) and this should be closed as not a bug. Otherwise there is something wrong on the software side.

I think it could make sense to mark this bug as NEEDINFO.
Comment 4 Emmanuel Grumbach 2015-05-01 11:33:52 UTC 
I have no knowledge about the way the assembly should look like. Since there is no issue any more, I am closing this bug.
Comment 5 Enrico Tagliavini 2015-05-07 18:14:33 UTC 
(In reply to Emmanuel Grumbach from comment #4)
> I have no knowledge about the way the assembly should look like. Since there
> is no issue any more, I am closing this bug.

FYI we called Intel Italy and we were able to sort out the way the layout should look like. There are two antennas, one is for the Wireless, the other one is for the Bluetooth. The original setup was correct but we cannot get it to work properly. By swapping the two we are using the bluetooth antenna for the wireless, but this is a workaround.

This doesn't necessarily means there is a bug with the Linux driver, there might still be an issue with the antenna assembly, even if the original order is correct. However we were told we are not authorized to remove the motherboard from the NUC to check if the WiFi antenna is in good condition / position, without voiding the warranty. Hence we are waiting for more information from Intel Italy now about what to do next.

Will keep you posted.
Comment 6 Enrico Tagliavini 2015-06-15 16:47:49 UTC 
Ok this story is over :).

In short the NUC we got had an hardware damage to the WiFi antenna. We got a replacement under warranty and this works as expected with firmware 25.17.12.0 (now included with Fedora updates). With old firmware from the 25.15 series I can reproduce some of the issue we had, as per bug #93431.

Sorry for the noise, this was a very devious issue.

Thank you for the support.
Comment 7 Emmanuel Grumbach 2015-06-15 16:51:16 UTC 
No problem.

I hope it works fine for you now.