From: Chandra Shekhar Sah <edu4madh@gmail.com>
To: Grant Grundler <grundler@google.com>
Cc: Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: port multiplier problem
Date: Thu, 11 Feb 2010 15:22:15 -0500 [thread overview]
Message-ID: <4B7466F7.6070907@gmail.com> (raw)
In-Reply-To: <da824cf31002040959y63f3484cv6d551acd49b80fa7@mail.gmail.com>
Hi all,
Any suggestion?
Thanks,
Chandra
On 2/4/10 12:59 PM, Grant Grundler wrote:
> On Wed, Feb 3, 2010 at 7:24 PM, Tejun Heo<tj@kernel.org> wrote:
>
>> On 02/04/2010 11:37 AM, Grant Grundler wrote:
>>
>>> I had two questions on that thread that never got answered:
>>> http://markmail.org/message/snpekoj4qexrslk5
>>>
>>> | How can we find out if anyone has the SEMB properly wired up?
>>> | Would it be hard to make libata aware of "SEMB port not responding" case?
>>> | ie if the SEMB port times out or has no link, reduce the port count of
>>> | the sil3726 PMP by one.
>>> |
>>> | Maybe add a "enable_sil24_semb" flag to libata?
>>> | (avoid checking unless someone asks for it). I hate magic flags but also
>>> | don't want to subject most people to the timeout delay.
>>>
>>> I (or Gwendal) can post a patch (and lightly test) for any of the above.
>>> Just need to get some guidance so we don't waste our time.
>>>
>> It's not really sil24 tho. But anyways, I think we can just disable
>> them altogether. It's not like they have ever worked. Just limiting
>> both 3726 and 4726 to 5 ports should be fine.
>>
> Sorry - You are right. I meant "enable_sil3726_semb".
>
> I'm not sure we need to limit the SEMB ports anymore either. See below.
>
>
>> That said, I'm not
>> quite sure this is relevant to the reported problem but it's worth a
>> shot.
>>
> I didn't have a better idea.
>
> I'm seeing this in sata_pmp_quirks() since ATA_LFLAG_NO_SRST was introduced:
> 337 static void sata_pmp_quirks(struct ata_port *ap)
> 338 {
> 339 u32 *gscr = ap->link.device->gscr;
> 340 u16 vendor = sata_pmp_gscr_vendor(gscr);
> 341 u16 devid = sata_pmp_gscr_devid(gscr);
> 342 struct ata_link *link;
> 343
> 344 if (vendor == 0x1095&& devid == 0x3726) {
> 345 /* sil3726 quirks */
> 346 ata_for_each_link(link, ap, EDGE) {
> 347 /* Class code report is unreliable and SRST
> 348 * times out under certain configurations.
> 349 */
> 350 if (link->pmp< 5)
> 351 link->flags |= ATA_LFLAG_NO_SRST |
> 352 ATA_LFLAG_ASSUME_ATA;
> 353
> 354 /* port 5 is for SEMB device and it
> doesn't like SR ST */
> 355 if (link->pmp == 5)
> 356 link->flags |= ATA_LFLAG_NO_SRST |
> 357 ATA_LFLAG_ASSUME_SEMB;
> 358 }
>
>
> But the ATA_LFLAG_NO_SRST used in line 351 is not present in the
> 2.6.26 tree I know works with PMPs. The original commit comment isn't
> specific about exactly which HW had problems:
> http://www.mail-archive.com/git-commits-head@vger.kernel.org/msg24335.html
>
> "Some links on some PMPs locks up on SRST and/or report incorrect
> device signature. Implement ATA_LFLAG_NO_SRST, ASSUME_ATA and
> ASSUME_SEMB to handle these quirky links. NO_SRST makes EH avoid
> SRST. ASSUME_ATA and SEMB forces class code to ATA and SEMB_UNSUP
> respectively. Note that SEMB isn't currently supported yet so the
> _UNSUP variant is used."
>
>
> Can you publish which PMP implementations sometimes lock up on SRST?
>
> I doubt this is related to the problem Chandra is seeing but again,
> don't have better ideas.
>
> BTW, this same kernel works fine without disabling port 5 (SEMB port).
> I didn't know
> this until I just looked. I know previous source trees Google used
> ignored SEMB port
> on 3726 and I mistakenly assumed this one did too. :(
>
> thanks,
> grant
>
>
next prev parent reply other threads:[~2010-02-11 20:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4B5885F7.2020007@gmail.com>
[not found] ` <4B679EA9.6030203@kernel.org>
[not found] ` <4B6833DD.1020001@gmail.com>
2010-02-02 14:24 ` port multiplier problem Tejun Heo
2010-02-02 14:59 ` Chandra Shekhar Sah
2010-02-02 16:44 ` Grant Grundler
[not found] ` <4B686B2B.2080406@gmail.com>
2010-02-02 19:04 ` Grant Grundler
[not found] ` <4B687B7C.2070406@gmail.com>
2010-02-04 2:37 ` Grant Grundler
2010-02-04 3:24 ` Tejun Heo
2010-02-04 17:59 ` Grant Grundler
2010-02-05 2:44 ` Tejun Heo
2010-02-11 20:22 ` Chandra Shekhar Sah [this message]
2010-02-04 16:39 ` Chandra Shekhar Sah
2010-02-04 3:21 ` Tejun Heo
2010-01-21 16:57 Chandra Nepali
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=4B7466F7.6070907@gmail.com \
--to=edu4madh@gmail.com \
--cc=grundler@google.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).