Bug 1121331
Summary: | Fan at full speed on Dell T1650 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lars E. Pettersson <lars> | ||||||||||||||
Component: | xorg-x11-drv-nouveau | Assignee: | Ben Skeggs <bskeggs> | ||||||||||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||||
Priority: | unspecified | ||||||||||||||||
Version: | 27 | CC: | 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: |
|
Created attachment 919268 [details]
kernel 3.15.3
Created attachment 919269 [details]
kernel 3.15.4
Created attachment 919330 [details]
Result of 'sensors' with kernel-3.15.6-200.fc20.x86_64, fan still at full speed.
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. Correction: It is the GPU fan running at full speed. 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 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 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? (In reply to Josh Boyer from comment #9) Didn't know about that, thank you! 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. Created attachment 946132 [details]
Patch applied to various kernel sources
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. Can you clarify how to apply the patch in comment 8 please. Thanks 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). 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 (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). Created attachment 971822 [details]
Quiet fan - NVE0 family - darktama
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 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.
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 (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. 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 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. 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. (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. (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. (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 ... 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. Problem still present in Fedora 27 and kernel kernel-4.13.5-200.fc26.x86_64 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. 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. |
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