> It gets a little confusing because the ire_dlureq_mp is > used for both dl_unitdata requests and responses, but I think what you > are saying is that when we reinit the nce, we have a dl_unitdata *request* > (not the response) in the nce, so that we really cannot force the nce_state > to be ND_RECHABLE at this point. right?
That's at least part of it. It's not clear to me if it's by design that nce_add_v4() attaches two different types of mblk_t's to nce_res_mp. I'd think that it should always be attaching either an areq_t or an dl_unitdata_mp -- but right now it appears to attach one or the other, depending on whether the caller provided a res_mp. At a minimum, that's incredibly confusing. Why not have two separate fields in the ill_t? > The real solution is to eliminate the allow_unresolved hack, and figure > out what to do for cgtp. In the case of cgtp, I think the assert at > line 30020 of ip_xmit_v4 was triggered once during testing. I believe it > is ok to trigger this assert, but I would have to re-examine the cgtp > assumptions to do this part. > > As things stand, clearly the allow_unresolved is really not working at all, > since we can hit this path for cgtp packets as well. So I think this means the fix for 6508701 must be backed out of Nevada as a short-term solution. I will try backing it out in my workspace and removing the previous fix we'd arrived at, and see if things appear to be working. -- meem
