Bug 1121331

Summary: Fan at full speed on Dell T1650
Product: [Fedora] Fedora Reporter: Lars E. Pettersson <lars>
Component: xorg-x11-drv-nouveauAssignee: Ben Skeggs <bskeggs>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 27CC: airlied, ajax, bskeggs, gansalmon, itamar, jonathan, jwboyer, kernel-maint, kpschrage, madhu.chinakonda, mchehab
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-11-30 18:17:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
kernel 3.14.9
none
kernel 3.15.3
none
kernel 3.15.4
none
Result of 'sensors' with kernel-3.15.6-200.fc20.x86_64, fan still at full speed.
none
Patch applied to various kernel sources
none
Quiet fan - NVE0 family - darktama none

Description Lars E. Pettersson 2014-07-19 10:46:57 UTC
Created attachment 919267 [details]
kernel 3.14.9

Description of problem:

As of update kernel-3.15.3-200.fc20.x86_64 the fan is on full speed on my Dell T1650 system

Version-Release number of selected component (if applicable):

Problem exist on:
kernel-3.15.3-200.fc20.x86_64
kernel-3.15.4-200.fc20.x86_64
kernel-3.15.5-200.fc20.x86_64

But not on
kernel-3.14.9-200.fc20.x86_64

How reproducible:
Every time

Steps to Reproduce:
If you start with kernel 3.15.3-200.fc20.x86_64, or above, the fan runs at full speed.

Expected results:
Fan function as it did with kernel-3.14.9-200.fc20.x86_64 and below

Additional info:
The sensors command show the nouveau-pci-0100 fan running at full speed, the nouveau package has not been updated since install at "Sat 21 Dec 2013 01:26:18 PM CET" (xorg-x11-drv-nouveau-1.0.9-2.fc20.x86_64) so could not be the culprit here.

I have not physically opened the case to see if all fans are affected. But according to the sensors command, at least the nouveau-pci-0100 fan is at full speed (or close to it).

I attach three files showing the output of sensors and uname -a

Comment 1 Lars E. Pettersson 2014-07-19 10:47:34 UTC
Created attachment 919268 [details]
kernel 3.15.3

Comment 2 Lars E. Pettersson 2014-07-19 10:48:04 UTC
Created attachment 919269 [details]
kernel 3.15.4

Comment 3 Lars E. Pettersson 2014-07-20 07:54:50 UTC
Created attachment 919330 [details]
Result of 'sensors' with kernel-3.15.6-200.fc20.x86_64, fan still at full speed.

Comment 4 Klaus-Peter Schrage 2014-07-24 10:34:18 UTC
I experienced something similar (cpu fan running at full speed right from system start).

Problem exists with:
kernel-3.15.5-200.fc20.x86_64
kernel-3.15.6-200.fc20.x86_64

No problem with:
kernel-3.14.8-200.fc20.x86_64

It's a desktop system with an Asus B85M-G board and an Intel i3-4330 CPU.

Comment 5 Klaus-Peter Schrage 2014-07-24 12:33:43 UTC
Correction: It is the GPU fan running at full speed.

Comment 6 Lars E. Pettersson 2014-07-24 18:15:16 UTC
F.Y.I. My video card:

01:00.0 VGA compatible controller: NVIDIA Corporation GF106GL [Quadro 2000] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: NVIDIA Corporation Device 084a
	Flags: bus master, fast devsel, latency 0, IRQ 45
	Memory at f4000000 (32-bit, non-prefetchable) [size=32M]
	Memory at e0000000 (64-bit, prefetchable) [size=128M]
	Memory at e8000000 (64-bit, prefetchable) [size=64M]
	I/O ports at e000 [size=128]
	Expansion ROM at f6000000 [disabled] [size=512K]
	Capabilities: [60] Power Management version 3
	Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [78] Express Endpoint, MSI 00
	Capabilities: [b4] Vendor Specific Information: Len=14 <?>
	Capabilities: [100] Virtual Channel
	Capabilities: [128] Power Budgeting <?>
	Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
	Kernel driver in use: nouveau
	Kernel modules: nouveau

Comment 7 Klaus-Peter Schrage 2014-07-25 07:13:15 UTC
FWIW, here's mine:

01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 630] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device 8a90
        Flags: bus master, fast devsel, latency 0, IRQ 43
        Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
        Memory at e8000000 (64-bit, prefetchable) [size=128M]
        Memory at f0000000 (64-bit, prefetchable) [size=32M]
        I/O ports at e000 [size=128]
        Expansion ROM at f7000000 [disabled] [size=512K]
        Capabilities: [60] Power Management version 3
        Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [78] Express Endpoint, MSI 00
        Capabilities: [b4] Vendor Specific Information: Len=14 <?>
        Capabilities: [100] Virtual Channel
        Capabilities: [128] Power Budgeting <?>
        Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
        Kernel driver in use: nouveau
        Kernel modules: nouveau

