On 09/03/2013 11:13 AM, Bart Van Assche wrote:
> On 09/02/13 15:11, Hannes Reinecke wrote:
>> On 09/02/2013 02:45 PM, Bart Van Assche wrote:
>>> This patch adds several new calls to LLD EH handlers. Is it
>>> guaranteed that these will only be invoked before scsi_remove_host()
>>> has finished ? Fo
On 09/02/13 15:11, Hannes Reinecke wrote:
On 09/02/2013 02:45 PM, Bart Van Assche wrote:
This patch adds several new calls to LLD EH handlers. Is it
guaranteed that these will only be invoked before scsi_remove_host()
has finished ? For more background information, see also "[PATCH]
Make scsi_re
On 09/02/13 15:11, Hannes Reinecke wrote:
On 09/02/2013 02:45 PM, Bart Van Assche wrote:
On 09/02/13 09:12, Hannes Reinecke wrote:
@@ -353,6 +354,8 @@ void scsi_put_command(struct scsi_cmnd *cmd)
list_del_init(&cmd->list);
spin_unlock_irqrestore(&cmd->device->list_lock, flags);
+
On 09/02/2013 02:45 PM, Bart Van Assche wrote:
> On 09/02/13 09:12, Hannes Reinecke wrote:
>> @@ -353,6 +354,8 @@ void scsi_put_command(struct scsi_cmnd *cmd)
>> list_del_init(&cmd->list);
>> spin_unlock_irqrestore(&cmd->device->list_lock, flags);
>>
>> +cancel_delayed_work(&cmd->ab
On 09/02/13 09:12, Hannes Reinecke wrote:
@@ -353,6 +354,8 @@ void scsi_put_command(struct scsi_cmnd *cmd)
list_del_init(&cmd->list);
spin_unlock_irqrestore(&cmd->device->list_lock, flags);
+ cancel_delayed_work(&cmd->abort_work);
+
__scsi_put_command(cmd->device->h
On 08/22/2013 10:51 AM, Ren Mingxin wrote:
Hi, Hannes:
On 07/01/2013 10:24 PM, Hannes Reinecke wrote:
When a command runs into a timeout we need to send an 'ABORT TASK'
TMF. This is typically done by the 'eh_abort_handler' LLDD callback.
Conceptually, however, this function is a normal SCSI co
Hi, Hannes:
On 07/01/2013 10:24 PM, Hannes Reinecke wrote:
When a command runs into a timeout we need to send an 'ABORT TASK'
TMF. This is typically done by the 'eh_abort_handler' LLDD callback.
Conceptually, however, this function is a normal SCSI command, so
there is no need to enter the erro
On 06/12/2013 08:34 AM, Bart Van Assche wrote:
> On 06/11/13 20:57, James Bottomley wrote:
>> Actually, I think we can dump the workqueue altogether. The only
>> reason
>> we need it is because the current abort handlers wait for the command
>> and return the completion state. However, all LLDs a
On 06/11/13 20:57, James Bottomley wrote:
Actually, I think we can dump the workqueue altogether. The only reason
we need it is because the current abort handlers wait for the command
and return the completion state. However, all LLDs are capable of
emitting TMFs at interrupt level, so if we se
On 06/11/2013 08:57 PM, James Bottomley wrote:
> On Mon, 2013-06-10 at 01:20 -0700, Christoph Hellwig wrote:
>> On Mon, Jun 10, 2013 at 09:40:52AM +0200, Hannes Reinecke wrote:
>>> When a command runs into a timeout we need to send an 'ABORT TASK'
>>> TMF. This is typically done by the 'eh_abort_ha
On Tue, 2013-06-11 at 16:41 -0400, Ewan Milne wrote:
> On Tue, 2013-06-11 at 18:57 +, James Bottomley wrote:
> > On Mon, 2013-06-10 at 01:20 -0700, Christoph Hellwig wrote:
> > > On Mon, Jun 10, 2013 at 09:40:52AM +0200, Hannes Reinecke wrote:
> > > > When a command runs into a timeout we need
On Tue, 2013-06-11 at 18:57 +, James Bottomley wrote:
> On Mon, 2013-06-10 at 01:20 -0700, Christoph Hellwig wrote:
> > On Mon, Jun 10, 2013 at 09:40:52AM +0200, Hannes Reinecke wrote:
> > > When a command runs into a timeout we need to send an 'ABORT TASK'
> > > TMF. This is typically done by
On Mon, 2013-06-10 at 01:20 -0700, Christoph Hellwig wrote:
> On Mon, Jun 10, 2013 at 09:40:52AM +0200, Hannes Reinecke wrote:
> > When a command runs into a timeout we need to send an 'ABORT TASK'
> > TMF. This is typically done by the 'eh_abort_handler' LLDD callback.
> >
> > Conceptually, howev
On Tue, 11 June 2013 08:18:51 +0200, Hannes Reinecke wrote:
> On 06/11/2013 01:24 AM, Jörn Engel wrote:
> > On Mon, 10 June 2013 11:19:16 -0400, Jörn Engel wrote:
> >>
> >> I don't care too much whether we use per-command work items or a
> >> single system-global thread.
> >
> > Actually, I do car
On 06/11/2013 01:24 AM, Jörn Engel wrote:
> On Mon, 10 June 2013 11:19:16 -0400, Jörn Engel wrote:
>>
>> I don't care too much whether we use per-command work items or a
>> single system-global thread.
>
> Actually, I do care. We have to abort the commands in parallel, as a
> fairly large number
On Mon, 10 June 2013 11:19:16 -0400, Jörn Engel wrote:
>
> I don't care too much whether we use per-command work items or a
> single system-global thread.
Actually, I do care. We have to abort the commands in parallel, as a
fairly large number of abort can queue up and individual aborts can
take
On Mon, 10 June 2013 09:40:52 +0200, Hannes Reinecke wrote:
> +
> + spin_lock_irqsave(&sdev->list_lock, flags);
> + if (list_empty(&sdev->eh_abort_list))
> + kick_worker = 1;
> + list_add(&scmd->eh_entry, &sdev->eh_abort_list);
> + spin_unlock_irqrestore(&sdev->list_lock
On Mon, 10 June 2013 11:00:49 +0200, Hannes Reinecke wrote:
> On 06/10/2013 10:20 AM, Christoph Hellwig wrote:
> >
> > Why can't we use a work item per command? Linking things into a list
> > just to queue it up to workqueues missed half of the point of the
> > workqueue infrastructure.
> >
> Hm
On 06/10/2013 10:20 AM, Christoph Hellwig wrote:
> On Mon, Jun 10, 2013 at 09:40:52AM +0200, Hannes Reinecke wrote:
>> When a command runs into a timeout we need to send an 'ABORT TASK'
>> TMF. This is typically done by the 'eh_abort_handler' LLDD callback.
>>
>> Conceptually, however, this functio
On Mon, Jun 10, 2013 at 09:40:52AM +0200, Hannes Reinecke wrote:
> When a command runs into a timeout we need to send an 'ABORT TASK'
> TMF. This is typically done by the 'eh_abort_handler' LLDD callback.
>
> Conceptually, however, this function is a normal SCSI command, so
> there is no need to e
20 matches
Mail list logo
