From your dmesg, thinkpad_acpi gets loaded. I had a quick look at the kernel source code, and there don't seem to be any fan related messages it outputs.
However, some comments in the code say:
ThinkPad EC register 0x84 (LSB), 0x85 (MSB):
Main fan tachometer reading (in RPM)
This register is present on all ThinkPads with a new-...
According to RHEL documentation:
This message is informational only. It does not indicate anything is wrong and can be safely ignored.
The system hardware defines a 32-bit register size for its ACPI Pm1aControlBlock and Pm2ControlBlock, however the ACPI specification defines a 16-bit register size for the Pm1aControlBlock and 8-bit ...
You can try "acpi=noirq" instead. That's the only way I can get my ttyS0 to work with Serial-Over-Lan on an Intel AMT platform. It doesn't seem to have any ill effects but if anyone else knows a better solution, please share.
You could extract and decompile ACPI table for your computer.
By use Intel's ASL compiler, you could turn your systems DSDT table into source code.
You'll need to install acpica-tools:
Ubuntu: sudo apt-get install acpica-tools
Arch Linux: sudo pacman -S --needed acpica
Here is the steps:
Extract ACPI tables (as root): # cat /sys/firmware/acpi/tables/...
You can also check the battery health by using the inxi tool with this command :
$ ./inxi -Bxxx
Battery: ID-1: BAT0 charge: 39.5 Wh condition: 40.3/47.5 Wh (85%) volts: 10.8/10.8 model: PA5109U-1BRS type: Li-ion
serial: FA80 status: Discharging
and check the condition value.
I'm not a Kali user, this is just a suggestion of something to try much more than an out right answer.
Given that Kali is based on Debian there's a reasonable chance of sharing boot issues.
There's an answer (here https://unix.stackexchange.com/a/255583/20140 ) which points to issues with graphics drivers.
You do have access to get an unbootable system ...
I am not familiar with bbswitch, so I don't know how many details you'll need.
While acpidump will dump the tables, it's better to dump them in binary format (acpidump -b, produces various files) and then use iasl to decompile them.
The ACPI standard is quite complex, details can be found here or here. You may have to do quite a bit of reading.
The problem was with how I plugged my monitor. It was plugged to my graphical card (with a DVI wire) and to my motherboard (with a VGA wire). It worked fine on Windows because I duplicated the display on both. I didn't had that problem on Fedora, I don't know why.
/dev/sda2: clean, 144851/121020416 files, 8908502/484074496 blocks
indicates that ...
I am on a MIO single board computer with the same problem: sudo reboot or [CTRL]+[ALT]+[DEL] leads to hanging at
watchdog did not stop
None of the above worked for me, but thankfully a combination of them did the job:
Use GRUB_CMDLINE_LINUX="reboot=bios" (reboot=acpi did not work for me)
Use systemctl reboot -i, to successfully reboot the system. (...
In Linux 4.19, I found that disabling the GPE (echo "disable" > /sys/firmware/acpi/interrupts/gpe17) did not fix this issue anymore. Even with the GPE disabled, the number kept running up and the CPU kept busy. It seems the new solution since Linux 4.10 is masking instead of disabling:
# echo mask > /sys/firmware/acpi/interrupts/gpe17
Or use the boot ...