That is a kernel panic. The Apple signifies that the kernel has been loaded and the system is loading kext to get read to start launchd and load actual programs and user items.

• Apple Chud Tools For Mac Free

You'll need to troubleshoot this or just try reinstalling the OS (erase if needed) if you have a good and recent backup of the user data. If you don't have a backup or want to troubleshoot this for learning purposes, I would start as follows:. Review Apple's troubleshooting guide:.

Unplug all accessories (yes even keyboard, monitor, everything - and then only connect the things you need and only when you need them). Boot to safe mode to see if it's a non-essential kext or configuration that's causing the panic. (so - I would try a safe mode boot with only a USB keyboard connected- wait 5 minutes and then plug in the monitor if it's a desktop Mac).

Make a backup if you can boot into safe mode. Boot into recovery mode (or target mode) and make backups of any files you need. Resintall the OS (this shouldn't erase any user data and hopefully it will fix the panic).

Optionally you can pause and dig into the /private/var/log/panic.log contents to see if you want to remove any third party kernel extensions. Of course, it could actually be a hardware error and the Xcode install is pure coincidence (you needed to be doing something right before it failed), but there are lots of things you can do before taking it in for service in most instances where a KP happens at boot.

From the loaded kernel extensions in the backtrace, we can see that com.apple.iokit.CHUDKernLib is the bundle identifier of the kernel extension that is causing the kernel panic. That makes sense, as the CHUD tools are part of the older Xcode installs.

Apple Chud Tools For Mac Free

If you're comfortable with the command line, what I would do is start up in single-user mode by holding down Commmand-S right after you start up your machine. At the prompt, type the following and press return: mount -uw / This will mount the filesystem in read-write mode so you can make changes. Then type the following 4 commands, pressing return after each line.

Ten Things Apple Did To Make Mac OS X Faster © Amit Singh. All Rights Reserved.

Written in May 2004 Introduction The performance of computer hardware typically increases monotonically with time. Even if the same could be said of software, the rate at which software performance improves is usually very slow compared to that of hardware.

In fact, many might opine that there is plenty of software whose performance has deteriorated consistently with time. Moreover, it is rather difficult to establish an objective performance metric for software as complex as an operating system: a 'faster OS' is a very subjective, context dependent phrase. An operating system's architecture has a much greater longevity than that of common hardware. Operating system researchers do not come up with new, much faster algorithms as consistently or frequently as hardware updates happen. Nevertheless, those involved in 'producing' operating systems - researchers, designers, implementers, and even marketeers - have the arduous task of ensuring that the associated performance curves keep going up.

There are not many viable players in the OS market (some might argue, even if rhetorically, that essentially there's only one). Still, it is a very tough market, and OS vendors must 'improve' their systems incessantly.

Now, given that you are not likely to run into earth-shattering algorithmic breakthroughs in every OS release cycle, how do you make your system faster? The problem has a multi-pronged solution:. Rather than looking for generalized optimizations pedantically, you could look into making the system faster for one (or more, but a few) 'common' usage scenario. You could consider numerous minor and mundane performance improvements, even if they are technically unimpressive/uninteresting, or ugly/kludgy to implement. Together, such improvements could lead to a perceptible performance gain from the users' point of view.

You could vary the granularity at which you would usually make improvements. For example, in addition to improving typical OS algorithms, you could look into improving more meta operations, such as the entire boot process. The most important kind of performance is the one perceived by the eventual users of a system. Thus, in any usage scenario, a 'faster workflow' would be tantamount to 'higher performance'. It might be possible to make the workflow faster without making fundamental changes in the design and implementation of the components involved. With apriori knowledge of how the system would be typically used, you could rearrange the order in which things happen (even if the resulting order is unnatural or unclean), if doing so makes the user believe that things are happening faster. Example: Mac OS X This document discusses ten things that Apple did (beyond initial/fundamental OS design and implementation) to improve Mac OS X's performance.

Some of these are simply good ideas and obvious candidates for implementation; some are guidelines or tools for developers to help them create high-performance applications, while some are proactive attempts at extracting performance from strategically chosen quarters. Consider the following a sampling of such optimizations, in no particular order: Summary. 1. BootCache Mac OS X uses a boot-time optimization (effectively a smart read-ahead) that monitors the pattern of incoming read requests to a block device (the boot disk), and sorts the pattern into a 'playlist', which is used to cluster reads into a private cache. This 'boot cache' is then used for satisfying incoming read requests, if possible. The scheme also measures the cache hit rate, and stores the request pattern into a 'history list' for being adaptive in future.

If the hit rate is too low, the caching is disabled. The loadable (sorted) read pattern is stored in /var/db/BootCache.playlist. Once this pattern is loaded, the cache comes into effect. The entire process is invisible from users. This feature is only supported on the root device. Further, it requires at least 128 MB of physical RAM before it is enabled (automatically). /System/Library/Extensions/BootCache.kext is the location of the kernel extension implementing the cache while Contents/Resources/BootCacheControl within that directory is the user-level control utility (it lets you load the playlist, among other things).

The effectiveness of BootCache can be gauged from the following: in a particular update to 'Panther', a reference to BootCacheControl was broken. BootCache is started (via BootCacheControl, the control utility) in /etc/rc, and a prefetch tag is inserted (unless the system is booting in safe mode).

/etc/rc looks for BootCacheControl in the Resources directory of the BootCache.kext bundle, as well as in /usr/sbin, and finds it in the former (it doesn't exist in the latter). However, another program ( loginwindow.app) accesses /usr/sbin/BootCacheControl directly, and does not find it. For what it's worth, making BootCacheControl available in /usr/sbin, say via a symbolic link, reduces the boot time (measured from clicking on the 'Restart' confirmation button to the point where absolutely everything has shown up on the system menu) from 135 seconds to 60 seconds on one of my machines. Kernel Extensions Cache There may be close to a hundred kernel extensions that are loaded on a typical Mac OS X system, and perhaps twice as many residing in the system's 'Extensions' folder(s).

Kernel extensions may have dependencies on other extensions. Rather than scan all these every time the system boots (or worse, every time an extension is to be loaded), Mac OS X uses caching for kernel extensions, and the kernel itself. There are three types of kernel/kext caches used in this context:. The kernel cache contains the kernel code, linked kernel extensions, and info dictionaries of any number of kernel extensions.

The default cache directory for this type of cache is /System/Library/Caches/com.apple.kernelcaches. The cache files in this directory are named kernelcache.XXXXXXXX, where the suffix is a 32-bit adler checksum (the same algorithm as used by Gzip). The multi-extension, or mkext cache, contains multiple kernel extensions and their info directories. Such caches are used during early system startup. BootX, the bootloader, tries to load a previously cached list of device drivers (created/updated by /usr/sbin/kextcache). If the mkext cache is corrupt or missing, BootX would look in /System/Library/Extensions for extensions that are needed in the current scenario (as determined by the value of the OSBundleRequired property in the Info.plist file of the extension's bundle.

The mkext cache exists by default as /System/Library/Extensions.mkext. You can use /usr/sbin/mkextunpack to extract the contents of a mkext archive. The kext repository cache contains the info dictionaries for all kernel extensions in a single repository directory, including their plugins. This cache exists by default as /System/Library/Extensions.kextcache. Note that this file is simply a large property list (XML) file that is Gzip compressed. Hot File Clustering Hot File Clustering (HFC) aims to improve the performance of small, frequently accessed files on HFS Plus volumes. This optimization is currently used only on boot volumes.

HFC is a multi-staged clustering scheme that records 'hot' files (except journal files, and ideally quota files) on a volume, and moves them to the 'hot space' on the volume (0.5% of the total filesystem size located at the end of the default metadata zone, which itself is at the start of the volume). The files are also defragmented.

The various stages in this scheme are DISABLED, IDLE, BUSY, RECORDING, EVALUATION, EVICTION, and ADOPTION. At most 5000 files, and only files less than 10 MB in size are 'adopted' under this scheme. The 'metadata zone' referred to in the above description is an area on disk that may be used by HFS Plus for storing volume metadata: the Allocation Bitmap File, the Extents Overflow File, the Journal File, the Catalog File, Quota Files, and Hot Files. Mac OS X 10.3.x places the metadata zone near the beginning of the volume, immediately after the volume header.

HFC (and the metadata zone policy) are used only on journaled HFS Plus volumes that are at least 10 GB in size. Note that what constitutes the set of hot files on your system will depend on your usage pattern over a few days.

If you are doing extensive C programming for a few days, say, then it is likely that many of your hot files will be C headers. Refer to Apple's documentation for these tools for more details. fsusage Report system calls and page faults related to filesystem activity. heap List all malloc-allocated buffers in a process's heap. ktrace/kdump Enable/view (from a trace) kernel process tracing.

leaks Search a process's for unreferenced malloc buffers. mallochistory Show a process's malloc allocations. otool Display various parts of an object file. pagestuff Display information on specified pages of a Mach-O file.

sample Profile a process during a time interval. scusage Show system call usage statistics.

vmmap Display virtual memory regions allocated in a process. Performance Measurement Tools. MallocDebug Tracks and analyzes allocated memory. ObjectAlloc Tracks Objective-C and Core Foundation object allocations and deallocations.

OpenGL Profiler Tool for profiling OpenGL applications. PEFViewer Viewer for the contents of a PEF binary. QuartzDebug Visualizer for an application's screen drawing behavior - the areas being redrawn are flashed briefly. Sampler Viewer for execution behavior of a program. Spin Control Samples applications that cause the spinning cursor to appear. Thread Viewer Viewer for threads and their activity. CHUD Tools The Computer Hardware Understanding Development (CHUD) Tools package, an optional installation, provides tools such as the following:.

BigTop A graphical equivalent to top, vmstat, etc. Displays system statistics.

CacheBasher Measures cache performance. MONster Tool for collecting and visualizing hardware level performance data.

PMC Index Tool for searching Performance Monitoring Counter (PMC) events. Reggie SE A viewer (and editor) for CPU and PCI configuration registers. Saturn Tool for profiling applications at the function-call level, and visualizing the profile data. Shark Performs system-wide sampling/profiling to create a profile of the execution behavior of a program, so as to help you understand where time is being spent as your code runs. Skidmarks GT Processor performance benchmark (integer, floating-point, and vector benchmarks). SpindownHD Utility for displaying the sleep/active status of attached drives.

acid Analyzes traces generated by amber (only the TT6E format). amber Traces all threads of execution in a process, recording every instruction and data access to a trace file. simg4 A cycle-accurate core simulator of the Motorola PowerPC G4 processor.

simg5 A cycle-accurate core simulator of the IBM PowerPC 970 (G5) processor. Journaling in HFS Plus While modern filesystems are often journaled by design, journaling came to HFS Plus rather late. Apple retrofitted journaling into HFS Plus as a supplementary mechanism to the erstwhile working of the filesystem, with Panther being the first version to have journaling turned on by default. On a journaled HFS Plus volume, file object metadata and volume structures are journaled, but not file object data (fork contents, that is). The primary purpose of the journal is to make recovery faster and more reliable, in case a volume is unmounted uncleanly, but it may improve the performance of metadata operations. Instant-on Apple computers do not hibernate.

Rather, when they 'sleep', enough devices (in particular, the dynamic RAM) are kept alive (at the cost of some battery life, if the computer is running on battery power). Consequently, upon wakeup, the user perceives instant-on behavior: a very desirable effect.

Similarly, by default the system tries to keep network connections alive even if the machine sleeps. For example, if you login (via SSH, say) from one PowerBook to another, and both of them go to sleep, your login should stay alive within the constraints of the protocols. Epilogue Using Mac OS X as an example, we looked at a few kinds of optimizations that 'OS people' (particularly those involved in creating an end-user system) adopt to improve performance. The integration of all such optimizations is perhaps even more important than the optimizations themselves. The end result should be a perceptible improvement in performance. A desirable manifestation of such improvement would be a faster workflow for the end-user.