Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Dale
Neil Bothwick wrote:
> On Fri, 21 Apr 2023 09:55:24 -0500, Dale wrote:
>
 Also, I switch to the current kernel, it failed in the same way.  It
 isn't just the new kernel, it seems to be any of them.  I wonder how
 hard it is to switch to that other driver.  From the wiki page, it
 looks like a big deal.   
>>> Not really, AFAIR. You just enable nouveau drivers in your kernel
>>> config, uninstall the nvidia package and reboot. This assumes you
>>> haven't got any direct references to the nvisia driver in
>>> /etc/xorg.conf*.
>> I think, pretty much certain, I have it set to nvidia in xorg.conf. 
>> This is a old install.  If I recall correctly, I have to change that. 
>> Also, I'd need to edit make.conf I think.  I read the wiki thingy a few
>> times.  It's mostly undoing things but with the age of this install, I
>> don't think my old way is the new way.  Yep.  I'm getting better at
>> grep.  lol
>>
>> root@fireball / # cat /etc/X11/xorg.conf | grep driver
>>     Driver "mouse"
>>     Driver "kbd"
>>     Driver "nvidia"
> xorg.conf is often unnecessary these days. I only have a file in
> xorg.conf.d to switch the buttons on my trackball.

I thought I read that somewhere.  This is a old install tho.  A decade
or so.  To be honest tho, I'd like to configure my 2nd screen in the
conf file.  As it is, I have it set up within KDE itself I think.  When
I kill the X part, the 2nd screen dies since KDE and friends isn't
running.  I just haven't had the nerve to do it yet.  I can't even be
sure how it is done nowadays.  I think nvidia has a command that does it. 


>> root@fireball / #cat /etc/make.conf | grep video_cards
>> VIDEO_CARDS="nvidia vesa"
>> root@fireball / #
>>
>> I think I'd have to change those.  It may or may not rebuild some
>> packages.  Would I need to leave out vesa or OK to leave it in?
> You'll need to replace nvidia with nouveau here, leave in vesa as a
> fallback.
>
> The worst that can happen is that X fails to start and you need to
> re-emerge the nvidia drivers, which you quickpkg'd of course.
>
>


Back when I was using Mandrake, I actually wrote a step by step guide to
installing the video drivers and did it a way that even a noobie could
follow it.  That was back in the mid 2000's tho.  It was on Linux
Questions I think.  That thing had tons of views and lots of grateful
users.  I thought I had to change that and the one in the xorg.conf file
too.  The big one when rebooting is the xorg file tho.  I just wasn't
sure if something had changed. 

I looked at a Nvidia GTX 1050 video card.  May be good for starting to
accumulate parts for new rig.  Anyway, it has a weird set of outputs.  I
need two HDMI, or three, for mine.  My current monitor will take either
DB15HD or HDMI.  My TV ports are HDMI.  I kinda like everything else
about it except the outputs.  I may have to dig further. 

Dale

:-)  :-)



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Neil Bothwick
On Fri, 21 Apr 2023 09:55:24 -0500, Dale wrote:

> >> Also, I switch to the current kernel, it failed in the same way.  It
> >> isn't just the new kernel, it seems to be any of them.  I wonder how
> >> hard it is to switch to that other driver.  From the wiki page, it
> >> looks like a big deal.   
> > Not really, AFAIR. You just enable nouveau drivers in your kernel
> > config, uninstall the nvidia package and reboot. This assumes you
> > haven't got any direct references to the nvisia driver in
> > /etc/xorg.conf*.

> I think, pretty much certain, I have it set to nvidia in xorg.conf. 
> This is a old install.  If I recall correctly, I have to change that. 
> Also, I'd need to edit make.conf I think.  I read the wiki thingy a few
> times.  It's mostly undoing things but with the age of this install, I
> don't think my old way is the new way.  Yep.  I'm getting better at
> grep.  lol
> 
> root@fireball / # cat /etc/X11/xorg.conf | grep driver
>     Driver "mouse"
>     Driver "kbd"
>     Driver "nvidia"

xorg.conf is often unnecessary these days. I only have a file in
xorg.conf.d to switch the buttons on my trackball.

> root@fireball / #cat /etc/make.conf | grep video_cards
> VIDEO_CARDS="nvidia vesa"
> root@fireball / #
> 
> I think I'd have to change those.  It may or may not rebuild some
> packages.  Would I need to leave out vesa or OK to leave it in?

You'll need to replace nvidia with nouveau here, leave in vesa as a
fallback.

The worst that can happen is that X fails to start and you need to
re-emerge the nvidia drivers, which you quickpkg'd of course.


-- 
Neil Bothwick

This is as bad as it can get; but don't bet on it.


pgp76AGQEPv1X.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Dale
Dr Rainer Woitok wrote:
> Dale,
>
> On Thursday, 2023-04-20 17:36:23 -0500, you wrote:
>
>> ...
>> * Package:    x11-drivers/nvidia-drivers-470.182.03:0/470
>>  * Repository: mine
> Maybe I'm  missing something,  but as of today  "x11-drivers/nvidia-dri-
> vers" version 470.182.03 is still in the normal Gentoo tree.  So why use
> your personal repo?  Do you have a local patch applied?
>
> Sincerely,
>   Rainer
> .
>

I ran into a buggy driver a while back and once I synced and upgraded,
the old one was gone.  So, I started keeping a local copy just in case. 
Of course, as long as I keep a older driver to fall back on, it won't
break anymore.  As soon as I miss one tho, problems.  LOL 

Thanks to you and Ionen.

Dale

:-)  :-) 



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Dale
Arve Barsnes wrote:
> On Fri, 21 Apr 2023 at 11:55, Dale  wrote:
>> Did something change with overlays?  In the past, I copied the ebuild
>> over to local overlay and ran the ebuild command for the manifest.  It
>> downloaded everything that was needed.  Now, it seems it doesn't.  They
>> add a step?  I miss a step that slipped my mind?
> I don't think the files/ directory contents were ever downloaded by
> the ebuilds, they are a part of the portage tree, so they appear when
> you sync. Maybe the files/ contents from the main tree were available
> for your overlay ebuild somehow? I've never had that luxury, so now
> I*m wondering how your ebuild ever worked :-)
>
> Regards,
> Arve
>
>

That's right.  I rarely do anything with local overlays so I forgot
about that.  Next time I'll try to remember to copy the whole directory,
without deleting files no longer in the tree tho.  Don't want to remove
one I need.  ;-)

Thanks.

Dale

:-)  :-) 



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Dale
Neil Bothwick wrote:
> On Fri, 21 Apr 2023 03:58:11 -0500, Dale wrote:
>
>> I did a emerge -ef nvidia-drivers and it still fails.  I was hoping that
>> would pick up the needed files.  Guess not.  I decided to do some more
>> digging.  I noticed that the same version is still in the tree.  I
>> copied the ebuild a while back to a local overlay to make sure I don't
>> lose it.  It seems emerge gives my local overlay priority over the one
>> in the tree.  I renamed the ebuild in my overlay with .old tacked on. 
>> It emerges fine after that since it uses the ebuild in the tree.  It
>> seems my overlay is broken somehow.  Likely a design improvement.  ;-) 
> That's the default by design. If you copy an ebuild to your overlay, it's
> usually because you want to make changes to it, so it should be given
> priority. You can change the priority of overlays in
> /etc/portage/repos.conf, or you can simply mask the overlay version.
>
>

Found the needed info on the wiki and added the priority setting.  I
added "priority=100" which should work right?  It will use the Gentoo
tree first and then mine?  That's my reading of the wiki page anyway. 

Thanks.

Dale

:-)  :-) 


Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Dale
Neil Bothwick wrote:
> On Thu, 20 Apr 2023 20:33:22 -0500, Dale wrote:
>
>> Also, I switch to the current kernel, it failed in the same way.  It
>> isn't just the new kernel, it seems to be any of them.  I wonder how
>> hard it is to switch to that other driver.  From the wiki page, it looks
>> like a big deal. 
> Not really, AFAIR. You just enable nouveau drivers in your kernel config,
> uninstall the nvidia package and reboot. This assumes you haven't got any
> direct references to the nvisia driver in /etc/xorg.conf*.
>
>


I think, pretty much certain, I have it set to nvidia in xorg.conf. 
This is a old install.  If I recall correctly, I have to change that. 
Also, I'd need to edit make.conf I think.  I read the wiki thingy a few
times.  It's mostly undoing things but with the age of this install, I
don't think my old way is the new way.  Yep.  I'm getting better at
grep.  lol

root@fireball / # cat /etc/X11/xorg.conf | grep driver
    Driver "mouse"
    Driver "kbd"
    Driver "nvidia"
root@fireball / #cat /etc/make.conf | grep video_cards
VIDEO_CARDS="nvidia vesa"
root@fireball / #

I think I'd have to change those.  It may or may not rebuild some
packages.  Would I need to leave out vesa or OK to leave it in?

The easiest part, enable in kernel and build it.  With your nifty dracut
command option, it just works. LOL  By the way, the nvidia-driver
package compiled fine against the new kernel.

I may be into to much today to play with this tho.  Maybe late today. 
Tomorrow depending on weather. 

Next time I copy a ebuild to a local overlay, I need to remember to copy
any files directory over too.  I don't recall ever doing that before. 

Thanks to all.  Gotta do some things so may reply to others later. 

Dale

:-)  :-) 



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Neil Bothwick
On Thu, 20 Apr 2023 20:33:22 -0500, Dale wrote:

> Also, I switch to the current kernel, it failed in the same way.  It
> isn't just the new kernel, it seems to be any of them.  I wonder how
> hard it is to switch to that other driver.  From the wiki page, it looks
> like a big deal. 

Not really, AFAIR. You just enable nouveau drivers in your kernel config,
uninstall the nvidia package and reboot. This assumes you haven't got any
direct references to the nvisia driver in /etc/xorg.conf*.


-- 
Neil Bothwick

New sig wanted good price paid.


pgp7HlTOyzzcT.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Neil Bothwick
On Fri, 21 Apr 2023 03:58:11 -0500, Dale wrote:

> I did a emerge -ef nvidia-drivers and it still fails.  I was hoping that
> would pick up the needed files.  Guess not.  I decided to do some more
> digging.  I noticed that the same version is still in the tree.  I
> copied the ebuild a while back to a local overlay to make sure I don't
> lose it.  It seems emerge gives my local overlay priority over the one
> in the tree.  I renamed the ebuild in my overlay with .old tacked on. 
> It emerges fine after that since it uses the ebuild in the tree.  It
> seems my overlay is broken somehow.  Likely a design improvement.  ;-) 

That's the default by design. If you copy an ebuild to your overlay, it's
usually because you want to make changes to it, so it should be given
priority. You can change the priority of overlays in
/etc/portage/repos.conf, or you can simply mask the overlay version.


-- 
Neil Bothwick

Dream as if you'll live forever. Live as if you'll die today.


pgptWnU_q8g1I.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Ionen Wolkens
On Thu, Apr 20, 2023 at 05:36:23PM -0500, Dale wrote:
> /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
> No such file or directory

This sounds like you copied the ebuild to your local overlay but not
the files/ dir which includes the patch. So the patch is not found.

> this error tho and it work when I reboot, it would be great.  I don't
> think that driver version is in the tree anymore.  It shows it is in my
> local overlay.

It is in the tree, 470.x is a long-term-support branch and as long as
NVIDIA continue to support it there's no reason to drop it from the
tree. Just use the ::gentoo version.

470.182.03 is even fairly recent, was a security release added to the
tree last month followed by the cleanup of the vulnerable 470.161.03.

https://packages.gentoo.org/packages/x11-drivers/nvidia-drivers

-- 
ionen


signature.asc
Description: PGP signature


Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Dr Rainer Woitok
Dale,

On Thursday, 2023-04-20 17:36:23 -0500, you wrote:

> ...
> * Package:    x11-drivers/nvidia-drivers-470.182.03:0/470
>  * Repository: mine

Maybe I'm  missing something,  but as of today  "x11-drivers/nvidia-dri-
vers" version 470.182.03 is still in the normal Gentoo tree.  So why use
your personal repo?  Do you have a local patch applied?

Sincerely,
  Rainer



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Arve Barsnes
On Fri, 21 Apr 2023 at 11:55, Dale  wrote:
> Did something change with overlays?  In the past, I copied the ebuild
> over to local overlay and ran the ebuild command for the manifest.  It
> downloaded everything that was needed.  Now, it seems it doesn't.  They
> add a step?  I miss a step that slipped my mind?

I don't think the files/ directory contents were ever downloaded by
the ebuilds, they are a part of the portage tree, so they appear when
you sync. Maybe the files/ contents from the main tree were available
for your overlay ebuild somehow? I've never had that luxury, so now
I*m wondering how your ebuild ever worked :-)

Regards,
Arve



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Dale
Arve Barsnes wrote:
> On Fri, 21 Apr 2023 at 10:58, Dale  wrote:
>> I put my local ebuilds in /usr/local/portage.  Obviously emerge sees it
>> since it was trying to use it.  I don't understand why it doesn't work
>> tho.  I looked at the ebuild in the tree and my overlay, they look the
>> same, including the patches from different versions.
>>
>> Now I need to figure out why the overlay version isn't working.  I've
>> had occasion to need older versions before, due to some bug or
>> something.  Gonna see if it builds against the new kernel now.  Let us
>> pray.
> If your ebuild and the repo ebuild are the same, that means that the
> patch was changed, look in your
> /usr/local/portage/x11-drivers/nvidia-drivers/files/ folder and
> compare with the current files.
>
> Regards,
> Arve
>
>


Well, there's the problem.  There's no files directory there.  I ran the
ebuild command when I added it to the overlay, I don't think it
downloaded anything.  I just copied the ebuild file from the Gentoo
tree.  If I ever need to emerge from the overlay, I hope it works now. 

Did something change with overlays?  In the past, I copied the ebuild
over to local overlay and ran the ebuild command for the manifest.  It
downloaded everything that was needed.  Now, it seems it doesn't.  They
add a step?  I miss a step that slipped my mind? 

Dale

:-)  :-) 



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Arve Barsnes
On Fri, 21 Apr 2023 at 10:58, Dale  wrote:
> I put my local ebuilds in /usr/local/portage.  Obviously emerge sees it
> since it was trying to use it.  I don't understand why it doesn't work
> tho.  I looked at the ebuild in the tree and my overlay, they look the
> same, including the patches from different versions.
>
> Now I need to figure out why the overlay version isn't working.  I've
> had occasion to need older versions before, due to some bug or
> something.  Gonna see if it builds against the new kernel now.  Let us
> pray.

If your ebuild and the repo ebuild are the same, that means that the
patch was changed, look in your
/usr/local/portage/x11-drivers/nvidia-drivers/files/ folder and
compare with the current files.

Regards,
Arve



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Dale
Frank Steinmetzger wrote:
> Am Thu, Apr 20, 2023 at 08:33:22PM -0500 schrieb Dale:
>
>> I cleared the tmp files to give it a fresh start.  It still failed.  The
>> directory and files it complains about being missing, they are.  I went
>> to the ebuild to see what patches are supposed to be installed.  This is
>> the part of the ebuild. 
>>
>>
>> PATCHES=(
>>     "${FILESDIR}"/nvidia-drivers-470.141.03-clang15.patch
>>     "${FILESDIR}"/nvidia-modprobe-390.141-uvm-perms.patch
>>     "${FILESDIR}"/nvidia-settings-390.144-desktop.patch
>>     "${FILESDIR}"/nvidia-settings-390.144-no-gtk2.patch
>>     "${FILESDIR}"/nvidia-settings-390.144-raw-ldflags.patch
>> )
>>
>>
>> As you can see, it wants to apply patches from several versions so while
>> odd, I guess it really does it that way.  I suspect given the age of the
>> drivers that the patches no longer exist or something.  I'd think it
>> would report it couldn't download the files but maybe not.  I may be
>> running out of luck here.  Odd thing is, it compiled a while back. 
> If I read your error output correctly, it’s not that the patch file is 
> missing, but that a file that is mentioned inside the patch is.
>


Oh.  The output of emerge has always been sort of cryptic.  LOL  I just
hope nothing happens where I have to re-emerge it.  At this point, I'd
be in a pickle if the drivers failed and needed to be reinstalled. 

I did a emerge -ef nvidia-drivers and it still fails.  I was hoping that
would pick up the needed files.  Guess not.  I decided to do some more
digging.  I noticed that the same version is still in the tree.  I
copied the ebuild a while back to a local overlay to make sure I don't
lose it.  It seems emerge gives my local overlay priority over the one
in the tree.  I renamed the ebuild in my overlay with .old tacked on. 
It emerges fine after that since it uses the ebuild in the tree.  It
seems my overlay is broken somehow.  Likely a design improvement.  ;-) 

I put my local ebuilds in /usr/local/portage.  Obviously emerge sees it
since it was trying to use it.  I don't understand why it doesn't work
tho.  I looked at the ebuild in the tree and my overlay, they look the
same, including the patches from different versions. 

Now I need to figure out why the overlay version isn't working.  I've
had occasion to need older versions before, due to some bug or
something.  Gonna see if it builds against the new kernel now.  Let us
pray. 

Always something.  :/

Dale

:-)  :-) 



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-21 Thread Frank Steinmetzger
Am Thu, Apr 20, 2023 at 08:33:22PM -0500 schrieb Dale:

> I cleared the tmp files to give it a fresh start.  It still failed.  The
> directory and files it complains about being missing, they are.  I went
> to the ebuild to see what patches are supposed to be installed.  This is
> the part of the ebuild. 
> 
> 
> PATCHES=(
>     "${FILESDIR}"/nvidia-drivers-470.141.03-clang15.patch
>     "${FILESDIR}"/nvidia-modprobe-390.141-uvm-perms.patch
>     "${FILESDIR}"/nvidia-settings-390.144-desktop.patch
>     "${FILESDIR}"/nvidia-settings-390.144-no-gtk2.patch
>     "${FILESDIR}"/nvidia-settings-390.144-raw-ldflags.patch
> )
> 
> 
> As you can see, it wants to apply patches from several versions so while
> odd, I guess it really does it that way.  I suspect given the age of the
> drivers that the patches no longer exist or something.  I'd think it
> would report it couldn't download the files but maybe not.  I may be
> running out of luck here.  Odd thing is, it compiled a while back. 

If I read your error output correctly, it’s not that the patch file is 
missing, but that a file that is mentioned inside the patch is.

-- 
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Error: this virus requires DirectX and 64 MB of RAM!


signature.asc
Description: PGP signature


Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-20 Thread Dale
Morgan Wesström wrote:
> On 2023-04-21 00:36, Dale wrote:
>> /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/temp/environment:
>> line 1291:
>> /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
>>
>> No such file or directory
>>
>> Any thoughts?  Ideas?
>>
>
> I couldn't reproduce the error here. One thing that comes to mind is
> that your system might have an error in its repository configuration.
> /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files is a
> symlink and should point to your main repository, normally
> /var/db/repos/gentoo/x11-drivers/nvidia-drivers/files. When the emerge
> fails, can you check what that symlink actually points to and if this
> is where your repository is stored? What is the output of emerge
> --info? (Repository info is in that output).
>
> /Morgan
>
>

I cleared the tmp files to give it a fresh start.  It still failed.  The
directory and files it complains about being missing, they are.  I went
to the ebuild to see what patches are supposed to be installed.  This is
the part of the ebuild. 


