1. 04 10月, 2016 1 次提交
  2. 12 7月, 2016 1 次提交
  3. 13 5月, 2016 8 次提交
  4. 12 11月, 2015 1 次提交
  5. 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
  6. 01 4月, 2015 3 次提交
  7. 25 3月, 2015 1 次提交
  8. 20 2月, 2015 5 次提交
  9. 20 11月, 2014 1 次提交
  10. 23 10月, 2014 1 次提交
  11. 26 8月, 2014 2 次提交
  12. 20 8月, 2014 1 次提交
  13. 19 8月, 2014 1 次提交
  14. 23 5月, 2014 2 次提交
  15. 30 4月, 2014 1 次提交
  16. 30 10月, 2013 1 次提交
  17. 26 8月, 2013 1 次提交
  18. 22 6月, 2013 1 次提交
  19. 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
  20. 11 6月, 2013 1 次提交
  21. 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
  22. 05 4月, 2013 1 次提交
  23. 01 2月, 2013 1 次提交
  24. 14 12月, 2012 2 次提交