5 acpi_pad processes are each consuming 100% CPU on tin. Between that and puppet running, tin is nearly unresponsive, and everything runs very slowly. It's almost impossible to deploy MediaWiki code right now because of this issue. Just tab-completing a directory name takes 1-2 seconds.
closing this one as tin is back to normal with the short term fix
as follow-up the change above is already in review and linked to the parent task (formerly known as "tracking task") for acpi_pad issues on multiple hosts.
The "Improperly owned -0:0- files in /srv/mediawiki-staging" Icinga check was failing on tin, caused by a timeout of completing the check in time. It turns out tin is currently running with approx 200 MHz only:
root@tin:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
This is probably not caused by rmmoding acpi_pad, but a different aspect of the same bug on those R320 models.