Re: [RFC PATCH v5 7/7] libsas: let libata recover links that fail to transmit initial sig-fis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jan 14, 2012 at 10:10 AM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
> libsas fails to discover all sata devices in the domain.  If a device fails
> negotiation and does not transmit a signature fis the link needs recovery.
> libata already understands how to manage slow to come up links, so treat these
> conditions as ata device attach events for the purposes of creating an
> ata_port.  This allows libata to manage retrying link bring up.
>
> Cc: Jack Wang <jack_wang@xxxxxxxxx>
> Cc: Xiangliang Yu <yuxiangl@xxxxxxxxxxx>
> Cc: Luben Tuikov <ltuikov@xxxxxxxxx>
> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
> ---
[..]
>  static int smp_ata_check_ready(struct ata_link *link)
>  {
>        int res;
> -       u8 addr[8];
>        struct ata_port *ap = link->ap;
>        struct domain_device *dev = ap->private_data;
>        struct domain_device *ex_dev = dev->parent;
>        struct sas_phy *phy = sas_get_local_phy(dev);
> +       struct ex_phy *ex_phy = &ex_dev->ex_dev.ex_phy[phy->number];
>
> -       res = sas_get_phy_attached_sas_addr(ex_dev, phy->number, addr);
> +       res = sas_ex_phy_discover(ex_dev, phy->number);
>        sas_put_local_phy(phy);
> +
>        /* break the wait early if the expander is unreachable,
>         * otherwise keep polling
>         */
>        if (res == -ECOMM)
>                return res;
> -       if (res != SMP_RESP_FUNC_ACC || SAS_ADDR(addr) == 0)
> +       if (res != SMP_RESP_FUNC_ACC)
>                return 0;
> -       else
> -               return 1;
> +
> +       switch (ex_phy->attached_dev_type) {
> +       case SATA_PENDING:
> +               return 0;
> +       case SAS_END_DEV:
> +               if (ex_phy->attached_sata_dev)
> +                       return sas_ata_clear_pending(dev, ex_phy);
> +       default:
> +               return -ENODEV;
> +       }
>  }

Side comment, it strikes me as deadlock prone that we need to do
GFP_KERNEL allocations to recover a domain_device.  Since we're now
enforcing one in-flight smp command per expander, we might as well
pre-allocate the request/response buffers for managing remote phys.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux