First, please try 1.8.4.3 which should be in updates-testing.  Then can you go into the asterisk console and enable debugging to see of there's anything obvious?

Updating:
 asterisk                   x86_64   1.8.4.3-1.fc15     updates-testing   2.6 M
Updating for dependencies:
 asterisk-alsa              x86_64   1.8.4.3-1.fc15     updates-testing    83 k
 asterisk-festival          x86_64   1.8.4.3-1.fc15     updates-testing    79 k
 asterisk-jabber            x86_64   1.8.4.3-1.fc15     updates-testing   145 k
 asterisk-voicemail         x86_64   1.8.4.3-1.fc15     updates-testing    80 k
 asterisk-voicemail-plain   x86_64   1.8.4.3-1.fc15     updates-testing   147 k

arbol*CLI> core set debug 100
Core debug was 0 and is now 100
arbol*CLI> core set verbose 100
Verbosity was 1 and is now 100
arbol*CLI> 
<no output of any type>

The cpu that asterisk is running on (this is a 4-core system) is still 100% used up.
Top shows 75% idle (1 of 4 cores in a spin loop) and shows 100% for asterisk's CPU usage in the bottom half of the display.

Is there something specific I should turn on to trace where asterisk is chewing up the CPU?  Strace didn't show anything the last time I tried it indicating it is looping in user space.

I don't normally use anything but the core package so it's probably something in one of the other packages that you have that has a bad default config that is driving the CPU usage up.  Try removing the subpackages one at a time and see what happens.  Also check the audit logs to see if there are any selinux AVCs.  "ausearch -x /usr/sbin/asterisk" should filter out the uninteresting stuff.

Loaded plugins: langpacks, presto, refresh-packagekit
Installed Packages
asterisk.x86_64                           1.8.4.3-1.fc15   @updates-testing     
asterisk-debuginfo.x86_64                 1.8.4.3-1.fc15   @updates-testing-debuginfo
Available Packages
...

I've removed all the asterisk-* packages except the base and the debuginfo.  I still see the looping.

I wonder how my system is different from yours.  Are you testing on a 64-bit OS?

Sealert is currently nonfunctional.  Seems someone broke a library api.

 Opps, sealert hit an error!

Traceback (most recent call last):
  File "/usr/bin/sealert", line 692, in <module>
    run_as_dbus_service(username)
  File "/usr/bin/sealert", line 112, in run_as_dbus_service
    app = SEAlert(user, dbus_service.presentation_manager, watch_setroubleshootd=True)
  File "/usr/bin/sealert", line 326, in __init__
    from setroubleshoot.browser import BrowserApplet
  File "/usr/lib64/python2.7/site-packages/setroubleshoot/browser.py", line 46, in <module>
    import report.io.GTKIO
ImportError: No module named GTKIO

Looking at the /var/log/audit/audit.log file directly I don't see any avc's (or anything) between the start and stop printfs.

type=SERVICE_START msg=audit(1309208473.597:290): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="asterisk" exe="/bin/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1309208855.958:291): user pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="asterisk" exe="/bin/systemd" hostname=? addr=? terminal=? res=success'

One difference that we may have in our systems is that I have 1) multiple network inferfaces and I have ipv6 enabled and in use.

I don't have multiple interfaces on my asterisk systems but I do use ipv6.  One difference is that I usually don't start asterisk up until after I've done some basic configuration, especially SIP.  One other way to track down the source of the problem is to unload individual modules (or block them from loading in the first place) to see which one may be causing the problem.

Can you try adding the following lines to /etc/asterisk/modules.conf and see if it fixes this problem?

noload => chan_mgcp.so
noload => res_pktccops.so

See bug#658431 for more information.

Adding the two noload lines did the trick.  fixed.  thanks!

*** This bug has been marked as a duplicate of bug 658431 ***