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

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

[Chris Stankevitz]

https://bugs.gentoo.org/show_bug.cgi?id=447566

This bug describes a problem people are having with nvidia/kernel.  My question:

Are "regular" nvidia users who run a completely stable system (with
only stable nvidia-drivers and stable gentoo-sources) affected by any
of this?

I run a stable system but I've been afraid to sync for fear I'll get
sucked into having to mask/unmask packages and keep up with the
unfolding drama.

Thank you,

Chris

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

[Randy Westlund]

On Fri, Aug 23, 2013 at 10:45:46AM -0700, Chris Stankevitz wrote:
> Are "regular" nvidia users who run a completely stable system (with
> only stable nvidia-drivers and stable gentoo-sources) affected by any
> of this?

I believe so.  I run testing, but this just cleared up for me a few days ago when I went to kernel 3.10.7 (stable).  I'm currently running kernel 3.10.9 and nvidia-drivers 325.15 (both testing), which works just fine.  Try it and see what happens.

Randy

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

[Paul Klos]

Op vrijdag 23 augustus 2013 14:09:59 schreef Randy Westlund:
> On Fri, Aug 23, 2013 at 10:45:46AM -0700, Chris Stankevitz wrote:
> > Are "regular" nvidia users who run a completely stable system (with
> > only stable nvidia-drivers and stable gentoo-sources) affected by any
> > of this?
> 
> I believe so.  I run testing, but this just cleared up for me a few days ago when I went to kernel 3.10.7 (stable).  I'm currently running kernel 3.10.9 and nvidia-drivers 325.15 (both testing), which works just fine.  Try it and see what happens.
> 
> Randy
> 
Updated to gentoo-sources 3.10.7 (stable) today. I had (stable) x11-drivers/nvidia-drivers-319.32 which failed rebuilding. After keywording x11-drivers/nvidia-drivers I'm on 325.15 as well. Seems to be fine so far.

Paul

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

[»Q«]

On Sat, 24 Aug 2013 00:15:40 +0200
Paul Klos <gentoo@klos2day.nl> wrote:

> Op vrijdag 23 augustus 2013 14:09:59 schreef Randy Westlund:
> > On Fri, Aug 23, 2013 at 10:45:46AM -0700, Chris Stankevitz wrote:  
> > > Are "regular" nvidia users who run a completely stable system
> > > (with only stable nvidia-drivers and stable gentoo-sources)
> > > affected by any of this?  
> > 
> > I believe so.  I run testing, but this just cleared up for me a few
> > days ago when I went to kernel 3.10.7 (stable).  I'm currently
> > running kernel 3.10.9 and nvidia-drivers 325.15 (both testing),
> > which works just fine.  Try it and see what happens.
> 
> Updated to gentoo-sources 3.10.7 (stable) today. I had (stable)
> x11-drivers/nvidia-drivers-319.32 which failed rebuilding. After
> keywording x11-drivers/nvidia-drivers I'm on 325.15 as well. Seems to
> be fine so far.

Same here, amd64

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.
  

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

[Chris Stankevitz]

On Fri, Aug 23, 2013 at 9:12 PM, »Q« <boxcars@gmx.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.

http://www.gentoo.org/main/en/philosophy.xml

The goal of Gentoo is to design tools and systems that allow a user to
do that work as pleasantly and efficiently as possible, as they see
fit. Our tools should be a joy to use, and should help the user to
appreciate the richness of the Linux and free software community, and
the flexibility of free software.

Kind of funny... Gentoo's mandate is sort of at odds with itself.  A
joy to use while simultaneously giving full flexibility.

Chris

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

[Alan McKinnon]

On 24/08/2013 06:26, Chris Stankevitz wrote:
> On Fri, Aug 23, 2013 at 9:12 PM, »Q« <boxcars@gmx.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;
elog messages




> 
> http://www.gentoo.org/main/en/philosophy.xml
> 
> The goal of Gentoo is to design tools and systems that allow a user to
> do that work as pleasantly and efficiently as possible, as they see
> fit. Our tools should be a joy to use, and should help the user to
> appreciate the richness of the Linux and free software community, and
> the flexibility of free software.
> 
> Kind of funny... Gentoo's mandate is sort of at odds with itself.  A
> joy to use while simultaneously giving full flexibility.
> 
> Chris
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[»Q«]

