Most recent kernel where this bug did not occur: Distribution: OpenSuSE 10.1 Alpha1 ~ Alpha3 (current) Hardware Environment: FSC Amilo M3438G P-M750 (Dothan)/i915PM/Go6800-256MB Software Environment: Problem Description: fan is always running on low RPM and there's nothing in /proc/acpi/fan/ directory (should be at least FAN0/state subdir/file). Steps to reproduce: permanent condition
Please append output of dmesg and acpidump.
Created attachment 6705 [details] dmesg output
Created attachment 6706 [details] ACPI dump
No ACPI fan control available for this system.
Well, if so why it's always running? Under offtopic it starts/stops dynamically depending on load. Under Linux it runs despite of the fact that system is idle and CPU is in 800mhz (cpufreq_ondemand is used). Does this mean that FSC has buggy DSDT or BIOS or smth else?
Did you install any machine-specific drivers under "offtopic"?
> Did you install any machine-specific drivers under "offtopic"? No, not a single third-party driver/tool. Linux ACPI support for this piece of hardware is a bit odd. When I try to use built-in synaptics touchpad, AC/battery status starts toggling between 'online->online batt discharged->offline batt full->offline batt discharged'. Below follows bunch of messages I get in /var/log/messages: Dec 1 22:28:21 barracuda kernel: ACPI-0412: *** Error: Handler for [EmbeddedControl] returned AE_TIME Dec 1 22:28:21 barracuda kernel: ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BST] (Node dffb9220), AE_TIME Dec 1 22:30:49 barracuda kernel: ACPI-0412: *** Error: Handler for [EmbeddedControl] returned AE_TIME Dec 1 22:30:49 barracuda kernel: ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BST] (Node dffb9220), AE_TIME Dec 1 22:33:25 barracuda kernel: ACPI-0412: *** Error: Handler for [EmbeddedControl] returned AE_TIME Dec 1 22:33:25 barracuda kernel: ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BST] (Node dffb9220), AE_TIME Dec 1 22:33:56 barracuda kpilotDaemon: resmgr: communication failure: Broken pipe Dec 1 22:34:49 barracuda kernel: ACPI-0412: *** Error: Handler for [EmbeddedControl] returned AE_TIME Dec 1 22:34:49 barracuda kernel: ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BST] (Node dffb9220), AE_TIME Dec 1 22:34:52 barracuda kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost synchronization, throwing 3 bytes away. Dec 1 22:34:52 barracuda kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 Dec 1 22:34:52 barracuda kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 Dec 1 22:34:52 barracuda kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 Dec 1 22:34:52 barracuda kernel: psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. Dec 1 22:34:53 barracuda kernel: ACPI-0412: *** Error: Handler for [EmbeddedControl] returned AE_TIME Dec 1 22:34:53 barracuda kernel: ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.BAT0._BST] (Node dffb9220), AE_TIME Mouse itself works as expected (pointer moves, clicks are recognized by X11/KDE). Because of this buggy behaviour I had to get USB mouse and swith off built-in touchpad (there's touchpad toggle button just above the pad).
> Well, if so why it's always running? Under offtopic it starts/stops dynamically > depending on load. Under Linux it runs despite of the fact that system is idle In ACPI the thermal control w/fan is carried out through the methods defined under _TZ scope. In your case only _TMP (i.e. temperature getting) and _CRT (i.e. critical trip point) methods are defined. Also, there are no devices with fan HID ("PNP0C0B") defined in your DSDT. ACPI doesn't assume another fan handling methods. > Linux ACPI support for this piece of > hardware is a bit odd Please, try to boot with ec_burst=1
I'll try this kernel option and post results here later, thanks for advice. Regarding fan control - what do you think is the problem? Is it faulty BIOS or something else? If BIOS is under question then why fan is ON but not OFF by default? I've updated BIOS to the latest available on FSC site - 1.06RC. Should I file bug report to FSC? It's really dissapointing - running fan generates noise (it's almost silent, but still) and collects dust...
> Regarding fan control - what do you think is the problem? Is it faulty BIOS or > something else? If BIOS is under question then why fan is ON but not OFF by > default? I've updated BIOS to the latest available on FSC site - 1.06RC. Should > I file bug report to FSC? It's really dissapointing - running fan generates > noise (it's almost silent, but still) and collects dust... 1. There is chipset driver for XP on FSC site - it could be the reason. 2. You could try to rebuild the kernel with ACPI disabled, APM enabled, and see if the fan behavior will change. 3. It is more safe to have the fan always on, because it can cool the system.
> 1. There is chipset driver for XP on FSC site - it could be the reason. I checked XP devices in device manager - all ACPI- or motherboard-related drivers are provided by Microsoft... I don't beleive FSC mangled them. > 2. You could try to rebuild the kernel with ACPI disabled, APM enabled, and > see if the fan behavior will change. acpi=off makes no changes, as well as acpi=off in junction with apm=off (both power subsystems disabled). > 3. It is more safe to have the fan always on, because it can cool the system. Well, it's arguable - constantly running fan drains battery faster, gets dust quicker and lowers lifetime. Not to mention noise... What else can I try to make fan work as expected? Maybe DSDT recompile into kernel? Please advise.
ec_burst=1 seems to solve the touchpad bug - now built-in mouse is useable. Thanks for hint :)
The fan on this system has nothing to do with ACPI, either under Linux or under Windows. > There is chipset driver for XP on FSC site This is probably why there is fan control on Windows. Again, it has nothing to do with ACPI. If FSC supplied a platform specific driver for XP, it is their decision to supply one or not for Linux. Sometimes the community writes platform specific drivers as well, with or without support from the platform vendor. > ec_burst=1 This will be the default in in the next mm-patch, and should be the default in 2.6.16. Note that it is re-named to be ec_intr=1 going forward. So what is left is that you'd like fan control on this platform under Linux. This is a valid request. Really it should be made to FSC. In any case, I'm moving this report out of the ACPI category and into Platform Specific.
Dear Len, thanks for your reply. I will open TT with FSC.
I have the same problem on my m3438. More over, few time ago I'm having problem also in windows XP.
This is meant to be handled by ACPI or better a driver docked to ACPI... Please grep the DSDT for SetSilentMode. It is embedded in this device: Device (AMW0){ Name (_HID, EisaId ("PNP0C14")) ... Name (_WDG, Buffer (0x50) ... } Please have a look at this: http://www.microsoft.com/whdc/system/pnppwr/wmi/wmi-acpi.mspx and grep for AMW, _WDG, PNP0C14, ... I see this the first time, even the site says: Updated: December 4, 2001... I am still reading this, has it ever been discussed to copy the WMI functionality into some kind of a kernel module?
Do I understand right, and this will require one more interpreter, now for even not specified MOF files, which we should recover from _other_ OS installation?
I have this computer too, and the same problem with the fan. I'm not understanding all of the above, but should I take it that there is no solution today? Is someone talking to FSC about it, or are there any other plans regarding this? Just curious, could use any extra battery time as it is kinda low on these computers as it is. I'm running Ubuntu Dapper with a 2.6.15 kernel at the moment and would be happy to provide any test data if that would help (but it seems you already know what is going on).
I tried to contact FSC with this issue but no luck since fan works as expected under windows. Unfortunately FSC does not support linux officially. Is there any progress on this bug? Thomas, I hardly get your comment - did you mean this bug can be resolved somehow? FYI: this laptop has "Silent mode" button. If pressed, it turns blue fan LCD and should slow down CPU and GPU frequencies according to docs. There's no any visible impact under linux though.
There is one real write in all this WMI stuff to EC that probably influences fan activity in some way. I believe that if SilentMode Button is pressed, Windows catches it and makes use of these strange WMI methods. It even seems as if fan is controlled inside WMI, maybe it gets information how to do it from ACPI (these encrypted byte streams?), no idea. A module to access EC with experimental flag as it is done in the acpi_ibm module could help to find a workaround for you...
I have the same problem witm F-S Amilo M1439G. The problem remain with Suse 10.1 beta 9. There is a solution?!? :(
> I believe that if SilentMode Button is pressed, Windows catches it and makes use of these strange WMI methods. FYI, I'm using vanilla 2.15 and when I press the silent button, CPU frequency switches from and to "lower frequency" / "user set frequency" as expected.
Created attachment 7891 [details] DSDT from CyberLink's InstantOn (linux 2.6.7) This laptop comes with InstantOn preinstalled. This software is actually stripped down linux 2.6.7 with custom app running on top of X11. The thing is, that fan behaves as it should when running InstantOn. It starts and stops when not needed anymore, just like in windows. This is copy os DSDT from InstantOn booted.
Just in case that helps, the InstantOn sources are available at least in part as per the GPL and can be downloaded from here: http://www.cyberlink.com/english/products/powercinema/pcm-linux/pcmlinuxgpl.jsp
I have tried out the InstantOn dsdt on my Amilo M3438G (added it into initrd) and my laptop hung after I rebooted the system. With switching acpi support off I was able to boot again and changed the dsdt file with a file, I extracted from the bios of the machine and booting with acpi works again. I also recognized that PowerCinema Instant On does not have the fan problems. My question is how the dsdt from Power Cinema InstantOn was obtained? I have analyzed the PowerCinema system installed on Amilo M3438G for myself and found out, that its file initrd.gz does not contain a dsdt file. The supplied dsdt file only differs from the one in the bios in some lines (I have attached a diff file) but these lines cause the Amilo to hang while starting up. I am not really sure, whether the following notes will help to solve the problem, but perhaps they contain some interesting facts: 1. The acpid config directory of Power Cinema's Instant On only contain one entry for the power button. 2. Instant On comes with a lot of kernel modules for acpi like battery, thermal and fan whereas only battery is loaded in the startup script "run" that is contained in the file "image" that is in turn mounted as /dev/loop0 from the script "rclinux" that is contained in "initrd.gz" that is loaded by a modified grub (installed by ion_install.exe). 3. I was not able to find out why the program "run" and not "init" will be started by the kernel (a busybox init program is present, but no inittabs or a rc.d directory). So I have to assume that the kernel was also modified to boot "run" and not "init". 4. I have grepped all contained programs of Instant On (mostly python scripts) for calls to load acpi modules or call some of the appropriate scripts in scripts but could not find any occurences. The next consequent step would be to change the "run" script in order to get a shell and list the loaded modules but unfortunately, I do not have alot of time. 5. When I start my Amilo with SuSE 10.0, the fan stays silent for about thirty seconds and then increases to full speed. The delay is always the same. Perhaps a kernel thread that ios not started by InstantOn is causing too much load so that the fan is always on? 6. The slow down button on the Amilo also works correctly under SuSE 10.0, even the blue light goes on. 7. I have told Power Cinema about the fan problem, but they only answered, that they only sell the codecs and the linux port was made by third party vendors. 8. Last thought: I do not know for 100 percent, if the noise is coming from the fan of the processor or the fan of the nvidia graphic card.
Created attachment 8032 [details] diff from original dsdt and instant on dsdt As you can see, the two dsdt files only differ in some lines. To my mind, they have nothing to do with the fan. The instant on dsdt causes my Amilo M3438G to crash.
The Power Cinema Instant On on my Amilo M 3438G has a kernel with version 2.6.6 that was part of the official Fujitsu Siemens CDs.
This notebook has only one fan that treats both CPU and GPU - I looked under the bonnet :). Seems that some kernel thread loads CPU, I tried with no modules loaded, no framebuffer, no syslog/cron/others, just init=/bin/bash. This is output of 'w' command in idle system: alex@barracuda:~> w 18:11:01 up 2 days, 10:59, 3 users, load average: 0,28, 0,83, 0,99 For instance my PIII tualatin 1.2GHz system running Fedora Core 4 load avg is 0,00 0,00 0,00 while system is idle within runlevel 5 (X11/other daemons).
Only one fan seems strange to me. There are lots of forum entries how the gpu fan can be controlled under Windows.
Hi guys, I've the same problem on the same laptop. The fan noise increase after 30seconds, at the login's prompt. I've tried to fix my DSDT and i've succeeded to remove warning message during compilation but this hasn't solved the problem.. I'd read all over the internet and a lot of people have the same problem but no one founded a solution.. Has anyone fixed this problem here?
> PNP0C14 If soembody chooses to implement the Windows Management Interface on Linux and there is an ACPI bug that prevents it, then this is the place to file it. But lack of WMI support on Linux is not an Linux ACPI bug.
This problem will be solved quickly or we must continue using windows ? :/ There is any progress ? thanks.
I think it depends on gpu drivers. I found it when i installed in XP different nvidia drivers than from fsc dvd. With nvidia drivers with fan control option fan is only on when cpu temperature goes over 50'C. But without this option it works all the time so you can't hear big deference when cpu fan is on or off :).