Thanks. I merged and pushed these patches. When you get some time, reply to that mail I sent offlist about how long it is taking for the set host net params to succeed, so I can fix my login/init patch as needed.
On 12/11/2014 01:53 PM, The Lee-Man wrote: > Hi Mike: > > I have started working more with iscsiuio. > > I have discovered what I consider a bug in an error message printed > during normal operation of iscsiadm that makes it seem like something > bad happened. > > As you know, when performing discovery via the bnx2i transport and the > iscsiuio daemon, the iscsiadm command tries to set up host parameters > when a target is discovered. The iscsiadm command does this by sending a > message to the iscsiuio daemon, who actually does the work in this case > and then normally returns that information. > > But it looks like the design of iscsiuio is that it does not even try to > set up the NIC it is using very first time its called. Instead, it > initializes the NIC only when the first attempt to use it is received, > while it returns EAGAIN to the caller. The protocol evidently is that > the caller knows to retry. In this case, the iscsiadm code retries > several times no matter what error is returned. In fact, the iscsiadm > code being used translates all errors received from this attempt to talk > to iscsiuio into an "INTERNAL_ERROR", and the communication is retried > anyway. > > This translation is the only problem, IMHO, and resulted in these > messages from iscsiadm, which are misleading (and poorly formatted): > > iscsiadm: Could not set host net params (err 29) > > iscsiadm: Connection to discovery portal 10.125.128.120 failed: > internal error > ... > > which becomes, with my patches: > > iscsiadm: Could not set host net params (err 29) > iscsiadm: Connection to discovery portal 192.168.30.1 failed: operation > failed but retry may succeed > ... > > The "fix" is simple: in the case where iscsiuio returns EAGAIN, let it > through. (And fix the error message printing so we don't core dump, of > course.) > > I thought about a more aggressive fix, i.e. letting all return values > from the communications attempt through, but I worried about fixing > something that is not really broken and perhaps breaking something else. > So, in the spirit of fixing just what is broken, I submit two patches: > > 0001-Supply-strings-for-newly-added-error-numbers.patch: This patch is > needed by the second patch, though it stands alone. This patch fixes the > problem that a couple of new error codes have been added to the > open-iscsi package but the array of error strings used to convert those > errors into printed messages has not kept pace. So two missing error > messages are added. > > 0002-Allow-setting-host-params-to-return-EAGAIN-errors.patch - This is > the simple patch that allows EAGAIN errors through when trying to talk > to iscsiuio. If you want the more aggressive version please let me know. > > -- > You received this message because you are subscribed to the Google > Groups "open-iscsi" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to open-iscsi+unsubscr...@googlegroups.com > <mailto:open-iscsi+unsubscr...@googlegroups.com>. > To post to this group, send email to open-iscsi@googlegroups.com > <mailto:open-iscsi@googlegroups.com>. > Visit this group at http://groups.google.com/group/open-iscsi. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
