summaryrefslogtreecommitdiffstats
path: root/Documentation/hwmon
diff options
context:
space:
mode:
authorAmul Shah <amul.shah@unisys.com>2007-02-13 13:26:20 +0100
committerAndi Kleen <andi@basil.nowhere.org>2007-02-13 13:26:20 +0100
commit54413927f022292aeccadd268fbf1c0b42129945 (patch)
treece5aa0834b56519e8a202e1ae25b878fb124b9e1 /Documentation/hwmon
parent076422d2af7e3d8e72c6e70843f6ea377714b082 (diff)
downloadkernel-crypto-54413927f022292aeccadd268fbf1c0b42129945.tar.gz
kernel-crypto-54413927f022292aeccadd268fbf1c0b42129945.tar.xz
kernel-crypto-54413927f022292aeccadd268fbf1c0b42129945.zip
[PATCH] x86-64: x86_64-make-the-numa-hash-function-nodemap-allocation fix fix
- Removed an extraneous debug message from allocate_cachealigned_map - Changed extract_lsb_from_nodes to return 63 for the case where there was only one memory node. The prevents the creation of the dynamic hashmap. - Changed extract_lsb_from_nodes to use only the starting memory address of a node. On an ES7000, our nodes overlap the starting and ending address, meaning, that we see nodes like 00000 - 10000 10000 - 20000 But other systems have nodes whose start and end addresses do not overlap. For example: 00000 - 0FFFF 10000 - 1FFFF In this case, using the ending address will result in an LSB much lower than what is possible. In this case an LSB of 1 when in reality it should be 16. Cc: Andi Kleen <ak@suse.de> Cc: Rohit Seth <rohitseth@google.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Andi Kleen <ak@suse.de>
Diffstat (limited to 'Documentation/hwmon')
0 files changed, 0 insertions, 0 deletions