1. 14 12月, 2009 5 次提交
  2. 13 12月, 2009 1 次提交
  3. 12 12月, 2009 3 次提交
    • M
      x86: Limit the number of processor bootup messages · 2eaad1fd
      Mike Travis 提交于
      When there are a large number of processors in a system, there
      is an excessive amount of messages sent to the system console.
      It's estimated that with 4096 processors in a system, and the
      console baudrate set to 56K, the startup messages will take
      about 84 minutes to clear the serial port.
      
      This set of patches limits the number of repetitious messages
      which contain no additional information.  Much of this information
      is obtainable from the /proc and /sysfs.   Some of the messages
      are also sent to the kernel log buffer as KERN_DEBUG messages so
      dmesg can be used to examine more closely any details specific to
      a problem.
      
      The new cpu bootup sequence for system_state == SYSTEM_BOOTING:
      
      Booting Node   0, Processors  #1 #2 #3 #4 #5 #6 #7 Ok.
      Booting Node   1, Processors  #8 #9 #10 #11 #12 #13 #14 #15 Ok.
      ...
      Booting Node   3, Processors  #56 #57 #58 #59 #60 #61 #62 #63 Ok.
      Brought up 64 CPUs
      
      After the system is running, a single line boot message is displayed
      when CPU's are hotplugged on:
      
          Booting Node %d Processor %d APIC 0x%x
      
      Status of the following lines:
      
          CPU: Physical Processor ID:		printed once (for boot cpu)
          CPU: Processor Core ID:		printed once (for boot cpu)
          CPU: Hyper-Threading is disabled	printed once (for boot cpu)
          CPU: Thermal monitoring enabled	printed once (for boot cpu)
          CPU %d/0x%x -> Node %d:		removed
          CPU %d is now offline:		only if system_state == RUNNING
          Initializing CPU#%d:		KERN_DEBUG
      Signed-off-by: NMike Travis <travis@sgi.com>
      LKML-Reference: <4B219E28.8080601@sgi.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      2eaad1fd
    • M
      x86: Remove enabling x2apic message for every CPU · 450b1e8d
      Mike Travis 提交于
      Print only once that the system is supporting x2apic mode.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <4B226E92.5080904@sgi.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      450b1e8d
    • B
      x86, msr: Add support for non-contiguous cpumasks · 50542251
      Borislav Petkov 提交于
      The current rd/wrmsr_on_cpus helpers assume that the supplied
      cpumasks are contiguous. However, there are machines out there
      like some K8 multinode Opterons which have a non-contiguous core
      enumeration on each node (e.g. cores 0,2 on node 0 instead of 0,1), see
      http://www.gossamer-threads.com/lists/linux/kernel/1160268.
      
      This patch fixes out-of-bounds writes (see URL above) by adding per-CPU
      msr structs which are used on the respective cores.
      
      Additionally, two helpers, msrs_{alloc,free}, are provided for use by
      the callers of the MSR accessors.
      
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Aristeu Rozanski <aris@redhat.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <20091211171440.GD31998@aftab>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      50542251
  4. 11 12月, 2009 8 次提交
  5. 10 12月, 2009 8 次提交
    • C
      vfs: Implement proper O_SYNC semantics · 6b2f3d1f
      Christoph Hellwig 提交于
      While Linux provided an O_SYNC flag basically since day 1, it took until
      Linux 2.4.0-test12pre2 to actually get it implemented for filesystems,
      since that day we had generic_osync_around with only minor changes and the
      great "For now, when the user asks for O_SYNC, we'll actually give
      O_DSYNC" comment.  This patch intends to actually give us real O_SYNC
      semantics in addition to the O_DSYNC semantics.  After Jan's O_SYNC
      patches which are required before this patch it's actually surprisingly
      simple, we just need to figure out when to set the datasync flag to
      vfs_fsync_range and when not.
      
      This patch renames the existing O_SYNC flag to O_DSYNC while keeping it's
      numerical value to keep binary compatibility, and adds a new real O_SYNC
      flag.  To guarantee backwards compatiblity it is defined as expanding to
      both the O_DSYNC and the new additional binary flag (__O_SYNC) to make
      sure we are backwards-compatible when compiled against the new headers.
      
      This also means that all places that don't care about the differences can
      just check O_DSYNC and get the right behaviour for O_SYNC, too - only
      places that actuall care need to check __O_SYNC in addition.  Drivers and
      network filesystems have been updated in a fail safe way to always do the
      full sync magic if O_DSYNC is set.  The few places setting O_SYNC for
      lower layers are kept that way for now to stay failsafe.
      
      We enforce that O_DSYNC is set when __O_SYNC is set early in the open path
      to make sure we always get these sane options.
      
      Note that parisc really screwed up their headers as they already define a
      O_DSYNC that has always been a no-op.  We try to repair it by using it for
      the new O_DSYNC and redefinining O_SYNC to send both the traditional
      O_SYNC numerical value _and_ the O_DSYNC one.
      
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andreas Dilger <adilger@sun.com>
      Acked-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Acked-by: NUlrich Drepper <drepper@redhat.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      6b2f3d1f
    • J
      x86/amd-iommu: Fix PCI hotplug with passthrough mode · 8638c491
      Joerg Roedel 提交于
      The device change notifier is initialized in the dma_ops
      initialization path. But this path is never executed for
      iommu=pt. Move the notifier initialization to IOMMU hardware
      init code to fix this.
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      8638c491
    • J
      x86/amd-iommu: Fix passthrough mode · b7cc9554
      Joerg Roedel 提交于
      The data structure changes to use dev->archdata.iommu field
      broke the iommu=pt mode because in this case the
      dev->archdata.iommu was left uninitialized. This moves the
      inititalization of the devices into the main init function
      and fixes the problem.
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      b7cc9554
    • J
      x86: mmio-mod.c: Use pr_fmt · 3a0340be
      Joe Perches 提交于
      - Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
       - Remove #define NAME
       - Remove NAME from pr_<level>
      Signed-off-by: NJoe Perches <joe@perches.com>
      LKML-Reference: <009cb214c45ef932df0242856228f4739cc91408.1260383912.git.joe@perches.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3a0340be
    • J
      x86: kmmio.c: Add and use pr_fmt(fmt) · 1bd591a5
      Joe Perches 提交于
      - Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
       - Strip "kmmio: " from pr_<level>s
      Signed-off-by: NJoe Perches <joe@perches.com>
      LKML-Reference: <7aa509f8a23933036d39f54bd51e9acc52068049.1260383912.git.joe@perches.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1bd591a5
    • J
      x86: i8254.c: Add pr_fmt(fmt) · a78d9626
      Joe Perches 提交于
      - Add pr_fmt(fmt) "pit: " fmt
       - Strip pit: prefixes from pr_debug
      Signed-off-by: NJoe Perches <joe@perches.com>
      LKML-Reference: <bbd4de532f18bb7c11f64ba20d224c08291cb126.1260383912.git.joe@perches.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a78d9626
    • J
      x86: setup_percpu.c: Use pr_<level> and add pr_fmt(fmt) · 40685236
      Joe Perches 提交于
      - Added #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
       - Stripped PERCPU: from a pr_warning
      Signed-off-by: NJoe Perches <joe@perches.com>
      LKML-Reference: <7ead24eccbea8f2b11795abad3e2893a98e1e111.1260383912.git.joe@perches.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      40685236
    • J
      x86: es7000_32.c: Use pr_<level> and add pr_fmt(fmt) · 5cd476ef
      Joe Perches 提交于
      - Added #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
       - Converted a few printk(KERN_INFO to pr_info(
       - Stripped "es7000_mipcfg" from pr_debug
      Signed-off-by: NJoe Perches <joe@perches.com>
      LKML-Reference: <3b4375af246dec5941168858910210937c110af9.1260383912.git.joe@perches.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5cd476ef
  6. 09 12月, 2009 5 次提交
  7. 08 12月, 2009 2 次提交
  8. 07 12月, 2009 2 次提交
  9. 06 12月, 2009 6 次提交
    • J
      x86, perf probe: Fix warning in test_get_len() · be2bf0a2
      Jean Delvare 提交于
      Fix the following warning:
      
       arch/x86/tools/test_get_len.c: In function "main":
       arch/x86/tools/test_get_len.c:116: warning: unused variable "c"
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      be2bf0a2
    • S
      x86: Fix typo in arch/x86/mm/kmmio.c · 8055039c
      Shaun Patterson 提交于
      Signed-off-by: NShaun Patterson <shaunpatterson@gmail.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: pq@iki.fi
      LKML-Reference: <1260027694.10074.170.camel@linux-4lgc.site>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8055039c
    • F
      x86: Fixup wrong irq frame link in stacktraces · af2d8289
      Frederic Weisbecker 提交于
      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: NFrederic 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
    • F
      x86: Fixup wrong debug exception frame link in stacktraces · b625b3b3
      Frederic Weisbecker 提交于
      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: NFrederic 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
    • F
      x86/perf: Exclude the debug stack from the callchains · 7f33f9c5
      Frederic Weisbecker 提交于
      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: NFrederic 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
    • F
      hw-breakpoints: Use overflow handler instead of the event callback · b326e956
      Frederic Weisbecker 提交于
      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: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NFrederic 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