Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Do we need a PhD in portage in order to use Gentoo?
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
orionbelt
Tux's lil' helper
Tux's lil' helper


Joined: 05 Apr 2006
Posts: 135
Location: Brussels, Belgium

PostPosted: Mon Apr 24, 2017 1:56 am    Post subject: Do we need a PhD in portage in order to use Gentoo? Reply with quote

I am bringing up this question here after having asked it in a bug report and in a forum topic and having received no answer.

In short, i am stuck with kernel 4.4.39, i.e. 4 stable versions too old, because "it's the maintainer's policy not to apply patches to address kernel compatibility issues [for nvidia-drivers] as this is often a moving target". This is despite the fact that a successful patch has been applied, and apparently still works for all 4.9 kernels, so it is not so much of a moving target, after all. Furthermore (please correct me if i am wrong), it is the kernel that has changed interfaces, not the nvidia drivers, and for all of Nvidia's atrocities towards Linux, i am not sure whether we should expect them to follow up with an immediate new release after every Linux kernel change...

So, my first question is whether it is official Gentoo policy to have the users apply patches instead of applying the patch once and for all centrally, at the repository level.

After giving up on waiting, i decided to dive into applying the patch myself, a task that i didn't have to do so far. So i used the link provided in Comment 10 of the aforementioned bug report:
Quote:
Just use eapply_user mechanism with patch provided in attachments
https://wiki.gentoo.org/wiki//etc/portage/patches

Unfortunately, there is no explanation on how to use the eapply_user mechanism in that link, or in any other link that i tried to find by searching. There is only an example of the deprecated epatch_user mechanism. Still, assuming that epatch_user may still work, i tried to go through the instructions, but apparently they assume one is already familiar with the ebuild universe.

So i come to my second question, follow-up to the first one: Does Gentoo now require of its users to be experts in portage and ebuilds in order to be mere users of Gentoo?! I would like to hope the answer is no...

Please note that this question has nothing to do with whether or not i may be personally inclined to learn how ebuild works. Perhaps i am, but the question is whether this should be a requirement for everyone.

Thanks for any and all comments.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 5296

PostPosted: Mon Apr 24, 2017 3:21 am    Post subject: Re: Do we need a PhD in portage in order to use Gentoo? Reply with quote

orionbelt wrote:
So, my first question is whether it is official Gentoo policy to have the users apply patches instead of applying the patch once and for all centrally, at the repository level.

orionbelt ... obviously, in this case, yes ... but what do we mean by "policy", because where gentoo is concerned developers don't understand the basics of what gentoo is, and their role within it, and so contructing "policy" is such an environment is most likely to be arbitrary.

orionbelt wrote:
So i come to my second question, follow-up to the first one: Does Gentoo now require of its users to be experts in portage and ebuilds in order to be mere users of Gentoo?! I would like to hope the answer is no...

That is not a question that can be answered, what is the baseline requirement for use of any tool?

best ... khay
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 4379

PostPosted: Mon Apr 24, 2017 3:26 am    Post subject: Re: Do we need a PhD in portage in order to use Gentoo? Reply with quote

Quote:
So i come to my second question, follow-up to the first one: Does Gentoo now require of its users to be experts in portage and ebuilds in order to be mere users of Gentoo?! I would like to hope the answer is no...

No, only nVidia does that.

Since you're going to be stuck on an obsolete kernel for an indefinite length of time, why not just apply the patch to it directly?
_________________
Your PID1 sucks // runit-scripts
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2300

PostPosted: Mon Apr 24, 2017 3:32 am    Post subject: Re: Do we need a PhD in portage in order to use Gentoo? Reply with quote

orionbelt wrote:
There is only an example of the deprecated epatch_user mechanism.
What makes you think the two don't follow the same input format? The article explicitly says that they do.

And if you can't read the file location /etc/portage/patches/${CATEGORY}/${P} to mean you need to put the patch in a
new directory /etc/portage/patches/sys-kernel/gentoo-sources you will have major problems trying to run Gentoo...
_________________
First things first, but not necessarily in that order.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11176

PostPosted: Mon Apr 24, 2017 3:39 am    Post subject: Reply with quote

As I understand it, the problem with the nVidia drivers is that they put themselves in a bad spot. On the one hand, they refuse to upstream their driver, so they are stuck maintaining their own compatibility layer, trying to interface to an upstream target that has been very clear about not keeping a guaranteed API over time. On the other hand, they wrote their driver to depend so deeply on kernel internals that regular development churn in the mainline kernel routinely breaks the compatibility shim. If they did not depend on kernel functions that keep changing for good reason, or if they would delegate the compatibility updates to the community, they would be fine. They chose the middle path, which is far more painful than either of those. That pain mostly falls on them, but spills out onto users unfortunate enough to need the nVidia driver (instead of the open one, which unfortunately is not perfectly competitive). If you aren't one of those users who needs the closed nVidia driver, you could switch to Nouveau to avoid this mess.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 5360
Location: Austria

PostPosted: Mon Apr 24, 2017 6:16 am    Post subject: Re: Do we need a PhD in portage in order to use Gentoo? Reply with quote

orionbelt wrote:
Furthermore (please correct me if i am wrong), it is the kernel that has changed interfaces, not the nvidia drivers, and for all of Nvidia's atrocities towards Linux, i am not sure whether we should expect them to follow up with an immediate new release after every Linux kernel change...

