Skip to content

L
linux
Switch branch/tag
  1. 20 Mar, 2007 3 commits
    • Jay Lan's avatar
      [IA64] Fix typo/thinko in crash.c · 60b548df
      Jay Lan authored 
      Clearly should be checking for "val == DIE_INIT_SLAVE_ENTER".
Signed-off-by: default avatarJay Lan <jlan@sgi.com>
Acked-by: default avatarSimon Horman <horms@verge.net.au>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      60b548df
    • Jack Steiner's avatar
      [IA64] Fix get_model_name() for mixed cpu type systems · c5e83e3f
      Jack Steiner authored 
      If a system consists of mixed processor types, kmalloc()
can be called before the per-cpu data page is initialized.
If the slab contains sufficient memory, then kmalloc() works
ok. However, if the slabs are empty, slab calls the memory
allocator. This requires per-cpu data (NODE_DATA()) & the
cpu dies.

Also noted by Russ Anderson who had a very similar patch.
Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      c5e83e3f
    • Zou Nan hai's avatar
      [IA64] min_low_pfn and max_low_pfn calculation fix · a3f5c338
      Zou Nan hai authored 
      We have seen bad_pte_print when testing crashdump on an SN machine in
recent 2.6.20 kernel.  There are tons of bad pte print (pfn < max_low_pfn)
reports when the crash kernel boots up, all those reported bad pages
are inside initmem range; That is because if the crash kernel code and
data happens to be at the beginning of the 1st node. build_node_maps in
discontig.c will bypass reserved regions with filter_rsvd_memory. Since
min_low_pfn is calculated in build_node_map, so in this case, min_low_pfn
will be greater than kernel code and data.

Because pages inside initmem are freed and reused later, we saw
pfn_valid check fail on those pages.

I think this theoretically happen on a normal kernel. When I check
min_low_pfn and max_low_pfn calculation in contig.c and discontig.c.
I found more issues than this.

1. min_low_pfn and max_low_pfn calculation is inconsistent between
contig.c and discontig.c,
min_low_pfn is calculated as the first page number of boot memmap in
contig.c (Why? Though this may work at the most of the time, I don't
think it is the right logic). It is calculated as the lowest physical
memory page number bypass reserved regions in discontig.c.
max_low_pfn is calculated include reserved regions in contig.c. It is
calculated exclude reserved regions in discontig.c.

2. If kernel code and data region is happen to be at the begin or the
end of physical memory, when min_low_pfn and max_low_pfn calculation is
bypassed kernel code and data, pages in initmem will report bad.

3. initrd is also in reserved regions, if it is at the begin or at the
end of physical memory, kernel will refuse to reuse the memory. Because
the virt_addr_valid check in free_initrd_mem.

So it is better to fix and clean up those issues.
Calculate min_low_pfn and max_low_pfn in a consistent way.
Signed-off-by: default avatarZou Nan hai <nanhai.zou@intel.com>
Acked-by: default avatarJay Lan <jlan@sgi.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      a3f5c338
  3. 10 Mar, 2007 37 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7