I am having a permanent fan problem with my obviously esoteric graphics card (NVIDIA GeForce GT 630, see [1], [2]) for which I found a viable, but tediuos workaround: - get the kernel src.rpm - apply a specific patch to the nouveau driver - build and install new kernel rpms (see [3]).
I still have to do this on Fedora 21 with the actual kernel version 3.17.6-300, and I fear it will last a while until this problem might be addressed (if ever).
Now doing this the way described in [3] always means copying and moving GBs of code (not to mention the build time), although just a few lines of code are affected. So I thought about rebuilding only the nouveau module instead of compiling the complete kernel source each time the Fedora kernel gets an update. Of course, there are lots of instructions available on building kernel modules, but I found none that refers to a Redhat/Fedora kernel source (there is a section 'Building Only Kernel Modules' in the wiki [3], but this is sort of inapprehensible for me and seems to be outdated).
So any hint would be greatly appreciated. Klaus
[1]https://lists.fedoraproject.org/pipermail/users/2014-July/452276.html [2]https://bugzilla.redhat.com/show_bug.cgi?id=1121331 [3]http://fedoraproject.org/wiki/Building_a_custom_kernel
On 21.12.2014 15:09, Klaus-Peter Schrage wrote:
I am having a permanent fan problem with my obviously esoteric graphics card (NVIDIA GeForce GT 630, see [1], [2]) for which I found a viable, but tediuos workaround:
- get the kernel src.rpm
- apply a specific patch to the nouveau driver
- build and install new kernel rpms (see [3]).
I still have to do this on Fedora 21 with the actual kernel version 3.17.6-300, and I fear it will last a while until this problem might be addressed (if ever).
Now doing this the way described in [3] always means copying and moving GBs of code (not to mention the build time), although just a few lines of code are affected. So I thought about rebuilding only the nouveau module instead of compiling the complete kernel source each time the Fedora kernel gets an update. Of course, there are lots of instructions available on building kernel modules, but I found none that refers to a Redhat/Fedora kernel source (there is a section 'Building Only Kernel Modules' in the wiki [3], but this is sort of inapprehensible for me and seems to be outdated).
So any hint would be greatly appreciated. Klaus
https://lists.fedoraproject.org/pipermail/test/2014-November/123954.html
The only difference with regard to 3.17 compatibility, point to 3.17 branch i.e. git clone -b linux-3.17 git://people.freedesktop.org/~darktama/nouveau
Am 21.12.2014 um 16:27 schrieb poma:
On 21.12.2014 15:09, Klaus-Peter Schrage wrote:
... So I thought about rebuilding only the nouveau module instead of compiling the complete kernel source each time the Fedora kernel gets an update. Of course, there are lots of instructions available on building kernel modules, but I found none that refers to a Redhat/Fedora kernel source (there is a section 'Building Only Kernel Modules' in the wiki [3], but this is sort of inapprehensible for me and seems to be outdated).
https://lists.fedoraproject.org/pipermail/test/2014-November/123954.html
The only difference with regard to 3.17 compatibility, point to 3.17 branch i.e. git clone -b linux-3.17 git://people.freedesktop.org/~darktama/nouveau
Thank you, poma, that was easier than I thought. I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source - which I didn't do yet, but which is, of course, a much easier task now than before.
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
Am 21.12.2014 um 18:34 schrieb Heinz Diehl:
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
Yes, I'll do so when I have figured out how to apply the patch to the nouveau driver from freedesktop.org. The patch is *againsts the kernel source*, like: --- a/drivers/gpu/drm/nouveau/core/... +++ b/drivers/gpu/drm/nouveau/core/... but the structure of the driver from git is: nouveau/drm/core/... (sorry for being so clueless, but I never dealt with kernel modules ...)
On 21.12.2014 19:45, Klaus-Peter Schrage wrote:
Am 21.12.2014 um 18:34 schrieb Heinz Diehl:
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
Yes, I'll do so when I have figured out how to apply the patch to the nouveau driver from freedesktop.org. The patch is *againsts the kernel source*, like: --- a/drivers/gpu/drm/nouveau/core/... +++ b/drivers/gpu/drm/nouveau/core/... but the structure of the driver from git is: nouveau/drm/core/... (sorry for being so clueless, but I never dealt with kernel modules ...)
Check rhbz #1121331, recent comments.
Am 22.12.2014 um 00:11 schrieb poma:
On 21.12.2014 19:45, Klaus-Peter Schrage wrote:
Am 21.12.2014 um 18:34 schrieb Heinz Diehl:
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
Yes, I'll do so when I have figured out how to apply the patch to the nouveau driver from freedesktop.org. The patch is *againsts the kernel source*, like: --- a/drivers/gpu/drm/nouveau/core/... +++ b/drivers/gpu/drm/nouveau/core/... but the structure of the driver from git is: nouveau/drm/core/... (sorry for being so clueless, but I never dealt with kernel modules ...)
Check rhbz #1121331, recent comments.
Thank you for your detailed instructions on bugzilla, they were easy to follow - but on reboot, the gpu fan began to roar like before, although no errors occurred during the process of building and installing the nouveau module:
1. The nouveau source from git got patched by your patchfile in exactly the same way as the kernel source tree got patched by "my" patchfile. The four respective files were identical.
2. The make process of the nouveau module finished without error, I copied nouveau.ko to /lib/modules/3.17.6-300.fc21.x86_64/updates/
3. After depmod, modinfo -n showed the appropriate location of the module: /lib/modules/3.17.6-300.fc21.x86_64/updates/nouveau.ko
So I really can't figure out what happened, I repeated the process of rebuilding the complete kernel tree and got a quiet fan again ...
On 12/22/2014 08:52 AM, Klaus-Peter Schrage wrote:
Am 22.12.2014 um 00:11 schrieb poma:
On 21.12.2014 19:45, Klaus-Peter Schrage wrote:
Am 21.12.2014 um 18:34 schrieb Heinz Diehl:
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
Yes, I'll do so when I have figured out how to apply the patch to the nouveau driver from freedesktop.org. The patch is *againsts the kernel source*, like: --- a/drivers/gpu/drm/nouveau/core/... +++ b/drivers/gpu/drm/nouveau/core/... but the structure of the driver from git is: nouveau/drm/core/... (sorry for being so clueless, but I never dealt with kernel modules ...)
Check rhbz #1121331, recent comments.
Thank you for your detailed instructions on bugzilla, they were easy to follow - but on reboot, the gpu fan began to roar like before, although no errors occurred during the process of building and installing the nouveau module:
- The nouveau source from git got patched by your patchfile in exactly
the same way as the kernel source tree got patched by "my" patchfile. The four respective files were identical.
Are all four files inside nouveau or is there one or a couple that patch something else?
- The make process of the nouveau module finished without error, I
copied nouveau.ko to /lib/modules/3.17.6-300.fc21.x86_64/updates/
- After depmod, modinfo -n showed the appropriate location of the module:
/lib/modules/3.17.6-300.fc21.x86_64/updates/nouveau.ko
So I really can't figure out what happened, I repeated the process of rebuilding the complete kernel tree and got a quiet fan again ...
a) Does your patch modify the version number of the driver, and if so, b) After installing the new driver, does "modinfo nouveau" show your new version? ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - First Law of Work: - - If you can't get it done in the first 24 hours, work nights. - ----------------------------------------------------------------------
Am 22.12.2014 um 17:52 schrieb Klaus-Peter Schrage:
Am 22.12.2014 um 00:11 schrieb poma:
On 21.12.2014 19:45, Klaus-Peter Schrage wrote:
Am 21.12.2014 um 18:34 schrieb Heinz Diehl:
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
Yes, I'll do so when I have figured out how to apply the patch to the nouveau driver from freedesktop.org. The patch is *againsts the kernel source*, like: --- a/drivers/gpu/drm/nouveau/core/... +++ b/drivers/gpu/drm/nouveau/core/... but the structure of the driver from git is: nouveau/drm/core/... (sorry for being so clueless, but I never dealt with kernel modules ...)
Check rhbz #1121331, recent comments.
Thank you for your detailed instructions on bugzilla, they were easy to follow - but on reboot, the gpu fan began to roar like before, although no errors occurred during the process of building and installing the nouveau module:
- The nouveau source from git got patched by your patchfile in exactly
the same way as the kernel source tree got patched by "my" patchfile. The four respective files were identical.
- The make process of the nouveau module finished without error, I
copied nouveau.ko to /lib/modules/3.17.6-300.fc21.x86_64/updates/
- After depmod, modinfo -n showed the appropriate location of the module:
/lib/modules/3.17.6-300.fc21.x86_64/updates/nouveau.ko
So I really can't figure out what happened, I repeated the process of rebuilding the complete kernel tree and got a quiet fan again ...
There is even more magic: I repeated the proposed build process of the patched nouveau driver after an update to the most recent kernel (3.17.7-300) - result again: a noisy fan.
Than (after booting into a different kernel) I removed kernel-3.17.7-300.fc21.x86_64 (and the corresponding kernel-core and kernel-modules), this, btw., left /lib/modules/3.17.7-300.fc21.x86_64/ untouched, including the module binary nouveau.ko.
Next step was an update to kernel-3.17.7-300.fc21.x86_64 again, and after booting into it, the fan was silent! modinfo -n nouveau says: /lib/modules/3.17.7-300.fc21.x86_64/updates/nouveau.ko, which is the binary that had survived the erasure of 3.17.7-300.
I really have no idea about the way modules get installed during a kernel update, but there seems to be something more than a "simple" depmod command that I gave after the initial modules build.
On 12/22/2014 09:58 AM, Klaus-Peter Schrage wrote:
Am 22.12.2014 um 17:52 schrieb Klaus-Peter Schrage:
Am 22.12.2014 um 00:11 schrieb poma:
On 21.12.2014 19:45, Klaus-Peter Schrage wrote:
Am 21.12.2014 um 18:34 schrieb Heinz Diehl:
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
Yes, I'll do so when I have figured out how to apply the patch to the nouveau driver from freedesktop.org. The patch is *againsts the kernel source*, like: --- a/drivers/gpu/drm/nouveau/core/... +++ b/drivers/gpu/drm/nouveau/core/... but the structure of the driver from git is: nouveau/drm/core/... (sorry for being so clueless, but I never dealt with kernel modules ...)
Check rhbz #1121331, recent comments.
Thank you for your detailed instructions on bugzilla, they were easy to follow - but on reboot, the gpu fan began to roar like before, although no errors occurred during the process of building and installing the nouveau module:
- The nouveau source from git got patched by your patchfile in exactly
the same way as the kernel source tree got patched by "my" patchfile. The four respective files were identical.
- The make process of the nouveau module finished without error, I
copied nouveau.ko to /lib/modules/3.17.6-300.fc21.x86_64/updates/
- After depmod, modinfo -n showed the appropriate location of the
module: /lib/modules/3.17.6-300.fc21.x86_64/updates/nouveau.ko
So I really can't figure out what happened, I repeated the process of rebuilding the complete kernel tree and got a quiet fan again ...
There is even more magic: I repeated the proposed build process of the patched nouveau driver after an update to the most recent kernel (3.17.7-300) - result again: a noisy fan.
Than (after booting into a different kernel) I removed kernel-3.17.7-300.fc21.x86_64 (and the corresponding kernel-core and kernel-modules), this, btw., left /lib/modules/3.17.7-300.fc21.x86_64/ untouched, including the module binary nouveau.ko.
Next step was an update to kernel-3.17.7-300.fc21.x86_64 again, and after booting into it, the fan was silent! modinfo -n nouveau says: /lib/modules/3.17.7-300.fc21.x86_64/updates/nouveau.ko, which is the binary that had survived the erasure of 3.17.7-300.
I really have no idea about the way modules get installed during a kernel update, but there seems to be something more than a "simple" depmod command that I gave after the initial modules build.
Oh, yeah. Forgot. I suspect you'll need to rebuild the initramfs after patching your driver. The "depmod" verifies that all the module dependencies were met so if you were to "modprobe" nouveau it'd work, but I believe nouveau goes into the initramfs so the boot was still using the original one from the kernel update. So:
1. Patch 2. Build 3. Move to appropriate spot 4. Depmod 5. Rebuild initramfs...make sure the new module is included 6. Reboot ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - To err is human, to moo bovine. - ----------------------------------------------------------------------
Am 22.12.2014 um 19:05 schrieb Rick Stevens:
On 12/22/2014 09:58 AM, Klaus-Peter Schrage wrote:
Am 22.12.2014 um 17:52 schrieb Klaus-Peter Schrage:
Am 22.12.2014 um 00:11 schrieb poma:
On 21.12.2014 19:45, Klaus-Peter Schrage wrote:
Am 21.12.2014 um 18:34 schrieb Heinz Diehl:
On 21.12.2014, Klaus-Peter Schrage wrote:
Oh, yeah. Forgot. I suspect you'll need to rebuild the initramfs after patching your driver. The "depmod" verifies that all the module dependencies were met so if you were to "modprobe" nouveau it'd work, but I believe nouveau goes into the initramfs so the boot was still using the original one from the kernel update. So:
- Patch
- Build
- Move to appropriate spot
- Depmod
- Rebuild initramfs...make sure the new module is included
- Reboot
Rick, I think that's it: lsinitrd lists the nouveau driver and points to the newly built binary in /lib/modules/.../updates/.
In older versions of the initramfs image in my /boot directory, the original driver is listed.
So, in your step 5, a simple "dracut" should do the trick (with the "--force"-option when the initramfs version corresponds to the running kernel). I found that dracut finds and includes the binary in /lib/modules/ .../updates/.
Thank you for pointing me into this direction!
On 12/22/14 17:52, Klaus-Peter Schrage wrote:
- The make process of the nouveau module finished without error, I
copied nouveau.ko to /lib/modules/3.17.6-300.fc21.x86_64/updates/
I did exactly this, but did not realize that the kernel had been updated since I started my computer, so after the reboot the kernel was now at 3.17.7-300, and it, of course, did not find my newly compiled module :) Perhaps this happened to you also?
I then compiled it for the new kernel, but for me the problem is still there, a noisy fan. I will investigate further...
Regarding Nicks question, here I get: $ modinfo nouveau filename: /lib/modules/3.17.7-300.fc21.x86_64/updates/nouveau.ko
Which is the file I compiled.
Lars
On 12/22/2014 10:03 AM, Lars E. Pettersson wrote:
On 12/22/14 17:52, Klaus-Peter Schrage wrote:
- The make process of the nouveau module finished without error, I
copied nouveau.ko to /lib/modules/3.17.6-300.fc21.x86_64/updates/
I did exactly this, but did not realize that the kernel had been updated since I started my computer, so after the reboot the kernel was now at 3.17.7-300, and it, of course, did not find my newly compiled module :) Perhaps this happened to you also?
I then compiled it for the new kernel, but for me the problem is still there, a noisy fan. I will investigate further...
Regarding Nicks question, here I get: $ modinfo nouveau filename: /lib/modules/3.17.7-300.fc21.x86_64/updates/nouveau.ko
Which is the file I compiled.
I was more interested in the "version:" line, not the filename, but looking at nouveau, it doesn't support that, just the "vermagic:" line. Grrrrr! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Sarchasm: The gulf between the author of sarcastic wit and the - - reader...who doesn't get it. - ----------------------------------------------------------------------
On 12/22/14 19:10, Rick Stevens wrote:
On 12/22/2014 10:03 AM, Lars E. Pettersson wrote:
Regarding Nicks question, here I get: $ modinfo nouveau filename: /lib/modules/3.17.7-300.fc21.x86_64/updates/nouveau.ko
Which is the file I compiled.
I was more interested in the "version:" line, not the filename, but looking at nouveau, it doesn't support that, just the "vermagic:" line. Grrrrr!
Sorry for misspelling your name.
Yes, no version, just vermagic.
You were completely right. Step "5. Rebuild initramfs...make sure the new module is included" is needed. Just did it, and my computer is now as silent as it was when I bought it :) Thanks!
Lars
On 12/22/2014 10:31 AM, Lars E. Pettersson wrote:
On 12/22/14 19:10, Rick Stevens wrote:
On 12/22/2014 10:03 AM, Lars E. Pettersson wrote:
Regarding Nicks question, here I get: $ modinfo nouveau filename: /lib/modules/3.17.7-300.fc21.x86_64/updates/nouveau.ko
Which is the file I compiled.
I was more interested in the "version:" line, not the filename, but looking at nouveau, it doesn't support that, just the "vermagic:" line. Grrrrr!
Sorry for misspelling your name.
Yes, no version, just vermagic.
You were completely right. Step "5. Rebuild initramfs...make sure the new module is included" is needed. Just did it, and my computer is now as silent as it was when I bought it :) Thanks!
No worries about the name. I've been called far, FAR worse things!
Anyway, glad you got it sorted out. Nouveau is one of those drivers that needs to be in the RAM disk at boot (along with any filesystem and disk drivers needed to get / mounted). And if you're mucking with kernel modules, it never hurts to rebuild the RAM disk when you're done. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - The light at the end of the tunnel is really an oncoming train. - ----------------------------------------------------------------------
On 24.12.2014 18:50, Rick Stevens wrote: ...
Anyway, glad you got it sorted out. Nouveau is one of those drivers that needs to be in the RAM disk at boot (along with any filesystem and disk drivers needed to get / mounted). And if you're mucking with kernel modules, it never hurts to rebuild the RAM disk when you're done.
So you also use nouveau.ko to mount the root filesystem? :)
Did you not read what is written here in this thread, man.
On 22.12.2014, Lars E. Pettersson wrote:
I then compiled it for the new kernel, but for me the problem is still there, a noisy fan. I will investigate further...
How about finding the first official kernel with the faulty behaviour, bisecting the offending commit and reporting it to the lkml people?
Continuously patching away an obvious bug can't be the solution (and someday it won't work any longer or need a manual merge)..
Btw: is the problem still persistent in plain vanilla 3.19-rc1? https://www.kernel.org/pub/linux/kernel/v3.x/testing/linux-3.19-rc1.tar.xz
On 12/22/14 19:48, Heinz Diehl wrote:
How about finding the first official kernel with the faulty behaviour, bisecting the offending commit and reporting it to the lkml people?
This bugzilla-comment contains a link to the kernel patch that seem to create problems for some of us. The question is whether this patch cures problems for others?
https://bugzilla.redhat.com/show_bug.cgi?id=1121331#c8
(my card is Fermi card, NVC0, a Quadro 2000, code name NVC3(GF106), whether that one has "0x46 entries in the thermal table", or not, is beyond me)
Continuously patching away an obvious bug can't be the solution (and someday it won't work any longer or need a manual merge)..
Yes...
Btw: is the problem still persistent in plain vanilla 3.19-rc1? https://www.kernel.org/pub/linux/kernel/v3.x/testing/linux-3.19-rc1.tar.xz
I haven't compiled a kernel in years (decades), but my hunch is that if the patch mentioned in the bugzilla above is still there, it will still have problems (for some of us).
Lars
Am 22.12.2014 um 19:48 schrieb Heinz Diehl:
On 22.12.2014, Lars E. Pettersson wrote:
I then compiled it for the new kernel, but for me the problem is still there, a noisy fan. I will investigate further...
How about finding the first official kernel with the faulty behaviour, bisecting the offending commit and reporting it to the lkml people?
Heinz, it was you who pointed me to the offending patch: http://tinyurl.com/mz4vsr8 As far as I can see, the nouveau driver hasn't changed much since then.
Continuously patching away an obvious bug can't be the solution (and someday it won't work any longer or need a manual merge)..
As you have suggested, I will file a bug on freedesktop.org against the nouveau driver.
On 22.12.2014, Klaus-Peter Schrage wrote:
Heinz, it was you who pointed me to the offending patch: http://tinyurl.com/mz4vsr8 As far as I can see, the nouveau driver hasn't changed much since then.
Hmm, I wrote this because it seems to me that reverting this particular commit does work for some, but not for others. Maybe the faulty behavior is triggered by something which is exposed to this particuar commit, without the commit itself being the root cause.
On 22.12.2014 17:52, Klaus-Peter Schrage wrote:
Am 22.12.2014 um 00:11 schrieb poma:
On 21.12.2014 19:45, Klaus-Peter Schrage wrote:
Am 21.12.2014 um 18:34 schrieb Heinz Diehl:
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
Yes, I'll do so when I have figured out how to apply the patch to the nouveau driver from freedesktop.org. The patch is *againsts the kernel source*, like: --- a/drivers/gpu/drm/nouveau/core/... +++ b/drivers/gpu/drm/nouveau/core/... but the structure of the driver from git is: nouveau/drm/core/... (sorry for being so clueless, but I never dealt with kernel modules ...)
Check rhbz #1121331, recent comments.
Thank you for your detailed instructions on bugzilla, they were easy to follow - but on reboot, the gpu fan began to roar like before, although no errors occurred during the process of building and installing the nouveau module:
- The nouveau source from git got patched by your patchfile in exactly
the same way as the kernel source tree got patched by "my" patchfile. The four respective files were identical.
- The make process of the nouveau module finished without error, I
copied nouveau.ko to /lib/modules/3.17.6-300.fc21.x86_64/updates/
- After depmod, modinfo -n showed the appropriate location of the module:
/lib/modules/3.17.6-300.fc21.x86_64/updates/nouveau.ko
So I really can't figure out what happened, I repeated the process of rebuilding the complete kernel tree and got a quiet fan again ...
- 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.
On 12/22/14 22:07, poma wrote:
Therefore, you no longer need to re/generate an initramfs after building and installing patched nouveau.
Isn't the nouveau module needed in initramfs? If not, why is it put there in the first place?
Lars
On 22.12.2014 22:18, Lars E. Pettersson wrote:
On 12/22/14 22:07, poma wrote:
Therefore, you no longer need to re/generate an initramfs after building and installing patched nouveau.
Isn't the nouveau module needed in initramfs? If not, why is it put there in the first place?
Lars
http://www.linuxfromscratch.org/~krejzi/kde5/postlfs/initramfs.html "The only purpose of an initramfs is to mount the root filesystem." ... But in modern Linux distributions in the init-ram-fs-image are the giraffe, elephant and parrot, of course.
On 12/22/14 23:56, poma wrote:
http://www.linuxfromscratch.org/~krejzi/kde5/postlfs/initramfs.html "The only purpose of an initramfs is to mount the root filesystem."
Yes, that was my thinking also, and that the nouveau module had been put there for a reason, but apparently not :)
But in modern Linux distributions in the init-ram-fs-image are the giraffe, elephant and parrot, of course.
So it seems :)
Lars
On 23.12.2014 09:30, Lars E. Pettersson wrote:
On 12/22/14 23:56, poma wrote:
http://www.linuxfromscratch.org/~krejzi/kde5/postlfs/initramfs.html "The only purpose of an initramfs is to mount the root filesystem."
Yes, that was my thinking also, and that the nouveau module had been put there for a reason, but apparently not :)
But in modern Linux distributions in the init-ram-fs-image are the giraffe, elephant and parrot, of course.
So it seems :)
Lars
Size and content of the init-ram-fs-image varies in relation to the expected functionality, or to put it simply, depend on certain module ex/in-clusion, but not limited to.
man 8 dracut
# ll -h /boot/initramfs-$(uname -r).img | awk '{print $5}' 25M # lsinitrd /boot/initramfs-$(uname -r).img | grep .ko | wc -l 415
# ll -h /boot/initramfs-$(uname -r).img | awk '{print $5}' 4.7M # lsinitrd /boot/initramfs-$(uname -r).img | grep .ko | wc -l 1
Exemplary example - BIOS SATA_AHCI/MD-RAID1/EXT4 & S3/S4 (SUSPEND/HIBERNATE)
/etc/dracut.conf.d/local.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)
# Turn off all dracut modules unnecessary for local boot & system power sleep states omit_dracutmodules+=" bash biosdevname btrfs busybox cms convertfs crypt crypt-gpg crypt-loop dasd dasd_mod dasd_rules debug dm dmraid dmsquash-live drm ecryptfs fstab-sys i18n img-lib lvm kernel-modules modsign multipath plymouth pollcdrom qemu rescue selinux shutdown syslog systemd systemd-bootchart terminfo url-lib usrmount virtfs watchdog zfcp zfcp_rules "
# Host-Only mode: Install only what is needed for booting the local host # instead of a generic host and generate host-specific configuration. # hostonly="{yes|no}" hostonly="yes"
man 5 dracut.conf
Perhaps someone understand all this, but giraffe, elephant and parrot are awesome and understood by all. :)
On 21.12.2014 18:34, Heinz Diehl wrote:
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
PWM fan speed too high https://lists.fedoraproject.org/pipermail/users/2014-July/452287.html
You forgot, and Mr. Fantomas fan finally joined upstream bugzilla after five months later. :) Battle of Marathon.
Lars, the more people report, sooner will be resolved.
Am 23.12.2014 um 23:39 schrieb poma:
On 21.12.2014 18:34, Heinz Diehl wrote:
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
PWM fan speed too high https://lists.fedoraproject.org/pipermail/users/2014-July/452287.html
You forgot, and Mr. Fantomas fan finally joined upstream bugzilla after five months later. :) Battle of Marathon.
Lars, the more people report, sooner will be resolved.
On 24.12.2014 09:54, Klaus-Peter Schrage wrote:
Am 23.12.2014 um 23:39 schrieb poma:
On 21.12.2014 18:34, Heinz Diehl wrote:
On 21.12.2014, Klaus-Peter Schrage wrote:
I first tried the latest and greatest nouveau driver from freedesktop.org "as is", but the fan problem remains, so I still have to apply "my" patch to the nouveau source..
I think you should file a bug against the nouveau driver on bugs.freedesktop.org (xorg -> driver -> nouveau).
PWM fan speed too high https://lists.fedoraproject.org/pipermail/users/2014-July/452287.html
You forgot, and Mr. Fantomas fan finally joined upstream bugzilla after five months later. :) Battle of Marathon.
Lars, the more people report, sooner will be resolved.
That's right. All users should participate more, they shouldn't be just a casual observers. That is the true value.
On 24.12.2014, poma wrote:
All users should participate more, they shouldn't be just a casual observers. That is the true value.
Yes. And if the faulty behaviour is reproduceable with the latest mainline, and since the offending commit is already known, the bug could be directly reported to the lkml. Most probably, this isn't a Fedora-specific thing..
On 12/24/14 11:16, poma wrote:
All users should participate more, they shouldn't be just a casual observers. That is the true value.
Well, as the fedora bugzilla on this issue seem to lead nowhere, I have also added my information on the freedesktop bugzilla. Hopefully this will lead to this issue being resolved...
Lars
On 25.12.2014 01:58, Lars E. Pettersson wrote:
On 12/24/14 11:16, poma wrote:
All users should participate more, they shouldn't be just a casual observers. That is the true value.
Well, as the fedora bugzilla on this issue seem to lead nowhere, I have also added my information on the freedesktop bugzilla. Hopefully this will lead to this issue being resolved...
Lars
https://lists.fedoraproject.org/pipermail/kernel/2014-December/005678.html
For the resolution issue should I be filing bugs for Fedora against xorg-x11-drv-nouveau or would I be better off going upstream? B.W. III
"Either works but upstream is usually better in most cases." J.B. - Fedora kernel maintainer
Guys, do not forget to show interest in what's going on, to folks upstream!
Upstream (freedesktop.org): il silencio
Am 19. Januar 2015 20:39:05 MEZ, schrieb poma pomidorabelisima@gmail.com:
Guys, do not forget to show interest in what's going on, to folks upstream!
On 01/19/15 20:39, poma wrote:
Guys, do not forget to show interest in what's going on, to folks upstream!
Not much going on anywhere. Martin Peres mentioned that he was moving (Dec 23) https://bugs.freedesktop.org/show_bug.cgi?id=80901 so perhaps that is delaying things. Who knows...
But I just updated https://bugzilla.redhat.com/show_bug.cgi?id=1121331 to reflect that the problem is still present in Fedora 21 (the bug was filed to Fedora 20).
Lars
On 19.01.2015 21:22, Lars E. Pettersson wrote:
On 01/19/15 20:39, poma wrote:
Guys, do not forget to show interest in what's going on, to folks upstream!
Not much going on anywhere. Martin Peres mentioned that he was moving (Dec 23) https://bugs.freedesktop.org/show_bug.cgi?id=80901 so perhaps that is delaying things. Who knows...
But I just updated https://bugzilla.redhat.com/show_bug.cgi?id=1121331 to reflect that the problem is still present in Fedora 21 (the bug was filed to Fedora 20).
Lars
That's right, if no one asks no one will know. Do not hesitate to greet a man, ask him how he is, is he working on solving your and not only your problem. There's nothing wrong with that, you know.
-
Heinz Diehl -
Klaus-Peter Schrage -
Lars E. Pettersson -
poma -
Rick Stevens