Using ifnet_output_raw() kpi function.
Using ifnet_output_raw() kpi function.
- Subject: Using ifnet_output_raw() kpi function.
- From: "Alexander Klyuev" <email@hidden>
- Date: Thu, 18 Jun 2009 00:12:25 -0400
- Organization: MusicLab, inc.
Hi ALL,
I've been using ifnet_output_raw() kpi function with no problems on Tiger
and Leopard OS (32-bit kernel).
But having tried to move to 64-bit kernel on Snow Leopard preview (build
10A380) I unexpectedly got a problem.
I'm permanently getting kernel panic like that:
panic(cpu 1 caller 0xffffff800024c91c): assertion failed: m->m_type ==
MT_FREE && m->m_flags == M_EXT, file:
/SourceCache/xnu/xnu-1456/bsd/kern/uipc_mbuf.c, line: 3271.
I use mbufs of both kinds: <packet> and <header> i.e. with/without external
cluster and I definitely have problems with mbufs with external cluster.
I've read all the versions of documentation on ifnet_output_raw(). Here are
some of them:
(ADC Ref Library Xcode 2.5)
... ifnet_output_raw will always free the packet chain.
(SDK10.4u; kpi_interface.h)
... ifnet_output_raw will free the packet chain in the event of an error.
(ADC Ref Library Xcode 3.0+; SDK10.5 & SDK 10.6; kpi_interface.h)
... ifnet_output_raw will always free the packet chain.
Some old versions conflicted with newer ones regarding mbuf ownership and
I've assumed "ifnet_output_raw will always free the packet chain." statement
is correct.
However I'm a bit stuck with 64-bit kernel. Whatever I do with mbufs with
ext cluster, I get kernel panics like mentioned above and similar when I
call mbuf_getpacket(),
ifnet_output_raw() functions. I'm also having unexpected panics with similar
reason description when mbuf cache audit is performed by kernel.
Nothing of mentioned above happens on 32-bit kernel. BTW, when I manipulate
mbufs with no ext cluster, everything works correctly on 64-bit kernel as
expected.
Does anybody knows what's the reason of such 64-bit kernel behaviour
regarding mbufs with external cluster or I'm just missing something?
Any ideas/suggestions will be highly appreciated.
Alexander
_______________________________________________
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