vs.
orionbelt wrote:
In short, i am stuck with kernel 4.4.39, i.e. 4 stable versions too old

So, not really 'immediate' anymore, right? Also, we can all follow Linux development live, and so can Nvidia, so it's not like they learn about such changes only on release day.

It is Nvidia's choice of a broken approach, and the users' choice when they buy from Nvidia, to bring hardship on themselves. But besides that, using 4.4.39 is perfectly fine, unless something else is broken for you that you want to upgrade to a newer major release?
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5804

PostPosted: Mon Apr 24, 2017 1:07 pm    Post subject: Reply with quote

If you look at kernel.org you'll get 12 kernels, out of those 12, 4 only are 4.9+
So 8 kernels remains compatible with nvidia drivers, and in real only two that are LTS 4.9.24 and stable 4.10.12 are problematic, other 2 are mainline and next, both unstable.
So even nvidia is doing "bad" generally because of the binary drivers, in this case, even if they would release a new version that still doesn't work with 3.9, it would still be a version that would works with the majority of kernels release so far.

So for me and for that specific case only, i'll blame
gentoo devs (seriously refusing a patch that works for no reason, that argument about moving fast is so stupid when you see gentoo kernel using patches to fix radeon issue on 3.9.9, look at the size of this one)

It's a pity to see some gentoo devs use their position to promote their own mentality or feelings against a company, to a point it hurt gentoo (they are gentoo devs, and should work for gentoo community and not use gentoo for their own war nobody cares about).

gentoo devs not using the patch are doing shit.
gentoo devs stabilizing both nvidia drivers and kernel that are not compatible with each other are doing shit.
gentoo devs using patchse that were last update 2 years ago! (the last one is for 3.9.9 series) are doing shit
gentoo devs telling anyone blahblahblah nvidia instead of speaking about lack of maintenance on the patchset are doing shit.

Yeah we could blame nvidia all we want for the binary drivers, but it wouldn't remove the fact gentoo devs are doing shit there.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 5360
Location: Austria

PostPosted: Mon Apr 24, 2017 5:07 pm    Post subject: Reply with quote

krinn wrote:
It's a pity to see some gentoo devs use their position to promote their own mentality or feelings against a company, to a point it hurt gentoo (they are gentoo devs, and should work for gentoo community and not use gentoo for their own war nobody cares about).

Think, for a second, about the ridiculousness of your statement. Do you really believe the nvidia-drivers maintainer would actively work against their own interests, or waste valuable time on a package only to 'promote their own mentality' against Nvidia? Rather than drop it and just don't care...

Wrt radeon, this is a completely different situation, OSS drivers, maintained by X11 team, and on kernel side, obviously nothing to see here - whatever patchset they apply for hardware, obviously they can't do anything for Nvidias binary bluurb.

It is bad enough that people think we should stall stabilisation in favour of lagging proprietary drivers. <-- this is my opinion as someone not involved at all in GPU drivers.

As always, everyone is invited to join the developer's club - all things X and drivers can use additional manpower.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1199

PostPosted: Mon Apr 24, 2017 5:35 pm    Post subject: Reply with quote

As I just posted to that other thread, I'm using x11-drivers/nvidia-drivers-304.134 on my x86 system with an older nVidia card with sys-kernel/gentoo-sources-4.9.6-r1 and the patch posted in that thread.

And yes...I put all these issues on nVidia for sure, and would never expect their crap to get in the way of kernel stabilization etc. It's been an ongoing battle for me for sure, but one that I put 100% on nVidia and not Gentoo or the kernel.

Tom
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5804

PostPosted: Mon Apr 24, 2017 7:07 pm    Post subject: Reply with quote

asturm wrote:
Think, for a second, about the ridiculousness of your statement. Do you really believe the nvidia-drivers maintainer would actively work against their own interests, or waste valuable time on a package only to 'promote their own mentality' against Nvidia? Rather than drop it and just don't care...

Something you should had done yourself, because only thinking less than a second would had let you think i was speaking about nvidia-drivers maintainer...
Take another second again, and rethink now what statement is ridiculous
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 5360
Location: Austria

PostPosted: Mon Apr 24, 2017 7:17 pm    Post subject: Reply with quote

krinn wrote:
Something you should had done yourself, because only thinking less than a second would had let you think i was speaking about nvidia-drivers maintainer...
Take another second again, and rethink now what statement is ridiculous

What sense would that make? You blame devs not related to nvidia-drivers at all for the state of nvidia-drivers? Anyone else is allowed to state their opinions, they do not affect maintenance of the package.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Roman_Gruber
Advocate
Advocate


Joined: 03 Oct 2006
Posts: 3777
Location: Austro Bavaria

PostPosted: Mon Apr 24, 2017 8:35 pm    Post subject: Re: Do we need a PhD in portage in order to use Gentoo? Reply with quote

orionbelt wrote:
Furthermore (please correct me if i am wrong), it is the kernel that has changed interfaces, not the nvidia drivers, and for all of Nvidia's atrocities towards Linux, i am not sure whether we should expect them to follow up with an immediate new release after every Linux kernel change...


So what.

I had several notebooks with nvidia graphics. Nvidia is broken by design.