Comment 8 Klaus-Peter Schrage 2014-07-26 08:21:39 UTC
Following a suggestion, I reverted this kernel patch:
http://tinyurl.com/mz4vsr8
on kernel-3.15.6-200.fc20.src.rpm.
After installing the resulting kernel rpm and booting into it, the fan problem, at least for me, has gone.

BTW: Why has this problem been assigned to xorg-x11-drv-nouveau?

Comment 10 Klaus-Peter Schrage 2014-07-26 13:39:24 UTC
(In reply to Josh Boyer from comment #9)

Didn't know about that, thank you!

Comment 11 Klaus-Peter Schrage 2014-08-04 12:45:03 UTC
FWIW, the problem continues after recent kernel update to 3.15.7-200.fc20.x86_64.
Again, reversly applying the patch mentioned in Comment 8 to the kernel source rpm cures the problem.

Comment 12 Klaus-Peter Schrage 2014-10-12 16:44:23 UTC
Created attachment 946132 [details]
Patch applied to various kernel sources

Comment 13 Klaus-Peter Schrage 2014-10-12 16:52:18 UTC
Just to keep this issue alive, although the affected hardware (mine: GeForce GT 630) may be too obsolete:
With the latest update to kernel-3.16.4-200.fc20.x86_64, the GPU fan still runs at full speed. And again, applying the patch mentioned in Comment 8 to kernel-3.16.4-200.fc20.src.rpm, makes the fan behave more decently.

For your information, I have attached the patch in question in Comment 12.

Comment 14 Mo Sh 2014-10-19 01:25:16 UTC
Can you clarify how to apply the patch in comment 8 please.

Thanks

Comment 15 Klaus-Peter Schrage 2014-10-19 09:46:12 UTC
The patch cited in Comment 8 (you might call it "fanloud.patch") seems to be responsible for the problems with certain Fermi cards, so you have to reverse it to calm down the fan (with "patch -R ...").
Starting from there, you can create a patch to be applied to the kernel source rpm as described in http://fedoraproject.org/wiki/Building_a_custom_kernel.

You already find this patch ("quietfan.patch") as attachment 946132 [details]. As long as the nouveau driver in the kernel isn't changed, the following paragraphs from the wiki will result in a modified rpm of the Fedora kernel:

-"Get the Source"
-"Prepare the Kernel Source Tree"
(You can omit the next paragraph "Copy the Source Tree and Generate a Patch", because you already have quietfan.patch)
-"Configure Kernel Options": basically, I only execute "make oldconfig".
-"Prepare Build Files": basically, that means to edit the kernel.spec file to include quietfan.patch.
-"Build the New Kernel": I do this with the following command:
rpmbuild -bb --with baseonly --without debuginfo --target=`uname -m` kernel.spec

This sounds a bit complicated, and for me, it really is ... I'd be happy to find a more straightforward procedure (perhaps it might be sufficient just to rebuild the nouveau kernel module, I don't know).

Comment 16 Mo Sh 2014-10-19 12:32:32 UTC
That solved it for me. Thank you very much!

For anyone who is new to creating a custom kernel with a patch, the patch file needs to be placed within the source directory. Also, you will need to change the linux version within the patch file.

Wherever it says:
linux-3.15.7-200.fc20.x86_64/... that needs to change to linux-3.<version>.../...
kernel-3.15.fc20/... that needs to change to kernel-3.<version...>/...

you will also need to remove the .new and .old within those names

