Latest working kernel version: N/A Distribution: Gentoo Hardware Environment: Toshiba Satellite L300-214 Software Environment: GCC version 4.1.2 (Gentoo 4.1.2 p1.0.2) Binutils 2.18-r3 Grub (GNU GRUB 0.97) Architecture: x86_64 Grub Kernel additional boot flags: acpi_osi="Linux" Kernel ACPI compiled modules: ACPI_TOSHIBA (Toshiba Laptop Extras) Selected values from /proc/acpi: # grep . thermal_zone/*/* | head -n11; echo; grep . fan/*/* thermal_zone/THRM/cooling_mode:0 - Active; 1 - Passive thermal_zone/THRM/polling_frequency:<polling disabled> thermal_zone/THRM/state:state: ok thermal_zone/THRM/temperature:temperature: 48 C thermal_zone/THRM/trip_points:critical (S5): 110 C thermal_zone/THRM/trip_points:passive: 110 C: tc1=2 tc2=5 tsp=300 devices=CPU0 CPU1 thermal_zone/THRM/trip_points:active[0]: 70 C: devices= FAN status: on Problem Description: After resuming from suspend to ram (previously suspending through 'echo mem > /sys/power/state') the system's fan doesn't turn on or does rotate but very slowly and doesn't speed up with the temperature increase. I've tried to wait and observed the temperature from 'sensors', I reached 70-75C which made me turn off the laptop quickly to cool it down.
> acpi_osi="Linux" why? what changes to you see when you add this option? please attach the output from acpidump > ACPI_TOSHIBA Do you still have the same problem with this is excluded from the kernel build? Please paste the output of grep . /proc/acpi/thermal_zone/*/* /proc/acpi/fan/*/* before and after suspend. The output above shows a single active trip point at 70C, so I would not expect to hear the fan speed up until that temperature is reached. However, after it is reached, you should hear the fan speed up and should see that indicated in the grep output above
Created attachment 21316 [details] acpidump output with acpi_osi="Linux" flag
Created attachment 21317 [details] acpidump output after omitting that flag
(In reply to comment #1) > > acpi_osi="Linux" > why? what changes to you see when you add this option? Without this option, the laptop's fan starts to act strangely or more seems to be uncontrolled anymore by ACPI. The effect is that the fan starts once and keeps turning at it's max speed and never stops. I got you 'grep . /proc/acpi/thermal_zone/*/* /proc/acpi/fan/*/*' output after removing that flag: $ grep . /proc/acpi/thermal_zone/*/* /proc/acpi/fan/*/* /proc/acpi/thermal_zone/THRM/cooling_mode:0 - Active; 1 - Passive /proc/acpi/thermal_zone/THRM/polling_frequency:<polling disabled> /proc/acpi/thermal_zone/THRM/state:state: ok /proc/acpi/thermal_zone/THRM/temperature:temperature: 41 C /proc/acpi/thermal_zone/THRM/trip_points:critical (S5): 110 C /proc/acpi/thermal_zone/THRM/trip_points:passive: 110 C: tc1=2 tc2=5 tsp=300 devices=CPU0 CPU1 /proc/acpi/thermal_zone/THRM/trip_points:active[0]: 70 C: devices= FAN /proc/acpi/fan/FAN/state:status: on Here's 'sensors' output: $ sensors coretemp-isa-0000 Adapter: ISA adapter Core 0: +36°C (high = +100°C) coretemp-isa-0001 Adapter: ISA adapter Core 1: +36°C (high = +100°C) The temperature is at 36C but still the fan doesn't stop and turns at it's full speed. Inserting that flag, I do not experience such kind of behaviour. > please attach the output from acpidump I've attached the both output of 'acpidump' while having acpi_osi flag and without it. Please check them above. > > ACPI_TOSHIBA > > Do you still have the same problem with this is excluded from the kernel > build? I actually compiled the kernel with this module, because my battery wasn't functioning properly under Power Management. The battery didn't seem to be recognized as the laptop didn't use to shutdown on critical battery state. Though, the suspend behaviour is the same in both cases (with or without that module). > Please paste the output of > grep . /proc/acpi/thermal_zone/*/* /proc/acpi/fan/*/* > > before and after suspend. Before suspend: $ grep . /proc/acpi/thermal_zone/*/* /proc/acpi/fan/*/* /proc/acpi/thermal_zone/THRM/cooling_mode:0 - Active; 1 - Passive /proc/acpi/thermal_zone/THRM/polling_frequency:<polling disabled> /proc/acpi/thermal_zone/THRM/state:state: ok /proc/acpi/thermal_zone/THRM/temperature:temperature: 46 C /proc/acpi/thermal_zone/THRM/trip_points:critical (S5): 110 C /proc/acpi/thermal_zone/THRM/trip_points:passive: 110 C: tc1=2 tc2=5 tsp=300 devices=CPU0 CPU1 /proc/acpi/thermal_zone/THRM/trip_points:active[0]: 70 C: devices= FAN /proc/acpi/fan/FAN/state:status: on After suspend: # grep . /proc/acpi/thermal_zone/*/* /proc/acpi/fan/*/* /proc/acpi/thermal_zone/THRM/cooling_mode:0 - Active; 1 - Passive /proc/acpi/thermal_zone/THRM/polling_frequency:<polling disabled> /proc/acpi/thermal_zone/THRM/state:state: active[0] /proc/acpi/thermal_zone/THRM/temperature:temperature: 53 C /proc/acpi/thermal_zone/THRM/trip_points:critical (S5): 110 C /proc/acpi/thermal_zone/THRM/trip_points:passive: 110 C: tc1=2 tc2=5 tsp=300 devices=CPU0 CPU1 /proc/acpi/thermal_zone/THRM/trip_points:active[0]: 70 C: devices= FAN /proc/acpi/fan/FAN/state:status: on
what if you turn off the fan manually? i.e. echo 3 > /proc/acpi/fan/FAN/state ? does the fan work normally? does it spin on automatically even if the system is cool? You mentioned that the fan doesn't turn on after S3, do you mean "/proc/acpi/fan/FAN/state:status:off" or you can not hear the fan spinning? does /proc/acpi/fan/FAN/state always reflect the correct state of the fan?
Hah, fake ACPI fan device is implemented. PowerResource (FN00, 0x00, 0x0000) { Method (_STA, 0, Serialized) { Return (One) } Method (_ON, 0, Serialized) { } Method (_OFF, 0, Serialized) { } } Device (FAN) { Name (_HID, EisaId ("PNP0C0B")) Name (_UID, Zero) Name (_PR0, Package (0x01) { FN00 }) } I'm sure you can not control the fan state by running echo {0,3} > /proc/acpi/fan/FAN/state, right? We should find out which driver is controlling the fan on this laptop first. but definitely not ACPI. :)
> I'm sure you can not control the fan state by running echo {0,3} > > /proc/acpi/fan/FAN/state, right? Correct, if I try to execute 'echo 3 > /proc/acpi/fan/FAN/state', I receive the following: # echo 3 > /proc/acpi/fan/FAN/state -su: echo: write error: Exec format error > You mentioned that the fan doesn't turn on after S3, > do you mean "/proc/acpi/fan/FAN/state:status:off" or you can not hear the fan > spinning? After suspending to memory, the fan stops spinning completely and never starts what so ever the temperature value reaches. > does /proc/acpi/fan/FAN/state always reflect the correct state of the fan? No. In both cases, before and after suspending, the output of /proc/acpi/fan/FAN/state is always 'status: on'. > We should find out which driver is controlling the fan on this laptop first. > but definitely not ACPI. :) In all forums I checked out, users say that the fan in Toshiba is controlled by ACPI, though I found an Official Japanies Toshiba Linux support webpage. There are some manual pages, a download section, patches under Kernel for developers' interest. Probably this will interest you. So I would like to share it. http://linux.toshiba-dme.co.jp/linux/index.htm (the page is in english)
I was wrong about ACPI_TOSHIBA module. I had it built-in in my Kernel and I didn't check if it was actually working. I tried to apply the newest Toshiba ACPI driver described in this link http://memebeam.org/toys/ToshibaAcpiDriver , mainly linked from http://linux.toshiba-dme.co.jp/linux/eng/download.htm . I had to change the directory in that patch to patch it correctly and re-compiled the ACPI_TOSHIBA as a module. I tried to modprobe it, received: No such device. So I wondered if that module was ever previously working. I reversed the patch and recompiled, nope, failed with the same error. I wanted to try Omnibook driver as followed by that page, but the page doesn't load for me.
re: acpi_osi=Linux The DSDT shows that this doesn't actually add any Linux compatibility, since there are no comparisons of OSYS with 3E8. but it disables all Windows compatibility. So if this parameter actually does have an effect on the fan, then you should see the same result with "acpi_osi=" which disables all OSI strings -- though we don't actually get to see OSYS' default value.... Method (_INI, 0, NotSerialized) { If (CondRefOf (_OSI, Local0)) { If (_OSI ("Linux")) { Store (0x03E8, OSYS) } Else { Store (0x07D0, OSYS) If (_OSI ("Windows 2001")) { Store (0x07D1, OSYS) } If (_OSI ("Windows 2001 SP1")) { Store (0x07D1, OSYS) } If (_OSI ("Windows 2001 SP2")) { Store (0x07D2, OSYS) } If (_OSI ("Windows 2006")) { Store (0x07D6, OSYS) } If (LNotEqual (OSYS, 0x07D6)) { If (_OSI ("Windows 2006 SP1")) { Store (0x07D6, OSYS) } Else { If (_OSI ("Windows 2006 SP2")) { Store (0x07D6, OSYS) } } } } }
do you have a windows partition on this box, and if so, does does the fan spin after windows resumes? does linux work any better if you build it with CONFIG_HWMON=n ?
right. the toshiba_acpi driver looks for "\\_SB_.VALD.GHCI" and "\\_SB_.VALZ.GHCI" when loaded. And apparently they are not available on this laptop. So I agree with Len, we should verify what role hwmon plays on this laptop.
*** Bug 13157 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > do you have a windows partition on this box, > and if so, does does the fan spin after windows resumes? Nope, I got only gentoo on the whole disk. > does linux work any better if you build it with > CONFIG_HWMON=n ? I removed CONFIG_HWMON as suggested. The first reboot after compiling the kernel was abit different than any previous times. The fan was spinning first at the start boot, then stopped after reaching ~44C, then started to spin again on ~57C. I checked the thermal stats in /proc and found nothing new. But this didn't repeat any after. The fan works now (after the first weird case) as usual, at a very low speed, when the temperature is at minimum and increases with the temperature (which isn't something new). Though, after the suspend, the fan still fails. And as I commented before, if acpi_osi=Linux is removed from kernel options in grub, the fan won't work like this, which is a bit weird to the facts that Len stated. I will attach my kernel .config to this post, maybe it will help abit.
Created attachment 21428 [details] kernel's configure file.
re: comment #13 was that test made with default parameters, or with an acpi_osi override?
(In reply to comment #15) > re: comment #13 > was that test made with default parameters, > or with an acpi_osi override? With acpi_osi=Linux.
please attach the output of "grep . /sys/class/hwmon/*/*" when hwmon is running.
(In reply to comment #17) > please attach the output of "grep . /sys/class/hwmon/*/*" when hwmon is > running. I compiled the kernel with the following modules: CONFIG_HWMON=y CONFIG_THERMAL_HWMON=y to get the output. $ grep . /sys/class/hwmon/*/* /sys/class/hwmon/hwmon0/name:acpitz /sys/class/hwmon/hwmon0/temp1_crit:110000 /sys/class/hwmon/hwmon0/temp1_input:52000
please check if the toshiba-acpi driver is loaded or not. If it's loaded, please attach the output of "grep . /proc/acpi/toshiba/*/*"
(In reply to comment #19) > please check if the toshiba-acpi driver is loaded or not. > If it's loaded, please attach the output of "grep . /proc/acpi/toshiba/*/*" I tried to compile ACPI_TOSHIBA module but it won't load. I receive "FATAL: Error inserting toshiba_acpi (/lib/modules/2.6.29-gentoo-r4/kernel/drivers/platform/x86/toshiba_acpi.ko): No such device", which is what you said in Comment #11.
well, the fan is controlled by neither ACPI fan driver nor toshiba platform driver. IMO, this is not an ACPI bug because we can not control the fan state via ACPI. Another thing I'd like to know is if the fan works well in Windows, but unfortunately, it's not available on this laptop. I suggest to close this bug because we can not do anything from ACPI.
If we cannot control the fan via ACPI, can we control it elsewhere in the kernel? If not, would you be interested in drawing up a formal letter to Insyde (the BIOS manufacturer) and Toshiba?
(In reply to comment #21) > well, the fan is controlled by neither ACPI fan driver nor toshiba platform > driver. > IMO, this is not an ACPI bug because we can not control the fan state via > ACPI. > Another thing I'd like to know is if the fan works well in Windows, but > unfortunately, it's not available on this laptop. > I suggest to close this bug because we can not do anything from ACPI. If it's not controlled by ACPI, then why using acpi_os="Linux" makes such a difference. If nothing is controlled, why would acpi_os make a difference? I see no logic here to be honest.
Can the fan be controlled elsewhere in the kernel?
I agree with comment #23: something does not make sense here. Just for fun, I put my other HDD in and booted into Redmond Vista. Once there, the Fan was working beautifully: slow and steady switching upwards (not even to max spin speed) and downwards again. Here is what I found in the regedit: HKEY_LOCAL_MACHINE > System ControlSet001 Control > Class > [Some Numbers] > DriverDesc ACPI Fan Enum > ACPI > [Some Numbers] > DriverDesc ACPI Fan ControlSet002 Control > Class > [Some Numbers] > DriverDesc ACPI Fan Enum > ACPI > [Some Numbers] > DriverDesc ACPI Fan Current Control Set Control > Class > [Some Numbers] > DriverDesc ACPI Fan Enum > ACPI > [Some Numbers] > DriverDesc ACPI Fan Does the BIOS fool Vista into thinking we are running an ACPI controlled Fan, but cannot fool Linux?
Any updates on this? I'm currently on kernel 2.6.31.2 and noticed something about the fan behavior when i try to hibernate to disk. The fan starts and rotates usually (like before hibernating). I still don't get why suspend to ram makes so much difference. I can assume that when i hibernate and want to turn my laptop back on, i will go through the bios screen before the kernel loads and then loads the previous image. Maybe that's the reason for so much difference?