First two years manual changing the kernel because the nivida bios is defunct.
Last two years patching because nvidia decided to declare a 4 year old gpu (was brand new at the time of purchase) as obsolte. They name obsolete gpus legacy gpus.

---

It is not that hard to use an editor and apply those changes manually. Why should anyone do this for you in teh first place for a binary driver only gpu?

I did that several times a month with every new release of gentoo-sources.

--

I suggest that you read about how much nvidia provides efforts and help for the open source drivers.

Latest cards are locked out because the driver has to be signed. REference => open source drivers => check their homepage!

--

AMD has decided to go the full open source route. It may be wise, to not use intel or nvidia gpus in the first place and go for the AMD route, when you desire long term support.

--

I also used for a very long time period a kernel branch which was not in the gentoo repro in the past. When you know what you are doing, there is no issue in the first place. 4.4 is not that bad kernel branch for dated hardware.

--

Next hardware will be not an intel gpu or nvidia gpu because of their lack of proper driver support. I expect that common features work or work in a timely fashion.

--

nvidia has its own forum, feel free to ask there, but in my point of view it's a wasted effort, as there was hardly an useable response.

--

As long temr nvidia user, it is common knowledge, to check if the binary drivers supports the new kernel. It is not uncommon to wait a bit for a suitable pair, or just stay at a kernel version which is supported.
Back to top
View user's profile Send private message
Roman_Gruber
Advocate
Advocate


Joined: 03 Oct 2006
Posts: 3777
Location: Austro Bavaria

PostPosted: Mon Apr 24, 2017 8:44 pm    Post subject: Re: Do we need a PhD in portage in order to use Gentoo? Reply with quote

orionbelt wrote:


So, my first question is whether it is official Gentoo policy to have the users apply patches instead of applying the patch once and for all centrally, at the repository level.


When you use dated hardware it is your choice to go the open source route, which should be proper supported. i checked my sold gpu, and that was fully supported.

--

Anyway. I made at least 3 bug reports which included how to deal with that issue.

AS not everyone needs those, the bug report are the source of information. The forum is also a source for information.

Most easy route is to manually patch the kernel source. Search / edit by hand!

Quote:

So i come to my second question, follow-up to the first one: Does Gentoo now require of its users to be experts in portage and ebuilds in order to be mere users of Gentoo?! I would like to hope the answer is no...


Well you just need to read what is changed, and change it. Search, edit replace.

When you are able to use a text writer, you should be able to do that too.

[/quote]portage and ebuilds i
Quote:


No need for that

you could patch it, but that implies that you find the patch for that particular kernel source. Which is not that easy most of the time.

I most of the time had only patches for arch linux, which i manually applied by hand for the gentoo sources! Yeah broken gpu bios!

--

GEntoo is for advanced users. When you struggle or unwilling to use an editor. SEtup your box. You may use something else. I heard windows needs less knowledge for example.
Back to top
View user's profile Send private message
Tony0945
Veteran
Veteran


Joined: 25 Jul 2006
Posts: 1936
Location: Illinois, USA

PostPosted: Mon Apr 24, 2017 8:45 pm    Post subject: Reply with quote

If you are not gaming or using multiple cards or screens, please try using the kernel's nouveau driver. It will do the basic display.

To Roman-Gruber, surely you are not gaming on a notebook?

Latest 4.4 kernel is 4.4.63, just unmask it if necessary. Upstream kernels are coming fast and furious (too fast IMHO). I just built 4.10.11 yesterday and now 4.10.12 is out. I don't know how Linus can consider releasing a kernel every week is stable.
Back to top
View user's profile Send private message
orionbelt
Tux's lil' helper
Tux's lil' helper


Joined: 05 Apr 2006
Posts: 135
Location: Brussels, Belgium

PostPosted: Wed Apr 26, 2017 2:12 am    Post subject: Reply with quote

First, thanks to Hu for his explanation of the nature of the problem with nVidia drivers. I guess i should retract the statement that "it is the kernel that has changed interfaces, not the nvidia drivers, and for all of Nvidia's atrocities towards Linux, i am not sure whether we should expect them to follow up with an immediate new release after every Linux kernel change", since the root problem is nVidia's decision to depend on kernel functions that keep changing while refusing to upstream their driver. I will also grant asturm that the 4.4 kernel series has advanced quite a bit in terms of versions (i don't know in terms of time but still...), so nVidia should have provided an update by now. Well, Gentoo devs didn't know that when they refused to patch early on, but let us assume that they "knew" this would be nVidia's tactic...

However, it is clear that this was not my main point. Of course, i would not expect Gentoo devs to spend their time coming up with a fix or harvesting nVidia forums (though i am curious about what happened with other, bigger distros and whether Gentoo could have copied their solution). My main point was that there was a kind soul who provided a patch, and several people confirmed it was working for them. So all Gentoo devs had to do was apply that patch to benefit us all. The only reason presented in the bug report as to why this doesn't happen is that "it's the maintainer's policy not to apply patches to address kernel compatibility issues as this is often a moving target". To which i counter that there are already 7 versions of the 4.9 kernel branch on Gentoo, and 5 of the 4.10 branch for which the patch or a very similar one may also work. So it's clear that the target does not move that fast, and it's more than just a kernel subversion or two that would benefit from the patch. Besides, it's not that patching is a rare activity. Kernels have already plenty of patches, and so do many other packages.