PATCHES=(
    "${FILESDIR}"/nvidia-drivers-470.141.03-clang15.patch
    "${FILESDIR}"/nvidia-modprobe-390.141-uvm-perms.patch
    "${FILESDIR}"/nvidia-settings-390.144-desktop.patch
    "${FILESDIR}"/nvidia-settings-390.144-no-gtk2.patch
    "${FILESDIR}"/nvidia-settings-390.144-raw-ldflags.patch
)


As you can see, it wants to apply patches from several versions so while
odd, I guess it really does it that way.  I suspect given the age of the
drivers that the patches no longer exist or something.  I'd think it
would report it couldn't download the files but maybe not.  I may be
running out of luck here.  Odd thing is, it compiled a while back. 

I tried to google and find the patch, no luck.  No idea where it comes
from.  May run emerge -ef nvidia-drivers and see if it works. 

Also, I switch to the current kernel, it failed in the same way.  It
isn't just the new kernel, it seems to be any of them.  I wonder how
hard it is to switch to that other driver.  From the wiki page, it looks
like a big deal. 

Dale

:-)  ;-)



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-20 Thread Morgan Wesström

On 2023-04-21 00:36, Dale wrote:

/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/temp/environment:
line 1291:
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
No such file or directory

Any thoughts?  Ideas?



I couldn't reproduce the error here. One thing that comes to mind is that your 
system might have an error in its repository configuration. 
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files is a symlink and 
should point to your main repository, normally 
/var/db/repos/gentoo/x11-drivers/nvidia-drivers/files. When the emerge fails, 
can you check what that symlink actually points to and if this is where your 
repository is stored? What is the output of emerge --info? (Repository info is 
in that output).

/Morgan



Re: [gentoo-user] Nvidia-drivers fails to patch

2023-04-20 Thread Mark Knecht
On Thu, Apr 20, 2023 at 3:36 PM Dale  wrote:

>  *   patch -p1  failed with
>
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch


You know I don't run Gentoo, right?

That looks weird to me - building 470.182.03 but patching it with
470.141.03.
Just looks weird...

I think the other day someone - maybe Thelma? - had a problem
where there was something left over in some 'patch' directory.
Possibly you have something like that going on?

You know I don't run Gentoo, right? ;-)

Cheers,
Mark


[gentoo-user] Nvidia-drivers fails to patch

2023-04-20 Thread Dale
Howdy,

I tried a while back to upgrade my kernel but nvidia didn't like it. 
Given I can do this a piece at a time, I thought I'd try again.  Kernel
compiled fine and when nvidia complained about missing options, I fixed
those and recompiled the kernel.  I finally got it happy as far as
missing kernel options goes.  Then it fails with this error. 


* Package:    x11-drivers/nvidia-drivers-470.182.03:0/470
 * Repository: mine
 * USE:    X abi_x86_64 amd64 driver elibc_glibc kernel_linux tools
userland_GNU
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
 * Determining the location of the kernel source code
 * Found kernel source directory:
 * /usr/src/linux
 * Found sources for kernel version:
 * 6.1.23-gentoo
 * Checking for suitable kernel configuration options ...
 [ ok ]
>>> Unpacking source...
>>> Unpacking NVIDIA-Linux-x86_64-470.182.03.run to
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
>>> Unpacking nvidia-installer-470.182.03.tar.bz2 to
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
>>> Unpacking nvidia-modprobe-470.182.03.tar.bz2 to
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
>>> Unpacking nvidia-persistenced-470.182.03.tar.bz2 to
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
>>> Unpacking nvidia-settings-470.182.03.tar.bz2 to
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
>>> Unpacking nvidia-xconfig-470.182.03.tar.bz2 to
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
>>> Source unpacked in
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
>>> Preparing source in
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work ...
 * Applying nvidia-drivers-470.141.03-clang15.patch ...
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/temp/environment:
line 1291:
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
No such file or directory
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/temp/environment:
line 1294:
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
No such file or directory
 [ !! ]
 * ERROR: x11-drivers/nvidia-drivers-470.182.03::mine failed (prepare
phase):
 *   patch -p1  failed with
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch
 *
 * Call stack:
 *   ebuild.sh, line  136:  Called src_prepare
 * environment, line 3731:  Called default
 *  phase-functions.sh, line  872:  Called default_src_prepare
 *  phase-functions.sh, line  948:  Called __eapi8_src_prepare
 * environment, line  468:  Called eapply '--'
'/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch'
'/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-modprobe-390.141-uvm-perms.patch'
'/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-settings-390.144-desktop.patch'
'/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-settings-390.144-no-gtk2.patch'
'/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-settings-390.144-raw-ldflags.patch'
 * environment, line 1359:  Called _eapply_patch
'/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch'
 * environment, line 1297:  Called __helpers_die 'patch -p1 
failed with
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch'
 *   isolated-functions.sh, line  112:  Called die
 * The specific snippet of code:
 *  die "$@"
 *


According to the nvidia website, I'm using the correct version.  Thing
is, it's old.  I may have to get a newer video card.  If I can correct
this error tho and it work when I reboot, it would be great.  I don't
think that driver version is in the tree anymore.  It shows it is in my
local overlay.  Given the next version of driver doesn't work with this
card, I may be stuck with current kernel version or buying a newer
card.  Do I need to switch to a different driver?  Novau or something? 

Any thoughts?  Ideas? 

Thanks. 

Dale

:-)  :-) 



[gentoo-user] nvidia-drivers update broke screen 2.

2022-11-17 Thread Dale
Howdy,

A while back during my routine upgrades, I got a update to
nvidia-drivers.  I went from nvidia-drivers-470.129.06 to
nvidia-drivers-470.141.03.  Since then, I'm having trouble getting
screen 2 to stay on.  When I turn the TV on, it disables screen 2 which
makes TV 2 not have a signal.  I enable screen 2 again but it disables
again when the TV powers back up and tries to connect.  After I do this
a few times, it eventually accepts it and stays on.  I wanted to go back
to old 129 driver version but it is no longer in the tree and when I
found a link to the ebuild on packages.gentoo.org, it doesn't like the
ebuild for some reason.  It won't let me make a manifest for it.  Also,
this happens when I turn my TVs off and lock my screen so I can go to my
weekly Doctor visit and grocery shopping trip.  When I come back and cut
everything on, this is when the trouble starts.  Once I get it running,
it runs all week without any problems at all as long as the TVs stay
on.  Also, I have 2 TVs.  Video card goes to a splitter which then goes
to both TVs. 

I don't mind putting the old version in a local overlay and running it
but if that can't happen, does anyone know of a way to force nvidia to
work?  I'm open to either option.  This is my xorg.conf file:


root@fireball / # cat /etc/X11/xorg.conf
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 470.86

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 331.13 
(buildmeister@swio-display-x86-rhel47-04)  Sun Sep 29 21:52:30 PDT 2013

Section "ServerLayout"
    Identifier "Layout0"
    Screen  0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from data in "/etc/conf.d/gpm"
    Identifier "Mouse0"
    Driver "mouse"
    Option "Protocol" "IMPS/2"
    Option "Device" "/dev/input/mice"
    Option "Emulate3Buttons" "no"
    Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier "Keyboard0"
    Driver "kbd"
EndSection

Section "Monitor"
    Identifier "Monitor0"
    VendorName "Unknown"
    ModelName  "Samsung S27E310"
    HorizSync   30.0 - 81.0
    VertRefresh 56.0 - 75.0
    Option "DPMS"
EndSection

Section "Device"
    Identifier "Device0"
    Driver "nvidia"
    VendorName "NVIDIA Corporation"
    BoardName  "NVIDIA GeForce GTX 650"
EndSection

Section "Screen"

# Removed Option "metamodes" "VGA-0: nvidia-auto-select +0+0, HDMI-0:
1280x720 +0+0; VGA-0: 1680x1050 +0+0, HDMI-0: nvidia-auto-select +0+0;
VGA-0: 1600x900 +0+0, HDMI-0: nvidia-auto-select +0+0; VGA-0: 1440x900
+0+0, HDMI-0: nvidia-auto-select +0+0; VGA-0: 1280x1024 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1280x1024_60 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1280x800 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1280x720 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1152x864 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1024x768 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1024x768_70 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1024x768_60 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 800x600 +0+0, HDMI-0: nvidia-auto-select
+0+0; VGA-0: 800x600_72 +0+0, HDMI-0: nvidia-auto-select +0+0; VGA-0:
800x600_60 +0+0, HDMI-0: nvidia-auto-select +0+0; VGA-0: 800x600_56
+0+0, HDMI-0: nvidia-auto-select +0+0"
# Removed Option "metamodes" "VGA-0: 1920x1080 +0+0, HDMI-0: 1280x720
+1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On};
VGA-0: 1680x1050 +0+0, HDMI-0: nvidia-auto-select +0+0; VGA-0: 1600x900
+0+0, HDMI-0: nvidia-auto-select +0+0; VGA-0: 1440x900 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1280x1024 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1280x1024_60 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1280x800 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1280x720 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1152x864 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1024x768 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1024x768_70 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 1024x768_60 +0+0, HDMI-0:
nvidia-auto-select +0+0; VGA-0: 800x600 +0+0, HDMI-0: nvidia-auto-select
+0+0; VGA-0: 800x600_72 +0+0, HDMI-0: nvidia-auto-select +0+0; VGA-0:
800x600_60 +0+0, HDMI-0: nvidia-auto-select +0+0"
    Identifier "Screen0"
    Device "Device0"
    Monitor    "Monitor0"
    DefaultDepth    24
    Option "Stereo" "0"
    Option "nvidiaXineramaInfoOrder" "CRT-0"
    Option "metamodes" "VGA-0: 1920x1080 +0+0, HDMI-0: 1920x1080
+1920+0; VGA-0: 1680x1050 +0+0, HDMI-0: nvidia-auto-select +0+0; VGA-0:
1600x900 +0+0, HDMI-0: nvidia-auto-select +0+0; VGA-0: 1440x900 +0+0,
HDMI-0: nvidia-auto-select +0+0; VGA-0: 1280x1024 +0+0, HDMI-0:

Re: [gentoo-user] nvidia-drivers wants static-libs, I do not.

2022-02-13 Thread Dale
Arve Barsnes wrote:
> On Sun, 13 Feb 2022 at 14:12, Dale  wrote:
>> I suspect Kicad is not used by most but removing digikam seemed to be
>> the one that opened the door to a clear path for emerge.  That package
>> is commonly used.  So, that info may help if a person runs into this.
>> I'm not sure what if any effect boost had.  It may be worth not removing
>> it unless others fail to give a clear path.
>>
>> Thanks again for the help.  I saw it but didn't realize its meaning.
>> You did.
> You shouldn't have libs in your world file anyway, it should only be
> the packages that you directly use. If packages need it, and many use
> boost, they will pull it in as needed. :)
>
> Regards,
> Arve
>
>


I noticed that boost was pulled in when doing the other updates since. 
I have -1 in my emerge defaults so at some point, I had to have a good
reason for putting it there on purpose.  Thing is, you are correct, it
shouldn't be there. 

As a update to status, it is doing a emerge @preserved-rebuild right now
but it found a clear path.  Once that is done, I plan to add the others
in my list except boost.  I'm going to scan my world file too, just in
case something else is lurking about that shouldn't be there.  We all
know that having things in there that shouldn't be there causes issues. 
How boost got there, I'm not sure. 

Thanks again.  So far, nvidia-settings is not wanting static-libs so it
seems that is fixed. 

Dale

:-)  :-) 

P. S.  I got a email that another part of KDE just got released.  Oh
yeppie.  :-D



Re: [gentoo-user] nvidia-drivers wants static-libs, I do not.

2022-02-13 Thread Arve Barsnes
On Sun, 13 Feb 2022 at 14:12, Dale  wrote:
> I suspect Kicad is not used by most but removing digikam seemed to be
> the one that opened the door to a clear path for emerge.  That package
> is commonly used.  So, that info may help if a person runs into this.
> I'm not sure what if any effect boost had.  It may be worth not removing
> it unless others fail to give a clear path.
>
> Thanks again for the help.  I saw it but didn't realize its meaning.
> You did.

You shouldn't have libs in your world file anyway, it should only be
the packages that you directly use. If packages need it, and many use
boost, they will pull it in as needed. :)

Regards,
Arve



Re: [gentoo-user] nvidia-drivers wants static-libs, I do not.

2022-02-13 Thread Dale
Arve Barsnes wrote:
> On Sun, 13 Feb 2022 at 09:43, Dale  wrote:
>> The following USE changes are necessary to proceed:
>>  (see "package.use" in the portage(5) man page for more details)
>> # required by sci-libs/vtk-9.0.3-r4::gentoo[video_cards_nvidia]
>> # required by sci-libs/opencascade-7.5.2-r5::gentoo[vtk]
>> # required by sci-electronics/kicad-5.1.12-r2::gentoo[occ]
>> # required by sci-electronics/kicad-packages3d-5.1.12-r1::gentoo
>> # required by sci-electronics/kicad-meta-5.1.12::gentoo[-minimal]
>> # required by @selected
>> # required by @world (argument)
>>> =x11-drivers/nvidia-drivers-470.103.01 static-libs
>> Would you like to add these changes to your config files? [Yes/No]
>>
>>
>> I'm not sure if the boost output is related or not.  I did read
>> somewhere that opencascade is replacing oce.  From the above, I suspect
>> vtk and/or opencascade is causing this.  That may be related but dang if
>> I can figure out a way around this.  Anyone else run into this and find
>> a fix or see something I'm missing?
> I don't know how this would impact functionality, but it looks like
> you could avoid this by setting USE on sci-libs/vtk to
> "-video_cards_nvidia". The cuda USE flag requires this, but that is
> already disabled for you.
>
> Regards,
> Arve
>
>

Oh thank you for that hint.  I thought that was coming from make.conf
that I had a nvidia video card as opposed to a ATI or something.  No
idea I could disable it since it was just a USE flag.  Changing that got
me out of the static-libs USE flag demand. 

Now I'm having issues with hdf5 and flann.  I think this is like the
harfbuzz circle people run into.  I ended up removing packages that are
not absolutely needed in order to get it to give me a clean path.  I
plan to add those packages back to the world file once this emerge is
done and see if it emerges those back without problems.  In case someone
else runs into this problem, even tho this thread wasn't exactly about
this, this is what I had to remove from the world file.


dev-libs/boost
sci-electronics/kicad-meta
media-gfx/digikam


I suspect Kicad is not used by most but removing digikam seemed to be
the one that opened the door to a clear path for emerge.  That package
is commonly used.  So, that info may help if a person runs into this. 
I'm not sure what if any effect boost had.  It may be worth not removing
it unless others fail to give a clear path.

Thanks again for the help.  I saw it but didn't realize its meaning. 
You did. 

Dale

:-)  :-) 



Re: [gentoo-user] nvidia-drivers wants static-libs, I do not.

2022-02-13 Thread Arve Barsnes
On Sun, 13 Feb 2022 at 09:43, Dale  wrote:
> The following USE changes are necessary to proceed:
>  (see "package.use" in the portage(5) man page for more details)
> # required by sci-libs/vtk-9.0.3-r4::gentoo[video_cards_nvidia]
> # required by sci-libs/opencascade-7.5.2-r5::gentoo[vtk]
> # required by sci-electronics/kicad-5.1.12-r2::gentoo[occ]
> # required by sci-electronics/kicad-packages3d-5.1.12-r1::gentoo
> # required by sci-electronics/kicad-meta-5.1.12::gentoo[-minimal]
> # required by @selected
> # required by @world (argument)
> >=x11-drivers/nvidia-drivers-470.103.01 static-libs
>
> Would you like to add these changes to your config files? [Yes/No]
>
>
> I'm not sure if the boost output is related or not.  I did read
> somewhere that opencascade is replacing oce.  From the above, I suspect
> vtk and/or opencascade is causing this.  That may be related but dang if
> I can figure out a way around this.  Anyone else run into this and find
> a fix or see something I'm missing?

I don't know how this would impact functionality, but it looks like
you could avoid this by setting USE on sci-libs/vtk to
"-video_cards_nvidia". The cuda USE flag requires this, but that is
already disabled for you.

Regards,
Arve



[gentoo-user] nvidia-drivers wants static-libs, I do not.

2022-02-13 Thread Dale
Howdy,

I recently did my weekly updates.  It wanted nvidia-drivers to have the
static-libs USE flag enabled so I did it.  Then the video card wouldn't
work when I logged out and back in because of a mismatch somewhere so I
disabled static-libs and emerged it again.  That fixed the problem of no
GUI.  Now I'm trying to finish the upgrade and get a clean output. 
However, it seems a package, vtk and/or opencascade, demands the
static-libs USE flag for nvidia-drivers which would again break the
display the next time I logout and back in.  So, no matter what it
wants, it can not have it.  The drivers do me no good if the result
leaves me without a GUI.  This is the best output with details I can
get.  I've tried removing packages, doing it in smaller parts but either
way, it ends up with this:



root@fireball / # emerge -auDNt world

These are the packages that would be merged:

Calculating dependencies... done!
[nomerge   ] app-crypt/veracrypt-1.24_p8::gentoo  USE="X asm -doc"
CPU_FLAGS_X86="sse2 sse4_1 ssse3"
[nomerge   ]  x11-libs/wxGTK-3.0.4-r302:3.0-gtk3::gentoo  USE="X
gstreamer libnotify opengl sdl tiff -debug -doc -webkit" ABI_X86="(64)
-32 (-x32)"
[nomerge   ]   x11-libs/libnotify-0.7.9-r1::gentoo 
USE="introspection -gtk-doc -test" ABI_X86="(64) -32 (-x32)"
[nomerge   ]    virtual/notification-daemon-0::gentoo  USE="kde -gnome"
[nomerge   ] kde-plasma/plasma-workspace-5.24.0-r1:5::gentoo 
USE="calendar fontconfig handbook (policykit) -appstream -debug
-geolocation -gps -screencast -semantic-desktop -telemetry -test"
[nomerge   ]  media-libs/phonon-4.11.1-r1::gentoo  USE="vlc
-debug -designer -gstreamer -pulseaudio"
[nomerge   ]   media-libs/phonon-vlc-0.11.3-r1::gentoo 
USE="-debug"
[nomerge   ]    media-video/vlc-3.0.16-r7:0/5-9::gentoo  USE="X
a52 alsa bidi bluray cddb dbus dvbpsi dvd encode ffmpeg flac fontconfig
gcrypt jpeg libnotify libsamplerate mad mp3 mpeg ncurses ogg png qt5 ssl
svg truetype udev x264 x265 xml zeroconf -aom -archive -aribsub
-chromaprint -chromecast -dav1d -dc1394 -debug (-directx) -dts -faad
-fdk -fluidsynth -gme -gnome-keyring -gstreamer -ieee1394 -jack -kate
-libass -libcaca -libtar -libtiger -linsys -lirc -live -lua
-macosx-notifications -matroska -modplug -mtp -musepack -nfs -omxil
-optimisememory -opus -projectm -pulseaudio -rdp -run-as-root -samba
-sdl-image -sftp -shout -sid -skins -soxr -speex -srt -taglib -test
-theora -tremor -twolame -upnp -v4l -vaapi -vdpau -vnc -vpx -wayland
-zvbi" CPU_FLAGS_X86="mmx sse" LUA_SINGLE_TARGET="lua5-1"
[nomerge   ] media-video/ffmpeg-4.4.1-r1:0/56.58.58::poly-c 
USE="X alsa bluray bzip2 dav1d encode fdk fontconfig frei0r gnutls gpl
iconv jpeg2k lzma mp3 network opengl openh264 postproc sdl svg theora
threads truetype vorbis vpx x264 x265 xvid zlib -amr -amrenc (-appkit)
-bs2b -cdio -chromaprint -chromium -codec2 -cpudetection -cuda -debug
-doc -flite -fribidi -gcrypt -gme -gmp -gsm -hardcoded-tables -iec61883
-ieee1394 -jack -kvazaar -ladspa -libaom -libaribb24 -libass -libcaca
-libdrm -libilbc -librtmp -libsoxr -libtesseract -libv4l -libxml2 -lv2
(-mipsdspr1) (-mipsdspr2) (-mipsfpu) (-mmal) -modplug -openal -opencl
-openssl -opus -oss -pic -pulseaudio -rav1e -rubberband -samba -snappy
-sndio -speex -srt -ssh -static-libs -svt-av1 -test -twolame -v4l -vaapi
-vdpau -vidstab -vulkan -webp -zeromq -zimg -zvbi" ABI_X86="(64) -32
(-x32)" CPU_FLAGS_X86="aes avx fma3 fma4 mmx mmxext sse sse2 sse3 sse4_1
sse4_2 ssse3 xop -3dnow -3dnowext -avx2" FFTOOLS="aviocat cws2fws
ffescape ffeval ffhash fourcc2pixfmt graph2dot ismindex pktdumper
qt-faststart sidxindex trasher" VIDEO_CARDS="nvidia"
[nomerge   ]  media-libs/nv-codec-headers-11.1.5.0::gentoo 
ABI_X86="(64) -32 (-x32)"
[ebuild   R    ]  
x11-drivers/nvidia-drivers-470.103.01:0/470::gentoo  USE="X driver
static-libs* tools -dist-kernel -persistenced -wayland" ABI_X86="(64)
-32" 0 KiB
[nomerge   ]  app-admin/sudo-1.9.8_p2::gentoo  USE="nls offensive
pam sasl secure-path sendmail ssl -gcrypt -ldap (-selinux) -skey -sssd"
[nomerge   ]   dev-libs/cyrus-sasl-2.1.27-r6:2::gentoo  USE="gdbm
java mysql pam sqlite ssl -authdaemond -berkdb -kerberos -ldapdb
-openldap -postgres -sample (-selinux) -srp -static-libs -urandom"
ABI_X86="(64) -32 (-x32)"
[nomerge   ]    virtual/jdk-1.8.0-r6:1.8::gentoo  USE="-headless-awt"
[ebuild U  ] dev-java/openjdk-bin-8.322_p06:8::gentoo
[8.312_p07:8::gentoo] USE="alsa cups -examples -headless-awt (-selinux)
-source" 100,649 KiB
[nomerge   ] media-gfx/digikam-7.5.0:5::gentoo  USE="X gphoto2 heif
imagemagick lensfun mysql opengl openmp panorama scanner -addressbook
-calendar -debug -marble -mediaplayer -semantic-desktop"
[ebuild  N ]  media-gfx/hugin-2020.0.0-r1::gentoo  USE="sift -debug
-lapack -python -raw" L10N="-ca -ca-valencia -cs -da -de -en-GB -es -eu
-fi -fr -hu -it -ja -nl -pl -pt-BR -ro -ru -sk -sv -zh-CN -zh-TW"
PYTHON_SINGLE_TARGET="python3_9 

Re: [gentoo-user] nvidia-drivers-440.82-r3 failing to compile: Kernel configuration is invalid

2020-05-22 Thread Ján Zahornadský



On 21/05/2020 20:25, Ashley Dixon wrote:

On Thu, May 21, 2020 at 08:13:38PM +0100, Ján Zahornadský wrote:

when updating the system today, a new revision of nvidia-drivers ebuild
fails with

ERROR: Kernel configuration is invalid.
include/generated/autoconf.h or include/config/auto.conf are missing.
Run 'make oldconfig && make prepare' on kernel src to fix it.

(full log attached as build.log)

I'm fairly sure my kernel sources and configuration are in place:

bolt /usr/src/linux-5.6.14-gentoo # ls -l include/generated/autoconf.h
include/config/auto.conf
-rw--- 1 root root 26144 May 21 10:13 include/config/auto.conf
-rw--- 1 root root 35329 May 21 10:13 include/generated/autoconf.h


Try executing `chmod a+r ` on both of those files.



Yes, thanks, it was a permission issue after all, re-setting umask and 
re-running make mrproper && make && make modules_install fixed it!


All the best,
Jan



Re: [gentoo-user] nvidia-drivers-440.82-r3 failing to compile: Kernel configuration is invalid

2020-05-21 Thread Ján Zahornadský

On 21/05/2020 20:25, Ashley Dixon wrote:

On Thu, May 21, 2020 at 08:13:38PM +0100, Ján Zahornadský wrote:

when updating the system today, a new revision of nvidia-drivers ebuild
fails with

ERROR: Kernel configuration is invalid.
include/generated/autoconf.h or include/config/auto.conf are missing.
Run 'make oldconfig && make prepare' on kernel src to fix it.

(full log attached as build.log)

I'm fairly sure my kernel sources and configuration are in place:

bolt /usr/src/linux-5.6.14-gentoo # ls -l include/generated/autoconf.h
include/config/auto.conf
-rw--- 1 root root 26144 May 21 10:13 include/config/auto.conf
-rw--- 1 root root 35329 May 21 10:13 include/generated/autoconf.h


Try executing `chmod a+r ` on both of those files.



That sadly didn't help :-(

> Is  /usr/src/linux a symlink to  /usr/src/linux-5.6.14-gentoo ? The
> nvidia-drivers package looks for the kernel sources in /usr/src/linux
> so if the symlink is wrong then you might get errors like these.

Yes, I have a symlink in /usr/src:

bolt ~ # ls -l /usr/src/
total 8
lrwxrwxrwx  1 root root   19 May 21 10:12 linux -> linux-5.6.14-gentoo
drwxr-xr-x 25 root root 4096 May 20 22:03 linux-5.6.13-gentoo
drwxr-xr-x 25 root root 4096 May 21 10:58 linux-5.6.14-gentoo



Re: [gentoo-user] nvidia-drivers-440.82-r3 failing to compile: Kernel configuration is invalid

2020-05-21 Thread Ashley Dixon
On Thu, May 21, 2020 at 08:13:38PM +0100, Ján Zahornadský wrote:
> when updating the system today, a new revision of nvidia-drivers ebuild
> fails with
> 
> ERROR: Kernel configuration is invalid.
>include/generated/autoconf.h or include/config/auto.conf are missing.
>Run 'make oldconfig && make prepare' on kernel src to fix it.
> 
> (full log attached as build.log)
> 
> I'm fairly sure my kernel sources and configuration are in place:
> 
> bolt /usr/src/linux-5.6.14-gentoo # ls -l include/generated/autoconf.h
> include/config/auto.conf
> -rw--- 1 root root 26144 May 21 10:13 include/config/auto.conf
> -rw--- 1 root root 35329 May 21 10:13 include/generated/autoconf.h

Try executing `chmod a+r ` on both of those files.

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA



signature.asc
Description: PGP signature


Re: [gentoo-user] nvidia-drivers-440.82-r3 failing to compile: Kernel configuration is invalid

2020-05-21 Thread Manuel McLure
On Thu, May 21, 2020 at 12:14 PM Ján Zahornadský  wrote:

>
> bolt /usr/src/linux-5.6.14-gentoo # ls -l include/generated/autoconf.h
> include/config/auto.conf
> -rw--- 1 root root 26144 May 21 10:13 include/config/auto.conf
> -rw--- 1 root root 35329 May 21 10:13 include/generated/autoconf.h
>
>
Is  /usr/src/linux a symlink to  /usr/src/linux-5.6.14-gentoo ? The
nvidia-drivers package looks for the kernel sources in /usr/src/linux so if
the symlink is wrong then you might get errors like these.

-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft


Re: [gentoo-user] nvidia-drivers-396.24-r1

2018-07-15 Thread Philip Webb
180709 Davyd McColl wrote:
> 180610 Philip Webb wrote:
>> I updated to the latest stable Nvidia-drivers-396.24-r1 ,
>> rebooted & 'startx' :
>> the result was an X error "No devices detected ... no screens found".
>> I updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above
>> with the same result ; downgrading to 390.67 got X working again.
> I have exactly the same kernel (4.14.52-gentoo) and nvidia-drivers 
> (396.24-r1) and I don't experience this issue
> Perhaps this is specific to the card ? I have a 660ti.

I have ASUS GT610 , which is supported by Nvidia 396.18 :
https://www.geforce.com/drivers/results/133571 .
NB they say '18' is beta & don't list '24' at all :
I'm not sure why it's marked stable by Gentoo.

> Have you checked that the nvidia module is even being loaded :
> 'lsmod | grep nvidia' ?

No problem loading the '390' driver : why would the '396' be different ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca




Re: [gentoo-user] nvidia-drivers-396.24-r1

2018-07-08 Thread Davyd McColl
I have exactly the same kernel (4.14.52-gentoo) and nvidia-drivers 
(396.24-r1) and I don't experience this issue (though games requiring 
Vulkan crash out sporadically - there's an ongoing issue on the nvidia 
forums for this, where apparently it's already been fixed in some ancient 
fork, and not merged back).

Perhaps this is specific to the card? I have a 660ti.

Have you checked that the nvidia module is even being loaded (lsmod | grep 
nvidia)?


-d


On July 9, 2018 00:46:34 Philip Webb  wrote:


180610 Philip Webb wrote:

I updated to the latest stable Nvidia-drivers-396.24-r1 ,
rebooted & 'startx' :
the result was an X error "No devices detected ... no screens found".
Downgrading to 390.48 got X working again.
Nothing to see on the Forum or among Gentoo 'nvidia' bugs.
My kernel is 4.9.16-gentoo.


I've updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above
with the same result ; downgrading to 390.67 got X working again.

Has anyone else experienced this problem or similar ?
Does anyone have advice ?

--
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca








Re: [gentoo-user] nvidia-drivers-396.24-r1

2018-07-08 Thread Jack

On 2018.07.08 18:46, Philip Webb wrote:

180610 Philip Webb wrote:
> I updated to the latest stable Nvidia-drivers-396.24-r1 ,
> rebooted & 'startx' :
> the result was an X error "No devices detected ... no screens  
found".

> Downgrading to 390.48 got X working again.
> Nothing to see on the Forum or among Gentoo 'nvidia' bugs.
> My kernel is 4.9.16-gentoo.

I've updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above
with the same result ; downgrading to 390.67 got X working again.

Has anyone else experienced this problem or similar ?
Does anyone have advice ?


Check the xorg log.  New(er) nvidia-drivers often take a bit of time to  
get upgraded to handle the most recent kernels.  There is likely a more  
concrete (if no less helpful) message in the xorg log.  You may need to  
stick to an older driver and/or kernel until one of them catches up  
with the other.  (I no longer have an nvidia card in my Gentoo box, so  
I have no current specifics, but even when I did, it was legacy 340.xx.


Jack


Re: [gentoo-user] nvidia-drivers-396.24-r1

2018-07-08 Thread Philip Webb
180610 Philip Webb wrote:
> I updated to the latest stable Nvidia-drivers-396.24-r1 ,
> rebooted & 'startx' :
> the result was an X error "No devices detected ... no screens found".
> Downgrading to 390.48 got X working again.
> Nothing to see on the Forum or among Gentoo 'nvidia' bugs.
> My kernel is 4.9.16-gentoo.

I've updated to kernel 4.14.52-gentoo & tried Nvidia-drivers as above
with the same result ; downgrading to 390.67 got X working again.

Has anyone else experienced this problem or similar ?
Does anyone have advice ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca




Re: [gentoo-user] nvidia-drivers-396.24-r1

2018-06-10 Thread T ed Ozolins

On 18-06-09 10:22 PM, Philip Webb wrote:

I updated to the latest stable Nvidia-drivers-396.24-r1 ,
rebooted & 'startx' :
the result was an X error "No devices detected ... no screens found".
Downgrading to 390.48 got X working again.
Nothing to see on the Forum or among Gentoo 'nvidia' bugs.
My kernel is 4.9.16-gentoo.

Has anyone else run into this ?  Any other advice or comments ?


Last time that happened here, I ended up buying a newer nvidia card.

--
Ted Ozolins
Cranbrook, BC




[gentoo-user] nvidia-drivers-396.24-r1

2018-06-09 Thread Philip Webb
I updated to the latest stable Nvidia-drivers-396.24-r1 ,
rebooted & 'startx' :
the result was an X error "No devices detected ... no screens found".
Downgrading to 390.48 got X working again.
Nothing to see on the Forum or among Gentoo 'nvidia' bugs.
My kernel is 4.9.16-gentoo.

Has anyone else run into this ?  Any other advice or comments ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca




Re: [gentoo-user] Nvidia-drivers,

2018-03-18 Thread Jigme Datse Yli-Rasku
Some time around when Spectre/Meltdown were announced, I started
experiencing similar problems.  I don't know "what's wrong" because so
far I have found no answers.

The best I can offer at this point is that on my system, it seems that
it will work with Nouveau drivers much better than the system currently
works with NVIDIA drivers.

Unfortunately, I haven't managed to get a working version of that yet,
but I usually only manage to put a few hours a week on trying to figure
it out.

I fortunately haven't had the problem that I have to kill power to the
computer, though I think I have gone through some times I have needed to
reboot, rather than just get back into X either through killing
processes, or (very rarely) stopping one problematic process which is
the source.

On 03/18/2018 09:40 AM, Alan Grimes wrote:
> Gentlemen, we have a problem...
> 
> Okay, ~ a week ago there was a power outage at my place, everything goes
> down for a day or two. I had recently refreshed my UPS batteries, so I
> had a chance to put that into the circuit, no biggy.
> 
> Since nobody will offer me a job, I was playing Kerbal space program yet
> again. (not even Don Corleone could get me a job at this point, I
> frequently joke about the horse head trick but, seriously, I don't think
> even that would work...)
> 
> So, after all of two and a half days of uptime, nvidia drivers takes
> x'-doze down.
> 
> I was like "Ok, fine, I'll do a maintenance cycle on my machine and all
> will be good..."
> 
> So I update the bios, update the kernel, update portage, flush a few
> dead packages down the memory hole... Ok, my system was in shape again...
> 
> So, I'm back in kerbal, another day or two goes by, I'm sitting there
> trying to figure out whether I have enough room in my departure corridor
> to slot in a contract mission to Jool.. I wasn't even sitting down, just
> poking around in my kitchen. When I got back, the game was frozen. I had
> to log in with my PoS laptop which is useful only for this task. I found
> that KSP, and X'doze were live-locked, presumably on a Nvidia-drivers
> bug. =( I tried killing off KSP but it ended up going zombie... I tried
> killing off parent processes, no luck, I then tried shutting down the
> machine the normal way, no good. I eventually ended up going to the
> dusty 28 year old power commander thing and throwing the big orange
> switch labelled COMPUTER (complete and instantaneous removal of power).
> 
> What's going on here? Nvidia drivers have been stable for years...
> what's the deal? =\
> 
> 



signature.asc
Description: OpenPGP digital signature


[gentoo-user] Nvidia-drivers,

2018-03-18 Thread Alan Grimes
Gentlemen, we have a problem...

Okay, ~ a week ago there was a power outage at my place, everything goes
down for a day or two. I had recently refreshed my UPS batteries, so I
had a chance to put that into the circuit, no biggy.

Since nobody will offer me a job, I was playing Kerbal space program yet
again. (not even Don Corleone could get me a job at this point, I
frequently joke about the horse head trick but, seriously, I don't think
even that would work...)

So, after all of two and a half days of uptime, nvidia drivers takes
x'-doze down.

I was like "Ok, fine, I'll do a maintenance cycle on my machine and all
will be good..."

So I update the bios, update the kernel, update portage, flush a few
dead packages down the memory hole... Ok, my system was in shape again...

So, I'm back in kerbal, another day or two goes by, I'm sitting there
trying to figure out whether I have enough room in my departure corridor
to slot in a contract mission to Jool.. I wasn't even sitting down, just
poking around in my kitchen. When I got back, the game was frozen. I had
to log in with my PoS laptop which is useful only for this task. I found
that KSP, and X'doze were live-locked, presumably on a Nvidia-drivers
bug. =( I tried killing off KSP but it ended up going zombie... I tried
killing off parent processes, no luck, I then tried shutting down the
machine the normal way, no good. I eventually ended up going to the
dusty 28 year old power commander thing and throwing the big orange
switch labelled COMPUTER (complete and instantaneous removal of power).

What's going on here? Nvidia drivers have been stable for years...
what's the deal? =\


-- 
Please report bounces from this address to a...@numentics.com

Powers are not rights.




Re: [gentoo-user] Nvidia Drivers. =(

2017-04-05 Thread Andreas K. Huettel
Am Mittwoch, 5. April 2017, 18:53:43 CEST schrieb Alan Grimes:
> I hit the "view raw" link and used save as... I then copied it into the
> "files" subdirectoy and portage threw a hissy fit 

Please re-read the instructions in Fabio's mail.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Nvidia Drivers. =(

2017-04-05 Thread Neil Bothwick
On Wed, 05 Apr 2017 12:53:43 -0400, Alan Grimes wrote:

> I hit the "view raw" link and used save as... I then copied it into the
> "files" subdirectoy and portage threw a hissy fit and refused to do
> anything because letting the user patch a package is simply
> unthinkable!!! A mere USER, applying a custom patch to one of our
> immaculate packages on HIS OWN COMPUTER??!?!?! UNTHINKABLE!!!

Yes, just let anyone modify files in your portage tree and have portage
ignore any such changes, very secure.

> So it
> doesn't flash a warning, or a "are you sure?", it just barfs and
> quits.  I then mv ..'d it. and portage completely ignores the file. 
> Doesn't match any of the versions I have anyway.

One of the problems with top posting is it makes it much easier to reply
to an email without properly reading it. The text you quoted tells you
exactly how to apply user patches, and they don't go in the portage tree.
 
> Which gets me back to how wise I was for version-freezing myself at
> 4.6.7...
> 
> And yes, I am continuing to call my Ryzen 1800x "tortoise". =P
> 
> ###
> 
> tortoise nvidia-drivers # ls -l
> total 268
> -rw-r--r-- 1 rootroot10392 Apr  5 12:42 378.09-4.10-rc8.patch
> drwxr-xr-x 2 portage portage  4096 Apr  5 12:43 files
> -rw-r--r-- 1 portage portage 32304 Mar 30 03:29 Manifest
> -rw-r--r-- 1 portage portage  1250 Mar 30 03:27 metadata.xml
> -rw-r--r-- 1 portage portage 16490 Feb 28 14:50
> nvidia-drivers-173.14.39-r1.ebuild
> -rw-r--r-- 1 portage portage 16476 Feb 28 14:50
> nvidia-drivers-173.14.39-r2.ebuild
> -rw-r--r-- 1 portage portage 13327 Feb 28 14:50
> nvidia-drivers-304.134.ebuild
> -rw-r--r-- 1 portage portage 13412 Feb 28 14:50
> nvidia-drivers-304.134-r1.ebuild
> -rw-r--r-- 1 portage portage 13410 Mar 30 03:29
> nvidia-drivers-304.135.ebuild
> -rw-r--r-- 1 portage portage 14460 Feb 28 14:50
> nvidia-drivers-340.101.ebuild
> -rw-r--r-- 1 portage portage 14525 Feb 28 14:50
> nvidia-drivers-340.101-r1.ebuild
> -rw-r--r-- 1 portage portage 14523 Mar 30 03:29
> nvidia-drivers-340.102.ebuild
> -rw-r--r-- 1 portage portage 15425 Feb 28 14:50
> nvidia-drivers-375.26.ebuild -rw-r--r-- 1 portage portage 15613 Feb 28
> 14:50 nvidia-drivers-375.26-r3.ebuild
> -rw-r--r-- 1 portage portage 15611 Mar 30 03:29
> nvidia-drivers-375.39.ebuild -rw-r--r-- 1 portage portage 15676 Mar 30
> 03:29 nvidia-drivers-378.13.ebuild -rw-r--r-- 1 portage portage 14755
> Feb 28 14:50 nvidia-drivers-96.43.23-r1.ebuild
> tortoise nvidia-drivers #
> 
> 
> 
> 
> Fabio Scaccabarozzi wrote:
> >
> > You can drop it in /etc/portage/patches/x11-drivers/nvidia-drivers
> > folder, portage should take care of the rest when you emerge the
> > package. You should see 3 lines near the prepare phase, before the
> > configure phase, saying something like "applying user patches from...
> > Applying ...Done applying user patches"
> >
> >
> > Il mer 5 apr 2017, 17:40 Alan Grimes  > > ha scritto:
> >
> > Looks like a good patch but can you link to instructions for
> > applying this patch?
> >
> >
> > Fabio Scaccabarozzi wrote:  
> > >
> > > Hi Alan,
> > >
> > > That is expected with 4.10 kernels.
> > > You can grab a patch from my /etc/portage repository:
> > >  
> > 
> > https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch
> >   
> > >
> > > I took it from the NVidia forums, you can also find it there, I
> > > just rebased it for portage.
> > >  
> >
> >
> > --
> > Strange Game.
> > The only winning move is not to play.
> >
> > Powers are not rights.
> >
> >  
> 
> 




-- 
Neil Bothwick

NOTICE:
  --  THE ELEVATORS WILL BE OUT OF ORDER TODAY  --
  (The nearest working elevators are in the building
   across the street.)


pgpvSPvO0uqsN.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Nvidia Drivers. =(

2017-04-05 Thread Manuel McLure
On Wed, Apr 5, 2017 at 9:53 AM, Alan Grimes  wrote:

> I hit the "view raw" link and used save as... I then copied it into the
> "files" subdirectoy and portage threw a hissy fit and refused to do
> anything because letting the user patch a package is simply
> unthinkable!!! A mere USER, applying a custom patch to one of our
> immaculate packages on HIS OWN COMPUTER??!?!?! UNTHINKABLE!!! So it
> doesn't flash a warning, or a "are you sure?", it just barfs and
> quits.  I then mv ..'d it. and portage completely ignores the file.
> Doesn't match any of the versions I have anyway.
>
> Which gets me back to how wise I was for version-freezing myself at
> 4.6.7...
>
> And yes, I am continuing to call my Ryzen 1800x "tortoise". =P
>
> It looks like you put it in /usr/portage/x11-drivers/nvidia-drivers, not
in  /etc/portage/patches/x11-drivers/nvidia-drivers

>
>

-- 
Manuel A. McLure WW1FA  
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft


Re: [gentoo-user] Nvidia Drivers. =(

2017-04-05 Thread Alan Grimes
I hit the "view raw" link and used save as... I then copied it into the
"files" subdirectoy and portage threw a hissy fit and refused to do
anything because letting the user patch a package is simply
unthinkable!!! A mere USER, applying a custom patch to one of our
immaculate packages on HIS OWN COMPUTER??!?!?! UNTHINKABLE!!! So it
doesn't flash a warning, or a "are you sure?", it just barfs and
quits.  I then mv ..'d it. and portage completely ignores the file. 
Doesn't match any of the versions I have anyway.

Which gets me back to how wise I was for version-freezing myself at
4.6.7...

And yes, I am continuing to call my Ryzen 1800x "tortoise". =P

###

tortoise nvidia-drivers # ls -l
total 268
-rw-r--r-- 1 rootroot10392 Apr  5 12:42 378.09-4.10-rc8.patch
drwxr-xr-x 2 portage portage  4096 Apr  5 12:43 files
-rw-r--r-- 1 portage portage 32304 Mar 30 03:29 Manifest
-rw-r--r-- 1 portage portage  1250 Mar 30 03:27 metadata.xml
-rw-r--r-- 1 portage portage 16490 Feb 28 14:50
nvidia-drivers-173.14.39-r1.ebuild
-rw-r--r-- 1 portage portage 16476 Feb 28 14:50
nvidia-drivers-173.14.39-r2.ebuild
-rw-r--r-- 1 portage portage 13327 Feb 28 14:50
nvidia-drivers-304.134.ebuild
-rw-r--r-- 1 portage portage 13412 Feb 28 14:50
nvidia-drivers-304.134-r1.ebuild
-rw-r--r-- 1 portage portage 13410 Mar 30 03:29
nvidia-drivers-304.135.ebuild
-rw-r--r-- 1 portage portage 14460 Feb 28 14:50
nvidia-drivers-340.101.ebuild
-rw-r--r-- 1 portage portage 14525 Feb 28 14:50
nvidia-drivers-340.101-r1.ebuild
-rw-r--r-- 1 portage portage 14523 Mar 30 03:29
nvidia-drivers-340.102.ebuild
-rw-r--r-- 1 portage portage 15425 Feb 28 14:50 nvidia-drivers-375.26.ebuild
-rw-r--r-- 1 portage portage 15613 Feb 28 14:50
nvidia-drivers-375.26-r3.ebuild
-rw-r--r-- 1 portage portage 15611 Mar 30 03:29 nvidia-drivers-375.39.ebuild
-rw-r--r-- 1 portage portage 15676 Mar 30 03:29 nvidia-drivers-378.13.ebuild
-rw-r--r-- 1 portage portage 14755 Feb 28 14:50
nvidia-drivers-96.43.23-r1.ebuild
tortoise nvidia-drivers #




Fabio Scaccabarozzi wrote:
>
> You can drop it in /etc/portage/patches/x11-drivers/nvidia-drivers
> folder, portage should take care of the rest when you emerge the
> package. You should see 3 lines near the prepare phase, before the
> configure phase, saying something like "applying user patches from...
> Applying ...Done applying user patches"
>
>
> Il mer 5 apr 2017, 17:40 Alan Grimes  > ha scritto:
>
> Looks like a good patch but can you link to instructions for applying
> this patch?
>
>
> Fabio Scaccabarozzi wrote:
> >
> > Hi Alan,
> >
> > That is expected with 4.10 kernels.
> > You can grab a patch from my /etc/portage repository:
> >
> 
> https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch
> >
> > I took it from the NVidia forums, you can also find it there, I just
> > rebased it for portage.
> >
>
>
> --
> Strange Game.
> The only winning move is not to play.
>
> Powers are not rights.
>
>


-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.




Re: [gentoo-user] Nvidia Drivers. =(

2017-04-05 Thread Fabio Scaccabarozzi
You can drop it in /etc/portage/patches/x11-drivers/nvidia-drivers folder,
portage should take care of the rest when you emerge the package. You
should see 3 lines near the prepare phase, before the configure phase,
saying something like "applying user patches from... Applying
...Done applying user patches"

Il mer 5 apr 2017, 17:40 Alan Grimes  ha scritto:

> Looks like a good patch but can you link to instructions for applying
> this patch?
>
>
> Fabio Scaccabarozzi wrote:
> >
> > Hi Alan,
> >
> > That is expected with 4.10 kernels.
> > You can grab a patch from my /etc/portage repository:
> >
> https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch
> >
> > I took it from the NVidia forums, you can also find it there, I just
> > rebased it for portage.
> >
>
>
> --
> Strange Game.
> The only winning move is not to play.
>
> Powers are not rights.
>
>
>


Re: [gentoo-user] Nvidia Drivers. =(

2017-04-05 Thread Alan Grimes
Looks like a good patch but can you link to instructions for applying
this patch?


Fabio Scaccabarozzi wrote:
>
> Hi Alan,
>
> That is expected with 4.10 kernels.
> You can grab a patch from my /etc/portage repository:
> https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch
>
> I took it from the NVidia forums, you can also find it there, I just
> rebased it for portage.
>


-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.




Re: [gentoo-user] Nvidia Drivers. =(

2017-04-05 Thread Fabio Scaccabarozzi
Hi Alan,

That is expected with 4.10 kernels.
You can grab a patch from my /etc/portage repository:
https://github.com/fsvm88/gentoo-portage_etc/blob/master/patches/x11-drivers/nvidia-drivers/378.09-4.10-rc8.patch

I took it from the NVidia forums, you can also find it there, I just
rebased it for portage.

Il mer 5 apr 2017, 16:19 Alan Grimes  ha scritto:

> I'm still running on my old kernel as I re-build my system, Nvidia
> drivers just barfed
>
> ###
> tortoise src # ls -l
> total 12
> lrwxrwxrwx  1 root root   13 Apr  5 09:50 linux -> linux-4.10.8/
> drwxr-xr-x 25 root root 4096 Apr  5 10:01 linux-4.10.8
> drwxrwxr-x 25 root root 4096 Apr  4 22:34 linux-4.6.7
> drwxr-xr-x  7 root root 4096 Nov 23  2014 rpm
> tortoise src #
> ###
>
>
> x86_64-pc-linux-gnu-gcc
>
> -Wp,-MD,/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/.nv-pat.o.d
> -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include
> -I/usr/src/linux-4.10.8/arch/x86/include
> -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated
> -I/usr/src/linux-4.10.8/include -I./include
> -I/usr/src/linux-4.10.8/arch/x86/include/uapi
> -I/usr/src/linux-4.10.8/include/uapi -I./include/generated/uapi -include
> /usr/src/linux-4.10.8/include/linux/kconfig.h
>
> -I/usr/src/linux-4.10.8//var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel
> -I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel
> -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
> -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
> -Wno-format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2
> -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387
> -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup
> -march=k8 -mno-red-zone -mcmodel=kernel -funit-at-a-time
> -maccumulate-outgoing-args -DCONFIG_AS_CFI=1
> -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
> -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
> -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1
> -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare
> -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -O2
> --param=allow-store-data-races=0 -Wframe-larger-than=2048
> -fno-stack-protector -Wno-unused-but-set-variable
> -fno-omit-frame-pointer -fno-optimize-sibling-calls
> -fno-var-tracking-assignments -fno-inline-functions-called-once
> -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
> -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes
> -Werror=date-time -Werror=incompatible-pointer-types -DCC_HAVE_ASM_GOTO
> -I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/common/inc
> -I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel -Wall
> -MD -Wsign-compare -Wno-cast-qual -Wno-error -D__KERNEL__ -DMODULE
> -DNVRM -DNV_VERSION_STRING=\"378.13\" -Wno-unused-function
> -Wuninitialized -fno-strict-aliasing -mno-red-zone -mcmodel=kernel
> -DNV_UVM_ENABLE -Wno-sign-compare -Wno-format-extra-args -Werror=undef
> -I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia
> -DNV_BUILD_MODULE_INSTANCES=0 -UDEBUG -U_DEBUG -DNDEBUG  -DMODULE
> -DKBUILD_BASENAME='"nv_pat"'  -DKBUILD_MODNAME='"nvidia"' -c -o
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.o
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:
> In function ‘nvidia_cpu_callback’:
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:213:14:
> error: ‘CPU_DOWN_FAILED’ undeclared (first use in this function)
>  case CPU_DOWN_FAILED:
>   ^
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:213:14:
> note: each undeclared identifier is reported only once for each function
> it appears in
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:220:14:
> error: ‘CPU_DOWN_PREPARE’ undeclared (first use in this function)
>  case CPU_DOWN_PREPARE:
>   ^
> In file included from
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:15:0:
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:
> In function ‘nv_init_pat_support’:
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/common/inc/nv-linux.h:391:34:
> error: implicit declaration of function ‘register_cpu_notifier’
> [-Werror=implicit-function-declaration]
>  #define register_hotcpu_notifier register_cpu_notifier
>   ^
>
> /var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:258:17:
> note: in expansion of macro ‘register_hotcpu_notifier’
>  if (register_hotcpu_notifier(_hotcpu_nfb) != 0)
>  

[gentoo-user] Nvidia Drivers. =(

2017-04-05 Thread Alan Grimes
I'm still running on my old kernel as I re-build my system, Nvidia
drivers just barfed

###
tortoise src # ls -l
total 12
lrwxrwxrwx  1 root root   13 Apr  5 09:50 linux -> linux-4.10.8/
drwxr-xr-x 25 root root 4096 Apr  5 10:01 linux-4.10.8
drwxrwxr-x 25 root root 4096 Apr  4 22:34 linux-4.6.7
drwxr-xr-x  7 root root 4096 Nov 23  2014 rpm
tortoise src #
###


x86_64-pc-linux-gnu-gcc
-Wp,-MD,/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/.nv-pat.o.d
 
-nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include
-I/usr/src/linux-4.10.8/arch/x86/include
-I./arch/x86/include/generated/uapi -I./arch/x86/include/generated 
-I/usr/src/linux-4.10.8/include -I./include
-I/usr/src/linux-4.10.8/arch/x86/include/uapi
-I/usr/src/linux-4.10.8/include/uapi -I./include/generated/uapi -include
/usr/src/linux-4.10.8/include/linux/kconfig.h
-I/usr/src/linux-4.10.8//var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel
-I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2
-mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387
-mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup
-march=k8 -mno-red-zone -mcmodel=kernel -funit-at-a-time
-maccumulate-outgoing-args -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1
-DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -O2
--param=allow-store-data-races=0 -Wframe-larger-than=2048
-fno-stack-protector -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -fno-inline-functions-called-once
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -Werror=implicit-int -Werror=strict-prototypes
-Werror=date-time -Werror=incompatible-pointer-types -DCC_HAVE_ASM_GOTO 
-I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/common/inc 
-I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel -Wall
-MD -Wsign-compare -Wno-cast-qual -Wno-error -D__KERNEL__ -DMODULE
-DNVRM -DNV_VERSION_STRING=\"378.13\" -Wno-unused-function
-Wuninitialized -fno-strict-aliasing -mno-red-zone -mcmodel=kernel
-DNV_UVM_ENABLE -Wno-sign-compare -Wno-format-extra-args -Werror=undef 
-I/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia
-DNV_BUILD_MODULE_INSTANCES=0 -UDEBUG -U_DEBUG -DNDEBUG  -DMODULE 
-DKBUILD_BASENAME='"nv_pat"'  -DKBUILD_MODNAME='"nvidia"' -c -o
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.o
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:
In function ‘nvidia_cpu_callback’:
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:213:14:
error: ‘CPU_DOWN_FAILED’ undeclared (first use in this function)
 case CPU_DOWN_FAILED:
  ^
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:213:14:
note: each undeclared identifier is reported only once for each function
it appears in
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:220:14:
error: ‘CPU_DOWN_PREPARE’ undeclared (first use in this function)
 case CPU_DOWN_PREPARE:
  ^
In file included from
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:15:0:
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:
In function ‘nv_init_pat_support’:
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/common/inc/nv-linux.h:391:34:
error: implicit declaration of function ‘register_cpu_notifier’
[-Werror=implicit-function-declaration]
 #define register_hotcpu_notifier register_cpu_notifier
  ^
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:258:17:
note: in expansion of macro ‘register_hotcpu_notifier’
 if (register_hotcpu_notifier(_hotcpu_nfb) != 0)
 ^
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:
In function ‘nv_teardown_pat_support’:
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/common/inc/nv-linux.h:388:36:
error: implicit declaration of function ‘unregister_cpu_notifier’
[-Werror=implicit-function-declaration]
 #define unregister_hotcpu_notifier unregister_cpu_notifier
^
/var/tmp/portage/x11-drivers/nvidia-drivers-378.13/work/kernel/nvidia/nv-pat.c:283:9:
note: in expansion of macro 

[gentoo-user] nvidia-drivers on x64 system triggers a lot of x32 rebuilds

2017-01-24 Thread Raffaele Belardi
This was discussed on the forum but I did not see it here: recent nvidia-drivers update on 
~amd64 require tens of new abi_x86_32 use flag additions for all kinds of packages.


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

The suggested workaround (build nvidia-drivers with -tools) worked for me.

raffaele



Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-08-06 Thread David Haller
Hello Meino,

On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:
[..]
>WHOW! Thanks a lot for the patch!

As this issue has just come up on gentoo-dev as well, has the patch
worked for you (so far)? Please give a report if it worked or not.

I've been unable to run/test my system with that patch for longer to
really have an opinion (no idea when that code actually gets called
while running the driver).

TIA,
-dnh

-- 
Ugga Ugga ! Nognog! Dadadadada! [Woko° in dag°]



Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-31 Thread David Haller
Hello,

On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:
>David Haller  [16-07-30 13:24]:
[..]
>> I've got it working with the attached patch in
>> /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/
[..]
>Short qyestion: How can I apply it...I mean...as soon as I do an
>emerge, either the original source will be unpacked or my package
>will be rejected for being modified an different from the one, which
>does not compile...

In this case: just create the dir

mkdir -p /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/

and save the patch there. The rest works "as if by magic" thanks to
the epatch-user in the ebuild. The version in the directory-name makes
it only get applied to that version of the driver.

HTH,
-dnh

-- 
  If you fall and break your legs, don't come running to me.
-- Samuel Goldwyn



Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-30 Thread Meino . Cramer
james  [16-07-30 20:52]:
> On 07/30/2016 01:15 PM, meino.cra...@gmx.de wrote:
> 
> >>>Short qyestion: How can I apply it...I mean...as soon as I do an
> >>>emerge, either the original source will be unpacked or my package
> >>>will be rejected for being modified an different from the one, which
> >>>does not compile...
> 
> >>http://tinyurl.com/jur3t8v
> 
> >Meino
> 
> I think that is true for EAPI-5. EAPI-6 or later ebuilds should only 
> require the patch be located in the dir with the sources 
> (/usr/portage  or /usr/local/portage/, I think.
> (epatch-users is good to google on. There might be a bit more to it, 
> but just google. Also, there are some eclasses that help this out a bit 
> for more complicated hacks. [1]
> 
> 1] https://devmanual.gentoo.org/eclass-reference/
> 
> 
> Usually, the best thing to do is put (your) patches and a full copy of 
> the ebuild into /usr/local/portage, for a guy like you who is hacking
> at ebuilds for embedded  boards anyway.
> 
> 
> proxy-maint folks are the best to answer these question and help you,
> cause there are always twists and bumps along the way, like 
> dependencies slightly changed and thus requiring a tweak. Unfortunately 
> they are only available on the irc channel.  Hopefully on of the devs 
> will clear this up even further, as last time I looked, this is a 
> subject that the devManual has not fully documented, or anyone compiled 
> a few examples for user to look at. It's a moving target depending on 
> the EAPI-level of the ebuild.
> 
> 
> hth,
> James
> 
> 
Hi James,

thanks for your help ! :)
Will check that... ;)

Best regards,
Meino





Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-30 Thread james

On 07/30/2016 01:15 PM, meino.cra...@gmx.de wrote:


Short qyestion: How can I apply it...I mean...as soon as I do an
emerge, either the original source will be unpacked or my package
will be rejected for being modified an different from the one, which
does not compile...



http://tinyurl.com/jur3t8v



Meino


I think that is true for EAPI-5. EAPI-6 or later ebuilds should only 
require the patch be located in the dir with the sources 
(/usr/portage  or /usr/local/portage/, I think.
(epatch-users is good to google on. There might be a bit more to it, but 
just google. Also, there are some eclasses that help this out a bit for 
more complicated hacks. [1]


1] https://devmanual.gentoo.org/eclass-reference/


Usually, the best thing to do is put (your) patches and a full copy of 
the ebuild into /usr/local/portage, for a guy like you who is hacking

at ebuilds for embedded  boards anyway.


proxy-maint folks are the best to answer these question and help you,
cause there are always twists and bumps along the way, like dependencies 
slightly changed and thus requiring a tweak. Unfortunately they are only 
available on the irc channel.  Hopefully on of the devs will clear this 
up even further, as last time I looked, this is a subject that the 
devManual has not fully documented, or anyone compiled a few examples 
for user to look at. It's a moving target depending on the EAPI-level of 
the ebuild.



hth,
James




Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-30 Thread Meino . Cramer
Andrew Lowe  [16-07-30 20:12]:
> On 31/07/2016 1:54 AM, meino.cra...@gmx.de wrote:
> >David Haller  [16-07-30 13:24]:
> >>Hello,
> >>
> >>On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:
> >>>trying the new kernel linux-4.7 (vanilla, downloaded from
> 
> [snip]
> 
> >
> >Short qyestion: How can I apply it...I mean...as soon as I do an
> >emerge, either the original source will be unpacked or my package
> >will be rejected for being modified an different from the one, which
> >does not compile...
> >
> >?
> >
> >Best regards,
> >Meino
> 
>   It's currently 2am Perth time and I've been staring at a screen for 
> too long trying to get a portable Win32 dev environmet for Uni students 
> working. I've consumed a fair amount of chocolate so the usual grain of 
> salt proviso applies. If I've understood the question correctly, this 
> link may be of help:
> 
> http://tinyurl.com/jur3t8v
> 
>   Andrew
> 
> 

Hi Andrew,

:)

Thanks a lot for your help!
Best
Meino




Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-30 Thread Andrew Lowe

On 31/07/2016 1:54 AM, meino.cra...@gmx.de wrote:

David Haller  [16-07-30 13:24]:

Hello,

On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:

trying the new kernel linux-4.7 (vanilla, downloaded from


[snip]



Short qyestion: How can I apply it...I mean...as soon as I do an
emerge, either the original source will be unpacked or my package
will be rejected for being modified an different from the one, which
does not compile...

?

Best regards,
Meino


	It's currently 2am Perth time and I've been staring at a screen for too 
long trying to get a portable Win32 dev environmet for Uni students 
working. I've consumed a fair amount of chocolate so the usual grain of 
salt proviso applies. If I've understood the question correctly, this 
link may be of help:


http://tinyurl.com/jur3t8v

Andrew




Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-30 Thread Meino . Cramer
David Haller  [16-07-30 13:24]:
> Hello,
> 
> On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:
> >trying the new kernel linux-4.7 (vanilla, downloaded from
> >ftp.kernel.org) with nvidia drivers 
> >(Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
> >multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
> >-wayland KERNEL="linux -FreeBSD")).
> >The kernel compiled fine, the nvidia-drivers does not.
> >
> >Anuone else with the same problem (read: This has to be
> >fixed by nvidia/Linus) or am I the only one (so it is
> >my problem...which does not neccessarily imply that I
> >know how to fix that ... ;) ???
> 
> I've got it working with the attached patch in
> /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/
> 
> I've no idea though, if I hit that codepath yet. Should work though,
> as the patch makes the module use the kernel function and what I read
> about radix_tree_gang_lookup() it should be ok this way.
> 
> But do not expect anything to work ;)
> 
> I'm courious what the official patch will be ;) The first part
> (patching kernel/nvidia-drm/nvidia-drm-{fb,gem}.c) I've found online.
> 
> HTH,
> -dnh
> 
> -- 
> Please do not think so much about licenses, it will just make your head
> explode if not carefully studied over the years ;)
>   -- Marcus Meissner

Content-Description: 
/etc/portage/patches/x11-drivers/nvidia-drivers-367.35/nvidia-drivers-367.35-kernel-4.7.0.patch
> diff -purN a/kernel/nvidia-drm/nvidia-drm-fb.c 
> b/kernel/nvidia-drm/nvidia-drm-fb.c
> --- a/kernel/nvidia-drm/nvidia-drm-fb.c   2016-07-12 06:53:45.0 
> +0200
> +++ b/kernel/nvidia-drm/nvidia-drm-fb.c   2016-07-28 09:43:11.494515158 
> +0200
> @@ -32,6 +32,8 @@
>  
>  #include 
>  
> +#include 
> +
>  static void nvidia_framebuffer_destroy(struct drm_framebuffer *fb)
>  {
>  struct nvidia_drm_device *nv_dev = fb->dev->dev_private;
> @@ -114,7 +116,11 @@ static struct drm_framebuffer *internal_
>   * We don't support any planar format, pick up first buffer only.
>   */
>  
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0)
> +gem = drm_gem_object_lookup(file, cmd->handles[0]);
> +#else
>  gem = drm_gem_object_lookup(dev, file, cmd->handles[0]);
> +#endif
>  
>  if (gem == NULL)
>  {
> diff -purN a/kernel/nvidia-drm/nvidia-drm-gem.c 
> b/kernel/nvidia-drm/nvidia-drm-gem.c
> --- a/kernel/nvidia-drm/nvidia-drm-gem.c  2016-07-12 06:53:45.0 
> +0200
> +++ b/kernel/nvidia-drm/nvidia-drm-gem.c  2016-07-28 09:27:24.610637573 
> +0200
> @@ -28,6 +28,8 @@
>  #include "nvidia-drm-ioctl.h"
>  #include "nvidia-drm-gem.h"
>  
> +#include 
> +
>  static struct nvidia_drm_gem_object *nvidia_drm_gem_new
>  (
>  struct drm_file *file_priv,
> @@ -408,7 +410,11 @@ int nvidia_drm_dumb_map_offset
>  
>  mutex_lock(>struct_mutex);
>  
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0)
> +gem = drm_gem_object_lookup(file, handle);
> +#else
>  gem = drm_gem_object_lookup(dev, file, handle);
> +#endif
>  
>  if (gem == NULL)
>  {
> diff -purN a/kernel/nvidia-uvm/uvm_linux.h b/kernel/nvidia-uvm/uvm_linux.h
> --- a/kernel/nvidia-uvm/uvm_linux.h   2016-07-12 06:52:17.0 +0200
> +++ b/kernel/nvidia-uvm/uvm_linux.h   2016-07-28 09:29:21.096322608 +0200
> @@ -554,11 +554,13 @@ static void uvm_init_radix_tree_preloada
>  INIT_RADIX_TREE(tree, GFP_NOWAIT);
>  }
>  
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0)
>  static bool radix_tree_empty(struct radix_tree_root *tree)
>  {
>  void *dummy;
>  return radix_tree_gang_lookup(tree, , 0, 1) == 0;
>  }
> +#endif
>  
>  
>  #if !defined(NV_USLEEP_RANGE_PRESENT)


Hi David,

WHOW! Thanks a lot for the patch!

Short qyestion: How can I apply it...I mean...as soon as I do an
emerge, either the original source will be unpacked or my package
will be rejected for being modified an different from the one, which
does not compile...

?

Best regards,
Meino





Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-30 Thread David Haller
Hello,

On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote:
>trying the new kernel linux-4.7 (vanilla, downloaded from
>ftp.kernel.org) with nvidia drivers 
>(Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
>multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
>-wayland KERNEL="linux -FreeBSD")).
>The kernel compiled fine, the nvidia-drivers does not.
>
>Anuone else with the same problem (read: This has to be
>fixed by nvidia/Linus) or am I the only one (so it is
>my problem...which does not neccessarily imply that I
>know how to fix that ... ;) ???

I've got it working with the attached patch in
/etc/portage/patches/x11-drivers/nvidia-drivers-367.35/

I've no idea though, if I hit that codepath yet. Should work though,
as the patch makes the module use the kernel function and what I read
about radix_tree_gang_lookup() it should be ok this way.

But do not expect anything to work ;)

I'm courious what the official patch will be ;) The first part
(patching kernel/nvidia-drm/nvidia-drm-{fb,gem}.c) I've found online.

HTH,
-dnh

-- 
Please do not think so much about licenses, it will just make your head
explode if not carefully studied over the years ;)
  -- Marcus Meissnerdiff -purN a/kernel/nvidia-drm/nvidia-drm-fb.c b/kernel/nvidia-drm/nvidia-drm-fb.c
--- a/kernel/nvidia-drm/nvidia-drm-fb.c	2016-07-12 06:53:45.0 +0200
+++ b/kernel/nvidia-drm/nvidia-drm-fb.c	2016-07-28 09:43:11.494515158 +0200
@@ -32,6 +32,8 @@
 
 #include 
 
+#include 
+
 static void nvidia_framebuffer_destroy(struct drm_framebuffer *fb)
 {
 struct nvidia_drm_device *nv_dev = fb->dev->dev_private;
@@ -114,7 +116,11 @@ static struct drm_framebuffer *internal_
  * We don't support any planar format, pick up first buffer only.
  */
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0)
+gem = drm_gem_object_lookup(file, cmd->handles[0]);
+#else
 gem = drm_gem_object_lookup(dev, file, cmd->handles[0]);
+#endif
 
 if (gem == NULL)
 {
diff -purN a/kernel/nvidia-drm/nvidia-drm-gem.c b/kernel/nvidia-drm/nvidia-drm-gem.c
--- a/kernel/nvidia-drm/nvidia-drm-gem.c	2016-07-12 06:53:45.0 +0200
+++ b/kernel/nvidia-drm/nvidia-drm-gem.c	2016-07-28 09:27:24.610637573 +0200
@@ -28,6 +28,8 @@
 #include "nvidia-drm-ioctl.h"
 #include "nvidia-drm-gem.h"
 
+#include 
+
 static struct nvidia_drm_gem_object *nvidia_drm_gem_new
 (
 struct drm_file *file_priv,
@@ -408,7 +410,11 @@ int nvidia_drm_dumb_map_offset
 
 mutex_lock(>struct_mutex);
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0)
+gem = drm_gem_object_lookup(file, handle);
+#else
 gem = drm_gem_object_lookup(dev, file, handle);
+#endif
 
 if (gem == NULL)
 {
diff -purN a/kernel/nvidia-uvm/uvm_linux.h b/kernel/nvidia-uvm/uvm_linux.h
--- a/kernel/nvidia-uvm/uvm_linux.h	2016-07-12 06:52:17.0 +0200
+++ b/kernel/nvidia-uvm/uvm_linux.h	2016-07-28 09:29:21.096322608 +0200
@@ -554,11 +554,13 @@ static void uvm_init_radix_tree_preloada
 INIT_RADIX_TREE(tree, GFP_NOWAIT);
 }
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0)
 static bool radix_tree_empty(struct radix_tree_root *tree)
 {
 void *dummy;
 return radix_tree_gang_lookup(tree, , 0, 1) == 0;
 }
+#endif
 
 
 #if !defined(NV_USLEEP_RANGE_PRESENT)


Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-30 Thread Meino . Cramer



Andrew Lowe  [16-07-30 08:44]:
> On 30/07/16 14:09, meino.cra...@gmx.de wrote:
> >Hi,
> >
> >thank you for your reply ! :)
> >I have to use the nvidia drivers, because I am using Blender, which
> >renders via CUDA on the GPU...
> >
> >Best regards
> >Meino
> >
> >
> >
> >
> >Jigme Datse Yli-RAsku  [16-07-30 
> >08:04]:
> >>I have an earlier version of the x11-drivers/nvidia-drivers installed 
> >>(361.28), but if I recall, I couldn't get x11 to use them.  Or maybe 
> >>they are already using them, but I don't know it (but I believe I 
> >>couldn't get the tools to recognize that they were being used).  My 
> >>understanding is that using the correct framebuffer drivers is as 
> >>good, if not better than using the official nvidia ones.  But as I 
> >>don't believe I have had the opportunity to do so, I can't really 
> >>say.
> >>
> >>Jigme Datse Yli-Rasku
> >>
> >>On 2016-07-29 22:36, meino.cra...@gmx.de wrote:
> >>>Hi,
> >>>
> >>>trying the new kernel linux-4.7 (vanilla, downloaded from
> >>>ftp.kernel.org) with nvidia drivers
> >>>(Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
> >>>multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
> >>>-wayland KERNEL="linux -FreeBSD")).
> >>>The kernel compiled fine, the nvidia-drivers does not.
> >>>
> >>>Anuone else with the same problem (read: This has to be
> >>>fixed by nvidia/Linus) or am I the only one (so it is
> >>>my problem...which does not neccessarily imply that I
> >>>know how to fix that ... ;) ???
> >>>
> >>>Best regards
> >>>Meino
> 
>   There is a duplicate definition of a function[1], the kernel 
> apparently has a function and a certain parameter list and then someone 
> at nVidia managed to use the same name but a different parameter list - 
> hence the duplicate definition.
> 
>   I hit this last night, went back one kernel but the latest nvidia 
> driver only works with the 4.7 series kernel so had to go one back with 
> the drivers as well. It's known so just hang tight a day or two and all 
> should be well.
> 
>   Andrew
> 
> [1] From memory at 2am and after a lot of chocolate so could be 
> slightly wrong here
>

Hi,

thanks a lot for the good news!
Fingers crossed...waiting in front of my monitor, compiler engines
started and ready to accelerate...
The compiler will go where no men has ever compiled before...

;)

Best regards,
Meino



 



Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-30 Thread Andrew Lowe

On 30/07/16 14:09, meino.cra...@gmx.de wrote:

Hi,

thank you for your reply ! :)
I have to use the nvidia drivers, because I am using Blender, which
renders via CUDA on the GPU...

Best regards
Meino




Jigme Datse Yli-RAsku  [16-07-30 08:04]:

I have an earlier version of the x11-drivers/nvidia-drivers installed (361.28), 
but if I recall, I couldn't get x11 to use them.  Or maybe they are already 
using them, but I don't know it (but I believe I couldn't get the tools to 
recognize that they were being used).  My understanding is that using the 
correct framebuffer drivers is as good, if not better than using the official 
nvidia ones.  But as I don't believe I have had the opportunity to do so, I 
can't really say.

Jigme Datse Yli-Rasku

On 2016-07-29 22:36, meino.cra...@gmx.de wrote:

Hi,

trying the new kernel linux-4.7 (vanilla, downloaded from
ftp.kernel.org) with nvidia drivers
(Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
-wayland KERNEL="linux -FreeBSD")).
The kernel compiled fine, the nvidia-drivers does not.

Anuone else with the same problem (read: This has to be
fixed by nvidia/Linus) or am I the only one (so it is
my problem...which does not neccessarily imply that I
know how to fix that ... ;) ???

Best regards
Meino


	There is a duplicate definition of a function[1], the kernel apparently 
has a function and a certain parameter list and then someone at nVidia 
managed to use the same name but a different parameter list - hence the 
duplicate definition.


	I hit this last night, went back one kernel but the latest nvidia 
driver only works with the 4.7 series kernel so had to go one back with 
the drivers as well. It's known so just hang tight a day or two and all 
should be well.


Andrew

[1] From memory at 2am and after a lot of chocolate so could be slightly 
wrong here




Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-30 Thread Meino . Cramer
Hi,

thank you for your reply ! :)
I have to use the nvidia drivers, because I am using Blender, which
renders via CUDA on the GPU...

Best regards
Meino




Jigme Datse Yli-RAsku  [16-07-30 08:04]:
> I have an earlier version of the x11-drivers/nvidia-drivers installed 
> (361.28), but if I recall, I couldn't get x11 to use them.  Or maybe they are 
> already using them, but I don't know it (but I believe I couldn't get the 
> tools to recognize that they were being used).  My understanding is that 
> using the correct framebuffer drivers is as good, if not better than using 
> the official nvidia ones.  But as I don't believe I have had the opportunity 
> to do so, I can't really say.
> 
> Jigme Datse Yli-Rasku
> 
> On 2016-07-29 22:36, meino.cra...@gmx.de wrote:
> > Hi,
> >
> > trying the new kernel linux-4.7 (vanilla, downloaded from
> > ftp.kernel.org) with nvidia drivers
> > (Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
> > multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
> > -wayland KERNEL="linux -FreeBSD")).
> > The kernel compiled fine, the nvidia-drivers does not.
> >
> > Anuone else with the same problem (read: This has to be
> > fixed by nvidia/Linus) or am I the only one (so it is
> > my problem...which does not neccessarily imply that I
> > know how to fix that ... ;) ???
> >
> > Best regards
> > Meino
> >
> >
> >
> >
> 
> -- 
> Jigme Datse Yli-Rasku
> jigme.da...@datsemultimedia.com (Preferred address for new messages)
> 250-505-6117
> 
> Jigme Datse Yli-Rasku
> PO Box 270
> Rossland, BC V0G 1Y0
> Canada
> 
> ...
> ... This message should be electronically signed, and if the sender ...
> ... has your public key, may also be encrypted. ...
> ... If you have any questions about this, please email, or call. ...
> ... ...
> ... Note, unknown calls likely will go to voicemail. ...
> ... Please leave a message if you get voicemail. ...
> ...
> 
> 
> 
> 



Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-30 Thread Jigme Datse Yli-RAsku
I have an earlier version of the x11-drivers/nvidia-drivers installed (361.28), 
but if I recall, I couldn't get x11 to use them.  Or maybe they are already 
using them, but I don't know it (but I believe I couldn't get the tools to 
recognize that they were being used).  My understanding is that using the 
correct framebuffer drivers is as good, if not better than using the official 
nvidia ones.  But as I don't believe I have had the opportunity to do so, I 
can't really say.

Jigme Datse Yli-Rasku

On 2016-07-29 22:36, meino.cra...@gmx.de wrote:
> Hi,
>
> trying the new kernel linux-4.7 (vanilla, downloaded from
> ftp.kernel.org) with nvidia drivers
> (Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
> multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
> -wayland KERNEL="linux -FreeBSD")).
> The kernel compiled fine, the nvidia-drivers does not.
>
> Anuone else with the same problem (read: This has to be
> fixed by nvidia/Linus) or am I the only one (so it is
> my problem...which does not neccessarily imply that I
> know how to fix that ... ;) ???
>
> Best regards
> Meino
>
>
>
>

-- 
Jigme Datse Yli-Rasku
jigme.da...@datsemultimedia.com (Preferred address for new messages)
250-505-6117

Jigme Datse Yli-Rasku
PO Box 270
Rossland, BC V0G 1Y0
Canada

...
... This message should be electronically signed, and if the sender ...
... has your public key, may also be encrypted. ...
... If you have any questions about this, please email, or call. ...
... ...
... Note, unknown calls likely will go to voicemail. ...
... Please leave a message if you get voicemail. ...
...






[gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?

2016-07-29 Thread Meino . Cramer
Hi,

trying the new kernel linux-4.7 (vanilla, downloaded from
ftp.kernel.org) with nvidia drivers 
(Installed versions:  367.35-r1^md(03:00:46 07/30/16)(X driver kms
multilib uvm -acpi -compat -gtk3 -pax_kernel -static-libs -tools
-wayland KERNEL="linux -FreeBSD")).
The kernel compiled fine, the nvidia-drivers does not.

Anuone else with the same problem (read: This has to be
fixed by nvidia/Linus) or am I the only one (so it is
my problem...which does not neccessarily imply that I
know how to fix that ... ;) ???

Best regards
Meino






[Solved] Re: [gentoo-user] Nvidia-drivers does not compile anymore

2016-04-30 Thread Jacques Montier
2016-04-30 17:41 GMT+02:00 Jacques Montier :

> 2016-04-30 15:25 GMT+02:00 Neil Bothwick :
>
>> On Sat, 30 Apr 2016 14:01:12 +0200, Jacques Montier wrote:
>>
>> > You can get the complete log in the attached file
>> > x11-drivers:nvidia-drivers-340.76:20160430-104727.log
>>
>> Which ends with
>>
>>  !!! User patches were applied to this build!
>>
>> Are you applying your own patches? Do you have anything
>> in /etc/portage/patches/x11-drivers?
>>
>> I've been caught by this one before, adding a patch that was necessary
>> for the current version, which then causes newer versions to fail.
>>
>>
>> --
>> Neil Bothwick
>>
>> If I want your opinion, I'll ask you to fill out the necessary form.
>>
>
>
> Thank you Neil,
>
> Yes, i applied the nvidia-drivers-340-76-kernel-4.0.patch (attached file).
> So i tried compiling nvidia-drivers without any patch and it fails with
> the errors :
>
> make[3]: ***
> [/var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel/nv-pat.o]
> Error 1
> /var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel/nv-procfs.o]
> Error 1
>
> Complete log in attached file.
>
> Best regards,
>
>
> *--*
> *Jacques*
>

Hello again,

I've found a working nvidia-drivers-340-96 (instead of 340-76) which
compiles fine with the 4.4.6 kernel and without any patch !
So it's solved !

Thanks a lot for your responses.

Best regards,

*--*
*Jacques*


Re: [gentoo-user] Nvidia-drivers does not compile anymore

2016-04-30 Thread Neil Bothwick
On Sat, 30 Apr 2016 14:01:12 +0200, Jacques Montier wrote:

> You can get the complete log in the attached file
> x11-drivers:nvidia-drivers-340.76:20160430-104727.log

Which ends with

 !!! User patches were applied to this build!

Are you applying your own patches? Do you have anything
in /etc/portage/patches/x11-drivers?

I've been caught by this one before, adding a patch that was necessary
for the current version, which then causes newer versions to fail.


-- 
Neil Bothwick

If I want your opinion, I'll ask you to fill out the necessary form.


pgpT_FpM2jSBF.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Nvidia-drivers does not compile anymore

2016-04-30 Thread Alan McKinnon
On 30/04/2016 12:52, Jacques Montier wrote:
> Hello all,
> 
> I need nvidia-drivers-340.76 for my Nvidia GeForce GT240 graphic card.
> I use nvidia-drivers-340.76 from a local overlay with the
> nvidia-drivers-340-76-kernel-4.0.patch which works fine with
> gentoo-sources-4.1.15-r1.
> I would like to upgrade to the 4.4.6 kernel.
> Unfortunately, nvidia-drivers-340.76 does not compile anymore.
> I get the errors :
> 
> 3410:make[3]: ***
> [/var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel/nv-procfs.o]
> Error 1
> 3651:make[2]: ***
> [_module_/var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel]
> Error 2
> 3654:make[1]: *** [sub-make] Error 2
> 3659:make: *** [nvidia.ko] Error 1
> 
> Any idea ? New patch ?
> 
> Thanks a lot,
> 
> Regards,
> 
> /--/
> /Jacques/


The real error is higher up in the output. Please post it.

-- 
Alan McKinnon
alan.mckin...@gmail.com




[gentoo-user] Nvidia-drivers does not compile anymore

2016-04-30 Thread Jacques Montier
Hello all,

I need nvidia-drivers-340.76 for my Nvidia GeForce GT240 graphic card.
I use nvidia-drivers-340.76 from a local overlay with the
nvidia-drivers-340-76-kernel-4.0.patch which works fine with
gentoo-sources-4.1.15-r1.
I would like to upgrade to the 4.4.6 kernel.
Unfortunately, nvidia-drivers-340.76 does not compile anymore.
I get the errors :

3410:make[3]: ***
[/var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel/nv-procfs.o]
Error 1
3651:make[2]: ***
[_module_/var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel]
Error 2
3654:make[1]: *** [sub-make] Error 2
3659:make: *** [nvidia.ko] Error 1

Any idea ? New patch ?

Thanks a lot,

Regards,

*--*
*Jacques*


Re: [gentoo-user] nvidia-drivers using deprecated...

2016-02-09 Thread Andrew Savchenko
On Mon, 1 Feb 2016 10:00:40 + Neil Bothwick wrote:
> On Mon, 1 Feb 2016 12:38:45 +0300, Andrew Savchenko wrote:
> 
> > > It's nothing to worry about, deprecated only mean is will be broken at
> > > some time in the future, it still works for now. IMO ebuild QA
> > > messages like this should not be shown to users.  
> > 
> > The idea is that users should ping developers with appropriate bug
> > reports.
> 
> Instead, they ask in here or on the forums. Shouldn't the devs see such
> messages anyway and already be aware of the need to update the ebuild?

They see them, but only when they build packages, e.g. when making
version bump. Eclass may become deprecated after last update of a
package, in such case devs may not see such warning because they
have no need to rebuild the package.

Best regards,
Andrew Savchenko


pgpAB9hzw17ZR.pgp
Description: PGP signature


Re: [gentoo-user] nvidia-drivers using deprecated...

2016-02-09 Thread Neil Bothwick
On Tue, 9 Feb 2016 11:00:07 +0300, Andrew Savchenko wrote:

> > > The idea is that users should ping developers with appropriate bug
> > > reports.  
> > 
> > Instead, they ask in here or on the forums. Shouldn't the devs see
> > such messages anyway and already be aware of the need to update the
> > ebuild?  
> 
> They see them, but only when they build packages, e.g. when making
> version bump. Eclass may become deprecated after last update of a
> package, in such case devs may not see such warning because they
> have no need to rebuild the package.

It still seems an awfully noisy and inefficient way of doing things.
Can't the developer deprecating the eclass parse the tree for ebuilds
still using it an d ping the developers, this sort of QA stuff should be
automated , not rely on users seeing the messages and reporting rather
than ignoring them.

Anyway, the eclass has only been deprecated, the ebuild devs should be
aware of this long before it is obsoleted.


-- 
Neil Bothwick

"There are no stupid questions, just too many inquisitive idiots."


pgpgOxa7r6HQ3.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] nvidia-drivers using deprecated...

2016-02-08 Thread Andrew Savchenko
On Mon, 1 Feb 2016 05:04:14 -0500 Philip Webb wrote:
> 160201 Andrew Savchenko wrote:
> > On Mon, 1 Feb 2016 09:03:50 + Neil Bothwick wrote:
> >> On Mon, 1 Feb 2016 05:56:37 +0100, meino.cra...@gmx.de wrote:
> >>> Switching to nvidia OpenCL interface... done
> >>>  * x11-drivers/nvidia-drivers is using the deprecated
> >>> readme.gentoo.eclass.<<>>
> >>>  * Please use readme.gentoo-r1 instead.
> >>> What does the marked line implies? This is an outdated readme?
> >> It's a QA message stating that the ebuild should be updated
> >> to use a newer eclass. The readme.gentoo eclass is used
> >> to generate messages specific to installing the package on Gentoo.
> >> IMO ebuild QA messages like this should not be shown to users.
> > The idea is that users should ping developers
> > with appropriate bug reports.
> 
> However are users supposed to know that ?
> How would they know whether such a bug report really was "appropriate" ?
> 
> Really, Portage output needs a serious re-think (smile).

If emerge outputs something strange for ebuild, this should be
reported as bug, as well as any other weird package behaviour. 

Of course, no one _must_ report this, this is a matter of a good
will.

Best regards,
Andrew Savchenko


pgpHqJ2igRnLX.pgp
Description: PGP signature


Re: [gentoo-user] nvidia-drivers using deprecated...

2016-02-01 Thread Neil Bothwick
On Mon, 1 Feb 2016 05:56:37 +0100, meino.cra...@gmx.de wrote:

> Switching to nvidia OpenCL interface... done
>  * x11-drivers/nvidia-drivers is using the deprecated
> readme.gentoo.eclass.<<>>
>  * Please use readme.gentoo-r1 instead.

> What does the marked line implies? This is an outdated readme?

It's a QA message stating thst the ebuild should be updated to use a
newer eclass. The readme.gentoo eclass is used to generate messages
specific to installing the package on Gentoo.

It's nothing to worry about, deprecated only mean is will be broken at
some time in the future, it still works for now. IMO ebuild QA messages
like this should not be shown to users.


-- 
Neil Bothwick

Top Oxymorons Number 13: Computer jock


pgpX9a4m0BR3_.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] nvidia-drivers using deprecated...

2016-02-01 Thread Neil Bothwick
On Mon, 1 Feb 2016 12:38:45 +0300, Andrew Savchenko wrote:

> > It's nothing to worry about, deprecated only mean is will be broken at
> > some time in the future, it still works for now. IMO ebuild QA
> > messages like this should not be shown to users.  
> 
> The idea is that users should ping developers with appropriate bug
> reports.

Instead, they ask in here or on the forums. Shouldn't the devs see such
messages anyway and already be aware of the need to update the ebuild?


-- 
Neil Bothwick

Voting Democrat or Republican is like choosing a cabin in the Titanic.


pgpDFyjAJHRdJ.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] nvidia-drivers using deprecated...

2016-02-01 Thread Philip Webb
160201 Andrew Savchenko wrote:
> On Mon, 1 Feb 2016 09:03:50 + Neil Bothwick wrote:
>> On Mon, 1 Feb 2016 05:56:37 +0100, meino.cra...@gmx.de wrote:
>>> Switching to nvidia OpenCL interface... done
>>>  * x11-drivers/nvidia-drivers is using the deprecated
>>> readme.gentoo.eclass.<<>>
>>>  * Please use readme.gentoo-r1 instead.
>>> What does the marked line implies? This is an outdated readme?
>> It's a QA message stating that the ebuild should be updated
>> to use a newer eclass. The readme.gentoo eclass is used
>> to generate messages specific to installing the package on Gentoo.
>> IMO ebuild QA messages like this should not be shown to users.
> The idea is that users should ping developers
> with appropriate bug reports.

However are users supposed to know that ?
How would they know whether such a bug report really was "appropriate" ?

Really, Portage output needs a serious re-think (smile).

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca




Re: [gentoo-user] nvidia-drivers using deprecated...

2016-02-01 Thread Andrew Savchenko
On Mon, 1 Feb 2016 09:03:50 + Neil Bothwick wrote:
> On Mon, 1 Feb 2016 05:56:37 +0100, meino.cra...@gmx.de wrote:
> 
> > Switching to nvidia OpenCL interface... done
> >  * x11-drivers/nvidia-drivers is using the deprecated
> > readme.gentoo.eclass.<<>>
> >  * Please use readme.gentoo-r1 instead.
> 
> > What does the marked line implies? This is an outdated readme?
> 
> It's a QA message stating thst the ebuild should be updated to use a
> newer eclass. The readme.gentoo eclass is used to generate messages
> specific to installing the package on Gentoo.
> 
> It's nothing to worry about, deprecated only mean is will be broken at
> some time in the future, it still works for now. IMO ebuild QA messages
> like this should not be shown to users.

The idea is that users should ping developers with appropriate bug
reports.

Best regards,
Andrew Savchenko


pgpBnYPzAwv9I.pgp
Description: PGP signature


[gentoo-user] nvidia-drivers using deprecated...

2016-01-31 Thread Meino . Cramer
hi,

ths morning brings an update to the nividia-drivers, whch where
successfully emerged and installed. Right at the end of this process
this was prointed on the console:

 * Removing x11-drivers/nvidia-drivers-361.18-r2 from moduledb.
Switching to nvidia OpenGL interface... done
>>> Regenerating /etc/ld.so.cache...
>>> Original instance of package unmerged safely.
 * Updating module dependencies for 4.4.0-RT ...
 [ ok ]
 * Adding module to moduledb.
Switching to nvidia OpenGL interface... done
Switching to nvidia OpenCL interface... done
 * x11-drivers/nvidia-drivers is using the deprecated readme.gentoo.eclass.
<<>>
 * Please use readme.gentoo-r1 instead.
>>> x11-drivers/nvidia-drivers-361.18-r4 merged.
>>> Regenerating /etc/ld.so.cache...
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.


What does the marked line implies? This is an outdated readme?



Thank you very much in advance for any translation! :)

Best regards,
Meino






[gentoo-user] nvidia-drivers-340.76 failed with gentoo-sources-4.0.5

2015-06-18 Thread Jacques Montier
Hi all,

Because of an old graphic card, i have to compile nvidia-drivers-340.76.
nvidia-drivers-340.76 does not compile with the new 4.0.5 kernel.
Here is the output error :
/var/tmp/portage/x11-drivers/nvidia-drivers-340.76/work/kernel/nv-pat.o]
Error 1

I saw a topic about that problem on Gentoo forum :
https://forums.gentoo.org/viewtopic-p-7754020.html?sid=3b9fed3069c0b6644c1a41e839455b85
I tried to apply the patch
/etc/portage/patches/x11-drivers/nvidia-drivers/nvidia-drivers-340.76.patch

*--- a/kernel/nv-pat.c.orig *
*+++ b/kernel/nv-pat.c *
*@@ -35,8 +35,13 @@ *
* unsigned long cr0 = read_cr0(); *
* write_cr0(((cr0  (0xdfff)) | 0x4000)); *
* wbinvd(); *
*+if LINUX_VERSION_CODE  KERNEL_VERSION(3, 20, 0) *
* *cr4 = read_cr4(); *
* if (*cr4  0x80) write_cr4(*cr4  ~0x80); *
*+else *
*+*cr4 = __read_cr4(); *
*+if (*cr4  0x80) __write_cr4(*cr4  ~0x80); *
*+endif *
* __flush_tlb(); *
* } *

*@@ -46,7 +51,11 @@ *
* wbinvd(); *
* __flush_tlb(); *
* write_cr0((cr0  0x9fff)); *
*+if LINUX_VERSION_CODE  KERNEL_VERSION(3, 20, 0) *
* if (cr4  0x80) write_cr4(cr4); *
*+else *
*+if (cr4  0x80) __write_cr4(cr4); *
*+endif *
* } *

* static int nv_determine_pat_mode(void)*

This patch does not work ; i get the error

* Failed Patch: nvidia-drivers-340.76.patch !
 *  (
/etc/portage/patches//x11-drivers/nvidia-drivers/nvidia-drivers-340.76.patch
)


Any idea ?

Thanks a lot,


Cheers,






*--*
*Jacques*


Re: [gentoo-user] nvidia-drivers 325.15 removal

2013-12-15 Thread Philip Webb
131214 »Q« wrote:
 It looks to me as if the removal of nvidia-drivers-325.15 was a mistake
 I run mostly stable amd64.
 I *think* 325.15 was the latest stable

  [I] x11-drivers/nvidia-drivers
 Available versions:  96.43.23^msd 173.14.39^msd 304.116^msd ~304.117^msd 
319.76^msd 331.20^msd {+X acpi custom-cflags gtk multilib pax_kernel (+)tools 
KERNEL=FreeBSD linux}
 Installed versions:  331.20^msd([2013-11-23 15:26:19])(X multilib -acpi 
-pax_kernel -tools KERNEL=linux -FreeBSD)

No problems here.  Have you sync'ed recently ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca




[gentoo-user] nvidia-drivers 325.15 removal

2013-12-14 Thread »Q«
It looks to me as if the removal of nvidia-drivers-325.15 was a
mistake, but I've got a lot going on in the meat world right now, and I
don't want to file a bug if I've simply gotten confused.

I run mostly stable amd64.  I have 325.15 installed, and nothing
regarding nvidia-drivers in /etc/portage/package/accept_keywords, so I
*think* 325.15 was the latest stable and shouldn't have been removed
for being old.  The removal makes portage want to downgrade the package
for me.

I see in the changelog:

  14 Dec 2013; Jeroen Roovers j...@gentoo.org -nvidia-drivers-325.15.ebuild:
  Old.

  [...]

  02 Nov 2013; Jeroen Roovers j...@gentoo.org -nvidia-drivers-325.08.ebuild,
  nvidia-drivers-325.15.ebuild:
  Stable for AMD64 x86 too.

Could someone confirm or set me straight?




[gentoo-user] nvidia-drivers segfault when starting X

2013-08-01 Thread Alexander Puchmayr
Hi there,

When I start X (or start kdm), I get a segmentation fault and no X.

The Xorg-log says:
[  8675.702] (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
[  8675.702] (==) NVIDIA(0): RGB weight 888
[  8675.702] (==) NVIDIA(0): Default visual is TrueColor
[  8675.702] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
[  8675.702] (**) NVIDIA(0): Option TwinViewOrientation LeftOf
[  8675.703] (**) NVIDIA(0): Option AddARGBGLXVisuals
[  8675.703] (**) NVIDIA(0): Option UseEvents false
[  8675.703] (**) NVIDIA(0): Enabling 2D acceleration
[  8676.186] (II) NVIDIA(GPU-0): Display (Samsung SyncMaster (DFP-0)) does not 
support NVIDIA
[  8676.186] (II) NVIDIA(GPU-0): 3D Vision stereo.
[  8676.253] (II) NVIDIA(GPU-0): Display (Eizo L565 (DFP-1)) does not support 
NVIDIA 3D Vision
[  8676.253] (II) NVIDIA(GPU-0): stereo.
[  8676.255] (II) NVIDIA(0): NVIDIA GPU GeForce 7600 GT (G73) at PCI:1:0:0 
(GPU-0)
[  8676.255] (--) NVIDIA(0): Memory: 262144 kBytes
[  8676.255] (--) NVIDIA(0): VideoBIOS: 05.73.22.18.00
[  8676.255] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[  8676.255] (--) NVIDIA(0): Interlaced video modes are supported on this GPU
[  8676.255] (--) NVIDIA(0): Valid display device(s) on GeForce 7600 GT at 
PCI:1:0:0
[  8676.255] (--) NVIDIA(0): CRT-0
[  8676.255] (--) NVIDIA(0): CRT-1
[  8676.255] (--) NVIDIA(0): TV-0
[  8676.255] (--) NVIDIA(0): Samsung SyncMaster (DFP-0) (connected)
[  8676.255] (--) NVIDIA(0): Eizo L565 (DFP-1) (connected)
[  8676.255] (--) NVIDIA(0): CRT-0: 400.0 MHz maximum pixel clock
[  8676.255] (--) NVIDIA(0): CRT-1: 400.0 MHz maximum pixel clock
[  8676.255] (--) NVIDIA(0): TV-0: 400.0 MHz maximum pixel clock
[  8676.255] (--) NVIDIA(0): TV encoder: Unknown
[  8676.255] (--) NVIDIA(0): Samsung SyncMaster (DFP-0): 330.0 MHz maximum 
pixel clock
[  8676.255] (--) NVIDIA(0): Samsung SyncMaster (DFP-0): Internal Dual Link 
TMDS
[  8676.255] (--) NVIDIA(0): Eizo L565 (DFP-1): 165.0 MHz maximum pixel clock
[  8676.255] (--) NVIDIA(0): Eizo L565 (DFP-1): Internal Single Link TMDS
[  8676.255] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID 
for display
[  8676.255] (**) NVIDIA(0): device Samsung SyncMaster (DFP-0) (Using EDID 
frequencies
[  8676.255] (**) NVIDIA(0): has been enabled on all display devices.)
[  8676.255] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID 
for display
[  8676.255] (**) NVIDIA(0): device Eizo L565 (DFP-1) (Using EDID 
frequencies has been
[  8676.255] (**) NVIDIA(0): enabled on all display devices.)
[  8676.255] (II) NVIDIA(0): Validated MetaModes:
[  8676.255] (II) NVIDIA(0): DFP-0:nvidia-auto-select,DFP-1:nvidia-auto-
select
[  8676.255] (II) NVIDIA(0): Virtual screen size determined to be 3200 x 1200
[  8676.256] (WW) NVIDIA(0): Unable to support custom viewPortOut 1920 x 1080 
+0 +60
[  8676.256] (WW) NVIDIA(0): Unable to support custom viewPortOut 1920 x 1080 
+0 +60
[  8676.256] (--) NVIDIA(0): DPI set to (93, 95); computed from UseEdidDpi X 
config
[  8676.256] (--) NVIDIA(0): option
[  8676.256] (**) NVIDIA(0): Enabling 32-bit ARGB GLX visuals.
[  8676.256] (--) Depth 24 pixmap format is 32 bpp
[  8676.262] (II) NVIDIA(0): Setting mode DFP-0:nvidia-auto-
select,DFP-1:nvidia-auto-select
[  8676.286] (EE) 
[  8676.286] (EE) Backtrace:
[  8676.286] (EE) 0: X (xorg_backtrace+0x34) [0x5cd634]
[  8676.286] (EE) 1: X (0x40+0x1d1ca9) [0x5d1ca9]
[  8676.286] (EE) 2: /lib64/libpthread.so.0 (0x7fe689cb+0x10810) 
[0x7fe689cc0810]
[  8676.286] (EE) 3: /usr/lib64/xorg/modules/drivers/nvidia_drv.so 
(0x7fe6840d8000+0x11643b) [0x7fe6841ee43b]
[  8676.286] (EE) 4: /usr/lib64/xorg/modules/drivers/nvidia_drv.so 
(0x7fe6840d8000+0x72773) [0x7fe68414a773]
[  8676.286] (EE) 5: /usr/lib64/xorg/modules/drivers/nvidia_drv.so 
(0x7fe6840d8000+0xeaa01) [0x7fe6841c2a01]
[  8676.286] (EE) 6: /usr/lib64/xorg/modules/drivers/nvidia_drv.so 
(0x7fe6840d8000+0xe30e4) [0x7fe6841bb0e4]
[  8676.286] (EE) 7: /usr/lib64/xorg/modules/drivers/nvidia_drv.so 
(0x7fe6840d8000+0xe3820) [0x7fe6841bb820]
[  8676.286] (EE) 8: /usr/lib64/xorg/modules/drivers/nvidia_drv.so 
(0x7fe6840d8000+0x9447b) [0x7fe68416c47b]
[  8676.286] (EE) 9: /usr/lib64/xorg/modules/drivers/nvidia_drv.so 
(0x7fe6840d8000+0x8fedb) [0x7fe684167edb]
[  8676.286] (EE) 10: /usr/lib64/xorg/modules/drivers/nvidia_drv.so 
(0x7fe6840d8000+0xde8f6) [0x7fe6841b68f6]
[  8676.286] (EE) 11: /usr/lib64/xorg/modules/drivers/nvidia_drv.so 
(0x7fe6840d8000+0x56f6bb) [0x7fe6846476bb]
[  8676.286] (EE) 12: /usr/lib64/xorg/modules/drivers/nvidia_drv.so 
(0x7fe6840d8000+0x5609f1) [0x7fe6846389f1]
[  8676.286] (EE) 13: X (AddScreen+0x75) [0x43ddb5]
[  8676.286] (EE) 14: X (InitOutput+0x3ec) [0x48b20c]
[  8676.286] (EE) 15: X (0x40+0x29910) [0x429910]
[  8676.286] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xec) 
[0x7fe68890a4cc]
[  8676.286] (EE) 17: X (0x40+0x2a22d) [0x42a22d]
[  8676.286] (EE) 
[  8676.286] (EE) 

Re: [gentoo-user] Nvidia drivers and KDE problem

2013-05-29 Thread Paul Hartman
On Sun, May 26, 2013 at 4:12 AM, Dale rdalek1...@gmail.com wrote:
 The problem.  After I am logged into KDE for a good while, like several
 hours to maybe a day or so, the kicker thingy at the bottom locks up
 tight.  I can't switch desktops, clock stops working, can't click the K
 menu thingy either.  Everything in the kicker thingy is dead as a door
 nail.  I can switch desktops with the keyboard and everything else works
 in KDE just fine.  I can also switch to a console too.  Killing X and
 restarting it fixes it, xdm restart in my case.  I don't have to reload
 drivers or restart the system.  I do go back and downgrade the drivers
 after testing it.

I recently started having trouble where KDE becomes unresponsive at
login and logout for about 20 seconds or more. In my case it was
because of pulseaudio and KDE not getting along together for some
reason. The facts are a bit more nuanced but the work-around that
makes everything normal for me again was to edit
/etc/xdg/autostart/pulseaudio.desktop and add a line which says:
NotShowIn=KDE

Maybe unrelated to your problem but I thought I would mention it just in case.



Re: [gentoo-user] Nvidia drivers and KDE problem

2013-05-29 Thread Dale
Paul Hartman wrote:
 On Sun, May 26, 2013 at 4:12 AM, Dale rdalek1...@gmail.com wrote:
 The problem.  After I am logged into KDE for a good while, like several
 hours to maybe a day or so, the kicker thingy at the bottom locks up
 tight.  I can't switch desktops, clock stops working, can't click the K
 menu thingy either.  Everything in the kicker thingy is dead as a door
 nail.  I can switch desktops with the keyboard and everything else works
 in KDE just fine.  I can also switch to a console too.  Killing X and
 restarting it fixes it, xdm restart in my case.  I don't have to reload
 drivers or restart the system.  I do go back and downgrade the drivers
 after testing it.
 I recently started having trouble where KDE becomes unresponsive at
 login and logout for about 20 seconds or more. In my case it was
 because of pulseaudio and KDE not getting along together for some
 reason. The facts are a bit more nuanced but the work-around that
 makes everything normal for me again was to edit
 /etc/xdg/autostart/pulseaudio.desktop and add a line which says:
 NotShowIn=KDE

 Maybe unrelated to your problem but I thought I would mention it just in case.




I don't use pulseaudio but thanks for the post tho.  If I did, could
have helped.  :-) 

Also, I still have two posts I have not replied to because it hasn't
locked up yet.  I haven't been able to test the things yet.  If it locks
up again, will reply with the results.

Dale

:-)  :-) 

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




Re: [gentoo-user] Nvidia drivers and KDE problem

2013-05-27 Thread Fast Turtle
On Sun, 26 May 2013 07:10:53 -0500
Dale rdalek1...@gmail.com wrote:

 Alan McKinnon wrote:
  On 26/05/2013 13:03, Dale wrote:
  Alan McKinnon wrote:
  On 26/05/2013 11:51, Dale wrote:
 
  What package provides the kicker thingy?  I think in KDE3 it was called
  kicker but it appears to have changed to something else.  Is that
  krunner that has it now?
  Maybe it's time you used the thingy suffix a little less and the real
  names of things a little more :-)
 
  What thing are you asking about? The panel that is usually at the bottom
  and holds the plasma widgets? Or the thin popup you get with Alt-F2?
 
  The panel is called plasma-desktop and comes from 
  kde-base/plasma-workspace
  The popup is krunner and comes from kde-base/krunner
 
  I doubt very much it's a real bug as such in either KDE app (although
  the fix might go in there). It looks much more to me like a side-effect
  of IO blocking - two or more apps are trying to get something done and
  unexpectedly are not getting answers, so they hang around waiting in the
  doorway and get get in the way of everything else. And just for fun,
  video drivers are also trying to get in on the act as they have to deal
  with mouse pointer repaints...
 
  Debugging this one is going to be fun (for peculiar definitions of fun)
 
 
  The thingy is the thing at the bottom where I can switch desktops, click
  the K menu and where my clock is.  I think it was called Kicker in
  KDE3.  KDE4 seems to have changed it but not sure what the new name is. 
  It's a plasma widget called a panel, the only useful thing it does is to
  be a container for other widgets that do useful stuff.
 
  The panel is started by plasma-desktop as one of the standard widgets it
  manages. The idea is to give you stuff on the screen that looks more or
  less like a familiar desktop. Plasma can do other things and give you
  completely different layouts; like for instance not giving you a panel
  at all. This would be useful on a phone with small screen
 
  The whole thing is heavily event based and has to react to a bucket load
  of system events being generated such as what the mouse is doing.
  There's a fantastic number of ways this could go wrong, some might be
  plasma's fault, some might be faults that happen to plasma
 
 
 I'll try to remember to call it a panel thingy then.  ROFL 
 
 
  I hope they fix this thing soon.  If they remove the driver from the
  tree, I'm in a bit of a pickle. 
  No, you won't be. You have the ebuild right now, copy it to your overlay
  and remove becomes something that will not happen
 
 
 
 
 Last time I did that, it didn't work out well.  Actually, it just plain
 didn't work.  May as well tell it like it is.  ;-)  I'll save a copy
 just in case. 
 
 Cross that bridge when I get there I guess. 
 
 Dale
 
 :-)  :-) 
 
 -- 
 I am only responsible for what I said ... Not for what you understood or how 
 you interpreted my words!
 
 
I suspect it's the fact your using the ~arch version of kde (4.10.3) is not 
fully stable yet and yes there be bugs in them valleys. 



[gentoo-user] Nvidia drivers and KDE problem

2013-05-26 Thread Dale
Howdy,

I been letting portage upgrade nvidia drivers as usual.  Thing is, the
last two or three drivers seems to cause a issue.  First, versions that
cause the issue:

=x11-drivers/nvidia-drivers-319.12
=x11-drivers/nvidia-drivers-319.17
=x11-drivers/nvidia-drivers-319.23

I'm currently using this one which works fine:

x11-drivers/nvidia-drivers-313.30

This is KDE info:

[IP-] [  ] kde-base/kdelibs-4.10.3-r2

Video card info:

01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce GT
220] (rev a2) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation Device 069a
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at fb00 (32-bit, non-prefetchable) [size=16M]
Memory at c000 (64-bit, prefetchable) [size=256M]
Memory at de00 (64-bit, prefetchable) [size=32M]
I/O ports at ef00 [size=128]
[virtual] Expansion ROM at d000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [b4] Vendor Specific Information: Len=14 ?
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting ?
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1
Len=024 ?
Kernel driver in use: nvidia
Kernel modules: nvidia


The problem.  After I am logged into KDE for a good while, like several
hours to maybe a day or so, the kicker thingy at the bottom locks up
tight.  I can't switch desktops, clock stops working, can't click the K
menu thingy either.  Everything in the kicker thingy is dead as a door
nail.  I can switch desktops with the keyboard and everything else works
in KDE just fine.  I can also switch to a console too.  Killing X and
restarting it fixes it, xdm restart in my case.  I don't have to reload
drivers or restart the system.  I do go back and downgrade the drivers
after testing it.

So, is this a nvidia bug, KDE bug or is it something else?  Since it
works when I go back a version of nvidia, it looks like nvidia.  Think
is, it only affects KDE and nothing else.  Is it possible that my card
is not supposed to use the 319.* series of drivers?  The versions that
don't work are all 319.* series. 

Thoughts? 

Dale

:-)  :-) 

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




Re: [gentoo-user] Nvidia drivers and KDE problem

2013-05-26 Thread Alan McKinnon
On 26/05/2013 11:12, Dale wrote:
 Howdy,
 
 I been letting portage upgrade nvidia drivers as usual.  Thing is, the
 last two or three drivers seems to cause a issue.  First, versions that
 cause the issue:
 
 =x11-drivers/nvidia-drivers-319.12
 =x11-drivers/nvidia-drivers-319.17
 =x11-drivers/nvidia-drivers-319.23
 
 I'm currently using this one which works fine:
 
 x11-drivers/nvidia-drivers-313.30
 
 This is KDE info:
 
 [IP-] [  ] kde-base/kdelibs-4.10.3-r2
 
 Video card info:
 
 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce GT
 220] (rev a2) (prog-if 00 [VGA controller])
 Subsystem: NVIDIA Corporation Device 069a
 Flags: bus master, fast devsel, latency 0, IRQ 18
 Memory at fb00 (32-bit, non-prefetchable) [size=16M]
 Memory at c000 (64-bit, prefetchable) [size=256M]
 Memory at de00 (64-bit, prefetchable) [size=32M]
 I/O ports at ef00 [size=128]
 [virtual] Expansion ROM at d000 [disabled] [size=512K]
 Capabilities: [60] Power Management version 3
 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
 Capabilities: [78] Express Endpoint, MSI 00
 Capabilities: [b4] Vendor Specific Information: Len=14 ?
 Capabilities: [100] Virtual Channel
 Capabilities: [128] Power Budgeting ?
 Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1
 Len=024 ?
 Kernel driver in use: nvidia
 Kernel modules: nvidia
 
 
 The problem.  After I am logged into KDE for a good while, like several
 hours to maybe a day or so, the kicker thingy at the bottom locks up
 tight.  I can't switch desktops, clock stops working, can't click the K
 menu thingy either.  Everything in the kicker thingy is dead as a door
 nail.  I can switch desktops with the keyboard and everything else works
 in KDE just fine.  I can also switch to a console too.  Killing X and
 restarting it fixes it, xdm restart in my case.  I don't have to reload
 drivers or restart the system.  I do go back and downgrade the drivers
 after testing it.
 
 So, is this a nvidia bug, KDE bug or is it something else?  Since it
 works when I go back a version of nvidia, it looks like nvidia.  Think
 is, it only affects KDE and nothing else.  Is it possible that my card
 is not supposed to use the 319.* series of drivers?  The versions that
 don't work are all 319.* series. 


I get a similar issue, my video card is an ATI and I use the radeon drivers.

Same symptom as you - plasma stops updating it's widgets like clocks and
stops responding to the mouse. Keyboard works.

In my case, it's usually linked to nfs and smb mounts that went away
(eg, if I forget to umount my NFS media server at home and go to work)
which indicates a blocking issue somehow. I've read many reports on the
internet that krunner is somehow involved, so that might be a good
starting point for investigation. krunner is the thing you get in KDE
when typing Alt-F2


-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] Nvidia drivers and KDE problem

2013-05-26 Thread Dale
Alan McKinnon wrote:
 I get a similar issue, my video card is an ATI and I use the radeon
 drivers. Same symptom as you - plasma stops updating it's widgets like
 clocks and stops responding to the mouse. Keyboard works. In my case,
 it's usually linked to nfs and smb mounts that went away (eg, if I
 forget to umount my NFS media server at home and go to work) which
 indicates a blocking issue somehow. I've read many reports on the
 internet that krunner is somehow involved, so that might be a good
 starting point for investigation. krunner is the thing you get in KDE
 when typing Alt-F2 

So this may not be a nvidia issue at all since you get the same with a
ATI card.  Right? 

What package provides the kicker thingy?  I think in KDE3 it was called
kicker but it appears to have changed to something else.  Is that
krunner that has it now?

Thanks.

Dale 

:-)  :-) 

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




Re: [gentoo-user] Nvidia drivers and KDE problem

2013-05-26 Thread Alan McKinnon
On 26/05/2013 11:51, Dale wrote:
 Alan McKinnon wrote:
 I get a similar issue, my video card is an ATI and I use the radeon
 drivers. Same symptom as you - plasma stops updating it's widgets like
 clocks and stops responding to the mouse. Keyboard works. In my case,
 it's usually linked to nfs and smb mounts that went away (eg, if I
 forget to umount my NFS media server at home and go to work) which
 indicates a blocking issue somehow. I've read many reports on the
 internet that krunner is somehow involved, so that might be a good
 starting point for investigation. krunner is the thing you get in KDE
 when typing Alt-F2 
 
 So this may not be a nvidia issue at all since you get the same with a
 ATI card.  Right? 

yes


 
 What package provides the kicker thingy?  I think in KDE3 it was called
 kicker but it appears to have changed to something else.  Is that
 krunner that has it now?

Maybe it's time you used the thingy suffix a little less and the real
names of things a little more :-)

What thing are you asking about? The panel that is usually at the bottom
and holds the plasma widgets? Or the thin popup you get with Alt-F2?

The panel is called plasma-desktop and comes from kde-base/plasma-workspace
The popup is krunner and comes from kde-base/krunner

I doubt very much it's a real bug as such in either KDE app (although
the fix might go in there). It looks much more to me like a side-effect
of IO blocking - two or more apps are trying to get something done and
unexpectedly are not getting answers, so they hang around waiting in the
doorway and get get in the way of everything else. And just for fun,
video drivers are also trying to get in on the act as they have to deal
with mouse pointer repaints...

Debugging this one is going to be fun (for peculiar definitions of fun)


-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] Nvidia drivers and KDE problem

2013-05-26 Thread Dale
Alan McKinnon wrote:
 On 26/05/2013 11:51, Dale wrote:

 What package provides the kicker thingy?  I think in KDE3 it was called
 kicker but it appears to have changed to something else.  Is that
 krunner that has it now?
 Maybe it's time you used the thingy suffix a little less and the real
 names of things a little more :-)

 What thing are you asking about? The panel that is usually at the bottom
 and holds the plasma widgets? Or the thin popup you get with Alt-F2?

 The panel is called plasma-desktop and comes from kde-base/plasma-workspace
 The popup is krunner and comes from kde-base/krunner

 I doubt very much it's a real bug as such in either KDE app (although
 the fix might go in there). It looks much more to me like a side-effect
 of IO blocking - two or more apps are trying to get something done and
 unexpectedly are not getting answers, so they hang around waiting in the
 doorway and get get in the way of everything else. And just for fun,
 video drivers are also trying to get in on the act as they have to deal
 with mouse pointer repaints...

 Debugging this one is going to be fun (for peculiar definitions of fun)



The thingy is the thing at the bottom where I can switch desktops, click
the K menu and where my clock is.  I think it was called Kicker in
KDE3.  KDE4 seems to have changed it but not sure what the new name is. 

I hope they fix this thing soon.  If they remove the driver from the
tree, I'm in a bit of a pickle. 

Dale

:-)  :-) 

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




Re: [gentoo-user] Nvidia drivers and KDE problem

2013-05-26 Thread Alan McKinnon
On 26/05/2013 13:03, Dale wrote:
 Alan McKinnon wrote:
 On 26/05/2013 11:51, Dale wrote:

 What package provides the kicker thingy?  I think in KDE3 it was called
 kicker but it appears to have changed to something else.  Is that
 krunner that has it now?
 Maybe it's time you used the thingy suffix a little less and the real
 names of things a little more :-)

 What thing are you asking about? The panel that is usually at the bottom
 and holds the plasma widgets? Or the thin popup you get with Alt-F2?

 The panel is called plasma-desktop and comes from kde-base/plasma-workspace
 The popup is krunner and comes from kde-base/krunner

 I doubt very much it's a real bug as such in either KDE app (although
 the fix might go in there). It looks much more to me like a side-effect
 of IO blocking - two or more apps are trying to get something done and
 unexpectedly are not getting answers, so they hang around waiting in the
 doorway and get get in the way of everything else. And just for fun,
 video drivers are also trying to get in on the act as they have to deal
 with mouse pointer repaints...

 Debugging this one is going to be fun (for peculiar definitions of fun)


 
 The thingy is the thing at the bottom where I can switch desktops, click
 the K menu and where my clock is.  I think it was called Kicker in
 KDE3.  KDE4 seems to have changed it but not sure what the new name is. 

It's a plasma widget called a panel, the only useful thing it does is to
be a container for other widgets that do useful stuff.

The panel is started by plasma-desktop as one of the standard widgets it
manages. The idea is to give you stuff on the screen that looks more or
less like a familiar desktop. Plasma can do other things and give you
completely different layouts; like for instance not giving you a panel
at all. This would be useful on a phone with small screen

The whole thing is heavily event based and has to react to a bucket load
of system events being generated such as what the mouse is doing.
There's a fantastic number of ways this could go wrong, some might be
plasma's fault, some might be faults that happen to plasma

 
 I hope they fix this thing soon.  If they remove the driver from the
 tree, I'm in a bit of a pickle. 

No, you won't be. You have the ebuild right now, copy it to your overlay
and remove becomes something that will not happen



-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] Nvidia drivers and KDE problem

2013-05-26 Thread Dale
Alan McKinnon wrote:
 On 26/05/2013 13:03, Dale wrote:
 Alan McKinnon wrote:
 On 26/05/2013 11:51, Dale wrote:

 What package provides the kicker thingy?  I think in KDE3 it was called
 kicker but it appears to have changed to something else.  Is that
 krunner that has it now?
 Maybe it's time you used the thingy suffix a little less and the real
 names of things a little more :-)

 What thing are you asking about? The panel that is usually at the bottom
 and holds the plasma widgets? Or the thin popup you get with Alt-F2?

 The panel is called plasma-desktop and comes from kde-base/plasma-workspace
 The popup is krunner and comes from kde-base/krunner

 I doubt very much it's a real bug as such in either KDE app (although
 the fix might go in there). It looks much more to me like a side-effect
 of IO blocking - two or more apps are trying to get something done and
 unexpectedly are not getting answers, so they hang around waiting in the
 doorway and get get in the way of everything else. And just for fun,
 video drivers are also trying to get in on the act as they have to deal
 with mouse pointer repaints...

 Debugging this one is going to be fun (for peculiar definitions of fun)


 The thingy is the thing at the bottom where I can switch desktops, click
 the K menu and where my clock is.  I think it was called Kicker in
 KDE3.  KDE4 seems to have changed it but not sure what the new name is. 
 It's a plasma widget called a panel, the only useful thing it does is to
 be a container for other widgets that do useful stuff.

 The panel is started by plasma-desktop as one of the standard widgets it
 manages. The idea is to give you stuff on the screen that looks more or
 less like a familiar desktop. Plasma can do other things and give you
 completely different layouts; like for instance not giving you a panel
 at all. This would be useful on a phone with small screen

 The whole thing is heavily event based and has to react to a bucket load
 of system events being generated such as what the mouse is doing.
 There's a fantastic number of ways this could go wrong, some might be
 plasma's fault, some might be faults that happen to plasma


I'll try to remember to call it a panel thingy then.  ROFL 


 I hope they fix this thing soon.  If they remove the driver from the
 tree, I'm in a bit of a pickle. 
 No, you won't be. You have the ebuild right now, copy it to your overlay
 and remove becomes something that will not happen




Last time I did that, it didn't work out well.  Actually, it just plain
didn't work.  May as well tell it like it is.  ;-)  I'll save a copy
just in case. 

Cross that bridge when I get there I guess. 

Dale

:-)  :-) 

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




Re: [gentoo-user] Nvidia drivers and KDE problem

2013-05-26 Thread Volker Armin Hemmann
Am 26.05.2013 11:12, schrieb Dale:
 Howdy,

 I been letting portage upgrade nvidia drivers as usual.  Thing is, the
 last two or three drivers seems to cause a issue.  First, versions that
 cause the issue:

 =x11-drivers/nvidia-drivers-319.12
 =x11-drivers/nvidia-drivers-319.17
 =x11-drivers/nvidia-drivers-319.23

 I'm currently using this one which works fine:

 x11-drivers/nvidia-drivers-313.30

 This is KDE info:

 [IP-] [  ] kde-base/kdelibs-4.10.3-r2

 Video card info:

 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce GT
 220] (rev a2) (prog-if 00 [VGA controller])
 Subsystem: NVIDIA Corporation Device 069a
 Flags: bus master, fast devsel, latency 0, IRQ 18
 Memory at fb00 (32-bit, non-prefetchable) [size=16M]
 Memory at c000 (64-bit, prefetchable) [size=256M]
 Memory at de00 (64-bit, prefetchable) [size=32M]
 I/O ports at ef00 [size=128]
 [virtual] Expansion ROM at d000 [disabled] [size=512K]
 Capabilities: [60] Power Management version 3
 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
 Capabilities: [78] Express Endpoint, MSI 00
 Capabilities: [b4] Vendor Specific Information: Len=14 ?
 Capabilities: [100] Virtual Channel
 Capabilities: [128] Power Budgeting ?
 Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1
 Len=024 ?
 Kernel driver in use: nvidia
 Kernel modules: nvidia


 The problem.  After I am logged into KDE for a good while, like several
 hours to maybe a day or so, the kicker thingy at the bottom locks up
 tight.  I can't switch desktops, clock stops working, can't click the K
 menu thingy either.  Everything in the kicker thingy is dead as a door
 nail.  I can switch desktops with the keyboard and everything else works
 in KDE just fine.  I can also switch to a console too.  Killing X and
 restarting it fixes it, xdm restart in my case.  I don't have to reload
 drivers or restart the system.  I do go back and downgrade the drivers
 after testing it.

 So, is this a nvidia bug, KDE bug or is it something else?  Since it
 works when I go back a version of nvidia, it looks like nvidia.  Think
 is, it only affects KDE and nothing else.  Is it possible that my card
 is not supposed to use the 319.* series of drivers?  The versions that
 don't work are all 319.* series. 

 Thoughts? 

 Dale

 :-)  :-) 


next time as root do:
killall -9 krunner
killall -9 plasma-desktop



[gentoo-user] nvidia-drivers fail to determine kernel version

2013-02-05 Thread meino . cramer
Hi,

when using vanilla kernel 3.7.5 (appropiate kernel headers installed)
emergeing nvidia-drivers 313.18 works fine.
As soon vanilla kernel 3.7.6 are installed the emerge process fails
because the kernel version couldnt be determined.

Both times /usr/src/linux symlinks to the according kernel sources.

What did I wrong? How can I fix that?

Thank you very much in advance for any help!
Best regards,
mcc






Re: [gentoo-user] nvidia-drivers fail to determine kernel version

2013-02-05 Thread Alexandre Domi
Note sure it's something wrong that you did, but that sure is strange... It
usually happens when switching from 3.x to 3.y kernel version...
When you're trying to emerge nvidia-drivers, are you running the recently
compiled kernel?


2013/2/5 meino.cra...@gmx.de

 Hi,

 when using vanilla kernel 3.7.5 (appropiate kernel headers installed)
 emergeing nvidia-drivers 313.18 works fine.
 As soon vanilla kernel 3.7.6 are installed the emerge process fails
 because the kernel version couldnt be determined.

 Both times /usr/src/linux symlinks to the according kernel sources.

 What did I wrong? How can I fix that?

 Thank you very much in advance for any help!
 Best regards,
 mcc







Re: [gentoo-user] nvidia-drivers fail to determine kernel version

2013-02-05 Thread meino . cramer
Hi Alexandre,

thanks for your reply! :)

Both kernels were compiled the same way prior to emergeing the
nvidia-drivers. In both cases the symlink /usr/src/linux points to
the correct kernel sources...
I also to booted into the kernel for which I want to emerge the
drivers which doesnt make a difference...

What else may be the reason for that?

Best regards,
mcc






Alexandre Domi crok.r...@gmail.com [13-02-05 16:04]:
 Note sure it's something wrong that you did, but that sure is strange... It
 usually happens when switching from 3.x to 3.y kernel version...
 When you're trying to emerge nvidia-drivers, are you running the recently
 compiled kernel?
 
 
 2013/2/5 meino.cra...@gmx.de
 
  Hi,
 
  when using vanilla kernel 3.7.5 (appropiate kernel headers installed)
  emergeing nvidia-drivers 313.18 works fine.
  As soon vanilla kernel 3.7.6 are installed the emerge process fails
  because the kernel version couldnt be determined.
 
  Both times /usr/src/linux symlinks to the according kernel sources.
 
  What did I wrong? How can I fix that?
 
  Thank you very much in advance for any help!
  Best regards,
  mcc
 
 
 
 
 




Re: [gentoo-user] nvidia-drivers fail to determine kernel version

2013-02-05 Thread Dale
meino.cra...@gmx.de wrote:
 Hi Alexandre,

 thanks for your reply! :)

 Both kernels were compiled the same way prior to emergeing the
 nvidia-drivers. In both cases the symlink /usr/src/linux points to
 the correct kernel sources...
 I also to booted into the kernel for which I want to emerge the
 drivers which doesnt make a difference...

 What else may be the reason for that?

 Best regards,
 mcc



Bug maybe?  I would search the forums then B.G.O. and see if it has been
reported there. 

Dale

:-)  :-) 

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




Re: [gentoo-user] nvidia-drivers fail to determine kernel version

2013-02-05 Thread Alexandre Domi
Hi,

It could be because it's hard coded in the nvidia sh script...
It used to be like that, don't know if it's still the case...
Le 5 févr. 2013 16:32, meino.cra...@gmx.de a écrit :

 Hi Alexandre,

 thanks for your reply! :)

 Both kernels were compiled the same way prior to emergeing the
 nvidia-drivers. In both cases the symlink /usr/src/linux points to
 the correct kernel sources...
 I also to booted into the kernel for which I want to emerge the
 drivers which doesnt make a difference...

 What else may be the reason for that?

 Best regards,
 mcc






 Alexandre Domi crok.r...@gmail.com [13-02-05 16:04]:
  Note sure it's something wrong that you did, but that sure is strange...
 It
  usually happens when switching from 3.x to 3.y kernel version...
  When you're trying to emerge nvidia-drivers, are you running the recently
  compiled kernel?
 
 
  2013/2/5 meino.cra...@gmx.de
 
   Hi,
  
   when using vanilla kernel 3.7.5 (appropiate kernel headers installed)
   emergeing nvidia-drivers 313.18 works fine.
   As soon vanilla kernel 3.7.6 are installed the emerge process fails
   because the kernel version couldnt be determined.
  
   Both times /usr/src/linux symlinks to the according kernel sources.
  
   What did I wrong? How can I fix that?
  
   Thank you very much in advance for any help!
   Best regards,
   mcc
  
  
  
  
  





Re: [gentoo-user] nvidia-drivers-304.64 build failure against vanilla linux-3.7.4

2013-01-29 Thread Raffaele BELARDI
On 01/27/2013 01:06 AM, staticsafe wrote:
 I just grabbed vanilla 3.7.4 from kernel.org, the kernel build itself
 went fine but when I did a modules-rebuild, the nvidia module failed to
 build. As requested by the error message:

I had the same problem, I had success with this:

https://devtalk.nvidia.com/default/topic/525699/linux/nvidia-linux-3-7-patch-fix/

I applied the patch and also had to create the link to version.h as
suggested towards the end of the page.
That was with gentoo-sources-3.7.4-something and nvidia-drivers-304.64
on ~amd64.

raf


[gentoo-user] nvidia-drivers-304.64 build failure against vanilla linux-3.7.4

2013-01-26 Thread staticsafe
I just grabbed vanilla 3.7.4 from kernel.org, the kernel build itself
went fine but when I did a modules-rebuild, the nvidia module failed to
build. As requested by the error message:

output of `emerge --info '=x11-drivers/nvidia-drivers-304.64'`:
http://sprunge.us/QLUN

output of `emerge -pqv '=x11-drivers/nvidia-drivers-304.64'`
http://sprunge.us/PfcV

complete build log:
http://sprunge.us/AQfS

Anyone have any ideas?

-- 
staticsafe
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post - http://goo.gl/YrmAb



Re: [gentoo-user] Nvidia-drivers + kernel 3.4

2012-06-15 Thread microcai
don't, use 295.59 :)

2012/6/15 Philip Webb purs...@ca.inter.net

 I haven't seen any mention of the problem here,
 but after installing Kernel 3.4 , Nvidia-drivers 295.49 wouldn't compile.
 The solution (via Google + Launchpad bugzilla) is to copy  4  header files
 from  /usr/src/linux/arch/arm/include/asm  to  -/-/-/-/x86/include/asm :
  system.h compiler.h system_info.h system_misc.h .

 Also the Ethernet kernel config lines have changed a bit
  I had to ask explicitly for my mobo's version with 'r8169'.

 HTH others

 --
 ,,
 SUPPORT ___//___,   Philip Webb
 ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
 TRANSIT`-O--O---'   purslowatchassdotutorontodotca





Re: [gentoo-user] Nvidia-drivers + kernel 3.4

2012-06-15 Thread Philip Webb
120615 microcai wrote:
 2012/6/15 Philip Webb purs...@ca.inter.net
 after installing Kernel 3.4 , Nvidia-drivers 295.49 wouldn't compile.
 The solution (via Google + Launchpad bugzilla) is to copy  4  header files
 from  /usr/src/linux/arch/arm/include/asm  to  -/-/-/-/x86/include/asm :
  system.h compiler.h system_info.h system_misc.h .
 Also the Ethernet kernel config lines have changed a bit
  I had to ask explicitly for my mobo's version with 'r8169'.
 don't, use 295.59 :)

Do you mean Don't use 295.59 or Don't use 295.49, use 295.59 ?
In any case, do you mean '295.49' or '295.53', the only versions available ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca




[gentoo-user] Nvidia-drivers + kernel 3.4

2012-06-14 Thread Philip Webb
I haven't seen any mention of the problem here,
but after installing Kernel 3.4 , Nvidia-drivers 295.49 wouldn't compile.
The solution (via Google + Launchpad bugzilla) is to copy  4  header files
from  /usr/src/linux/arch/arm/include/asm  to  -/-/-/-/x86/include/asm :
 system.h compiler.h system_info.h system_misc.h .

Also the Ethernet kernel config lines have changed a bit
 I had to ask explicitly for my mobo's version with 'r8169'.

HTH others

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca




Re: [gentoo-user] nvidia-drivers vs. nouveau

2012-04-13 Thread Canek Peláez Valdés
On Wed, Apr 11, 2012 at 4:36 PM, Canek Peláez Valdés can...@gmail.com wrote:
 On Wed, Apr 11, 2012 at 4:30 PM, Stefan G. Weichinger li...@xunil.at wrote:
 Am 11.04.2012 23:16, schrieb ny6...@gmail.com:

 I use the nouveau drivers because they update themselves when you update the
 kernel, and there's less work involved in keeping everything up to date. But
 I can't comment on the nvidia drivers since I've never tried them. Nouveau
 works well enough for me.

 See my other reply: Nikos hit the point.

 I actually changed to nouveau because the desktop performance of
 nvidia-drivers sucked at the time. I still use nvidia-drivers in my
 media center (because of VDPAU), but in my desktop I changed about
 year and a half ago, and I'm pretty happy with it.

 Before that, I used nvidia-drivers for many years, and it was always
 full of ups and downs; some versions worked great, others were barely
 usable. The nouveau drivers have been consistently good, even for
 small 3D use (things like Blender).

 If you don't use (modern) games, I highly recommend the nouveau
 drivers. For a modern desktop they work great.

Relevant to the thread, I believe:

Open-Source NVIDIA Driver Approaches Stable State
http://www.phoronix.com/scan.php?page=articleitem=nouveau_linux_stablenum=1

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México



Re: [gentoo-user] nvidia-drivers vs. nouveau

2012-04-12 Thread Alan McKinnon
On Wed, 11 Apr 2012 16:36:06 -0500
Canek Peláez Valdés can...@gmail.com wrote:

 On Wed, Apr 11, 2012 at 4:30 PM, Stefan G. Weichinger
 li...@xunil.at wrote:
  Am 11.04.2012 23:16, schrieb ny6...@gmail.com:
 
  I use the nouveau drivers because they update themselves when you
  update the kernel, and there's less work involved in keeping
  everything up to date. But I can't comment on the nvidia drivers
  since I've never tried them. Nouveau works well enough for me.
 
  See my other reply: Nikos hit the point.
 
 I actually changed to nouveau because the desktop performance of
 nvidia-drivers sucked at the time. I still use nvidia-drivers in my
 media center (because of VDPAU), but in my desktop I changed about
 year and a half ago, and I'm pretty happy with it.
 
 Before that, I used nvidia-drivers for many years, and it was always
 full of ups and downs; some versions worked great, others were barely
 usable. The nouveau drivers have been consistently good, even for
 small 3D use (things like Blender).
 
 If you don't use (modern) games, I highly recommend the nouveau
 drivers. For a modern desktop they work great.

I'll second that. I don't need blazing fast 3D performance, I do need
stable drivers that keep pace with kernel releases. I got tired of
having to remember to fully test nvidia-drivers every time I did a
kernel upgrade so switched to nouveau.

That was the previous laptop. This current one has an ATI card and I
use ati drivers rather than fglrx for the same reason.

The other killer was that I could never get nvidia-drivers to deal with
a multi-monitor setup in any kind of sane fashion. nVidia does do
multi-monitor, it just wants to present it in a way that made no sense
to me at all. Even something as simple as unplugging my desk monitor
and going to a meeting room to do a presentation on the projector
required an X restart.

-- 
Alan McKinnnon
alan.mckin...@gmail.com




Re: [gentoo-user] nvidia-drivers vs. nouveau

2012-04-12 Thread Helmut Jarausch

On 04/12/2012 09:09:16 AM, Alan McKinnon wrote:

That was the previous laptop. This current one has an ATI card and I
use ati drivers rather than fglrx for the same reason.


What's the difference (in performance) between fglrx and xf86-video-ati  
?

Do both of them support GPU usage?

Thanks for some info,
Helmut.




Re: [gentoo-user] nvidia-drivers vs. nouveau

2012-04-12 Thread Alan McKinnon
On Thu, 12 Apr 2012 10:06:17 +0200
Helmut Jarausch jarau...@igpm.rwth-aachen.de wrote:

 On 04/12/2012 09:09:16 AM, Alan McKinnon wrote:
  That was the previous laptop. This current one has an ATI card and I
  use ati drivers rather than fglrx for the same reason.
 
 What's the difference (in performance) between fglrx and
 xf86-video-ati ?
 Do both of them support GPU usage?

To be truthful, I really don't know the details.

My major overriding need is for the video driver to be in sync with the
rest of my software at all times so that portage can just do the right
thing (exactly like all the other drivers I use).

As long as the right pixels light up at the right time on the screen
and X does not crash, then I do not care about super video performance.

The open source ATI drivers completely fulfil my needs.


-- 
Alan McKinnnon
alan.mckin...@gmail.com




  1   2   3   >