On Sat, 24 Aug 2013 09:49:43 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 24/08/2013 06:26, Chris Stankevitz wrote:
> > On Fri, Aug 23, 2013 at 9:12 PM, »Q« <boxcars@gmx.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.

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

[Alan McKinnon]

On 25/08/2013 02:45, »Q« wrote:
> On Sat, 24 Aug 2013 09:49:43 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> On 24/08/2013 06:26, Chris Stankevitz wrote:
>>> On Fri, Aug 23, 2013 at 9:12 PM, »Q« <boxcars@gmx.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.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 3024 bytes --]

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@gmail.com> wrote:
> >> On 24/08/2013 06:26, Chris Stankevitz wrote:
> >>> On Fri, Aug 23, 2013 at 9:12 PM, »Q« <boxcars@gmx.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?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[hasufell]

On 08/25/2013 06:34 PM, 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@gmail.com> wrote:
>>>> On 24/08/2013 06:26, Chris Stankevitz wrote:
>>>>> On Fri, Aug 23, 2013 at 9:12 PM, »Q« <boxcars@gmx.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?
> 

Sort of. When I hit a nice spot with a kernel/nvidia-driver combination,
then I do not update both for quite a while.

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@gmail.com> wrote:
>>>> On 24/08/2013 06:26, Chris Stankevitz wrote:
>>>>> On Fri, Aug 23, 2013 at 9:12 PM, »Q« <boxcars@gmx.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@gmail.com

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

[Dale]

hasufell wrote:
> On 08/25/2013 06:34 PM, Mick wrote:
>>
>> 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?
>>
> Sort of. When I hit a nice spot with a kernel/nvidia-driver combination,
> then I do not update both for quite a while.
>
>

I rarely have issues with them installing.  I may find some odd bug but
not a clash with kernel and driver.  Then again, I don't update my
kernel very often either.  I did make it to 3.9.5 a little while back. 

I do recall reading about issues with the 3.10.* kernels tho.  I think
something moved or something and Nvidia needed to update the drivers. 

I would usually say I am lucky but folks that know me know better than
that.  lol

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

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

[»Q«]

On Sun, 25 Aug 2013 18:18:09 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 25/08/2013 02:45, »Q« wrote:
> > On Sat, 24 Aug 2013 09:49:43 +0200
> > Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > 
> >> On 24/08/2013 06:26, Chris Stankevitz wrote:
> >>> On Fri, Aug 23, 2013 at 9:12 PM, »Q« <boxcars@gmx.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 was unclear to the point of being misleading.  I'm sorry.

The wiki idea is only for a page which tells which
kernel/nvidia-drivers combinations the Gentoo nvidia-drivers
maintainers support.  And by "support", I mean they'll look into bugs
and fix build problems if they're able to.  This is exactly the info I'm
grepping out of ewarn messages in their ebuilds now.

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

[Alan McKinnon]

On 26/08/2013 03:52, »Q« wrote:
>> 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 was unclear to the point of being misleading.  I'm sorry.
> 
> The wiki idea is only for a page which tells which
> kernel/nvidia-drivers combinations the Gentoo nvidia-drivers
> maintainers support.  And by "support", I mean they'll look into bugs
> and fix build problems if they're able to.  This is exactly the info I'm
> grepping out of ewarn messages in their ebuilds now.


That list is the list of kernels that nVidia supports, which is easy to
find.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[»Q«]

On Mon, 26 Aug 2013 08:02:32 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 26/08/2013 03:52, »Q« wrote:
> >> 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 was unclear to the point of being misleading.  I'm sorry.
> > 
> > The wiki idea is only for a page which tells which
> > kernel/nvidia-drivers combinations the Gentoo nvidia-drivers
> > maintainers support.  And by "support", I mean they'll look into
> > bugs and fix build problems if they're able to.  This is exactly
> > the info I'm grepping out of ewarn messages in their ebuilds now.
> 
> 
> That list is the list of kernels that nVidia supports, which is easy
> to find.

Where?  AIUI from reading various threads about this, sometimes that
info can be found in nVidia's developer web forum, but I've never been
able to find it there.  nVidia's READMEs give a minimum kernel version,
but no max.

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

[Alan McKinnon]