Let me put it slightly differently: If this did not concern nvidia-drivers but some other package, would Gentoo devs be equally reluctant to apply patches?

So, unless there is some other valid counter-argument that i am missing, it seems to me that as irrational as it may seem (as asturm explained), the anti-nVidia sentiment of some developers (which may be well justified) has become anti-nVidia-user sentiment (which, i think, is much less justified). Or at least they may feel justified in their inaction since it's the users' "fault" for choosing nVidia. As if their users always have a choice as to the hardware they run on. Or as if their users should have known that a choice made 8 or 9 years ago, when the nvidia drivers worked fine, would necessarily lead to today's situation. Again, i am not asking for Gentoo devs to work more because some of their users have nVidia GPUs, but when a patch comes up and it's so easy to apply, i find their refusal to do so quite staggering.

May i add that, open source drivers or not, it's not that AMD's GPUs are piece of cake for Linux. I just tried to use one on a modern laptop a few weeks ago, and there was apparently no way! I ended up using the Intel CPU's integrated GPU, and i read that even Intel is not as good as it used to be with Linux support of its integrated GPUs. So yes, the issues may not be those faced with nVidia's attitudes, but using AMD or Intel GPUs isn't a panacea either. Or perhaps we should return to console mode?

krinn recommended to stay with my current series-4.4 kernel, which i am doing anyway by necessity :) Well, presumably new kernels can contain security fixes, so i try to keep up with the stable kernels in gentoo-sources. My attitude is that this is what a distribution is there for, and people who know better than i decide about kernel progression, and i can save my time by following their stable versions. Besides, i don't know which 4.4 subversions are LTS, in which case i could worry less about security fixes...

Hu and Tony0945 suggested switching to nouveau. Well, i may have to if the current situation persists and neither nVidia nor our beloved Gentoo devs are shamed into action... :? When i tried nouveau some 8 years ago, it had quite a few issues but it has surely improved since then, and i now see that at least on paper it looks quite nice for my GPU.

Still, my motivation for this thread was developer attitude towards (not) applying an existing patch because it concerns nvidia-drivers. I wanted to see how universal this attitude is and, unfortunately IMO, it seems to be quite universal...
Back to top
View user's profile Send private message
orionbelt
Tux's lil' helper
Tux's lil' helper


Joined: 05 Apr 2006
Posts: 135
Location: Brussels, Belgium

PostPosted: Fri Jun 02, 2017 7:12 am    Post subject: Reply with quote

A couple of weeks after the discussion above, i was able to apply an appropriate patch so that i can use kernel 4.9 with nvidia-drivers 340.101 and 340.102. In retrospect, it is something that can be done in 5 minutes if you know exactly what to do. But it took me several hours, spread over several days, to figure it out.

At first i thought of posting here a write-up of my "adventures", for two reasons. One, to show even more clearly to the developers in this discussion, who may be used to patching, that it's not as easy for a first-timer as they seem to think (in addition to my argument that Gentoo should not expect from simple users to be fluent in the ebuild system in order to use Gentoo). Second, to offer it as documentation to those who may have the same problems as i had.

