Saadia Fatima wrote:
> I observed it in mac layer. Specifically in mac_promisc_dispatch_one. I
> check the original packet to make sure that it is not malformed i.e
> (db_base <= b_rptr <= b_wptr <= db_lim) and MBLKL for original is
> non-zero. Is there any workaround? Is there any address alignment or
> data size factor involved?

I can't say I've ever seen a problem like that.

No -- neither size nor alignment should have any effect.  In fact, the
code goes out of its way to preserve these things so that copies really
are just copies.

Perhaps it's a problem related to zero copy or indirect dblks or one of
those other performance-enhancement edge cases that I really haven't
done much with.  That's the only sort of issue that comes to mind.

As for "workaround," until the root cause of the problem is identified,
I don't see how there could be a coherent workaround.  I'd suggest
starting the investigation by using either dtrace or good old
cmn_err(CE_NOTE, ...) statements to figure out what's wrong with the
message block and why your code is going so wrong (when so many others
have "no problem").

-- 
James Carlson         42.703N 71.076W         <carls...@workingcode.com>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to