1. 11 Dec, 2009 4 commits
  2. 10 Dec, 2009 6 commits
  3. 09 Dec, 2009 4 commits
    • Andy Isaacson's avatar
      x86: Print DMI_BOARD_NAME as well as DMI_PRODUCT_NAME from __show_regs() · a1884b8e
      Andy Isaacson authored
      
      
      Robert Hancock observes that DMI_BOARD_NAME is often more useful
      than DMI_PRODUCT_NAME, especially on standalone motherboards.
      So, print both.
      Signed-off-by: default avatarAndy Isaacson <adi@hexapodia.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Robert Hancock <hancockrwd@gmail.com>
      Cc: Richard Zidlicky <rz@linux-m68k.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <20091208083021.GB27174@hexapodia.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a1884b8e
    • Andy Isaacson's avatar
      x86: Factor duplicated code out of __show_regs() into show_regs_common() · 814e2c84
      Andy Isaacson authored
      
      
      Unify x86_32 and x86_64 implementations of __show_regs() header,
      standardizing on the x86_64 format string in the process. Also,
      32-bit will now call print_modules.
      Signed-off-by: default avatarAndy Isaacson <adi@hexapodia.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Robert Hancock <hancockrwd@gmail.com>
      Cc: Richard Zidlicky <rz@linux-m68k.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <20091208082942.GA27174@hexapodia.org>
      [ v2: resolved conflict ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      814e2c84
    • Frederic Weisbecker's avatar
      hw-breakpoints: Modify breakpoints without unregistering them · 44234adc
      Frederic Weisbecker authored
      
      
      Currently, when ptrace needs to modify a breakpoint, like disabling
      it, changing its address, type or len, it calls
      modify_user_hw_breakpoint(). This latter will perform the heavy and
      racy task of unregistering the old breakpoint and registering a new
      one.
      
      This is racy as someone else might steal the reserved breakpoint
      slot under us, which is undesired as the breakpoint is only
      supposed to be modified, sometimes in the middle of a debugging
      workflow. We don't want our slot to be stolen in the middle.
      
      So instead of unregistering/registering the breakpoint, just
      disable it while we modify its breakpoint fields and re-enable it
      after if necessary.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Prasad <prasad@linux.vnet.ibm.com>
      LKML-Reference: <1260347148-5519-1-git-send-regression-fweisbec@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      44234adc
    • Joe Perches's avatar
      arch/x86/kernel/microcode*: Use pr_fmt() and remove duplicated KERN_ERR prefix · f58e1f53
      Joe Perches authored
      
      
      - Use #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
      - Remove "microcode: " prefix from each pr_<level>
      - Fix duplicated KERN_ERR prefix
      - Coalesce pr_<level> format strings
      - Add a space after an exclamation point
      
      No other change in output.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
      LKML-Reference: <1260340250.27677.191.camel@Joe-Laptop.home>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f58e1f53
  4. 08 Dec, 2009 2 commits
  5. 07 Dec, 2009 1 commit
    • Thomas Gleixner's avatar
      x86: Fix bogus warning in apic_noop.apic_write() · a946d8f1
      Thomas Gleixner authored
      
      
      apic_noop is used to provide dummy apic functions. It's installed
      when the CPU has no APIC or when the APIC is disabled on the kernel
      command line.
      
      The apic_noop implementation of apic_write() warns when the CPU has
      an APIC or when the APIC is not disabled.
      
      That's bogus. The warning should only happen when the CPU has an
      APIC _AND_ the APIC is not disabled. apic_noop.apic_read() has the
      correct check.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: <stable@kernel.org> # in <= .32 this typo resides in native_apic_write_dummy()
      LKML-Reference: <alpine.LFD.2.00.0912071255420.3089@localhost.localdomain>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a946d8f1
  6. 06 Dec, 2009 5 commits
    • Frederic Weisbecker's avatar
      x86: Fixup wrong irq frame link in stacktraces · af2d8289
      Frederic Weisbecker authored
      
      
      When we enter in irq, two things can happen to preserve the link
      to the previous frame pointer:
      
      - If we were in an irq already, we don't switch to the irq stack
        as we are inside. We just need to save the previous frame
        pointer and to link the new one to the previous.
      
      - Otherwise we need another level of indirection. We enter the irq with
        the previous stack. We save the previous bp inside and make bp
        pointing to its saved address. Then we switch to the irq stack and
        push bp another time but to the new stack. This makes two levels to
        dereference instead of one.
      
      In the second case, the current stacktrace code omits the second level
      and loses the frame pointer accuracy. The stack that follows will then
      be considered as unreliable.
      
      Handling that makes the perf callchain happier.
      Before:
      
      43.94%  [k] _raw_read_lock
                  |
                  --- _read_lock
                     |
                     |--60.53%-- send_sigio
                     |          __kill_fasync
                     |          kill_fasync
                     |          evdev_pass_event
                     |          evdev_event
                     |          input_pass_event
                     |          input_handle_event
                     |          input_event
                     |          synaptics_process_byte
                     |          psmouse_handle_byte
                     |          psmouse_interrupt
                     |          serio_interrupt
                     |          i8042_interrupt
                     |          handle_IRQ_event
                     |          handle_edge_irq
                     |          handle_irq
                     |          __irqentry_text_start
                     |          ret_from_intr
                     |          |
                     |          |--30.43%-- __select
                     |          |
                     |          |--17.39%-- 0x454f15
                     |          |
                     |          |--13.04%-- __read
                     |          |
                     |          |--13.04%-- vread_hpet
                     |          |
                     |          |--13.04%-- _xcb_lock_io
                     |          |
                     |           --13.04%-- 0x7f630878ce8
      
      After:
      
          50.00%  [k] _raw_read_lock
                  |
                  --- _read_lock
                     |
                     |--98.97%-- send_sigio
                     |          __kill_fasync
                     |          kill_fasync
                     |          evdev_pass_event
                     |          evdev_event
                     |          input_pass_event
                     |          input_handle_event
                     |          input_event
                     |          |
                     |          |--96.88%-- synaptics_process_byte
                     |          |          psmouse_handle_byte
                     |          |          psmouse_interrupt
                     |          |          serio_interrupt
                     |          |          i8042_interrupt
                     |          |          handle_IRQ_event
                     |          |          handle_edge_irq
                     |          |          handle_irq
                     |          |          __irqentry_text_start
                     |          |          ret_from_intr
                     |          |          |
                     |          |          |--39.78%-- __const_udelay
                     |          |          |          |
                     |          |          |          |--91.89%-- ath5k_hw_register_timeout
                     |          |          |          |          ath5k_hw_noise_floor_calibration
                     |          |          |          |          ath5k_hw_reset
                     |          |          |          |          ath5k_reset
                     |          |          |          |          ath5k_config
                     |          |          |          |          ieee80211_hw_config
                     |          |          |          |          |
                     |          |          |          |          |--88.24%-- ieee80211_scan_work
                     |          |          |          |          |          worker_thread
                     |          |          |          |          |          kthread
                     |          |          |          |          |          child_rip
                     |          |          |          |          |
                     |          |          |          |           --11.76%-- ieee80211_scan_completed
                     |          |          |          |                     ieee80211_scan_work
                     |          |          |          |                     worker_thread
                     |          |          |          |                     kthread
                     |          |          |          |                     child_rip
                     |          |          |          |
                     |          |          |           --8.11%-- ath5k_hw_noise_floor_calibration
                     |          |          |                     ath5k_hw_reset
                     |          |          |                     ath5k_reset
                     |          |          |                     ath5k_config
      
      Note: This does not only affect perf events but also x86-64
      stacktraces. They were considered as unreliable once we quit
      the irq stack frame.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: "K. Prasad" <prasad@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      af2d8289
    • Frederic Weisbecker's avatar
      x86: Fixup wrong debug exception frame link in stacktraces · b625b3b3
      Frederic Weisbecker authored
      
      
      While dumping a stacktrace, the end of the exception stack won't link
      the frame pointer to the previous stack.
      
      The interrupted stack will then be considered as unreliable and ignored
      by perf, as the frame pointer is unreliable itself.
      
      This happens because we overwrite the frame pointer that links to the
      interrupted frame with the address of the exception stack. This is
      done in order to reserve space inside.
      But rbp has been chosen here only because it is not a scratch register,
      so that the address of the exception stack remains in rbp after calling
      do_debug(), we can then release the exception stack space without the
      need to retrieve its address again.
      
      But we can pick another non-scratch register to do that, so that we
      preserve the link to the interrupted stack frame in the stacktraces.
      
      Just randomly choose r12. Every registers are saved just before and
      restored just after calling do_debug(). And r12 is not used in the
      middle, which makes it a perfect candidate.
      
      Example: perf record -g -a -c 1 -f -e mem:$(tasklist_lock_addr):rw
      
      Before:
          44.18%  [k] _raw_read_lock
                  |
                  |
                  ---  |--6.31%-- waitid
                       |
                       |--4.26%-- writev
                       |
                       |--3.63%-- __select
                       |
                       |--3.15%-- __waitpid
                       |          |
                       |          |--28.57%-- 0x8b52e00000139f
                       |          |
                       |          |--28.57%-- 0x8b52e0000013c6
                       |          |
                       |          |--14.29%-- 0x7fde786dc000
                       |          |
                       |          |--14.29%-- 0x62696c2f7273752f
                       |          |
                       |           --14.29%-- 0x1ea9df800000000
                       |
                       |--3.00%-- __poll
      
      After:
      
          43.94%  [k] _raw_read_lock
                  |
                  --- _read_lock
                     |
                     |--60.53%-- send_sigio
                     |          __kill_fasync
                     |          kill_fasync
                     |          evdev_pass_event
                     |          evdev_event
                     |          input_pass_event
                     |          input_handle_event
                     |          input_event
                     |          synaptics_process_byte
                     |          psmouse_handle_byte
                     |          psmouse_interrupt
                     |          serio_interrupt
                     |          i8042_interrupt
                     |          handle_IRQ_event
                     |          handle_edge_irq
                     |          handle_irq
                     |          __irqentry_text_start
                     |          ret_from_intr
                     |          |
                     |          |--30.43%-- __select
                     |          |
                     |          |--17.39%-- 0x454f15
                     |          |
                     |          |--13.04%-- __read
                     |          |
                     |          |--13.04%-- vread_hpet
                     |          |
                     |          |--13.04%-- _xcb_lock_io
                     |          |
                     |           --13.04%-- 0x7f630878ce87
      
      Note: it does not only affect perf events but also other stacktraces in
      x86-64. They were considered as unreliable once we quit the debug
      stack frame.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: "K. Prasad" <prasad@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      b625b3b3
    • Frederic Weisbecker's avatar
      x86/perf: Exclude the debug stack from the callchains · 7f33f9c5
      Frederic Weisbecker authored
      
      
      Dumping the callchains from breakpoint events with perf gives strange
      results:
      
      3.75%             perf  [kernel]           [k] _raw_read_unlock
                             |
                             --- _raw_read_unlock
                                 perf_callchain
                                 perf_prepare_sample
                                 __perf_event_overflow
                                 perf_swevent_overflow
                                 perf_swevent_add
                                 perf_bp_event
                                 hw_breakpoint_exceptions_notify
                                 notifier_call_chain
                                 __atomic_notifier_call_chain
                                 atomic_notifier_call_chain
                                 notify_die
                                 do_debug
                                 debug
                                 munmap
      
      We are infected with all the debug stack. Like the nmi stack, the debug
      stack is undesired as it is part of the profiling path, not helpful for
      the user.
      
      Ignore it.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: "K. Prasad" <prasad@linux.vnet.ibm.com>
      7f33f9c5
    • Frederic Weisbecker's avatar
      hw-breakpoints: Use overflow handler instead of the event callback · b326e956
      Frederic Weisbecker authored
      
      
      struct perf_event::event callback was called when a breakpoint
      triggers. But this is a rather opaque callback, pretty
      tied-only to the breakpoint API and not really integrated into perf
      as it triggers even when we don't overflow.
      
      We prefer to use overflow_handler() as it fits into the perf events
      rules, being called only when we overflow.
      Reported-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: "K. Prasad" <prasad@linux.vnet.ibm.com>
      b326e956
    • Frederic Weisbecker's avatar
      hw-breakpoints: Drop callback and task parameters from modify helper · 2f0993e0
      Frederic Weisbecker authored
      
      
      Drop the callback and task parameters from modify_user_hw_breakpoint().
      For now we have no user that need to modify a breakpoint to the point
      of changing its handler or its task context.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: "K. Prasad" <prasad@linux.vnet.ibm.com>
      2f0993e0
  7. 05 Dec, 2009 2 commits
    • Leann Ogasawara's avatar
      x86: ASUS P4S800 reboot=bios quirk · 4832ddda
      Leann Ogasawara authored
      Bug reporter noted their system with an ASUS P4S800 motherboard would
      hang when rebooting unless reboot=b was specified.  Their dmidecode
      didn't contain descriptive System Information for Manufacturer or
      Product Name, so I used their Base Board Information to create a
      reboot quirk patch.  The bug reporter confirmed this patch resolves
      the reboot hang.
      
      Handle 0x0001, DMI type 1, 25 bytes
      System Information
             Manufacturer: System Manufacturer
             Product Name: System Name
             Version: System Version
             Serial Number: SYS-1234567890
             UUID: E0BFCD8B-7948-D911-A953-E486B4EEB67F
             Wake-up Type: Power Switch
      
      Handle 0x0002, DMI type 2, 8 bytes
      Base Board Information
           Manufacturer: ASUSTeK Computer INC.
           Product Name: P4S800
           Version: REV 1.xx
           Serial Number: xxxxxxxxxxx
      
      BugLink: http://bugs.launchpad.net/bugs/366682
      
      
      
      ASUS P4S800 will hang when rebooting unless reboot=b is specified.
      Add a quirk to reboot through the bios.
      Signed-off-by: default avatarLeann Ogasawara <leann.ogasawara@canonical.com>
      LKML-Reference: <1259972107.4629.275.camel@emiko>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: <stable@kernel.org>
      4832ddda
    • Chris Wright's avatar
      PCI: add pci_request_acs · 5d990b62
      Chris Wright authored
      Commit ae21ee65
      
       "PCI: acs p2p upsteram
      forwarding enabling" doesn't actually enable ACS.
      
      Add a function to pci core to allow an IOMMU to request that ACS
      be enabled.  The existing mechanism of using iommu_found() in the pci
      core to know when ACS should be enabled doesn't actually work due to
      initialization order;  iommu has only been detected not initialized.
      
      Have Intel and AMD IOMMUs request ACS, and Xen does as well during early
      init of dom0.
      
      Cc: Allen Kay <allen.m.kay@intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      5d990b62
  8. 04 Dec, 2009 1 commit
  9. 03 Dec, 2009 4 commits
    • Mikael Pettersson's avatar
      x86, apic: Enable lapic nmi watchdog on AMD Family 11h · 7d1849af
      Mikael Pettersson authored
      
      
      The x86 lapic nmi watchdog does not recognize AMD Family 11h,
      resulting in:
      
        NMI watchdog: CPU not supported
      
      As far as I can see from available documentation (the BKDM),
      family 11h looks identical to family 10h as far as the PMU
      is concerned.
      
      Extending the check to accept family 11h results in:
      
        Testing NMI watchdog ... OK.
      
      I've been running with this change on a Turion X2 Ultra ZM-82
      laptop for a couple of weeks now without problems.
      Signed-off-by: default avatarMikael Pettersson <mikpe@it.uu.se>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <19223.53436.931768.278021@pilspetsen.it.uu.se>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7d1849af
    • Xiaotian Feng's avatar
      x86/reboot: Add pci_dev_put in reboot_fixup_32.c for consistency · 57fea8f7
      Xiaotian Feng authored
      
      
      pci_get_device will increase the ref count of found device.
      Although we're going to reset soon, we should use pci_dev_put
      to decrease the ref count for consistency.
      Signed-off-by: default avatarXiaotian Feng <dfeng@redhat.com>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      LKML-Reference: <1259838400-23833-1-git-send-email-dfeng@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      57fea8f7
    • Darrick J. Wong's avatar
      x86, Calgary IOMMU quirk: Find nearest matching Calgary while walking up the PCI tree · 4528752f
      Darrick J. Wong authored
      
      
      On a multi-node x3950M2 system, there's a slight oddity in the
      PCI device tree for all secondary nodes:
      
       30:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
        \-33:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
           \-34:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)
      
      ...as compared to the primary node:
      
       00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
        \-01:00.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
       03:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
        \-04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)
      
      In both nodes, the LSI RAID controller hangs off a CalIOC2
      device, but on the secondary nodes, the BIOS hides the VGA
      device and substitutes the device tree ending with the disk
      controller.
      
      It would seem that Calgary devices don't necessarily appear at
      the top of the PCI tree, which means that the current code to
      find the Calgary IOMMU that goes with a particular device is
      buggy.
      
      Rather than walk all the way to the top of the PCI
      device tree and try to match bus number with Calgary descriptor,
      the code needs to examine each parent of the particular device;
      if it encounters a Calgary with a matching bus number, simply
      use that.
      
      Otherwise, we BUG() when the bus number of the Calgary doesn't
      match the bus number of whatever's at the top of the device tree.
      
      Extra note: This patch appears to work correctly for the x3950
      that came before the x3950 M2.
      Signed-off-by: default avatarDarrick J. Wong <djwong@us.ibm.com>
      Acked-by: default avatarMuli Ben-Yehuda <muli@il.ibm.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: Jon D. Mason <jdmason@kudzu.us>
      Cc: Corinna Schultz <coschult@us.ibm.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <20091202230556.GG10295@tux1.beaverton.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4528752f
    • Hidetoshi Seto's avatar
      x86, mce: don't restart timer if disabled · fe5ed91d
      Hidetoshi Seto authored
      
      
      Even it is in error path unlikely taken, add_timer_on() at
      CPU_DOWN_FAILED* needs to be skipped if mce_timer is disabled.
      Signed-off-by: default avatarHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Jan Beulich <jbeulich@novell.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      fe5ed91d
  10. 02 Dec, 2009 6 commits
  11. 01 Dec, 2009 1 commit
    • H. Peter Anvin's avatar
      x86, mm: Correct the implementation of is_untracked_pat_range() · ccef0864
      H. Peter Anvin authored
      The semantics the PAT code expect of is_untracked_pat_range() is "is
      this range completely contained inside the untracked region."  This
      means that checkin 8a271389
      
       was
      technically wrong, because the implementation needlessly confusing.
      
      The sane interface is for it to take a semiclosed range like just
      about everything else (as evidenced by the sheer number of "- 1"'s
      removed by that patch) so change the actual implementation to match.
      Reported-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jack Steiner <steiner@sgi.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <20091119202341.GA4420@sgi.com>
      ccef0864
  12. 30 Nov, 2009 1 commit
  13. 27 Nov, 2009 3 commits