1. 17 7月, 2010 1 次提交
    • Y
      x86: Fix x2apic preenabled system with kexec · fd19dce7
      Yinghai Lu 提交于
      Found one x2apic system kexec loop test failed
      when CONFIG_NMI_WATCHDOG=y (old) or CONFIG_LOCKUP_DETECTOR=y (current tip)
      
      first kernel can kexec second kernel, but second kernel can not kexec third one.
      
      it can be duplicated on another system with BIOS preenabled x2apic.
      First kernel can not kexec second kernel.
      
      It turns out, when kernel boot with pre-enabled x2apic, it will not execute
      disable_local_APIC on shutdown path.
      
      when init_apic_mappings() is called in setup_arch, it will skip setting of
      apic_phys when x2apic_mode is set. ( x2apic_mode is much early check_x2apic())
      Then later, disable_local_APIC() will bail out early because !apic_phys.
      
      So check !x2apic_mode in x2apic_mode in disable_local_APIC with !apic_phys.
      
      another solution could be updating init_apic_mappings() to set apic_phys even
      for preenabled x2apic system. Actually even for x2apic system, that lapic
      address is mapped already in early stage.
      
      BTW: is there any x2apic preenabled system with apicid of boot cpu > 255?
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4C3EB22B.3000701@kernel.org>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      fd19dce7
  2. 15 7月, 2010 5 次提交
  3. 14 7月, 2010 3 次提交
  4. 13 7月, 2010 8 次提交
  5. 12 7月, 2010 10 次提交
  6. 10 7月, 2010 3 次提交
    • R
      ARM: lockdep: fix unannotated irqs-on · ac78884e
      Russell King 提交于
      CPU: Testing write buffer coherency: ok
      ------------[ cut here ]------------
      WARNING: at kernel/lockdep.c:3145 check_flags+0xcc/0x1dc()
      Modules linked in:
      [<c0035120>] (unwind_backtrace+0x0/0xf8) from [<c0355374>] (dump_stack+0x20/0x24)
      [<c0355374>] (dump_stack+0x20/0x24) from [<c0060c04>] (warn_slowpath_common+0x58/0x70)
      [<c0060c04>] (warn_slowpath_common+0x58/0x70) from [<c0060c3c>] (warn_slowpath_null+0x20/0x24)
      [<c0060c3c>] (warn_slowpath_null+0x20/0x24) from [<c008f224>] (check_flags+0xcc/0x1dc)
      [<c008f224>] (check_flags+0xcc/0x1dc) from [<c00945dc>] (lock_acquire+0x50/0x140)
      [<c00945dc>] (lock_acquire+0x50/0x140) from [<c0358434>] (_raw_spin_lock+0x50/0x88)
      [<c0358434>] (_raw_spin_lock+0x50/0x88) from [<c00fd114>] (set_task_comm+0x2c/0x60)
      [<c00fd114>] (set_task_comm+0x2c/0x60) from [<c007e184>] (kthreadd+0x30/0x108)
      [<c007e184>] (kthreadd+0x30/0x108) from [<c0030104>] (kernel_thread_exit+0x0/0x8)
      ---[ end trace 1b75b31a2719ed1c ]---
      possible reason: unannotated irqs-on.
      irq event stamp: 3
      hardirqs last  enabled at (2): [<c0059bb0>] finish_task_switch+0x48/0xb0
      hardirqs last disabled at (3): [<c002f0b0>] ret_slow_syscall+0xc/0x1c
      softirqs last  enabled at (0): [<c005f3e0>] copy_process+0x394/0xe5c
      softirqs last disabled at (0): [<(null)>] (null)
      
      Fix this by ensuring that the lockdep interrupt state is manipulated in
      the appropriate places.  We essentially treat userspace as an entirely
      separate environment which isn't relevant to lockdep (lockdep doesn't
      monitor userspace.)  We don't tell lockdep that IRQs will be enabled
      in that environment.
      
      Instead, when creating kernel threads (which is a rare event compared
      to entering/leaving userspace) we have to update the lockdep state.  Do
      this by starting threads with IRQs disabled, and in the kthread helper,
      tell lockdep that IRQs are enabled, and enable them.
      
      This provides lockdep with a consistent view of the current IRQ state
      in kernel space.
      
      This also revert portions of 0d928b0b
      which didn't fix the problem.
      Tested-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ac78884e
    • G
      i2c/mips: Fix error return codes from Sibyte i2c bus driver · 102b59c6
      Guenter Roeck 提交于
      Sibyte i2c bus driver returns non-descriptive error values.
      Update to return error values as defined in Documentation/i2c/fault-codes.
      Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      102b59c6
    • J
      i2c: Fix probability check · 827900c5
      Jean Delvare 提交于
      The new unified probing function differs from the original code, and
      the preliminary test whether probing is possible must be updated
      accordingly.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      827900c5
  7. 09 7月, 2010 10 次提交