You are not logged in.
Seemingly at random, while performing everyday tasks (urxvt, chromium), my laptop will freeze up entirely. There is no visible error message, but the system becomes completely unresponsive, including to SysReq REISUB key sequences (which work normally -- I've tested them before the crashes and they work exaclty as expected), and I have to force shutdown by holding down the power button. I cannot reproduce the freezes consistently. Perhaps it's coincidence, but it seems like the freezes only happen when I am on battery power, or at least, I have yet to experience any freezes while plugged into a laptop. This makes me suspect that my power managers -- tlp and xfce4-power-manager -- are the culprits. I never encountered these problems when using KDE or Gnome on the same machine, so my guess is this is something related to xfce...but I'd really like to figure out what.
The last lines from journalctl don't contain anything particularly revealing -- no helpful error messages, even with verbose logging (systemd.log_level=debug). For the latest crash, the last events that showed up in the logs were system-udevd starting /usr/bin/tlp auto followed by a bunch of cycles of the following:
Mar 07 21:24:42 ashiklom systemd[1]: systemd-logind.service: Got notification message from PID 287 (WATCHDOG=1)
Mar 07 21:25:22 ashiklom systemd[1]: systemd-journald.service: Got notification message from PID 139 (WATCHDOG=1)
Mar 07 21:25:42 ashiklom systemd[1]: systemd-udevd.service: Got notification message from PID 170 (WATCHDOG=1)
Here's a link to a full journalctl -xb pastebin:
Briefly, I am using a Lanovo T450s with an Intel i7 processor the latest Arch kernel version (4.9.11-1-ARCH) and the XFCE desktop environment. All of my packages are fully up to date (pacman -Syu) as of the time of writing (2017-03-07). I'm running on a Lenovo T450s with an Intel i7 processor.
Here's a link to detailed system information (lshw; are there better tools out there?).
Any ideas?
Offline
Uninstall TLP and use powertop to identify what needs tuning.
Offline
Thanks for the tip! It's definitely worth a shot...but I'm particularly interested in ways that I can confirm that TLP is, in fact, the culprit. Is there an additional log I should be checking, logging settings I should enable? I already have debug logging enabled in my udev.conf, but are there other places I can make such changes? Are there robust ways to make sure journalctl stores results of hard freezes like this one?
Offline
Well, if you uninstall TLP and the freezes stop (as I expect they will) you will have identified the culprit.
systemd is pretty good at logging, your previous journal should record the freeze (-b -1).
Offline
or, try to disable disable Nmi_watchdog 0 in /etc/default/tlp
hp-envy dv7
Offline
There's a guide for that: http://linrunner.de/en/tlp/docs/tlp-tro … oting.html
Offline
Thanks all for the useful feedback!
I'll try jasonwryan's suggestion of uninstalling TLP (which is also what linrunner's linked TLP guide recommends) and see if I get any more freezes. If not, I'll follow the rest of the TLP debugging guide and post my results here.
In the meantime, for the record, I hit a freeze a few minutes ago even after booting the LTS kernel instead of the Arch standard one (as suggested in a similar thread here), so that didn't solve it.
EDIT: Here's the systemd log from the latest crash (journalctl -xb -1). It failed in a very similar way to the last one, which increases my confidence in blaming TLP.
Last edited by blowfish711 (2017-03-10 18:29:48)
Offline