The whole system froze for something like 30 seconds, then a process got killed

[throwaway45224]

Upgraded from xenial to zesty recently.

I was using a Firefox instance, one which is a part of Tor Browser Bundled. First, the application window grayed out, then the whole system froze for something like 30 seconds (I tried to switch to VT1 to no avail), then the process got killed.

Well, not exactly killed.

The grayed-out window is still there, `xprop | grep PID` and clicking on it gives:

```
_NET_WM_PID(CARDINAL) = 13
```

PID 13 is a child of kthreadd:

```
$ ps -A | awk '$1 == "13" { print }'
   13 ? 00:00:00 cpuhp/1
```

And this is how the relevant part of `ps -AH` with the "killed" process looks like:

```
 5709 pts/11 00:00:00 firejail
 5710 pts/11 00:00:00 firejail
 5725 pts/11 00:00:00 bash
 5736 pts/11 00:56:49 firefox <defunct>
 5769 pts/11 00:00:24 tor
```

EDIT: Launchpad doesn't preserve whitespace apparently, so I'm adding the output above as ps.log.

I checked syslog and dmesg. Both of them have an interesting and identical message, which I add as dmesg.log.

I also add the output of `cat /proc/version_signature` as version.log.

I don't think `sudo lspci -vnvn` is relevant here, so I'm not gonna share it unless absolutely necessary.

The crashed process will be there for something like 2 or 3 days at least (I don't restart my laptop often), so feel free to ask me to manipulate or query it somehow, if necessary.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1683091

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[throwaway45224 (throwaway45224)]

I also had a similar, but maybe not identical issue today.

First, several application windows grayed out, one after another. Then my system slowed down and after a few seconds became completely unresponsive. Of course, I couldn't switch to VT1 too. I waited for more than 10 minutes, but nothing changed, so I restarted the laptop.

What is unusual about the situation is that during the freeze there was no HDD activity (the blinkenlight didn't blink even once and I didn't hear my HDD) and the CPU apparently did almost nothing too (my laptop's fan was completely silent).

Unfortunately, there was nothing interesting in syslog when I checked it after the restart, and checking out dmesg after a restart wouldn't help much too.

I never experienced anything like this when I was on xenial. On xenial, usually, when I was running out of memory and swap, my system would become very, but not completely unresponsive, the fan would spin like crazy, the blinkenlight responsible for HDD activity would blink like crazy, and of course I would be able to hear the HDD too. I would usually switch to VT1, patiently wait until the switch actually happened, then type a command to kill the offending process. The 2 incidents that happened to me today (after I had upgraded to zesty) were nothing like this.

[throwaway45224 (throwaway45224)]

I have already mentioned that I'm not gonna share the output of `sudo lspci -vnvn` unless absolutely necessary to resolve this issue, so I'm changing the bug status to 'Confirmed', as instructed by brad-figg.

If you believe that the output of `sudo lspci -vnvn` is absolutely necessary to resolve this issue, please explain why.

[Joseph Salisbury (jsalisbury)]

Do you have a way to reproduced this bug, or was it a one time event?

[throwaway45224 (throwaway45224)]

Unfortunately, there's no reliable way to reproduce it, but similar issues happen quite regularly. There were at least 9 cases since I reported the bug. Sometimes the system freezes completely and I have to restart, sometimes only one process gets killed, while its window is still there, doing nothing and being gray. The grayed-out window's owner (from `xprop | grep PID`) is always PID=13, which is always [cpuhp/1]. Oh, and also, when I say the system freezes completely, it sometimes might not be entirely true: sometimes I have a web server running and it still responds to requests; if I have music playing, sometimes it continues to play even after the freeze. But the system doesn't respond to any keyboard or mouse events.

I updated the kernel to 4.10.0.20.22 on 2017-04-28 23:44:32. Subjectively, the issues became even worse and more frequent.

I save syslogs after every freeze or similar event. I will post them after I prune them. I'm not sure though. Should I post all of them in this issue or create a new one, which would describe the bug more accurately? After all, this bug is about a process getting killed after a short freeze, not about permanent freezes, even though I encounter both.

Also, am I the only one affected? Really?

[throwaway45224 (throwaway45224)]

Related: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1688643.

[throwaway45224 (throwaway45224)]

Related: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1687731.

[throwaway45224 (throwaway45224)]

Related: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1684080.

[throwaway45224 (throwaway45224)]

Related: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838.