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
