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: Fri, 23 Apr 2010 03:00:01 -0700
You really only want DEBUG on for the section of the code giving you
problems. There are some kernel structure sizes that change which may
be responsible for your DEBUG kernel failing this way (this isn't
supposed to be the case, but you never know. That said...
On Apr 22, 2010, at 5:16 PM, Andrew Gallatin wrote:
Terry Lambert wrote:
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.
No, but it somehow re-orders things so that the Intel ethernet driver
gets loaded prior to the crash, so I might actually be able to get
a remote dump if I can remember the trick to make a netdump work
when the arp cache is empty and there is no IP assigned yet.
By my recollection, for Intel machines, the firmware doesn't DHCP an
IP address before handing things off to the kernel, so this may not
work (it works for PPC because OpenFirmware gets a DHCP lease which
configd later re-gets). The method involves setting an explicit ARP
entry for the machine to give it an IP address. I don't think this
will be enough for a kernel dump, but you can try.
Typical recommendation is to use the firewire debug KEXT, and dump
over firewire using the local loopback proxy (you end up connecting to
the proxy listening on the machine connected via firewire, but you
have to connect the machines and start the proxy before you boot the
target machine for the chip to be set up correctly there).
Both of these mthods are described in a lot of detail at <http://developer.apple.com
> under the topic "kernel debugging".
I seem to recall you saying you don't have two Macs on the list? If
so, firewire won't work for you.
There was a recent discussion of using VMWare to do this on a single
machine (see the list archives); I'm not sure if this is an option for
you or not.
The final alternative is to write down (or take a photo) of the hex
number in the backtrace, reboot the machine on a good kernel, and gdb
the panic'ing kernel, then use "list *0xblahblah" on each address to
dump out the source line information for each line in the backtrace.
You will probably end up with a section that is blowing up in
"inaccessible memory", which translates to "this stuff was in a
KEXT". You can find that, too, but only if you know where the KEXT is
loaded so you can translate those addresses at least to assembly code.
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
Yes, that's the one. No serial console or dump, so I'm transcribing
things from a monitor just at the limits of my aging vision.
FWIW, I'm loading my driver manually, so this is one bug thats not
mine ;)
So, just to be sure, it is supposed to be safe to build a kernel and
just copy it into /mach_kernel, right? Or is there more stuff I'm
supposed to be updating from my build?
This is also described on the developer site.
Basically, it depends on what/how much you are rebuilding. A KEXT
will generally link against the kernel as a result of the rebuilt
KEXTcache after linking against the kernel (this typically happens on
shutdown before it lets the machine reboot, if you touch /mach_kernel).
In some cases, it's necessary to copy the entire build root so that
the fake libraries that the KEXTs link against are copied as well.
Usually, I just copy the whole root when I'm in doubt.
-- 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