In the end, i decided that my time, of which i had already wasted enough to find a fix on my own, would not be worth it: Judging from previous responses, i doubt that any kind of rational argument could convince some people to change their mind about this. They are convinced that simple users should be able to use ebuild... As for offering back to the community, well, the notion of a "community" assumes certain collaborative and social qualities beyond the "i'll do as i please" attitude, and such qualities are manifestly absent here... (Still, if anyone wishes to know, i'll be happy to provide details).

Recently nvidia-drivers 340.102-r1 came out, and once again, i proved to myself how hopelessly naive i am. I thought that the patch might have been applied this time (assuming nVidia didn't fix it by themselves), so i disabled my user patch before emerging the new nvidia-drivers, and restarted X. "Of course", X crashed. In fact, it was worse than with 340.101: Now X froze my system, which forced me to a hard reset. Not the best of things by itself, and it's even worse on a RAID system --now i'm going through several hours of having a slow system while RAID is in the process of rebuilding. Thank you, Gentoo devs.

Roman_Gruber wrote:
GEntoo is for advanced users. When you struggle or unwilling to use an editor. SEtup your box. You may use something else. I heard windows needs less knowledge for example.

The Doctor wrote:
And if you can't read the file location /etc/portage/patches/${CATEGORY}/${P} to mean you need to put the patch in a new directory /etc/portage/patches/sys-kernel/gentoo-sources you will have major problems trying to run Gentoo...

Please spare me the latent elitism, gentlemen. I may not be a professional developer, but i've dug my teeth to several Unices and their editors and compilers over the decades, and i am a reasonably happy Gentoo user (not developer!) for 13 years now. This is precisely what makes me react like this: Until now i have not needed to know the internals of ebuild to use Gentoo, and i don't think users should have to if they do not wish to.

By the way, i find quite funny that the good Doctor's reply chastising me for failing to do the obvious, is itself wrong (which led me to some wasted time, too): The patch should not go to /etc/portage/patches/sys-kernel/gentoo-sources but to /etc/portage/patches/x11-drivers/nvidia-drivers-340.102/nvidia.patch

Ten years ago, the kind of responses that i got would have probably be shunned by Gentoo overseers. At the time they were concerned about QA, about offering a certain level of user experience, and so on. It seems we are regressing to the days of elitism...
Back to top
View user's profile Send private message
arnvidr
Guru
Guru


Joined: 19 Aug 2004
Posts: 556
Location: Oslo, Norway

PostPosted: Fri Jun 02, 2017 8:36 am    Post subject: Reply with quote

orionbelt wrote:
As for offering back to the community, well, the notion of a "community" assumes certain collaborative and social qualities beyond the "i'll do as i please" attitude, and such qualities are manifestly absent here... (Still, if anyone wishes to know, i'll be happy to provide details).
Please do, my own efforts to move to 4.9 were stumped, and I'm stuck on 4.8 for now. I think all patches I tried made X crash, and I have not had much time to look at that lately.
_________________
Noone wrote:
anything
Back to top
View user's profile Send private message
xaviermiller
Administrator
Administrator


Joined: 23 Jul 2004
Posts: 7218
Location: ~Brussels - Belgique

PostPosted: Fri Jun 02, 2017 10:34 am    Post subject: Reply with quote

001-kernel-4.9.patch:
--- ./kernel/nv-drm.c
+++ ./kernel/nv-drm.c
@@ -115,7 +115,11 @@
 };

 static struct drm_driver nv_drm_driver = {
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0)
+    .driver_features = DRIVER_GEM | DRIVER_PRIME | DRIVER_LEGACY,
+#else
     .driver_features = DRIVER_GEM | DRIVER_PRIME,
+#endif
     .load = nv_drm_load,
     .unload = nv_drm_unload,
     .fops = &nv_drm_fops,


plus

002-kernel-4.10.patch:

diff --git a/kernel/nv-linux.h b/kernel/nv-linux.h
index e7068e3..3ac3c0b 100644
--- a/kernel/nv-linux.h
+++ b/kernel/nv-linux.h
@@ -270,7 +270,7 @@ RM_STATUS nvos_forward_error_to_cray(struct pci_dev *, NvU32,

 extern int nv_pat_mode;

-#if !defined(NV_VMWARE) && defined(CONFIG_HOTPLUG_CPU)
+#if 0
 #define NV_ENABLE_HOTPLUG_CPU
 #include <linux/cpu.h>              /* CPU hotplug support              */
 #include <linux/notifier.h>         /* struct notifier_block, etc       */
diff --git a/kernel/nv-pat.c b/kernel/nv-pat.c
index a725533..91070e0 100644
--- a/kernel/nv-pat.c
+++ b/kernel/nv-pat.c
@@ -210,14 +210,13 @@ nvidia_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu

     switch (action)
     {
-        case CPU_DOWN_FAILED:
         case CPU_ONLINE:
             if (cpu == (NvUPtr)hcpu)
                 nv_setup_pat_entries(NULL);
             else
                 NV_SMP_CALL_FUNCTION(nv_setup_pat_entries, hcpu, 1);
             break;
-        case CPU_DOWN_PREPARE:
+        case CPU_DOWN_PREPARE_FROZEN:
             if (cpu == (NvUPtr)hcpu)
                 nv_restore_pat_entries(NULL);
             else


and for kernel 4.11 (you need to remove above 2 patches)
003-kernel-4.11.patch:

--- ./kernel/nv-linux.h
+++ ./kernel/nv-linux.h
@@ -2082,6 +2082,8 @@ static inline NvU64 nv_node_end_pfn(int nid)
  *    2016 Dec 14:5b56d49fc31dbb0487e14ead790fc81ca9fb2c99
  */

+#include <linux/version.h>
+
 #if defined(NV_GET_USER_PAGES_REMOTE_PRESENT)
     #if defined(NV_GET_USER_PAGES_HAS_WRITE_AND_FORCE_ARGS)
         #define NV_GET_USER_PAGES           get_user_pages
@@ -2129,8 +2131,13 @@ static inline NvU64 nv_node_end_pfn(int nid)

         #else

+#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0)
                return get_user_pages_remote(tsk, mm, start, nr_pages, flags,
                                             pages, vmas);
+#else
+               return get_user_pages_remote(tsk, mm, start, nr_pages, flags,
+                                            pages, vmas, NULL);
+#endif

         #endif

--- ./kernel/nv-pat.c
+++ ./kernel/nv-pat.c
@@ -203,6 +203,7 @@ void nv_disable_pat_support(void)
 }

 #if defined(NV_ENABLE_PAT_SUPPORT) && defined(NV_ENABLE_HOTPLUG_CPU)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0)
 static int
 nvidia_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
 {
@@ -234,6 +235,34 @@ static struct notifier_block nv_hotcpu_nfb = {
     .notifier_call = nvidia_cpu_callback,
     .priority = 0
 };
+#else
+static int nvidia_cpu_online(unsigned int hcpu)
+{
+    unsigned int cpu = get_cpu();
+    if (cpu == hcpu)
+        nv_setup_pat_entries(NULL);
+    else
+        NV_SMP_CALL_FUNCTION(nv_setup_pat_entries, (void *)(long int)hcpu, 1);
+
+    put_cpu();
+
+    return 0;
+}
+
+static int nvidia_cpu_down_prep(unsigned int hcpu)
+{
+    unsigned int cpu = get_cpu();
+    if (cpu == hcpu)
+        nv_restore_pat_entries(NULL);
+    else
+        NV_SMP_CALL_FUNCTION(nv_restore_pat_entries, (void *)(long int)hcpu, 1);
+
+    put_cpu();
+
+    return 0;
+}
+#endif
+
 #endif

 int nv_init_pat_support(nv_stack_t *sp)
@@ -255,7 +284,14 @@ int nv_init_pat_support(nv_stack_t *sp)
 #if defined(NV_ENABLE_PAT_SUPPORT) && defined(NV_ENABLE_HOTPLUG_CPU)
         if (nv_pat_mode == NV_PAT_MODE_BUILTIN)
         {
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0)
             if (register_hotcpu_notifier(&nv_hotcpu_nfb) != 0)
+#else
+            if (cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
+                                  "gpu/nvidia:online",
+                                  nvidia_cpu_online,
+                                  nvidia_cpu_down_prep) != 0)
+#endif
             {
                 nv_disable_pat_support();
                 nv_printf(NV_DBG_ERRORS,
@@ -280,7 +316,11 @@ void nv_teardown_pat_support(void)
     {
         nv_disable_pat_support();
 #if defined(NV_ENABLE_PAT_SUPPORT) && defined(NV_ENABLE_HOTPLUG_CPU)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0)
         unregister_hotcpu_notifier(&nv_hotcpu_nfb);
+#else
+        cpuhp_remove_state_nocalls(CPUHP_AP_ONLINE_DYN);
+#endif
 #endif
     }
 }
--- ./kernel/uvm/nvidia_uvm_lite.c
+++ ./kernel/uvm/nvidia_uvm_lite.c
@@ -820,7 +820,11 @@ done:
 #if defined(NV_VM_OPERATIONS_STRUCT_HAS_FAULT)
 int _fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 10, 0)
     unsigned long vaddr = (unsigned long)vmf->virtual_address;
+#else
+    unsigned long vaddr = (unsigned long)vmf->address;
+#endif
     struct page *page = NULL;
     int retval;

--- ./kernel/nv-drm.c   2017-03-31 03:42:21.000000000 +0200
+++ ./kernel/nv-drm.c   2017-04-06 23:53:14.273356795 +0200
@@ -48,7 +48,7 @@
     return -ENODEV;
 }

-static int nv_drm_unload(
+static void nv_drm_unload(
     struct drm_device *dev
 )
 {
@@ -60,7 +60,7 @@
         {
             BUG_ON(nvl->drm != dev);
             nvl->drm = NULL;
-            return 0;
+            return;
         }
     }

@@ -64,7 +64,7 @@
         }
     }

-    return -ENODEV;
+    return;
 }

 static void nv_gem_free(
--- ./kernel/uvm/nvidia_uvm_linux.h  2017-03-31 03:42:21.000000000 +0200
+++ ./kernel/uvm/nvidia_uvm_linux.h  2017-04-06 23:53:14.273356795 +0200
@@ -124,6 +124,7 @@
 #include <linux/delay.h>            /* mdelay, udelay                   */

 #include <linux/sched.h>            /* suser(), capable() replacement   */
+#include <linux/sched/signal.h>
 #include <linux/moduleparam.h>      /* module_param()                   */
 #if !defined(NV_VMWARE)
 #include <asm/tlbflush.h>           /* flush_tlb(), flush_tlb_all()     */
@@ -362,17 +363,6 @@
     void address_space_init_once(struct address_space *mapping);
 #endif

-#if !defined(NV_FATAL_SIGNAL_PENDING_PRESENT)
-    static inline int __fatal_signal_pending(struct task_struct *p)
-    {
-        return unlikely(sigismember(&p->pending.signal, SIGKILL));
-    }
-
-    static inline int fatal_signal_pending(struct task_struct *p)
-    {
-        return signal_pending(p) && __fatal_signal_pending(p);
-    }
-#endif

 //
 // Before the current->cred structure was introduced, current->euid,
--- ./kernel/uvm/nvidia_uvm_lite.c  2017-03-31 03:42:21.000000000 +0200
+++ ./kernel/uvm/nvidia_uvm_lite.c  2017-04-06 23:53:14.273356795 +0200
@@ -818,7 +818,7 @@
 }

 #if defined(NV_VM_OPERATIONS_STRUCT_HAS_FAULT)
