1. 25 Mar, 2008 6 commits
    • Jeff Garzik's avatar
      [libata] ahci: SB600 workaround is suspect... play it safe for now · 4cde32fc
      Jeff Garzik authored
      At least one report claims that a878539e
      failed to solve lockups, whereas the old limit-to-32-bit trick worked.
      
      Restore the 32-bit limit, but also leave the 255-sector limit in place,
      because we know that's needed as well.
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      4cde32fc
    • Mikael Pettersson's avatar
      sata_promise: fix hardreset hotplug events, take 2 · c07a9c49
      Mikael Pettersson authored
      A Promise SATA controller will signal hotplug events when a hard
      reset (COMRESET) is done on a port. These events aren't masked by
      the driver, and the unexpected interrupts will cause a sequence
      of failed reset attempts util libata's EH finally gives up.
      
      This has not been a common problem so far, but the pending libata
      hardreset-by-default changes makes it a critical issue.
      
      The solution is to disable hotplug events before a reset, and to
      reenable them afterwards. (Promise's driver does this too.)
      
      This patch adds SATA-specific versions of ->freeze() and ->thaw()
      that also disable and enable hotplug events. PATA ports continue
      to use the old versions of ->freeze() and ->thaw().
      
      Accesses to the hotplug register must be serialised via host->lock.
      We rely on ap->lock == &ap->host->lock and that libata takes this
      lock before ->freeze() and ->thaw(). Document this requirement.
      The interrupt handler is adjusted so its hotplug register accesses
      are inside the region protected by host->lock.
      
      Tested on various chips (SATA300TX4, SATA300TX2plus, SATAII150TX4,
      FastTrack TX4000) with various combinations of SATA and PATA disks,
      with and without the pending hardreset-by-default changes.
      Signed-off-by: default avatarMikael Pettersson <mikpe@it.uu.se>
      Acked-by: default avatarTejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      c07a9c49
    • Tejun Heo's avatar
      libata: improve HPA error handling · dda7aba1
      Tejun Heo authored
      There's no point in retrying and eventually failing device detection
      when the device rejects READ_NATIVE_MAX[_EXT].  Disable HPA unlocking
      if READ_NATIVE_MAX[_EXT] is rejected as done when SET_MAX[_EXT] is
      rejected.
      
      This allows some old drives to work even if they aren't blacklisted.
      Signed-off-by: default avatarTejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      dda7aba1
    • Tejun Heo's avatar
      libata: assume no device is attached if both IDENTIFYs are aborted · 1ffc151f
      Tejun Heo authored
      This is to fix bugzilla #10254.  QSI cdrom attached to pata_sis as
      secondary master appears as phantom device for the slave.
      Interestingly, instead of not setting DRQ after IDENTIFY which
      triggers NODEV_HINT, it aborts both IDENTIFY and IDENTIFY PACKET which
      makes EH retry.
      
      Modify EH such that it assumes no device is attached if both flavors
      of IDENTIFY are aborted by the device.  There really isn't much point
      in retrying when the device actively aborts the commands.
      
      While at it, convert NODEV detection message to ata_dev_printk() to
      help debugging obscure detection problems.
      
      This problem was reported by Jan Bücken.
      Signed-off-by: default avatarTejun Heo <htejun@gmail.com>
      Cc: Jan Bücken <jb.faq@gmx.de>
      Acked-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      1ffc151f
    • Tejun Heo's avatar
      pata_it821x: use raw nbytes in check_atapi_dma · b63b1331
      Tejun Heo authored
      pata_it821x needs to look at raw request size in check_atapi_dma().
      Signed-off-by: default avatarTejun Heo <htejun@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      b63b1331
    • Tejun Heo's avatar
      libata: implement ata_qc_raw_nbytes() · aacda375
      Tejun Heo authored
      Implement ata_qc_raw_nbytes() which determines the raw user-requested
      size of a PC command.
      Signed-off-by: default avatarTejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      aacda375
  2. 24 Mar, 2008 16 commits
  3. 23 Mar, 2008 13 commits
  4. 22 Mar, 2008 5 commits
    • Steve French's avatar
      [CIFS] Fix mem leak on dfs referral · 04b6e6ec
      Steve French authored
      Signed-off-by: default avatarIgor Mammedov <niallain@gmail.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      04b6e6ec
    • Herbert Xu's avatar
      [TCP]: Let skbs grow over a page on fast peers · 69d15067
      Herbert Xu authored
      While testing the virtio-net driver on KVM with TSO I noticed
      that TSO performance with a 1500 MTU is significantly worse
      compared to the performance of non-TSO with a 16436 MTU.  The
      packet dump shows that most of the packets sent are smaller
      than a page.
      
      Looking at the code this actually is quite obvious as it always
      stop extending the packet if it's the first packet yet to be
      sent and if it's larger than the MSS.  Since each extension is
      bound by the page size, this means that (given a 1500 MTU) we're
      very unlikely to construct packets greater than a page, provided
      that the receiver and the path is fast enough so that packets can
      always be sent immediately.
      
      The fix is also quite obvious.  The push calls inside the loop
      is just an optimisation so that we don't end up doing all the
      sending at the end of the loop.  Therefore there is no specific
      reason why it has to do so at MSS boundaries.  For TSO, the
      most natural extension of this optimisation is to do the pushing
      once the skb exceeds the TSO size goal.
      
      This is what the patch does and testing with KVM shows that the
      TSO performance with a 1500 MTU easily surpasses that of a 16436
      MTU and indeed the packet sizes sent are generally larger than
      16436.
      
      I don't see any obvious downsides for slower peers or connections,
      but it would be prudent to test this extensively to ensure that
      those cases don't regress.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      69d15067
    • Thomas Gleixner's avatar
      x86: revert: reserve dma32 early for gart · 9e963048
      Thomas Gleixner authored
      Revert
      
      commit f62f1fc9
      Author: Yinghai Lu <yhlu.kernel@gmail.com>
      Date:   Fri Mar 7 15:02:50 2008 -0800
      
          x86: reserve dma32 early for gart
      
      The patch has a dependency on bootmem modifications which are not .25
      material that late in the -rc cycle. The problem which is addressed by
      the patch is limited to machines with 256G and more memory booted with
      NUMA disabled. This is not a .25 regression and the audience which is
      affected by this problem is very limited, so it's safer to do the
      revert than pulling in intrusive bootmem changes right now.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      9e963048
    • Bartlomiej Zolnierkiewicz's avatar
      Revert "ide-tape: schedule driver for removal after 6 months" · ca4e2ab5
      Bartlomiej Zolnierkiewicz authored
      This reverts commit d48567dd.
      
      Borislav is working on ide-tape "light" version instead.
      
      Cc: Borislav Petkov <petkovbb@gmail.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      ca4e2ab5
    • Bartlomiej Zolnierkiewicz's avatar
      ide: mark "hdx=remap" and "hdx=remap63" kernel parameters as obsoleted · d708c40d
      Bartlomiej Zolnierkiewicz authored
      Mark "hdx=remap" and "hdx=remap63" kernel parameters as obsoleted
      (they are layering violation and should be dealt with in the same
       way as done by libata - device-mapper should be used instead).
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      d708c40d