linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>
>    


  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).