Lately I have experienced some freezes in my laptop (Acer Aspire V 11 Touch). In all cases there were neither high loads at stake nor alleged programs (once I was even typing around simple commands in the terminal).
The issue has been severe though, since the keyword too went unresponsive, hence the solutions in the like of these https://askubuntu.com/questions/4408 are not applicable and I resorted to power off the machine brutally.
I initially blamed the upgrade from Ubuntu 14.04 to Ubuntu 16.04. However, the problem persists also after having downgraded the release to 14.04. I also noticed that one other desktop running on Ubuntu 14.04 has never gotten stuck. Then the release is not the culprit, seemingly.
Two features that I can recognise are common to the occurrence of the problem: it's either the laptop, or the newer kernel (well, or both). The issue only presented itself with the most recent kernel 4.4.0-53-generic (regardless of the distribution release), while the machine with an older kernel 3.13.0-101-generic is doing well.
Now, to isolate the culprit, I could boot the laptop with an older kernel (3.19.0-77-generic) via the boot loader and see if the issue appears again. However, I would like to speed up the process of isolating where the weak link is. I am somewhat short of time and cannot put the laptop to the test while I use it for work. And the freezes are or might be a bit situational...
In other words, while normally I'd just have tried and seen, now I would really minimize the risk of having a freeze at work. I could prefer not to spend time on fixing the laptop at all and leaving it at home. But obviously I would also like to know whether upgrading the kernel in any other machine means heading for troubles.
So eventually the question. Is there a way to induce some freeze-like situations intendedly so that I can test whether the culprit is the laptop as the kernel it is running on or the laptop as anything but the kernel?
I am aware that the question is a bit paradoxical, because I would aim to stress the system and use the failure to do so as a proof that the system is stable. But perhaps this is an acknowledged strategy.
And, preferably, this should be a quick test and suitable to a power user... otherwise the whole lot is not worth the bother in the first place.
