Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 13 8月, 2008 1 次提交
    • M
      x86: fix 2 section mismatch warnings - find_and_reserve_crashkernel · 6b356022
      由 Marcin Slusarz 提交于 
      WARNING: vmlinux.o(.text+0xcd1f): Section mismatch in reference from the function find_and_reserve_crashkernel() to the function .init.text:find_e820_area()
The function find_and_reserve_crashkernel() references
the function __init find_e820_area().
This is often because find_and_reserve_crashkernel lacks a __init
annotation or the annotation of find_e820_area is wrong.

WARNING: vmlinux.o(.text+0xcd38): Section mismatch in reference from the function find_and_reserve_crashkernel() to the function .init.text:reserve_bootmem_generic()
The function find_and_reserve_crashkernel() references
the function __init reserve_bootmem_generic().
This is often because find_and_reserve_crashkernel lacks a __init
annotation or the annotation of reserve_bootmem_generic is wrong.

find_and_reserve_crashkernel is called from __init function (reserve_crashkernel)
and calls 2 __init functions (find_e820_area, reserve_bootmem_generic),
so mark it __init
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6b356022
  3. 12 8月, 2008 1 次提交
  5. 09 8月, 2008 1 次提交
  7. 24 7月, 2008 1 次提交
  9. 22 7月, 2008 1 次提交
  11. 20 7月, 2008 2 次提交
  13. 19 7月, 2008 2 次提交
    • B
      x86: move dma32_reserve_bootmem() after reserve_crashkernel() · 91467bdf
      由 Bernhard Walle 提交于 
      On a x86-64 machine (nothing special I could encounter) I had the problem that
crashkernel reservation with the usual "64M@16M" failed. While debugging that,
I encountered that dma32_reserve_bootmem() reserves a memory region which is in
that area.

Because dma32_reserve_bootmem() does not rely on a specific offset but
crashkernel does, it makes sense to move the dma32_reserve_bootmem()
reservation down a bit. I tested that patch and it works without problems. I
don't see any negative effects of that move, but maybe I oversaw something ...

While we strictly don't need that patch in 2.6.27 because we have the
automatic, dynamic offset detection, it makes sense to also include it here
because:

  - it's easier to get it in -stable then,
  - many people are still used to the 'crashkernel=...@16M' syntax,
  - not everybody may be using a reloatable kernel.
Signed-off-by: NBernhard Walle <bwalle@suse.de>
Cc: kexec@lists.infradead.org
Cc: vgoyal@redhat.com
Cc: akpm@linux-foundation.org
Cc: Bernhard Walle <bwalle@suse.de>
Cc: yhlu.kernel@gmail.com
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      91467bdf
    • A
      x86 setup.c: cleanup includes · 47129654
      由 Alexander Beregalov 提交于 
      x86: remove double includes in setup.c
Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
Cc: yhlu.kernel@gmail.com
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      47129654
  15. 16 7月, 2008 2 次提交
  17. 13 7月, 2008 1 次提交
    • Y
      x86: fix numaq_tsc_disable calling · 3d88cca7
      由 Yinghai Lu 提交于 
      got this on a test-system:

 calling  numaq_tsc_disable+0x0/0x39
 NUMAQ: disabling TSC
 initcall numaq_tsc_disable+0x0/0x39 returned 0 after 0 msecs

that's because we should not be using arch_initcall to call numaq_tsc_disable.

need to call it in setup_arch before time_init()/tsc_init()
and call it in init_intel() to make the cpu feature bits right.
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3d88cca7
  19. 11 7月, 2008 3 次提交
  21. 09 7月, 2008 2 次提交
  23. 08 7月, 2008 23 次提交