1. 16 Jul, 2010 2 commits
    • Jacob Pan's avatar
      x86, pci, mrst: Add extra sanity check in walking the PCI extended cap chain · f82c3d71
      Jacob Pan authored
      The fixed bar capability structure is searched in PCI extended
      configuration space.  We need to make sure there is a valid capability
      ID to begin with otherwise, the search code may stuck in a infinite
      loop which results in boot hang.  This patch adds additional check for
      cap ID 0, which is also invalid, and indicates end of chain.
      End of chain is supposed to have all fields zero, but that doesn't
      seem to always be the case in the field.
      Suggested-by: default avatar"H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarJacob Pan <jacob.jun.pan@linux.intel.com>
      Reviewed-by: Jesse Barnes's avatarJesse Barnes <jbarnes@virtuousgeek.org>
      LKML-Reference: <1279306706-27087-1-git-send-email-jacob.jun.pan@linux.intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
    • Yinghai Lu's avatar
      x86: Fix x2apic preenabled system with kexec · fd19dce7
      Yinghai Lu authored
      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: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4C3EB22B.3000701@kernel.org>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
  2. 15 Jul, 2010 4 commits
  3. 14 Jul, 2010 4 commits
  4. 12 Jul, 2010 8 commits
  5. 11 Jul, 2010 10 commits
  6. 10 Jul, 2010 3 commits
    • Russell King's avatar
      ARM: lockdep: fix unannotated irqs-on · ac78884e
      Russell King authored
      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: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Guenter Roeck's avatar
      i2c/mips: Fix error return codes from Sibyte i2c bus driver · 102b59c6
      Guenter Roeck authored
      Sibyte i2c bus driver returns non-descriptive error values.
      Update to return error values as defined in Documentation/i2c/fault-codes.
      Signed-off-by: default avatarGuenter Roeck <guenter.roeck@ericsson.com>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
    • Jean Delvare's avatar
      i2c: Fix probability check · 827900c5
      Jean Delvare authored
      The new unified probing function differs from the original code, and
      the preliminary test whether probing is possible must be updated
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
  7. 09 Jul, 2010 9 commits