FAIL: cooling/acpi in a 2008 trashiba

Links: fan speed control :: cooling and acpi :: fancontrol :: Satellite L305D-S5869 :: One user's solution - v.2.0

---

I have a disposable Satellite L305D-S5869 or, more specifically, a PSLC8U-00Y010, for trips and low priority activities. It has the older Toshiba BIOS (Insyde H20 Rev 3.5 v. 1.8) with flakey DSDT code; it's hit or miss with ACPI or kernel module fan speed control. This appears to apply mostly to Slackware and Slackware hybrids; the laptop's fans do occasionally work with Fedora-based OS's. Another challenge for this crappy BIOS is hibernation, but that's another post.

$ lsmod |grep thermal
thermal 8082 0
thermal_sys 13862 4 thermal,processor,video,fan
hwmon 1473 3 radeon,thermal_sys,k10temp

$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1: +56.9°C (high = +70.0°C)

acpitz-virtual-0
Adapter: Virtual device
temp1: +56.0°C (crit = +105.0°C)

Not bad, except I had never heard the fan on even at over 70C. Taking a trip into the BIOS, there were no ACPI settings, but I added append="acpi=force"into LILO. Still over 70C with no fans. (On the BIOS tip, you can read further down that I also updated the BIOS to the latest version to no avail).

fancontrol

We can set thresholds to whatever we'd like, using the program to increase or decrease fan use. I don't yet have a configuration file in place.

# fancontrol
Loading configuration from /etc/fancontrol ...
Error: Can't read configuration file

# ls /etc/fancontrol
ls: cannot access /etc/fancontrol: No such file or directory

A larger problems; it may be that fancontrol cannot detect my fans -- its configuration editor is unable to detect them.

# pwmconfig
pwmconfig revision 5770 (2009-09-16)
/usr/sbin/pwmconfig: There are no pwm-capable sensor modules installed

At first cut, it appears no Pulse Width Modification controllable fans are in the laptop, but it may be the system fan is controllable via some other method(s). It's also of note that KDE is the WM running, and that Kinfocenter does not indicate hardware has been properly detected. Fedora-based distros have had no such problems. Accordingly, although this post began about cooling, detection is the first order of business, and it has been added to the title in parentheses.

Notably, Kinfocenter provides identical results as lshal, where it might have looked for its information:

# lshal
[snip]
udi = '/org/freedesktop/Hal/devices/acpi_CPU0'
info.category = 'processor' (string)
info.product = 'Unknown Processor' (string)

So instead of hal or other OS detection, let's directly access fan information.

# ls /sys/class/thermal
cooling_device0 cooling_device1 cooling_device2 cooling_device3 thermal_zone0

# cat /sys/class/thermal/cooling_device0/device/hid
PNP0C0B

# cat /sys/class/thermal/cooling_device0/device/modalias
acpi:PNP0C0B:

So this fan's ACPI identifier is PNP0C0B. The fan is currently off; what are its range of possible values when running?

# cat /sys/class/thermal/cooling_device0/device/thermal_cooling/cur_state
0

# cat /sys/class/thermal/cooling_device0/device/thermal_cooling/max_state
1

# cat /sys/class/thermal/cooling_device0/device/thermal_cooling/power/control
auto

Now it's clear why no PWM functionality was detected by pwmconfig: the fan's options are apparently either "on" or "off". Power is controlled "auto"-matically. But similarly to these commands for a backlight, let's attempt to turn on "cooling_device0".

# echo 1 > /sys/class/thermal/cooling_device0/device/thermal_cooling/power/wakeup_active
bash: /sys/class/thermal/cooling_device0/device/thermal_cooling/power/wakeup_active: Permission denied

This sort of problem continued with other attempts "invalid parameters" and so forth. The next step seemed to be query the device for legal settings. Assistance via a specialized program to add to efficiency seemed sensible.

acpitool

Links: acpitool :: acpitool GUI

---

I'm running a Toshiba laptop, so let's try

# acpitool -F 1
Forcing the fan of/off is only supported on Toshiba laptops.
No Toshiba ACPI extensions were found.

Hah! OK, so "No Toshiba ACPI extensions" on a Toshiba laptop means that either specific kernel modules are not loading for Toshiba, or playing with the BIOS and LILO until this changes. Probably the former, toshiba_acpi.ko.

# find -name toshiba_acpi.ko
./lib/modules/2.6.37.6/kernel/drivers/platform/x86/toshiba_acpi.ko

# lsmod |grep toshiba

# grep -n toshiba /etc/rc.d/rc.modules
178:#/sbin/modprobe toshiba_acpi

