Re: dtrace return hook missing for some iokit funcs?
Re: dtrace return hook missing for some iokit funcs?
- Subject: Re: dtrace return hook missing for some iokit funcs?
- From: Terry Lambert <email@hidden>
- Date: Thu, 22 Apr 2010 14:36:12 -0700
On Apr 22, 2010, at 2:17 PM, Andrew Gallatin wrote:
Terry Lambert wrote:
If you compile a DEBUG kernel, you will get an IOLog telling you
more or less exactly what's going on.
Any words of wisdom for a DEBUG kernel? I"m crashing early in boot
when I try to use it (preemption (1) != 0!) from the context of kext.
It seems to happen before the ethernet driver is loaded, so I'm pretty
much DOA.
I used the instructions here (except used the versions on the 10.6.3
page since the crashbox runs 10.6.3):
http://shantonu.blogspot.com/2009/09/mac-os-x-kernel-source-xnu-has-been.html
Then I copied the resulting mach_kernel to / and rebooted.
Is there something else I need to do, or does a 10.6.3
DEBUG kernel just not boot?
Generally a panic in an otherwise unmodified DEBUG kernel is either an
invalid assertion, or there's an OSBundleRequired/Root in a plist
somewhere that's not really required and is shooting you in the foot.
In the case of an invalid assertion, you can either comment it out or
change it to a printf (since we use these kernels internally, there
should be no issues there, however).
To rule out a bogus KEXT, you should hold down the shift key to boot
it in "safe mode" so that it doesn't load non-required KEXTs; this may
get you all the way up. If not, check for third party KEXTs.
FWIW, this assertion (I assume you meant "preemption_level(1) !=
0"???) is meant to identify locations where someone is holding a
simple lock while attempting to acquire a mutex. Basically, it means
they are mixing simple/spin locks and mutexes. The assertion lives in
the CHECK_PREEMPTION_LEVEL() macro in the file osfmk/i386/i386_lock.s,
if you need to comment it out (but I think what needs to happen
instead is for someone to fix the busted KEXT...). Note that
acquisition of a mutex takes a potentially very long time,
particularly if someone else holds it, and spin locks will panic if
they are held more tha a few microseconds, so trying to get a mutex
while holding a simple lock is a very very bad coding error.
-- Terry
_______________________________________________
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