Bug 57051 - CPU fan runs at maximum speed most of the time on Dell Inspiron 7520
Summary: CPU fan runs at maximum speed most of the time on Dell Inspiron 7520
Status: CLOSED WILL_NOT_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Fan (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Aaron Lu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-24 06:16 UTC by Sergio Durigan Junior
Modified: 2013-07-22 05:43 UTC (History)
2 users (show)

See Also:
Kernel Version: kernel-3.4.5-2.fc17.x86_64
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump output (242.27 KB, text/plain)
2013-04-24 10:40 UTC, Sergio Durigan Junior
Details
dmesg output (106.77 KB, text/plain)
2013-04-24 10:41 UTC, Sergio Durigan Junior
Details

Description Sergio Durigan Junior 2013-04-24 06:16:58 UTC
Hi,

This bug is actually a replication of:

<https://bugzilla.redhat.com/show_bug.cgi?id=842179>

There is a lot of information there, so I would kindly ask for you to read the description first.  I have also found a similar bug in the Kernel Bugzilla, which is bug #42605.  Not sure if it is the same, though.

I unfortunately haven't had the time to test with a pristine kernel, and I am using Fedora 17 now (kernel version kernel-3.8.3-103.fc17.x86_64), but the problem still persists and is exactly the same as described in the Fedora bug posted above.  I will try to test the mainline kernel ASAP.

I would like some instructions on how to proceed on the debugging of this issue.  Please let me know what I can do to help solving this really annoying issue.  Thanks a lot.
Comment 1 Aaron Lu 2013-04-24 06:40:28 UTC
Hi Sergio,

Please attach acpidump and dmesg output:
# acpidump > acpidump.out
# dmesg > dmesg.out

And is there a known working kernel?
Thanks.
Comment 2 Sergio Durigan Junior 2013-04-24 10:40:11 UTC
Created attachment 99891 [details]
acpidump output

This is the output of "acpidump".  Please notice that "i8kmon" is running, so the module "i8k" is loaded.
Comment 3 Sergio Durigan Junior 2013-04-24 10:41:13 UTC
Created attachment 99901 [details]
dmesg output

This is the output of "dmesg".  Same comments apply.
Comment 4 Sergio Durigan Junior 2013-04-24 10:43:19 UTC
(In reply to comment #1)
> And is there a known working kernel?
> Thanks.

Hi Aaron,

Thanks for the reply.  No, there no known working kernel, at least AFAIK.  I have tested only 3 or 4 kernel versions, as stated in the Fedora bug.
Comment 5 Sergio Durigan Junior 2013-05-10 04:44:01 UTC
Hi there,

Any news about this bug?  FWIW, I have just updated to kernel 3.8.11-100.fc17.x86_64 and the problem still persists.  Please let me know if there is something else I can provide to help you investigate this bug.

Thanks a lot for taking a look into this issue!
Comment 6 Aaron Lu 2013-06-21 05:59:25 UTC
Sorry for the long delay...I forgot this bug.

From the acpidump, the FAN control interface provided by ACPI firmware is fake:

        PowerResource (FN01, 0x00, 0x0000)
        {
            Method (_STA, 0, Serialized)  // _STA: Status
            {
                Return (VFN1)
            }

            Method (_ON, 0, Serialized)  // _ON_: Power On
            {
                Store (One, VFN1)
            }

            Method (_OFF, 0, Serialized)  // _OFF: Power Off
            {
                Store (Zero, VFN1)
            }
        }

And VFN1 is just a variable in memory space:

    OperationRegion (GNVS, SystemMemory, 0x9AFBEA18, 0x00000203)
    Field (GNVS, AnyAcc, Lock, Preserve)
    {
        OSYS,   16, 
        ....
        Offset (0xED), 
        GPIC,   8, 
        CTYP,   8, 
        L01C,   8, 
        VFN0,   8, 
        VFN1,   8, 
        VFN2,   8, 
        VFN3,   8, 
        VFN4,   8, 
        ....
    }
 
There is nothing we can do in Linux about this. Can you please check if there is some BIOS setting to select how FAN is controlled? Or you may check if there is BIOS update from your vendor's site.
Comment 7 Sergio Durigan Junior 2013-06-23 07:12:46 UTC
Hello Aaron,

Thanks for the reply.

Oh, gosh.  I was really concerned that this might turn out to be the vendor's fault.  I had already tried to find a BIOS setting to control the FAN, but obviously found nothing.  And last time I checked, there wasn't a BIOS update (but that was last year).

Anyway, I'm afraid that if there is a BIOS update now, and if I update it, I will end up having those UEFI/Secure Boot crap.  But I will take a look anyway, maybe Dell suddenly decided to fix this issue.

Thanks a lot.
Comment 8 Sergio Durigan Junior 2013-06-23 17:25:30 UTC
FWIW, I have updated my BIOS (I was using version A02, updated to the latest version A09, from February/2013), but unfortunately the FAN is still crazy.  I don't know if there is something else I could do in this case, or if there is some kind of "user feedback" that I could give to Dell that would make them fix this issue.
Comment 9 Zhang Rui 2013-06-24 02:57:57 UTC
1. please build a clean upstream kernel
2. check /sys/class/thermal/cooling_deviceX/type file to see which is the fan
3. echo {1,0} > /sys/class/thermal/cooling_deviceX/cur_state for the fan devices and see if this can change the fan state.
If no, this means that maybe the fan can be controlled by software, but it is NOT ACPI. It may be either a BIOS problem or we are missing some vendor support in Linux kernel.
Comment 10 Sergio Durigan Junior 2013-06-28 19:14:57 UTC
(In reply to comment #9)
> 1. please build a clean upstream kernel

I built 3.10-rc7, the latest mainline as of today.

> 2. check /sys/class/thermal/cooling_deviceX/type file to see which is the fan

I have 8 entries for Processor and 2 for LCD:

# cat /sys/class/thermal/cooling_device*/cur_state 
0
0
0
0
0
0
0
0
0
0

> 3. echo {1,0} > /sys/class/thermal/cooling_deviceX/cur_state for the fan
> devices and see if this can change the fan state.

I changed the cur_state of all entries, many times, but nothing happened.

> If no, this means that maybe the fan can be controlled by software, but it is
> NOT ACPI. It may be either a BIOS problem or we are missing some vendor
> support
> in Linux kernel.

The fan can be controlled by software (i.e., i8kutils, as I posted in the description of the bug).  But this software unfortunately does not offer many possibilities of control, and is definitely not as good as what the kernel/ACPI/whatever could do.

As described in my last comments, I updated the BIOS to the latest available version by Dell (version A09), but that did not solve the problem either.

So, according to your comment, it is Dell's fault, right?  Is there anything I/we/you can do to fix it, or do we depend on Dell to make things work?

Thanks.
Comment 11 Aaron Lu 2013-07-05 01:02:34 UTC
(In reply to Sergio Durigan Junior from comment #10)
> (In reply to comment #9)
> > 2. check /sys/class/thermal/cooling_deviceX/type file to see which is the
> fan
> 
> I have 8 entries for Processor and 2 for LCD:
> 
> # cat /sys/class/thermal/cooling_device*/cur_state 
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0

I think there is something wrong. Though I wouldn't expect the FAN device to work, but it should at least appear as a cooling device here. But from the dump here, it shows no FAN type cooling device exists...

> 
> > 3. echo {1,0} > /sys/class/thermal/cooling_deviceX/cur_state for the fan
> > devices and see if this can change the fan state.
> 
> I changed the cur_state of all entries, many times, but nothing happened.

The above echo command is meant for you to test a FAN type cooling device, since there is no FAN type cooling device, it doesn't make sense to issue the command.

> 
> > If no, this means that maybe the fan can be controlled by software, but it
> is
> > NOT ACPI. It may be either a BIOS problem or we are missing some vendor
> support
> > in Linux kernel.
> 
> The fan can be controlled by software (i.e., i8kutils, as I posted in the
> description of the bug).  But this software unfortunately does not offer
> many possibilities of control, and is definitely not as good as what the
> kernel/ACPI/whatever could do.

I suppose it doesn't use ACPI to control the FAN.

> 
> As described in my last comments, I updated the BIOS to the latest available
> version by Dell (version A09), but that did not solve the problem either.

Looks like Dell does not intend to support FAN control through ACPI.

> 
> So, according to your comment, it is Dell's fault, right?  Is there anything
> I/we/you can do to fix it, or do we depend on Dell to make things work?

There is very little we can do in ACPI's regard(except to find out why no FAN type cooling device gets created but then, due to the fake empty FAN control method, it wouldn't work), but there may be other software ways to control the FAN that I have no idea of.
Comment 12 Sergio Durigan Junior 2013-07-15 18:51:51 UTC
(In reply to Aaron Lu from comment #11)
> (In reply to Sergio Durigan Junior from comment #10)

> > > If no, this means that maybe the fan can be controlled by software, but
> it is
> > > NOT ACPI. It may be either a BIOS problem or we are missing some vendor
> support
> > > in Linux kernel.
> > 
> > The fan can be controlled by software (i.e., i8kutils, as I posted in the
> > description of the bug).  But this software unfortunately does not offer
> > many possibilities of control, and is definitely not as good as what the
> > kernel/ACPI/whatever could do.
> 
> I suppose it doesn't use ACPI to control the FAN.

As far as I have seen, no, it doesn't.  The code for i8kutils is here: <http://ftp.de.debian.org/debian/pool/main/i/i8kutils/i8kutils_1.33.tar.gz>, in case you want to take a look at how it does things.

> > As described in my last comments, I updated the BIOS to the latest
> available
> > version by Dell (version A09), but that did not solve the problem either.
> 
> Looks like Dell does not intend to support FAN control through ACPI.

Yes, the question is if/how they intend to support it.

> > So, according to your comment, it is Dell's fault, right?  Is there
> anything
> > I/we/you can do to fix it, or do we depend on Dell to make things work?
> 
> There is very little we can do in ACPI's regard(except to find out why no
> FAN type cooling device gets created but then, due to the fake empty FAN
> control method, it wouldn't work), but there may be other software ways to
> control the FAN that I have no idea of.

Well, I filed this bug against ACPI because that was my best guess when I tried to determine where this issue belonged to.

OK, so if I get this conversation, I basically have two choices: (a) contact Dell and ask them to fix it (highly unlikely event, by the way), or (b) figure out a way of doing a fine-grained control of the FAN via software.

BTW, I think it's worth mentioning that when I updated to Linux 3.9.8 the temperature of the machine (idle) increased a lot, and I still don't know why.

Thanks for the feedback.
Comment 13 Aaron Lu 2013-07-22 05:43:39 UTC
I just take a little look at i8k, it makes use of SMM mode code provided by BIOS to do the FAN control thing, not related to ACPI. SMM mode is a special CPU mode run without OS' awareness, so as long as CPU is transferred to SMM mode, OS has no control.

So Dell is using SMM code to do the FAN control instead of ACPI. Try to play with i8kutils to see if you can get FAN works well, I don't see anything we can do in ACPI's regard.

Note You need to log in before you can comment on or make changes to this bug.