From: Mark Lord <liml@rtr.ca>
To: Tejun Heo <tj@kernel.org>
Cc: Jeff Garzik <jgarzik@pobox.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: [PATCH] libata-core More robust parsing for multi_count(v5)
Date: Thu, 19 Mar 2009 23:37:31 -0400 [thread overview]
Message-ID: <49C30F7B.30800@rtr.ca> (raw)
In-Reply-To: <49C2D642.90706@kernel.org>
Tejun Heo wrote:
> Hello, Mark.
>
> Mark Lord wrote:
>> Make libata more robust when parsing the multi_count
>> field from a drive's identify data. This prevents us from
>> attempting to use dubious multi_count values ad infinitum.
>>
>> Reset dev->multi_count to zero and reprobe it each time
>> through this routine, as it can change on device reset.
>>
>> Also ensure that the reported "maximum" value is valid
>> and is a power of two, and that the reported "count" value
>> is valid and also a power of two. And that the "count"
>> value is not greater than the "maximum" value.
>>
>> Signed-off-by: Mark Lord <mlord@pobox.com>
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> The patch looks safe to me although requiring power_of_2 on max seems
> a bit too strict.
..
Just a safeguard against bad IDENTIFY data.
I've never seen a drive that specified anything there
other than 1, 8, or 16, and the ATA spec specifically
recommends against using settings that are not powers of 2.
> For configuration, ata_dev_configure() is the right
> place. I think the following should work.
>
> * add dev->multi_limit which is initialized to -1 on ata_dev_init().
>
> * during ata_dev_configure() if multi_limit < 0, set it to device max.
>
> * set dev->multi to rounddown_pow_of_two(multi_limit) and issue
> SET_MULTI.
>
> On EH side, ata_eh_speed_down() is the place to handle it. It can
> probably piggy back on ATA_EH_SPDN_SPEED_DOWN block. All it has to do
> is reducing dev->multi_limit. dev_config will run later and apply it.
..
I won't have time to pursue this in the near/foreseeable future,
so if you feel the urge.. please do it. Otherwise I might get to
it in a few months from now.
> I'm not sure how the speed down strategy should exactly be tho. It is
> distinguisible from regular transfer errors?
..
I don't really have a recommendation there, other than to simply stop
using multi_count if there are repeated PIO errors. Seems like a reasonable
strategy, when all else is failing.
We really need to add SET_MULTIPLE smarts to libata at some point.
Cheers
next prev parent reply other threads:[~2009-03-20 3:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-18 14:26 [PATCH] libata-core Use more robust parsing for multi_count Mark Lord
2009-03-18 14:32 ` Alan Cox
2009-03-18 15:06 ` Mark Lord
2009-03-18 15:13 ` Mark Lord
2009-03-18 17:09 ` Alan Cox
2009-03-18 15:58 ` Mark Lord
2009-03-18 16:18 ` [PATCH] libata-core More robust parsing for multi_count(v3) Mark Lord
2009-03-18 16:24 ` Mark Lord
2009-03-19 0:23 ` Tejun Heo
2009-03-19 0:25 ` Tejun Heo
2009-03-19 17:30 ` [PATCH] libata-core More robust parsing for multi_count(v4) Mark Lord
2009-03-19 17:32 ` [PATCH] libata-core More robust parsing for multi_count(v5) Mark Lord
2009-03-19 23:33 ` Tejun Heo
2009-03-20 3:37 ` Mark Lord [this message]
2009-03-20 13:13 ` Mark Lord
2009-03-20 13:14 ` Mark Lord
2009-03-20 14:07 ` Alan Cox
2009-03-20 15:36 ` Mark Lord
2009-03-20 23:14 ` Tejun Heo
2009-03-21 0:54 ` Jeff Garzik
2009-03-21 2:17 ` Tejun Heo
2009-03-21 13:54 ` Mark Lord
2009-03-21 14:02 ` Alan Cox
2009-03-21 14:59 ` Mark Lord
2009-03-20 13:38 ` Alan Cox
2009-04-12 15:10 ` Mark Lord
2009-04-12 15:18 ` Alan Cox
2009-04-12 15:31 ` Jeff Garzik
2009-03-25 2:40 ` Jeff Garzik
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=49C30F7B.30800@rtr.ca \
--to=liml@rtr.ca \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=tj@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.