Skip to content

C
clone-Linux

gsplhtlxg / clone-Linux

通知 2
Star 0
Fork 1
C
clone-Linux

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

切换分支/标签
  1. 17 10月, 2007 18 次提交
  3. 16 10月, 2007 3 次提交
  5. 15 10月, 2007 2 次提交
    • J
      [IA64] update sn2_defconfig · 432a7d65
      由 Jes Sorensen 提交于 
      Update defonfig file for sn2 to match recent changes in config options.
Signed-off-by: NJes Sorensen <jes@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      432a7d65
    • S
      kbuild: enable 'make CFLAGS=...' to add additional options to CC · a0f97e06
      由 Sam Ravnborg 提交于 
      The variable CFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.

This patch replace use of CFLAGS with KBUILD_CFLAGS all over the
tree and enabling one to use:
make CFLAGS=...
to specify additional gcc commandline options.

One usecase is when trying to find gcc bugs but other
use cases has been requested too.

Patch was tested on following architectures:
alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k

Test was simple to do a defconfig build, apply the patch and check
that nothing got rebuild.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      a0f97e06
  7. 13 10月, 2007 11 次提交
    • K
      [IA64] Fix kernel hangup in kdump on INIT · 2010d7fe
      由 Kenji Kaneshige 提交于 
      Fix the problem that kdump on INIT hung up if kdump kernel image is
not configured.

The kdump_init_notifier() on monarch CPU stops its operation at
DIE_INIT_MONARCH_LEAVE time if the kdump kernel image is not
configured. On the other hand, kdump_init_notifier() on non-monarch
CPUs get into spin because they don't know the fact the monarch stops
its operation. This is the cause of this problem. To fix this problem,
we need to check the kdump kernel image at the top of the
kdump_init_notifier() function.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      2010d7fe
    • K
      [IA64] Fix kernel panic in kdump on INIT · ac542a51
      由 Kenji Kaneshige 提交于 
      Fix the problem that kdump on INIT causes a kernel panic if kdump
kernel image is not configured. The cause of this problem is
machine_kexec_on_init() is using printk in INIT context. It should
use ia64_mca_printk() instead.
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      ac542a51
    • S
      [IA64] Remove vector from ia64_machine_kexec() · a62c9fe4
      由 Simon Horman 提交于 
      The use of vector in ia64_machine_kexec() seems spurious,
and removing it simplifies the code slightly.

As suggested by Alex Williamson <alex.williamson@hp.com>

Cc: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      a62c9fe4
    • R
      [IA64] Fix race when multiple cpus go through MCA · e1b1eb01
      由 Russ Anderson 提交于 
      Additional testing uncovered a situation where the MCA recovery code could
hang due to a race condition.

According to the SAL spec, SAL sends a rendezvous interrupt to all but the first
CPU that goes into MCA.  This includes other CPUs that go into MCA at the same
time.  Those other CPUs will go into the linux MCA handler (rather than the
slave loop) with the rendezvous interrupt pending.  When all the CPUs have
completed MCA processing and the last monarch completes, freeing all the CPUs,
the CPUs with the pended rendezvous interrupt then go into the
ia64_mca_rendez_int_handler().  In ia64_mca_rendez_int_handler() the CPUs
get marked as rendezvoused, but then leave the handler (due to no MCA).
That leaves the CPUs marked as rendezvoused _before_ the next MCA event.

When the next MCA hits, the monarch will mistakenly believe that all the CPUs
are rendezvoused when they are not, opening up a window where a CPU can get
stuck in the slave loop.

This patch avoids leaving CPUs marked as rendezvoused when they are not.
Signed-off-by: NRuss Anderson <rja@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      e1b1eb01
    • R
      [IA64] Remove needless delay in MCA rendezvous · 2bc5c282
      由 Russ Anderson 提交于 
      While testing the MCA recovery code, noticed that some machines would have a
five second delay rendezvousing cpus.  What was happening is that
ia64_wait_for_slaves() would check to see if all the slave CPUs had
rendezvoused.  If any had not, it would wait 1 millisecond then check again.
If any CPUs had still not rendezvoused, it would wait 5 seconds before
checking again.

On some configs the rendezvous takes more than 1 millisecond, causing the code
to wait the full 5 seconds, even though the last CPU rendezvoused after only
a few milliseconds.

The fix is to check every 1 millisecond to see if all the cpus have
rendezvoused.  After 5 seconds the code concludes the CPUs will never
rendezvous (same as before).

The MCA code is, by definition, not performance critical, but a needless
delay of 5 seconds is senseless.  The 5 seconds also adds up quickly
when running the error injection code in a loop.

This patch both simplifies the code and removes the needless delay.
Signed-off-by: NRuss Anderson <rja@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      2bc5c282
    • B
      [IA64] add driver for ACPI methods to call native firmware · 28eda5b8
      由 Bjorn Helgaas 提交于 
      This driver for HPQ5001 devices installs a global ACPI OpRegion handler.
