Mailing List Archive

On Tue, 2011-05-03 at 20:36 -0700, Fedor Pikus wrote:
> The NVidia RPM is configured to blacklist nouveau, which usually does
> the job of removing it. But recently I ran into the case where it does
> not work. It goes like this:
> 1) Do fresh install of F14 (may be others, but that's all I tried).
> 2) During install, configure F14 update repos
> 3) After install, add ATRPM repos and install NVidia drivers
>
> NVidia module does not load, lsmod shows that nouveau is there.
> Blacklist does not help, blacklisting nouveau on the boot line does
> not help,

Have you tried nouveau.modeset=0?

> even removing nouveau.ko does not help. Fedora installer
> crammed nouveau into initrd! The only solution is to rerun mkinitrd,
> don't need any special arguments, I think nouveau is not one of the
> modules mkinitrd adds just because they are loaded when it runs.
>
> I think if you update the kernel, the problem goes away because
> mkinitrd reruns and new initrd does not contain nouveau (this is why,
> if you don't configure updates, the problem usually does not happen,
> at least if the kernel is updated before ATRPMs are added). Perhaps
> the NVidia RPM from ATRPMs should also regenerate initrd using
> whatever commands the kernel RPM does?
>


--
http://thimm.gr/ - http://ATrpms.net/

On Wed, May 4, 2011 at 12:11 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
> On Tue, 2011-05-03 at 20:36 -0700, Fedor Pikus wrote:
>> The NVidia RPM is configured to blacklist nouveau, which usually does
>> the job of removing it. But recently I ran into the case where it does
>> not work. It goes like this:
>> 1) Do fresh install of F14 (may be others, but that's all I tried).
>> 2) During install, configure F14 update repos
>> 3) After install, add ATRPM repos and install NVidia drivers
>>
>> NVidia module does not load, lsmod shows that nouveau is there.
>> Blacklist does not help, blacklisting nouveau on the boot line does
>> not help,
>
> Have you tried nouveau.modeset=0?

Yes, tried that and rdblacklist=nouveau. I think the problem is that
initrd is built during the install and is configured for
high-resolution text modes, and all modules in initrd are loaded even
if they are later not used. So I may be able to rmmod nouveau if I
disable graphical boot, and then load nvidia, but it requires manual
intervention (and does not seem reliable, sometimes nouveau remains
with refcount one even when lsmod shows no uses of it).
>
>> even removing nouveau.ko does not help. Fedora installer
>> crammed nouveau into initrd! The only solution is to rerun mkinitrd,
>> don't need any special arguments, I think nouveau is not one of the
>> modules mkinitrd adds just because they are loaded when it runs.
>>
>> I think if you update the kernel, the problem goes away because
>> mkinitrd reruns and new initrd does not contain nouveau (this is why,
>> if you don't configure updates, the problem usually does not happen,
>> at least if the kernel is updated before ATRPMs are added). Perhaps
>> the NVidia RPM from ATRPMs should also regenerate initrd using
>> whatever commands the kernel RPM does?
>>
>
>
> --
> http://thimm.gr/ - http://ATrpms.net/
>
> _______________________________________________
> atrpms-devel mailing list
> atrpms-devel@atrpms.net
> http://lists.atrpms.net/mailman/listinfo/atrpms-devel
>



--
Fedor G Pikus (fpikus@gmail.com)
http://www.pikus.net
http://wild-light.com

_______________________________________________
atrpms-devel mailing list
atrpms-devel@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

