1. 07 12月, 2011 1 次提交
    • A
      oprofile, s390: Add event interface to the System z hardware sampling module · dd3c4670
      Andreas Krebbel 提交于
      With this patch the OProfile Basic Mode Sampling support for System z
      is enhanced with a counter file system.  That way hardware sampling
      can be configured using the user space tools with only little
      modifications.
      
      With the patch by default new cpu_types (s390/z10, s390/z196) are
      returned in order to indicate that we are running a CPU which provides
      the hardware sampling facility.  Existing user space tools will
      complain about an unknown cpu type. In order to be compatible with
      existing user space tools the `cpu_type' module parameter has been
      added.  Setting the parameter to `timer' will force the module to
      return `timer' as cpu_type.  The module will still try to use hardware
      sampling if available and the hwsampling virtual filesystem will be
      also be available for configuration.  So this has a different effect
      than using the generic oprofile module parameter `timer=1'.
      
      If the basic mode sampling is enabled on the machine and the
      cpu_type=timer parameter is not used the kernel module will provide
      the following virtual filesystem:
      
      /dev/oprofile/0/enabled
      /dev/oprofile/0/event
      /dev/oprofile/0/count
      /dev/oprofile/0/unit_mask
      /dev/oprofile/0/kernel
      /dev/oprofile/0/user
      
      In the counter file system only the values of 'enabled', 'count',
      'kernel', and 'user' are evaluated by the kernel module. Everything
      else must contain fixed values.
      
      The 'event' value only supports a single event - HWSAMPLING with value
      0.
      
      The 'count' value specifies the hardware sampling rate as it is passed
      to the CPU measurement facility.
      
      The 'kernel' and 'user' flags can now be used to filter for samples
      when using hardware sampling.
      
      Additionally also the following file will be created:
      /dev/oprofile/timer/enabled
      
      This will always be the inverted value of /dev/oprofile/0/enabled. 0
      is not accepted without hardware sampling.
      Signed-off-by: NAndreas Krebbel <krebbel@linux.vnet.ibm.com>
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      dd3c4670
  2. 04 11月, 2011 1 次提交
  3. 14 8月, 2011 2 次提交
  4. 12 8月, 2011 1 次提交
  5. 11 8月, 2011 1 次提交
  6. 04 8月, 2011 2 次提交
  7. 03 8月, 2011 1 次提交
  8. 01 8月, 2011 1 次提交
  9. 27 7月, 2011 1 次提交
    • H
      panic: panic=-1 for immediate reboot · 4302fbc8
      Hugh Dickins 提交于
      When a kernel BUG or oops occurs, ChromeOS intends to panic and
      immediately reboot, with stacktrace and other messages preserved in RAM
      across reboot.
      
      But the longer we delay, the more likely the user is to poweroff and
      lose the info.
      
      panic_timeout (seconds before rebooting) is set by panic= boot option or
      sysctl or /proc/sys/kernel/panic; but 0 means wait forever, so at
      present we have to delay at least 1 second.
      
      Let a negative number mean reboot immediately (with the small cosmetic
      benefit of suppressing that newline-less "Rebooting in %d seconds.."
      message).
      Signed-off-by: NHugh Dickins <hughd@chromium.org>
      Signed-off-by: NMandeep Singh Baines <msb@chromium.org>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Olaf Hering <olaf@aepfle.de>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4302fbc8
  10. 24 7月, 2011 2 次提交
  11. 23 7月, 2011 1 次提交
  12. 17 7月, 2011 1 次提交
  13. 09 7月, 2011 1 次提交
  14. 20 6月, 2011 1 次提交
  15. 08 6月, 2011 1 次提交
    • A
      usb-storage: redo incorrect reads · 21c13a4f
      Alan Stern 提交于
      Some USB mass-storage devices have bugs that cause them not to handle
      the first READ(10) command they receive correctly.  The Corsair
      Padlock v2 returns completely bogus data for its first read (possibly
      it returns the data in encrypted form even though the device is
      supposed to be unlocked).  The Feiya SD/SDHC card reader fails to
      complete the first READ(10) command after it is plugged in or after a
      new card is inserted, returning a status code that indicates it thinks
      the command was invalid, which prevents the kernel from retrying the
      read.
      
      Since the first read of a new device or a new medium is for the
      partition sector, the kernel is unable to retrieve the device's
      partition table.  Users have to manually issue an "hdparm -z" or
      "blockdev --rereadpt" command before they can access the device.
      
      This patch (as1470) works around the problem.  It adds a new quirk
      flag, US_FL_INVALID_READ10, indicating that the first READ(10) should
      always be retried immediately, as should any failing READ(10) commands
      (provided the preceding READ(10) command succeeded, to avoid getting
      stuck in a loop).  The patch also adds appropriate unusual_devs
      entries containing the new flag.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NSven Geggus <sven-usbst@geggus.net>
      Tested-by: NPaul Hartman <paul.hartman+linux@gmail.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      21c13a4f
  16. 07 6月, 2011 1 次提交
  17. 01 6月, 2011 1 次提交
    • Y
      intel-iommu: Enable super page (2MiB, 1GiB, etc.) support · 6dd9a7c7
      Youquan Song 提交于
      There are no externally-visible changes with this. In the loop in the
      internal __domain_mapping() function, we simply detect if we are mapping:
        - size >= 2MiB, and
        - virtual address aligned to 2MiB, and
        - physical address aligned to 2MiB, and
        - on hardware that supports superpages.
      
      (and likewise for larger superpages).
      
      We automatically use a superpage for such mappings. We never have to
      worry about *breaking* superpages, since we trust that we will always
      *unmap* the same range that was mapped. So all we need to do is ensure
      that dma_pte_clear_range() will also cope with superpages.
      
      Adjust pfn_to_dma_pte() to take a superpage 'level' as an argument, so
      it can return a PTE at the appropriate level rather than always
      extending the page tables all the way down to level 1. Again, this is
      simplified by the fact that we should never encounter existing small
      pages when we're creating a mapping; any old mapping that used the same
      virtual range will have been entirely removed and its obsolete page
      tables freed.
      
      Provide an 'intel_iommu=sp_off' argument on the command line as a
      chicken bit. Not that it should ever be required.
      
      ==
      
      The original commit seen in the iommu-2.6.git was Youquan's
      implementation (and completion) of my own half-baked code which I'd
      typed into an email. Followed by half a dozen subsequent 'fixes'.
      
      I've taken the unusual step of rewriting history and collapsing the
      original commits in order to keep the main history simpler, and make
      life easier for the people who are going to have to backport this to
      older kernels. And also so I can give it a more coherent commit comment
      which (hopefully) gives a better explanation of what's going on.
      
      The original sequence of commits leading to identical code was:
      
      Youquan Song (3):
            intel-iommu: super page support
            intel-iommu: Fix superpage alignment calculation error
            intel-iommu: Fix superpage level calculation error in dma_pfn_level_pte()
      
      David Woodhouse (4):
            intel-iommu: Precalculate superpage support for dmar_domain
            intel-iommu: Fix hardware_largepage_caps()
            intel-iommu: Fix inappropriate use of superpages in __domain_mapping()
            intel-iommu: Fix phys_pfn in __domain_mapping for sglist pages
      Signed-off-by: NYouquan Song <youquan.song@intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      6dd9a7c7
  18. 25 5月, 2011 1 次提交
  19. 20 5月, 2011 1 次提交
  20. 18 5月, 2011 2 次提交
  21. 05 4月, 2011 2 次提交
  22. 31 3月, 2011 1 次提交
  23. 23 3月, 2011 3 次提交
  24. 12 3月, 2011 1 次提交
  25. 04 3月, 2011 1 次提交
  26. 26 2月, 2011 1 次提交
    • T
      genirq: Provide forced interrupt threading · 8d32a307
      Thomas Gleixner 提交于
      Add a commandline parameter "threadirqs" which forces all interrupts except
      those marked IRQF_NO_THREAD to run threaded. That's mostly a debug option to
      allow retrieving better debug data from crashing interrupt handlers. If
      "threadirqs" is not enabled on the kernel command line, then there is no
      impact in the interrupt hotpath.
      
      Architecture code needs to select CONFIG_IRQ_FORCED_THREADING after
      marking the interrupts which cant be threaded IRQF_NO_THREAD. All
      interrupts which have IRQF_TIMER set are implict marked
      IRQF_NO_THREAD. Also all PER_CPU interrupts are excluded.
      
      Forced threading hard interrupts also forces all soft interrupt
      handling into thread context.
      
      When enabled it might slow down things a bit, but for debugging problems in
      interrupt code it's a reasonable penalty as it does not immediately
      crash and burn the machine when an interrupt handler is buggy.
      
      Some test results on a Core2Duo machine:
      
      Cache cold run of:
       # time git grep irq_desc
      
            non-threaded       threaded
       real 1m18.741s          1m19.061s
       user 0m1.874s           0m1.757s
       sys  0m5.843s           0m5.427s
      
       # iperf -c server
      non-threaded
      [  3]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   934 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
      threaded
      [  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   934 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   937 Mbits/sec
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20110223234956.772668648@linutronix.de>
      8d32a307
  27. 22 2月, 2011 3 次提交
  28. 26 1月, 2011 1 次提交
  29. 12 1月, 2011 1 次提交
  30. 08 1月, 2011 1 次提交
  31. 03 1月, 2011 1 次提交