On 27/08/2013 04:06, »Q« wrote:
> On Mon, 26 Aug 2013 08:02:32 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> On 26/08/2013 03:52, »Q« wrote:
>>>> 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 was unclear to the point of being misleading.  I'm sorry.
>>>
>>> The wiki idea is only for a page which tells which
>>> kernel/nvidia-drivers combinations the Gentoo nvidia-drivers
>>> maintainers support.  And by "support", I mean they'll look into
>>> bugs and fix build problems if they're able to.  This is exactly
>>> the info I'm grepping out of ewarn messages in their ebuilds now.
>>
>>
>> That list is the list of kernels that nVidia supports, which is easy
>> to find.
> 
> Where?  AIUI from reading various threads about this, sometimes that
> info can be found in nVidia's developer web forum, but I've never been
> able to find it there.  nVidia's READMEs give a minimum kernel version,
> but no max.


So ask nVidia to clearly and unambiguously state in an easily found
place what kernels *they* support.

Look, all issues with building the driver shim are directly the
responsibility of nVidia themselves, a result of *their* business
decisions. The correct thing to do is to make it nVidia's problem and
not force the community to jump through hoops trying to track down what
does and does not work today.

Or, you could do the heavy lifting yourself. You test all current
drivers with all recent kernels and maintain a gentoo wiki page that
lists the info you want.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Pandu Poluan]

On Tue, Aug 27, 2013 at 12:57 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
> On 27/08/2013 04:06, »Q« wrote:
> > On Mon, 26 Aug 2013 08:02:32 +0200
> > Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >
> >> On 26/08/2013 03:52, »Q« wrote:
> >>>> 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 was unclear to the point of being misleading.  I'm sorry.
> >>>
> >>> The wiki idea is only for a page which tells which
> >>> kernel/nvidia-drivers combinations the Gentoo nvidia-drivers
> >>> maintainers support.  And by "support", I mean they'll look into
> >>> bugs and fix build problems if they're able to.  This is exactly
> >>> the info I'm grepping out of ewarn messages in their ebuilds now.
> >>
> >>
> >> That list is the list of kernels that nVidia supports, which is easy
> >> to find.
> >
> > Where?  AIUI from reading various threads about this, sometimes that
> > info can be found in nVidia's developer web forum, but I've never been
> > able to find it there.  nVidia's READMEs give a minimum kernel version,
> > but no max.
>
>
> So ask nVidia to clearly and unambiguously state in an easily found
> place what kernels *they* support.
>
> Look, all issues with building the driver shim are directly the
> responsibility of nVidia themselves, a result of *their* business
> decisions. The correct thing to do is to make it nVidia's problem and
> not force the community to jump through hoops trying to track down what
> does and does not work today.
>
> Or, you could do the heavy lifting yourself. You test all current
> drivers with all recent kernels and maintain a gentoo wiki page that
> lists the info you want.


Hmm... reading this thread makes me understand why Linus gave nVidia 'the bird'.


Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

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

[Alan McKinnon]

On 27/08/2013 09:14, Pandu Poluan wrote:
>>>> That list is the list of kernels that nVidia supports, which is easy
>>>> > >> to find.
>>> > >
>>> > > Where?  AIUI from reading various threads about this, sometimes that
>>> > > info can be found in nVidia's developer web forum, but I've never been
>>> > > able to find it there.  nVidia's READMEs give a minimum kernel version,
>>> > > but no max.
>> >
>> >
>> > So ask nVidia to clearly and unambiguously state in an easily found
>> > place what kernels *they* support.
>> >
>> > Look, all issues with building the driver shim are directly the
>> > responsibility of nVidia themselves, a result of *their* business
>> > decisions. The correct thing to do is to make it nVidia's problem and
>> > not force the community to jump through hoops trying to track down what
>> > does and does not work today.
>> >
>> > Or, you could do the heavy lifting yourself. You test all current
>> > drivers with all recent kernels and maintain a gentoo wiki page that
>> > lists the info you want.
> 
> Hmm... reading this thread makes me understand why Linus gave nVidia 'the bird'.



I'm not so sure. I can understand nVidia's position. They make and sell
hardware. They want their stuff to run on as many things as possible.

They also have a huge codebase driven mostly by the primary OS of their
users - Windows. Maintaining that is a large job so they'd like to
re-use the bulk of it across all OSes. Business-wise this does make
sense. But it does mean that they have to drop support for much built-in
goodness on Linux (KMS, shipped OpenGL and more) and provide that bit
themselves. No biggy - they have it all already for Windows.