-int _fault(struct vm_area_struct *vma, struct vm_fault *vmf)
+int _fault(struct vm_fault *vmf)
 {
     unsigned long vaddr = (unsigned long)vmf->virtual_address;
     struct page *page = NULL;
@@ -828,7 +828,7 @@
     struct page *page = NULL;
     int retval;

-    retval = _fault_common(vma, vaddr, &page, vmf->flags);
+    retval = _fault_common(NULL, vaddr, &page, vmf->flags);

     vmf->page = page;

@@ -866,7 +866,7 @@
 // it's dealing with anonymous mapping (see handle_pte_fault).
 //
 #if defined(NV_VM_OPERATIONS_STRUCT_HAS_FAULT)
-int _sigbus_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
+int _sigbus_fault(struct vm_fault *vmf)
 {
     vmf->page = NULL;
     return VM_FAULT_SIGBUS;
--- ./kernel/nv-drm.c
+++ ./kernel/nv-drm.c
@@ -115,7 +115,11 @@ static const struct file_operations nv_drm_fops = {
 };

 static struct drm_driver nv_drm_driver = {
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0)
+    .driver_features = DRIVER_GEM | DRIVER_PRIME | DRIVER_LEGACY,
+#else
     .driver_features = DRIVER_GEM | DRIVER_PRIME,
+#endif
     .load = nv_drm_load,
     .unload = nv_drm_unload,
     .fops = &nv_drm_fops,

_________________
Kind regards,
Xavier Miller
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5804

PostPosted: Fri Jun 02, 2017 1:00 pm    Post subject: Reply with quote

XavierMiller if it was your contribution for the "top dude award of the month", you have my vote.
Back to top
View user's profile Send private message
orionbelt
Tux's lil' helper
Tux's lil' helper


Joined: 05 Apr 2006
Posts: 135
Location: Brussels, Belgium

PostPosted: Fri Jun 02, 2017 3:12 pm    Post subject: Reply with quote

arnvidr,

In my case (GeForce 8600 GT, x11-drivers/nvidia-drivers-340.102-r1 and sys-kernel/gentoo-sources-4.9.16), i only needed apply the first patch (001-kernel-4.9.patch) provided by xaviermiller for kernel 4.9:
Code:
--- work/kernel/nv-drm.c
+++ work/kernel/nv-drm.c
@@ -115,7 +115,11 @@
 };
 
 static struct drm_driver nv_drm_driver = {
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 9, 0)
+    .driver_features = DRIVER_GEM | DRIVER_PRIME | DRIVER_LEGACY,
+#else
     .driver_features = DRIVER_GEM | DRIVER_PRIME,
+#endif
     .load = nv_drm_load,
     .unload = nv_drm_unload,
     .fops = &nv_drm_fops,

The procedure in detail is as follows:

  1. Create the path /etc/portage/patches/x11-drivers/nvidia-drivers-340.102/
  2. Inside that path, create file 001-kernel-4.9.patch (anything ending in .patch, really), and copy-paste in it the contents of the patch listed above.
  3. emerge -av1 nvidia-drivers

That's it. To be sure that the patch has been applied, check out at the beginning of the emerge output for "User patches applied". It should look like this:
Code:
>>> Emerging (1 of 1) x11-drivers/nvidia-drivers-340.102-r1::gentoo
 * NVIDIA-Linux-x86_64-340.102.run SHA256 SHA512 WHIRLPOOL size ;-) ...  [ ok ]
 * nvidia-settings-340.102.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...  [ ok ]
 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux
 * Found kernel object directory:
 *     /lib/modules/4.9.16-gentoo/build
 * Found sources for kernel version:
 *     4.9.16-gentoo
 * Checking for suitable kernel configuration options...                 [ ok ]
 * Checking for suitable kernel configuration options...                 [ ok ]
