So have Intel ratified a 10.5.x ICH9R firmware?
The latest ASUS provided me with for my RE was 10.1.x?
Must admit I am curious to see how they perform with the new 10.6 WHQL Matrix Storage Manager.
John
Printable View
So have Intel ratified a 10.5.x ICH9R firmware?
The latest ASUS provided me with for my RE was 10.1.x?
Must admit I am curious to see how they perform with the new 10.6 WHQL Matrix Storage Manager.
John
AFAIK, the most reliable updated O-ROM to date is 9.6. Newer versions on X38/48/P45 chipsets just don't seem to work right.
Than we must be very lucky because it seems to work fine with Windows 7 X64 and Ubuntu 64 bit.
You know a lot about modding a BIOS. Is there anyway we can fix the BITS MSR fails or are we screwed when ASUS doesn't want to fix it?
I tried both configured as IDE and AHCI and I didn't have any problems.
Same way i did it, i could even get into the config witch ctrl+l, setup raid, etc, but just 1 sec after i exit it hangs
Tried with ezflash and afudos /pbnc /n
I will try again - removed oem logo and nic oroms, i suspect that my lsi 9260 could intefere with this new intel orom coz its size is bigger than 10.0.x
I can confirm that BIOS update from SoLoR works for me, no issues here. I am using RAID0 aswell. But I haven't tried to edit/change my RAID0 array in the BIOS.
I'm also using the newest Intel Chipset & RST drivers in Win7 x64.
Have you tried to reflash?
Alien,
I'm using the OCZ Vertex II 240 GB SSD and Seagate Momentus XT 2TB with the X48 RF. Used Acronis to image my W7 Prof 64 to the SSD and have cold boot error ever since. OCZ said the only solution is to do a clean install, no imaging. Got a replacement from Amazon and it did the same thing. If you're willing to reboot on cold startup everytime, it's very fast, otherwize I'd pass unless I was doing a clean install. Also, Vertex III is a waste on X48 since it only supports SATA 2.
JBJ
I'm using Ghost to make my backup images and I didn't have a problem to restore my backup images on my OCZ Vertex 3. I don't think that an OCZ Vertex 3 is a waste. I see it as a good investment for the future.:D
A waste is buying a cheaper SATA 300 drive to use on a SATA 600 board.
I've tested both drives with EVEREST Disk Benchmark.
http://i431.photobucket.com/albums/q...kBenchmark.jpg
Since i see you still try to access moded bios on that address i gave before, i want to tell you i moved it to here
@Alien Grey
Aida64 is "new" Everest...
My first experiences with the OCZ Vertex 3 and the ASUS Rampage Formula.
Getting the drive to work on the ASUS Rampage Formula isn't a problem. A big minus is trying to update the firmware. It isn't possible to update the OCZ Vertex 3 firmware when it's your primary drive.:confused: That's a big problem because for most users if not all users it's the primary drive.
I've tried a few Windows boot cd's but it didn't make much difference. Then I've found on the OCZ forum a set of Linux tools to make an USB boot drive with everything necessary to update the firmware. With these tools it was possible to update the firmware but it wasn't easy. When I tried to update the firmware it wasn't possible because the drive is locked. Unlocking the drive isn't difficult you would think because there's also a tool available to let the computer go in to sleep mode. Than you wait a few seconds to make the computer wake up again by pressing the power button. A big problem on the ASUS Rampage Formula because when the board tries to wake up from sleep mode it fails to do that and reposts.
If that doesn't work than there's always the hard way. Disconnecting the power from the drive and wait a few seconds before reconnecting it again to unlock the drive. This sucks when it's hard to reach the power cable.
Finally. It's now possible to update the firmware. Great but not so great. To update the drive with the latest firmware you've got to edit a file so you don't end up with an older firmware like me. Great now you can do the whole hassle again.
After a few hours, I'm using the latest firmware which results in a performance decrease and a broken side panel fan that can't be fixed from all the hassle trying to update the firmware.:shakes:
Hello everyone,
please, what's the difference between 1002b-R0.zip and 1002b-R1.zip ROM files?
I have appreciation for SoLoR's work since his Creative X-Fi modded drivers!
Thank you :clap:...
LE: Think it's the old BIOS, judging by it's build date...
R0 is old, with jmb 1.08.01 and intel 10.1.xxxx, R1 is new with jmb 1.07.27 and intel 10.5.1.xxxxx
Would be cool if there was someway to fix the BITS errors and the SMI Latency as ASUS support really just do not care.
I appreciate that our boards (Rampage Forumla and Rampage Extreme) are long in the teeth now and are perhaps just out of the 3 year support period... BUT surely it is not unreasonable for ASUS to release the source code when products reach EOL.
That way developers can address any bugs which may still be in the code, or develop custom BIOSes which get the best out of our boards.
It just feels "selfish" that we spend out on the hardware, only for the firmware to let us down.
John
Can you sum up what the problem is (to the end user noticeable), when BITS errors and SMI Latency present?
My 0x124 BSOD are still here and i will low my overclock once more (CPU only), unless BSOD is related to these 2 things.
Hey guys, wanted to get your input on this BSOD (code 0x124) I got yesterday...
Less than one year ago I moved into my current apartment which isn't air conditioned besides my crummy window unit. Due to the heat in the US right now my A/C unit is barely able to keep ambient temps below 80F (27C). I seem to recall reading somewhere that the rampage formula will randomly BSOD once the ambient temps get up high enough, and I was wondering if anyone can confirm. I have passed hours of memtest, prime, linx, run heaven/3dmark, and the evga oc tool for stress and none of them have made me BSOD, but that was in the winter with ambient temps around 65-70F (18-21C). I've checked operating temps and even with the heat my CPU tops out around 55C under gaming load - lapped and have push-pull washermod TRUE. My gfx cards top out around 60-65C.
Basically is this just crashing due to the freak heat wave or is it possible I'm seeing some processor degradation? Is it likely that the component failing is infact the motherboard since my cpu and gpu temps are pretty well under control? I've been running 3.6 GHz for about two years at this point but I did upgrade from 4GB to 8GB ram this past winter and upgraded from gtx 280 to gtx 470 sli. If it is just due to heat am I better off not using the computer for gaming until after it passes (do I risk degradation due to more extreme operating conditions)? Any suggestions?
Thanks in advance.
EDIT: more details:
CPU: 400x9, 1.525V bios, 1.504V real, LLC enabled
other settings: CPL 7, FSB strap 333, nb: 1.41V, vtt: 1.34V, 100ps delay on cpu and nb
DRAM: DDR2800, 4-4-4-12, 2.2V bios
gfx cards at stock speeds atm
It's possible that the MSR fails and bad SMI Latency are causing these 0x124 BSOD. To know that for sure you would need a BIOS without the MSR fails and better SMI latency and that's impossible because ASUS doesn't want to fix it although it's a compatibility issue. It's the ASUS support at it's best. They also promised a few times on the XS forum to update the Option ROMs in their BIOSes but that was also a long time ago.
Very strange. I'm doing great with that BIOS. No issues with Windows 7 X64 or Ubuntu 64 Bit.
Ubuntu Disk Benchmark
http://i431.photobucket.com/albums/q...-Benchmark.jpg
The OCZ Vertex 3 likes this board and BIOS. The drives speed is limited because of SATA 2 but it runs without issues and that can't be said by everyone with different boards.:D
Don't worry it's probably because of the higher room temperature. I also had to go back to CPU Clock Skew Delay 200ps and NB Clock Skew Delay 100ps and bump the NB Voltage a notch to keep everything stable. I would also need more CPU Voltage to keep Prime95 running without BSOD but I don't care much about it as long as she's running BOINC stable in Ubuntu.
But all Bioses have these issues,right? 0902 had no issue for almost a year with higher clocks than i am using now with latest SoLoR modded.
I will lower once more Core MHz and keeping same voltages, because once i did that the BSOD were less frequent. (9x450 went to 9x445)
i cant even make it that far. My boot drive is an array of 3 intel 40GB ssds. The raid controller is crapping out on boot so no OS for me. it appears that it could still boot from an external device, but all the internal drives just wont show up. But they are listed when the raid initializes. Thats when it locks up though.
Yes, all BIOSes have these issues but all BIOSes also trigger the 0x124 BSOD. The 0x124 BSOD is a genuine MACHINE_CHECK_EXCEPTION BSOD. It's a CPU malfunction. That's all what I could find with debugging the minidump.
This is what Intel has to say about this issue.
Hmm... "Missing proper microcode...".:rolleyes:Quote:
Potential Causes for Machine Check Exceptions
MCEs are difficult to debug mostly because of the large number of potential
causes. Some of the potential factors are:
• Violations to board design guidelines. For example, routing traces over
power and ground planes may cause unwanted noise and inadequate
signal spacing may cause signal integrity issues.
• Operating the processor out of specification. Examples include over-
clocking of the CPU and front-side bus speeds. The behavior of the system
cannot be predicted when the processor operates out of specification.
• Environmental factors, such as: alpha particles or cosmic ray hits,
extremely hot, and cold temperatures.
• Improperly fitted heat sinks or fans and incorrect hardware installation.
• Missing proper microcode updates that could contain fixes for known
processor errata.
• BIOS setup issue or OS issue may cause MCE handling scheme to behave
differently.
• Faulty components, such as: add-in cards, DIMMs, etc., can also cause
system errors that may eventually lead to a MCE.
Maybe this raid isue is already fixed in version 10.6.x.
I have done myself minidump debug also.
Sometimes it is VGA related or so (dgmms something at stack) and other times no possible explanation.
All are VISTA_DRIVER_FAULT for sure, but no particular process is repeated at stack trace