Re: [gentoo-user] Re: X segfault with nvidia-drivers-295.40 on GT520

[Michael Mol]

On Thu, May 3, 2012 at 10:13 AM, Raffaele BELARDI
<raffaele.belardi@××.com> wrote:
> On 05/03/2012 08:50 AM, Nikos Chantziaras wrote:
>> On 03/05/12 09:39, Raffaele BELARDI wrote:
>>> One month ago I switched to an Nvidia-based (ASUS GT520, PCI-e) video
>>> card on an ~amd64 box. I immediately had problems with the latest Nvidia
>>> driver causing a segfault when X started (text console is ok) so I
>>> switched to 295.20-r1 and everything was fine.
>>>
>>> But I forgot to mask 295.40 and during yesterday's update it got pulled
>>> in again, with the same segfault behaviour when starting X.
>>>
>>> I tried to manually downgrade nvidia-drivers but now glibc is upgraded
>>> to 2.15-r1 and nvidia-drivers-295.20-r1 depends on an older glibc
>>> (2.14.1-r3, I think). Emerge refuses to downgrade glibc so I am stuck.
>>>
>>> Since it is a mythtv box I want to stay away from nouveau. No problem
>>> myself with it but most of the mythtv development is around proprietary
>>> nvidia drivers.
>>>
>>> What other options do I have?
>>> Is everybody running nvidia-drivers-295.40 without problems?
>>
>> No problems here, but you can try 302.07 (I run those since yesterday.)
>>   The usual way: copy the ebuild in your local overlay and rename it to
>> nvidia-drivers-302.07.ebuild, then do a digest.  Same for
>> nvidia-settings, but edit it and remove the patches.
>
> thanks, but I'd rather  keep that as a last option because I have no
> guarantee of success with the 302.07 driver.
>
> Another possibility came to my mind: I have a backup partition which I
> did not upgrade since I switched from the on-board ATI GPU to the Nvidia
> video card.
> I'll try to upgrade that partition masking >nvidia-drivers-295.20-r1.
>
> It'd be interesting to understand why I'm getting the segfault with the
> 295.40, but being a closed driver I suppose there is little I can diagnose.

Emerge with --ggdb3, enable core dumps (I forget the particular
sysctl, sorry), and open up the core dump in gdb. At the very least,
you might get something interesting if the segfault happens in a stack
frame belonging to an open-source function a closed blob links to, or
if the segfault happens in a pure portion of the stack.

(For example, on my broken boxes, the stack hadn't gotten into
application-specific portions; it was still trying to get into the
general CRT prologue code.)

-- 
:wq