laptop fans doesn't work sometimes

Bug #72775 reported by David Rando
22
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Undecided
Unassigned
linux-source-2.6.17 (Ubuntu)
Fix Released
High
Unassigned

Bug Description

Binary package hint: linux-image-2.6.17-10-386

Hello.

I have a Fujitsu l1310g based on ati IXP chipset with radeon Xpress 200M

Recently discussed on the forum, some of us (and looks like more and more with different types of notebooks) are having this problem.

Sometimes when you boot the laptop, after the splash screen appears, the laptop fan stops. When it works, works like it should be, not always on (going much better than dapper). But sometimes doesn't work at all, and the laptop overheat.

I've been unable to see anything weird at the logs, dmesg and stuff, and at /proc, the fan part, it reports that the fans are on (the two that comes with the laptop).

Booting with 2.6.15, the fans works like it were on dapper, always on.

If I boot on windows when i have the fan stopped, and then boot on edgy, the fan works again.

When the laptop is overheated, i have to wait to cool it down, to try to boot again with edgy, because if i don't do that, every other boot resolves in a non-working fan.

This problem seems related to the psmouse module:
@See [ACPI problems and solution] http://www.wolframschenck.de/nx6325.htm

The ACPI problem is threefold:
(1) The psmouse module is compiled directly into the kernel. This causes rebooting into a "bad state". If Linux is directly started after a reboot or shutdown from Linux, ACPI freaks completely out including the read-out of the battery status.
(2) The DSDT table of the bios seems to be broken regarding the methods of turning the CPU fan on.
(3) ACPI events are not processed properly in the kernel.

Tags: cft-2.6.27
Revision history for this message
David Rando (david-rando) wrote :

Sorry i've attached the bug to a bad package. I figure it affects everything, but the bug is related to the linux-image-2.6.17-10 and not the source.

(I didn't try the source directly).

Sorry.

Revision history for this message
Ben Collins (ben-collins) wrote :

You assigned it to the correct package, since the source is where the bug is :)

Anyway, please attach (do not paste into comments) the output of dmesg. Also, perform this command:

tar zcf acpi.tgz /proc/acpi

Attach acpi.tgz as well. Thanks.

Changed in linux-source-2.6.17:
importance: Undecided → High
status: Unconfirmed → Needs Info
Revision history for this message
David Rando (david-rando) wrote :
Revision history for this message
David Rando (david-rando) wrote :

Here are both, dmesg and acpi as you requested

I've noticed after creating the dmesg output, that first line says: Linux version 2.6.15-25-386 (buildd@terranova) (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5))

