Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 6
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 15 10月, 2008 8 次提交
  3. 30 9月, 2008 1 次提交
  5. 23 9月, 2008 3 次提交
    • S
      signals: demultiplexing SIGTRAP signal · da654b74
      由 Srinivasa Ds 提交于 
      Currently a SIGTRAP can denote any one of below reasons.
	- Breakpoint hit
	- H/W debug register hit
	- Single step
	- Signal sent through kill() or rasie()

Architectures like powerpc/parisc provides infrastructure to demultiplex
SIGTRAP signal by passing down the information for receiving SIGTRAP through
si_code of siginfot_t structure. Here is an attempt is generalise this
infrastructure by extending it to x86 and x86_64 archs.
Signed-off-by: NSrinivasa DS <srinivasa@in.ibm.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: akpm@linux-foundation.org
Cc: paulus@samba.org
Cc: linuxppc-dev@ozlabs.org
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      da654b74
    • J
      [IA64] kexec fails on systems with blocks of uncached memory · d3758f87
      由 Jay Lan 提交于 
      Currently a memory segment in memory map with attribute of EFI_MEMORY_UC
is denoted as "System RAM" in /proc/iomem, while memory of attribute
(EFI_MEMORY_WB|EFI_MEMORY_UC) is also labeled the same.

The kexec utility then includes uncached memory as part of vmcore. The
kdump kernel MCA'ed when it tries to save the vmcore to a disk. A normal
"cached" access may cause MCAs.

This patch would label memory with attribute of EFI_MEMORY_UC only as
"Uncached RAM" so that kexec would know not to include it in the vmcore.
I will submit a separate kexec-tools patch to the kexec list.
Signed-off-by: NJay Lan <jlan@sgi.com>
Acked-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      d3758f87
    • A
      [IA64] Ski simulator doesn't need check_sal_cache_flush · 06f95ea8
      由 Alex Chiang 提交于 
      Peter Chubb reported that commit 3463a93d
(Update check_sal_cache_flush to use platform_send_ipi()) broke
Ski because it does not implement IPIs.

Tony Luck suggested we just #ifndef out the call (since the simulator
does not have the SAL bug that this code is attempting to detect and
workaround)
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      06f95ea8
  7. 20 9月, 2008 1 次提交
  9. 11 9月, 2008 4 次提交
  11. 10 9月, 2008 1 次提交
  13. 09 9月, 2008 1 次提交
    • M
      kernel/cpu.c: create a CPU_STARTING cpu_chain notifier · e545a614
      由 Manfred Spraul 提交于 
      Right now, there is no notifier that is called on a new cpu, before the new
cpu begins processing interrupts/softirqs.
Various kernel function would need that notification, e.g. kvm works around
by calling smp_call_function_single(), rcu polls cpu_online_map.

The patch adds a CPU_STARTING notification. It also adds a helper function
that sends the message to all cpu_chain handlers.

Tested on x86-64.
All other archs are untested. Especially on sparc, I'm not sure if I got
it right.
Signed-off-by: NManfred Spraul <manfred@colorfullife.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e545a614
  15. 08 9月, 2008 1 次提交
    • F
      ia64: dma_alloc_coherent always use GFP_DMA · 3a80b6aa
      由 FUJITA Tomonori 提交于 
      This patch makes dma_alloc_coherent use GFP_DMA at all times. This is
necessary for swiotlb, which requires the callers to set up the gfp
flags properly.

swiotlb_alloc_coherent tries to allocate pages with the gfp flags. If
the allocated memory isn't fit for dev->coherent_dma_mask,
swiotlb_alloc_coherent reserves some of the swiotlb memory area, which
is precious resource. So the callers need to set up the gfp flags
properly.

This patch means that other IA64 IOMMUs' dma_alloc_coherent also use
GFP_DMA. These IOMMUs (e.g. SBA IOMMU) don't need GFP_DMA since they
can map a memory to any address. But IA64's GFP_DMA is large,
generally drivers allocate small memory with dma_alloc_coherent only
at startup. So I chose the simplest way to set up the gfp flags for
swiotlb.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3a80b6aa
  17. 07 9月, 2008 1 次提交
  19. 04 9月, 2008 1 次提交
  21. 26 8月, 2008 2 次提交
  23. 19 8月, 2008 4 次提交
  25. 15 8月, 2008 1 次提交
  27. 13 8月, 2008 2 次提交
    • A
      [IA64] use bcd2bin/bin2bcd · 430ac5ba
      由 Adrian Bunk 提交于 
      This patch changes ia64 to use the new bcd2bin/bin2bcd functions instead
of the obsolete BCD2BIN/BIN2BCD macros.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      430ac5ba
    • T
      [IA64] Ensure cpu0 can access per-cpu variables in early boot code · 10617bbe
      由 Tony Luck 提交于 
      ia64 handles per-cpu variables a litle differently from other architectures
in that it maps the physical memory allocated for each cpu at a constant
virtual address (0xffffffffffff0000). This mapping is not enabled until
the architecture specific cpu_init() function is run, which causes problems
since some generic code is run before this point. In particular when
CONFIG_PRINTK_TIME is enabled, the boot cpu will trap on the access to
per-cpu memory at the first printk() call so the boot will fail without
the kernel printing anything to the console.

Fix this by allocating percpu memory for cpu0 in the kernel data section
and doing all initialization to enable percpu access in head.S before
calling any generic code.

Other cpus must take care not to access per-cpu variables too early, but
their code path from start_secondary() to cpu_init() is all in arch/ia64
Signed-off-by: NTony Luck <tony.luck@intel.com>
      10617bbe
  29. 05 8月, 2008 7 次提交
  31. 02 8月, 2008 1 次提交
    • T
      [IA64] Move include/asm-ia64 to arch/ia64/include/asm · 7f30491c
      由 Tony Luck 提交于 
      After moving the the include files there were a few clean-ups:

1) Some files used #include <asm-ia64/xyz.h>, changed to <asm/xyz.h>

2) Some comments alerted maintainers to look at various header files to
make matching updates if certain code were to be changed. Updated these
comments to use the new include paths.

3) Some header files mentioned their own names in initial comments. Just
deleted these self references.
Signed-off-by: NTony Luck <tony.luck@intel.com>
      7f30491c
  33. 31 7月, 2008 1 次提交
    • J
      GRU Driver: hardware data structures · 34d8a380
      由 Jack Steiner 提交于 
      This series of patches adds a driver for the SGI UV GRU.  The driver is
still in development but it currently compiles for both x86_64 & IA64.
All simple regression tests pass on IA64.  Although features remain to be
added, I'd like to start the process of getting the driver into the
kernel.  Additional kernel drivers will depend on services provide by the
GRU driver.

The GRU is a hardware resource located in the system chipset.  The GRU
contains memory that is mmaped into the user address space.  This memory
is used to communicate with the GRU to perform functions such as
load/store, scatter/gather, bcopy, AMOs, etc.  The GRU is directly
accessed by user instructions using user virtual addresses.  GRU
instructions (ex., bcopy) use user virtual addresses for operands.

The GRU contains a large TLB that is functionally very similar to
processor TLBs.  Because the external contains a TLB with user virtual
address, it requires callouts from the core VM system when certain types
of changes are made to the process page tables.  There are several MMUOPS
patches currently being discussed but none has been accepted into the
kernel.  The GRU driver is built using version V18 from Andrea Arcangeli.

This patch:

Contains the definitions of the hardware GRU data structures that are used
by the driver to manage the GRU.

[akpm@linux-foundation;org: export hpage_shift]
Signed-off-by: NJack Steiner <steiner@sgi.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      34d8a380