From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 9A27B1381F3 for ; Sun, 25 Aug 2013 20:10:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D6E27E0C06; Sun, 25 Aug 2013 20:09:54 +0000 (UTC) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B5FD5E0BA7 for ; Sun, 25 Aug 2013 20:09:53 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id hr7so3572031wib.16 for ; Sun, 25 Aug 2013 13:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qcirfY7kLIXn0B3d7kxvSOU9MelVBsvwmNQc89yYjJo=; b=aa8zz/HAr/li4g0EhnAih9SHkIGqyCkYH68ZBvr0CGFKDjGG9Myz8ZGPWPRrMHN4Hz tH/ETlgu/Jpt2GGtF2bkrM7mip+UMMyUdticE3X1yvyju9NXp4GdnPJteEqFhH5G0XqG hdqAjFzIH08FQmyYzbLFjebYh1ui49/8+o3i5Op7yqjQoord8Z8/FI/M5JNkpdPfY9YJ wf//qqFg027qfxFh9b+BAuuyXoQYVruVuV3TY3mKiwfC1h8BlkdFyJPPYfO1864RS2+e DdKGWsRbgJ2BATW9VBDkh5OXnRHnOpbVMk0hW+VYhbc/iADSLDUAojYgwAX/IZhwxvC4 E/aA== X-Received: by 10.180.37.16 with SMTP id u16mr5096257wij.46.1377461392353; Sun, 25 Aug 2013 13:09:52 -0700 (PDT) Received: from [172.20.0.41] (196-210-127-228.dynamic.isadsl.co.za. [196.210.127.228]) by mx.google.com with ESMTPSA id ei6sm13326314wid.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 13:09:52 -0700 (PDT) Message-ID: <521A63BE.4090006@gmail.com> Date: Sun, 25 Aug 2013 22:06:22 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet? References: <20130824194527.122b5436@fuchsia.remarqs.net> <521A2E41.2020001@gmail.com> <201308251734.25129.michaelkintzios@gmail.com> In-Reply-To: <201308251734.25129.michaelkintzios@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 70faafa0-fc9f-4fd7-bdcd-8db840b6e1ee X-Archives-Hash: 621c0efe91acf7c0ba4ed4b3ca665c41 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 wrote: >>>> On 24/08/2013 06:26, Chris Stankevitz wrote: >>>>> On Fri, Aug 23, 2013 at 9:12 PM, »Q« 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