1. 26 3月, 2009 5 次提交
  2. 19 2月, 2009 1 次提交
  3. 31 12月, 2008 1 次提交
  4. 25 12月, 2008 5 次提交
  5. 15 11月, 2008 1 次提交
  6. 25 7月, 2008 1 次提交
  7. 14 7月, 2008 4 次提交
  8. 30 4月, 2008 3 次提交
  9. 27 4月, 2008 2 次提交
  10. 17 4月, 2008 3 次提交
  11. 10 2月, 2008 1 次提交
  12. 08 2月, 2008 1 次提交
    • B
      Introduce flags for reserve_bootmem() · 72a7fe39
      Bernhard Walle 提交于
      This patchset adds a flags variable to reserve_bootmem() and uses the
      BOOTMEM_EXCLUSIVE flag in crashkernel reservation code to detect collisions
      between crashkernel area and already used memory.
      
      This patch:
      
      Change the reserve_bootmem() function to accept a new flag BOOTMEM_EXCLUSIVE.
      If that flag is set, the function returns with -EBUSY if the memory already
      has been reserved in the past.  This is to avoid conflicts.
      
      Because that code runs before SMP initialisation, there's no race condition
      inside reserve_bootmem_core().
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix powerpc build]
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Cc: <linux-arch@vger.kernel.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      72a7fe39
  13. 05 2月, 2008 3 次提交
  14. 26 1月, 2008 6 次提交
  15. 04 12月, 2007 1 次提交
  16. 20 11月, 2007 2 次提交
    • H
      [S390] Fix irq tracing and lockdep_sys_exit calls. · 411788ea
      Heiko Carstens 提交于
      Current support for TRACE_IRQFLAGS and lockdep_sys_exit is broken.
      IRQ flag tracing is broken for program checks. Even worse is that
      the newly introduced calls to lockdep_sys_exit are in the critical
      section code which is not supposed to call any C functions. In
      addition the checks if locks are still held are also done when
      returning to kernel code which is broken as well.
      Fix all this by disabling interrupts and machine checks at the
      exit paths and then do the appropriate checks and calls.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      411788ea
    • C
      [S390] magic sysrq: check for in_atomic before doing an console_unblank · 7aa8dac7
      Christian Borntraeger 提交于
      When doing an magic sysrq reboot on s390 the following bug message
      appears:
      
      SysRq : Resetting
      BUG: sleeping function called from invalid context at include/asm/semaphore.h:61
      
      in_atomic():1, irqs_disabled():0
      07000000004002a8 000000000fe6bc48 0000000000000002 0000000000000000
             000000000fe6bce8 000000000fe6bc60 000000000fe6bc60 000000000012a79a
             0000000000000000 07000000004002a8 0000000000000006 0000000000000000
             0000000000000000 000000000fe6bc48 000000000000000d 000000000fe6bcb8
             00000000004000c8 0000000000103234 000000000fe6bc48 000000000fe6bc90
      Call Trace:
      (¬<00000000001031b2>| show_trace+0x12e/0x148)
       ¬<000000000011ffca>| __might_sleep+0x10a/0x118
       ¬<0000000000129fba>| acquire_console_sem+0x92/0xf4
       ¬<000000000012a2ca>| console_unblank+0xc2/0xc8
       ¬<0000000000107bb4>| machine_restart+0x54/0x6c
       ¬<000000000028e806>| sysrq_handle_reboot+0x26/0x30
       ¬<000000000028e52a>| __handle_sysrq+0xa6/0x180
       ¬<0000000000140134>| run_workqueue+0xcc/0x18c
       ¬<000000000014029a>| worker_thread+0xa6/0x108
       ¬<00000000001458e4>| kthread+0x64/0x9c
       ¬<0000000000106f0e>| kernel_thread_starter+0x6/0xc
       ¬<0000000000106f08>| kernel_thread_starter+0x0/0xc
      
      The only reason for doing a console_unblank on s390 is to flush the
      log buffer. We have to check for in_atomic before doing a
      console_unblank as the console is otherwise filled with an unrelated
      bug message.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      7aa8dac7