Skip to content
  1. Oct 15, 2007
  3. Oct 13, 2007
    • Kenji Kaneshige's avatar
      [IA64] Fix kernel hangup in kdump on INIT · 2010d7fe
      Kenji Kaneshige authored 
      

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: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      2010d7fe
    • Kenji Kaneshige's avatar
      [IA64] Fix kernel panic in kdump on INIT · ac542a51
      Kenji Kaneshige authored 
      

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: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      ac542a51
    • Simon Horman's avatar
      [IA64] Remove vector from ia64_machine_kexec() · a62c9fe4
      Simon Horman authored 
      

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: default avatarSimon Horman <horms@verge.net.au>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      a62c9fe4
    • Russ Anderson's avatar
      [IA64] Fix race when multiple cpus go through MCA · e1b1eb01
      Russ Anderson authored 
      

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: default avatarRuss Anderson <rja@sgi.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      e1b1eb01
    • Russ Anderson's avatar
      [IA64] Remove needless delay in MCA rendezvous · 2bc5c282
      Russ Anderson authored 
      

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: default avatarRuss Anderson <rja@sgi.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      2bc5c282
    • Bjorn Helgaas's avatar
      [IA64] add driver for ACPI methods to call native firmware · 28eda5b8
      Bjorn Helgaas authored 
      

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: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: default avatarLen Brown <len.brown@intel.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      28eda5b8
    • Bjorn Helgaas's avatar
      [IA64] abstract SAL_CALL wrapper to allow other firmware entry points · edbe7075
      Bjorn Helgaas authored 
      

SAL_CALL() always calls through the ia64_sal function pointer.  I am adding
new functionality that needs the same conventions as SAL_CALL (FP regs
saved/restored, sal_lock acquired, etc), but doesn't use the ia64_sal
function pointer.

This patch pulls the body of SAL_CALL out into a new "IA64_FW_CALL" that
takes care of these calling conventions, but allows the caller to specify
either ia64_sal or some other firmware entry point.

Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: default avatarLen Brown <len.brown@intel.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      edbe7075
    • Satyam Sharma's avatar
      [IA64] perfmon: Remove exit_pfm_fs() · 8e75ad89
      Satyam Sharma authored 
      

Because it is dead code and not referenced by anybody else (that file cannot
be built modular).

Signed-off-by: default avatarSatyam Sharma <satyam@infradead.org>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Stephane Eranian <eranian@hpl.hp.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      8e75ad89
    • Satyam Sharma's avatar
      [IA64] tree-wide: Misc __cpu{initdata, init, exit} annotations · db6a5cef
      Satyam Sharma authored 
      

* 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: default avatarSatyam Sharma <satyam@infradead.org>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      db6a5cef
  5. Oct 12, 2007