Re: [PATCH] hptiop: HighPoint RocketRAID 3xxx controller driver

Re: [PATCH] hptiop: HighPoint RocketRAID 3xxx controller driver

[HighPoint Linux Team]

On Saturday, June 10, 2006 11:36 PM, James Bottomley wrote: 
>	_req = get_req(hba);
>	if (_req == NULL) {
>		dprintk("hptiop_queuecmd : no free req\n");
>		scp->result = DID_BUS_BUSY << 16;
>		goto cmd_done;
>	}
> 
> This should be doing a return SCSI_MLQUEUE_HOST_BUSY.  DID_BUS_BUSY
> doesn't do the resource contention counting that you want
> (MLQUEUE_HOST_BUSY will wait until a command returns ... presumably
> freeing up resources before trying another).

Right, this should be modified.

>	/*
>	 * hptiop_shutdown will flash controller cache.
>	 */
>	if (scp->cmnd[0] == SYNCHRONIZE_CACHE)  {
>		scp->result = DID_OK<<16;
>		goto cmd_done;
>	}
>
> Are you really sure you want to do this?  It looks like we'll be doing
> this in cases where shutdown won't be called (like suspend). 

These lines should be removed. The controller firmware will response to
SYNCHRONIZE_CACHE command.

>	host->can_queue = le32_to_cpu(iop_config.max_requests);
>	host->cmd_per_lun = le32_to_cpu(iop_config.max_requests);
> 
> You might want to think about adjusting this.  For the single LUN case,
> it's fine.  For the multi-lun case it may allow commands to a single LUN
> to starve everything else.

There will be no multi-lun support for the controller so this is not
an issue.

Signed-off-by: HighPoint Linux Team <linux@highpoint-tech.com>
---

diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
index 8302f3b..7806c45 100644
--- a/drivers/scsi/hptiop.c
+++ b/drivers/scsi/hptiop.c
@@ -504,18 +504,10 @@ static int hptiop_queuecommand(struct sc
 	BUG_ON(!done);
 	scp->scsi_done = done;
 
-	/*
-	 * hptiop_shutdown will flash controller cache.
-	 */
-	if (scp->cmnd[0] == SYNCHRONIZE_CACHE)  {
-		scp->result = DID_OK<<16;
-		goto cmd_done;
-	}
-
 	_req = get_req(hba);
 	if (_req == NULL) {
 		dprintk("hptiop_queuecmd : no free req\n");
-		scp->result = DID_BUS_BUSY << 16;
+		scp->result = SCSI_MLQUEUE_HOST_BUSY;
 		goto cmd_done;
 	}

Re: [PATCH] hptiop: HighPoint RocketRAID 3xxx controller driver

[HighPoint Linux Team]

On Sunday 11 June 2006 05:07 pm, HighPoint Linux Team wrote:
>>
>>	host->can_queue = le32_to_cpu(iop_config.max_requests);
>>	host->cmd_per_lun = le32_to_cpu(iop_config.max_requests);
>> 
>> You might want to think about adjusting this.  For the single LUN case,
>> it's fine.  For the multi-lun case it may allow commands to a single LUN
>> to starve everything else.
>
>There will be no multi-lun support for the controller so this is not
>an issue.

Sorry, a mistake. Multi-lun is supported.
Should host->can_queue be set to (cmd_per_lun * max_lun) ?

Re: [PATCH] hptiop: HighPoint RocketRAID 3xxx controller driver

[Jeff Garzik]

HighPoint Linux Team wrote:
> --- a/drivers/scsi/hptiop.c
> +++ b/drivers/scsi/hptiop.c
> @@ -504,18 +504,10 @@ static int hptiop_queuecommand(struct sc
>  	BUG_ON(!done);
>  	scp->scsi_done = done;
>  
> -	/*
> -	 * hptiop_shutdown will flash controller cache.
> -	 */
> -	if (scp->cmnd[0] == SYNCHRONIZE_CACHE)  {
> -		scp->result = DID_OK<<16;
> -		goto cmd_done;
> -	}
> -
>  	_req = get_req(hba);
>  	if (_req == NULL) {
>  		dprintk("hptiop_queuecmd : no free req\n");
> -		scp->result = DID_BUS_BUSY << 16;
> +		scp->result = SCSI_MLQUEUE_HOST_BUSY;
>  		goto cmd_done;
>  	}

Close.  For the last bit of code quoted above, you should return 
SCSI_MLQUEUE_HOST_BUSY as your ->queuecommand() return code, rather than 
setting scp->result and calling the done() hook.

	Jeff

Re: [PATCH] hptiop: HighPoint RocketRAID 3xxx controller driver

[James Bottomley]

On Sun, 2006-06-11 at 19:18 +0800, HighPoint Linux Team wrote:
>                 dprintk("hptiop_queuecmd : no free req\n");
> -               scp->result = DID_BUS_BUSY << 16;
> +               scp->result = SCSI_MLQUEUE_HOST_BUSY;
>                 goto cmd_done;

As jeff said, this needs to become a return SCSI_MLQUEUE_HOST_BUSY.

> On Sunday 11 June 2006 05:07 pm, HighPoint Linux Team wrote:
> >>
> >>	host->can_queue = le32_to_cpu(iop_config.max_requests);
> >>	host->cmd_per_lun = le32_to_cpu(iop_config.max_requests);
> >> 
> >> You might want to think about adjusting this.  For the single LUN case,
> >> it's fine.  For the multi-lun case it may allow commands to a single LUN
> >> to starve everything else.
> >
> >There will be no multi-lun support for the controller so this is not
> >an issue.
> 
> Sorry, a mistake. Multi-lun is supported.
> Should host->can_queue be set to (cmd_per_lun * max_lun) ?

It depends on how the controller behaves.  Setting can_queue and
cmd_per_lun tends to work for most SCSI controllers because the actual
scsi devices have queue depths << this number.  If your controller will
behave like this (i.e. will not allow the internal queue for a single
lun to fill up to this depth) then you can keep this setting (although,
again, since this is probably fixed by the firmware, you want to set
cmd_per_lun to this value to avoid excessive QUEUE_FULL returns).  If
the controller will happily load all the available slots up for a single
lun, then you might want to think about reducing cmd_per_lun to some
fraction of can_queue (you could even set it to can_queue - 2 like the
3ware controller).

Most of the other actual raid controllers seem to have much smaller
per-lun queues, so they mainly set smaller, fixed size values for
cmd_per_lun.

James

Re: [PATCH] hptiop: HighPoint RocketRAID 3xxx controller driver

[HighPoint Linux Team]

James Bottomley wrote:
>> Should host->can_queue be set to (cmd_per_lun * max_lun) ?
>
> It depends on how the controller behaves.  Setting can_queue and
> cmd_per_lun tends to work for most SCSI controllers because the 
> actual scsi devices have queue depths << this number.  If your 
> controller will behave like this (i.e. will not allow the internal
> queue for a single lun to fill up to this depth) then you can keep
> this setting (although, again, since this is probably fixed by the
> firmware, you want to set cmd_per_lun to this value to avoid
> excessive QUEUE_FULL returns). If the controller will happily load
> all the available slots up for a single lun, then you might want
> to think about reducing cmd_per_lun to some fraction of can_queue
> (you could even set it to can_queue - 2 like the 3ware controller).

The hptiop firmware works as the latter case. Should it be modified
like this:
  host->can_queue = le32_to_cpu(iop_config.max_requests);
- host->cmd_per_lun = le32_to_cpu(iop_config.max_requests);
+ host->cmd_per_lun = host->can_queue - 2;

While the 3ware driver sets both can_queue and cmd_per_lun to 254:

(3w-9xxx.h)
#define TW_Q_LENGTH           256
#define TW_MAX_CMDS_PER_LUN   254

(3w-9xxx.c)
.can_queue   = TW_Q_LENGTH-2,
.cmd_per_lun = TW_MAX_CMDS_PER_LUN

Should can_queue be set to TW_Q_LENGTH ?

HighPoint Linux Team

Re: [PATCH] hptiop: HighPoint RocketRAID 3xxx controller driver

[HighPoint Linux Team]

Updates:
- don't bypass SYNCHRONIZE_CACHE command
- return SCSI_MLQUEUE_HOST_BUSY when no free request slots
- move scsi_remove_host() to the begin of hpt_remove(), or it will
  not work after resources being released.


Signed-off-by: HighPoint Linux Team <linux@highpoint-tech.com>
---

diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
index 8302f3b..a96751c 100644
--- a/drivers/scsi/hptiop.c
+++ b/drivers/scsi/hptiop.c
@@ -504,19 +504,10 @@ static int hptiop_queuecommand(struct sc
 	BUG_ON(!done);
 	scp->scsi_done = done;
 
-	/*
-	 * hptiop_shutdown will flash controller cache.
-	 */
-	if (scp->cmnd[0] == SYNCHRONIZE_CACHE)  {
-		scp->result = DID_OK<<16;
-		goto cmd_done;
-	}
-
 	_req = get_req(hba);
 	if (_req == NULL) {
 		dprintk("hptiop_queuecmd : no free req\n");
-		scp->result = DID_BUS_BUSY << 16;
-		goto cmd_done;
+		return SCSI_MLQUEUE_HOST_BUSY;
 	}
 
 	_req->scp = scp;
@@ -1429,6 +1420,8 @@ static void hptiop_remove(struct pci_dev
 
 	dprintk("scsi%d: hptiop_remove\n", hba->host->host_no);
 
+	scsi_remove_host(host);
+
 	spin_lock(&hptiop_hba_list_lock);
 	list_del_init(&hba->link);
 	spin_unlock(&hptiop_hba_list_lock);
@@ -1448,7 +1441,6 @@ static void hptiop_remove(struct pci_dev
 	pci_set_drvdata(hba->pcidev, NULL);
 	pci_disable_device(hba->pcidev);
 
-	scsi_remove_host(host);
 	scsi_host_put(host);
 }
 

[PATCH] hptiop: wrong register used in hptiop_reset_hba()

[HighPoint Linux Team]

IOP reset message should be posted to inbound message register
instead of outbound message register.

Signed-off-by: HighPoint Linux Team <linux@highpoint-tech.com>
---

diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
index ab2f8b2..74d4d22 100644
--- a/drivers/scsi/hptiop.c
+++ b/drivers/scsi/hptiop.c
@@ -577,7 +577,7 @@ static int hptiop_reset_hba(struct hptio
 	if (atomic_xchg(&hba->resetting, 1) == 0) {
 		atomic_inc(&hba->reset_count);
 		writel(IOPMU_INBOUND_MSG0_RESET,
-				&hba->iop->outbound_msgaddr0);
+				&hba->iop->inbound_msgaddr0);
 		hptiop_pci_posting_flush(hba->iop);
 	}