How do I kill an IRQ process in Linux?

You've probably been hacked and they are running spambots, tradingbots or even mining. Get in firewall the crap out of it, change root password, deinstall any instance of Openssh and upgrade the kernel. I just moved up to the next release.

Be sure to block outgoing ssh. Then watch the ufw.log as the peers try to connect (list of other hacked nodes in the network). Note the list of repositories when running the upgrade. You are likely to note your desktop's 'username'-files as a subdomain listed. Because they tar balled and ex-filtrated your workstation's files when you connected.

Then dig in... I'm looking for the credentials to kill the repository.

As @hobbs explained, it is a kernel thread. A broader perspective is the following:

IRQ handling is problematic in any OS because interrupts can arrive at any time. Interrupts can arrive even while the kernel is in the middle of working on a complex task and resources are inconsistent (pointers are pointing to invalid addresses and so on). This problem can be solved with locks, i.e. don't allow the interrupt handlers to run until the kernel is in an interruptible, consistent state. The disadvantage of using locks is that too many locks make the system slow and inefficient.

Thus, the optimal solution for the problem is this:

1. The kernel interrupt handlers are as short as possible.
2. Their only job is to move all relevant interrupt data into a temporary buffer
3. Some "background" thread works continuously on this buffer and does the real work on behalf of the interrupt handlers.

These "background" threads are the interrupt handler kernel threads.

• You see them in top as normal processes.
• However, they are displayed as if they use zero memory.
• And yes, this is true, because no real user space memory belongs to them.

They are essentially kernel threads running in the background.

You can't kill kernel threads: they are managed entirely by the kernel. If you could kill it, the irq/142 handler in your nvidia driver wouldn't exist any more: if your video card sends an interrupt, nothing would handle it. The result would be likely a freeze, but your video surely wouldn't work any more.

The problem in your system is that this interrupt handler gets a lot of CPU resource. There are many potential reasons:

• For some reason, the hardware (your video card) sends so many interrupts that your CPU can't handle all of them.
• The hardware is buggy.
• The driver is buggy.

Knowing the quality of the Nvidia drivers, unfortunately a buggy driver is the most likely.

The solution is to somehow reset this driver. Some ideas, ordered ascending by brutality:

• Is it running some 3D accelerated process in the background? Google Earth, for example? If yes, stop or kill it.
• From X, switch back to character console (alt/ctrl/f1) and then back (alt/ctrl/f7). Then most of the video will re-initialize.
• Restart X (exit ordinarily, or type alt/ctrl/backspace to kill the X server).
• Kill X (killall -9 Xorg). It is better if you do this from the character console.

If you kill X and you still see this kernel thread, you may try to remove the Nvidia kernel module (you can see it in the list given by lsmod, then you can remove it with rmmod). Restarting X will insmod it automatically, resetting the hardware.

If none of these work, you need to reboot. If an ordinary reboot doesn't work you can do this with additional brutality: use alt/printscreen/s followed by alt/printscreen/b.

---

Extension: as a temporary workaround you could try to give a very low priority to that thread (renice +20 -p 1135). Then it will still run, but it will have less impact on your system performance.

You can't. It's not a process, it's a kernel thread. You can't kill it, and if you did manage to you would only make your system (more) unusable.