could you try 2 things?

- reload factory settings, save user defaults and restart

- change sound system in the preferences to `None` (save and reload)

The very familiar issue was reported a while ago. It was related on measurement plugin. Disabling it returned blender to normal cpu usage.

No response in a week.
Given information is not enough to figure out why this happens, but it was noticed Measurement addon might lead to such situations. Make sure it's disabled and if high CPU usage still occurs for you, we'll need exact steps how to reproduce the issue to fix it.
Thanks for the report, but will close it until more info is provided.

im sorry this has taken so long but i didnt have time to track down the cause of this problem. hwoever i found it today and am able to reproduce it every time on different systems and different builds.

so here is how to reproduce it.
1. load factory defaults.
2. go into user preferences > system and change "Window Draw Method" to "Full"
3. save this as user default (restarting blender is required to make the load happen)
4. restart blender
5. now comes the fun part, with the default scene go crazy with the viewport navigation, and when i say crazy i mean CRAZY:D the cpu load has to reach about 50% or so to make it happen.
6. open your taskmanager . performance tab and check the core usage. you should see that one core is stuck at 100%.

so this is how i can reproduce this every time on different systems (all windows7, intel cpus and nvidia cards) and different builds (trunk , official 2.62)

Reopening.
Tried to reproduce myself without luck. Maybe somebody else is able to reproduce?

hm on my system at home im unable to reproduce the problem:/
here i can not get the cpu usage over 30%, and ive only seen the 100% usage happening when the cpu usage is at about 50%+ in total.
i will do some more testing tomorrow on the systems where i got the problem.

tested on a 4th system, also with intel cpu, nvidia card and windows 7 64 pro. and could reproduce the behavior every time as well. might this have something to do with the hardware/os combination? because on all the intel/nvidia/win systems i test it i get the same issue.

got it again today with "Triple Buffer", so maybe its not the draw method that causes it but just makes it happen faster if its set to full since it causes more load.
so when the load is above a certain threshold something will hang.

dan, did you test changing sound system to sdl/none as Campbell suggested in first post?

So far can't reproduce the issue on laptop with nvidia card and intel cpu. Would ask other devs with access to windows to test this.

i have sound disabled in the configuration i work with and where it happens frequently, i can try to set it to sdl if that should make a difference.
i can cause the issue on 5 systems here (did not test more) but i dont think the draw method is the problem, i think it just helps it happening since fuill uses a bit more cpu power and therefore goes over the threshold where the issue apears.

I ran into this issue as well, but couldn't determine how it happened.

