1. 14 9月, 2010 1 次提交
  2. 11 9月, 2010 2 次提交
  3. 10 9月, 2010 8 次提交
  4. 09 9月, 2010 4 次提交
  5. 08 9月, 2010 8 次提交
  6. 05 9月, 2010 2 次提交
    • A
      x86, mcheck: Avoid duplicate sysfs links/files for thresholding banks · 1389298f
      Andreas Herrmann 提交于
      kobject_add_internal failed for threshold_bank2 with -EEXIST,
      don't try to register things with the same name in the same
      directory:
      
        Pid: 1, comm: swapper Tainted: G        W  2.6.31 #1
        Call Trace:
        [<ffffffff81161b07>] ? kobject_add_internal+0x156/0x180
        [<ffffffff81161cc0>] ? kobject_add+0x66/0x6b
        [<ffffffff81161793>] ? kobject_init+0x42/0x82
        [<ffffffff81161cf9>] ? kobject_create_and_add+0x34/0x63
        [<ffffffff81393963>] ? threshold_create_bank+0x14f/0x259
        [<ffffffff8139310a>] ? mce_create_device+0x8d/0x1b8
        [<ffffffff81646497>] ? threshold_init_device+0x3f/0x80
        [<ffffffff81646458>] ? threshold_init_device+0x0/0x80
        [<ffffffff81009050>] ? do_one_initcall+0x4f/0x143
        [<ffffffff816413a0>] ? kernel_init+0x14c/0x1a2
        [<ffffffff8100c8da>] ? child_rip+0xa/0x20
        [<ffffffff81641254>] ? kernel_init+0x0/0x1a2
        [<ffffffff8100c8d0>] ? child_rip+0x0/0x20
        kobject_create_and_add: kobject_add error: -17
      
      (Probably the for_each_cpu loop should be entirely removed.)
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      LKML-Reference: <20100827092006.GB5348@loge.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1389298f
    • F
      x86: Fix the address space annotations of iomap_atomic_prot_pfn() · cc1a8e52
      Francisco Jerez 提交于
      This patch fixes the sparse warnings when the return pointer of
      iomap_atomic_prot_pfn() is used as an argument of iowrite32()
      and friends.
      Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
      LKML-Reference: <1283633804-11749-1-git-send-email-currojerez@riseup.net>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cc1a8e52
  7. 03 9月, 2010 3 次提交
    • R
      perf, x86: Try to handle unknown nmis with an enabled PMU · 4177c42a
      Robert Richter 提交于
      When the PMU is enabled it is valid to have unhandled nmis, two
      events could trigger 'simultaneously' raising two back-to-back
      NMIs. If the first NMI handles both, the latter will be empty
      and daze the CPU.
      
      The solution to avoid an 'unknown nmi' massage in this case was
      simply to stop the nmi handler chain when the PMU is enabled by
      stating the nmi was handled. This has the drawback that a) we
      can not detect unknown nmis anymore, and b) subsequent nmi
      handlers are not called.
      
      This patch addresses this. Now, we check this unknown NMI if it
      could be a PMU back-to-back NMI. Otherwise we pass it and let
      the kernel handle the unknown nmi.
      
      This is a debug log:
      
       cpu #6, nmi #32333, skip_nmi #32330, handled = 1, time = 1934364430
       cpu #6, nmi #32334, skip_nmi #32330, handled = 1, time = 1934704616
       cpu #6, nmi #32335, skip_nmi #32336, handled = 2, time = 1936032320
       cpu #6, nmi #32336, skip_nmi #32336, handled = 0, time = 1936034139
       cpu #6, nmi #32337, skip_nmi #32336, handled = 1, time = 1936120100
       cpu #6, nmi #32338, skip_nmi #32336, handled = 1, time = 1936404607
       cpu #6, nmi #32339, skip_nmi #32336, handled = 1, time = 1937983416
       cpu #6, nmi #32340, skip_nmi #32341, handled = 2, time = 1938201032
       cpu #6, nmi #32341, skip_nmi #32341, handled = 0, time = 1938202830
       cpu #6, nmi #32342, skip_nmi #32341, handled = 1, time = 1938443743
       cpu #6, nmi #32343, skip_nmi #32341, handled = 1, time = 1939956552
       cpu #6, nmi #32344, skip_nmi #32341, handled = 1, time = 1940073224
       cpu #6, nmi #32345, skip_nmi #32341, handled = 1, time = 1940485677
       cpu #6, nmi #32346, skip_nmi #32347, handled = 2, time = 1941947772
       cpu #6, nmi #32347, skip_nmi #32347, handled = 1, time = 1941949818
       cpu #6, nmi #32348, skip_nmi #32347, handled = 0, time = 1941951591
       Uhhuh. NMI received for unknown reason 00 on CPU 6.
       Do you have a strange power saving mode enabled?
       Dazed and confused, but trying to continue
      
      Deltas:
      
       nmi #32334 340186
       nmi #32335 1327704
       nmi #32336 1819      <<<< back-to-back nmi [1]
       nmi #32337 85961
       nmi #32338 284507
       nmi #32339 1578809
       nmi #32340 217616
       nmi #32341 1798      <<<< back-to-back nmi [2]
       nmi #32342 240913
       nmi #32343 1512809
       nmi #32344 116672
       nmi #32345 412453
       nmi #32346 1462095   <<<< 1st nmi (standard) handling 2 counters
       nmi #32347 2046      <<<< 2nd nmi (back-to-back) handling one
       counter nmi #32348 1773      <<<< 3rd nmi (back-to-back)
       handling no counter! [3]
      
      For  back-to-back nmi detection there are the following rules:
      
      The PMU nmi handler was handling more than one counter and no
      counter was handled in the subsequent nmi (see [1] and [2]
      above).
      
      There is another case if there are two subsequent back-to-back
      nmis [3]. The 2nd is detected as back-to-back because the first
      handled more than one counter. If the second handles one counter
      and the 3rd handles nothing, we drop the 3rd nmi because it
      could be a back-to-back nmi.
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      [ renamed nmi variable to pmu_nmi to avoid clash with .nmi in entry.S ]
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: peterz@infradead.org
      Cc: gorcunov@gmail.com
      Cc: fweisbec@gmail.com
      Cc: ying.huang@intel.com
      Cc: ming.m.lin@intel.com
      Cc: eranian@google.com
      LKML-Reference: <1283454469-1909-3-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4177c42a
    • P
      perf, x86: Fix handle_irq return values · de725dec
      Peter Zijlstra 提交于
      Now that we rely on the number of handled overflows, ensure all
      handle_irq implementations actually return the right number.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: peterz@infradead.org
      Cc: robert.richter@amd.com
      Cc: gorcunov@gmail.com
      Cc: fweisbec@gmail.com
      Cc: ying.huang@intel.com
      Cc: ming.m.lin@intel.com
      Cc: eranian@google.com
      LKML-Reference: <1283454469-1909-4-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      de725dec
    • D
      perf, x86: Fix accidentally ack'ing a second event on intel perf counter · 2e556b5b
      Don Zickus 提交于
      During testing of a patch to stop having the perf subsytem
      swallow nmis, it was uncovered that Nehalem boxes were randomly
      getting unknown nmis when using the perf tool.
      
      Moving the ack'ing of the PMI closer to when we get the status
      allows the hardware to properly re-set the PMU bit signaling
      another PMI was triggered during the processing of the first
      PMI.  This allows the new logic for dealing with the
      shortcomings of multiple PMIs to handle the extra NMI by
      'eat'ing it later.
      
      Now one can wonder why are we getting a second PMI when we
      disable all the PMUs in the begining of the NMI handler to
      prevent such a case, for that I do not know.  But I know the fix
      below helps deal with this quirk.
      
      Tested on multiple Nehalems where the problem was occuring.
      With the patch, the code now loops a second time to handle the
      second PMI (whereas before it was not).
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: peterz@infradead.org
      Cc: robert.richter@amd.com
      Cc: gorcunov@gmail.com
      Cc: fweisbec@gmail.com
      Cc: ying.huang@intel.com
      Cc: ming.m.lin@intel.com
      Cc: eranian@google.com
      LKML-Reference: <1283454469-1909-2-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2e556b5b
  8. 02 9月, 2010 5 次提交
  9. 01 9月, 2010 7 次提交