1. 12 Jun, 2009 3 commits
  2. 11 Jun, 2009 1 commit
  3. 10 Jun, 2009 27 commits
  4. 09 Jun, 2009 2 commits
    • Chuck Ebbert's avatar
      x86: Clear TS in irq_ts_save() when in an atomic section · 0b8c3d5a
      Chuck Ebbert authored
      The dynamic FPU context allocation changes caused the padlock driver
      to generate the below warning. Fix it by masking TS when doing padlock
      encryption operations in an atomic section.
      This solves:
      BUG: sleeping function called from invalid context at mm/slub.c:1602
      in_atomic(): 1, irqs_disabled(): 0, pid: 82, name: cryptomgr_test
      Pid: 82, comm: cryptomgr_test Not tainted #1
      Call Trace:
      [<ffffffff8103ff16>] __might_sleep+0x10b/0x110
      [<ffffffff810cd3b2>] kmem_cache_alloc+0x37/0xf1
      [<ffffffff81018505>] init_fpu+0x49/0x8a
      [<ffffffff81012a83>] math_state_restore+0x3e/0xbc
      [<ffffffff813ac6d0>] do_device_not_available+0x9/0xb
      [<ffffffff810123ab>] device_not_available+0x1b/0x20
      [<ffffffffa001c066>] ? aes_crypt+0x66/0x74 [padlock_aes]
      [<ffffffff8119a51a>] ? blkcipher_walk_next+0x257/0x2e0
      [<ffffffff8119a731>] ? blkcipher_walk_first+0x18e/0x19d
      [<ffffffffa001c1fe>] aes_encrypt+0x9d/0xe5 [padlock_aes]
      [<ffffffffa0027253>] crypt+0x6b/0x114 [xts]
      [<ffffffffa001c161>] ? aes_encrypt+0x0/0xe5 [padlock_aes]
      [<ffffffffa001c161>] ? aes_encrypt+0x0/0xe5 [padlock_aes]
      [<ffffffffa0027390>] encrypt+0x49/0x4b [xts]
      [<ffffffff81199acc>] async_encrypt+0x3c/0x3e
      [<ffffffff8119dafc>] test_skcipher+0x1da/0x658
      [<ffffffff811979c3>] ? crypto_spawn_tfm+0x8e/0xb1
      [<ffffffff8119672d>] ? __crypto_alloc_tfm+0x11b/0x15f
      [<ffffffff811979c3>] ? crypto_spawn_tfm+0x8e/0xb1
      [<ffffffff81199dbe>] ? skcipher_geniv_init+0x2b/0x47
      [<ffffffff8119a905>] ? async_chainiv_init+0x5c/0x61
      [<ffffffff8119dfdd>] alg_test_skcipher+0x63/0x9b
      [<ffffffff8119e1bc>] alg_test+0x12d/0x175
      [<ffffffff8119c488>] cryptomgr_test+0x38/0x54
      [<ffffffff8119c450>] ? cryptomgr_test+0x0/0x54
      [<ffffffff8105c6c9>] kthread+0x4d/0x78
      [<ffffffff8101264a>] child_rip+0xa/0x20
      [<ffffffff81011f67>] ? restore_args+0x0/0x30
      [<ffffffff8105c67c>] ? kthread+0x0/0x78
      [<ffffffff81012640>] ? child_rip+0x0/0x20
      Signed-off-by: default avatarChuck Ebbert <cebbert@redhat.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <20090609104050.50158cfe@dhcp-100-2-144.bos.redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Andreas Herrmann's avatar
      x86: Detect use of extended APIC ID for AMD CPUs · 42937e81
      Andreas Herrmann authored
      Booting a 32-bit kernel on Magny-Cours results in the following panic:
        Using APIC driver default
        Overriding APIC driver with bigsmp
        Getting VERSION: 80050010
        Getting VERSION: 80050010
        Getting ID: 10000000
        Getting ID: ef000000
        Getting LVT0: 700
        Getting LVT1: 10000
        Kernel panic - not syncing: Boot APIC ID in local APIC unexpected (16 vs 0)
        Pid: 1, comm: swapper Not tainted 2.6.30-rcX #2
        Call Trace:
         [<c05194da>] ? panic+0x38/0xd3
         [<c0743102>] ? native_smp_prepare_cpus+0x259/0x31f
         [<c073b19d>] ? kernel_init+0x3e/0x141
         [<c073b15f>] ? kernel_init+0x0/0x141
         [<c020325f>] ? kernel_thread_helper+0x7/0x10
      The reason is that default_get_apic_id handled extension of local APIC
      ID field just in case of XAPIC.
      Thus for this AMD CPU, default_get_apic_id() returns 0 and
      bigsmp_get_apic_id() returns 16 which leads to the respective kernel
      This patch introduces a Linux specific feature flag to indicate
      support for extended APIC id (8 bits instead of 4 bits width) and sets
      the flag on AMD CPUs if applicable.
      Signed-off-by: default avatarAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <20090608135509.GA12431@alberich.amd.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  5. 08 Jun, 2009 1 commit
    • Jack Steiner's avatar
      x86, UV: Fix macros for multiple coherency domains · c4ed3f04
      Jack Steiner authored
      Fix bug in the SGI UV macros that support systems with multiple
      coherency domains.  The macros used for referencing global MMR
      (chipset registers) are failing to correctly "or" the NASID
      (node identifier) bits that reside above M+N. These high bits
      are supplied automatically by the chipset for memory accesses
      coming from the processor socket.
      However, the bits must be present for references to the special
      global MMR space used to map chipset registers. (See uv_hub.h
      for more details ...)
      The bug results in references to invalid/incorrect nodes.
      Signed-off-by: default avatarJack Steiner <steiner@sgi.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <20090608154405.GA16395@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  6. 07 Jun, 2009 2 commits
  7. 03 Jun, 2009 2 commits
    • Cliff Wickman's avatar
      x86: Fix UV BAU activation descriptor init · 0e2595cd
      Cliff Wickman authored
      The UV tlb shootdown code has a serious initialization error.
      An array of structures [32*8] is initialized as if it were [32].
      The array is indexed by (cpu number on the blade)*8, so the short
      initialization works for up to 4 cpus on a blade.
      But above that, we provide an invalid opcode to the hub's
      broadcast assist unit.
      This patch changes the allocation of the array to use its symbolic
      dimensions for better clarity. And initializes all 32*8 entries.
      Shortened 'UV_ACTIVATION_DESCRIPTOR_SIZE' to 'UV_ADP_SIZE' per Ingo's
      Tested on the UV simulator.
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <E1M6lZR-0007kV-Aq@eag09.americas.sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Yong Wang's avatar
      perf_counter/x86: Remove the IRQ (non-NMI) handling bits · a3288106
      Yong Wang authored
      Remove the IRQ (non-NMI) handling bits as NMI will be used always.
      Signed-off-by: default avatarYong Wang <yong.y.wang@intel.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: John Kacur <jkacur@redhat.com>
      LKML-Reference: <20090603051255.GA2791@ywang-moblin2.bj.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  8. 29 May, 2009 1 commit
  9. 28 May, 2009 1 commit