The kernel shim module is GPL'ed, but not in mainline, and there's this
little thing about the Linux kernel - the famous stable api nonsense. So
they are forever playing catch-up, and the kernel DOES rip out huge
chunks of the api as and when needed.

So what's nVidia to do? By and large their support for X11 is pretty
good, and I've seen much worse. Yes, they are behind current kernel
releases. No, they are not years behind. For the most part their code
keeps up with the major binary distros.

To those users who want to run whatever kernel Linux shipped today and
expect nVidia to always keep up, I have an answer: get real people.

nvidia support Linux, they never promised to keep up with Linus. Why do
users think they have a right to demand something from a vendor that the
vendor never promised to do?

Why do some users think it correct and proper to demand the Gentoo
maintainers jump through hoops to provide functionality that nVidia
never promised, for versions they do not support *yet*?

Seriously, to all the nVidia dumpers (not you Pandu), get a life people
and get real. You bought hardware knowing full well what the conditions
for drivers were going to be. The vendor does an OK job in the market
place and if you don't like that, well that's tough. Buy different
hardware. But don't expect entities to do stuff they never agreed to do.

To Gentoo users who dump on this matter, when you installed Gentoo you
implicitly agreed to be your own packager. There is no PPA or Yum repo
and there's no paid staff member building packages. The work the
packager does for Ubuntu and RedHat is now you now have to do yourself,
and part of that is dealing with the times when shit don't work.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[»Q«]

On Tue, 27 Aug 2013 07:57:20 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 27/08/2013 04:06, »Q« wrote:
> > On Mon, 26 Aug 2013 08:02:32 +0200
> > Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > 
> >> That list is the list of kernels that nVidia supports, which is
> >> easy to find.
> > 
> > Where?  AIUI from reading various threads about this, sometimes that
> > info can be found in nVidia's developer web forum, but I've never
> > been able to find it there.  nVidia's READMEs give a minimum kernel
> > version, but no max.
> 
> So ask nVidia to clearly and unambiguously state in an easily found
> place what kernels *they* support.

Nah, they wouldn't help.  I only asked you because you said it was easy
to find.

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

[»Q«]

On Fri, 23 Aug 2013 23:12:39 -0500
»Q« <boxcars@gmx.net> wrote:

> On Sat, 24 Aug 2013 00:15:40 +0200
> Paul Klos <gentoo@klos2day.nl> wrote:
> 
> > Op vrijdag 23 augustus 2013 14:09:59 schreef Randy Westlund:
> > > On Fri, Aug 23, 2013 at 10:45:46AM -0700, Chris Stankevitz
> > > wrote:  
> > > > Are "regular" nvidia users who run a completely stable system
> > > > (with only stable nvidia-drivers and stable gentoo-sources)
> > > > affected by any of this?  
> > > 
> > > I believe so.  I run testing, but this just cleared up for me a
> > > few days ago when I went to kernel 3.10.7 (stable).  I'm currently
> > > running kernel 3.10.9 and nvidia-drivers 325.15 (both testing),
> > > which works just fine.  Try it and see what happens.
> > 
> > Updated to gentoo-sources 3.10.7 (stable) today. I had (stable)
> > x11-drivers/nvidia-drivers-319.32 which failed rebuilding. After
> > keywording x11-drivers/nvidia-drivers I'm on 325.15 as well. Seems
> > to be fine so far.
> 
> Same here, amd64
> 
> 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.

This script works with the nvidia-drivers ebuilds currently in the
tree.  If the format of the ewarn messages changes, it won't.

#!/bin/sh

# This quick-and-dirty script checks the available nvidia-drivers
# ebuilds to show you which are meant to build against which kernel
# versions.
# If you use grep without pcre support, you get to rewrite the grep line.

[ -f /etc/make.conf ] && . /etc/make.conf
[ -f /etc/portage/make.conf ] && . /etc/portage/make.conf
echo
for ebuildversion in $(ls "${PORTDIR}"/x11-drivers/nvidia-drivers/*.ebuild)
  do
    echo ${ebuildversion##*/} supports
    grep -Po '<sys-kernel.*\d' "${ebuildversion}"
    echo
  done
exit