On Wed, 2011-05-04 at 00:26 -0700, Fedor Pikus wrote:
> On Wed, May 4, 2011 at 12:11 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
> > On Tue, 2011-05-03 at 20:36 -0700, Fedor Pikus wrote:
> >> The NVidia RPM is configured to blacklist nouveau, which usually does
> >> the job of removing it. But recently I ran into the case where it does
> >> not work. It goes like this:
> >> 1) Do fresh install of F14 (may be others, but that's all I tried).
> >> 2) During install, configure F14 update repos
> >> 3) After install, add ATRPM repos and install NVidia drivers
> >>
> >> NVidia module does not load, lsmod shows that nouveau is there.
> >> Blacklist does not help, blacklisting nouveau on the boot line does
> >> not help,
> >
> > Have you tried nouveau.modeset=0?
>
> Yes, tried that and rdblacklist=nouveau. I think the problem is that
> initrd is built during the install and is configured for
> high-resolution text modes, and all modules in initrd are loaded even
> if they are later not used.

I thought these commands would prevent the loading of nouveau from
initrd/initram.

Try booting into mode 3 or mode 1 and see if the nouveau driver has been
loaded (lsmod | grep nouveau). BTW you need both the nouveau.modeset=0
setting *and* the blacklisting at modprobe level, e.g. nouveau needs
blacklisting at two levels.

I have the above kernel command line option and blacklist nouveau
in /etc/modprobe.d/nvidia.conf and didn't have a nouveau/nvidia clash
since ever.

> So I may be able to rmmod nouveau if I disable graphical boot, and
> then load nvidia, but it requires manual intervention (and does not
> seem reliable, sometimes nouveau remains with refcount one even when
> lsmod shows no uses of it).
--
http://thimm.gr/ - http://ATrpms.net/

On Wed, May 4, 2011 at 1:13 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
> On Wed, 2011-05-04 at 00:26 -0700, Fedor Pikus wrote:
>> On Wed, May 4, 2011 at 12:11 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
>> > On Tue, 2011-05-03 at 20:36 -0700, Fedor Pikus wrote:
>> >> The NVidia RPM is configured to blacklist nouveau, which usually does
>> >> the job of removing it. But recently I ran into the case where it does
>> >> not work. It goes like this:
>> >> 1) Do fresh install of F14 (may be others, but that's all I tried).
>> >> 2) During install, configure F14 update repos
>> >> 3) After install, add ATRPM repos and install NVidia drivers
>> >>
>> >> NVidia module does not load, lsmod shows that nouveau is there.
>> >> Blacklist does not help, blacklisting nouveau on the boot line does
>> >> not help,
>> >
>> > Have you tried nouveau.modeset=0?
>>
>> Yes, tried that and rdblacklist=nouveau. I think the problem is that
>> initrd is built during the install and is configured for
>> high-resolution text modes, and all modules in initrd are loaded even
>> if they are later not used.
>
> I thought these commands would prevent the loading of nouveau from
> initrd/initram.
>
> Try booting into mode 3 or mode 1 and see if the nouveau driver has been
> loaded (lsmod | grep nouveau). BTW you need both the nouveau.modeset=0

That's how I tracked it to initrd, I booted "single" and nouveau was
there, that's before most things are loaded. Well, that, and removing
nouveau.ko.

> setting *and* the blacklisting at modprobe level, e.g. nouveau needs
> blacklisting at two levels.

When it's not in initrd, blacklist in modprobe.conf is sufficient.
When it's in initrd, it just gets force-loaded on boot.

>
> I have the above kernel command line option and blacklist nouveau
> in /etc/modprobe.d/nvidia.conf and didn't have a nouveau/nvidia clash
> since ever.
>
>> So I may be able to rmmod nouveau if I disable graphical boot, and
>> then load nvidia, but it requires manual intervention (and does not
>> seem reliable, sometimes nouveau remains with refcount one even when
>> lsmod shows no uses of it).
> --
> http://thimm.gr/ - http://ATrpms.net/
>
> _______________________________________________
> atrpms-devel mailing list
> atrpms-devel@atrpms.net
> http://lists.atrpms.net/mailman/listinfo/atrpms-devel
>



--
Fedor G Pikus (fpikus@gmail.com)
http://www.pikus.net
http://wild-light.com

_______________________________________________
atrpms-devel mailing list
atrpms-devel@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

