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.

zenwalk 5.2 in Toshiba Satellite (L305D-S5869)

2022 update

The original post from 2008 is at the bottom, but I just couldn't help wanting this dinosaur alive. NB: You must get the replacement battery for the model S5869 which is 11.1 VDC, not the 10.8 VDC of most replacements. I could not get the laptop to boot with a 10.8VDC battery.

battery and sdd

• $0 CMOS battery: run down, but I don't have an adjustable soldering iron right now, so I installed ntp and ran

  # ntpdate pool.ntp.org

  right after connecting to my local router
• $19 battery: an inexpensive Chinese "TA3533LH" Li-Ion, 5200mAh, 6 cell. However, when I received it, it was for the
• $15 hdd -> ssd: I'd read somewhere that SATAIII was backwards compatible with SATAI and II, so I simply bought a new drive and moved stuff over.
• $0 OS: The latest version of Arch worked fine with the old hardware.

From 2008

These were on-sale recently (9/25) at Fry's and seemed like a good deal although it's understood the Linux factor might be difficult with ATI video and so on. Still for $400:

15.4 WXGA
AMD Athlon 64 X2 Dual Core
1024 MB PC6400 SDRAM
Radeon 3100HD (RS780) w/VGA out
Atheros AR5007EG (wifi)
Realtek RTL8102E (ethernet)
Realtek ALC268 (sound)
120GB 5400 RPM SATA 2.5"
DVD RW, PCMCIA, SD port
3xUSB 2.0
No bluetooth or videocamera

Booted into pre-installed Windows Vista first. The return policy is 15 days for laptops and specifies software and hardware must remain unmodified. After verification of hardware features, I blew out the unbelievably bloaty factory load, dropped in a boot disk, formatted, and mke2fs /dev/sda1. Nice.

Slackware 12.0

I had a Slack 12.0 DVD gathering dust available and Slackware is my favorite. However, errors appeared on installation and it seemed an extensive parameter set was required to tame them:

#boot nosmp noapic irqpoll

To me, these problems meant that, if I continued with the Slack install on the newer hardware, I might be compiling and patching over the weekend, or that I should download and burn Slack 12.1 and begin there. I also had a copy of Slackware-based Zenwalk (formerly Minislack) 5.2 which possessed a newer kernel and a supposedly candy-coated installation process. Choices.

Zenwalk 5.2

Installed smoothly with only irqpoll needed as a parameter.

Atheros AR242x 64 (5007 chipset)
The instructions here were helpful for understanding this newer card. Zenwalk provides ath5k, but it wasn't going well. The Madwifi site has information on ath5k here, and it appears the ath5k module will eventually be effective. Currently however, the steps which worked were:

1. in /etc/modprobe.d/blacklist, blacklist the "ath5k" module
2. reboot and lsmod - make sure the ath5k is gone
3. download madwifi-hal-0.10.5.6-r3861-20080903.tar.gz , or the newest one there, make, and install.
4. reboot again and lsmod
5. iwconfig ath0

WEP and WPA
WEP is trivial, merely need the two iwconfig commands "essid" and "key restricted" to make it work. WPA, on the other hand, is a separate post. It only took 10 minutes to configure, but the description is too long for this overview. If one has a distro which requires kernel modification for WPA, the process becomes longer. This site seems to explain it t I'm also currently building a chart for easier understanding based on this site.

screen brightness and gamma
The default settings for screen brightness and backlighting install maxed at 100%, and the Fn buttons don't seem to work except in Windows - battery life, screen life, eyestrain. Without going into X, one has command-line control over the brightness. Look in /proc/acpi/video/VGA/LCD/brightness to see the possible brightness settings for the card, such as 25, 50, 75%, and so on. I like 25%, so:

#echo -n 25 > /proc/acpi/video/VGA/LCD/brightness

It appears we cannot change the backlighting outside of X, though I haven't researched. Once in X however, open a terminal and select any number between 0.00 and 1.0 for gamma, eg:

xgamma -gamma 0.75

Realtek ALC268 Sound
Some duplicate alsamixer settings were seen. For example, alsamixer showed two microphone capture bars when only one channel was connected. I went to the Realtek downloads site, clicked a link there to the "HD Audio Codec Driver", and agreed to licensing language. After download and unpacking, it turned out this was the latest release of ALSA, so it basically installs the latest ALSA, but apparently with a newer HD driver. The alsamixer showed proper inputs following this ALSA update. and so, after setting levels, it was time for # alsactl store.

