Skip to content

L
linux
Switch branch/tag
  1. 03 Feb, 2009 14 commits
    • Tejun Heo's avatar
      libata: implement HORKAGE_1_5_GBPS and apply it to WD My Book · 9062712f
      Tejun Heo authored 
      3Gbps is often much more prone to transmission failures.  It's usually
okay to let EH handle speed down after transmission failures but some
WD My Book drives completely shutdown after certain transmission
failures and after it only power cycling can revive them.  Combined
with the fact that external drives often end up with cable assembly
which is longer than usual and more likely to have intervening gender,
this makes these drives very likely to shutdown under certain
configurations virtually rendering them unusable.

This patch implements HOARKGE_1_5_GBPS and applies it to WD My Book
such that 1.5Gbps is forced once the device is identified.

Please take a look at the following bz for related reports.

  http://bugzilla.kernel.org/show_bug.cgi?id=9913Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      9062712f
    • Tejun Heo's avatar
      libata: add no penalty retry request for EH device handling routines · cf9a590a
      Tejun Heo authored 
      Let -EAGAIN from EH device handling routines trigger EH retry without
consuming its tries count.  This will be used to implement link SPD
horkage which requires hardreset to adjust SPD without affecting other
EH decisions.  As it bypasses the forward progress guarantee provided
by the tries count, the requester is responsible for ensuring forward
progress.
Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      cf9a590a
    • Tejun Heo's avatar
      libata: improve probe failure handling · c2c7a89c
      Tejun Heo authored 
      When link is flaky at high speed, it isn't uncommon for a device to
repeatedly fail probing sequence early after successfully negotiating
high link speed.  This often leads to consecutive hotplug events
without successful probing.

This patch improves libata EH such that it remembers probing trials
and if there have been more than two unsuccessful trials in the past
60 seconds, slows down link speed to 1.5Gbps.

As link speed negotiation is the duty of the PHY layer proper, the
goal of this fallback mechanism is to provide the last resort when
everything else fails, which unfortunately happens not too
infrequently, so no fancy 6->3->1.5 speeding down or highest
successful transmission speed seen kind of logics (yet).
Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      c2c7a89c
    • Tejun Heo's avatar
      libata: add @spd_limit to sata_down_spd_limit() · a07d499b
      Tejun Heo authored 
      Add @spd_limit to sata_down_spd_limit() so that the caller can specify
the SPD limit it wants.  This parameter doesn't get in the way even
when it's too low.  The closest possible limit is applied.
Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      a07d499b
    • Tejun Heo's avatar
      libata: clear dev->ering in smarter way · 99cf610a
      Tejun Heo authored 
      dev->ering used to be cleared together with the rest of ata_device in
ata_dev_init() which is called whenever a probing event occurs.
dev->ering is about to be used to track probing failures so it needs
to remain persistent over multiple porbing events.  This patch
achieves this by doing the following.

* Instead of CLEAR_OFFSET, define CLEAR_BEGIN and CLEAR_END and only
  clear between BEGIN and END.  ering is moved after END.  The split
  of persistent area is to allow hotter items remain at the head.

* ering is explicitly cleared on ata_dev_disable() and when device
  attach succeeds.  So, ering is persistent throug a device's life
  time (unless explicitly cleared of course) and also through periods
  inbetween disablement of an attached device and successful detection
  of the next one.
Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      99cf610a
    • Tejun Heo's avatar
      libata: check onlineness before using SPD in sata_down_spd_limit() · 9913ff8a
      Tejun Heo authored 
      sata_down_spd_limit() should check whether the link is online before
using the SPD value to determine how to limit the link speed.  Factor
out onlineness test and test it from sata_down_spd_limit().
Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      9913ff8a
    • Tejun Heo's avatar
      libata: move ata_dev_disable() to libata-eh.c · 678afac6
      Tejun Heo authored 
      ata_dev_disable() is about to be more tightly integrated into EH
logic.  Move it to libata-eh.c.
Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      678afac6
    • Tejun Heo's avatar
      libata: fix EH device failure handling · d89293ab
      Tejun Heo authored 
      The dev->pio_mode > XFER_PIO_0 test is there to avoid unnecessary
speed down warning messages but it accidentally disabled SATA link spd
down during configuration phase after reset where PIO mode is always
zero.

This patch fixes the problem by moving the test where it belongs.
This makes libata probing sequence behave better when the connection
is flaky at higher link speeds which isn't too uncommon for eSATA
devices.
Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      d89293ab
    • Tejun Heo's avatar
      sata_nv: ck804 has borked hardreset too · 8d993eaa
      Tejun Heo authored 
      While playing with nvraid, I found out that rmmoding and insmoding
