On 11/07/2013 05:45 PM, Stephen M. Cameron wrote:
> From: Stephen M. Cameron <scame...@beardog.cce.hp.com>
>
> The hardware guys tell us that after initiating a software
> reset via the doorbell register we need to wait 5 seconds before
> attempting to talk to the board *at all*.  This means that we
> cannot watch the board to verify it transitions from "ready" to
> to "not ready" then back "ready", since this transition will
> most likely happen during those 5 seconds (though we can still
> verify the reset happens by watching the "driver version" field
> get cleared.)
>
> Signed-off-by: Stephen M. Cameron <scame...@beardog.cce.hp.com>
> ---
>  drivers/scsi/hpsa.c |   32 +++++++++++++++++++++++---------
>  1 files changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 20fc598..fff5fd3 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -3781,6 +3781,13 @@ static int hpsa_controller_hard_reset(struct pci_dev 
> *pdev,
>                */
>               dev_info(&pdev->dev, "using doorbell to reset controller\n");
>               writel(use_doorbell, vaddr + SA5_DOORBELL);
> +
> +             /* PMC hardware guys tell us we need a 5 second delay after
> +              * doorbell reset and before any attempt to talk to the board
> +              * at all to ensure that this actually works and doesn't fall
> +              * over in some weird corner cases.
> +              */
> +             msleep(5000);
>       } else { /* Try to do it the PCI power state way */
>  
>               /* Quoting from the Open CISS Specification: "The Power
> @@ -3977,15 +3984,22 @@ static int hpsa_kdump_hard_reset_controller(struct 
> pci_dev *pdev)
>          need a little pause here */
>       msleep(HPSA_POST_RESET_PAUSE_MSECS);

I know it's complicated with a lot of different devices and fw versions,
but here^ we wait for 3sec - isn't the method - wait for 3s then wait for board 
not ready
a bit fragile, what if a board comes up faster?
When the method "watching the "driver version"" works why don't you want to use 
it  
regardless of the reset method used?

>  
> -     /* Wait for board to become not ready, then ready. */
> -     dev_info(&pdev->dev, "Waiting for board to reset.\n");
> -     rc = hpsa_wait_for_board_state(pdev, vaddr, BOARD_NOT_READY);
> -     if (rc) {
> -             dev_warn(&pdev->dev,
> -                     "failed waiting for board to reset."
> -                     " Will try soft reset.\n");
> -             rc = -ENOTSUPP; /* Not expected, but try soft reset later */
> -             goto unmap_cfgtable;
> +     if (!use_doorbell) {
> +             /* Wait for board to become not ready, then ready.
> +              * (if we used the doorbell, then we already waited 5 secs
> +              * so the "not ready" state is already gone by so we
> +              * won't catch it.)
> +              */
> +             dev_info(&pdev->dev, "Waiting for board to reset.\n");
> +             rc = hpsa_wait_for_board_state(pdev, vaddr, BOARD_NOT_READY);
> +             if (rc) {
> +                     dev_warn(&pdev->dev,
> +                             "failed waiting for board to reset."
> +                             " Will try soft reset.\n");
> +                     /* Not expected, but try soft reset later */
> +                     rc = -ENOTSUPP;
> +                     goto unmap_cfgtable;
> +             }
>       }
>       rc = hpsa_wait_for_board_state(pdev, vaddr, BOARD_READY);
>       if (rc) {
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to