1. 21 Oct, 2015 1 commit
    • Baoquan He's avatar
      x86/setup: Do not reserve crashkernel high memory if low reservation failed · eb6db83d
      Baoquan He authored
      People reported that when allocating crashkernel memory using
      the ",high" and ",low" syntax, there were cases where the
      reservation of the high portion succeeds but the reservation of
      the low portion fails.
      
      Then kexec can load the kdump kernel successfully, but booting
      the kdump kernel fails as there's no low memory.
      
      The low memory allocation for the kdump kernel can fail on large
      systems for a couple of reasons. For example, the manually
      specified crashkernel low memory can be too large and thus no
      adequate memblock region would be found.
      
      Therefore, we try to reserve low memory for the crash kernel
      *after* the high memory portion has been allocated. If that
      fails, we free crashkernel high memory too and return. The user
      can then take measures accordingly.
      Tested-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      [ Massage text. ]
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarJoerg Roedel <jroedel@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: WANG Chao <chaowang@redhat.com>
      Cc: jerry_hoemann@hp.com
      Cc: yinghai@kernel.org
      Link: http://lkml.kernel.org/r/1445246268-26285-2-git-send-email-bp@alien8.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      eb6db83d
  2. 12 Oct, 2015 6 commits
  3. 11 Oct, 2015 9 commits
  4. 10 Oct, 2015 12 commits
  5. 09 Oct, 2015 10 commits
  6. 08 Oct, 2015 2 commits
    • Mikulas Patocka's avatar
      crash in md-raid1 and md-raid10 due to incorrect list manipulation · a452744b
      Mikulas Patocka authored
      The commit 55ce74d4 (md/raid1: ensure
      device failure recorded before write request returns) is causing crash in
      the LVM2 testsuite test shell/lvchange-raid.sh. For me the crash is 100%
      reproducible.
      
      The reason for the crash is that the newly added code in raid1d moves the
      list from conf->bio_end_io_list to tmp, then tests if tmp is non-empty and
      then incorrectly pops the bio from conf->bio_end_io_list (which is empty
      because the list was alrady moved).
      
      Raid-10 has a similar bug.
      
      Kernel Fault: Code=15 regs=000000006ccb8640 (Addr=0000000100000000)
      CPU: 3 PID: 1930 Comm: mdX_raid1 Not tainted 4.2.0-rc5-bisect+ #35
      task: 000000006cc1f258 ti: 000000006ccb8000 task.ti: 000000006ccb8000
      
           YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
      PSW: 00001000000001001111111000001111 Not tainted
      r00-03  000000ff0804fe0f 000000001059d000 000000001059f818 000000007f16be38
      r04-07  000000001059d000 000000007f16be08 0000000000200200 0000000000000001
      r08-11  000000006ccb8260 000000007b7934d0 0000000000000001 0000000000000000
      r12-15  000000004056f320 0000000000000000 0000000000013dd0 0000000000000000
      r16-19  00000000f0d00ae0 0000000000000000 0000000000000000 0000000000000001
      r20-23  000000000800000f 0000000042200390 0000000000000000 0000000000000000
      r24-27  0000000000000001 000000000800000f 000000007f16be08 000000001059d000
      r28-31  0000000100000000 000000006ccb8560 000000006ccb8640 0000000000000000
      sr00-03  0000000000249800 0000000000000000 0000000000000000 0000000000249800
      sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      
      IASQ: 0000000000000000 0000000000000000 IAOQ: 000000001059f61c 000000001059f620
       IIR: 0f8010c6    ISR: 0000000000000000  IOR: 0000000100000000
       CPU:        3   CR30: 000000006ccb8000 CR31: 0000000000000000
       ORIG_R28: 000000001059d000
       IAOQ[0]: call_bio_endio+0x34/0x1a8 [raid1]
       IAOQ[1]: call_bio_endio+0x38/0x1a8 [raid1]
       RP(r2): raid_end_bio_io+0x88/0x168 [raid1]
      Backtrace:
       [<000000001059f818>] raid_end_bio_io+0x88/0x168 [raid1]
       [<00000000105a4f64>] raid1d+0x144/0x1640 [raid1]
       [<000000004017fd5c>] kthread+0x144/0x160
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Fixes: 55ce74d4 ("md/raid1: ensure device failure recorded before write request returns.")
      Fixes: 95af587e ("md/raid10: ensure device failure recorded before write request returns.")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      a452744b
    • Srinivas Pandruvada's avatar
      cpufreq: prevent lockup on reading scaling_available_frequencies · 55582bcc
      Srinivas Pandruvada authored
      When scaling_available_frequencies is read on an offlined cpu, then
      either lockup or junk values are displayed. This is caused by
      freed freq_table, which policy is using.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      55582bcc