On Dec 12, 2014, at 10:30 AM, Mike Christie <micha...@cs.wisc.edu> wrote: > > 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: > > That is not how we do it. Just like in that other thread about the sysfs > scanning. We want to fix the root cause and also any issues that result > from it.
Interesting that you would reference that other thread. I don't think there's any absolute root cause in either case, so it's a judgement call. > > Please just fix this properly. It is really silly that the user would > have to run this command twice to actually do discovery. > Ouch. Okay, interesting approach. I guess I stand rebuffed. "Fixing this" would really mean getting rid of iscsiuio and having BRCM devices use the network stack, wouldn't it? I'm not sure where you draw the line between cosmetic hacks and fixing it "properly". Why do you think the user has to "run this command twice"? That is incorrect. The iscsiadm command retries the communication 10 times, I believe, or until iscsiuio replies. Do you consider that silly? Do you mean that the iscsiadm code should not retry? Or do you mean the iscsiuio code should be redesigned? This old code uses the uIP stack to perform the functions of a network driver. I am hesitant to redesign this multi-threaded beast when I have only one BRCM card, and it mostly just works now. -- The Lee-Man Rides Again "...And maddest of all, to see life as it is and not as it should be!" — Cervantes -- 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.
