Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 12-23-10, 11:29 AM   #13
voegel
Registered User
 
Join Date: Dec 2010
Posts: 12
Default Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

I am also getting the above error message frequently w/ 260.19.29. I have attached the nvidia bug report.

This problem came with the update to ubuntu 10.10. So I suspect a problem that came with an update of either kernel or X server.

Any ideas?

Sebastian
Attached Files
File Type: gz nvidia-bug-report.log.gz (71.3 KB, 81 views)
voegel is offline   Reply With Quote
Old 12-24-10, 09:20 PM   #14
damentz
Registered User
 
Join Date: Jan 2009
Posts: 59
Default Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

I noticed that on the newer drivers, AccelerateTrapezoids is enabled and that causes X to freeze noticeably when minimizing and reopening windows.

Try turning them off and see if that helps.
damentz is offline   Reply With Quote
Old 12-27-10, 04:40 PM   #15
voegel
Registered User
 
Join Date: Dec 2010
Posts: 12
Default Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

Thanks for the hint. Unfortunately no change. I don't even know if this option is supported by my onboard 6150LE.
voegel is offline   Reply With Quote
Old 01-11-11, 05:58 PM   #16
voegel
Registered User
 
Join Date: Dec 2010
Posts: 12
Default Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

Bump.

I am still having this issue. Any news?
voegel is offline   Reply With Quote
Old 01-11-11, 06:31 PM   #17
jpi110
Gentoo User
 
Join Date: Jan 2011
Location: Portland, Oregon
Posts: 14
Default Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

Quote:
Originally Posted by voegel View Post
Bump.

I am still having this issue. Any news?
I haven't heard anything either. So, I decided to test to see if it was hardware or drivers.