# nano /etc/rc.d/rc.modules
/sbin/modprobe/toshiba_acpi
/sbin/modprobe/thermal
/sbin/modprobe/processor
/sbin/modprobe/fan

Hopefully this is not too many modules and hogs memory. Following this I rebooted.

# lsmod |grep toshiba

Huh. Okay then...

# modprobe toshiba_acpi
FATAL: Error inserting toshiba_acpi (/lib/modules/2.6.37.6/kernel/drivers/platform/x86/toshiba_acpi.ko): No such device

Not good. Per this site, I checked the BIOS and note that the BIOS is not Toshiba. Appears I will have to recompile the kernel and enable (menuconfig) Device Drivers / x86 Platform Specific Device Drivers / Toshiba Laptop Extras . I'm dubious since, if it can't load an external module, how is it likely to work as a built-in option. Still, have to try everything for cooling...

post kernel - BIOS

As feared, the kernel was unable to detect the Toshiba-ness of the laptop, even after building in the Toshiba-specific features above, in addition to some other switches which I hoped would allow the kernel to grasp it was in a Toshiba.

# acpitool -F 1
Forcing the fan of/off is only supported on Toshiba laptops.
No Toshiba ACPI extensions were found.

Next stop is the BIOS. The BIOS, Insyde H20 v.1.2 rev.3.5, appears rudimentary and has no ACPI settings. Perhaps we can flash it to something better/more recent. At the Toshiba website, the most recent (April 2009) BIOS for the L305D. Sort of old and the file is Windows specific - slc8v180.exe. I ran strings against it see if it was just an archive.

$ strings slc8v180.exe
[snip] processorArchitecture="X86" name="Roshal.WinRAR.WinRAR" type="win32" /> WinRAR archiver

I was able to unpack this. I found a bootable ISO in the files with a README to reboot with it. Thereafter, I burned the ISO to a CD, and rebooted the system. Voila, the Insyde BIOS updated from 1.2 to 1.8. However, looking inside it, no ACPI functions were added, and I still get the following:

# modprobe toshiba_acpi
FATAL: Error inserting toshiba_acpi (/lib/modules/2.6.37.6/kernel/drivers/platform/x86/toshiba_acpi.ko): No such device

Arch installation

Let's see if we can find better interaction with a different OS, with a newer kernel. Installed Arch and then compiled acpitool.

# acpitool -F 1
Could not open file : /proc/acpi/toshiba/fan
You must have write access to /proc/acpi/toshiba/fan to stop or start the fan.
Or ensure yourself you are running a kernel with Toshiba ACPI support enabled.

Fails, but more information. Acpitool apparently only points at /proc/acpi/toshiba/fan, but the fan directory for this this system is /sys/bus/acpi/drivers/fan. Let's attempt a softlink, first being sure there is a /proc/acpi/toshiba directory into which we can link a "fans" directory.

# ls /proc/acpi/toshiba
keys version

# ln -s /sys/bus/acpi/drivers/fan /proc/acpi/toshiba
ln: failed to create symbolic link '/proc/acpi/toshiba/fan': No such
file or directory

Let me get this straight, ln fails to create a directory, because the directory it's supposed to create doesn't exist before it creates it? Brilliant program. But at any rate, the device in the "fan" directory, PNP0C0B:00, is a symlink to another directory.

$ ls -an /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00
total 0
drwxr-xr-x 4 0 0 0 Aug 1 12:06 .
drwxr-xr-x 6 0 0 0 Aug 1 12:06 ..
lrwxrwxrwx 1 0 0 0 Aug 1 18:42 driver -> ../../../../bus/acpi/drivers/fan
-r--r--r-- 1 0 0 4096 Aug 1 18:41 hid
-r--r--r-- 1 0 0 4096 Aug 1 18:41 modalias
-r--r--r-- 1 0 0 4096 Aug 1 18:41 path
drwxr-xr-x 2 0 0 0 Aug 1 18:41 power
drwxr-xr-x 2 0 0 0 Aug 1 18:41 power_resources_D0
-r--r--r-- 1 0 0 4096 Aug 1 18:41 power_state
-r--r--r-- 1 0 0 4096 Aug 1 18:41 real_power_state
lrwxrwxrwx 1 0 0 0 Aug 1 18:42 subsystem -> ../../../../bus/acpi
lrwxrwxrwx 1 0 0 0 Aug 1 18:42 thermal_cooling -> ../../../virtual/thermal/cooling_device3
-rw-r--r-- 1 0 0 4096 Aug 1 12:06 uevent
-r--r--r-- 1 0 0 4096 Aug 1 18:41 uid

