Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Resolved i7-940 and kernel panic
- Thread starter Zeke D
- Start date
- Sort by reaction score
1) Download dosdude1 Apple Microcode tool from http://dosdude1.com/apps/
2) Run Apple Microcode Tool, drag 0085 to it.
3) Select the first 106A4 microcode, right click to extract, save it.
4) Do the same for the another 106A4.
5) Open 0089 LOCKED.fd, insert both microcodes, one by one. You will need to exclude some of the other microcodes to open space, try excluding 206C0.
6) Save the edited 0089 BootROM, flash it with ROMTool.
Last edited:
Do this with the LOCKED.fd. To add the missing microcodes to your personalised version we will have to test what's the needed microcode for you to boot your other Xeon and keep both.
gotcha. off to dosdude's site.
[doublepost=1533479386][/doublepost]Worked as expected.
[doublepost=1533479603][/doublepost]I'll save those microcodes so that I can update new firmware updates. Now all I need to do is figure out why the 4,1 clicks 30 seconds after sleep and runs the GPU fan for about 3 seconds and then goes back to sleep like 10 seconds after that. (I probably just need to replace my GT8800 with a 120 or something.)
[doublepost=1533479386][/doublepost]Worked as expected.
[doublepost=1533479603][/doublepost]I'll save those microcodes so that I can update new firmware updates. Now all I need to do is figure out why the 4,1 clicks 30 seconds after sleep and runs the GPU fan for about 3 seconds and then goes back to sleep like 10 seconds after that. (I probably just need to replace my GT8800 with a 120 or something.)
Check what's the microcode being used on 0089.
Code:
sysctl machdep;/usr/libexec/ucupdate -q
Code:
Last login: Sun Aug 5 07:27:39 on console
Mac-Pro:~ default$ sysctl machdep;/usr/libexec/ucupdate -q
machdep.user_idle_level: 0
machdep.cpu.max_basic: 11
machdep.cpu.max_ext: 2147483656
machdep.cpu.vendor: GenuineIntel
machdep.cpu.brand_string: Intel(R) Core(TM) i7 CPU 940 @ 2.93GHz
machdep.cpu.family: 6
machdep.cpu.model: 26
machdep.cpu.extmodel: 1
machdep.cpu.extfamily: 0
machdep.cpu.stepping: 4
machdep.cpu.feature_bits: 43034600568257535
machdep.cpu.extfeature_bits: 4967106816
machdep.cpu.signature: 67236
machdep.cpu.brand: 0
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 POPCNT
machdep.cpu.extfeatures: SYSCALL XD EM64T LAHF RDTSCP TSCI
machdep.cpu.logical_per_package: 16
machdep.cpu.cores_per_package: 8
machdep.cpu.microcode_version: 18
machdep.cpu.processor_flag: 1
machdep.cpu.mwait.linesize_min: 64
machdep.cpu.mwait.linesize_max: 64
machdep.cpu.mwait.extensions: 3
machdep.cpu.mwait.sub_Cstates: 4384
machdep.cpu.thermal.sensor: 1
machdep.cpu.thermal.dynamic_acceleration: 1
machdep.cpu.thermal.invariant_APIC_timer: 0
machdep.cpu.thermal.thresholds: 2
machdep.cpu.thermal.ACNT_MCNT: 1
machdep.cpu.thermal.core_power_limits: 0
machdep.cpu.thermal.fine_grain_clock_mod: 0
machdep.cpu.thermal.package_thermal_intr: 0
machdep.cpu.thermal.hardware_feedback: 0
machdep.cpu.thermal.energy_policy: 0
machdep.cpu.arch_perf.version: 3
machdep.cpu.arch_perf.number: 4
machdep.cpu.arch_perf.width: 48
machdep.cpu.arch_perf.events_number: 7
machdep.cpu.arch_perf.events: 64
machdep.cpu.arch_perf.fixed_number: 3
machdep.cpu.arch_perf.fixed_width: 48
machdep.cpu.cache.linesize: 64
machdep.cpu.cache.L2_associativity: 8
machdep.cpu.cache.size: 256
machdep.cpu.tlb.inst.small: 64
machdep.cpu.tlb.inst.large: 7
machdep.cpu.tlb.data.small: 64
machdep.cpu.tlb.data.large: 32
machdep.cpu.tlb.shared: 512
machdep.cpu.address_bits.physical: 36
machdep.cpu.address_bits.virtual: 48
machdep.cpu.core_count: 4
machdep.cpu.thread_count: 8
machdep.cpu.flex_ratio.desired: 63
machdep.cpu.flex_ratio.min: 12
machdep.cpu.flex_ratio.max: 22
machdep.cpu.tsc_ccc.numerator: 0
machdep.cpu.tsc_ccc.denominator: 0
machdep.vectors.timer: 221
machdep.vectors.IPI: 222
machdep.pmap.hashwalks: 382647
machdep.pmap.hashcnts: 743937
machdep.pmap.hashmax: 24
machdep.pmap.kernel_text_ps: 2097152
machdep.pmap.kern_pv_reserve: 8000
machdep.memmap.Conventional: 8579690496
machdep.memmap.RuntimeServices: 315392
machdep.memmap.ACPIReclaim: 159744
machdep.memmap.ACPINVS: 987136
machdep.memmap.PalCode: 0
machdep.memmap.Reserved: 8781824
machdep.memmap.Unusable: 0
machdep.memmap.Other: 0
machdep.tsc.frequency: 2925999627
machdep.tsc.deep_idle_rebase: 1
machdep.tsc.at_boot: 0
machdep.tsc.rebase_abs_time: 17199762891
machdep.tsc.nanotime.tsc_base: 1415325490
machdep.tsc.nanotime.ns_base: 1044575981249
machdep.tsc.nanotime.scale: 1467863241
machdep.tsc.nanotime.shift: 0
machdep.tsc.nanotime.generation: 4
machdep.misc.fast_uexc_support: 1
machdep.misc.panic_restart_timeout: 1266874889
machdep.misc.interrupt_latency_max: 0x1 0xde 0x2c26ee
machdep.misc.timer_queue_trace:
machdep.misc.nmis: 0
machdep.xcpm.mode: 0
machdep.xcpm.hard_plimit_max_100mhz_ratio: 0
machdep.xcpm.hard_plimit_min_100mhz_ratio: 0
machdep.xcpm.soft_plimit_max_100mhz_ratio: 0
machdep.xcpm.soft_plimit_min_100mhz_ratio: 0
machdep.xcpm.tuib_plimit_max_100mhz_ratio: 0
machdep.xcpm.tuib_plimit_min_100mhz_ratio: 0
machdep.xcpm.tuib_enabled: 0
machdep.xcpm.power_source: 0
machdep.xcpm.bootplim: 0
machdep.xcpm.bootpst: 0
machdep.xcpm.tuib_ns: 0
machdep.xcpm.vectors_loaded_count: 0
machdep.xcpm.ratio_change_ratelimit_ns: 500000
machdep.xcpm.ratio_changes_total: 0
machdep.xcpm.maxbusdelay: 0
machdep.xcpm.maxintdelay: 0
machdep.xcpm.mid_applications: 0
machdep.xcpm.mid_relaxations: 0
machdep.xcpm.mid_mode: 1
machdep.xcpm.mid_cst_control_limit: 0
machdep.xcpm.mid_mode_active: 0
machdep.xcpm.mbd_mode: 1
machdep.xcpm.mbd_applications: 0
machdep.xcpm.mbd_relaxations: 0
machdep.xcpm.forced_idle_ratio: 100
machdep.xcpm.forced_idle_period: 30000000
machdep.xcpm.deep_idle_log: 0
machdep.xcpm.qos_txfr: 1
machdep.xcpm.deep_idle_count: 0
machdep.xcpm.deep_idle_last_stats: n/a
machdep.xcpm.deep_idle_total_stats: n/a
machdep.xcpm.cpu_thermal_level: 0
machdep.xcpm.gpu_thermal_level: 0
machdep.xcpm.io_thermal_level: 0
machdep.xcpm.io_control_engages: 0
machdep.xcpm.io_control_disengages: 0
machdep.xcpm.io_filtered_reads: 0
machdep.xcpm.io_cst_control_enabled: 0
machdep.xcpm.ring_boost_enabled: 0
machdep.xcpm.io_epp_boost_enabled: 0
machdep.xcpm.epp_override: 0
machdep.eager_timer_evaluations: 47
machdep.eager_timer_evaluation_max: 204481
machdep.x86_fp_simd_isr_uses: 0
signature: 0x106a4
microcode_version: 0x12
processor_flag: 0x1
Mac-Pro:~ default$
Seems it's working correctly. BTW, you used your personalised version to add the microcode.
Right, so iCloud/FaceTime/iMessage would work. Did you want me to do it with the LOCKED 0089? (like for testing and stuff?)
Only for the Bloomfield i7 processors, not for Nehalem/Westmere/Gulftown Xeon ones. Maybe something needed to be set/disabled on the microcode to make macOS boot, since it's a unsupported processor.
[doublepost=1533480926][/doublepost]
No, not needed. It was just a precaution. What's the model of your other Xeon @Zeke D?
Last edited:
SLBV3 is supported on 0x206c2 microcode, SLBEW needs 0x106a5 and you are ready for both since my choice of removing 0x206c0 was correct.
Since the new/Spectre updated microcodes are bigger, Apple needed to remove 0x106a4 microcodes to open space. So, no more Bloomfield support from now on.
Last edited:
Just don't try ES/QS or any Intel Confidential processors, you removed the microcode needed for them.
Last edited:
Typo.
QS = Qualification Samples
[doublepost=1533483770][/doublepost]Taking a look on SLBCK S-Spec, I've noticed that the i7-940 supports Thermal Monitor 2 and the standard Xeons don't have this. Maybe it's the motive for AppleCPUPowerManagement KP.
Last edited:
im glad yall where able to resolve the issue 
remember microcode is there as a low lever "patcher" for any bugs and such and it looks like the 106A4 Nehalem CPUs have such a bug that needs to be patched first before OS X can boot with said CPUs (thats a pretty interesting find in and of its self)
its why I was so admit that the BootROM get spectre patched microcode because several people where just saying "Oh the OS can do it whats the big deal?"
another example of this is 1067A Penryn CPUs without microcode theres a bug which causes you to lose support for a bunch of instruction sets one of which is needed for windows 8.1+ x64 to boot for example. (I actually wonder if this is why the MP3,1 is reported not to work with 1067A CPUs and if putting the microcode in would get em booting)
its also worth mentioning
Apple did NOT remove support for Bloomfield CPUs with the 0089 BootROM they only removed Microcode for the C0/C1 (106A4) stepping of Bloomfield CPUs
106A5 (D0) stepping Bloomfield CPUs are perfectly fine and are spectre patched, Remember several MacPro4,1 and 5,1 Mac Pros shipped with Bloomfield CPUs but every single one of those are D0, all production Xeon Bloomfield CPUs where D0 stepping it was only some of the i7s that where C0/C1
its also worth mentioning
QS CPUs Qualification Sample are generally always of a production stepping so those are fine in a Mac Pro
its the ES or engineering sample CPUs which can be of a pervious stepping and cause issues.
PS im pretty sure most if not all LGA1366 CPUs do TM2 it goes all the way back to the Pentium M days IIRC
remember microcode is there as a low lever "patcher" for any bugs and such and it looks like the 106A4 Nehalem CPUs have such a bug that needs to be patched first before OS X can boot with said CPUs (thats a pretty interesting find in and of its self)
its why I was so admit that the BootROM get spectre patched microcode because several people where just saying "Oh the OS can do it whats the big deal?"
another example of this is 1067A Penryn CPUs without microcode theres a bug which causes you to lose support for a bunch of instruction sets one of which is needed for windows 8.1+ x64 to boot for example. (I actually wonder if this is why the MP3,1 is reported not to work with 1067A CPUs and if putting the microcode in would get em booting)
its also worth mentioning
Apple did NOT remove support for Bloomfield CPUs with the 0089 BootROM they only removed Microcode for the C0/C1 (106A4) stepping of Bloomfield CPUs
106A5 (D0) stepping Bloomfield CPUs are perfectly fine and are spectre patched, Remember several MacPro4,1 and 5,1 Mac Pros shipped with Bloomfield CPUs but every single one of those are D0, all production Xeon Bloomfield CPUs where D0 stepping it was only some of the i7s that where C0/C1
its also worth mentioning
QS CPUs Qualification Sample are generally always of a production stepping so those are fine in a Mac Pro
its the ES or engineering sample CPUs which can be of a pervious stepping and cause issues.
PS im pretty sure most if not all LGA1366 CPUs do TM2 it goes all the way back to the Pentium M days IIRC
I'm a little late to the party, but there is no need to run the installer when attempting to update the firmware using Apple's tools. You can bless a firmware file manually, and have the Mac boot from and attempt to update it using the commands outlined at https://duo.com/assets/ebooks/Duo-Labs-The-Apple-of-Your-EFI.pdf, page 18. I've successfully used this to manually update firmware if needed.
However, my testing seems to indicate that the updater checks to see if the firmware you are attempting to update to is more recent than the one currently installed, and only does the update then. Based on what I've tried, it doesn't go by file name or metadata - there must be a flag within the firmware itself. This would explain the crashes that Zeke D saw - the firmware updater loads, shows the Apple logo and a progress meter for a second, then powers off the machine if the firmware you are attempting to install is older than the one currently installed.
Dosdude's ROMTool doesn't perform this check, so allows you to replace the EFI with whatever version you like.
Incidentally, has anyone tried flashing the board with ROMTool then run blank board serialiser? Does that set the board's SN#, or just the system? Would be interesting to find out. I'd love to see a function added to Dosdude's tool that mirrored this functionality too - something that let me set the system serial, board serial and any other identifiers within the EFI!
However, my testing seems to indicate that the updater checks to see if the firmware you are attempting to update to is more recent than the one currently installed, and only does the update then. Based on what I've tried, it doesn't go by file name or metadata - there must be a flag within the firmware itself. This would explain the crashes that Zeke D saw - the firmware updater loads, shows the Apple logo and a progress meter for a second, then powers off the machine if the firmware you are attempting to install is older than the one currently installed.
Dosdude's ROMTool doesn't perform this check, so allows you to replace the EFI with whatever version you like.
Incidentally, has anyone tried flashing the board with ROMTool then run blank board serialiser? Does that set the board's SN#, or just the system? Would be interesting to find out. I'd love to see a function added to Dosdude's tool that mirrored this functionality too - something that let me set the system serial, board serial and any other identifiers within the EFI!
Yes, but it's a lot easier for someone who don't exactly know what is doing to just use the macOS installer.
Worked for a lot of people at the time of the 0087 microcode debacle. Just renaming 0085 to 0088. I've downgraded my two Mac Pros 4,1>5,1 at least 5 times, from 0087 to even 0084. For some people that just didn't work.
You have to add the corresponding FFs in the LOCKED.fd in the place that BBS expects, then it works. It's easier to get a working dump and change the SSN to FFs. That is only 1/3 of the problem, you still have to put SON and LBS and all the code that surrounds it, it's missing from LOCKED.fd, to correctly identify the Mac.
I'd be very nice and will do a big favor to people with corrupted SPI flash on Mac Pros.
Last edited:
Thank you for the in-depth response! I'm very comfortable with the command line so didn't see that as an impediment but I can see your point - it's very easy to mistype a command, and simply running the updater removes this barrier to entry.
My experience was limited to my MacBook Pro, so that could explain the differences in the behaviour. I must look in to this in more detail. I think I need ANOTHER Mac - just for testing, of course!