From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b4) Gecko/20050915 Fedora/1.5-0.5.0.beta1 Firefox/1.4

Description of problem:
$ uptime; sleep 5; uptime
 00:54:54 up 50 min,  9 users,  load average: 189451.99, 137666.98, -444284.58
 00:54:59 up 50 min,  9 users,  load average: -440573.58, 267158.71, 625579.97

Need I say more? :-)

Load varies wildly pretty much forever.  If you're lucky, leaving the actual load close to 0 for some time from a half hour to 4 hours gets the first load average to a reasonable number, enabling mail delivery et al, but sometimes it stabilizes at a very large number instead.  Even after it stabilizes, random load fluctuations may cause it to get wild again.

Version-Release number of selected component (if applicable):
kernel-2.6.13-1.1594_FC5 (started at kernel-2.6.13-1.1580_FC5 or so; 1578 didn't have it for sure)

How reproducible:
Always

Steps to Reproduce:
1.Boot up a UP Athlon64 notebook

Actual Results:  Load average numbers are nonsensical.  The load distribution printed by top doesn't seem reasonable either.

Expected Results:  1578 had it right

Additional info:

Brian Gerst <bgerst> mentioned this problem on lkml one or two days ago, saying it only occurred with SMP enabled in the kernel build (like the default x86_64 kernel).  Today, he followed up:

I found the culprit: CPU hotplug.  The problem is that
prefill_possible_map() is called after setup_per_cpu_areas().  This
leaves the per-cpu data sections for the future cpus uninitialized
(still pointing to the original per-cpu data, which is initmem).
Since the cpus exists in cpu_possible_map, for_each_cpu will iterate
over them even though the per-cpu data is invalid.