1. 07 2月, 2013 3 次提交
    • D
      drm/usb: bind driver to correct device · 9f23de52
      Dave Airlie 提交于
      While looking at plymouth on udl I noticed that plymouth was trying
      to use its fb plugin not its drm one, it was trying to drmOpen a driver called
      usb not udl, noticed that we actually had out driver pointing at the wrong
      device.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9f23de52
    • D
      fbcon: don't lose the console font across generic->chip driver switch · ae128786
      Dave Airlie 提交于
      If grub2 loads efifb/vesafb, then when systemd starts it can set the console
      font on that framebuffer device, however when we then load the native KMS
      driver, the first thing it does is tear down the generic framebuffer driver.
      
      The thing is the generic code is doing the right thing, it frees the font
      because otherwise it would leak memory. However we can assume that if you
      are removing the generic firmware driver (vesa/efi/offb), that a new driver
      *should* be loading soon after, so we effectively leak the font.
      
      However the old code left a dangling pointer in vc->vc_font.data and we
      can now reuse that dangling pointer to load the font into the new
      driver, now that we aren't freeing it.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340
      
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      ae128786
    • D
      vgacon/vt: clear buffer attributes when we load a 512 character font (v2) · 2a248307
      Dave Airlie 提交于
      When we switch from 256->512 byte font rendering mode, it means the
      current contents of the screen is being reinterpreted. The bit that holds
      the high bit of the 9-bit font, may have been previously set, and thus
      the new font misrenders.
      
      The problem case we see is grub2 writes spaces with the bit set, so it
      ends up with data like 0x820, which gets reinterpreted into 0x120 char
      which the font translates into G with a circumflex. This flashes up on
      screen at boot and is quite ugly.
      
      A current side effect of this patch though is that any rendering on the
      screen changes color to a slightly darker color, but at least the screen
      no longer corrupts.
      
      v2: as suggested by hpa, always clear the attribute space, whether we
      are are going to or from 512 chars.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      2a248307
  2. 05 2月, 2013 5 次提交
  3. 02 2月, 2013 3 次提交
  4. 01 2月, 2013 8 次提交
  5. 31 1月, 2013 10 次提交
    • 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
    • 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
  6. 30 1月, 2013 10 次提交
  7. 28 1月, 2013 1 次提交
反馈
建议
客服 返回
顶部