Comment 17 Klaus-Peter Schrage 2014-10-19 16:34:43 UTC
(In reply to Mo Sh from comment #16)
 
> Wherever it says:
> linux-3.15.7-200.fc20.x86_64/... that needs to change to
> linux-3.<version>.../...
> kernel-3.15.fc20/... that needs to change to kernel-3.<version...>/...
> 
> you will also need to remove the .new and .old within those names

For me the patch works without these alterations - I left it unchanged since several kernel builds. The patch mechanism seems to be smart enough to strip the absolute paths to the essential (look for the -p option in the patch command).

Comment 18 poma 2014-12-21 22:46:50 UTC
Created attachment 971822 [details]
Quiet fan - NVE0 family - darktama

Comment 19 poma 2014-12-21 22:54:00 UTC
Comment on attachment 971822 [details]
Quiet fan - NVE0 family - darktama

$ uname -r
3.17.6-200.fc20.x86_64
$ su -c 'yum install kernel-devel'
$ git clone -b linux-3.17 git://people.freedesktop.org/~darktama/nouveau
$ cd nouveau/
$ curl -s https://bugzilla.redhat.com/attachment.cgi?id=971822 | patch -p1
$ cd drm/
$ make
$ su
# cp nouveau.ko /lib/modules/$(uname -r)/updates/
# depmod
# modinfo nouveau -n
/lib/modules/3.17.6-200.fc20.x86_64/updates/nouveau.ko
# reboot

Comment 20 poma 2014-12-21 23:06:12 UTC
Comment on attachment 971822 [details]
Quiet fan - NVE0 family - darktama

Klaus-Peter asked @users, so here it is.

BTW Josh, if so far upstream hasn't been able to solve it, else if this patch is effective and doesn't break anything else in nouv, why not consider to park it downstream.

Comment 21 Lars E. Pettersson 2014-12-22 18:47:05 UTC
As discussed on the users list a re-build of initramfs is also needed:

(In reply to poma from comment #19)
> # depmod
> # modinfo nouveau -n
> /lib/modules/3.17.6-200.fc20.x86_64/updates/nouveau.ko

Rebuild initramfs and check that the new module is there:

# dracut --force
# lsinitrd /boot/initramfs-$(uname -r).img | grep nouv

> # reboot

Comment 22 poma 2014-12-22 21:09:48 UTC
(In reply to Lars E. Pettersson from comment #21)
> As discussed on the users list a re-build of initramfs is also needed:
> 
> (In reply to poma from comment #19)
> > # depmod
> > # modinfo nouveau -n
> > /lib/modules/3.17.6-200.fc20.x86_64/updates/nouveau.ko
> 
> Rebuild initramfs and check that the new module is there:
> 
> # dracut --force
> # lsinitrd /boot/initramfs-$(uname -r).img | grep nouv
> 
> > # reboot


- Create a custom dracut config
/etc/dracut.conf.d/exclude-nouveau-in-the-initramfs.conf
# PUT YOUR CONFIG IN files named *.conf in /etc/dracut.conf.d/
# /etc/dracut.conf.d/*.conf will override the settings in /etc/dracut.conf
# SEE man dracut.conf(5)
#
# kernel modules to omit
# Specify a space-separated list of kernel modules not to add to the initramfs.
# The kernel modules have to be specified without the ".ko" suffix.
#
omit_drivers+=" nouveau "


- Only this time, for the current kernel
# dracut -f --kver $(uname -r)


- nouveau.ko doesn't fall anymore into the init image
# lsinitrd /boot/initramfs-$(uname -r).img | grep nouveau ; echo $?
1


Therefore, you no longer need to re/generate an initramfs after building and installing patched nouveau.

Comment 23 Lars E. Pettersson 2015-01-19 20:15:19 UTC
Still present in Fedora 21 kernels, so setting version to 21.

No good luck upstream yet, https://bugs.freedesktop.org/show_bug.cgi?id=80901

Comment 24 Fedora End Of Life 2015-11-04 14:04:30 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 25 Klaus-Peter Schrage 2015-11-05 14:18:59 UTC
The bug is still alive in Fedora 23 (as it is in 22). I didn't even have to install Fedora 23, the fan goes up to 100 % speed immediately after booting to Fedora-Server-DVD-x86_64-23 from an USB drive.

Comment 26 Lars E. Pettersson 2015-11-05 14:40:28 UTC
(In reply to Klaus-Peter Schrage from comment #25)
> The bug is still alive in Fedora 23 (as it is in 22). I didn't even have to
> install Fedora 23, the fan goes up to 100 % speed immediately after booting
> to Fedora-Server-DVD-x86_64-23 from an USB drive.

I also see it in 23. Have updated version information on this bug.

Comment 27 Lars E. Pettersson 2016-08-04 10:04:54 UTC
(In reply to Lars E. Pettersson from comment #26)
> (In reply to Klaus-Peter Schrage from comment #25)
> > The bug is still alive in Fedora 23 (as it is in 22). I didn't even have to
> > install Fedora 23, the fan goes up to 100 % speed immediately after booting
> > to Fedora-Server-DVD-x86_64-23 from an USB drive.
> 
> I also see it in 23. Have updated version information on this bug.

I also see it in 24. Have updated version information on this bug.

Comment 28 Klaus-Peter Schrage 2017-01-12 14:23:15 UTC
(In reply to Lars E. Pettersson from comment #27)
> (In reply to Lars E. Pettersson from comment #26)
> > (In reply to Klaus-Peter Schrage from comment #25)
> > > The bug is still alive in Fedora 23 (as it is in 22). I didn't even have to
> > > install Fedora 23, the fan goes up to 100 % speed immediately after booting
> > > to Fedora-Server-DVD-x86_64-23 from an USB drive.
> > 
> > I also see it in 23. Have updated version information on this bug.
> 
> I also see it in 24. Have updated version information on this bug.

Still alive in Fedora 25 ...

Comment 29 Fedora End Of Life 2017-11-16 19:54:05 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 30 Lars E. Pettersson 2017-11-17 08:36:05 UTC
Problem still present in Fedora 27 and kernel kernel-4.13.5-200.fc26.x86_64

Comment 31 Ben Cotton 2018-11-27 18:12:01 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 32 Ben Cotton 2018-11-30 18:17:12 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.