Radeon 3100HD RS780MC
Initially, Zenwalk loaded the vesa driver in /etc/xorg.conf, providing resolutions of 800x600. Common sense and #gtf seemed to indicate higher resolutions were available. In /etc/xorg.conf, I replaced "vesa" with, alternately, "ati", "radeon", and "radeonhd"; these did nothing but break X. I then relented for the proprietary driver "fglrx" described on most blogs as bloaty and slow, but operational. The driver was avialable here by selecting the Linux x86_64 -> Radeon -> ATI Radeon HD 3xxx Series and pressing "go". One note about installing this - I received checksum errors when I attemped to install it with #. ati*; I had to explicitly invoke bash #bash ati*. However, following this installation, I simply replaced "vesa" with "fglrx" in the Device section of /etc/X11/xorg.conf, rebooted, and everything worked. With the vesa-fglrx swap, the /etc/X11/xorg.conf file looks like this:

Section "Device"
Identifier "Videocard1"
VendorName "ATI Technologies Inc"
BoardName "Video device"
Driver "fglrx"
BusID "PCI:1:5:0"
Option "RenderAccel" "true"
EndSection

Adjustments to the fglrx module "Options" can come some other weekend; resolution and display appear sharp currently.

additional fglrx considerations for the Radeon 3100HD R5780MC
The fglrx driver, although supplied by Radeon, does appear to have significant Googleland complaints for slowness. For me, it renders well, but very slowly: I'm experience update lines even scrolling through a simple text page on Mousepad, etc. So, it appears something either a)very inefficient, or b)very underpowered, is taking place in terms of memory usage with the fglrx driver. From Google, it appears there are a few things to investigate: 1) does flglrx load as a module? (lsmod |grep fglrx). Mine does not appear in lsmod, and this apparently means xorg.conf loads a substandard fglrx_drv.ko module. Lsmod failed to locate this module either. Odd. 2) Settings in /etc/X11/xorg.conf for the fglrx driver, under "Options" may be important. 3)Settings (don't know syntax or location) for whether the ATI card uses SIDEPORT mode (card uses its own memory),UMA mode (card shares system memory), or another unnamed mode where it uses a mix of SIDEPORT and UMA. One thing for sure, a lifesaver in these forum boards is fglrxinfo or fglrxinfo -v:

# fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.4 (2.1 Mesa 7.0.3)

glxinfo is also important. On my system, glx is not enabled, though this may be a different problem than the overall slowness of screen panning and scrolling that I'm experiencing. A good forum thread for these issues is here, not for solutions but for the many aspects of the problem.

netpkg repos
Each time zenwalk is released, the repositories update to the most current release so that, if one needs a certain package, they generally have to update the rest of their system to be in sync with it. Suppose I like my release and just want to keep it into perpetuity. As long as 1) I have the installation disk 2) have netpkg'ed all the programs from that release I want (they download to /var/packages), and 3) have downloaded a copy of PACKAGES.TXT.gz, I can point netpkg to /var/packages and use the older release. A couple of simple modifications are required with two configuration files since netpkg doesn't inherently recognize URLs of the type "file:///". This link describes the changes to the two files, /usr/libexec/netpkg-functions and /etc/netpkg.config files, which I repeat here.

/usr/libexec/netpkg-functions, at or about line 144:

if [ $( echo "$url" | egrep -e "ftp:.*|http:.*|file:.*" ) ]; then

...at or about line 205:

if [ ! "$(echo $mirror | egrep 'http://|ftp://|file://')" ] ; then

/etc/netpkg.conf add another line such as

Internet_mirror = file:///var/packages

Put a copy of PACKAGES.TXT.gz into /var/packages, and you've got a self-contained distribution.

unsolved: multiple instantiation of mplayer, thunar, etc
Perhaps because of multiple processors, there's currently a problem when using DVD's. Multiple instances of related applications appear, eg 2 x MPlayer or 2 x Thunar. Working around this by disabling automatic HAL events for the time being. Manually opening one instance of the application for now.