Sent feedback at ~6:20 UTC and 6:58 UTC. 

Second one happened while I was browsing here in CRbug. First one I believe that I was opening a .zip file.

Sent more feedback at 7:09 UTC. Not sure if time stamps depend on when it was sent when wifi reconnected or not, if so then it's probably ending up sending around 2-3 mins after I say and I apologize for that.

Sent more feedback at 8:34 CST. I'm pretty sure this is actually a hardware issue and not a software issue now. Can't be too sure but if it is I'm sorry for wasting time.

A small section from the file:///var/log/messages 

https://docs.google.com/document/d/11I41VrMvymGSMd9mSscKIbHkKkt-5DKXnVyP0hBrYno/edit?usp=sharing

Communication to wifi device is failing.  Could be a hardware issue.

matt.chen: thoughts?

Hi Sameer,

Looks like platform issue, but I need more log prior what was printed in #4. I think there should be something like:
INFO kernel: [  136.091888] pcieport 0000:00:1c.0: AER: Multiple Corrected error received: id=00e0
ERR kernel: [  136.091929] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=00e0(Transmitter ID)
ERR kernel: [  136.091945] pcieport 0000:00:1c.0:   device [8086:0f48] error status/mask=00001000/00002000
ERR kernel: [  136.091959] pcieport 0000:00:1c.0:    [12] Replay Timer Timeout

or

NOTICE kernel: [  337.213771] Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)

It would be good to get the whole messages or net.log.

It hadn't happened since updating to Version 55.0.2883.54 beta (64-bit) (two or three days ago), now it just did it again.

I reseated the wifi module to make sure it was actually in place and secure, I will comment on this further if I get any more wifi dropping issues.

I have this issue across 30 HP Dell 11 P22t's as well. following

Hi Matt,
Following up to your comment in #c4, I have a log for you that looks like what you requested in #4. Attached file has /var/log/messages (syslog) and /var/log/net.log (netlog)

This user complained that they were not able to turn on the wifi interface. 

Snippet: 



2016-10-22T17:16:30.992038-07:00 ERR kernel: [ 1470.703551] pcieport 0000:00:1c.0:   device [8086:0f48] error status/mask=00000001/00002000
syslog2016-10-22T17:16:30.992044-07:00 ERR kernel: [ 1470.703568] pcieport 0000:00:1c.0:    [ 0] Receiver Error        
syslog2016-10-22T17:16:30.992048-07:00 INFO kernel: [ 1470.703587] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
syslog2016-10-22T17:16:30.992053-07:00 ERR kernel: [ 1470.703622] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e0(Receiver ID)
syslog2016-10-22T17:16:30.992057-07:00 ERR kernel: [ 1470.703635] pcieport 0000:00:1c.0:   device [8086:0f48] error status/mask=00000001/00002000
syslog2016-10-22T17:16:30.992061-07:00 ERR kernel: [ 1470.703661] pcieport 0000:00:1c.0:    [ 0] Receiver Error        
syslog2016-10-22T17:16:30.992065-07:00 INFO kernel: [ 1470.703684] pcieport 0000:00:1c.0: AER: Multiple Corrected error received: id=00e0
syslog2016-10-22T17:16:30.992070-07:00 ERR kernel: [ 1470.703706] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e0(Receiver ID)
syslog2016-10-22T17:16:30.992074-07:00 ERR kernel: [ 1470.703725] pcieport 0000:00:1c.0:   device [8086:0f48] error status/mask=00000001/00002000
syslog2016-10-22T17:16:30.992084-07:00 ERR kernel: [ 1470.703770] pcieport 0000:00:1c.0:    [ 0] Receiver Error        
syslog2016-10-22T17:16:30.992720-07:00 INFO kernel: [ 1470.703824] pcieport 0000:00:1c.0: AER: Multiple Corrected error received: id=00e0
syslog2016-10-22T17:16:30.992728-07:00 ERR kernel: [ 1470.703861] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e0(Receiver ID)
syslog2016-10-22T17:16:30.992733-07:00 ERR kernel: [ 1470.703880] pcieport 0000:00:1c.0:   device [8086:0f48] error status/mask=00000001/00002000
syslog2016-10-22T17:16:30.992737-07:00 ERR kernel: [ 1470.703932] pcieport 0000:00:1c.0:    [ 0] Receiver Error        
syslog2016-10-22T17:16:30.993716-07:00 INFO kernel: [ 1470.704841] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
syslog2016-10-22T17:16:30.993725-07:00 ERR kernel: [ 1470.704994] pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e0(Receiver ID)
syslog2016-10-22T17:16:31.018923-07:00 ERR kernel: [ 1470.729473] pcieport 0000:00:1c.0:   device [8086:0f48] error status/mask=00000001/00002000
syslog2016-10-22T17:16:31.018948-07:00 ERR kernel: [ 1470.729493] pcieport 0000:00:1c.0:    [ 0] Receiver Error        

Deleted: 14593202985_system_logs.txt 3.0 MB

