#11
|
||||
|
||||
An direct update to 10.5.5 via Apple Software Update crashed at about 12% on a test system, I tried two attempts. Update my main system wouldn't be useful because it was messed up even with kernel 9.3.0, random kernel panics and hangs and so on. Are there special files (kexts etc.) which should be replaced if a user can't update?
Yesterday I had two crazy crashes while filling my memory to test the 64bit-adapted NForce driver: Logic and MainStage crashed shortly after, but the crash report shows only ??? in the list. Do you want to fix the 'About this Mac' thing? I don't know, if parts of the system don't recognize the processor correctly some things may not work like they should. 2 Opteron systems: OSx86 10.5.8, Andy's 9.8.0 kernel, Asus A8N-SLI Premium, Opteron 185 o'clocked @ 2 x 2,95 GHz (2nd system 2.6 GHz), ATI Radeon HD2600XT 256MB Dual-Monitor 2x HP L2035, 4 GB RAM, Griffin FireWave as main audio device, Marvell + nForce LAN, Asus U3S6 USB3/SATA6 card, 5,5 TB harddisk, Firewire 800 card, Apple Remote + eHome IR receiver, 2x Wacom serial graphics tablet, Canon Pixma iP4700, Logitech Internet Navigator wireless keyboard/mouse combination. My Audio stuff: M-Audio Transit USB (default audio), M-Audio ProFire 610, M-Audio ProFire Lightbridge (34 channels) using Creamware A16 ADAT converter • MIDI: M-Audio Midiman 4x MIDI interface • Behringer Audio Mixers: Xenyx 1002, Xenyx 1002FX, Xenyx 1202FX, Eurorack UB1002FX, Eurorack MX1804FX, Eurorack MX262A • FX devices: Lexicon MPX100 DSP, Behringer DSP-1000 Virtualizer, Behringer MiniFEX 800 DSP, Behringer Multicom Pro MDX4400 compressor • RETRO: MSSIAH midi/sequencer/synthesizer cardridge for the C64 (Dual-SID), Steinberg M.S.I. MIDI Interface for C64 |
#12
|
||||
|
||||
It seems that my applications did not become obsolete ...
I'm happy ! |
#13
|
|||
|
|||
Will I be able to install from a retail 10.5.1 dvd and upgrade _after_ the install, or do I need an updated retail dvd?
|
#14
|
|||
|
|||
Quote:
All this kernel does is erase the distinction between AMD and Intel users, meaning you can follow a guide previously written only for Intel machines an in *theory* everything should go just as well. You still have to take precautions so your machine doesn't crash, if for example IntelCPUManagement gets loaded, you still need to make sure that you re-install the kernel if it's overwritten by an update, etc, etc. |
#15
|
||||
|
||||
What Dies said. In fact I can confirm that the crash at 12% was because of AppleIntelCPUPowerManagement.kext -- I hosed my system recently because of just that (and I have an Intel Pentium M..). So in short for updating, follow Intel guides, don't just blindly run software update for critical updates. The kernel erases distinction between AMD and Intel -- NOT between vanilla and patched setups.
Also @naquaada. re: processor identification. AMD is identified as Core Solo or Core Duo on purpose. For that part of the kernel, we had the option to report the processor either as one of Apple-supported CPUs, or report it as Unknown. There is no way to identify the cpu as anything else. Unknown doesn't work for some apps (installers specially) so we went with Intel Core.. Last edited by mercurysquad; 11-28-2008 at 09:09 PM. |
#16
|
||||
|
||||
Quote:
People are incorrectly assuming that the kernel allows them to update straight from software update - this is only true as much as for non-vanilla Intel users. From what I gather, your utility still does a whole lot of things apart from patching CPUIDs, so the utility is still relevant. Feel free to get in touch with us if you need more detailed info about the kernel and its workings. Everyone else please note that you can run prepatched binaries no problem, but it doesn't mean the kernel will not disassemble each binary as it is loaded (since we have no way to tell whether the binary is already patched or not unless we load it). This means you won't gain any performance by prepatching your whole HDD. Since on-the-fly is really very fast, the amount of time you'll spend reading the HDD, patching binaries and rewriting it back to disk will probably be longer than what the opcode patcher will take in total during average usage. If you still insist on prepatching manually and don't want to use the patcher at all, boot with patcher_opts=0. Last edited by mercurysquad; 11-28-2008 at 09:19 PM. |
#17
|
||||
|
||||
Quote:
For users which have problems with a kernel panic directly at the start, try booting with -f to fix all kernel extensions, this works for me. I added it in apple.com.boot.plist, my system actually crashes nearly all ten minutes, no matter which kernel. It's rather frustrating. 2 Opteron systems: OSx86 10.5.8, Andy's 9.8.0 kernel, Asus A8N-SLI Premium, Opteron 185 o'clocked @ 2 x 2,95 GHz (2nd system 2.6 GHz), ATI Radeon HD2600XT 256MB Dual-Monitor 2x HP L2035, 4 GB RAM, Griffin FireWave as main audio device, Marvell + nForce LAN, Asus U3S6 USB3/SATA6 card, 5,5 TB harddisk, Firewire 800 card, Apple Remote + eHome IR receiver, 2x Wacom serial graphics tablet, Canon Pixma iP4700, Logitech Internet Navigator wireless keyboard/mouse combination. My Audio stuff: M-Audio Transit USB (default audio), M-Audio ProFire 610, M-Audio ProFire Lightbridge (34 channels) using Creamware A16 ADAT converter • MIDI: M-Audio Midiman 4x MIDI interface • Behringer Audio Mixers: Xenyx 1002, Xenyx 1002FX, Xenyx 1202FX, Eurorack UB1002FX, Eurorack MX1804FX, Eurorack MX262A • FX devices: Lexicon MPX100 DSP, Behringer DSP-1000 Virtualizer, Behringer MiniFEX 800 DSP, Behringer Multicom Pro MDX4400 compressor • RETRO: MSSIAH midi/sequencer/synthesizer cardridge for the C64 (Dual-SID), Steinberg M.S.I. MIDI Interface for C64 |
#18
|
||||
|
||||
I will still work on cpuid patching, for my own knowledge and for some people who experience trouble with this kernel or who can't install EFI (which I think is necessary to use the voodoo kernel).
At the moment I'm learning Objective-C which, I think, is a good idea if I want to create applications for Mac OS. Quote:
And thanks for the work you and your team have done, I wanted a kernel like this one when I created my first release of Mac OS X ! |
#19
|
||||||
|
||||||
OK. Explanations follow.
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
And second, we do NOT have the option to identify the CPU correctly. It's either Unknown, OR an Intel CPU. The kernel, the programs, installers and kexts do NOT know about anything else. I will paste that part of the code so it will be clearer: The part which sets the cpu type: Code:
/* hw.cpufamily */ switch (cpuid_info()->cpuid_family) { case 6: switch (cpuid_info()->cpuid_model) { case 13: cpufamily = CPUFAMILY_INTEL_6_13; break; case 14: cpufamily = CPUFAMILY_INTEL_6_14; /* Core Solo/Duo */ break; case 15: cpufamily = CPUFAMILY_INTEL_6_15; /* Core 2 */ break; case 23: cpufamily = CPUFAMILY_INTEL_6_23; break; case 26: cpufamily = CPUFAMILY_INTEL_6_26; break; default: /* For other models, report Intel Core */ cpufamily = CPUFAMILY_INTEL_6_14; } break; /* mercurysquad: Report cpu family as one of the Apple-recognized * CPUs, for CPU families other than 6. This entire system is very * myopic, where the kernel explicitly encourages checking for a handful * of families with arbitrary signatures. We cannot define our own * signatures here as we never know when an installer or other app * might check among only the ones stock kernel supports.*/ case 15: /* This applies to Pentium 4/D and AMD Phenom. In the future * we might want to choose a more specific cpufamily based on the * number of cores etc., but for now it's just not worth it IMO */ switch (cpuid_info()->cpuid_model) { case 0: case 1: case 2: /* Report Core Solo/Duo for these models */ cpufamily = CPUFAMILY_INTEL_6_14; default: /* For higher models, report Core 2 Duo */ cpufamily = CPUFAMILY_INTEL_6_15; } default: /* For unknown CPU families, just report Intel Core */ cpufamily = CPUFAMILY_INTEL_6_14; } Code:
/* * CPU families (sysctl hw.cpufamily) * * These are meant to identify the CPU's marketing name - an * application can map these to (possibly) localized strings. * NB: the encodings of the CPU families are intentionally arbitrary. * There is no ordering, and you should never try to deduce whether * or not some feature is available based on the family. * Use feature flags (eg, hw.optional.altivec) to test for optional * functionality. */ #define CPUFAMILY_UNKNOWN 0 #define CPUFAMILY_POWERPC_G3 0xcee41549 #define CPUFAMILY_POWERPC_G4 0x77c184ae #define CPUFAMILY_POWERPC_G5 0xed76d8aa #define CPUFAMILY_INTEL_6_13 0xaa33392b #define CPUFAMILY_INTEL_6_14 0x73d67300 /* "Intel Core Solo" and "Intel Core Duo" (32-bit Pentium-M with SSE3) */ #define CPUFAMILY_INTEL_6_15 0x426f69ef /* "Intel Core 2 Duo" */ #define CPUFAMILY_INTEL_6_23 0x78ea4fbc /* Penryn */ #define CPUFAMILY_INTEL_6_26 0x6b5a4cd2 /* Nehalem */ #define CPUFAMILY_ARM_9 0xe73283ae #define CPUFAMILY_ARM_11 0x8ff620d8 #define CPUFAMILY_ARM_XSCALE 0x53b005f5 #define CPUFAMILY_INTEL_YONAH CPUFAMILY_INTEL_6_14 #define CPUFAMILY_INTEL_MEROM CPUFAMILY_INTEL_6_15 #define CPUFAMILY_INTEL_PENRYN CPUFAMILY_INTEL_6_23 #define CPUFAMILY_INTEL_NEHALEM CPUFAMILY_INTEL_6_26 #define CPUFAMILY_INTEL_CORE CPUFAMILY_INTEL_6_14 #define CPUFAMILY_INTEL_CORE2 CPUFAMILY_INTEL_6_15 Last edited by mercurysquad; 11-29-2008 at 03:46 AM. |
#20
|
|||
|
|||
Why do people care about what it says for CPU?
This is a mean-less thing as it is just something that tells you what CPU you have and doesn't effect how the system runs If people would just look at the big picture and see what mercurysquad and company have made and accomplished and be happy that they can run a system without patching and do the things that Intel user that run vanilla can do is quit a feat Great Job on the kernel On the AppleIntelPowermanagment.kext just get the null kext that way you don't have to worry about it when you update 💡 Deploy cloud instances seamlessly on DigitalOcean. Free credits ($100) for InfMac readers. Last edited by bhast2; 11-29-2008 at 04:56 AM. |