Quadro FX 2800M - lockups, resets, ...

Chris M · 03-07-11, 03:25 PM

Hello together!

please find attached five different nvidia-bug-report.log.gz that I recorded on my Dell Precision M6500 equipped with a Quadro FX 2800M.

This system runs Kubuntu 10.10 - and I had problems with their stock graphics driver (260.19.06) as well newer nVidia drivers that I installed through the PPA.

This system had very frequent xserver restarts bringing me back to login, xserver hang ups, sometimes a flickering screen (where - I guess - the xserver also reseted itself).
It seemed to help to disable PowerMizer by setting

Code:

   Option  "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerLevel=0x2; PowerMizerDefault=0x2; PowerMizerDefaultAC=0x2"

in the xorg.conf.
It also seems that the newest drivers are more stable - but I still get this bug every few hours.

After the first three reports I let the system run some more time - still getting lockups, flickering, etc. Even after updating to the latest driver again...

At the report 2011-02-27 14:27 the system froze but I could remote login to create the report. The PowerMizer was activated.

At the report 2011-02-27 23:04 the screen flickered white (multiple times with quite a time between the events) but was still usable (although a bit slower afterwards). The PowerMize was disabled.

Can you please help me to fix this issue - or I will have to return this laptop as an unstable system is useless for me.

Thanks,
Christian Mayer

PS: This is also recorded at
https://bugs.launchpad.net/nvidia-dr...tu/+bug/694611
https://bugs.launchpad.net/ubuntu/+s...rs/+bug/717873

Licaon · 03-08-11, 05:51 AM

can you try to disable HPET: http://ubuntuforums.org/showthread.php?t=1269421 ?

Chris M · 03-13-11, 03:45 PM

Thanks for the hint. It looks like it helps most of the time (even with activated PowerMizer!). I changed in /etc/default/grub the relevant line to

Code:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash hpet=disable"

But today I had a hard lockup again, no remote login was possible any more. At least the kern.log had a bit of information of the hang up:

Quote:

Originally Posted by kern.log

Mar 13 10:43:55 obiwan kernel: [ 336.183261] CE: hpet increased min_delta_ns to 7500 nsec
Mar 13 10:45:45 obiwan kernel: [ 445.890899] CE: hpet increased min_delta_ns to 11250 nsec
Mar 13 10:45:45 obiwan kernel: [ 445.890976] CE: hpet increased min_delta_ns to 16875 nsec
Mar 13 10:45:45 obiwan kernel: [ 445.891044] CE: hpet increased min_delta_ns to 25312 nsec
Mar 13 10:46:55 obiwan kernel: [ 516.495496] NVRM: Xid (0000:01:00): 6, PE0003

Hm, any more ideas?

(And what's the reasoning behind disabling the HPET?)

Licaon · 03-14-11, 02:56 AM

Why do you still have HPET related info in kern.log ? bizzare
Can you attach the full /etc/defaults/grub.conf ?

AFAIK, HPET is a good idea but badly implemented: https://secure.wikimedia.org/wikiped.../HPET#Problems

Can you try a newer kernel: https://groups.google.com/group/linu...86a9fd8e630303 ?

Chris M · 03-15-11, 04:08 PM

Thanks for the hint - I'll look if there's an other way to disable HPET...

BTW: Attached is also a new nVidia bug report - this time with a nice backtrace...

Licaon · 03-16-11, 07:06 AM

Quote:

Originally Posted by Chris M

Thanks for the hint - I'll look if there's an other way to disable HPET...

you did not run update-grub after editing grub.conf, right?
as i see from your log:

Quote:

[ 26.739] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.35-27-generic root=UUID=11a4d9bf-46d1-48d9-b353-2404262ec219 ro quiet splash

you have no HPET disabling option at boot

Chris M · 03-17-11, 04:43 PM

Quote:

Originally Posted by Licaon

you did not run update-grub after editing grub.conf, right?

You got me...

Now it's set - but two more crashes occured (one each day

) - attached is report from today.

Now I'll investigate the switch to a new kernel.

Chris M · 03-18-11, 05:08 PM