I ran a heavy normal-map bake (selected to active, used around 6GB RAM according to task mgr), CPU went to 25% (I have 4 cores) as usual, then strangely at 50% (Normal mapping baking doesn't use multiple cores AFAIK) and after the baking the CPU stayed at constant 25% from Blender. I thought it would be related to the mem consumption (swap file went crazy as I only have 4GB of physical RAM) but it didn't go away after a while.

I didn't give it much importance since restarting Blender solved it, but now I see this ticket. I wasn't able to reproduce it again, even though I did several similar backings afterwards.
If I see it again I'll ran the debugger.

My specs:
Intel Core 2 Quad Extreme X9650 3Ghz
4 GB RAM (2 sticks)
500GB HDD
GeForce 8600 GTS 512MB
Windows 7 64-bit
Using official Blender 2.63 for 64-bit

so i took some hours today to find the reason which causes this and i have found one addon with which i can reproduce it every time so i guess that was the problem all the time.
maybe theres an other addon that causes this under different circumstances but only time will tell for now.
how i can reproduce it:
enable the Ogre exporter (there are 2 so you need the correct one from the "official thread" in the link below" or the attachment) and then split blender window so you have 2 x 3d views. save that as default and restart blender and after a couple of seconds one core gets stuck at 100% (at least on my system).

the addon is a ogre exporter which is still in developement so its not in the official version (strange i thought i got the problem with factory settings as well)

http://www.ogre3d.org/tikiwiki/Blender+2.5+Exporter
follow the link to the "official thread" http://www.ogre3d.org/forums/viewtopic.php?f=8&t=64019

Can confirm the issue here. Not sure whether it's something to do with our code or it's Py API misusage.
Would check on that.

This is an issue in addon itself. Left a message in their forum about possible way how to solve this.

Nothing to do with a Blender itself, so think this report could be closed for until issue is reproduced with Ogre addon disabled.

@dan, great job on tracing glitchy addon, thanks!

unfortunately i encountered the 100% lock again but its really hard to track it down if its not reproducable every time:(

dan, do you mean you managed to reproduce it with Ogre addon disabled by default?

yes, i got the 100% lock with ogre addon "disabled" but i could not reproduce it again, maybe its some other strange combination that triggers it. i will try to keep an eye on the core usage and maybe i can reproduce what i did when it happens again and reproduce it.

i was able to reproduce the core lock with factory reset after all:O

how to reproduce:
1. load factory defaults
2. go into edit mode
3. open the proerties panel (N)
4. expand all the tabs
5. enable vertex and face normals in display panel
6. save this as dafault (i ccould only reproduce it on startup)
7. close blender
8. start blender
9. drag the display tab in the properties panel one up or down.
10. hover the mouse cursor over the face normal button until the description popup apears.
11. check the core usage, if it worked one core is locked at 100% now.

Doesn't happen here on linux. Are you on windows?

yes i am on windws 7 64bit pro

also i need to do step 9-10 fairly quick after startign blender or else it doesnt happen. but since ive seen the lock during a blender session as well (not from start) this might happen in some special cases as well. mayb when splitting the view and do step 9-10 or something like that.
its just how i was able to reproduce the issue about 8 of 10 times.

hm i can not reproduce this on my system at home which also has windows 7. at this point i have no idea why this happens on my work machine:/

this is getting pretty annoying, i have to restart blender every 15min or so because of this now. when the core is stuck at 100% blender is super laggish which is not much fun to work with:/

was really nobody able to reproduce this? iv set up a new system yesterday and have the exact same thing there:/

why was this closed exactly? its not fixed...

re-opening.

i run a profiler on blender when the core lock happens and attached the results. i used verysleepy for profiling http://www.codersnotes.com/sleepy/
i hope that gives more clues about what s going on

I don't know why it's assigned to me, i can not reproduce issue on none of my computers. Not actually sure ow to interpret profiling results, but quite enough of time nvidia driver is using.

you refere to the "nvoglv64" module?
so i guess i need to try an other clean wipe install of the nvidia drivers but the last system i got it had a AMD card inside so not sure if thats really the problem. will try it anyways. the question is what driver would be best because i have this for quite some time now and maybe its cause with a certain version...

so i tried again to clean install the Nvidia drivers and i even flashed the latest bios and reinstalled the chipset drivers but i still have the same issue.
is there anything else that i can do that would help you figure out why this happens here?

oh and i noticed that step 10 is not needed. aparently it already locks to 100% when i move a panel as soon as blender loaded. so i dont think i can narrow it down any further on my side. i guess its something in the panel rearanging code or so that messes up and creates an endless loop or something but im sure you know better than i do.

Panel draw happens from main thread, so if deadlock would have been happened there, the whole blender will be frozen. It could be so some sequence of opengl commands makes some driver unhappy, but that's difficult to figure out without having access to system which glitches.

Did you try reproducing this issue on other computers since the issue in ogre was tracked down? Does it now happen with default startup.blend (anyway, having your startup.blend could help a lot here). Are you installing drivers from nvidia site (unfortunately, drivers from computer vendor could be buggy)? Do you have other applications running in the background while you're using blender?

Attaching startup.blend with which i was able to reproduce the issue. SImply move edge between viewports up/down fast enough.

I can confirm this issue with Sergey's startup.blend (picture attached).

Blender 2.64 (r52458)
Intel i7 950@3.07Ghz
18GB DDR3 Ram
Nvidia GeForce 560Ti 448

It seems that the picture didnt attach correctly. Here is a direct link
http://img.photobucket.com/albums/v299/metalliandy/100_percent_cpu_metalliandy.jpg

Andrew, the file is actually Dan's. He gave it to me in IRC, i only attached it here so it wouldn't loss.

I'll bisect throw drawing code later today/tomorrow.

Cool, Thanks for clarifying, Sergey.

I've spent quite a while trying to figure out which part of code in blender causes it. Apparently it's widgetbase_draw function which is used to draw all widgets. Disabling any half of widgets in attached startup.blend prevents CPU core from lock.

My guess here is that the issue happens when number of opengl instructions passes some threshold value and high CPU usage is caused by some threading issue in nvidia driver (vertex and color buffers are sending to gpu in a separated thread, which could be a culprit).

I'll move the report to OpenGL tracker and will try to find some help from nvidia..

Moved from Blender 2.6 Bug Tracker to OpenGL errors

is there any news on this issue?

Dan, i've submitted some notes to their customer feedback, but doubt it'll make things moving.

Currently Brecht is waiting apprval in OpenGL/Game development program in NVidia's developer zone. This would allow to submit bugs more direct to developers. Not sure when they'll see request from Brecht tho.