Hullo there everyone,<div><br></div><div>In case nobody guessed I am the Robert that Paul keeps talking about. Hopefully he hasn't oversold me by too much.</div><div><br></div><div>I have been testing the 4.6.0 kernel and the 4.7.0-rc2-pm1 kernel. Hopefully some of my findings are interesting.</div><div><br></div><div>Configuration:</div><div>- EUFI 5.2.0</div><div>- 32bit Debian GNU/Linux</div><div>- All of the OS on the eMMC</div><div><br></div><div>Factors affecting stability:</div><div>- On <b>both</b> kernels loading the <b>correct</b> sound module seems to be related to (unexplained) lockups.</div><div>- On <b>both</b> kernels the wireless driver for the internal wireless seems to cause locks within the networking subsystem of the kernel</div><div><span style="white-space: pre-wrap">      - Tested with `ip a` which is pretty direct to the kernel, fails.</span></div><div><span style="white-space: pre-wrap">       - Tested trying to remove the module itself from the kernel, this fails as well.</span></div><div><span style="white-space: pre-wrap">        - Tested trying to restart NetworkManager, forcibly get a new DHCP address all locked up commands. Interestingly ping even got stuck once.</span></div><div><span style="white-space: pre-wrap">      - Once the WiFI driver has locked up even rebooting sometimes seems to need power button force.</span></div><div><span style="white-space: pre-wrap"> - Disabling the WiFi with NetworkManager (Gnome, just turned it off, not sure what that does on a hardware level, presume it is an rfkill) completely prevented lock ups.</span></div><div><span style="white-space: pre-wrap">       - If I disable the WiFi each time before putting the device away I can use it without any trouble at all.</span></div><div><span style="white-space: pre-wrap">- The 4.7.0-rc2-pm1 kernel seems slightly more stable but I'm not 100% sure.</span></div><div><span style="white-space: pre-wrap"><br></span></div><div><span style="white-space: pre-wrap;">Testing with CStates enabled (4.7.0-rc2-pm1):</span></div><div><span style="white-space: pre-wrap;">- Idle drain of 2.2-2.7W vs 2.7-3.4W</span></div><div><span style="white-space: pre-wrap;">- Active drain of 5.1.5.9W vs 5.6-6.9W</span></div><div><span style="white-space: pre-wrap;">- Feels a little cooler when idling, YMMV.</span></div><div><span style="white-space: pre-wrap;">- Ran two tests of just randomly opening, closing, leaving it for a bit and then coming back.</span></div><div><span style="white-space: pre-wrap">      - Test one lasted 6.5h until I needed to reboot for something else. No lock up at all.</span></div><div><span style="white-space: pre-wrap">  - Test two lasted 10h and locked up when I detached from charging. I also undocked and redocked it at one point to see if the keyboard still worked (it did). Not sure if the undock/dock may have been related to the lock up.</span></div><div><span style="white-space: pre-wrap">- Deliberately used the above method of turning WiFi off when not using the device.</span></div><div><span style="white-space: pre-wrap">- I may test this again further with the CStates enabled. 6.5h and 10h are both well over the margin where you'd be likely to conserve power by turning it off anyway.</span></div><div><span style="white-space: pre-wrap"><br></span></div><div><span style="white-space: pre-wrap">If I were to make a wild accusation I would say that something common to sound and WiFi causes issues. ACPI? Certainly looks like it.</span></div><div><span style="white-space: pre-wrap"><br></span></div><div><span style="white-space: pre-wrap;">OK, that's everything I remember. Please excuse any failure to conform to mailing list etiquette I haven't used one in some years.</span></div><div><span style="white-space: pre-wrap;"><br></span></div><div><span style="white-space: pre-wrap;">--Robert.</span></div><div><span style="white-space: pre-wrap;"><br></span></div>