Under recent rt-amd64, startx on NV43 always freezes, altSysReqR doesn't

dlc · 08-23-12, 08:20 PM

I have reported this as Debian bug 684952 which is currently classed important. A comparable non-rt config works as does an older rt/X config. Some ssh session impacts have been observed. The kern.log reveals 120-second X timeouts. Please advise if I can perform any data capture that would be helpful in pinning this down, which is hopefully involved with similar freezes that have been reported (spin lock issues would be my guess).

dlc · 08-24-12, 02:11 PM

I upgraded nvidia-kernel to the recent repackaging, 304.37-1, without any change of behavior under the rt kernel. However, specifying -logverbose 6 induces monstrous initialization delay under the non-rt kernel, measured in minutes. I added reportbug outputs to the Debian bug report and will not be using that option any more since (hopefully) the additional details are static for this configuration.

trulan · 08-25-12, 07:44 AM

Hi dlc,

I've been having problems with the combination of rt kernels and nvidia drivers for years, both on 64bit and 32bit. When I need to do rt stuff on my box with an NVidia gpu, I have to use the vesa drivers, as the nvidia driver locks the system, and the nouveau driver just gives me a blank screen. I seem to have a fairly cantankerous NVidia chip - it's a GeForce 6150 LE.

The 2.6.31-rt and 2.6.33-rt kernels actually worked for me with the NVidia binary driver, but the problem re-surfaced with 3.0-rt. We are by no means the only ones who have this problem, as is obvious here:
http://article.gmane.org/gmane.linux.rt.user/7478

The problem remains with 3.4-rt, though thankfully it is no longer necessary to patch the NVidia driver to get it to build. Undoubtedly, the rt-preempt patch is changing something that breaks the driver for a significant minority of systems. But, it's hard to say what is really going on.

08-23-12, 08:20 PM	#1
dlc Registered User Join Date: Nov 2011 Location: Gaithersburg, Maryland, USA Posts: 2	Under recent rt-amd64, startx on NV43 always freezes, altSysReqR doesn't I have reported this as Debian bug 684952 which is currently classed important. A comparable non-rt config works as does an older rt/X config. Some ssh session impacts have been observed. The kern.log reveals 120-second X timeouts. Please advise if I can perform any data capture that would be helpful in pinning this down, which is hopefully involved with similar freezes that have been reported (spin lock issues would be my guess).

08-24-12, 02:11 PM	#2
dlc Registered User Join Date: Nov 2011 Location: Gaithersburg, Maryland, USA Posts: 2	Re: Under recent rt-amd64, startx on NV43 always freezes, altSysReqR doesn't I upgraded nvidia-kernel to the recent repackaging, 304.37-1, without any change of behavior under the rt kernel. However, specifying -logverbose 6 induces monstrous initialization delay under the non-rt kernel, measured in minutes. I added reportbug outputs to the Debian bug report and will not be using that option any more since (hopefully) the additional details are static for this configuration.

08-25-12, 07:44 AM	#3
trulan Registered User Join Date: Oct 2011 Posts: 5	Re: Under recent rt-amd64, startx on NV43 always freezes, altSysReqR doesn't Hi dlc, I've been having problems with the combination of rt kernels and nvidia drivers for years, both on 64bit and 32bit. When I need to do rt stuff on my box with an NVidia gpu, I have to use the vesa drivers, as the nvidia driver locks the system, and the nouveau driver just gives me a blank screen. I seem to have a fairly cantankerous NVidia chip - it's a GeForce 6150 LE. The 2.6.31-rt and 2.6.33-rt kernels actually worked for me with the NVidia binary driver, but the problem re-surfaced with 3.0-rt. We are by no means the only ones who have this problem, as is obvious here: http://article.gmane.org/gmane.linux.rt.user/7478 The problem remains with 3.4-rt, though thankfully it is no longer necessary to patch the NVidia driver to get it to build. Undoubtedly, the rt-preempt patch is changing something that breaks the driver for a significant minority of systems. But, it's hard to say what is really going on.