|
Latest kernels (4.11-7 & 4.11-8) SEIZE UP shortly after resume from suspend-2-ram
Shortly after resuming from s2ram, keyboard & mouse become unresponsive, can't telnet in (on two different machines I use), but display & running pgms continue running. Last good kernel was 4.11-6. s2disk does not appear to be affected.
After doing some digging, I discovered, while using xosview, I discovered that each (of the 4) cores suddenly (one by one) go to 100% in "xosview" packed with "WIO" (red) activity while all other activity ("USR" and "SYS") continue normally (0-20%, etc.) and cpu remains "cool" and "load" remains normal (0.1, etc.), ("normal" == looks and works as before suspend). "top", meanwhile, shows normal cpu "usage" and no unusual "hogs" or anything out of the ordinary running along witn memory usage and disk activity all "normal". "WIO" (from the xosview manpage) means "I/O WAIT", so it appears that that somehow gums up the works hogging interactivity (once it takes up all 4 cores). The only way to recover is to power-cycle. Please look into this, provide advice or request additional info, which I'll be happy to try or provide. I'm running Liquorix pae kernels in 32bit setup with 8gig ram. As an aside, I'm running Liquorix v4.9-19 for now as it performs better (cooler and more efficient, and pbm.-free) than any of the releases since then. Thanks, Jim Back to top |
|||||
|
Ha! I just registered to ask about this problem. It's the same for me minus knowing which version works properly, and here it seems that the screen is completely blank, and can't do anything unless I restart. A few times I was able to switch to a TTY, and was able to type in my username to log in and diagnose, but it would just hang there and not prompt me for the password...
I don't have a 2nd machine to be able to connect to this PC through SSH... Any advice? Back to top |
|||||
|
It does that for me with all the 4.11 (backported) versions, but it seems it has to be in suspension for some time--I can't trigger it by suspending and resuming after a few seconds over and over.
:: Code ::
inxi -F System: Host: mx1 Kernel: 4.11.0-3.1-liquorix-amd64 x86_64 (64 bit) Desktop: Xfce 4.12.3 Distro: MX-16_x64 Metamorphosis 12 December 2016 Machine: Device: laptop System: Acer product: Aspire E5-575G v: V1.20 Mobo: Acer model: Ironman_SK v: V1.20 UEFI: Insyde v: V1.20 date: 12/13/2016 Battery BAT1: charge: 49.8 Wh 100.0% condition: 49.8/56.0 Wh (89%) CPU: Dual core Intel Core i5-6200U (-HT-MCP-) cache: 3072 KB clock speeds: max: 2301 MHz 1: 400 MHz 2: 400 MHz 3: 1000 MHz 4: 400 MHz Graphics: Card-1: Intel HD Graphics 520 Card-2: NVIDIA Device 179c Display Server: X.Org 1.16.4 driver: intel Resolution: 1920x1080@60.01hz GLX Renderer: Mesa DRI Intel HD Graphics 520 (Skylake GT2) GLX Version: 3.0 Mesa 13.0.6 Audio: Card Intel Sunrise Point-LP HD Audio driver: snd_hda_intel Sound: ALSA v: k4.11.0-3.1-liquorix-amd64 Network: Card-1: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter driver: ath10k_pci IF: wlan0 state: up mac: 54:8c:a0:79:52:2d Card-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169 IF: eth0 state: down mac: 54:ab:3a:b2:a4:5f Drives: HDD Total Size: 756.2GB (51.7% used) ID-1: /dev/sda model: TOSHIBA_MQ01ABD0 size: 500.1GB ID-2: /dev/sdb model: HFS256G39TND size: 256.1GB Partition: ID-1: / size: 117G used: 33G (30%) fs: ext4 dev: /dev/sdb4 ID-2: /home size: 416G used: 328G (84%) fs: ext4 dev: /dev/sda2 ID-3: swap-1 size: 3.66GB used: 0.01GB (0%) fs: swap dev: /dev/sda3 Sensors: System Temperatures: cpu: 51.0C mobo: N/A Fan Speeds (in rpm): cpu: N/A Info: Processes: 266 Uptime: 4:18 Memory: 1679.5/7861.4MB Client: Shell (bash) inxi: 2.3.8 Back to top |
|||||
|
Can you guys try the latest kernel, 4.11.0-3.3 / 4.11-9? This kernel disabled forced IRQ threading, which might be enough to help for the scenarios you guys are talking about.
Back to top |
|||||
|
OK, I'll test the Jessie backported version. I also just found a patch in the Arch AUR that will let the abandoned AMD fglrx-driver 3.15.12 build on the new kernel, for us laggards still on Debian stable. People with shiny new xorgs can't use fglrx, though.
Back to top |
|||||
|
So far I haven't experienced any freezeups with the 4.9-11 kernel. Fingers remain crossed.
Back to top |
|||||
|
4.11.0-3.3 - still no joy in suspense! :(
No dice! Tried latest (4.11.0-3.3), got same results, see attached image showing the cpus ALL at 100% IO/Wait (but still running a cool 109 fairenheight, fan on low, existing programs still running, can't open terminal or do anything else.
[/img][/i] Back to top |
|||||
|
Having similar issue with old laptop with kernels starting from 4.11.
After waking up from suspend (via systemctl suspend) many processes have D status (uninterruptible sleep) and system can't do anything, e.g. any login or shell session do nothing on command, and became D after trying to close it. Only way to get system to work after this is hard-reset. Since journald also die (and I have no persistent logging setup), there is nothing interesting in syslog, just some failed attempts to connect from network-manager. Will gladly provide any needed info. Currently running on 4.9.0-0.1-liquorix-686 since I nuked 4.10 before realizing that 4.11 wasn't stable. Back to top |
|||||
|
I can try removing the hrtimer / timeout patches from CK's patch set on the next version. That will bring it back to the behavior of 4.9, since the last version on liquorix.net still doesn't have them included.
Next release will be: 4.11.0-4.1 / 4.11-11 Back to top |
|||||
|
Tested with 4.11-11, got same results. After suspend many programs enter uninterruptible sleep and login/shell won't work, guess CK hrtimer / timeout wasn't culprit for my case. Willing to provide any necessary logs if needed.
Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||