3.64 KB, text/plain
4.12 KB, text/plain
3.83 KB, text/plain
3.46 KB, text/plain
4.29 KB, text/plain
15.13 KB, text/plain
2.64 KB, text/plain
I just noticed that Chimera 2002121304 was chewing up 100% cpu time in top. I put the system to sleep and then woke it up and chimera immediately returned to normal (minimal) cpu usage.
whoops should have left this UNCO
I could swear this is a dupe
Assignee: saari → sfraser
Hrm, I fixed a bug with big cpu usage when waking from sleep. Simon: if you see this again, please run sampler.
Status: NEW → ASSIGNED
During high cpu usage. Also, note what windows chimera is showing. Is the caret blinking in a text field in the page content? Are there animated GIFs?
Created attachment 110734 [details] a sample Frontmost window is http://www.w3.org/TR/xpath I don't think there's any textboxes or animated gifs in there. I have five tabs open, also: http://www.w3.org/TR/xslt#named-templates http://localhost/form.html?=&= -- has a form but no cursor, or blinking http://www.w3.org/TR/html401/interact/forms.html#h-17.5 http://www.oasis-open.org/committees/relax-ng/tutorial-20011203.html
Created attachment 110736 [details] another sample Taken just after the first one. Note that as I write in in another chimera window, chimera is still sucking the CPU. There's also another process running high. it's odd, it's PID 0 : kernel_tas (that's all that top shows, I guess it's kernel_task). This does not show up in ps -aux, and I cannot run sample on it from the command line. top -u says e.g.: 452 Navigator 68.8% 30:18.86 8 152 565 25.9M 30.1M+ 32.9M 130M 0 kernel_tas 26.6% 8:18.09 28 0 - - - 26.0M 325M
See ifyou can reconstruct what I was doing based on the pages I had open in comment #6 ;-)
That is this thread? 150 Thread_5303 150 _pthread_body 150 CAPThread::Entry(CAPThread*) 150 HALRunLoop::OwnThread(void*) 150 CFRunLoopRunSpecific 150 __CFRunLoopRun 150 mach_msg 150 mach_msg_trap 150 mach_msg_trap [STACK TOP] I don't see that on my machine.
Agreed. I don't have that on my navigator right now either (behaving normally). also - based on a mach trap corrolates with the high kernel CPU usage - HAL is for hardware abstraction layer ... something to do with audio?
The plot thickens. I just woke up my PB and saw the kernel process meter on "Spy" (in the toolbar) was at 100% but the user process meter was normal. I went into top and saw kernel_process (PID 0) was sucking all the CPU up, but the computer was still usable. Navigator was /not/ sucking the CPU. On a hunch I quit Navigator and the kernel CPU usage dropped back to normal. Sorry, I didn't get a sample.
Attachment #112005 - Attachment mime type: application/octet-stream → text/plain
Attachment #112005 - Attachment description: sample3a → sample3a - after wake from sleep
Attachment #112007 - Attachment description: sample3c - after 3rd sleep cycle → sample3c - after 3rd sleep cycle - back to normal CPU usage
I just had this again. I woke the system from sleep and found chimera was sucking CPU cycles. I sampled (3a) and then cycled sleep. To my surprise it was again spinning (3b) and so was Mail.app (3d). I killed off Mail which was not responding, although chimera was responding OK. Then I sleep cycled again and navigator was back to normal (3c). I forgot to sample chimera after killing mail and before sleeping. I also grabbed some screen scapes of top with expanded -uw output.
Note that my machine is a normal production machine, but it has some slight flakiness in that the fan never comes on when it overheats and sometimes that causes a kernel panic if I'm running DVDs, iTunes and charging the battery. However since this occurred after sleeping, I doubt the computer was hot. The system is a TiBook/400 with 256 ram, 10.2.3 currently, and 2003010804 currently.
nominating topembed as it may also affect embedding customers
Discussed in edt. Plussing.
Keywords: topembed → topembed+
We need more info on this bug, in particular, how it relates to bug 197863, and bug 197889.
if other apps have some issues (mail.app), and it's at the kernel level, and your fan doesn't always know to come on, i think you've got bigger problems :(
Could be. It's definitely flaky in the overheating thing.
Removing topembed+, since this is not obviously a problem for most people, and bug 197863 is the one we should care about.
Keywords: topembed+ → topembed
Discussed in topembed bug triage. Minusing.
Keywords: topembed → topembed-
Simon could you update this issue with a newer build ?
I haven't seen this since I got a new computer. I'll close it, and reopen if I ever see it again.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.