On Wed, May 4, 2011 at 11:05 AM, Fedor Pikus <fpikus@gmail.com> wrote:
> On Wed, May 4, 2011 at 1:13 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
>> On Wed, 2011-05-04 at 00:26 -0700, Fedor Pikus wrote:
>>> On Wed, May 4, 2011 at 12:11 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
>>> > On Tue, 2011-05-03 at 20:36 -0700, Fedor Pikus wrote:
>>> >> The NVidia RPM is configured to blacklist nouveau, which usually does
>>> >> the job of removing it. But recently I ran into the case where it does
>>> >> not work. It goes like this:
>>> >> 1) Do fresh install of F14 (may be others, but that's all I tried).
>>> >> 2) During install, configure F14 update repos
>>> >> 3) After install, add ATRPM repos and install NVidia drivers
>>> >>
>>> >> NVidia module does not load, lsmod shows that nouveau is there.
>>> >> Blacklist does not help, blacklisting nouveau on the boot line does
>>> >> not help,
>>> >
>>> > Have you tried nouveau.modeset=0?
>>>
>>> Yes, tried that and rdblacklist=nouveau. I think the problem is that
>>> initrd is built during the install and is configured for
>>> high-resolution text modes, and all modules in initrd are loaded even
>>> if they are later not used.
>>
>> I thought these commands would prevent the loading of nouveau from
>> initrd/initram.
>>
>> Try booting into mode 3 or mode 1 and see if the nouveau driver has been
>> loaded (lsmod | grep nouveau). BTW you need both the nouveau.modeset=0
>
> That's how I tracked it to initrd, I booted "single" and nouveau was
> there, that's before most things are loaded. Well, that, and removing
> nouveau.ko.
>
>> setting *and* the blacklisting at modprobe level, e.g. nouveau needs
>> blacklisting at two levels.
>
> When it's not in initrd, blacklist in modprobe.conf is sufficient.
> When it's in initrd, it just gets force-loaded on boot.
>
>>
>> I have the above kernel command line option and blacklist nouveau
>> in /etc/modprobe.d/nvidia.conf and didn't have a nouveau/nvidia clash
>> since ever.
>>
>>> So I may be able to rmmod nouveau if I disable graphical boot, and
>>> then load nvidia, but it requires manual intervention (and does not
>>> seem reliable, sometimes nouveau remains with refcount one even when
>>> lsmod shows no uses of it).
>> --
>> http://thimm.gr/ - http://ATrpms.net/
>>
>> _______________________________________________
>> atrpms-devel mailing list
>> atrpms-devel@atrpms.net
>> http://lists.atrpms.net/mailman/listinfo/atrpms-devel
>>
>
>
>
> --
> Fedor G Pikus (fpikus@gmail.com)
> http://www.pikus.net
> http://wild-light.com
>
> _______________________________________________
> atrpms-devel mailing list
> atrpms-devel@atrpms.net
> http://lists.atrpms.net/mailman/listinfo/atrpms-devel
>

A long time ago, Axel posted instructions on rebuilding initrd, which
should (I believe) fix the issue. I can't find the commands now, but
perhaps Axel can repost the commands. I think this is what finally
fixed the nouveau v nvidia issue for me.

Axel, any thoughts on this?

George

_______________________________________________
atrpms-devel mailing list
atrpms-devel@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

I have the following two added to the kernel boot params on a Fedora
14 laptop and it used to work just fine.

rdblacklist=nouveau vga=0×318


I moved the hard drive to a different laptop with an Intel card a
couple of months ago so can't say if the newest kernel doesn't do
something differently but before that it worked with Fedora 13 an 14
for over an year.

Dejan

_______________________________________________
atrpms-devel mailing list
atrpms-devel@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

