On Wed, Aug 8, 2018 at 1:27 AM, Bart Van Assche wrote:
> On Tue, 2018-08-07 at 21:46 +0530, Sreekanth Reddy wrote:
>> [Sreekanth] In the patch description I mentioned that I have done a
>> manual mistake and I am correcting with this patch.
>>
>> Hope I have answered all of your quires.
>
> Not
On Tue, 2018-08-07 at 21:46 +0530, Sreekanth Reddy wrote:
> [Sreekanth] In the patch description I mentioned that I have done a
> manual mistake and I am correcting with this patch.
>
> Hope I have answered all of your quires.
Not yet unfortunately. Why do you consider the current implementation
On Tue, Aug 7, 2018 at 8:27 PM, Bart Van Assche wrote:
> On Tue, 2018-08-07 at 20:03 +0530, Sreekanth Reddy wrote:
>> The main intention of this patch to reset the smid to zero after
>> resetting the corresponding smid entry's chain_offset to zero. While
>> posting "mpt3sas: Fix calltrace
On Tue, 2018-08-07 at 20:03 +0530, Sreekanth Reddy wrote:
> The main intention of this patch to reset the smid to zero after
> resetting the corresponding smid entry's chain_offset to zero. While
> posting "mpt3sas: Fix calltrace observed while running IO & reset"
> patch I have done manual
On Tue, Aug 7, 2018 at 7:29 PM, Bart Van Assche wrote:
> On Tue, 2018-08-07 at 12:10 +0530, Sreekanth Reddy wrote:
>> This function _base_get_chain_buffer_tracker() is called only during
>> the IO submission time and mpt3sas_base_clear_st() is called during IO
>> completion time and hence I don't
On Tue, 2018-08-07 at 12:10 +0530, Sreekanth Reddy wrote:
> This function _base_get_chain_buffer_tracker() is called only during
> the IO submission time and mpt3sas_base_clear_st() is called during IO
> completion time and hence I don't see any race condition here.
>
> Currently this patch is
On Mon, Aug 6, 2018 at 11:41 PM, Bart Van Assche wrote:
> On Sat, 2018-08-04 at 18:56 +0530, Sreekanth Reddy wrote:
>> No Bart, their is no race condition here. Since chain lookup table
>> entry is uniquely accessed using smid value. And this smid (which is
>> scmd->request->tag +1) is unique for
On Sat, 2018-08-04 at 18:56 +0530, Sreekanth Reddy wrote:
> No Bart, their is no race condition here. Since chain lookup table
> entry is uniquely accessed using smid value. And this smid (which is
> scmd->request->tag +1) is unique for each IO request. And
> _base_get_chain_buffer_tracker()
On Fri, Aug 3, 2018 at 10:02 PM, Bart Van Assche wrote:
> On Fri, 2018-08-03 at 12:16 -0400, Sreekanth Reddy wrote:
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
>> b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> index 902610d..2c5a5b4 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
>> +++
On Fri, 2018-08-03 at 12:16 -0400, Sreekanth Reddy wrote:
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index 902610d..2c5a5b4 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -1702,6 +1702,13 @@
In mpt3sas_base_clear_st() function smid value is reset in
wrong line, i.e. driver should reset smid value to zero after decrementing
chain_offset counter in chain_lookup table but in current code, driver is
resetting smid value before decrementing the chain_offset counter. Which we
are correcting
11 matches
Mail list logo