14593202985_system_logs.txt 3.0 MB View Download

The logs in #c11 were obtained from feedback report: 14593202985

(https://feedback.corp.google.com/product/208/neutron?lView=rd&lReport=<reportid>)

It is a platform issue, but we have no idea why it happened.
I think disable L1 will be helping the issue as:
1) setpci -s 1:00.0 0x50.B=0x40 (WiFi endpoint)
2) setpci -s 1c.0 0x50.B=0x40 (root port)

What platform is it ? I bet it is Baytrail-M platform ?

Does it help move back to R51 image for the same DUT ?

I have this issue on Lenovo Chromebox i3. Reseated wifi card, but still occurs. Has been happening sporadically last month or two. Power cycle is only fix, but temporary.

Additional info to C16, I have 4 ASUS chromeboxes on 24/7 that do not disconnect from WIFI. Two are 2955's and two are i3's. I submitted an issue report yesterday that may have more information.

Hi,

The issue is because when wifi(endpoint) tries to switch different state of ASPM, like L1 or L1-sutstates, it got interference from somewhere around the platform and turned out to be reporting pcie error from root port.
ASPM is a very basic power management in PCIe bus control. What I suggested in #14 is to disable ASPM, ie no PCIe power management so that we could get away from interference.

So when you see something like #11, you should be able to try what mentioned in #14. That will mitigate the interference.

Update on my issue, it is 100% a hardware issue, the wifi card comes loose in it's port (possibly because of me walking to school in cold weather and then coming inside and it heating up again and ending up shifting)

Comment on 19, this does NOT appear to be a hardware issue for me as mine is a Lenovo i3 Chromebox that is in a stable temperature environment.  Additionally, I have reseated the WIFI card more than once to ensure the connections are solid.  I have filed numerous problem reports hoping they contain logs that would be useful.  The time between reboot and disconnect varies from a few hours to 3 days.  Once the disconnect occurs, the WIFI icon is grayed out with an X, and the chromebox is unable to detect any SSID's until reboot.  

I continue to have wifi disconnects usually after a period of idleness. They seem more frequent under stable 56.  I am using Lenovo Thinkcentre i3 chromebox.  It's wifi card is Intel 7260NGW which I believe is also used in the Lenovo N21 chromebook, and I have seen similar reports of disconnects for it.  ChromeOS reports the wifi is on, but under version 56 stable channel, the wifi icon is gray. Prior to 56, there would also be an X in the gray wifi icon.  No SSID's are listed even though there are several around me.  Reboot is only option, but temporary. Does the driver for this WIFI card need an update?

Deleted: IMG_20170211_174800.jpg 3.0 MB

	IMG_20170211_174800.jpg 3.0 MB View Download

Re:#c21 and #c22: 
#c22 had this content and is now deleted: "Update on comment 21: I replaced the WIFI card in my Lenovo i3 chromebox and I have not had a disconnect in three days. I will continue to test, but it appears my problem was also a hardware issue."

kweber1869@gmail.com: Thank you for reaching out. I see that you shared a picture of the card that was not working for you. Could you do the same for the working one? It would help us ping Intel with both the serial numbers. 

Follow-up to #c23: Also to confirm, you were running the same OS version during the replacement or were your old and new cards under different M56 stable releases? (we had a stable go out 2/1 and then 2/14) 

I think I installed the 2/14 stable release on 2/14 and ran one more test with the old card and had the disconnect within 24 hours.  I installed the new card the evening of 2/15 and it has not disconnected so far.

Follow up to c23: Here is a pic of the card that has been working since I installed it three days ago.  Hope it helps.

Deleted: IMG_20170218_180801.jpg 290 KB

	IMG_20170218_180801.jpg 290 KB View Download

Follow up to c27: My apologies for not keeping better records, but I have not yet installed the 2/14 stable update as the system is currently showing a build date of 2/1/2017 and version 56.0.2924.87.  I am just now in the process of updating to what I assume is the 2/14 release.  This does, however, further confirm that I was on the same OS version during the time the old and new cards were installed.

WiFi is randomly dropping on Version 64.0.3282.122 (Official Build) beta (64-bit). Actually not random, WiFi drops after I start editing Google drive documents after Chromes OS has been still for a time. The dropping WiFi issue is the same on 3 different Chrome OS machines (disruptively dropping).  

(Bulk Edit) Adding the new conops Chrome OS hotlist to all open issues with the "#CBC-RS/TC-watchlist" tag, our former tracking tag.

This is happening for me.

Is anyone looking into this?

@chriswil... comment 33. I run 3 different Chromebook Chromebox OS devices: 2012, 2013,2017. A repetitive pattern I have noticed. The issue generally goes away after a new Chrome OS build, but then returns. This happens like clockwork on 2013 devices. Also happened on 2012 device till it stopped receiving updates. Has not happened on 2017 device. Mostly issue stays for 2 Chrome OS builds, then goes away for 2 builds. I hope this can help someone pinpoint.