1. 05 2月, 2013 5 次提交
  2. 02 2月, 2013 3 次提交
  3. 01 2月, 2013 8 次提交
  4. 31 1月, 2013 11 次提交
    • A
      dm: fix write same requests counting · fe7af2d3
      Alasdair G Kergon 提交于
      When processing write same requests, fix dm to send the configured
      number of WRITE SAME requests to the target rather than the number of
      discards, which is not always the same.
      
      Device-mapper WRITE SAME support was introduced by commit
      23508a96 ("dm: add WRITE SAME support").
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      Acked-by: NMike Snitzer <snitzer@redhat.com>
      fe7af2d3
    • M
      dm thin: fix queue limits stacking · 0f640dca
      Mike Snitzer 提交于
      thin_io_hints() is blindly copying the queue limits from the thin-pool
      which can lead to incorrect limits being set.  The fix here simply
      deletes the thin_io_hints() hook which leaves the existing stacking
      infrastructure to set the limits correctly.
      
      When a thin-pool uses an MD device for the data device a thin device
      from the thin-pool must respect MD's constraints about disallowing a bio
      from spanning multiple chunks.  Otherwise we can see problems.  If the raid0
      chunksize is 1152K and thin-pool chunksize is 256K I see the following
      md/raid0 error (with extra debug tracing added to thin_endio) when
      mkfs.xfs is executed against the thin device:
      
      md/raid0:md99: make_request bug: can't convert block across chunks or bigger than 1152k 6688 127
      device-mapper: thin: bio sector=2080 err=-5 bi_size=130560 bi_rw=17 bi_vcnt=32 bi_idx=0
      
      This extra DM debugging shows that the failing bio is spanning across
      the first and second logical 1152K chunk (sector 2080 + 255 takes the
      bio beyond the first chunk's boundary of sector 2304).  So the bio
      splitting that DM is doing clearly isn't respecting the MD limits.
      
      max_hw_sectors_kb is 127 for both the thin-pool and thin device
      (queue_max_hw_sectors returns 255 so we'll excuse sysfs's lack of
      precision).  So this explains why bi_size is 130560.
      
      But the thin device's max_hw_sectors_kb should be 4 (PAGE_SIZE) given
      that it doesn't have a .merge function (for bio_add_page to consult
      indirectly via dm_merge_bvec) yet the thin-pool does sit above an MD
      device that has a compulsory merge_bvec_fn.  This scenario is exactly
      why DM must resort to sending single PAGE_SIZE bios to the underlying
      layer. Some additional context for this is available in the header for
      commit 8cbeb67a ("dm: avoid unsupported spanning of md stripe boundaries").
      
      Long story short, the reason a thin device doesn't properly get
      configured to have a max_hw_sectors_kb of 4 (PAGE_SIZE) is that
      thin_io_hints() is blindly copying the queue limits from the thin-pool
      device directly to the thin device's queue limits.
      
      Fix this by eliminating thin_io_hints.  Doing so is safe because the
      block layer's queue limits stacking already enables the upper level thin
      device to inherit the thin-pool device's discard and minimum_io_size and
      optimal_io_size limits that get set in pool_io_hints.  But avoiding the
      queue limits copy allows the thin and thin-pool limits to be different
      where it is important, namely max_hw_sectors_kb.
      Reported-by: NDaniel Browning <db@kavod.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      0f640dca
    • A
      drm/radeon/evergreen+: wait for the MC to settle after MC blackout · ed39fadd
      Alex Deucher 提交于
      Some chips seem to need a little delay after blacking out
      the MC before the requests actually stop.
      
      May fix:
      https://bugs.freedesktop.org/show_bug.cgi?id=56139
      https://bugs.freedesktop.org/show_bug.cgi?id=57567Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      ed39fadd
    • L
      USB: add OWL CM-160 support to cp210x driver · 8de7f4da
      Luis Llorente Campo 提交于
      This adds support for the OWL CM-160 electricity monitor to the cp210x
      driver.
      Signed-off-by: NLuis Llorente <luisllorente@luisllorente.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8de7f4da
    • A
      USB: EHCI: fix bug in scheduling periodic split transfers · 3e619d04
      Alan Stern 提交于
      This patch (as1654) fixes a very old bug in ehci-hcd, connected with
      scheduling of periodic split transfers.  The calculations for
      full/low-speed bus usage are all carried out after the correction for
      bit-stuffing has been applied, but the values in the max_tt_usecs
      array assume it hasn't been.  The array should allow for allocation of
      up to 90% of the bus capacity, which is 900 us, not 780 us.
      
      The symptom caused by this bug is that any isochronous transfer to a
      full-speed device with a maxpacket size larger than about 980 bytes is
      always rejected with a -ENOSPC error.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e619d04
    • A
      USB: EHCI: fix for leaking isochronous data · b09a61cc
      Alan Stern 提交于
      This patch (as1653) fixes a bug in ehci-hcd.  Unlike iTD entries, an
      siTD entry in the periodic schedule may not complete until the frame
      after the one it belongs to.  Consequently, when scanning the periodic
      schedule it is necessary to start with the frame _preceding_ the one
      where the previous scan ended.
      
      Not doing this properly can result in memory leaks and failures to
      complete isochronous URBs.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NAndy Leiserson <andy@leiserson.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b09a61cc
    • A
      regulator: s2mps11: fix incorrect register for buck10 · c76edd52
      Alim Akhtar 提交于
      For BUCK10 the control registers are wrongly set as buck9 control register
      This patch corrects the control registers for buck10
      Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: stable@vger.kernel.org
      c76edd52
    • M
      samsung-laptop: Disable on EFI hardware · e0094244
      Matt Fleming 提交于
      It has been reported that running this driver on some Samsung laptops
      with EFI can cause those machines to become bricked as detailed in the
      following report,
      
      	https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      There have also been reports of this driver causing Machine Check
      Exceptions on recent EFI-enabled Samsung laptops,
      
      	https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      So disable it if booting from EFI since this driver relies on
      grovelling around in the BIOS memory map which isn't going to work.
      
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      e0094244
    • M
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming 提交于
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      83e68189
    • M
      drm/radeon: protect against div by 0 in backend setup · f689e3ac
      Mikko Tiihonen 提交于
      Make sure at least one RB is enabled in
      r6xx_remap_render_backend() to avoid an division by
      zero in some corner cases.
      
      See:
      https://bugzilla.redhat.com/show_bug.cgi?id=892233Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      f689e3ac
    • A
      drm/radeon: fix backend map setup on 1 RB sumo boards · f7eb9730
      Alex Deucher 提交于
      Need to adjust the backend map depending on which
      RB is enabled.
      
      Fixes:
      https://bugzilla.redhat.com/show_bug.cgi?id=892233Reported-by: NMikko Tiihonen <mikko.tiihonen@iki.fi>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      f7eb9730
  5. 30 1月, 2013 11 次提交
  6. 28 1月, 2013 2 次提交
    • S
      IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround · 318fe782
      Suravee Suthikulpanit 提交于
      The IOMMU may stop processing page translations due to a perceived lack
      of credits for writing upstream peripheral page service request (PPR)
      or event logs. If the L2B miscellaneous clock gating feature is enabled
      the IOMMU does not properly register credits after the log request has
      completed, leading to a potential system hang.
      
      BIOSes are supposed to disable L2B micellaneous clock gating by setting
      L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This
      patch corrects that for those which do not enable this workaround.
      Signed-off-by: NSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      318fe782
    • P
      dm9601: support dm9620 variant · 6642f91c
      Peter Korsgaard 提交于
      dm9620 is a newer variant of dm9601 with more features (usb 2.0, checksum
      offload, ..), but it can also be put in a dm9601 compatible mode, allowing
      us to reuse the existing driver.
      
      This does mean that the extended features like checksum offload cannot be
      used, but that's hardly critical on a 100mbps interface.
      
      Thanks to Sławek Wernikowski <slawek@wernikowski.net> for providing me
      with a dm9620 based device to test.
      Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6642f91c