Still with the usual kernel (2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:46 UTC 2011 x86_64 GNU/Linux) and with disabled HPET I got again a crash where the screen flickered.

Attached is the nvidia bug report as well the redirected output of the startx command (startx -- -logverbose 6 > log 2>&1).

This time again with a backtrace:

Code:

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x45c5a8]
1: /usr/bin/X (mieqEnqueue+0x1f4) [0x458ea4]
2: /usr/bin/X (xf86PostMotionEventP+0xc4) [0x488d74]
3: /usr/bin/X (xf86PostMotionEvent+0xa9) [0x488f19]
4: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7fa5183db000+0x37b3) [0x7fa5183de7b3]
5: /usr/lib/xorg/modules/input/synaptics_drv.so (0x7fa5183db000+0x5d48) [0x7fa5183e0d48]
6: /usr/bin/X (0x400000+0x6d4e7) [0x46d4e7]
7: /usr/bin/X (0x400000+0x1161a3) [0x5161a3]
8: /lib/libpthread.so.0 (0x7fa51edbc000+0xfb40) [0x7fa51edcbb40]
9: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0xb4542) [0x7fa5195d4542]
10: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0x784ff) [0x7fa5195984ff]
11: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0xdb165) [0x7fa5195fb165]
12: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0xdecd1) [0x7fa5195fecd1]
13: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0xc72e1) [0x7fa5195e72e1]
14: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0xbb6cb) [0x7fa5195db6cb]
15: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0xb3d84) [0x7fa5195d3d84]
16: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0xb44ae) [0x7fa5195d44ae]
17: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0x774bb) [0x7fa5195974bb]
18: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0xdb3c3) [0x7fa5195fb3c3]
19: /usr/lib/xorg/extra-modules/nvidia_drv.so (0x7fa519520000+0x4001de) [0x7fa5199201de]
20: /usr/bin/X (0x400000+0xd34fa) [0x4d34fa]
21: /usr/bin/X (0x400000+0x3f979) [0x43f979]
22: /usr/bin/X (0x400000+0x2187b) [0x42187b]
23: /lib/libc.so.6 (__libc_start_main+0xfe) [0x7fa51dd27d8e]
24: /usr/bin/X (0x400000+0x21409) [0x421409]

Chris M · 03-19-11, 06:48 AM

Switching to the newest kernel didn't work for me (using the Natty PPA version as described on the net) but I've changed to the newest version for Maveric (2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:39:03 UTC 2011 x86_64 GNU/Linux)

Still with HPET disabled I had a lock up this morning where the mouse could be moved but the system didn't react. Remote login showed that the Xorg was taking 100% CPU...
Bug report is attached again.

Are there any more ideas?
Might it be a hardware defect?

Licaon · 03-19-11, 07:46 PM

what's the problem with the latest kernel ?

can't your try 2.6.36? 2.6.37 ?

hmm, this might be ACPI related as the ACPI service keeps restarting or re-assesing the video card + monitor ( ACPI: Failed to switch the brightness ), can you set PowerMizer on Prefer Maximum Performance:

Quote:

Option "RegistryDwords" "PowerMizerEnable=0x1; PowerMizerLevel=0x1; PowerMizerDefault=0x1; PowerMizerDefaultAC=0x1"

( i see you want Balanced but do try this too )
actually this might not be anything at all...

the infamous [mi] Overflowing bug + os_raise atomic bug too seem present, can you disable the touchpad when using a mouse ( not that Microsoft IntelliMouse and not one from Logitech as most [mi] errors seem related to that brand

) ?

also try to mess around MTRR as you have some uncacheable entries: http://www.nvnews.net/vbulletin/show...8&postcount=39 ( not a solution but it does not hurt )

**danix** · 03-21-11, 07:42 PM

Hello Chris M,

Have you found a way (preferably automated) to trigger the crash on demand? Based on the suspicion that PowerMizer is involved, we tried running the following on our M6500 overnight to see if it would crash, but it didn't:

Code:

while true; do nvidia-settings -a [gpu:0]/GPUPowerMizerMode=$[$RANDOM%2]; sleep 2; done

