1. 01 11月, 2006 1 次提交
  2. 16 10月, 2006 1 次提交
  3. 13 9月, 2006 1 次提交
  4. 23 8月, 2006 1 次提交
    • P
      [POWERPC] Correct masks used in emulating some instructions · 87589f08
      Paul Mackerras 提交于
      When we get an illegal instruction exception, we check to see whether
      the instruction is one that we emulate for the user program.  Some of
      the masks we use in checking whether the offending instruction is one
      we care about didn't have the top bit set, which is the MSB of the
      major opcode.  Thus some undefined opcodes could get emulated as other
      (defined but unimplemented) instructions.  This corrects the masks.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      87589f08
  5. 17 8月, 2006 2 次提交
    • M
      [POWERPC] Make crash.c work on 32-bit and 64-bit · b6f35b49
      Michael Ellerman 提交于
      To compile kexec on 32-bit we need a few more bits and pieces. Rather
      than add empty definitions, we can make crash.c work on 32-bit, with
      only a couple of kludges.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b6f35b49
    • D
      [POWERPC] Make secondary CPUs call into kdump on reset exception · eac8392f
      David Wilder 提交于
      In the case of a system hang, the user will invoke soft-reset to
      initiate the kdump boot.  If xmon is enabled, the CPU(s) enter into the
      xmon debugger.   Unfortunately, the secondary CPU(s) will return to the
      hung state when they exit from the debugger (returned from die() ->
      system_reset_exception()).  This causes a problem in kdump since the
      hung CPU(s) will not respond to the IPI sent from kdump.  This patch
      fixes the issue by calling crash_kexec_secondary() directly from
      system_reset_exception() without returning to the previous state.  These
      secondary CPUs wait 5ms until the kdump boot is started by the primary
      CPU.   In the case we exited from the debugger to "recover" (command 'x'
      in xmon) the primary and the secondary CPUs will all return from die()
      -> system_reset_exception() ->crash_kexec_secondary() wait 5ms, then
      return to the previous state.  A kdump boot is not started in this case.
      Signed-off-by: NHaren Myneni <haren@us.ibm.com>
      Signed-off-by: NDavid Wilder <dwilder@us.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      eac8392f
  6. 15 8月, 2006 1 次提交
    • H
      [PATCH] Change panic_on_oops message to "Fatal exception" · 012c437d
      Horms 提交于
      Previously the message was "Fatal exception: panic_on_oops", as introduced
      in a recent patch whith removed a somewhat dangerous call to ssleep() in
      the panic_on_oops path.  However, Paul Mackerras suggested that this was
      somewhat confusing, leadind people to believe that it was panic_on_oops
      that was the root cause of the fatal exception.  On his suggestion, this
      patch changes the message to simply "Fatal exception".  A suitable oops
      message should already have been displayed.
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      012c437d
  7. 01 8月, 2006 1 次提交
    • H
      [PATCH] panic_on_oops: remove ssleep() · cea6a4ba
      Horms 提交于
      This patch is part of an effort to unify the panic_on_oops behaviour across
      all architectures that implement it.
      
      It was pointed out to me by Andi Kleen that if an oops has occured in
      interrupt context, then calling sleep() in the oops path will only cause a
      panic, and that it would be really better for it not to be in the path at
      all.
      
      This patch removes the ssleep() call and reworks the console message
      accordinly.  I have a slght concern that the resulting console message is
      too long, feedback welcome.
      
      For powerpc it also unifies the 32bit and 64bit behaviour.
      
      Fror x86_64, this patch only updates the console message, as ssleep() is
      already not present.
      Signed-off-by: NHorms <horms@verge.net.au>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cea6a4ba
  8. 01 7月, 2006 1 次提交
  9. 28 6月, 2006 1 次提交
    • D
      [POWERPC] Add the use of the firmware soft-reset-nmi to kdump. · c0ce7d08
      David Wilder 提交于
      With this patch, kdump uses the firmware soft-reset NMI for two purposes:
      1) Initiate the kdump (take a crash dump) by issuing a soft-reset.
      2) Break a CPU out of a deadlock condition that is detected during kdump
      processing.
      
      When a soft-reset is initiated each CPU will enter
      system_reset_exception() and set its corresponding bit in the global
      bit-array cpus_in_sr then call die(). When die() finds the CPU's bit set
      in cpu_in_sr crash_kexec() is called to initiate a crash dump. The first
      CPU to enter crash_kexec() is called the "crashing CPU". All other CPUs
      are "secondary CPUs". The secondary CPU's pass through to
      crash_kexec_secondary() and sleep. The crashing CPU waits for all CPUs
      to enter via soft-reset then boots the kdump kernel (see
      crash_soft_reset_check())
      
      When the system crashes due to a panic or exception, crash_kexec() is
      called by panic() or die(). The crashing CPU sends an IPI to all other
      CPUs to notify them of the pending shutdown. If a CPU is in a deadlock
      or hung state with interrupts disabled, the IPI will not be delivered.
      The result being, that the kdump kernel is not booted. This problem is
      solved with the use of a firmware generated soft-reset. After the
      crashing_cpu has issued the IPI, it waits for 10 sec for all CPUs to
      enter crash_ipi_callback(). A CPU signifies its entry to
      crash_ipi_callback() by setting its corresponding bit in the
      cpus_in_crash bit array. After 10 sec, if one or more CPUs have not set
      their bit in cpus_in_crash we assume that the CPU(s) is deadlocked. The
      operator is then prompted to generate a soft-reset to break the
      deadlock. Each CPU enters the soft reset handler as described above.
      
      Two conditions must be handled at this point:
      1) The system crashed because the operator generated a soft-reset. See
      2) The system had crashed before the soft-reset was generated ( in the
      case of a Panic or oops).
      
      The first CPU to enter crash_kexec() uses the state of the kexec_lock to
      determine this state. If kexec_lock is already held then condition 2 is
      true and crash_kexec_secondary() is called, else; this CPU is flagged as
      the crashing CPU, the kexec_lock is acquired and crash_kexec() proceeds
      as described above.
      
      Each additional CPUs responding to the soft-reset will pass through
      crash_kexec() to kexec_secondary(). All secondary CPUs call
      crash_ipi_callback() readying them self's for the shutdown. When ready
      they clear their bit in cpus_in_sr. The crashing CPU waits in
      kexec_secondary() until all other CPUs have cleared their bits in
      cpus_in_sr. The kexec kernel boot is then started.
      Signed-off-by: NHaren Myneni <haren@us.ibm.com>
      Signed-off-by: NDavid Wilder <dwilder@us.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      c0ce7d08
  10. 26 6月, 2006 1 次提交
  11. 09 6月, 2006 2 次提交
    • P
      [PATCH] powerpc: Implement PR_[GS]ET_UNALIGN prctls for powerpc · e9370ae1
      Paul Mackerras 提交于
      This gives the ability to control whether alignment exceptions get
      fixed up or reported to the process as a SIGBUS, using the existing
      PR_SET_UNALIGN and PR_GET_UNALIGN prctls.  We do not implement the
      option of logging a message on alignment exceptions.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e9370ae1
    • P
      [PATCH] powerpc: Implement support for setting little-endian mode via prctl · fab5db97
      Paul Mackerras 提交于
      This adds the PowerPC part of the code to allow processes to change
      their endian mode via prctl.
      
      This also extends the alignment exception handler to be able to fix up
      alignment exceptions that occur in little-endian mode, both for
      "PowerPC" little-endian and true little-endian.
      
      We always enter signal handlers in big-endian mode -- the support for
      little-endian mode does not amount to the creation of a little-endian
      user/kernel ABI.  If the signal handler returns, the endian mode is
      restored to what it was when the signal was delivered.
      
      We have two new kernel CPU feature bits, one for PPC little-endian and
      one for true little-endian.  Most of the classic 32-bit processors
      support PPC little-endian, and this is reflected in the CPU feature
      table.  There are two corresponding feature bits reported to userland
      in the AT_HWCAP aux vector entry.
      
      This is based on an earlier patch by Anton Blanchard.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      fab5db97
  12. 31 3月, 2006 1 次提交
  13. 28 3月, 2006 2 次提交
    • B
      [PATCH] powerpc: Kill _machine and hard-coded platform numbers · e8222502
      Benjamin Herrenschmidt 提交于
      This removes statically assigned platform numbers and reworks the
      powerpc platform probe code to use a better mechanism.  With this,
      board support files can simply declare a new machine type with a
      macro, and implement a probe() function that uses the flattened
      device-tree to detect if they apply for a given machine.
      
      We now have a machine_is() macro that replaces the comparisons of
      _machine with the various PLATFORM_* constants.  This commit also
      changes various drivers to use the new macro instead of looking at
      _machine.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e8222502
    • A
      [PATCH] Notifier chain update: API changes · e041c683
      Alan Stern 提交于
      The kernel's implementation of notifier chains is unsafe.  There is no
      protection against entries being added to or removed from a chain while the
      chain is in use.  The issues were discussed in this thread:
      
          http://marc.theaimsgroup.com/?l=linux-kernel&m=113018709002036&w=2
      
      We noticed that notifier chains in the kernel fall into two basic usage
      classes:
      
      	"Blocking" chains are always called from a process context
      	and the callout routines are allowed to sleep;
      
      	"Atomic" chains can be called from an atomic context and
      	the callout routines are not allowed to sleep.
      
      We decided to codify this distinction and make it part of the API.  Therefore
      this set of patches introduces three new, parallel APIs: one for blocking
      notifiers, one for atomic notifiers, and one for "raw" notifiers (which is
      really just the old API under a new name).  New kinds of data structures are
      used for the heads of the chains, and new routines are defined for
      registration, unregistration, and calling a chain.  The three APIs are
      explained in include/linux/notifier.h and their implementation is in
      kernel/sys.c.
      
      With atomic and blocking chains, the implementation guarantees that the chain
      links will not be corrupted and that chain callers will not get messed up by
      entries being added or removed.  For raw chains the implementation provides no
      guarantees at all; users of this API must provide their own protections.  (The
      idea was that situations may come up where the assumptions of the atomic and
      blocking APIs are not appropriate, so it should be possible for users to
      handle these things in their own way.)
      
      There are some limitations, which should not be too hard to live with.  For
      atomic/blocking chains, registration and unregistration must always be done in
      a process context since the chain is protected by a mutex/rwsem.  Also, a
      callout routine for a non-raw chain must not try to register or unregister
      entries on its own chain.  (This did happen in a couple of places and the code
      had to be changed to avoid it.)
      
      Since atomic chains may be called from within an NMI handler, they cannot use
      spinlocks for synchronization.  Instead we use RCU.  The overhead falls almost
      entirely in the unregister routine, which is okay since unregistration is much
      less frequent that calling a chain.
      
      Here is the list of chains that we adjusted and their classifications.  None
      of them use the raw API, so for the moment it is only a placeholder.
      
        ATOMIC CHAINS
        -------------
      arch/i386/kernel/traps.c:		i386die_chain
      arch/ia64/kernel/traps.c:		ia64die_chain
      arch/powerpc/kernel/traps.c:		powerpc_die_chain
      arch/sparc64/kernel/traps.c:		sparc64die_chain
      arch/x86_64/kernel/traps.c:		die_chain
      drivers/char/ipmi/ipmi_si_intf.c:	xaction_notifier_list
      kernel/panic.c:				panic_notifier_list
      kernel/profile.c:			task_free_notifier
      net/bluetooth/hci_core.c:		hci_notifier
      net/ipv4/netfilter/ip_conntrack_core.c:	ip_conntrack_chain
      net/ipv4/netfilter/ip_conntrack_core.c:	ip_conntrack_expect_chain
      net/ipv6/addrconf.c:			inet6addr_chain
      net/netfilter/nf_conntrack_core.c:	nf_conntrack_chain
      net/netfilter/nf_conntrack_core.c:	nf_conntrack_expect_chain
      net/netlink/af_netlink.c:		netlink_chain
      
        BLOCKING CHAINS
        ---------------
      arch/powerpc/platforms/pseries/reconfig.c:	pSeries_reconfig_chain
      arch/s390/kernel/process.c:		idle_chain
      arch/x86_64/kernel/process.c		idle_notifier
      drivers/base/memory.c:			memory_chain
      drivers/cpufreq/cpufreq.c		cpufreq_policy_notifier_list
      drivers/cpufreq/cpufreq.c		cpufreq_transition_notifier_list
      drivers/macintosh/adb.c:		adb_client_list
      drivers/macintosh/via-pmu.c		sleep_notifier_list
      drivers/macintosh/via-pmu68k.c		sleep_notifier_list
      drivers/macintosh/windfarm_core.c	wf_client_list
      drivers/usb/core/notify.c		usb_notifier_list
      drivers/video/fbmem.c			fb_notifier_list
      kernel/cpu.c				cpu_chain
      kernel/module.c				module_notify_list
      kernel/profile.c			munmap_notifier
      kernel/profile.c			task_exit_notifier
      kernel/sys.c				reboot_notifier_list
      net/core/dev.c				netdev_chain
      net/decnet/dn_dev.c:			dnaddr_chain
      net/ipv4/devinet.c:			inetaddr_chain
      
      It's possible that some of these classifications are wrong.  If they are,
      please let us know or submit a patch to fix them.  Note that any chain that
      gets called very frequently should be atomic, because the rwsem read-locking
      used for blocking chains is very likely to incur cache misses on SMP systems.
      (However, if the chain's callout routines may sleep then the chain cannot be
      atomic.)
      
      The patch set was written by Alan Stern and Chandra Seetharaman, incorporating
      material written by Keith Owens and suggestions from Paul McKenney and Andrew
      Morton.
      
      [jes@sgi.com: restructure the notifier chain initialization macros]
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: NJes Sorensen <jes@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e041c683
  14. 03 3月, 2006 1 次提交
    • P
      powerpc: Fix might-sleep warning in program check exception handler · cd8a5673
      Paul Mackerras 提交于
      On 32-bit, the exception prolog for the program check exception doesn't
      enable interrupts early on.  If it is an illegal instruction exception,
      we read the instruction in order to emulate certain instructions, and
      the get_user of the instruction triggers a WARN_ON since interrupts
      are still disabled.  This adds a local_irq_enable() to enable
      interrupts before reading the instruction.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cd8a5673
  15. 09 1月, 2006 3 次提交
  16. 11 11月, 2005 1 次提交
    • B
      [PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel · a7f290da
      Benjamin Herrenschmidt 提交于
      This patch moves the vdso's to arch/powerpc, adds support for the 32
      bits vdso to the 32 bits kernel, rename systemcfg (finally !), and adds
      some new (still untested) routines to both vdso's: clock_gettime() with
      support for CLOCK_REALTIME and CLOCK_MONOTONIC, clock_getres() (same
      clocks) and get_tbfreq() for glibc to retreive the timebase frequency.
      
      Tom,Steve: The implementation of get_tbfreq() I've done for 32 bits
      returns a long long (r3, r4) not a long. This is such that if we ever
      add support for >4Ghz timebases on ppc32, the userland interface won't
      have to change.
      
      I have tested gettimeofday() using some glibc patches in both ppc32 and
      ppc64 kernels using 32 bits userland (I haven't had a chance to test a
      64 bits userland yet, but the implementation didn't change and was
      tested earlier). I haven't tested yet the new functions.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a7f290da
  17. 10 11月, 2005 1 次提交
  18. 09 11月, 2005 1 次提交
  19. 08 11月, 2005 1 次提交
  20. 02 11月, 2005 1 次提交
  21. 01 11月, 2005 1 次提交
  22. 27 10月, 2005 1 次提交
    • D
      [PATCH] powerpc: Fix handling of fpscr on 64-bit · 25c8a78b
      David Gibson 提交于
      The recent merge of fpu.S broken the handling of fpscr for
      ARCH=powerpc and CONFIG_PPC64=y.  FP registers could be corrupted,
      leading to strange random application crashes.
      
      The confusion arises, because the thread_struct has (and requires) a
      64-bit area to save the fpscr, because we use load/store double
      instructions to get it in to/out of the FPU.  However, only the low
      32-bits are actually used, so we want to treat it as a 32-bit quantity
      when manipulating its bits to avoid extra load/stores on 32-bit.  This
      patch replaces the current definition with a structure of two 32-bit
      quantities (pad and val), to clarify things as much as is possible.
      The 'val' field is used when manipulating bits, the structure itself
      is used when obtaining the address for loading/unloading the value
      from the FPU.
      
      While we're at it, consolidate the 4 (!) almost identical versions of
      cvt_fd() and cvt_df() (arch/ppc/kernel/misc.S,
      arch/ppc64/kernel/misc.S, arch/powerpc/kernel/misc_32.S,
      arch/powerpc/kernel/misc_64.S) into a single version in fpu.S.  The
      new version takes a pointer to thread_struct and applies the correct
      offset itself, rather than a pointer to the fpscr field itself, again
      to avoid confusion as to which is the correct field to use.
      
      Finally, this patch makes ARCH=ppc64 also use the consolidated fpu.S
      code, which it previously did not.
      
      Built for G5 (ARCH=ppc64 and ARCH=powerpc), 32-bit powermac (ARCH=ppc
      and ARCH=powerpc) and Walnut (ARCH=ppc, CONFIG_MATH_EMULATION=y).
      Booted on G5 (ARCH=powerpc) and things which previously fell over no
      longer do.
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      25c8a78b
  23. 20 10月, 2005 1 次提交
    • D
      [PATCH] powerpc: Merge ppc64 pmc.[ch] with ppc32 perfmon.[ch] · f7f6f4fe
      David Gibson 提交于
      This patches the ppc32 and ppc64 versions of the headers and .c files
      with helper functions for manipulating the performance counting
      hardware.  As a side effect, it removes use of the term "perfmon" from
      ppc32, thus avoiding confusion with the unrelated performance counter
      interface from HP Labs also called "perfmon".
      
      Built, but not booted, for g5, pSeries, iSeries, and 32-bit Powermac
      with both ARCH=powerpc and ARCH=ppc{,64} as appropriate.
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f7f6f4fe
  24. 10 10月, 2005 1 次提交
  25. 06 10月, 2005 1 次提交
  26. 01 10月, 2005 1 次提交
  27. 26 9月, 2005 1 次提交
    • P
      powerpc: Merge enough to start building in arch/powerpc. · 14cf11af
      Paul Mackerras 提交于
      This creates the directory structure under arch/powerpc and a bunch
      of Kconfig files.  It does a first-cut merge of arch/powerpc/mm,
      arch/powerpc/lib and arch/powerpc/platforms/powermac.  This is enough
      to build a 32-bit powermac kernel with ARCH=powerpc.
      
      For now we are getting some unmerged files from arch/ppc/kernel and
      arch/ppc/syslib, or arch/ppc64/kernel.  This makes some minor changes
      to files in those directories and files outside arch/powerpc.
      
      The boot directory is still not merged.  That's going to be interesting.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      14cf11af
  28. 21 9月, 2005 1 次提交
  29. 11 9月, 2005 1 次提交
    • P
      [PATCH] ppc32: Kill init on unhandled synchronous signals · bb0bb3b6
      Paul Mackerras 提交于
      This is a patch that I have had in my tree for ages.  If init causes
      an exception that raises a signal, such as a SIGSEGV, SIGILL or
      SIGFPE, and it hasn't registered a handler for it, we don't deliver
      the signal, since init doesn't get any signals that it doesn't have a
      handler for.  But that means that we just return to userland and
      generate the same exception again immediately.  With this patch we
      print a message and kill init in this situation.
      
      This is very useful when you have a bug in the kernel that means that
      init doesn't get as far as executing its first instruction. :)
      Without this patch the system hangs when it gets to starting the
      userland init; with it you at least get a message giving you a clue
      about what has gone wrong.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bb0bb3b6
  30. 10 9月, 2005 1 次提交
  31. 05 9月, 2005 1 次提交
    • K
      [PATCH] ppc32: Added support for the Book-E style Watchdog Timer · a2f40ccd
      Kumar Gala 提交于
      PowerPC 40x and Book-E processors support a watchdog timer at the processor
      core level.  The timer has implementation dependent timeout frequencies
      that can be configured by software.
      
      One the first Watchdog timeout we get a critical exception.  It is left to
      board specific code to determine what should happen at this point.  If
      nothing is done and another timeout period expires the processor may
      attempt to reset the machine.
      
      Command line parameters:
        wdt=0 : disable watchdog (default)
        wdt=1 : enable watchdog
      
        wdt_period=N : N sets the value of the Watchdog Timer Period.
      
        The Watchdog Timer Period meaning is implementation specific. Check
        User Manual for the processor for more details.
      
      This patch is based off of work done by Takeharu Kato.
      Signed-off-by: NMatt McClintock <msm@freescale.com>
      Signed-off-by: NKumar Gala <kumar.gala@freescale.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a2f40ccd
  32. 26 6月, 2005 1 次提交
  33. 22 6月, 2005 1 次提交
  34. 29 5月, 2005 1 次提交
  35. 01 5月, 2005 1 次提交