I don’t know what your previous setup was, but given that running resolved fixes your DNS issues, run:

ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

This will point programs that use /etc/resolved.conf during DNS resolution to the local DNS server provided by systemd-resolved.

Then, enable resolved so that it is started when you reboot:

systemctl enable systemd-resolved.service

Finally, start the service so that it is available immediately:

systemctl start systemd-resolved.service

You will want it run those with the required permissions, e. g. via sudo.

The parent comment is correct. CODE is the server, you need the “Collabora Online app” for document editing. I’m not aware if there are alternatives to the ownCloud / Nextcloud apps.

I’ll post some links, but it’s a pretty busy week for me already, so give me some time.

An interrupt is an input that can be triggered to interrupt normal execution. It is used for e. g. hardware devices to signal the processor something has happened that requires timely processing, so that real-time behavior can be achieved (for variable definitions of real-time). Interrupts can also be triggered by software, and this explanation is a gross oversimplification, but that information is what is most likely relevant and interesting for your case at this point.

The commands you posted will sort the interrupts and output the one with the highest count (via head -1), thereby determining the interrupt that gets triggered the most. It will then disable that interrupt via the user-space interface to the ACPI interrupts.

One of the goals of ACPI is to provide a kind of general hardware abstraction without knowing the particular details about each and every hardware device. This is facilitated by offering (among other things), general purpose interrupts - GPEs. One of these GPEs is being triggered a lot, and the processing of that interrupt is what causes your CPU spikes.

The changes you made will not persist after a reboot.

Since this is handled by kworker, you could try and investigate further via the workqueue tools: https://github.com/torvalds/linux/tree/master/tools/workqueue

In general, Linux will detect if excessive GPEs are generated (look for the term “GPE storm” in your kernel log) and stop handling the interrupts by switching to polling. If that happens, or if the interrupts are manually disabled, the system might not react to certain events in a timely manner. What that means for each particular case depends on what the interrupts are being responsible for - hard to tell without additional details.

I shudder to think OP’s post was written by an actual person…