On Mon, 27 Aug 2012 22:23:00 -0700 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 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
