Skip to content

K
kernel_linux

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

通知 16
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 13 12月, 2006 9 次提交
    • T
      [IA64] Take defensive stance on ia64_pal_get_brand_info() · 75f6a1de
      由 Tony Luck 提交于 
      Stephane thought he saw a problem here (but was just confused
by the return value from ia64_pal_get_brand_info()).  But we
should be more defensive here in case an prototype PAL for
a future processor doesn't implement this PAL call.
Signed-off-by: NTony Luck <tony.luck@intel.com>
      75f6a1de
    • D
      [IA64] fix possible XPC deadlock when disconnecting · a460ef8d
      由 Dean Nelson 提交于 
      This patch eliminates a potential deadlock that is possible when XPC
disconnects a channel to a partition that has gone down. This deadlock will
occur if at least one of the kthreads created by XPC for the purpose of making
callouts to the channel's registerer is detained in the registerer and will
not be returning back to XPC until some registerer request occurs on the now
downed partition. The potential for a deadlock is removed by ensuring that
there always is a kthread available to make the channel disconnecting callout
to the registerer.
Signed-off-by: NDean Nelson <dcn@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      a460ef8d
    • J
      [IA64] - Reduce overhead of FP exception logging messages · 1cf24bdb
      由 Jack Steiner 提交于 
      Improve the scalability of the fpswa code that rate-limits
logging of messages.

There are 2 distinctly different problems in this code.

1) If prctl is used to disable logging, last_time is never
   updated. The result is that fpu_swa_count is zeroed out on
   EVERY fp fault. This causes a very very hot cache line.
   The fix reduces the wallclock time of a 1024p FP exception test
   from 28734 sec to 19 sec!!!

2) On VERY large systems, excessive messages are logged because
   multiple cpus can each reset or increment fpu_swa_count at
   about the same time. The result is that hundreds of messages
   are logged each second. The fixes reduces the logging rate
   to ~1 per second.
Signed-off-by: NJack Steiner <steiner@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      1cf24bdb
    • T
      [IA64] fix arch/ia64/mm/contig.c:235: warning: unused variable `nid' · 8b9c1068
      由 Tony Luck 提交于 
      This warning only shows up with CONFIG_VIRTUAL_MEM_MAP=y and
CONFIG_FLATMEM=y.

There is only one caller left for register_active_ranges() from the
contig.c code ... so it doesn't need to pick up the node number, the
node number is always zero.
Signed-off-by: NTony Luck <tony.luck@intel.com>
      8b9c1068
    • T
      [IA64] s/termios/ktermios/ in simserial.c · f889a26a
      由 Tony Luck 提交于 
      This got missed in 606d099cSigned-off-by: NTony Luck <tony.luck@intel.com>
      f889a26a
    • H
      [IA64] kexec/kdump: tidy up declaration of relocate_new_kernel_t · 53da5763
      由 Horms 提交于 
      * Make NORET_TYPE and ATTRIB_NORET in line with the
  declaration for other architectures
* Add parameter names
Signed-Off-By: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      53da5763
    • H
      [IA64] Kexec/Kdump: honour non-zero crashkernel offset. · ad1c3ba7
      由 Horms 提交于 
      There seems to be a value in both allowing the kernel to determine
the base offset of the crashkernel automatically and allowing
users's to sepcify it.

The old behaviour on ia64, which is still the current behaviour on
most architectures is for the user to always specify the address.
Recently ia64 was changed so that it is always automatically determined.

With this patch the kernel automatically determines the offset if
the supplied value is 0, otherwise it uses the value provided.

This should probably be backed by a documentation change.
Signed-Off-By: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      ad1c3ba7
    • H
      [IA64] CONFIG_KEXEC/CONFIG_CRASH_DUMP permutations · 45a98fc6
      由 Horms 提交于 
      Actually, on reflection I think that there is a good case for
keeping the options separate. I am thinking particularly of people
who want a very small crashdump kernel and thus don't want to compile
in kexec.

The patch below should fix things up so that all valid combinations of
KEXEC, CRASH_DUMP and VMCORE compile cleanly - VMCORE depends on
CRASH_DUMP which is why I said valid combinations. In a nutshell
it just untangles unrelated code and switches around a few defines.

Please note that it creats a new file, arch/ia64/kernel/crash_dump.c
This is in keeping with the i386 implementation.
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      45a98fc6
    • J
      [IA64] Do not call SN_SAL_SET_CPU_NUMBER twice on cpu 0 · adf142e3
      由 Jay Lan 提交于 
      This is an SN specific patch.

Architectually, cpu_init is always called twice on cpu 0
and thus resulted in two SN_SAL_SET_CPU_NUMBER calls.

This was harmless in production kernel; however, it can
cause problem on booting up a crashdump kernel at Altix.

Here is the patch that detects the second sn_cpu_init
call and skips the second call to SN_SAL_SET_CPU_NUMBER.
Signed-Off-By: NJay Lan <jlan@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      adf142e3
  3. 12 12月, 2006 25 次提交
  5. 11 12月, 2006 6 次提交