Bug 426968 - nspluginwrapper wakes up too much
nspluginwrapper wakes up too much
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: nspluginwrapper (Show other bugs)
15
All Linux
low Severity medium
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
: Reopened, Triaged
: 467565 549311 651717 (view as bug list)
Depends On:
Blocks: wakeup F11Target 603588
  Show dependency treegraph
 
Reported: 2007-12-28 21:44 EST by Christopher Aillon
Modified: 2011-12-06 09:59 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 603588 (view as bug list)
Environment:
Last Closed: 2011-12-06 09:59:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
experimental patch (2.02 KB, patch)
2008-03-06 08:20 EST, Martin Stransky
no flags Details | Diff

  None (edit)
Description Christopher Aillon 2007-12-28 21:44:21 EST
Using powertop, running firefox with nspluginwrapper and sitting idle, I get this:

Top causes for wakeups:
  29.0% (209.3)      npviewer.bin : schedule_timeout (process_timeout)
Comment 1 David Rees 2008-01-18 15:24:01 EST
Same here, nspluginwrapper-0.9.91.5-16.fc8:

Top causes for wakeups:
  38.2% (192.5)      npviewer.bin : schedule_timeout (process_timeout) 
Comment 2 Arjan van de Ven 2008-03-05 22:35:12 EST
Most likely caused by the following gem in src/npw-viewer.c:


  g_source_set_priority(xt_source, GDK_PRIORITY_EVENTS);
  g_source_set_can_recurse(xt_source, TRUE);
  g_source_attach(xt_source, NULL);
  xt_event_poll_fd.fd = ConnectionNumber(x_display);
  xt_event_poll_fd.events = G_IO_IN;
  xt_event_poll_fd.revents = 0;
  g_source_add_poll(xt_source, &xt_event_poll_fd);

  gint xt_polling_timer_id = g_timeout_add(25,
                                                                               
    xt_event_polling_timer_callback,
                                                                               
    NULL);


this adds a timer to poll for Xt events rather than setting up a callback for 
when the event poll actually triggers. A dozen lines below that the code does 
do that for another case, so this makes me wonder what the author was thinking 
here.

I have a feeling that when this is fixed, the app will also behave smoother in 
addition to not waking the cpu up all the time
Comment 3 Martin Stransky 2008-03-06 08:20:39 EST
Created attachment 297045 [details]
experimental patch

Here is the patch. Added to package nspluginwrapper-0.9.91.5-24.fc9, please
test. It works fine for me but there could be some problems with processing X
window events...
Comment 4 Bill Nottingham 2008-04-17 17:24:41 EDT
Should this be in MODIFIED (or closed)?
Comment 5 Martin Stransky 2008-04-18 02:27:18 EDT
The patch is in CVS. Moved to modified.
Comment 6 Bug Zapper 2008-05-14 00:15:37 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Christopher Aillon 2008-06-09 19:22:55 EDT
Using nspluginwrapper-0.9.91.5-27.fc9.x86_64, this is much better:

  10.6% ( 63.5)      npviewer.bin : schedule_timeout (process_timeout) 

But still too much.
Comment 8 Martin Stransky 2008-10-22 06:00:00 EDT
*** Bug 467565 has been marked as a duplicate of this bug. ***
Comment 9 Christopher Aillon 2008-12-15 18:30:34 EST
Targeting this for F-11 (though we may want to do updates for F9/10 after ample rawhide testing).
Comment 10 Martin Stransky 2008-12-16 01:29:50 EST
The experimental patch breaks adobe reader plugin so it's removed from the package now.
Comment 11 Orion Poplawski 2009-04-22 11:38:38 EDT
F-10, nppdf and libflashplayer, in hidden tabs:

   7.0% (123.3)      npviewer.bin : hrtimer_start_expires (hrtimer_wakeup)

Just libflashplayer:

   5.8% ( 99.5)      npviewer.bin : hrtimer_start_expires (hrtimer_wakeup)

