How to spot the fix...
How to spot the fix...
- Subject: How to spot the fix...
- From: Kevin Brock <email@hidden>
- Date: Wed, 24 Jan 2007 10:37:47 -0800
On Jan 23, 2007, at 12:10 PM, Bhavesh Davda wrote:
Date: Tue, 23 Jan 2007 10:29:37 -0800
From: Kevin Brock <email@hidden>
...
It sounds like mbuf_outbound_finalize won't work at all with certain
packets (large pings, for example). I knew I had to do workarounds
for byte order problems with the function, but I hadn't realized that
it was completely broken...
To work generically with 10.4.8 and previous kernels it sounds like I
need to do my own implementation of mbuf_outbound_finalize().
Welcome to the club :)
I had to do the same: walk the mbuf chains and do my own TCP/UDP/IPv4
header checksum computation. I was seeing the same "freeing free mbuf"
panics after calling mbuf_outbound_finalize() on Intel Macs, and I
noticed the same pattern: only happened when the mbuf was chained with
the DLIL header in the pkthdr mbuf, and the rest of the payload split
into one or more mbufs in that chain.
and
On Jan 23, 2007, at 10:19 AM, Adi Masputra wrote:
Yes, this was a long-standing bug that has been fixed recently along
with the mbuf_outbound_finalize() byte-ordering issue. The fix should
be available fairly soon.
What I'm wondering now is how we can spot the fix programmatically
when it's in.
Not the byte-order fix, which we've been told will be transparent,
but the fix to the loop that walks the mbuf chain.
Will we have to keep using our own checksum code on 10.4 systems, or
will there be some way to tell when mbuf_outbound_finalize works the
way it's supposed to? I'd really like to use the advertised API's
rather than my own code for the checksums...
Kevin Brock
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden