On Jul 18, 2008, at 12:01 PM, Chris Sarcone wrote:
This image is not drawn by EFI. It is drawn by the kernel. If a boot
time kext is installed and prevents the root device from being
found, that could cause this.
Okay, thanks.
Do you ever see a timeout in the verbose boot ("Still waiting for
root device....")? That is the verbose equivalent.
The client has reported a few times that the last thing he sees in
verbose boot is:
CSRHIDTransitionDriver.... done
Still waiting for root device
This jives what what you are saying.
There are a few boot-args you can set which will dump the IORegistry
in the verbose output to see what the state of the registry is and
if the root device stack has not fully built up. Search
"IOKitDebug.h" for the various options that get checked in xnu/iokit/
bsddev/IOKitBSDInit.cpp.
kIOLogDTree and kIOLogServiceTree look promising.
If ethernet has come up and the debugger is available, you can also
attach to the machine and see what's preventing the root device from
showing up (you can dump the registry information in the debugger
and you can inspect all the kernel stacks to see where one might be
blocked/deadlocked).
Unfortunately, it does not happen on my test machines, only the on the
client's (who is not local).
BTW, the root device is the IOBlockStorageDevice, right? As it turns
out, their kext includes an IOBlockStorageDriver subclass. Am I
correct in assuming that if IOBlockStorageDriver::start() takes too
long, it could delay the root device past the timeout, causing the
boot to fail?
-Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Boot-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
