> "Christoph" == Christoph Hellwig writes:
Christoph> On Tue, Jan 17, 2017 at 07:43:51PM +0530, Sreekanth Reddy wrote:
>> [Sreekanth] Just for readability purpose, can use use "if
>> (test_bit(0, &sas_device_priv_data->ata_command_pending)" instead of
>> "if (sas_device_priv_data->ata_command
On Tue, 2017-01-17 at 19:43 +0530, Sreekanth Reddy wrote:
> On Tue, Jan 17, 2017 at 1:31 AM, James Bottomley
> wrote:
> > From 91d249409546569444897a1ffde65c421e064899 Mon Sep 17 00:00:00
> > 2001
> > From: James Bottomley
> > Date: Sun, 1 Jan 2017 09:39:24 -0800
> > Subject: [PATCH] scsi: mpt3sa
On Tue, Jan 17, 2017 at 07:43:51PM +0530, Sreekanth Reddy wrote:
> [Sreekanth] Just for readability purpose, can use use "if (test_bit(0,
> &sas_device_priv_data->ata_command_pending)"
> instead of "if (sas_device_priv_data->ata_command_pending)".
> Since while setting & clearing the bit we are us
On Tue, Jan 17, 2017 at 1:31 AM, James Bottomley
wrote:
> From 91d249409546569444897a1ffde65c421e064899 Mon Sep 17 00:00:00 2001
> From: James Bottomley
> Date: Sun, 1 Jan 2017 09:39:24 -0800
> Subject: [PATCH] scsi: mpt3sas: fix hang on ata passthrough commands
>
> mpt3sas has a firmware failure
* Martin K. Petersen wrote:
> > "James" == James Bottomley
> > writes:
>
> James> Subject: [PATCH] scsi: mpt3sas: fix hang on ata passthrough
> James> commands
>
> James> mpt3sas has a firmware failure where it can only handle one pass
> James> through ATA command at a time. If anot
> "James" == James Bottomley writes:
James> Subject: [PATCH] scsi: mpt3sas: fix hang on ata passthrough
James> commands
James> mpt3sas has a firmware failure where it can only handle one pass
James> through ATA command at a time. If another comes in, contrary to
James> the SAT standard, it
>From 91d249409546569444897a1ffde65c421e064899 Mon Sep 17 00:00:00 2001
From: James Bottomley
Date: Sun, 1 Jan 2017 09:39:24 -0800
Subject: [PATCH] scsi: mpt3sas: fix hang on ata passthrough commands
mpt3sas has a firmware failure where it can only handle one pass
through ATA command at a time.
On Sun, 2017-01-15 at 09:01 -0800, James Bottomley wrote:
> From b47c28434e9cee9cbb95a794c97ec53657408111 Mon Sep 17 00:00:00 2001
> From: James Bottomley
> Date: Sun, 1 Jan 2017 09:39:24 -0800
> Subject: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands
>
> mp3sas has
omicity?
James
---
>From b47c28434e9cee9cbb95a794c97ec53657408111 Mon Sep 17 00:00:00 2001
From: James Bottomley
Date: Sun, 1 Jan 2017 09:39:24 -0800
Subject: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands
mp3sas has a firmware failure where it can only handle one pass
through AT
> "Sreekanth" == Sreekanth Reddy writes:
Sreekanth> We are fine with this patch. Can we rename function
Sreekanth> 'set_satl_pending()' name to '_scsih_set_satl_pending()' and
Sreekanth> can add headers to this function.
Sreekanth> other wise I am OK.
Sreekanth> Acked-by: Sreekanth Reddy
On Fri, Jan 6, 2017 at 7:29 AM, Martin K. Petersen
wrote:
>> "James" == James Bottomley writes:
>
> James> Now that I look at the reviews, each of the reviewers said what
> James> the correct thing to do was: return SAM_STAT_BUSY if SATL
> James> commands are outstanding like the spec says.
> "James" == James Bottomley writes:
James> Now that I look at the reviews, each of the reviewers said what
James> the correct thing to do was: return SAM_STAT_BUSY if SATL
James> commands are outstanding like the spec says. You all get
James> negative brownie points for not insisting on a r
On 01/01/2017 12:39 PM, James Bottomley wrote:
On Sun, 2017-01-01 at 11:33 -0500, David Miller wrote:
From: Bart Van Assche
Date: Sun, 1 Jan 2017 14:22:11 +
My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
secure erase premature termination"). Since the mpt3sas driv
On Sun, 2017-01-01 at 11:33 -0500, David Miller wrote:
> From: Bart Van Assche
> Date: Sun, 1 Jan 2017 14:22:11 +
>
> > My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
> > secure erase premature termination"). Since the mpt3sas driver uses the
> > single-queue approach
From: Bart Van Assche
Date: Sun, 1 Jan 2017 14:22:11 +
> My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
> secure erase premature termination"). Since the mpt3sas driver uses the
> single-queue approach and since the SCSI core unlocks the block layer
> request queue lo
On 01/01/2017 09:22 AM, Bart Van Assche wrote:
> On Sat, 2016-12-31 at 15:19 -0800, James Bottomley wrote:
>> On Thu, 2016-12-29 at 00:02 -0800, Christoph Hellwig wrote:
>>> On Wed, Dec 28, 2016 at 11:30:24PM -0500, Jason Baron wrote:
Add a new parameter to scsi_internal_device_block() to de
On Sat, 2016-12-31 at 15:19 -0800, James Bottomley wrote:
> On Thu, 2016-12-29 at 00:02 -0800, Christoph Hellwig wrote:
> > On Wed, Dec 28, 2016 at 11:30:24PM -0500, Jason Baron wrote:
> > > Add a new parameter to scsi_internal_device_block() to decide
> > > whether or not to invoke scsi_wait_for_
On Thu, 2016-12-29 at 00:02 -0800, Christoph Hellwig wrote:
> On Wed, Dec 28, 2016 at 11:30:24PM -0500, Jason Baron wrote:
> > Add a new parameter to scsi_internal_device_block() to decide
> > whether or not to invoke scsi_wait_for_queuecommand().
>
> We'll also need to deal with the blk-mq wait
From: Jason Baron
Date: Wed, 28 Dec 2016 23:30:24 -0500
> On ata passthru commands scsih_qcmd() ends up spinning in
> scsi_wait_for_queuecommand() indefinitely. scsih_qcmd() is called from
> __blk_run_queue_uncond() which first increments request_fn_active to a
> non-zero value. Thus, scsi_wait_f
On 12/29/2016 03:02 AM, Christoph Hellwig wrote:
> On Wed, Dec 28, 2016 at 11:30:24PM -0500, Jason Baron wrote:
>> Add a new parameter to scsi_internal_device_block() to decide whether
>> or not to invoke scsi_wait_for_queuecommand().
> We'll also need to deal with the blk-mq wait path that Bart h
On Wed, Dec 28, 2016 at 11:30:24PM -0500, Jason Baron wrote:
> Add a new parameter to scsi_internal_device_block() to decide whether
> or not to invoke scsi_wait_for_queuecommand().
We'll also need to deal with the blk-mq wait path that Bart has been
working on (I think it's already in the scsi tr
On ata passthru commands scsih_qcmd() ends up spinning in
scsi_wait_for_queuecommand() indefinitely. scsih_qcmd() is called from
__blk_run_queue_uncond() which first increments request_fn_active to a
non-zero value. Thus, scsi_wait_for_queuecommand() never completes because
its spinning waiting for
22 matches
Mail list logo