AML methods can use this OpRegion to call native firmware entry points.

ACPI does not define a mechanism for AML methods to call native firmware
interfaces such as PAL or SAL.  This OpRegion handler adds such a mechanism.
After the handler is installed, an AML method can call native firmware by
storing the arguments and firmware entry point to specific offsets in the
OpRegion.  When AML reads the "return value" offset from the OpRegion, this
handler loads up the arguments, makes the firmware call, and returns the
result.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      28eda5b8
    • K
      Driver core: change add_uevent_var to use a struct · 7eff2e7a
      由 Kay Sievers 提交于 
      This changes the uevent buffer functions to use a struct instead of a
long list of parameters. It does no longer require the caller to do the
proper buffer termination and size accounting, which is currently wrong
in some places. It fixes a known bug where parts of the uevent
environment are overwritten because of wrong index calculations.

Many thanks to Mathieu Desnoyers for finding bugs and improving the
error handling.
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7eff2e7a
    • S
      [IA64] perfmon: Remove exit_pfm_fs() · 8e75ad89
      由 Satyam Sharma 提交于 
      Because it is dead code and not referenced by anybody else (that file cannot
be built modular).
Signed-off-by: NSatyam Sharma <satyam@infradead.org>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Stephane Eranian <eranian@hpl.hp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      8e75ad89
    • S
      [IA64] tree-wide: Misc __cpu{initdata, init, exit} annotations · db6a5cef
      由 Satyam Sharma 提交于 
      * palinfo.c:

palinfo_cpu_notifier is a CPU hotplug notifier_block, and can be
marked __cpuinitdata, and the callback function palinfo_cpu_callback()
itself can be marked __cpuinit. create_palinfo_proc_entries() is only
called from __cpuinit callback or general __init code, therefore a
candidate for __cpuinit itself. remove_palinfo_proc_entries() is only
called from __cpuinit callback or general __exit code, therefore a
candidate for __cpuexit.

* salinfo.c:

The CPU hotplug notifier_block can be __cpuinitdata. The callback
salinfo_cpu_callback() is incorrectly marked __devinit -- it must
be __cpuinit instead.

* topology.c:

cache_sysfs_init() is only called at device_initcall() time so marking
it as __cpuinit is wrong and wasteful. It should be unconditionally
__init. Also cleanup reference to hotplug notifier callback function
from this function and replace with cache_add_dev(), which could also
enable us to use other tricks to replace __cpuinit{data} annotations,
as recently discussed on this list.

cache_shared_cpu_map_setup() is only ever called from __cpuinit-marked
functions hence both its definitions (SMP or !SMP) are candidates for
__cpuinit itself. Also all_cpu_cache_info can be __cpuinitdata because
only referenced from __cpuinit code.
Signed-off-by: NSatyam Sharma <satyam@infradead.org>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      db6a5cef
    • S
      ia64: fix sn to add include files using EXTRA_CFLAGS · c01b171d
      由 Sam Ravnborg 提交于 
      Changing the global CPPFLAGS is not the recommended way
to add additional include dirs.
Changed to use EXTRA_CFLAGS.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NJes Sorensen <jes@sgi.com>
      c01b171d
    • M
      [SCSI] simscsi: Free scsi host on error · a60ebc52
      由 Matthew Wilcox 提交于 
      If scsi_add_host returned an error, the host would never be freed.
We need to call scsi_host_put() if an error happens.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      a60ebc52
  9. 11 10月, 2007 2 次提交
  11. 05 10月, 2007 1 次提交
  13. 11 9月, 2007 1 次提交
    • R
      Fix spurious syscall tracing after PTRACE_DETACH + PTRACE_ATTACH · 7d941432
      由 Roland McGrath 提交于 
      When PTRACE_SYSCALL was used and then PTRACE_DETACH is used, the
TIF_SYSCALL_TRACE flag is left set on the formerly-traced task.  This
means that when a new tracer comes along and does PTRACE_ATTACH, it's
possible he gets a syscall tracing stop even though he's never used
PTRACE_SYSCALL.  This happens if the task was in the middle of a system
call when the second PTRACE_ATTACH was done.  The symptom is an
unexpected SIGTRAP when the tracer thinks that only SIGSTOP should have
been provoked by his ptrace calls so far.

A few machines already fixed this in ptrace_disable (i386, ia64, m68k).
But all other machines do not, and still have this bug.  On x86_64, this
constitutes a regression in IA32 compatibility support.

Since all machines now use TIF_SYSCALL_TRACE for this, I put the
clearing of TIF_SYSCALL_TRACE in the generic ptrace_detach code rather
than adding it to every other machine's ptrace_disable.
Signed-off-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7d941432
  15. 01 9月, 2007 2 次提交