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)
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
Brian Gerst <firstname.lastname@example.org> 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.
*** This bug has been marked as a duplicate of 169962 ***