From: Dan Williams <dan.j.williams@intel.com>
To: Jack Wang <jack_wang@usish.com>
Cc: linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [GIT PATCH v4 0/2] libsas: eh reworks (ata-eh vs discovery, races, ...)
Date: Thu, 12 Jan 2012 17:51:27 -0800 [thread overview]
Message-ID: <CABE8wwst8n10i_T00zOK1V72LgS9XOuaK78tTn=pM8AXoy9xvA@mail.gmail.com> (raw)
In-Reply-To: <93016D61E9AE4462B084F3715705FDD6@usish.com.cn>
On Thu, Jan 12, 2012 at 5:37 PM, Jack Wang <jack_wang@usish.com> wrote:
>> For example libata will reset 3 times with increasing wait times (10s,
>> 10s, 35s). On the last attempt it will slow down the phy to give the
>> ata device a better chance of connecting. libsas is just doing 3
>> 500ms tries at full speed and then giving up.
> [Jack Wang]
> Yes， in our internal test I expand the time to 10s, but I'm not sure this will be accepted by mainline kernel.
Do you happen to have logs of a passing and failing case, i.e. before
and after adding the 10s time delay change?
I think having libata do it's normal link recovery in this case would
solve both problems of giving enough time for ata device to come up,
and allowing the initial scan to find the device and let the initial
trip through ata eh manage link. But it would be a pretty big change
from what libsas is doing currently for sata discovery.
prev parent reply other threads:[~2012-01-13 1:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-10 7:38 [GIT PATCH v4 0/2] libsas: eh reworks (ata-eh vs discovery, races, ...) Dan Williams
2012-01-10 7:38 ` [PATCH v4 1/2] libsas: pre-clean commands that won the eh vs completion race Dan Williams
2012-01-10 7:38 ` [PATCH v4 2/2] libsas: feed the scsi_block_when_processing_errors() meter Dan Williams
2012-01-10 19:29 ` [GIT PATCH v4 0/2] libsas: eh reworks (ata-eh vs discovery, races, ...) James Bottomley
2012-01-10 20:18 ` Dan Williams
2012-01-16 8:40 ` James Bottomley
2012-01-16 17:00 ` Dan Williams
2012-01-16 20:24 ` James Bottomley
2012-01-16 20:44 ` Dan Williams
2012-01-13 0:57 ` Jack Wang
2012-01-13 1:21 ` Dan Williams
2012-01-13 1:37 ` Jack Wang
2012-01-13 1:51 ` Dan Williams [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABE8wwst8n10i_T00zOK1V72LgS9XOuaK78tTn=pM8AXoy9xvA@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=jack_wang@usish.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.