1. 26 Sep, 2006 4 commits
    • Andi Kleen's avatar
      [PATCH] Fix up panic messages for different NMI panics · fac58550
      Andi Kleen authored
      
      
      When a unknown NMI happened the panic would claim a NMI watchdog timeout.
      Also it would check the variable set by nmi_watchdog=panic and panic then.
      
      Fix up the panic message to be generic
      Unconditionally panic on unknown NMI when panic on unknown nmi is enabled.
      
      Noticed by Jan Beulich
      
      Cc: jbeulich@novell.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      fac58550
    • Don Zickus's avatar
      [PATCH] x86: x86 clean up nmi panic messages · c41c5cd3
      Don Zickus authored
      
      
      Clean up some of the output messages on the nmi error paths to make more
      sense when they are displayed.  This is mainly a cosmetic fix and
      shouldn't impact any normal code path.
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      c41c5cd3
    • Don Zickus's avatar
      [PATCH] x86: Allow users to force a panic on NMI · 8da5adda
      Don Zickus authored
      
      
      To quote Alan Cox:
      
      The default Linux behaviour on an NMI of either memory or unknown is to
      continue operation. For many environments such as scientific computing
      it is preferable that the box is taken out and the error dealt with than
      an uncorrected parity/ECC error get propogated.
      
      A small number of systems do generate NMI's for bizarre random reasons
      such as power management so the default is unchanged. In other respects
      the new proc/sys entry works like the existing panic controls already in
      that directory.
      
      This is separate to the edac support - EDAC allows supported chipsets to
      handle ECC errors well, this change allows unsupported cases to at least
      panic rather than cause problems further down the line.
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      8da5adda
    • Don Zickus's avatar
      [PATCH] x86: Cleanup NMI interrupt path · 3adbbcce
      Don Zickus authored
      
      
      This patch cleans up the NMI interrupt path.  Instead of being gated by if
      the 'nmi callback' is set, the interrupt handler now calls everyone who is
      registered on the die_chain and additionally checks the nmi watchdog,
      reseting it if enabled.  This allows more subsystems to hook into the NMI if
      they need to (without being block by set_nmi_callback).
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      3adbbcce
  2. 30 Aug, 2006 2 commits
  3. 14 Aug, 2006 1 commit
    • Horms's avatar
      [PATCH] Change panic_on_oops message to "Fatal exception" · 012c437d
      Horms authored
      
      
      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: default avatarSimon Horman <horms@verge.net.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      012c437d
  4. 31 Jul, 2006 1 commit
    • Horms's avatar
      [PATCH] panic_on_oops: remove ssleep() · cea6a4ba
      Horms authored
      
      
      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: default avatarHorms <horms@verge.net.au>
      Acked-by: default avatarPaul 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      cea6a4ba
  5. 28 Jul, 2006 1 commit
    • Andi Kleen's avatar
      [PATCH] x86_64: Dump leftover backtrace entries when dwarf2 unwinder got stuck · b13761ec
      Andi Kleen authored
      
      
      The dwarf2 unwinder currently often gets stuck because a lot
      of assembly code doesn't have proper dwarf2 annotiation yet.
      
      This currently often happens with __down. Should fix this by
      adding proper dwarf2 annotation to all inline assembly. However
      until that's done we need a quick fix for 2.6.18 to avoid
      incomplete backtraces.
      
      So when this happens dump the rest of the stack with the old unwinder
      instead of silently not dumping it. There was already a optional
      "both" mode that dumped both, but that was too ugly.
      
      I also clarified the headers for the different backtraces a bit.
      
      Also add a clear error message for missing dwarf2
      annotation that people can work on.
      
      And I removed a dead variable left over from Ingo's changes.
      
      Cc: mingo@elte.hu
      Cc: jbeulich@novell.com
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b13761ec
  6. 10 Jul, 2006 1 commit
  7. 03 Jul, 2006 2 commits
  8. 30 Jun, 2006 1 commit
  9. 26 Jun, 2006 5 commits
  10. 16 May, 2006 1 commit
  11. 08 May, 2006 2 commits
    • Corey Minyard's avatar
      [PATCH] x86_64: add nmi_exit to die_nmi · 8b1ffe95
      Corey Minyard authored
      
      
      Playing with NMI watchdog on x86_64, I discovered that it didn't
      do what I expected.  It always panic-ed, even when it didn't
      happen from interrupt context.  This patch solves that
      problem for me.  Also, in this case, do_exit() will be called
      with interrupts disabled, I believe.  Would it be wise to also
      call local_irq_enable() after nmi_exit()?
      [Yes I added it -AK]
      
      Currently, on x86_64, any NMI watchdog timeout will cause a panic
      because the irq count will always be set to be in an interrupt
      when do_exit() is called from die_nmi().  If we add nmi_exit() to
      the die_nmi() call (since the nmi will never exit "normally")
      it seems to solve this problem.  The following small program
      can be used to trigger the NMI watchdog to reproduce this:
        main ()
        {
              iopl(3);
              for (;;) asm("cli");
        }
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8b1ffe95
    • Corey Minyard's avatar
      [PATCH] x86_64: fix die_lock nesting · cdc60a4c
      Corey Minyard authored
      
      
      I noticed this when poking around in this area.
      
      The oops_begin() function in x86_64 would only conditionally claim
      the die_lock if the call is nested, but oops_end() would always
      release the spinlock. This patch adds a nest count for the die lock
      so that the release of the lock is only done on the final oops_end().
      Signed-off-by: default avatarCorey Minyard <minyard@acm.org>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      cdc60a4c
  12. 18 Apr, 2006 1 commit
  13. 31 Mar, 2006 1 commit
    • OGAWA Hirofumi's avatar
      [PATCH] Don't pass boot parameters to argv_init[] · 9b41046c
      OGAWA Hirofumi authored
      
      
      The boot cmdline is parsed in parse_early_param() and
      parse_args(,unknown_bootoption).
      
      And __setup() is used in obsolete_checksetup().
      
      	start_kernel()
      		-> parse_args()
      			-> unknown_bootoption()
      				-> obsolete_checksetup()
      
      If __setup()'s callback (->setup_func()) returns 1 in
      obsolete_checksetup(), obsolete_checksetup() thinks a parameter was
      handled.
      
      If ->setup_func() returns 0, obsolete_checksetup() tries other
      ->setup_func().  If all ->setup_func() that matched a parameter returns 0,
      a parameter is seted to argv_init[].
      
      Then, when runing /sbin/init or init=app, argv_init[] is passed to the app.
      If the app doesn't ignore those arguments, it will warning and exit.
      
      This patch fixes a wrong usage of it, however fixes obvious one only.
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9b41046c
  14. 27 Mar, 2006 1 commit
    • Alan Stern's avatar
      [PATCH] Notifier chain update: API changes · e041c683
      Alan Stern authored
      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: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: default avatarJes Sorensen <jes@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e041c683
  15. 25 Mar, 2006 3 commits
  16. 12 Feb, 2006 1 commit
    • John Blackwood's avatar
      [PATCH] arch/x86_64/kernel/traps.c PTRACE_SINGLESTEP oops · a65d17c9
      John Blackwood authored
      
      
      We found a problem with x86_64 kernels with preemption enabled, where
      having multiple tasks doing ptrace singlesteps around the same time will
      cause the system to 'oops'.  The problem seems that a task can get
      preempted out of the do_debug() processing while it is running on the
      DEBUG_STACK stack.  If another task on that same cpu then enters do_debug()
      and uses the same per-cpu DEBUG_STACK stack, the previous preempted tasks's
      stack contents can be corrupted, and the system will oops when the
      preempted task is context switched back in again.
      
      The typical oops looks like the following:
      
        Unable to handle kernel paging request at ffffffffffffffae RIP: <ffffffff805452a1>{thread_return+34}
        PGD 103027 PUD 102429067 PMD 0
        Oops: 0002 [1] PREEMPT SMP
        CPU 0
        Modules linked in:
        Pid: 3786, comm: ssdd Not tainted 2.6.15.2 #1
        RIP: 0010:[<ffffffff805452a1>] <ffffffff805452a1>{thread_return+34}
        RSP: 0018:ffffffff80824058  EFLAGS: 000136c2
        RAX: ffff81017e12cea0 RBX: 0000000000000000 RCX: 00000000c0000100
        RDX: 0000000000000000 RSI: ffff8100f7856e20 RDI: ffff81017e12cea0
        RBP: 0000000000000046 R08: ffff8100f68a6000 R09: 0000000000000000
        R10: 0000000000000000 R11: ffff81017e12cea0 R12: ffff81000c2d53e8
        R13: ffff81017f5b3be8 R14: ffff81000c0036e0 R15: 000001056cbfc899
        FS:  00002aaaaaad9b00(0000) GS:ffffffff80883800(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: ffffffffffffffae CR3: 00000000f6fcf000 CR4: 00000000000006e0
        Process ssdd (pid: 3786, threadinfo ffff8100f68a6000, task ffff8100f7856e20)
        Stack: ffffffff808240d8 ffffffff8012a84a ffff8100055f6c00 0000000000000020
               0000000000000001 ffff81000c0036e0 ffffffff808240b8 0000000000000000
               0000000000000000 0000000000000000
        Call Trace: <#DB>
      	<ffffffff8012a84a>{try_to_wake_up+985}
      	<ffffffff8012c0d3>{kick_process+87}
              <ffffffff8013b262>{signal_wake_up+48}
      	<ffffffff8013b5ce>{specific_send_sig_info+179}
              <ffffffff80546abc>{_spin_unlock_irqrestore+27}
      	<ffffffff8013b67c>{force_sig_info+159}
              <ffffffff801103a0>{do_debug+289} <ffffffff80110278>{sync_regs+103}
              <ffffffff8010ed9a>{paranoid_userspace+35}
        Unable to handle kernel paging request at 00007fffffb7d000 RIP: <ffffffff8010f2e4>{show_trace+465}
        PGD f6f25067 PUD f6fcc067 PMD f6957067 PTE 0
        Oops: 0000 [2] PREEMPT SMP
      
      This patch disables preemptions for the task upon entry to do_debug(), before
      interrupts are reenabled, and then disables preemption before exiting
      do_debug(), after disabling interrupts.  I've noticed that the task can be
      preempted either at the end of an interrupt, or on the call to
      force_sig_info() on the spin_unlock_irqrestore() processing.  It might be
      better to attempt to code a fix in entry.S around the code that calls
      do_debug().
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a65d17c9
  17. 04 Feb, 2006 1 commit
  18. 12 Jan, 2006 2 commits
  19. 11 Jan, 2006 9 commits