On Wed, May 4, 2011 at 8:33 AM, George Galt <george.galt@gmail.com> wrote:
> On Wed, May 4, 2011 at 11:05 AM, Fedor Pikus <fpikus@gmail.com> wrote:
>> On Wed, May 4, 2011 at 1:13 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
>>> On Wed, 2011-05-04 at 00:26 -0700, Fedor Pikus wrote:
>>>> On Wed, May 4, 2011 at 12:11 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
>>>> > On Tue, 2011-05-03 at 20:36 -0700, Fedor Pikus wrote:
>>>> >> The NVidia RPM is configured to blacklist nouveau, which usually does
>>>> >> the job of removing it. But recently I ran into the case where it does
>>>> >> not work. It goes like this:
>>>> >> 1) Do fresh install of F14 (may be others, but that's all I tried).
>>>> >> 2) During install, configure F14 update repos
>>>> >> 3) After install, add ATRPM repos and install NVidia drivers
>>>> >>
>>>> >> NVidia module does not load, lsmod shows that nouveau is there.
>>>> >> Blacklist does not help, blacklisting nouveau on the boot line does
>>>> >> not help,
>>>> >
>>>> > Have you tried nouveau.modeset=0?
>>>>
>>>> Yes, tried that and rdblacklist=nouveau. I think the problem is that
>>>> initrd is built during the install and is configured for
>>>> high-resolution text modes, and all modules in initrd are loaded even
>>>> if they are later not used.
>>>
>>> I thought these commands would prevent the loading of nouveau from
>>> initrd/initram.
>>>
>>> Try booting into mode 3 or mode 1 and see if the nouveau driver has been
>>> loaded (lsmod | grep nouveau). BTW you need both the nouveau.modeset=0
>>
>> That's how I tracked it to initrd, I booted "single" and nouveau was
>> there, that's before most things are loaded. Well, that, and removing
>> nouveau.ko.
>>
>>> setting *and* the blacklisting at modprobe level, e.g. nouveau needs
>>> blacklisting at two levels.
>>
>> When it's not in initrd, blacklist in modprobe.conf is sufficient.
>> When it's in initrd, it just gets force-loaded on boot.
>>
>>>
>>> I have the above kernel command line option and blacklist nouveau
>>> in /etc/modprobe.d/nvidia.conf and didn't have a nouveau/nvidia clash
>>> since ever.
>>>
>>>> So I may be able to rmmod nouveau if I disable graphical boot, and
>>>> then load nvidia, but it requires manual intervention (and does not
>>>> seem reliable, sometimes nouveau remains with refcount one even when
>>>> lsmod shows no uses of it).
>>> --

> A long time ago, Axel posted instructions on rebuilding initrd, which
> should (I believe) fix the issue. I can't find the commands now, but
> perhaps Axel can repost the commands.  I think this is what finally
> fixed the nouveau v nvidia issue for me.

Rebuilding initrd is easy, boot single or 3, cd /boot, and run
mkinitrd -f initrd-<current name> `uname -r`.

The problem is figuring out that you need to rebuild initrd. All
instructions I could find say tha one of several blacklist options
should work, and indeed they do, as soon as you update kernel at least
once (which gets initrd rebuilt).

--
Fedor G Pikus (fpikus@gmail.com)
http://www.pikus.net
http://wild-light.com

_______________________________________________
atrpms-devel mailing list
atrpms-devel@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

On Wed, 2011-05-04 at 08:05 -0700, Fedor Pikus wrote:
> >> > Have you tried nouveau.modeset=0?
> >>
> >> Yes, tried that and rdblacklist=nouveau. I think the problem is that
> >> initrd is built during the install and is configured for
> >> high-resolution text modes, and all modules in initrd are loaded even
> >> if they are later not used.
> >
> > I thought these commands would prevent the loading of nouveau from
> > initrd/initram.
> >
> > Try booting into mode 3 or mode 1 and see if the nouveau driver has been
> > loaded (lsmod | grep nouveau). BTW you need both the nouveau.modeset=0
>
> That's how I tracked it to initrd, I booted "single" and nouveau was
> there, that's before most things are loaded. Well, that, and removing
> nouveau.ko.
>
> > setting *and* the blacklisting at modprobe level, e.g. nouveau needs
> > blacklisting at two levels.
>
> When it's not in initrd, blacklist in modprobe.conf is sufficient.
> When it's in initrd, it just gets force-loaded on boot.

So you mean that if you use the rdblacklist or modeset args you still
get nouveau from the initramfs?

Maybe the circumstances have changed, but at least until about 3/4 year
ago I was maintaining a 20 node nvidia driven pool that autoinstalled
and (IIRC) all I did was to shove the modeline into the grub.conf.

If it has changed, and a new initramfs is needed, then maybe I'm fooled
by the fact that the second kernel you install already has a "fixed"
initramfs or maybe already the first, if the kickstart place the
modprobe snippet onto the fs before the kernel was installed.
--
http://thimm.gr/ - http://ATrpms.net/

On Wed, 2011-05-04 at 11:33 -0400, George Galt wrote:
> A long time ago, Axel posted instructions on rebuilding initrd, which
> should (I believe) fix the issue. I can't find the commands now, but
> perhaps Axel can repost the commands. I think this is what finally
> fixed the nouveau v nvidia issue for me.

I'm still not convinced, as every user out there should be falling in
the same trap and we would have tons of reports, not only on ATrpms, or
Fedora, but generally for nvidia closed source driver users on
distributions with nouveau and kernel mode switching (which should
probably be every current distribution out there).

> Axel, any thoughts on this?

The safest way is to pick the latest running kernel and query rpm itself
how it was done, as the mkinitrd or equivalents are masked behind
wrappers. For example the latest F14 kernel says:

$ rpm -q --scripts kernel-2.6.35.12-90.fc14.x86_64
postinstall scriptlet (using /bin/sh):

if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
[ -f /etc/sysconfig/kernel ]; then
/bin/sed -r -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
fi

/sbin/new-kernel-pkg --package kernel --install 2.6.35.12-90.fc14.x86_64 || exit $?
preuninstall scriptlet (using /bin/sh):
/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove 2.6.35.12-90.fc14.x86_64 || exit $?
posttrans scriptlet (using /bin/sh):
/sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 2.6.35.12-90.fc14.x86_64 || exit $?
/sbin/new-kernel-pkg --package kernel --rpmposttrans 2.6.35.12-90.fc14.x86_64 || exit $?

The interesting bits are the second to the last line in this case. But
beware, the scripts' layout can change (they have in the past and will
do so in the future), if you - dear reader in the year 2525 running
Fedora 10^3 - are reading this use rpm -q --scripts to check on how the
initramfs is set up in your time frame. ;)
--
http://thimm.gr/ - http://ATrpms.net/

On Wed, May 4, 2011 at 9:19 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
> On Wed, 2011-05-04 at 08:05 -0700, Fedor Pikus wrote:
>> >> > Have you tried nouveau.modeset=0?
>> >>
>> >> Yes, tried that and rdblacklist=nouveau. I think the problem is that
>> >> initrd is built during the install and is configured for
>> >> high-resolution text modes, and all modules in initrd are loaded even
>> >> if they are later not used.
>> >
>> > I thought these commands would prevent the loading of nouveau from
>> > initrd/initram.
>> >
>> > Try booting into mode 3 or mode 1 and see if the nouveau driver has been
>> > loaded (lsmod | grep nouveau). BTW you need both the nouveau.modeset=0
>>
>> That's how I tracked it to initrd, I booted "single" and nouveau was
>> there, that's before most things are loaded. Well, that, and removing
>> nouveau.ko.
>>
>> > setting *and* the blacklisting at modprobe level, e.g. nouveau needs
>> > blacklisting at two levels.
>>
>> When it's not in initrd, blacklist in modprobe.conf is sufficient.
>> When it's in initrd, it just gets force-loaded on boot.
>
> So you mean that if you use the rdblacklist or modeset args you still
> get nouveau from the initramfs?
>
> Maybe the circumstances have changed, but at least until about 3/4 year
> ago I was maintaining a 20 node nvidia driven pool that autoinstalled
> and (IIRC) all I did was to shove the modeline into the grub.conf.

