who decrements can_queue in Scsi_Host structure ?

who decrements can_queue in Scsi_Host structure ?

[MEHTA,HIREN (A-SanJose,ex1)]

Hi LIsts,

In the hosts.h file, the following was the definition of
can_queue variable in the Scsi_Host_Template (SHT) structure. 



    /* 
     * THis determines if we will use a non-interrupt driven
     * or an interrupt driver scheme, It is set to the maximum number
     * of simultaneous commands a given host adapter will accept.
     */
    int can_queue;

Scsi_Host structure also has the same variable which gets initialized
with the can_queue of SHT structure in the scsi_register().
Let's say the can_queue in initialized to 16. Now, I could not find
anybody decrementing this variable. So, when the time comes to
send a new command to the hba, the can_queue of the host sturcture is
checked and if that is non-zero, then the queuecommand() entry point
is immediately called. So, the queuecommand will always be called 
even if the host is already given 'can_queue' commands.

Any inputs on this ?

-hiren

Re: who decrements can_queue in Scsi_Host structure ?

[Eric Youngdale]

>     /*
>      * THis determines if we will use a non-interrupt driven
>      * or an interrupt driver scheme, It is set to the maximum number
>      * of simultaneous commands a given host adapter will accept.
>      */
>     int can_queue;
>
> Scsi_Host structure also has the same variable which gets initialized
> with the can_queue of SHT structure in the scsi_register().
> Let's say the can_queue in initialized to 16. Now, I could not find
> anybody decrementing this variable. So, when the time comes to
> send a new command to the hba, the can_queue of the host sturcture is
> checked and if that is non-zero, then the queuecommand() entry point
> is immediately called. So, the queuecommand will always be called
> even if the host is already given 'can_queue' commands.
>
> Any inputs on this ?

    It should never be decremented or incremented - this one should remain
relatively static.  The host_busy field indicates the number of commands
currently running on the HBA.

    I am seeing a bug however - in the event that can_queue is 0, the theory
was that we would go ahead and send the command down anyways and if the HBA
driver was busy it would simply reject it.  Instead we are falling through
into the ->command interface, which isn't at all what we want.

-Eric


-Eric