I plugged in a Windows 7 harddrive (which it did take me a while to find as I don't use Windows normally) via an eSATA port. I used the 'current' drivers for Windows. This introduced flickering on textures in 3d environments some of the time. But, it was stable otherwise. So, I went a step further. I decided to test to see how far I could push stability and installed the latest beta drivers for Windows. The flickering went away. The performance is slightly better. And absolutely no stability issues.

So, this tells me that the problem is decidedly not hardware related. Identical hardware. Identical BIOS settings. The only deltas relevant here is OS and drivers. Since the OS (and kernel) were fine until recent changes in the nVidia drivers, I am now forced to unequivocally conclude that the issue lies solely within the drivers.

Unfortunately, the nature of the crash is not leaving any debugging within the X server log file other than to say the drivers detected a crash and was trying (and never succeeding) to recover. Outside of the same error messages you're getting, I am not sure where else to look to try to determine the cause.
jpi110 is offline   Reply With Quote
Old 01-12-11, 05:08 AM   #18
voegel
Registered User
 
Join Date: Dec 2010
Posts: 12
Default Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

I think the problem came up with the update to the latest xorg 1.9. On ubuntu 10.04 everything was fine with driver 256.xx. If I revert to this version under ubuntu 10.10/xorg 1.9 that produces the same results.

I have also eliminated a HW related issue.

Sebastian
voegel is offline   Reply With Quote
Old 01-14-11, 02:34 PM   #19
jpi110
Gentoo User
 
Join Date: Jan 2011
Location: Portland, Oregon
Posts: 14
Angry Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

Quote:
Originally Posted by voegel View Post
I think the problem came up with the update to the latest xorg 1.9. On ubuntu 10.04 everything was fine with driver 256.xx. If I revert to this version under ubuntu 10.10/xorg 1.9 that produces the same results.

I have also eliminated a HW related issue.

Sebastian
I tested 2 GTX 275s vs 2 GTX 295s. No change or improvement in stability. This rules out possibly bad video cards.

BIOS features are at identical settings for both Linux and Windows. Hardware-wise, all combinations seem to work fine in Windows. That definitely rules out hardware.

On my Gentoo system, I'm using just 1.9.2. (Url: http://packages.gentoo.org/package/x11-base/xorg-server platform: amd64) And, it's using the amd64 keyword. Meaning, I'm not using what Gentoo considers unstable. Masked by the ~amd64 keyword are 1.9.2.902 and 1.9.3.901. I haven't tried with either of those yet.

I also don't use crazy or unacceptable optimization flags. (-O2 -march=native -mtune=native -pipe). That rules out possible unstable or aggressive optimization flags. I've tried nvidia-drivers with and without the custom-optimization keyword. No improvement there either.

However, I am inclined to this think the issue is within the nvidia drivers (for Linux) with certain CPU/GPU combinations.

Now, moving to the next sequence of tests, no kernel version supported by the drivers in Linux (with the dual quad-core opteron 2378s) seems to yield any more or less stability. That rules out a kernel issue. (2.6.34-gentoo-r1, 2.6.34-ck-r3, 2.6.36-gentoo-r5, 2.6.36-ck-r5 tested. 2 of which are stable {gentoo kernels} and 2 of which are ck patchsets added to the stable gentoo kernels {ck}).

Looking at the patch notes for 260.19.29: Fixed a bug that caused some OpenGL applications to become unresponsive for up to a minute on some GPUs when changing the resolution or refresh rate.

In my case, I wasn't changing resolution or refresh rate when the instability manifested itself. Though, this is decidedly pointing to a driver issue specifically within the OpenGL area with respect to either the GPU or CPU - or combination of them.

Looking at a further patch note going backward: Fixed a regression introduced after 256.35 that caused stability problems on GPUs such as GeForce GT 240.

I'm thinking that the issue here lies within the nVidia implementation of OpenGL on Linux for a specific set of GPU and/or CPU combinations. That would explain why the Windows iterations do not manifest this problem. Windows uses DirectX where possible and OpenGL where it is not. The application in question does definitely use DirectX in Windows and OpenGL in Linux.

I will have to do some more testing, but initial indications on a new CPU platform and motherboard (otherwise identical OS/kernel/drivers/video cards/hard drives in Linux) suggest that the issue could have been resolved at the moment. Or, more accurately, the nVidia drivers don't seem to blow up with this combination.

I have since moved to an ASUS M4N98TD Evo board with 1 AMD Phenom II X6 1090T (Black edition) CPU -- previously on a Supermicro H8DA8-2 with 2 AMD Opteron 2378s (quad core). The ASUS + 1090T combination in Linux appears to be stable at the moment. I will do more testing later this weekend to see if I can get it to crash.

Matrix as follows:

Kernel/OS CPU/Motherboard Nvidia Drivers Nvidia Cards Result
------------------- ------------------------------------------ ----------------- ------------------ -------
2.6.34-gentoo-r1 SuperMicro+2 AMD Opteron 2378 260.19.29 2 GTX 295-SLI FAIL
2.6.36-gentoo-r5 SuperMicro+2 AMD Opteron 2378 260.19.29 2 GTX 295-SLI FAIL
2.6.34-ck-r3 SuperMicro+2 AMD Opteron 2378 260.19.29 2 GTX 295-SLI FAIL
2.6.36-ck-r5 SuperMicro+2 AMD Opteron 2378 260.19.29 2 GTX 295-SLI FAIL
2.6.34-gentoo-r1 SuperMicro+2 AMD Opteron 2378 260.19.21 2 GTX 295-SLI FAIL
2.6.36-gentoo-r5 SuperMicro+2 AMD Opteron 2378 260.19.21 2 GTX 295-SLI FAIL
2.6.34-ck-r3 SuperMicro+2 AMD Opteron 2378 260.19.21 2 GTX 295-SLI FAIL
2.6.36-ck-r5 SuperMicro+2 AMD Opteron 2378 256.53 2 GTX 295-SLI FAIL
2.6.34-gentoo-r1 SuperMicro+2 AMD Opteron 2378 256.53 2 GTX 295-SLI FAIL
2.6.36-gentoo-r5 SuperMicro+2 AMD Opteron 2378 256.53 2 GTX 295-SLI FAIL
2.6.34-ck-r3 SuperMicro+2 AMD Opteron 2378 256.53 2 GTX 295-SLI FAIL
2.6.36-ck-r5 SuperMicro+2 AMD Opteron 2378 256.53 2 GTX 295-SLI FAIL
2.6.34-gentoo-r1 SuperMicro+2 AMD Opteron 2378 195.36.31 2 GTX 295-SLI SUCCESS {3}
2.6.36-gentoo-r5 SuperMicro+2 AMD Opteron 2378 195.36.31 2 GTX 295-SLI SUCCESS {3}
2.6.34-ck-r3 SuperMicro+2 AMD Opteron 2378 195.36.31 2 GTX 295-SLI SUCCESS {3}
2.6.36-ck-r5 SuperMicro+2 AMD Opteron 2378 195.36.31 2 GTX 295-SLI SUCCESS {3}


Windows 7 64bit SuperMicro+2 AMD Opteron 2378 266.35 2 GTX 295-SLI SUCCESS
Windows 7 64bit SuperMicro+2 AMD Opteron 2378 260.99 2 GTX 295-SLI SUCCESS {1}

2.6.34-gentoo-r1 SuperMicro+2 AMD Opteron 2378 260.19.29 2 GTX 275-SLI FAIL
2.6.36-gentoo-r5 SuperMicro+2 AMD Opteron 2378 260.19.29 2 GTX 275-SLI FAIL
2.6.34-ck-r3 SuperMicro+2 AMD Opteron 2378 260.19.29 2 GTX 275-SLI FAIL
2.6.36-ck-r5 SuperMicro+2 AMD Opteron 2378 260.19.29 2 GTX 275-SLI FAIL
2.6.34-gentoo-r1 SuperMicro+2 AMD Opteron 2378 260.19.21 2 GTX 275-SLI FAIL
2.6.36-gentoo-r5 SuperMicro+2 AMD Opteron 2378 260.19.21 2 GTX 275-SLI FAIL
2.6.34-ck-r3 SuperMicro+2 AMD Opteron 2378 260.19.21 2 GTX 275-SLI FAIL
2.6.36-ck-r5 SuperMicro+2 AMD Opteron 2378 260.19.21 2 GTX 275-SLI FAIL
2.6.34-gentoo-r1 SuperMicro+2 AMD Opteron 2378 256.53 2 GTX 275-SLI FAIL
2.6.36-gentoo-r5 SuperMicro+2 AMD Opteron 2378 256.53 2 GTX 275-SLI FAIL
2.6.34-ck-r3 SuperMicro+2 AMD Opteron 2378 256.53 2 GTX 275-SLI FAIL
2.6.36-ck-r5 SuperMicro+2 AMD Opteron 2378 256.53 2 GTX 275-SLI FAIL
2.6.34-gentoo-r1 SuperMicro+2 AMD Opteron 2378 195.36.31 2 GTX 275-SLI SUCCESS {3}
2.6.36-gentoo-r5 SuperMicro+2 AMD Opteron 2378 195.36.31 2 GTX 275-SLI SUCCESS {3}
2.6.34-ck-r3 SuperMicro+2 AMD Opteron 2378 195.36.31 2 GTX 275-SLI SUCCESS {3}
2.6.36-ck-r5 SuperMicro+2 AMD Opteron 2378 195.36.31 2 GTX 275-SLI SUCCESS {3}


2.6.36-ck-r5 ASUS M4N98TD EVO+AMD 1090T 260.19.29 2 GTX 295-SLI SUCCESS {2}

Key:
{1} Flickering was detected on 3D textures (fixed by using beta drivers)
{2} Tentatively, this looks successful. Will know more after extensive testing.
{3} Flickering was detected on 2D and 3D textures - making view of the screen quite difficult.

Last edited by jpi110; 01-14-11 at 06:15 PM. Reason: Added Gentoo Packages link. Also added tested configurations.
jpi110 is offline   Reply With Quote
Old 01-14-11, 05:56 PM   #20
voegel
Registered User
 
Join Date: Dec 2010
Posts: 12
Default Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

Thanks for the information. Keep us updated. I am really looking for a solution. Even if that means downgrading the nvidia driver.
voegel is offline   Reply With Quote

Old 01-14-11, 06:53 PM   #21
jpi110
Gentoo User
 
Join Date: Jan 2011
Location: Portland, Oregon
Posts: 14
Default Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

Quote:
Originally Posted by voegel View Post
Thanks for the information. Keep us updated. I am really looking for a solution. Even if that means downgrading the nvidia driver.
At this point, what might yield usable, though not optimal, results would probably be to downgrade to the 195.36.31 drivers. I can't say with certainty as the next set of drivers supposedly fixes bugs so it may depend on your hardware configuration. (Your mileage may vary.)

It netted some flickering in 2D/3D environments for me but did not otherwise introduce spinlock crashes. Try that and see if it works for you. It would certainly confirm in your environment whether or not the driver is the cause.
jpi110 is offline   Reply With Quote
Old 01-15-11, 01:55 PM   #22
voegel
Registered User
 
Join Date: Dec 2010
Posts: 12
Default Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

Quote:
Originally Posted by jpi110 View Post
At this point, what might yield usable, though not optimal, results would probably be to downgrade to the 195.36.31 drivers. I can't say with certainty as the next set of drivers supposedly fixes bugs so it may depend on your hardware configuration. (Your mileage may vary.)

It netted some flickering in 2D/3D environments for me but did not otherwise introduce spinlock crashes. Try that and see if it works for you. It would certainly confirm in your environment whether or not the driver is the cause.
Unfortunately the 195.xx version is unsuitable for me, because I then have problems with HDMI audio. This only works flawlessly on my hardware with 256.xx and up.

Interestingly though, a downgrade to 256.xx doesn't solve the problem, whereas in Mythbuntu 10.04 I didn't have any trouble with that version.
voegel is offline   Reply With Quote
Old 01-15-11, 09:23 PM   #23
jpi110
Gentoo User
 
Join Date: Jan 2011
Location: Portland, Oregon
Posts: 14
Default Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

Quote:
Originally Posted by voegel View Post
Unfortunately the 195.xx version is unsuitable for me, because I then have problems with HDMI audio. This only works flawlessly on my hardware with 256.xx and up.

Interestingly though, a downgrade to 256.xx doesn't solve the problem, whereas in Mythbuntu 10.04 I didn't have any trouble with that version.
I understand the HDMI audio issue. The point isn't necessarily to keep that version indefinitely but use it as part of diagnostic methodology. If the driver is otherwise stable (minus HDMI audio), that tells you the kernel + hardware is fine.

As an interesting point of reference, I have been running for hours now without an issue with the change in CPU/motherboard in Linux. Mind you, the previous combination worked fine in windows. Thus, this tells me the issue is with the nvidia drivers and that CPU/GPU combination (my previous post with the hardware/software matrix is still valid in my tests).

Update: 01/18/2011. I ran all day Saturday and Sunday with the change in CPU/motherboard just fine. I'm unclear as to what within the driver could cause the issue with Opteron 2378s under Linux but works fine under Windows. I am relatively convinced that it is either something within the kernel module itself (most likely by far) with a lowering probability that the proprietary OpenGL implementation is the cause.

Perhaps we should be asking a different question: How many other folks have multiple CPUs (I'm not talking multiple cores here. So if you only have 1 CPU chip that has 2+ cores, that isn't what I mean.)? e.g. CPU chip 1 and CPU chip 2.

Maybe the proprietary kernel module cannot properly schedule time if there are multiple physical CPUs vs multiple logical CPUs.

Last edited by jpi110; 01-18-11 at 12:43 PM.
jpi110 is offline   Reply With Quote
Old 01-20-11, 04:58 AM   #24
oyvind
Registered User
 
Join Date: May 2004
Location: Norway
Posts: 117
Unhappy Re: NVRM: os_schedule: Attempted to yield the CPU while in atomic[...] [260.19.21 x86

I tried using the latest 260.19.29 driver for a while, to see if things were in fact stable, even though scary errors are spewed out into my kernel log at times. Suspend/resume works, and the system looks stable on the surface.. .. Except for the "gray screen of death" that just hit me. Out of nowhere (when editing in Emacs), system froze and screen turned completely ## GRAY ##. Alt+SysRq dead, network dead, everything dead. So it is not usable nor stable in practice, which would also be the logical conclusion judging by the look of the error messages that appear in the kernel log. It was worth a shot, I guess ..

Please consider releasing something that works for the NVS 3100M and that is as stable as 195.36-series. Because 195.36.24 is solid (I've had uptime for more than a month using this driver, with lots of suspend/resume and hibernate cycles). If you need more information, logs or debugging data, please let me know, I'd be glad to help in any way I can ..
oyvind is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 08:00 AM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.