On F12 I never had this problem, but I just did 3 installs of F14, and
2 of them had that problem, nouveau was in initrd and I could not keep
it from loading until I ran mkinitrd. The 3rd system did not pick up
updated kernel during install, but got new kernel on the first run of
yum update, and did not have the same problem.

>
> If it has changed, and a new initramfs is needed, then maybe I'm fooled
> by the fact that the second kernel you install already has a "fixed"
> initramfs or maybe already the first, if the kickstart place the
> modprobe snippet onto the fs before the kernel was installed.

Anaconda does something special with the first initrd it creates,
subsequent "yum update" does not add nouveau to initrd. May be
kickstart creates normal initrd?

> --
> http://thimm.gr/ - http://ATrpms.net/
>
> _______________________________________________
> atrpms-devel mailing list
> atrpms-devel@atrpms.net
> http://lists.atrpms.net/mailman/listinfo/atrpms-devel
>



--
Fedor G Pikus (fpikus@gmail.com)
http://www.pikus.net
http://wild-light.com

_______________________________________________
atrpms-devel mailing list
atrpms-devel@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel

On Wed, May 4, 2011 at 9:28 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
> On Wed, 2011-05-04 at 11:33 -0400, George Galt wrote:
>> A long time ago, Axel posted instructions on rebuilding initrd, which
>> should (I believe) fix the issue. I can't find the commands now, but
>> perhaps Axel can repost the commands.  I think this is what finally
>> fixed the nouveau v nvidia issue for me.
>
> I'm still not convinced, as every user out there should be falling in
> the same trap and we would have tons of reports, not only on ATrpms, or
> Fedora, but generally for nvidia closed source driver users on
> distributions with nouveau and kernel mode switching (which should
> probably be every current distribution out there).

The problem does not happen if you don't configure updates during
install (and run yum update before adding nvidia-graphics from
atrpms). It's also timing-sensitive, if new kernel update appears the
problem goes away. That's what happened with one of my systems, after
install I did yum update and a new kernel was installed, then I added
atrpms repo, and everything was fine.

>
>> Axel, any thoughts on this?
>
> The safest way is to pick the latest running kernel and query rpm itself
> how it was done, as the mkinitrd or equivalents are masked behind
> wrappers. For example the latest F14 kernel says:
>
>        $ rpm -q --scripts kernel-2.6.35.12-90.fc14.x86_64
>        postinstall scriptlet (using /bin/sh):
>
>        if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
>           [ -f /etc/sysconfig/kernel ]; then
>          /bin/sed -r -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
>        fi
>
>        /sbin/new-kernel-pkg --package kernel --install 2.6.35.12-90.fc14.x86_64 || exit $?
>        preuninstall scriptlet (using /bin/sh):
>        /sbin/new-kernel-pkg --rminitrd --rmmoddep --remove 2.6.35.12-90.fc14.x86_64 || exit $?
>        posttrans scriptlet (using /bin/sh):
>        /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 2.6.35.12-90.fc14.x86_64 || exit $?
>        /sbin/new-kernel-pkg --package kernel --rpmposttrans 2.6.35.12-90.fc14.x86_64 || exit $?
>
> The interesting bits are the second to the last line in this case. But
> beware, the scripts' layout can change (they have in the past and will
> do so in the future), if you - dear reader in the year 2525 running
> Fedora 10^3 - are reading this use rpm -q --scripts to check on how the
> initramfs is set up in your time frame. ;)
> --
> http://thimm.gr/ - http://ATrpms.net/
>
> _______________________________________________
> atrpms-devel mailing list
> atrpms-devel@atrpms.net
> http://lists.atrpms.net/mailman/listinfo/atrpms-devel
>



--
Fedor G Pikus (fpikus@gmail.com)
http://www.pikus.net
http://wild-light.com

_______________________________________________
atrpms-devel mailing list
atrpms-devel@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-devel