[stgt] bs_rdwr_request

[FUJITA Tomonori]

On Mon, 27 Aug 2012 22:23:00 -0700
ronnie sahlberg <ronniesahlberg at gmail.com> wrote:

> On Mon, Aug 27, 2012 at 10:16 PM, FUJITA Tomonori
> <fujita.tomonori at lab.ntt.co.jp> wrote:
>> On Mon, 27 Aug 2012 22:10:22 -0700
>> ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>>
>>> On Sun, Aug 26, 2012 at 11:51 PM, FUJITA Tomonori
>>> <fujita.tomonori at lab.ntt.co.jp> wrote:
>>>> On Mon, 27 Aug 2012 09:42:02 +0300
>>>> Roi Dayan <roi.dayan at gmail.com> wrote:
>>>>
>>>>> On Mon, Aug 27, 2012 at 3:39 AM, FUJITA Tomonori
>>>>> <fujita.tomonori at lab.ntt.co.jp> wrote:
>>>>> > On Sun, 26 Aug 2012 15:58:02 +0300
>>>>> > Roi Dayan <roi.dayan at gmail.com> wrote:
>>>>> >
>>>>> >> On Sun, Aug 26, 2012 at 3:32 PM, Roi Dayan <roi.dayan at gmail.com> wrote:
>>>>> >> > On Fri, Aug 24, 2012 at 1:06 PM, <frederik.vos at linvirt.nl> wrote:
>>>>> >> >>
>>>>> >> >> I tested also version 1.0.28: no problem
>>>>> >> >> version 1.0.29: no problem
>>>>> >> >> version 1.0.30: there is the problem
>>>>> >> >>
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > Hi,
>>>>> >> >
>>>>> >> > I tested as well with ESXi 5.1 and I could not login with ESXi as initiator
>>>>> >> > The error from tgtd was as follows:
>>>>> >> >
>>>>> >> > tgtd: add_mode_page(1648) Mode Page 10 (0x01): param_count 6 != MODE
>>>>> >> > PAGE size : 31
>>>>> >> >
>>>>> >> >
>>>>> >> > I checked for commits between 1.0.29 - 1.0.30 that modify or call this
>>>>> >> > function and found
>>>>> >> > that commit 9a95b4431ccc01b82cb4febc735485cd06cd5ea4 added a new call
>>>>> >> > to add_mode_page()
>>>>> >> > and the error is the result of that new call:
>>>>> >> >
>>>>> >> > 518     +  /* Control Extensions mode page:  TCMOS:1 */
>>>>> >> > 519     +  add_mode_page(lu, "0x0a:1:0x1c:0x04:0x00:0x00");
>>>>> >> >
>>>>> >> >
>>>>> >> > After removing this call ESXi logged in fine and without any problems.
>>>>> >> >
>>>>> >> > frederik,
>>>>> >> > mind trying it as well?
>>>>> >
>>>>> > I guess that it's due to compare-and-write command but I might be
>>>>> > wrong.
>>>>> >
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> The failure is because add_mode_page expect size of data according to
>>>>> the size specified in the page string
>>>>> i.e. for the call: add_mode_page(lu, "0x0a:1:0x1c:0x04:0x00:0x00");
>>>>> the size is 0x1c (28) and the data count is 3 (0x04 0x00:0x00) so
>>>>> add_mode_page fails.
>>>>>
>>>>> The patch I sent accepts it and it means rest of the bytes in the page
>>>>> data will be 0 because of how the page is allocated.
>>>>
>>>> Ah, I see. Thanks for the explanation.
>>>>
>>>>
>>>>> Do you still want a patch to update the callers instead?
>>>>
>>>> No. Your patch sounds ok. Ronnie, any opinion?
>>>>
>>>> But I don't think that your patch fixes Frederik's problem.
>>>
>>> Ouch,
>>>
>>> That is definitely a bug for the 0x0a:0x01 modepage as Roi points out.
>>> I have been travelling and my mailbox is a bit 'unstructured' right
>>> now so I can not see Roi's patch
>>> but as SPC states this modepage must be 0x1c in size, (spc4 7.5.8)
>>> we should pad the mode page from the current 6 bytes to the proper 31
>>> bytes byt adding zeroes to it.
>>
>> Yeah, but COMPARE_AND_WRITE bug is not related with this?
> 
> No it is not I think.
> 
> Can we get a network trace of the failure?
> Then I can try to fix it over the next few days

He said that he got tons of the following bugs:

tgtd: bs_rdwr_request(336) io error 0x1003070 89 1024 1024 22544384, Success

that memcmp might fails.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html