Yep, acpi "proc" is being replaced by the newer "sys", which also effects "suspend", and other acpi activity. Which is the power state we need to change for the fan? Here are the "cats" for various of these entries:

driver directory
hid PNP0C0B
modalias acpi:PNP0C0B:
path \_TZ_.FAN1
power directory
power_resources_D0 directory
power_state D3cold
real_power_state D3cold
uevent DRIVER=fan
MODALIAS=acpi:PNP0C0B:
uid 2

Now in each of these three sub-directories "driver", "power", and "power_resources_D0"

/driver/
drwxr-xr-x 2 0 0 0 Aug 1 12:07 .
drwxr-xr-x 14 0 0 0 Aug 1 12:06 ..
lrwxrwxrwx 1 0 0 0 Aug 1 18:39 PNP0C0B:00 -> ../../../../devices/LNXSYSTM:00/device:44/PNP0C0B:00
--w------- 1 0 0 4096 Aug 1 18:37 bind
--w------- 1 0 0 4096 Aug 1 12:07 uevent
--w------- 1 0 0 4096 Aug 1 18:37 unbind

/power/
drwxr-xr-x 2 0 0 0 Aug 1 18:41 .
drwxr-xr-x 4 0 0 0 Aug 1 12:06 ..
-rw-r--r-- 1 0 0 4096 Aug 1 19:17 async
-rw-r--r-- 1 0 0 4096 Aug 1 19:17 autosuspend_delay_ms
-rw-r--r-- 1 0 0 4096 Aug 1 19:17 control
-r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_active_kids
-r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_active_time
-r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_enabled
-r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_status
-r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_suspended_time
-r--r--r-- 1 0 0 4096 Aug 1 19:17 runtime_usage

/power_resources_D0/
drwxr-xr-x 2 0 0 0 Aug 1 18:41 .
drwxr-xr-x 4 0 0 0 Aug 1 12:06 ..
lrwxrwxrwx 1 0 0 0 Aug 1 19:19 LNXPOWER:00 -> ../../LNXPOWER:00

The two symlinks are problematic infinite loops, but "power" appears to contain a useful writeable file named "control". According to this site, which is about USB, but has the appropriate power information, we should be able to use /power/control to change the fan's state from "auto" to "on".

$ cat /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00/power/control
auto

# echo on > /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00/power/control

$ cat /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00/power/control
on

$ cat /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00/power_state
D3cold

In other words, although the device seems to accept the power change, the fan does not power-up. And though we can see it in sys/devices, it's not detected by the kernel. Yeah, we see it in dmesg during boot, but it never is seen by the kernel -- we can tell because it never forms an entry in /proc/acpi. During boot, it's called "FAN1", but after that...gone.

$ dmesg |grep ACPI
PnP ACPI: found 10 devices
ACPI: bus type PNP unregistered
ACPI: bus type USB registered
ACPI: Battery Slot [BAT0] (battery present)
ACPI: AC Adapter [ADP0] (on-line)
ACPI: Power Button [PWRB]
ACPI: Lid Switch [LID]
ACPI: Power Button [PWRF]
ACPI: Video Device [VGA] (multi-head: yes rom: no post: no)
ACPI: Thermal Zone [THZN] (50 C)
ACPI: Fan [FAN1] (off)

# cd /proc/acpi

# grep -rn LID *
wakeup:2:LID S4 *enabled

# grep -rn FAN *
# grep -rni fan *

$ acpi -V
Battery 0: Unknown, 100%
Battery 0: design capacity 4000 mAh, last full capacity 2541 mAh = 63%
Adapter 0: on-line
Thermal 0: ok, 48.0 degrees C
Thermal 0: trip point 0 switches to mode critical at temperature 105.0 degrees C
Cooling 0: Fan 0 of 1
Cooling 1: LCD 3 of 7
Cooling 2: Processor 0 of 3
Cooling 3: Processor 0 of 10

Seems to be there, but nothing....

How about in /sys/bus/acpi/drivers/fan?

$ ls /sys/bus/acpi/drivers/fan
PNP0C0B:00 bind uevent unbind

$ ls /sys/bus/acpi/drivers/fan/PNP0C0B:00/
driver hid modalias path power power_resources_D0 power_state real_power_state subsystem thermal_cooling uevent uid

These are the same settings (and same problems) as earlier above in the former configuration: /sys/devices/LNXSYSTM:00/device:44/PNP0C0B:00/. A Gordian knot with no apparent commands to reach inside it -- so close but so far.