Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?

[Alan McKinnon]

On 25/08/2013 18:34, Mick wrote:
> On Sunday 25 Aug 2013 17:18:09 Alan McKinnon wrote:
>> On 25/08/2013 02:45, »Q« wrote:
>>> On Sat, 24 Aug 2013 09:49:43 +0200
>>>
>>> Alan McKinnon <alan.mckinnon@×××××.com> wrote:
>>>> On 24/08/2013 06:26, Chris Stankevitz wrote:
>>>>> On Fri, Aug 23, 2013 at 9:12 PM, »Q« <boxcars@×××.net> wrote:
>>>>>> It looks like maybe the best way to tell which ebuilds support
>>>>>> which kernels is to read the conditional for the ewarn message in
>>>>>> each ebuild.
>>>>>
>>>>> If this sort of problem spreads it might be good to build into
>>>>> portage some kind of blocker/keyword mechanism so that users need
>>>>> not deal with this.... not that I have any appreciation for the
>>>>> work involved.
>>>>
>>>> Those tools already exist.
>>>>
>>>> Blockers, which do not really apply here;
>>>
>>> In a comment on the bug (which is full of bugspam), someone suggested
>>> blocking kernels which are incompatible with the currently-installed
>>> nvidia-drivers.  I'm glad that idea was dismissed.
>>>
>>>> elog messages
>>>
>>> Those elog messages are presented after compiling a new kernel and then
>>> trying and failing to compile nvidia-drivers.  So now I grep the
>>> nvidia-drivers ebuilds for the messages before I compile a new kernel.
>>>
>>> A wiki page with info about which nvidia-drivers will build against
>>> which kernels would be a nice thing to have.
>>
>> Your reply demonstrates nicely the true nature of the problem:
>>
>> With nvidia-drivers, sometimes things break and there's nothing sane
>> that portage and the devs can do to help you. You can't check the
>> configured kernels as they may not be running. You can't check the
>> installed sources as they may not be in use. You can't even try identify
>> the sources symlinked by /usr/src/linux as they may have been patched,
>> tweaked or modified and nvidia-drivers may well build whereas against
>> stock sources they don't.
>>
>> The entire problem is completely due to how nVidia chose to do things,
>> it's their business decision. Now, if they were to get their shim code
>> into mainline, most of this nonsense would not happen anymore.
>>
>> The only thing left for Portage and the devs to do is to provide the
>> ebuild and ask you to run it. If it doesn't compile, then don't run that
>> kernel.
>>
>> I doubt your wiki page idea will work, it will be just accurate enough
>> to look like it might work and just inaccurate enough to be useless.
>> Which brings you back to the previous paragraph - try emerge
>> nvidia-drivers and if it fails then don't use that kernel.
>
> I've been always running ATI Radeon cards, by accident rather than design.  I
> was thinking of moving to NVidia on a new box to be built soon, because of the
> many accolades that I have read on the Internet, but reports of problems like
> this make me pause for thought.  Sure it's not major borkage, but it is an
> inconvenience.  How do NVidia users manage such problems?  Trial and error?


The second (trial and error). When you find a combination that works
correctly and well, mark it in your mind as stable++ and stick with it.

My current laptop has a Radeon, the three before that were nVidia. I
just got used to having to use a kernel that was a few versions behind
the most current one to be able to use the binary blob driver. It's
really no big deal in the grand scheme of things - kernels don't change
their behaviour *that* much between versions - most user-facing changes
are new drivers and decent power management stuff. More often than not
the user will have got along just nicely with an older kernel for a
while, and that kernel will carry on doing what it always did and work.
It's very rare that a user *must* have some new kernel and absolutely
cannot go back to an earlier version.

I satisfied myself with trying the most recent kernels once a month and
seeing if the drivers built. If yes, and they worked, great. If not, oh
well I would just go back to what I had before. Half the time I'd have
to do that anyway due to some regression from nVidia anyway (I lost
track of how often a driver update would send GPU temps through the roof
and have the fan running constantly)

nouveau also worked well for me. I don't need fancy 3D graphics (KDE and
e17 effects is about my limit of GPU stressing) and I don't need awesome
battery life, so I was willing to trade power efficiency and
piece-of-mid efficiency. Your needs might be different so YMMV.


-- 
Alan McKinnon
alan.mckinnon@×××××.com