but my uname -r reports 2.6.17-10-386 (i've also tried 2.6.17-10-generic).

The laptop comes with a intel celeron 1.6 processor.

Hope it helps.

Thanks for the reply.

Revision history for this message
Ben Collins (ben-collins) wrote :

You need to recheck some things. There's no way for dmesg to show 2.6.15, while uname shows 2.6.17. It's an impossibility.

So I need you to verify the kernel where you are experiencing this issue, thanks.

Revision history for this message
Eversmann (eversmann) wrote :

Ok, i'm going to deinstall 2.6.15 kernel and reinstall 2.6.17 and see what happens.

I'll report here my test.

thanks.

Revision history for this message
Eversmann (eversmann) wrote :

Sorry Ben, i've appended a wront dmesg message, looks like i had an existing dmesg.txt and when i did sudo dmesg >> dmesg.txt the result got added at the last of the file.

Here i've attached the correct dmesg. Was a weird issue having two different kernels versions reported, wasn't it? :-P

Thanks.

Revision history for this message
David Rando (david-rando) wrote :

Isn't the information enough? needs more info?

Changed in linux-source-2.6.17:
status: Needs Info → Confirmed
Revision history for this message
David Rando (david-rando) wrote :

OK, I think i found the bug. After giving up lots of time, and thinking about acpi and the way the laptops bios works, i went and read everything about acpi and linux.

at the place: /proc/acpi/thermal_zone/THRM i can see everything about the cooling state and settings for the laptop. The trip points are ok and are telling at which states of temperature the fan should start working.

But after looking to the wrong files long time, I stopped at "polling_frequency". So I thought that file controls the time that bios take to ask the state of the temperature and compare it with the trip_points that we set on the file.
When i looked at the file it said: "polling disabled".

So i said: "let's try with 5 seconds of polling" and put

sudo echo -n "5" ./polling_frequency.

And just when the laptop reached one of the temperatures on the trip_point file and fan started!! and works as it should (now i have to find the correct number of seconds to poll for the fan not disturb).

So looks like it's the problem about current kernel and leptop overheat: polling disabled.

Hope it helps, i'll update my wiki page and post on the forum for the rest of the community.

Revision history for this message
David Rando (david-rando) wrote :

Ok more test done. Looks like bios controls the fan somehow when the laptop boots on ubuntu. So what i'm doing right now is see if the fan works when using the notebook. If I see cpu temperature is at 60º or above, i tweak the pollinq_frequency file and make the fan start to work.

Don't know what can cause this bug that wasn't on 2.6.15, but at least it's a workaround.

emilmont (emilmont)
description: updated
Revision history for this message
David Rando (david-rando) wrote :

The above command to enable the polling_frequency is:
sudo echo -n "5" > /proc/acpi/thermal_zone/THRM/polling_frequency

sorry for the mistype.

Regarding the above change of the description, if it's related to psmouse module, looks like we'll have to patch the current ubuntu kernel with the information provided in the link, or wait and see how the new version (feist) goes.

Going to download the latest release and see how with that new kernel the laptop goes.

I'll keep this thread updated.

Revision history for this message
Brian Murray (brian-murray) wrote :

I am assigning this bug to the 'ubuntu-kernel-team' per their bug policy. For future reference you can learn more about their bug policy at https://wiki.ubuntu.com/KernelTeamBugPolicies .

Changed in linux-source-2.6.17:
assignee: nobody → ubuntu-kernel-team
milestone: edgy-updates → none
Revision history for this message
Zamiere Vonthokikkeiin (kikkeartworx) wrote :
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Hardy Heron Alpha series was recently released which contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ .

Also, we'll keep this report open against the actively developed kernel bug against 2.6.17 this will be closed. Thanks.

Changed in linux:
status: New → Incomplete
Changed in linux-source-2.6.17:
status: Confirmed → Won't Fix
Revision history for this message
klorofloristi (valtteri-makela) wrote :

Hello,

I also have fujitsu-siemens Amilo L 1310g, and I can confirm that the bug still exists with hardy with latest updates. I installed the beta from regular installation cd and ran dist-upgrade last night. 7.10 kept the fan running at all times.

The fan seems to stop at startup, while the init scripts/services are running/starting up. However it isn't any distinct moment in the boot process, and at least once it stopped after few minutes of use (this might be before updates). If the fan remains on, it seems to remain on indefinetly: last night the machine was on capturing dv-video. Acpi -t reports rising temperature, and /proc/acpi thinks that the fan is still on.

I have been trying to find if there is any logic in this behavior, but the stopping seems pretty random. However, it seems that every time the machine is unused (=cold) the fan stops. After 15mins of usage the cpu is 70C or so, and after restart the fan stays on. So maybe it stays on, if the initial temp is over some trip point?

I can provide dumps from /proc or anything else useful, or if you have any ideas/kernels/patches to test :)

cheers,

Valtteri

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi klorofloristi,

Care to attach your dmesg output for the latest Hardy kernel available? Also if you could attach a tarball of /proc/acpi that may also be helpful. The following wiki may also be of interest to you - https://wiki.ubuntu.com/DebuggingACPI .

If you are comfortable building the upstream vanilla kernel, you may want to test that out as well to verify this doesn't also exist upstream. The following wiki can help with building/booting the upstream kernel - https://wiki.ubuntu.com/KernelTeam/GitKernelBuild . Thanks.

Revision history for this message
klorofloristi (valtteri-makela) wrote :

Hi,

I upgraded all packages yesterday morning, and the bug still existed with 2.6.24-16 kernel. I also builded upstream kernel with instructions from the wiki (thanks for those informative links!), and confirmed the bug in 2.6.25-rc9.

