1. 03 1月, 2017 2 次提交
  2. 12 10月, 2016 1 次提交
    • H
      mips/panic: replace smp_send_stop() with kdump friendly version in panic path · 54c721b8
      Hidehiro Kawai 提交于
      Daniel Walker reported problems which happens when
      crash_kexec_post_notifiers kernel option is enabled
      (https://lkml.org/lkml/2015/6/24/44).
      
      In that case, smp_send_stop() is called before entering kdump routines
      which assume other CPUs are still online.  As the result, kdump
      routines fail to save other CPUs' registers.  Additionally for MIPS
      OCTEON, it misses to stop the watchdog timer.
      
      To fix this problem, call a new kdump friendly function,
      crash_smp_send_stop(), instead of the smp_send_stop() when
      crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a
      weak function, and it just call smp_send_stop().  Architecture
      codes should override it so that kdump can work appropriately.
      This patch provides MIPS version.
      
      Fixes: f06e5153 (kernel/panic.c: add "crash_kexec_post_notifiers" option)
      Link: http://lkml.kernel.org/r/20160810080950.11028.28000.stgit@sysi4-13.yrl.intra.hitachi.co.jpSigned-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Reported-by: NDaniel Walker <dwalker@fifo99.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Daniel Walker <dwalker@fifo99.com>
      Cc: Xunlei Pang <xpang@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Toshi Kani <toshi.kani@hpe.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: "Steven J. Hill" <steven.hill@cavium.com>
      Cc: Corey Minyard <cminyard@mvista.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      54c721b8
  3. 04 10月, 2016 2 次提交
  4. 12 7月, 2016 1 次提交
  5. 13 5月, 2016 8 次提交
  6. 12 11月, 2015 1 次提交
  7. 03 10月, 2015 1 次提交
    • M
      MIPS: Octeon: Fix kernel panic on startup from memory corruption · 66803dd9
      Matt Bennett 提交于
      During development it was found that a number of builds would panic
      during the kernel init process, more specifically in 'delayed_fput()'.
      The panic showed the kernel trying to access a memory address of
      '0xb7fdc00' while traversing the 'delayed_fput_list' structure.
      Comparing this memory address to the value of the pointer used on
      builds that did not panic confirmed that the pointer on crashing
      builds must have been corrupted at some stage earlier in the init
      process.
      
      By traversing the list earlier and earlier in the code it was found
      that 'plat_mem_setup()' was responsible for corrupting the list.
      Specifically the line:
      
          memory = cvmx_bootmem_phy_alloc(mem_alloc_size,
      			__pa_symbol(&__init_end), -1,
      			0x100000,
      			CVMX_BOOTMEM_FLAG_NO_LOCKING);
      
      Which would eventually call:
      
          cvmx_bootmem_phy_set_size(new_ent_addr,
      		cvmx_bootmem_phy_get_size
      		(ent_addr) -
      		(desired_min_addr -
      			ent_addr));
      
      Where 'new_ent_addr'=0x4800000 (the address of 'delayed_fput_list')
      and the second argument (size)=0xb7fdc00 (the address causing the
      kernel panic). The job of this part of 'plat_mem_setup()' is to
      allocate chunks of memory for the kernel to use. At the start of
      each chunk of memory the size of the chunk is written, hence the
      value 0xb7fdc00 is written onto memory at 0x4800000, therefore the
      kernel panics when it goes back to access 'delayed_fput_list' later
      on in the initialisation process.
      
      On builds that were not crashing it was found that the compiler had
      placed 'delayed_fput_list' at 0x4800008, meaning it wasn't corrupted
      (but something else in memory was overwritten).
      
      As can be seen in the first function call above the code begins to
      allocate chunks of memory beginning from the symbol '__init_end'.
      The MIPS linker script (vmlinux.lds.S) however defines the .bss
      section to begin after '__init_end'. Therefore memory within the
      .bss section is allocated to the kernel to use (System.map shows
      'delayed_fput_list' and other kernel structures to be in .bss).
      
      To stop the kernel panic (and the .bss section being corrupted)
      memory should begin being allocated from the symbol '_end'.
      Signed-off-by: NMatt Bennett <matt.bennett@alliedtelesis.co.nz>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Cc: linux-mips@linux-mips.org
      Cc: aleksey.makarov@auriga.com
      Patchwork: https://patchwork.linux-mips.org/patch/11251/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      66803dd9
  8. 01 4月, 2015 3 次提交
  9. 25 3月, 2015 1 次提交
  10. 20 2月, 2015 5 次提交
  11. 20 11月, 2014 1 次提交
  12. 23 10月, 2014 1 次提交
  13. 26 8月, 2014 2 次提交
  14. 20 8月, 2014 1 次提交
  15. 19 8月, 2014 1 次提交
  16. 23 5月, 2014 2 次提交
  17. 30 4月, 2014 1 次提交
  18. 30 10月, 2013 1 次提交
  19. 26 8月, 2013 1 次提交
  20. 22 6月, 2013 1 次提交
  21. 18 6月, 2013 1 次提交
    • R
      MIPS: Oceton: Fix build error. · 39205750
      Ralf Baechle 提交于
      If CONFIG_CAVIUM_OCTEON_LOCK_L2_TLB, CONFIG_CAVIUM_OCTEON_LOCK_L2_EXCEPTION,
      CONFIG_CAVIUM_OCTEON_LOCK_L2_LOW_LEVEL_INTERRUPT and
      CONFIG_CAVIUM_OCTEON_LOCK_L2_INTERRUPT are all undefined:
      
      arch/mips/cavium-octeon/setup.c: In function ‘prom_init’:
      arch/mips/cavium-octeon/setup.c:715:12: error: unused variable ‘ebase’ [-Werror=unused-variable]
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      39205750
  22. 11 6月, 2013 1 次提交
  23. 06 6月, 2013 1 次提交
    • D
      MIPS: OCTEON: Improve _machine_halt implementation. · 38c3c0f6
      David Daney 提交于
      As noted by Wladislav Wiebe:
         $ halt
         ..
         Sent SIGKILL to all processes
         Requesting system halt
         [66.729373] System halted.
         [66.733244]
         [66.734761] =====================================
         [66.739473] [ BUG: lock held at task exit time! ]
         [66.744188] 3.8.7-0-sampleversion-fct #49 Tainted: G           O
         [66.750202] -------------------------------------
         [66.754913] init/21479 is exiting with locks still held!
         [66.760234] 1 lock held by init/21479:
         [66.763990]  #0:  (reboot_mutex){+.+...}, at: [<ffffffff801776c8>] SyS_reboot+0xe0/0x218
         [66.772165]
         [66.772165] stack backtrace:
         [66.776532] Call Trace:
         [66.778992] [<ffffffff805780a8>] dump_stack+0x8/0x34
         [66.783972] [<ffffffff801618b0>] do_exit+0x610/0xa70
         [66.788948] [<ffffffff801777a8>] SyS_reboot+0x1c0/0x218
         [66.794186] [<ffffffff8013d6a4>] handle_sys64+0x44/0x64
      
      This is an alternative fix to the one sent by Wladislav.  We kill the
      watchdog for each CPU and then spin in WAIT with interrupts disabled.
      This is the lowest power mode for the OCTEON.  If we were to spin with
      interrupts enabled, we would get a continual stream of warning messages
      and backtraces from the lockup detector, so I chose to disable
      interrupts.
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Cc: Maxim Uvarov <muvarov@gmail.com>
      Cc: Wladislav Wiebe <wladislav.kw@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: David Daney <david.daney@cavium.com>
      Patchwork: https://patchwork.linux-mips.org/patch/5324/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      38c3c0f6