Fredrik, Can you collect a network trace of the failure so I can see how the initiator is using the comapre-and-write call ? You can just capture it with wireshark and send it to me or the list and Ill try to see what goes wrong. best regards ronnie sahlberg On Mon, Aug 27, 2012 at 10:23 PM, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > On Mon, Aug 27, 2012 at 10:16 PM, FUJITA Tomonori > <fujita.tomonori@xxxxxxxxxxxxx> wrote: >> On Mon, 27 Aug 2012 22:10:22 -0700 >> ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: >> >>> On Sun, Aug 26, 2012 at 11:51 PM, FUJITA Tomonori >>> <fujita.tomonori@xxxxxxxxxxxxx> wrote: >>>> On Mon, 27 Aug 2012 09:42:02 +0300 >>>> Roi Dayan <roi.dayan@xxxxxxxxx> wrote: >>>> >>>>> On Mon, Aug 27, 2012 at 3:39 AM, FUJITA Tomonori >>>>> <fujita.tomonori@xxxxxxxxxxxxx> wrote: >>>>> > On Sun, 26 Aug 2012 15:58:02 +0300 >>>>> > Roi Dayan <roi.dayan@xxxxxxxxx> wrote: >>>>> > >>>>> >> On Sun, Aug 26, 2012 at 3:32 PM, Roi Dayan <roi.dayan@xxxxxxxxx> wrote: >>>>> >> > On Fri, Aug 24, 2012 at 1:06 PM, <frederik.vos@xxxxxxxxxx> 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 > > regards > ronnie sahlberg -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
