The mistery of the dlil_filter_detach call
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Let's say we have the following KP log: The first two calls are: Call_continuation and dlil_detach_filter and then it goes into ip_input, etc... Problems: - there's been no interface filter detached as far as I know. Funny part: Question: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... I'm beginning to wonder if I'm not missing one point with the panic logs. Tue Feb 21 16:51:12 2006 panic(cpu 0 caller 0x002917A8): sbappendaddr Latest stack backtrace for cpu 0: Backtrace: 0x00095564 0x00095A7C 0x00026838 0x002917A8 0x00291994 0x001614D0 0x0014E6CC 0x0014F3A8 0x00139FFC 0x0013A110 0x0011C2A8 0x000A9654 Proceeding back via exception chain: Exception state (sv=0x44553280) PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown) Kernel version: Darwin Kernel Version 8.0.0: Thu Mar 24 19:14:36 PST 2005; root:xnu-790.1.obj~1/RELEASE_PPC - I don't see ifmaddr_ifnet being called in the source code of dlil_detach_filter. This Kernel Panic happens with a kext in its early stage of development and when double-clicking on a .pkg (Installer.app is launched and then bang!) Is it possible to trust a KP log on 10.4.x? I don't see any reason why dlil_detach_filter would be called (no interface filter is detached). So why can I see it in the log? The trace does not look perfectly correct as usual with the KP I see involving dlil_detach_filter. This email sent to site_archiver@lists.apple.com
participants (1)
-
Stephane