This basically randomly changes the PowerMizer mode between "Adaptive" and "Prefer Maximum Performance" every two seconds. If the system is otherwise idle while this runs, then it ought to switch between the fastest and slowest clocks. Does your system crash when running this for extended periods of time? If not, can you identify something that will so that we can try to get ours to crash?

Thanks.

Chris M · 03-27-11, 09:06 AM

Hallo danix

Quote:

Originally Posted by danix

Have you found a way (preferably automated) to trigger the crash on demand?

Sadly not.

Quote:

Originally Posted by danix

Based on the suspicion that PowerMizer is involved, we tried running the following on our M6500 overnight to see if it would crash, but it didn't:

Code:

while true; do nvidia-settings -a [gpu:0]/GPUPowerMizerMode=$[$RANDOM%2]; sleep 2; done

I tried that line for a short period of time. But as the PowerMizer mode switch itself isn't causing the troubles I've enhanced that to:

Code:

start=$SECONDS;count=0;count0=0;count1=0;while true; do count=$((count+1));mode=$((RANDOM%7<1));count0=$((count0+(mode==0)));count1=$((count1+(mode==1)));echo $count: $((SECONDS-start)) Seconds after start. Mode 0: $count0, Mode 1: $count1. Temperature `nvidia-settings -t -q [thermalsensor:0]/ThermalSensorReading` °C;nvidia-settings -a [gpu:0]/GPUPowerMizerMode=$mode; sleep 10; done

This will stay mostly in adaptive mode and sometimes kick in to performance mode. So the frequencies will change as much as possible.
That run fine so I stopped it, the last lines were:

Quote:

1726: 17609 Seconds after start. Mode 0: 1486, Mode 1: 240. Temperature 48 °C

Attribute 'GPUPowerMizerMode' (obiwan:0[gpu:0]) assigned value 0.

I.e. after nearly 5 hours running idle and only switching frequencies I couldn't force a hang up. (Temperatures stayed between 48°C and 53°C)

Thinking of it, it seems to me that mostly (allways?) the hang ups and crashes happen during user interaction. A very typical setup is that I'm reading a web page (i.e. everything is idle) and are switching to a different program (e.g. email client) that might even be on a different screen. I.e. the xserver has to handle mouse events and a graphic intense workload out of an idle state.
During long periods of leaving the laptop in an idle state hardly any (or even "no"?) hang ups occured.

03-08-11, 05:51 AM	#2
Licaon Registered User Join Date: Nov 2004 Location: Between the keyboard and the chair. Posts: 490	Re: Quadro FX 2800M - lockups, resets, ... can you try to disable HPET: http://ubuntuforums.org/showthread.php?t=1269421 ?

03-21-11, 07:42 PM	#11
danix NVIDIA Corporation Join Date: Feb 2010 Location: Santa Clara, CA Posts: 237	Re: Quadro FX 2800M - lockups, resets, ... Hello Chris M, Have you found a way (preferably automated) to trigger the crash on demand? Based on the suspicion that PowerMizer is involved, we tried running the following on our M6500 overnight to see if it would crash, but it didn't: Code: while true; do nvidia-settings -a [gpu:0]/GPUPowerMizerMode=$[$RANDOM%2]; sleep 2; done This basically randomly changes the PowerMizer mode between "Adaptive" and "Prefer Maximum Performance" every two seconds. If the system is otherwise idle while this runs, then it ought to switch between the fastest and slowest clocks. Does your system crash when running this for extended periods of time? If not, can you identify something that will so that we can try to get ours to crash? Thanks.

03-14-11, 02:56 AM	#4
Licaon Registered User Join Date: Nov 2004 Location: Between the keyboard and the chair. Posts: 490	Re: Quadro FX 2800M - lockups, resets, ... Why do you still have HPET related info in kern.log ? bizzare Can you attach the full /etc/defaults/grub.conf ? AFAIK, HPET is a good idea but badly implemented: https://secure.wikimedia.org/wikiped.../HPET#Problems Can you try a newer kernel: https://groups.google.com/group/linu...86a9fd8e630303 ?