Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 286159 - www-plugins/adobe-flash 64bit lahf_lm multiprocessor machine can benefit from 'taskset'
Summary: www-plugins/adobe-flash 64bit lahf_lm multiprocessor machine can benefit from...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal enhancement (vote)
Assignee: Jeroen Roovers (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-24 01:13 UTC by Gordon
Modified: 2016-12-15 09:14 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gordon 2009-09-24 01:13:23 UTC
This is a bug in the fix for bugs:
268336
273718

The ebuild for adobe-flash on amd64 now checks to make sure that at least one processor in /proc/cpuinfo has the lahf_lm instruction.  In some rare cases a multiprocessor machine will have one processor that has the lahf_lm instruction and another processor that lacks that instruction.  When firefox gets migrated to the processor that lacks lahf_lm, and adobe-flash is installed, firefox crashes.

I used taskset to ensure that using

Reproducible: Always

Steps to Reproduce:
1.  Have multiprocessor amd64 computer with at least one processor with lahf_lm and one processor without lahf_lm.
2.  Install mozilla-firefox and adobe-flash.
3.  Run and use mozilla-firefox until it crashes.

Actual Results:  
mozilla-firefox crashes

Expected Results:  
mozilla-firefox does not crash

I suggest that the ebuild check for any processors that lack lahf_lm instead of ensuring that at least one processor supports lahf_lm.  This will prevent unexpected crashes, but it is not my prefered solution.

I have aliased firefox="taskset 0x0000000A firefox" to prevent firefox from using the lahf_lm'less processor. In addition to the basic solution above I would like to see warning message when this situation has occurred along with override flag that would allow the user to provide their own solution such as taskset.

Sorry I don't have access to the affected machine right now, so I can't post 'emerge --info'.  Also this is my first bug report, so I apologize in advance for non-conformity, improper placement, etc.
Comment 1 Jim Ramsay (lack) (RETIRED) gentoo-dev 2010-03-27 14:56:52 UTC
Note to self: I think this comparison will do the right thing, checking if *any* of the processors are missing the flag instead of just the first one:

if grep '^flags' /proc/cpuinfo | grep -qv 'lahf_lm'; then
   ...
Comment 2 Jim Ramsay (lack) (RETIRED) gentoo-dev 2010-03-27 15:15:58 UTC
I have put the basic *any* versus *all* fix in for now.  The warning and override will take a little more work, so I'm leaving this bug open for now.

First stage fixed in adobe-flash-10.0.45.2-r1
Comment 3 Jim Ramsay (lack) (RETIRED) gentoo-dev 2010-07-27 14:33:03 UTC
Updating summary and priority.

Unfortunately since adobe-flash-10.1 is released 32-bit only *again* I'm not sure when this will need to get fixed.  But we'll hang on to this bug a while longer.
Comment 4 Gordon 2010-11-30 17:42:21 UTC
Thank-you for the fix.  Unfortunately gcc -march=native started to compile using that flag so I gave in and found a perfectly identical processor to swap out.  The fix looks like it will work but I no longer have a machine to test against if adobe-flash comes out in 64 bit again.