>>> Unpacking source...
>>> Unpacking NVIDIA-Linux-x86_64-340.102.run to /var/tmp/portage/x11-drivers/nvidia-drivers-340.102-r1/work
>>> Unpacking nvidia-settings-340.102.tar.bz2 to /var/tmp/portage/x11-drivers/nvidia-drivers-340.102-r1/work
>>> Source unpacked in /var/tmp/portage/x11-drivers/nvidia-drivers-340.102-r1/work
>>> Preparing source in /var/tmp/portage/x11-drivers/nvidia-drivers-340.102-r1/work ...
 * Applying patches from /etc/portage/patches/x11-drivers/nvidia-drivers-340.102 ...
 *   nvidia.patch ...                                                    [ ok ]
 * User patches applied.

If you tried to launch X before doing the above steps, you should probably "modprobe -r nvidia" before restarting X or else it may try to use the old nvidia module and possibly freeze your system. If this doesn't work, reboot (perhaps there is a better way, i'm not sure).

If you want to use kernels 4.10 or 4.11, you should no doubt follow xaviermiller's instructions (which i haven't tried myself). But they involve kernel (not nvidia-drivers) patches, as far as i can tell [edit: note that 4.10 needs two patches, both for nvidia-drivers and for the kernel], and i don't know whether the above mechanism is also used by genkernel (which i use to build my kernels) or only by emerge. Someone else might be able to explain this better. If the mechanism is the same, then you should put xaviermiller's patches in a directory named /etc/portage/patches/sys-kernel/gentoo-sources-4.10.xxx or /etc/portage/patches/sys-kernel/gentoo-sources-4.11.xxx, respectively.

Hope this helps.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11176

PostPosted: Sat Jun 03, 2017 12:54 am    Post subject: Reply with quote

As a minor correction/addition to your steps, I would add step 2a.: Verify that the newly created .patch file is readable by the portage user. My systems set root's umask to 027, so files created by root default to being inaccessible to unprivileged users. I have had a few times that I set up a user patch for some package (never nVidia drivers, but the principle holds regardless) where the patch defaulted to mode 640 and I forgot to change it before running emerge, causing Portage to die when trying to read the patch file.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 5360
Location: Austria

PostPosted: Sat Jun 03, 2017 10:00 am    Post subject: Reply with quote

orionbelt wrote:
Besides, i don't know which 4.4 subversions are LTS, in which case i could worry less about security fixes...

There is no 'subversions with LTS', all of 4.4 is LTS.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 5804

PostPosted: Sat Jun 03, 2017 10:58 am    Post subject: Reply with quote

LTS list is easy to get, just look at kernel.org you'll see what versions are.
Back to top
View user's profile Send private message
xaviermiller
Administrator
Administrator


Joined: 23 Jul 2004
Posts: 7218
Location: ~Brussels - Belgique

PostPosted: Wed Jul 05, 2017 6:51 am    Post subject: Reply with quote

Hi!,

Here is the patch to add for kernel 4.12:
/etc/portage/patches/x11-drivers/nvidia-drivers/004-linux-4.12.patch:
--- ./kernel/conftest.sh.orig   2017-07-04 19:34:18.849964147 +0200
+++ ./kernel/conftest.sh   2017-07-04 19:40:00.084349448 +0200
@@ -362,7 +362,11 @@
             # Determine if the set_memory_uc() function is present.
             #
             CODE="
-            #include <asm/cacheflush.h>
+            #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0)
+                #include <asm/set_memory.h>
+            #else
+                #include <asm/cacheflush.h>
+            #endif
             void conftest_set_memory_uc(void) {
                 set_memory_uc();
             }"
@@ -375,7 +379,11 @@
             # Determine if the set_memory_array_uc() function is present.
             #
             CODE="
-            #include <asm/cacheflush.h>
+            #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0)
+                #include <asm/set_memory.h>
+            #else
+                #include <asm/cacheflush.h>
+            #endif
             void conftest_set_memory_array_uc(void) {
                 set_memory_array_uc();
             }"
@@ -388,7 +396,11 @@
             # Determine if the set_pages_uc() function is present.
             #
             CODE="
-            #include <asm/cacheflush.h>
+            #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0)
+                #include <asm/set_memory.h>
+            #else
+                #include <asm/cacheflush.h>
+            #endif
             void conftest_set_pages_uc(void) {
                 set_pages_uc();
             }"
--- ./kernel/uvm/conftest.sh.orig   2017-07-04 19:41:43.317660686 +0200
+++ ./kernel/uvm/conftest.sh   2017-07-04 19:40:23.248644401 +0200
@@ -362,7 +362,11 @@
             # Determine if the set_memory_uc() function is present.
             #
             CODE="
-            #include <asm/cacheflush.h>
+            #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0)
+                #include <asm/set_memory.h>
+            #else
+                #include <asm/cacheflush.h>
+            #endif
             void conftest_set_memory_uc(void) {
                 set_memory_uc();
             }"
@@ -375,7 +379,11 @@
             # Determine if the set_memory_array_uc() function is present.
             #
             CODE="
-            #include <asm/cacheflush.h>
+            #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0)
+                #include <asm/set_memory.h>
+            #else
+                #include <asm/cacheflush.h>
+            #endif
             void conftest_set_memory_array_uc(void) {
                 set_memory_array_uc();
             }"
@@ -388,7 +396,11 @@
             # Determine if the set_pages_uc() function is present.
             #
             CODE="
-            #include <asm/cacheflush.h>
+            #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0)
+                #include <asm/set_memory.h>
+            #else
+                #include <asm/cacheflush.h>
+            #endif
             void conftest_set_pages_uc(void) {
                 set_pages_uc();
             }"
--- ./kernel/nv-vm.c.orig   2017-07-04 20:01:37.098802679 +0200
+++ ./kernel/nv-vm.c   2017-07-04 20:02:23.720384972 +0200
@@ -13,6 +13,10 @@
 #include "nv.h"
 #include "nv-linux.h"
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0)
+    #include <asm/set_memory.h>
+#endif
+
 static inline void nv_set_contig_memory_uc(nv_pte_t *page_ptr, NvU32 num_pages)
 {
     if (nv_update_memory_types)

(adapted from https://raw.githubusercontent.com/Hoshpak/void-packages/nvidia340-linux-4.12/srcpkgs/nvidia340/files/linux-4.12.patch)
_________________
Kind regards,
Xavier Miller
Back to top
View user's profile Send private message
R0b0t1
Apprentice
Apprentice


Joined: 05 Jun 2008
Posts: 199

PostPosted: Wed Jul 05, 2017 8:13 am    Post subject: Reply with quote

Hello,

I apologize for changing the topic. Based on feedback I have seen in #gentoo and related channels the Portage documentation is rather hard to read. Most Portage knowledge is passed via word of mouth and in general it seems hard to cite the documentation (no answers typically do this, except broad answers about a topic).

I think there are two causes for this:
  1. Portage is complex like the OP suggests. On some level it is always hard to link a goal with the information that is in the documentation. Most documentation can't cover every goal; it can only describe the software it is for.
  2. Portage is a moving target. Features change frequently and this is usually not reflected in documentation. A good example is /etc/portage/package.use and family - it is possible to find widely cited advice that uses three or more recent notations.

That said I don't know a good way to fix any of it. There might not be anything to fix. Some of the complaints brought up in this thread seem to be applicable to the difficulty of managing a modern Linux installation. Needless to say managing a Linux installation is harder without Portage.

If you use a distribution like Debian or Ubuntu and aim to make use of the latest features you will quickly find yourself doing what Portage does, but without Portage.


Last edited by R0b0t1 on Wed Jul 05, 2017 1:15 pm; edited 1 time in total
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum