X segfault with nvidia-drivers-295.40 on GT520
 

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?

thanks,

raffaele

X segfault with nvidia-drivers-295.40 on GT520
 

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.

X segfault with nvidia-drivers-295.40 on GT520
 

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.

raffaele

X segfault with nvidia-drivers-295.40 on GT520
 

On Thu, May 3, 2012 at 10:13 AM, Raffaele BELARDI
<raffaele.belardi@st.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

X segfault with nvidia-drivers-295.40 on GT520
 

On 05/03/2012 04:22 PM, Michael Mol wrote:
>> 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.)

X prints a backtrace when it segfaults and I saw some nvidia_* stuff I
*think* at the top of the stack. I'll re-check and possibly try your
suggestion.

raffaele

X segfault with nvidia-drivers-295.40 on GT520
 

On 03/05/12 17:13, Raffaele BELARDI 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.


There are no guarantees in life. Only wasted time, which in this case
amounts to 5-8 minutes for copying/editing and emerging. If you even
need a guarantee even for not losing 8 minutes of your time, then I
don't know :-/

X segfault with nvidia-drivers-295.40 on GT520
 

On 05/03/2012 04:45 PM, Nikos Chantziaras wrote:
>> thanks, but I'd rather keep that as a last option because I have no
>> guarantee of success with the 302.07 driver.
>
> There are no guarantees in life. Only wasted time, which in this case
> amounts to 5-8 minutes for copying/editing and emerging. If you even
> need a guarantee even for not losing 8 minutes of your time, then I
> don't know :-/

You are right, it might be a quick solution if it works.
What kernel and xorg-server version are you running with 302.07?

thanks,

raffaele

X segfault with nvidia-drivers-295.40 on GT520
 

On 03/05/12 18:18, Raffaele BELARDI wrote:

On 05/03/2012 04:45 PM, Nikos Chantziaras wrote:

thanks, but I'd rather keep that as a last option because I have no
guarantee of success with the 302.07 driver.


There are no guarantees in life. Only wasted time, which in this case
amounts to 5-8 minutes for copying/editing and emerging. If you even
need a guarantee even for not losing 8 minutes of your time, then I
don't know :-/


You are right, it might be a quick solution if it works.
What kernel and xorg-server version are you running with 302.07?


Latest versions available on ~amd64. So that's kernel 3.3.4 and
xorg-server 1.12.1.


Remember that for nvidia-settings, you need to delete (or comment-out)
the two patch lines after you copy the ebuild:


epatch "${FILESDIR}/0001-Makefile-improvements.patch"
epatch "${FILESDIR}/0002-Build-libNVCtrl-with-PIC.patch"

X segfault with nvidia-drivers-295.40 on GT520
 

On 05/02/2012 11:39 PM, 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

I make this ridiculous suggestion only because you're still having trouble.

The ebuild for the proprietary ati-drivers includes this advice:

"If you experience unexplained segmentation faults and kernel crashes"
"with this driver and multi-threaded applications such as wine,"
"set UseFastTLS in xorg.conf to either 0 or 1, but not 2."

Hey, how much time can you waste testing it with nvidia-drivers ;)

X segfault with nvidia-drivers-295.40 on GT520
 

On 05/03/2012 08:33 AM, 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.

Just an update: there is a new nvidia-drivers-295.49 in portage, with
this I no longer have an X segfault but the screen is blank and keyboard
is dead (Num Lock not responsive, CTR-ALT-F1 or CTRL-ALT-Backspace have
no effect). I can ssh into the box and X seems running happily, no
errors in the xorg.log but no video. The syslog contains some "Xid"
lines which according to the nvidia README indicate that a general GPU
error occurred:

NVRM: Xid (0000:01:00): 31, Ch 00000000, engmask 00000101, intr 10000000
NVRM: os_schedule: Attempted to yield the CPU while in atomic or
interrupt context
NVRM: os_schedule: Attempted to yield the CPU while in atomic or
interrupt context
NVRM: Xid (0000:01:00): 56, CMDre 00000000 00000088 0100cb05 00000007
00000000
NVRM: Xid (0000:01:00): 56, CMDre 00000000 0000008c 00000000 00000005
00000008
NVRM: Xid (0000:01:00): 56, CMDre 00000000 00000088 0100cb0b 00000007
00000000
NVRM: Xid (0000:01:00): 56, CMDre 00000000 0000008c 00000000 00000005
00000008
HDMI hot plug event: Codec=0 Pin=5 Presence_Detect=1 ELD_Valid=0
NVRM: Xid (0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005
00000008
HDMI status: Codec=0 Pin=5 Presence_Detect=1 ELD_Valid=0
HDMI hot plug event: Codec=0 Pin=5 Presence_Detect=0 ELD_Valid=1
HDMI status: Codec=0 Pin=5 Presence_Detect=1 ELD_Valid=1
HDMI: detected monitor SAMSUNG
at connection type HDMI
HDMI: available speakers: FL/FR
HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100
48000, bits = 16 20 24

Investigation goes on.

raffaele