often trigger hardreset failure on the first port (the second one was
always okay).  Seriously, how diverse can you get with hardreset
behaviors?  Anyways, make ck804 use noclassify variant too.
Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      8d993eaa
    • Sergei Shtylyov's avatar
      ide/libata: fix ata_id_is_cfa() (take 4) · 2999b58b
      Sergei Shtylyov authored 
      When checking for the CFA feature set support, ata_id_is_cfa() tests bit 2 in
word 82 of the identify data instead the word 83;  it also checks the ATA/PI
version support in the word 80 (which the CompactFlash specifications have as
reserved), this having no slightest chance to work on the modern CF cards that
don't have 0x848A in the word 0...
Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      2999b58b
    • Randy Dunlap's avatar
      libata: fix kernel-doc warnings · 5eb66fe0
      Randy Dunlap authored 
      Fix libata kernel-doc warnings:

Warning(linux-next-20090120//drivers/ata/libata-core.c:4720): Excess function parameter 'dev' description in 'ata_qc_new'
Warning(linux-next-20090120//drivers/ata/libata-scsi.c:428): No description found for parameter 'ap'
Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      5eb66fe0
    • Arjan van de Ven's avatar
      ahci: add a module parameter to ignore the SSS flags for async scanning · f3d7f23f
      Arjan van de Ven authored 
      The SSS flag, which directs the OS to spin up one disk at a time
to not have the PSU blow out, sometimes gets set even when not needed.
The effect of this is a longer-than-needed boot time.

This patch adds a module parameter that makes the driver ignore SSS
at least as far as the parallel scan during boot is concerned...
Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      f3d7f23f
    • Mark Lord's avatar
      sata_mv: Fix chip type for Hightpoint RocketRaid 1740/1742 · 4462254a
      Mark Lord authored 
      Fix chip type for the Highpoint RocketRAID 1740 and 1742 PCI cards.
These really do have Marvell 6042 chips on them, rather than the 5081 chip.

Confirmed by multiple (two) users (for the 1740), and by examining
the product photographs from Highpoint's web site.
Signed-off-by: default avatarMark Lord <mlord@pobox.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      4462254a
    • Pasi Kärkkäinen's avatar
      [libata] sata_sil: Fix compilation error with libata debugging enabled · 41137aa6
      Pasi Kärkkäinen authored 
      I tried compiling 2.6.29-rc1 and 2.6.29-rc3 with libata debugging enabled
and got the following error:

  CC [M]  drivers/ata/sata_sil.o
drivers/ata/sata_sil.c: In function 'sil_fill_sg':
drivers/ata/sata_sil.c:327: error: 'pi' undeclared (first use in this function)
drivers/ata/sata_sil.c:327: error: (Each undeclared identifier is reported only once
drivers/ata/sata_sil.c:327: error: for each function it appears in.)
make[2]: *** [drivers/ata/sata_sil.o] Error 1
make[1]: *** [drivers/ata] Error 2
make: *** [drivers] Error 2

include/linux/libata.h has the following enabled:

#define ATA_DEBUG
#define ATA_VERBOSE_DEBUG
#define ATA_IRQ_TRAP

This fixes the compilation.
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      41137aa6
  3. 01 Feb, 2009 1 commit
    • Linus Torvalds's avatar
      Manually revert "mlock: downgrade mmap sem while populating mlocked regions" · 27421e21
      Linus Torvalds authored 
      This essentially reverts commit 8edb08ca.

It downgraded our mmap semaphore to a read-lock while mlocking pages, in
order to allow other threads (and external accesses like "ps" et al) to
walk the vma lists and take page faults etc.  Which is a nice idea, but
the implementation does not work.

Because we cannot upgrade the lock back to a write lock without
releasing the mmap semaphore, the code had to release the lock entirely
and then re-take it as a writelock.  However, that meant that the caller
possibly lost the vma chain that it was following, since now another
thread could come in and mmap/munmap the range.

The code tried to work around that by just looking up the vma again and
erroring out if that happened, but quite frankly, that was just a buggy
hack that doesn't actually protect against anything (the other thread
could just have replaced the vma with another one instead of totally
unmapping it).

The only way to downgrade to a read map _reliably_ is to do it at the
end, which is likely the right thing to do: do all the 'vma' operations
with the write-lock held, then downgrade to a read after completing them
all, and then do the "populate the newly mlocked regions" while holding
just the read lock.  And then just drop the read-lock and return to user
space.

The (perhaps somewhat simpler) alternative is to just make all the
callers of mlock_vma_pages_range() know that the mmap lock got dropped,
and just re-grab the mmap semaphore if it needs to mlock more than one
vma region.

So we can do this "downgrade mmap sem while populating mlocked regions"
thing right, but the way it was done here was absolutely not correct.
Thus the revert, in the expectation that we will do it all correctly
some day.

Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      27421e21
  5. 31 Jan, 2009 15 commits
  7. 30 Jan, 2009 10 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7