1. 01 11月, 2014 4 次提交
  2. 29 10月, 2014 4 次提交
  3. 25 10月, 2014 4 次提交
  4. 17 10月, 2014 4 次提交
  5. 16 10月, 2014 1 次提交
  6. 12 10月, 2014 3 次提交
  7. 10 10月, 2014 4 次提交
  8. 09 10月, 2014 1 次提交
  9. 08 10月, 2014 3 次提交
  10. 03 10月, 2014 3 次提交
  11. 02 10月, 2014 9 次提交
    • N
      md/raid5: disable 'DISCARD' by default due to safety concerns. · 8e0e99ba
      NeilBrown 提交于
      It has come to my attention (thanks Martin) that 'discard_zeroes_data'
      is only a hint.  Some devices in some cases don't do what it
      says on the label.
      
      The use of DISCARD in RAID5 depends on reads from discarded regions
      being predictably zero.  If a write to a previously discarded region
      performs a read-modify-write cycle it assumes that the parity block
      was consistent with the data blocks.  If all were zero, this would
      be the case.  If some are and some aren't this would not be the case.
      This could lead to data corruption after a device failure when
      data needs to be reconstructed from the parity.
      
      As we cannot trust 'discard_zeroes_data', ignore it by default
      and so disallow DISCARD on all raid4/5/6 arrays.
      
      As many devices are trustworthy, and as there are benefits to using
      DISCARD, add a module parameter to over-ride this caution and cause
      DISCARD to work if discard_zeroes_data is set.
      
      If a site want to enable DISCARD on some arrays but not on others they
      should select DISCARD support at the filesystem level, and set the
      raid456 module parameter.
          raid456.devices_handle_discard_safely=Y
      
      As this is a data-safety issue, I believe this patch is suitable for
      -stable.
      DISCARD support for RAID456 was added in 3.7
      
      Cc: Shaohua Li <shli@kernel.org>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: Heinz Mauelshagen <heinzm@redhat.com>
      Cc: stable@vger.kernel.org (3.7+)
      Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: NMike Snitzer <snitzer@redhat.com>
      Fixes: 620125f2Signed-off-by: NNeilBrown <neilb@suse.de>
      8e0e99ba
    • B
      drm/nouveau: make sure display hardware is reinitialised on runtime resume · 6fbb702e
      Ben Skeggs 提交于
      Linus commit 05c63c2f modified the
      runtime suspend/resume paths to skip over display-related tasks to
      avoid locking issues on resume.
      
      Unfortunately, this resulted in the display hardware being left in
      a partially initialised state, preventing subsequent modesets from
      completing.
      
      This commit unifies the (many) suspend/resume paths, bringing back
      display (and fbcon) handling in the runtime paths.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      6fbb702e
    • B
      drm/nouveau: punt fbcon resume out to a workqueue · 634ffccc
      Ben Skeggs 提交于
      Preparation for some runtime pm fixes.  Currently we skip over fbcon
      suspend/resume in the runtime path, which causes issues on resume if
      fbcon tries to write to the framebuffer before the BAR subdev has
      been resumed to restore the BAR1 VM setup.
      
      As we might be woken up via a sysfs connector, we are unable to call
      fb_set_suspend() in the resume path as it could make its way down to
      a modeset and cause all sorts of locking hilarity.
      
      To solve this, we'll just delay the fbcon resume to a workqueue.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      634ffccc
    • B
      drm/nouveau: fix regression on original nv50 board · f2f9a2cb
      Ben Skeggs 提交于
      Xorg (and any non-DRM client really) doesn't have permission to directly
      touch VRAM on nv50 and up, which the fence code prior to g84 depends on.
      
      It's less invasive to temporarily grant it premission to do so, as it
      previously did, than it is to rework fencenv50 to use the VM.  That
      will come later on.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      f2f9a2cb
    • B
      drm/nv50/disp: fix dpms regression on certain boards · 5838ae61
      Ben Skeggs 提交于
      Reported in fdo#82527 comment #2.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      5838ae61
    • H
      r8152: disable power cut for RTL8153 · 49be1723
      hayeswang 提交于
      The firmware would be clear when the power cut is enabled for
      RTL8153.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49be1723
    • H
      r8152: remove clearing bp · 204c8704
      hayeswang 提交于
      The xxx_clear_bp() is used to halt the firmware. It only necessary
      for updating the new firmware. Besides, depend on the version of
      the current firmware, it may have problem to halt the firmware
      directly. Finally, halt the firmware would let the firmware code
      useless, and the bugs which are fixed by the firmware would occur.
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      204c8704
    • V
      bnx2: Correctly receive full sized 802.1ad fragmes · 1b0ecb28
      Vlad Yasevich 提交于
      This driver, similar to tg3, has a check that will
      cause full sized 802.1ad frames to be dropped.  The
      frame will be larger then the standard mtu due to the
      presense of vlan header that has not been stripped.
      The driver should not drop this frame and should process
      it just like it does for 802.1q.
      
      CC: Sony Chacko <sony.chacko@qlogic.com>
      CC: Dept-HSGLinuxNICDev@qlogic.com
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b0ecb28
    • V
      tg3: Allow for recieve of full-size 8021AD frames · 7d3083ee
      Vlad Yasevich 提交于
      When receiving a vlan-tagged frame that still contains
      a vlan header, the length of the packet will be greater
      then MTU+ETH_HLEN since it will account of the extra
      vlan header.  TG3 checks this for the case for 802.1Q,
      but not for 802.1ad.  As a result, full sized 802.1ad
      frames get dropped by the card.
      
      Add a check for 802.1ad protocol when receving full
      sized frames.
      Suggested-by: NPrashant Sreedharan <prashant@broadcom.com>
      CC: Prashant Sreedharan <prashant@broadcom.com>
      CC: Michael Chan <mchan@broadcom.com>
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d3083ee