Also I tried running different boot parameters from the Debugging ACPI -wiki entry, and the fan seemed to work with all off them. However, I kept the machine running just for few minutes each time, and as the bug doesn't manifest itself every time, it's hard to confirm that it would really work every time. Two of those (pnpacpi=off and noapic) leave the ethernet working, so I hoped that these could be acceptable workarounds. However later I tried with "pnpacpi=off", and it manifested the bug also. This happened on a cold machine, so it really seems that the fan is likely to stop if the machine is not "hot enough". When it was cold, kernel without parameters also exhibited the problem (as expected).

So only way to be sure that the fan works, is to use "acpi=off", which disables ethernet, battery/temperature info and automatic power off :(

Here are acpi tarball from latest kernel as you requested , uname -a:

Linux nollatoleranssi 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

Revision history for this message
klorofloristi (valtteri-makela) wrote :

and dmesg

Revision history for this message
klorofloristi (valtteri-makela) wrote :

and dmidecode

Revision history for this message
Eric Peterson (eric-peterson-mail) wrote :

I've tried this one http://forums.gentoo.org/viewtopic.php?t=122145 and haven't got any effects.
I've tried kernel 2.6.25 too.
Fan does'nt work at all.
Hardy doesn't like Amilo l1310g :-(

Revision history for this message
David Rando (david-rando) wrote :

Well, lucks like the damn ati chipset that comes with this laptop has a very big bug in the acpi that populates some versions on ubuntu. I would like to know what to disable in the kernel to just do it from source and compile it.

Is this bug or similar already filled for 2.6.25 on hardy? we should continue this thread there.

Revision history for this message
David Rando (david-rando) wrote :

Well, i've jumped into the pool and upgraded laptop to hardy. I can confirm the problem is there. I've dissassembled the DSDT table, fixed a little warning, updated using initramfs booting with acpi_os_name="Microsoft Windows XP"....... the fan works from the start and after a period, it stops.

Searching on the new, looks like it's being discussed on the acpi-devel mailing list, and it has a bug or something like that. No events on dmesg, no nothing.

Also, actually, i can't write on the trip_points file anymore, like i did on feisty.

I really really hope we can catch this bug. Some other people with different laptops have it.

Revision history for this message
Eric Peterson (eric-peterson-mail) wrote :

Very often I read that the Amilo L1310g has a buggy DSDT.
I tried this one http://acpi.sourceforge.net/dsdt/view.php?manufacturer=Fujitsu+Siemens&name=Amilo+L1310G
But fan still doesn't work. :-(
May it is buggy too?
Has anybody enough skills to check/fix this table?

Revision history for this message
David Rando (david-rando) wrote :

Already tried that on my own and doesn't work. And the _WAK is just a warning. Debugging the dsdt just gives the _WAK warning and no errors.
Would be great if someone with acpi programming skills can take a look at the dsdt.dsl file and see if it can be tweaked / fixed.

I've attached it to this post.

Thanks.

Revision history for this message
Eric Peterson (eric-peterson-mail) wrote :

Attached seems fixed, but fans still keep silence :-(

Revision history for this message
akamuza (akamuza) wrote :

exactly the same problem: randomly stops after some time.
using Ubuntu 8.04

laptop: Fujitsu Amilo L1310G

Revision history for this message
David Rando (david-rando) wrote :

Well, searching and searching for a solution I missed the main place to search: kernel list. And this was reported on 2005.

http://bugzilla.kernel.org/show_bug.cgi?id=5289

Quoting from there:
The issue is that ACPI first tries to read device power state from _PSC method,
if this is unsuccessful, it evaluates device state from the power resources,
defined for this device. In your DSDT the _PSC is defined with 0x00 value, and
never being updated later, so the device state is always reported ON.
With this patch the things should work as expected.

I have it running right now with the dsdt patched, and working great so far. Temperature is a bit higher but stable, and the fan are reported, at least, correctly.

I've attached the DSDT file that i'm actually running on. I'll confirm after a few days of work if this resolves the problem. Maybe it's a clue for some other people with other laptops having the same one.

Just be sure to put it on /etc/initramfs.... folder in uppercase (DSDT.aml) , use the update-initramfs option and use the acpi_no_auto_ssdt on kernel load, as described in the method to use custom dsdt files from the wiki.

Revision history for this message
David Rando (david-rando) wrote :

dsdl compiled (aml file)

Revision history for this message
David Rando (david-rando) wrote :

Fix posted in the thread.

Changed in linux-source-2.6.17:
status: Won't Fix → Fix Released
Revision history for this message
mindmachine (c-westermann) wrote : Problem is still there

Hello Eversmann,

I tried your solution with my L1310G but the problem still remains.
Is there any other action required besides this excellent explanation, you gave at the Ubuntu WIKI? Any changes in BIOS necessary (at the moment, the critical points, usb legacy support and this one bit thingy are disabled).

If you want me to provide some more documentation (log or file), just contact me.

Could anyone with or without success with the solution described here

https://wiki.ubuntu.com/LaptopTestingTeam/FujitsuAmiloL1310G

give a short comment about this?

Thanks
chris

Revision history for this message
David Rando (david-rando) wrote :

Be very sure to have the latest bios from fujitsu website (i guess it's 1.0F version). If it doesn't work, post your dmesg here to check if everything went ok including the dsdt file.

Changing those settings in the bios helps (i have them disabled) but i don't think it would make the problem better or worse.

Also, after boot, go to /proc/acpi/fan and check at FAN0 and FAN1 folder, the status file there, for the FAN0, at my very start, shows as off. If booting with laptop at cold state shows both FAN folders status as "on" something is going bad.

I thought about the file i posted here where an old version, but i remember that i uploaded the DSDT.aml from my /etc/initramfs folder that i'm currently using, so i'm pretty sure it's ok. But after checking your dmesg file, if it's everything ok, i'll double check the dsdt file and send you to your e-mail address.

Revision history for this message
klorofloristi (valtteri-makela) wrote :

Hi

I tried the dsdt fix yesterday with the instructions on the wiki, and it seems to work! very nice! I didn't quite understand does the fix disable the _PSC method (so the state is evaluated from the "power resources") or does it make it somehow update the state in _PSC. Either way, only problem I noticed is that the temperature reported (in /proc/acpi/..) jumps occasionally to about 10 degrees higher, so the fan sometimes starts for just few seconds. But that doesn't bother me, so I have a fully working linux amilo L1310G now, with upgraded memory and HD. Thank you!

I also tried the wlan module, so now the wlan led also works, or perhaps the antenna too, I didn't notice anything because the wlan box is just few meters away :)

- Valtteri

Revision history for this message
Eric Peterson (eric-peterson-mail) wrote :

It works for me too! Thanks!

Revision history for this message
mindmachine (c-westermann) wrote :

Now it works for me, too.
I simply tried it again and voila, no problems anymore.

Thanks for your support!!

mindmachine

Revision history for this message
Jui-Hao Chiang (windtracekimo) wrote :

Hi, everyone
Thank god finally I found a very solution here.
I am currently using Fujistu S7110 laptop, the cpu fan works very idle.
I have checked /proc/acpi/fan directory, there is nothing under it.
My bios is updated from the fujitsu-siemens to the latest version.
So, now I want to try this customed dsdt (but seems a difficult approach to me).
The attachment is the dsdt file I get from the current environment as the following
  cat /proc/acpi/dsdt > dsdt.dat
  iasl -d dsdt.dat (then the dsdt.dsl goes out as the file)
But I don't find any FAN area inside it, and also don't know how to change the _PSC that Eversmann has mentioned. (can I use the paramenters as the Eversmann's file?)
Hope someone who can help me on this.

Best wishes

Revision history for this message
David Rando (david-rando) wrote :

Hey Jui-Hao

Your dsdt file is far more complicated that mine. As a quick approach, could you try to boot with:

acpi_osi="!Linux" acpi_os_name="Windows 2006"

on your kernel boot line?

Let's see if this helps....

Revision history for this message
Jui-Hao Chiang (windtracekimo) wrote :

Thanks for your suggestion.
Now my boot options is as the following
kernel /boot/vmlinuz-2.6.24-16-generic root=UUID=3fd94c09-430d-4fa8-b1a2-e242bb7a9ba8 ro quiet splash pci=routeirq acpi_osi="!Linux" acpi_os_name="Windows 2006"
(the option pci=routeirq is added to remove the unknown PCI bug, but I don't know about the rest, such as "quiet" 'splash" by default)

I just open a little 3D game to run for 5 minutes, and the cpu temperatures keep between 46~52C.
Yesterday with the same game, it goes up to 73C
(but yesterday the indoor temperature is 10C higher than today)
So I will keep watching it for 1 day, and report to you later.

Many thanks for your quick response

Revision history for this message
Jui-Hao Chiang (windtracekimo) wrote :

Bad news, it's still not working.
I just tried another game (just want to test for higher cpu temperature).
As the temperature goes up to 70C, the fan still spins slow.
Also, the /proc/acpi/fan is still empty after these options.

Any idea?
(I know modifying dsdt is a terrible job).

Thanks

Revision history for this message
peter pan (clarcraft) wrote :

Hi!

Many thanks to Eversmann!!!
Great community support!
After following Evermans instructions (https://wiki.ubuntu.com/LaptopTestingTeam/FujitsuAmiloL1310G)
the fan works! Before that I had to start with acpi=off as boot option, which makes the fan work too,
but which has several disadvantages. But the Fan doesnt stop (so is always on) even with
Evermanns HowTo applied. But I think thats OK..
/proc/acpi/fan/FAN1/state switches to "off" at the critical Temp i think (50°C), but the fan doesnt switch off...
thanks again,

 - peter pan -

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
David Rando (david-rando) wrote :

I'm glad guys that my fix resolved your problem ;-)

I'll take a look at the new 2.6.27 kernel and i'll report a new bug if it's necessary.

Thanks for the information ;-)

Revision history for this message
chochem (chochem) wrote :

Yeah, thanks Evermann :)

One small problem, though: I seem to no longer be able to load the acpi-cpufreq module required to do cpu scaling on my non-celeron cpu... I know this is not relevant to the majority of l1310g users but do you have any idea as to why this is? Modprobing results in a no-such-device error (supposedly the device would be a scalable cpu).... I believe (though my memory might cheat me) that I was able to do cpu scaling with the sourceforge dsdt in place...

Revision history for this message
Neil Munro (neilmunro-deactivatedaccount) wrote :

Unfortunately this bug report is being closed because we received no response to the last inquiry for information. However, the Intrepid Ibex 8.10 Beta release was most recently announced - http://www.ubuntu.com/testing/intrepid/beta . If you are able to confirm this is still an issue with this most recent release please feel free to reopen this report. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks.

Revision history for this message
Neil Munro (neilmunro-deactivatedaccount) wrote :

This bug appears to be fixed, so this bug is being marked as fixed and is being closed, if the problem persists, please do feel free to open a new bug.

Changed in linux:
status: Incomplete → Fix Released
Revision history for this message
Artem (leipreachan) wrote :

Please hold on with closing this bug.
I've just installed the beta on my laptop (the brand name is Roverbook and the laptop is quite old ~3 years)
Fan stops running right after grub is loading. Sensor-applet shows 57C.
Since THE bug is fixed please tell me what should I provide to open a new bug?

/proc/acpi/fan is empty
linux-generic 2.6.27.6.7
amibios 02.57

thanks

Revision history for this message
klorofloristi (valtteri-makela) wrote :

Hi everyone,

I have been bit busy, so I didn't test the new kernel on time :( However I just installed xubuntu on another laptop and tried the live cd on the amilo also, and I can confirm, the bug still exists. This was xubuntu 8.10 RC1, with kernel 2.6.27-7-generic I believe.

It seems that the bug manifest itself every time the machine starts cold (=powered off more than one hour for example), so it's easy to duplicate/confirm. Should this bug be reopened or should we open a new one on intrepid?

Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.