Just nppdf:

   2.6% ( 38.9)      npviewer.bin : hrtimer_start_expires (hrtimer_wakeup)

nspluginwrapper-1.3.0-2.fc10.i386
Comment 12 Tom London 2009-05-13 13:34:56 EDT
With latest FC11 RC/Rawhide, I'm still seeing: 

   3.9% (108.3)      npviewer.bin : hrtimer_start_range_ns (hrtimer_wakeup) 

This is with nspluginwrapper-1.3.0-5.fc11.x86_64, and with firefox running, but with no tabs open with anything requiring npviewer.bin.  A "now closed" tab did use flash:

 3215 ?        Sl     1:06 /usr/lib64/nspluginwrapper/npviewer.bin --plugin /usr/lib64/mozilla/plugins/libflashplayer.so --connectio

npviewer.bin appears to be accumulating about a seconds worth of CPU time every minute or 2.
Comment 13 William Lovaton 2009-11-02 21:10:19 EST
is there any other way to fix the wake ups without breaking the adobe reader plugin?
Comment 14 Bug Zapper 2009-11-18 02:50:22 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Jan "Yenya" Kasprzak 2009-11-18 06:27:27 EST
Do not close this bug, the comment #11 clearly mentions it is still present at least in F11.
Comment 16 udo 2010-01-10 11:07:57 EST
Add f12 please. npviewer eats too much CPU.
Comment 17 Martin Stransky 2010-02-24 14:22:57 EST
*** Bug 549311 has been marked as a duplicate of this bug. ***
Comment 18 udo 2010-02-24 23:10:43 EST
Is there a workaround for this longstanding (as it appears) issue?
Does gnash work well enough?
Or would installing the 64-bit flash (instead of wrapping 32-bit flash in 64-bit) help?
Comment 19 Oliver Henshaw 2010-02-25 06:03:17 EST
Will this be obsoleted in the medium term by mozilla's Out Of Process Plugin (Electrolysis) work?
Comment 20 Bug Zapper 2010-03-15 07:57:26 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 21 Jim Cromie 2010-05-07 11:52:21 EDT
me too.  ie:
occasionally sucks lots of cpu,
this has happened for several years.
Ive not correlated it with any particular flash-content/site/javascript/etc
I usually just kill npviewer, never noticed any loss of functionality.
(but then I dont count animated gifs, etc as functionality ;-)
Comment 22 Martin Stransky 2010-12-16 07:41:25 EST
*** Bug 651717 has been marked as a duplicate of this bug. ***
Comment 23 Bug Zapper 2011-06-02 14:36:36 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 24 Bug Zapper 2011-06-27 09:56:10 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 25 udo 2011-06-27 10:10:49 EDT
The bugzapper process a counter-productive.
It doesn't work for the end-user.
This bug has been open since 2007 and what progress was made?
So we close it and be done.
Even when it was filed against rawhide. (!)

I can suggest a workaround:

Install 64-bit flash from adobe.
Yes, still closed source, not so well-maintained as 32-bit, but no need for the wrapper.
And it even works.

I also tried gnash but that is not yet ready for prime time, sadly. It eats too much CPU and had issues with cookies.
Comment 26 udo 2011-06-27 10:11:20 EDT
The bugzapper process is counter-productive.
It doesn't work for the end-user.
This bug has been open since 2007 and what progress was made?
So we close it and be done.
Even when it was filed against rawhide. (!)

I can suggest a workaround:

Install 64-bit flash from adobe.
Yes, still closed source, not so well-maintained as 32-bit, but no need for the wrapper.
And it even works.

I also tried gnash but that is not yet ready for prime time, sadly. It eats too much CPU and had issues with cookies.
Comment 27 Martin Stransky 2011-12-06 09:59:21 EST
I have no idea how to fix it and don't break the nspluginwrapper itself plus there's an official 64-bit adobre flash plugin available so closing as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.