Thanks for all suggestions, I tried to apply them and this is what I got. While I don't use the Android Studio I did often use Eclipse and other Java heavy processes in the past days (I'm a Java developer playing with big data, so the heavy apps idea sounded interesting). So today I've been leaving the laptop on, but without using it at all: just logged in Gnome 3, no apps running. After some hours it crashed, and (after waiting a bit and then rebooting), this is the output of `journalctl -b -1` after restarting it: Oct 06 22:33:06 t440.slug rtkit-daemon[840]: The canary thread is apparently starving. Taking action. Oct 06 22:33:06 t440.slug rtkit-daemon[840]: Demoting known real-time threads. Oct 06 22:33:06 t440.slug rtkit-daemon[840]: Successfully demoted thread 5579 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:06 t440.slug rtkit-daemon[840]: Successfully demoted thread 5576 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:06 t440.slug rtkit-daemon[840]: Successfully demoted thread 5571 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:06 t440.slug rtkit-daemon[840]: Successfully demoted thread 5564 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:06 t440.slug rtkit-daemon[840]: Successfully demoted thread 1572 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:06 t440.slug rtkit-daemon[840]: Successfully demoted thread 1569 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:06 t440.slug rtkit-daemon[840]: Successfully demoted thread 1566 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:06 t440.slug rtkit-daemon[840]: Successfully demoted thread 1560 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:06 t440.slug rtkit-daemon[840]: Demoted 8 threads. Oct 06 22:33:16 t440.slug rtkit-daemon[840]: The canary thread is apparently starving. Taking action. Oct 06 22:33:16 t440.slug rtkit-daemon[840]: Demoting known real-time threads. Oct 06 22:33:16 t440.slug rtkit-daemon[840]: Successfully demoted thread 5579 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:16 t440.slug rtkit-daemon[840]: Successfully demoted thread 5576 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:16 t440.slug rtkit-daemon[840]: Successfully demoted thread 5571 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:16 t440.slug rtkit-daemon[840]: Successfully demoted thread 5564 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:16 t440.slug rtkit-daemon[840]: Successfully demoted thread 1572 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:16 t440.slug rtkit-daemon[840]: Successfully demoted thread 1569 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:16 t440.slug rtkit-daemon[840]: Successfully demoted thread 1566 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:16 t440.slug rtkit-daemon[840]: Successfully demoted thread 1560 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:16 t440.slug rtkit-daemon[840]: Demoted 8 threads. Oct 06 22:33:26 t440.slug rtkit-daemon[840]: The canary thread is apparently starving. Taking action. Oct 06 22:33:26 t440.slug rtkit-daemon[840]: Demoting known real-time threads. Oct 06 22:33:26 t440.slug rtkit-daemon[840]: Successfully demoted thread 5579 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:26 t440.slug rtkit-daemon[840]: Successfully demoted thread 5576 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:26 t440.slug rtkit-daemon[840]: Successfully demoted thread 5571 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:26 t440.slug rtkit-daemon[840]: Successfully demoted thread 5564 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:26 t440.slug rtkit-daemon[840]: Successfully demoted thread 1572 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:26 t440.slug rtkit-daemon[840]: Successfully demoted thread 1569 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:26 t440.slug rtkit-daemon[840]: Successfully demoted thread 1566 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:26 t440.slug rtkit-daemon[840]: Successfully demoted thread 1560 of process 1560 (/usr/bin/pulseaudio). Oct 06 22:33:26 t440.slug rtkit-daemon[840]: Demoted 8 threads. Oct 06 22:33:36 t440.slug rtkit-daemon[840]: The canary thread is apparently starving. Taking action. Oct 06 22:33:36 t440.slug rtkit-daemon[840]: Demoting known real-time threads. Oct 06 22:33:36 t440.slug rtkit-daemon[840]: Successfully demoted thread 5579 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:36 t440.slug rtkit-daemon[840]: Successfully demoted thread 5576 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:36 t440.slug rtkit-daemon[840]: Successfully demoted thread 5571 of process 5564 (/usr/bin/pulseaudio). Oct 06 22:33:36 t440.slug rtkit-daemon[840]: Successfully demoted thread 5564 of process 5564 (/usr/bin/pulseaudio). [repeated over and over for several pages] I then repeated the cycle, but with an open SSH terminal from my other workstation (Fedora 22). Again after some hours the system seemed locked up again. But the SSH terminal was not disconnected! I eventually got the "Broken Pipe" message, terminating the SSH session, only after I forced it off. So I guess it was not entirely dead? Is this information enough for you to guess something, or should I go ahead and try the F24 kernels? Thanks again! Sanne On 6 October 2015 at 09:45, Kamil Paral <kparal@xxxxxxxxxx> wrote: >> Yes it's an Intel one, and yes I'm using a dock but it's only to get >> it charged conveniently and connect to other perks - such as wired >> network and input devices - but the dock has no monitor attached. >> >> I've had the lockups happen frequently when travelling; been away for >> 2 weeks now: that implies no dock at all for many days, and even with >> several reboots between the last time it was in the dock (obviously, >> because of the issue itself). > > So it's not dock then. > > When the device locks up, try to connect to it from PC2 over ssh and inspect the logs. If that doesn't work, wait a few minutes to make sure all data is synced (provided the system is at least a bit alive), and then reboot and inspect last boot logs with `journalctl -b -1`. (Using sysrq is very helpful here, sysrq+reisub). > > If that doesn't work either (the cause of the lock-up is not in the logs), you can also try connect from PC2 over ssh while your computer is working fine, run `journalctl -f` to follow the logs, and then wait until your computer locks up. Hopefully you'll see at least some useful info before it stops communicating over the network. > > As a rule of thumb, you can also try different kernels. You should still have some F22 kernels installed, try them (or install them manually from Koji). Then also try latest F24 non-debug kernels [1]. That will give you additional data points. > > [1] https://fedoraproject.org/wiki/KernelDebugStrategy > -- > test mailing list > test@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
