BIOS modding for GPU OC fun and profit!!

Pheonix BIOS Tool really makes this an easy process, just finished on my i5 540m + ATI 5730, 650/800 -> 830/1105. (Previously tested those values with S/W overclock) I haven't changed the thermal pads out for heatsink paste or removed the dust filter just yet, but GPU temps are 79-81 right now at prime+furmark load.

Of note: My BIOS Checksum came out lesser rather than larger in the end, so I had to change a different offset from the FF fillers at the end (You can't add anything to FF). Being familiar with C\C++ programming I found a string that references an .h file near the start, these strings aren't used during normal operation (just for debugging) so I changed a period in that string (0x2E) to a higher value (0x2E+0xCD=0xFB) which took care of the checksum.

I also used WinPhlash64 to flash (The PhoenixTool thread states "You can use winphlash for x32 (ensure Advanced=1 and Hide=0 in [UI] section of phlash.ini). Do NOT use winphlash for x64."). I didn't run into any problems using it other than having to untick the advanced options for verifying BIOS date/version. I did have to manually power cycle the machine after the reboot following the flash, the laptop hung. I think I recall that happening during the last normal update I did with WinPlash64 though.

In the end, it worked fine, the overclock works great in linux and the powerplay clocks are honored at idle.

Does anyone know if the VDDC reading in AMD GPU Clock Tool is accurate for the 5730? I did notice that using the S/W overclock it read 1.1V and using the BIOS overclock it reads 0.95V (same value it reads without the overclock, on stock bios)

I notice when the linux kernel boots with Intel IPS driver compiled in, that it reports the expected TDP value for the CPU is 35W, but the BIOS is overriding it to 25W (this affects the top end of turboboost negatively) - I wonder if we can tweak that similarly. Or if there's any other multiplier related options floating around in there.

 

If your BIOS is A10 or lower, and you have a 5730, then just run the .exe ant you'll be fine. It is perfectly safe for 99% of the 5730s out there, as it is a relatively mild overclock. The only way to know for sure is to download a software overclocking program like AMD GPU Tool, and try it out first.

Check out this thread for links to the tools, and testing methodology: http://forum.notebookreview.com/dell-xps-studio-xps/518711-xps-16-gpu-overclocking.html

 

That's an impressive overclock without any thermal mods, congrats! That's actually my exact same max clock using s/w. I can get the GPU clock up to 850 if I drop the memory down to 1050, but 830/1105 is actually faster.

My checksum was off as well, I just changed one of the blank spaces in the copyright string, figured nothing in there matters for anything.

The reason it shows up as .95v with the BIOS overclock, is that it is able do underclock/undervolt itself when not under high load, an ATI feature called 'powerplay'. When using a software OC powerplay is disabled. That is one of the advantages of doing a BIOS overclock (besides being more stable).

I don't get the TDP error booting into OpenSUSE, though I have the i7 (45w), and I've heard lots of people with the i5s complaining about the same thing.

I'm actually looking into the possibility of BIOS modding the CPU voltage to lower it, in an effort to reduce temps and fix the whole throttling thing on the i7s, but I haven't had much luck yet. I need to find somebody who knows a bit about the ACPI tables...

 

I imagine it's alot easier for the cooling system to handle it on a dual core rather than a quad core, so that probably accounts for not needing the thermal mods (yet, i'm in southern california and tested around 85F ambient temp, its known to get up to 115 down here at times, im sure i'll run into problems then.)

I think the only thing you'd have to be careful about changing in the copyright string is any character to a NULL (0x00) as that would indicate to the software that the string ends there, rather than where it used to end, which might cause some trickiness depending on the way it was programmed. (In my programming experience it doesn't matter though)

The reason I questioned the VDCC reading is that, at stock clocks w/high performance mode, and powerplay at maximize performance, under prime+furmark load it reads 0.95v. Using the SW overclock to 830/1105 changes it to 1.1v under load. Doing the BIOS mod it reads 0.95v under load, if I change the clocks even to the same clocks with AMD GPU Clock tool it reads 1.1v. The temperatures dont change from the SW OC to BIOS OC, and the max stable speed doesn't change. Usually with a voltage drop you would see lower temps and a lower top end OC, that's what makes me question if the reading is valid. I'll poke it some more if I get a chance

Re: The Intel IPS message, it's not an error but just a warning, shows up in the kernel output log (dmesg) and you'll only see it if you specifically compiled the Intel IPS driver into the kernel (Intelligent Power Sharing driver, intended to balance TDP/TDC load between the GPU core and CPU core on i5)

Since the i7 doesn't have the GPU core I don't imagine that option is turned on in the kernel by default. You'd have to enable it manually and re-compile. I would expect it to be set to an even more severe value on the i7 platform since the cooling design is unchanged between the two, but the i7 puts out a good deal more heat.

 

Oh, ok, I get what you mean now with the voltage. It does the same for me. I think that the AMD Tool doesn't read the actual voltage, it just shows you what it changes it to if/after you activate it. No other tools, like GPU-Z or Hardware Monitor, show you what the actual voltage is

 

FYI for vBIOS versions

For 1645, 5730: A07 - A10 are all 11/20/09 and A11/A12 are 7/25/10

For 1645, 4670: A07/08 7/28/09; A09 3/28/10; A10-A12 5/17/10

For any 1645 owners with the 4670 that want to keep the A09 vBIOS, it is possible to replace the A12 vBIOS with the A09 one, so you can get the other fixes in A12, while still keeping the non-throttling vBIOS.

Also, the only difference between the A09 and A10-12 vBIOS for the 4670 is a short string that changed from "66 03 57 6E 05 5F 73 07 64 78 09 14" to "55 03 4B 5A 05 50 5F 07 5A 64 09 14" If anybody is good at decoding stuff like this, we could determine why the first string throttles at 100C and the 2nd at 84C, and then we could set it to throttle at whatever you wanted.

The difference between the A07-10 and A11-12 vBIOS for the 5730 is a different story, as the change was significant. I mean over 75% of the vBIOS was changed.

 

Interesting idea, but I will stick with rivatuner since it works flawless for me.

 

Does this thread only apply to the 1645s?

 

Sounds good, I guess. Only thing that worries me is that the last time I remember looking around for BIOS mods, there was high risk involved with them, though I guess that may have changed over the years. In the case that my laptop ships with a11 or a12 bios, I'd have to downgrade. Is this safe, as well?

 

The modding method is specific to Pheonix/Insyde BIOSen, your 1647 has a Pheonix BIOS. So no, it applies to yours too. See my post a few posts up for my experiences on a similar system to yours. Note that I did the mods by hand using the tools, guides, and related posts to guide myself along to mod the original BIOS myself, rather than using a modded BIOS someone posted. In the end it works great

 

The contents of your post flew right over my head. Haha. Maybe I'll take the time to do some more research regarding OC. The good thing is that its about to get very cold over here in Chicago, which means VERY cool ambient temps, even in the apartment.

 

Let's see if I can't "laymanize" the process a bit. This post is a high-level overview of everything that follows in my post. My goal is to explain it as verbosely as possible without getting too technical. Read with coffee

The BIOS updater itself (In this case referring to the .exe file you download from dell) is a self-extracting .exe that puts it's contents in your computers %temp% folder when it runs. (%temp% is a variable that is different for each user on the computer, type it into windows explorer in the location bar and hit enter the same way you'd type C:\ to see where %temp% actually is)

The BIOS updater dell provides for the 1647 (probably 1645 too, but I haven't looked at one of those) extracts 2 folders, WinPhlash64 and WinPhlash32. It executes the updater .exe inside the folder that matches your operating system (in my case the one in the WinPhlash64 folder since i'm running Windows 7 Ultimate x64) -

This updater then loads the BIOS1.WPH file in the folder into your computers BIOS. Note that both WinPhlash32 and WinPlash64 folders contain a BIOS1.WPH, the file is identical. This file is the target for your modifications.

BIOS1.WPH can be thought of as another "container" similar to the self extracting .exe that held it. The tool seeker_moc linked earlier ( PheonixTool) handles the extraction of all the BIOS components, and later reassembly back into a .WPH after you do the modification.

After you "dump" the BIOS into its components using PheonixTool, you have to look inside the dump folder to find which file contains your video card BIOS. (there are seperate BIOSen for each component that the BIOS initializes, like ethernet, video, etc.) - In my case I used a program called EmEditor to search for a string of text in each file in the folder, all at once, using the "Find in Files" function. I searched for "MADISON" knowing that is the code name for the 5730 card. It was found in OPROM01.ROM in my case. So now I have the target file to modify. Copy the file out somewhere, as you will be modifying this, and want to preserve the original for later comparison.

Now you need to know the stock clock/memory speed for your card. In my case it is 650/800 for the 5730. Computers, however, generally don't store numbers in the way we are used to (which is base-10 notation) - in this case the number is stored in base-16 notation. So, you need to convert the numbers to base-16, in order to be able to find them in the BIOS with a hex editor, and change them to the values you desire. This post covers that process well.

You'll note in that post that ATI stores the clocks with 2 extra zeros at the end. So instead of 650/800 I was looking for 65000/80000. In my case we have 65000 (base-10) which, in base-16 is: FDE8. You can use an online converter like this to do the conversion. However, one more step is needed since the BIOS stores the value in 3 bytes (6 hexadecimal values) rather than only 2 bytes (4 hexadecimal values) like the online converter gave me. So we have to add a set of zeroes to that. (It would be similar to saying the number 200 as 0200, it's the same number, just added an insignificant digit to the beginning to fill up some space)

So, rather than FDE8 (2 bytes that equal 650) we have 00FDE8 (3 bytes that equal 650, the same value, we just added an insignificant byte to the beginning to fill in the space)

Now you do the same thing with the memory clock. In my case, 800, we add 2 zeros to it, and get 80000, then convert that to base-16: 13880. Note that again we need to add an insignificant value to this number to fill up the whole 3 bytes. In this case it would be stored in the BIOS as 013880 (we add the extra zero to the front of the 1 since a byte is always 2 hexadecimal numbers)

Now we have our clock speeds, 650 = 00FDE8, and 800 = 013880. You'll note also in Musho's post that ATI stores the values backwards in hex (this is typical for any program), so we need to reverse them. Rather than reversing it digit-by-digit as you would base-10 (54321 becomes 12345), we have to reverse them in pairs since bytes are always a pair of hexadecimal values. So 00FDE8 becomes E8FD00 and 013880 becomes 803801. This gives us the final string to search for in the BIOS using a hex editor: E8FD00803801

In my case I only found the string once. Now you need to do the same conversion process to the clocks you desire. In my case: 830/1105:
830 -> 83000 (add 2 zeroes) -> 14438 (in hexadecimal) -> 014438 (add the insignificant digit zero) -> 384401 (reverse it)
1105 -> 110500 (add 2 zeroes) -> 1AFA4 (in hexadecimal) -> 01AFA4 (add the insignificant digit zero) -> A4AF01 (reverse it)

So the string to replace is: E8FD00803801, and we are replacing it with: 384401A4AF01

Normally, that would be all you need to do. But there's an added step of making sure that the checksum comes out the same in the BIOS, in case the system verifies the checksum and PheonixTool doesn't update the checksum. (It would cause an error to be detected on boot time, corrupt BIOS)

The tool Musho recommends (Hex Workshop) has a feature to calculate the checksum of a file inside. So he calculated the checksum of the original file, and the checksum of his modified file. The checksum of the modified file was larger than the checksum of the original, so he needed to subtract that amount from somewhere in the file. At the end of the BIOS there's a bit of "padding" which is a term to describe "filler" data that exists to take up some space, but isn't really used for execution by the program. In essence that data is ignored. The padding is usually always a bunch of FF bytes, sometimes 00 bytes. Since he wanted to subtract, the FF bytes are perfect since FF is the highest value a byte can be. He subtracted 78 from FF which is 87 (note that this is base-16 math, not base-10), so all he had to do was change one of the FF's to 87. Then the checksum would match up.

In my case, my checksum came out smaller, rather than larger. That meant I needed to raise the value of a byte rather than subtract. Since FF is already the highest value a byte can hold, I couldn't add anything to that. So in my case I used my knowledge of programming to locate an insignificant string in the BIOS (something I could change without causing the program to react in an undesirable manner) - Near the start of the BIOS are a number of text strings that the BIOS uses to identify itself to the system. One of these refers to an .h file. The string ends in "Config.h" - the period symbol in this string is represented by the hex value 28. In my case, my checksum was smaller by the amount CF. So I added CF to 28 which gives you FD. So I replaced the period symbol (28 hex) with my new calculated value. (FD hex)

Now, done with the modifications to the ATI BIOS. The checksum matches the original one, so the BIOS won't detect it as being corrupted, and i've replaced the original clock speeds of 650/800 with my target clock speeds of 830/1105. Now I want to use PheonixTool to re-build the .WPH file, except with my new video BIOS instead of the original one. This post covers that process well.

That should give you a BIOS1_SLIC.WPH right alongside your original BIOS1.WPH that you gave PheonixTool to start with. This is your new, modified BIOS. You would drop that into the WinPhlash64 or WinPhlash32 folder (depending on which one matches your OS), delete the original BIOS1.WPH from there, and rename BIOS1_SLIC.WPH to BIOS1.WPH. Then run the WinPhlash(64).exe and click advanced, uncheck the boxes for "verify date" and "verify version" - change the path for the target BIOS to flash to match yours (it defaults to whatever path is set inside the WinPhlash.ini, in my case F:\SomeFolder\BIOS1.WPH which did not exist)

Then hit flash It should go, prompt you for a reboot at the end, and you're done! In my case my laptop hung after windows shut down and it went to reboot (I seem to recall WinPlash doing that with original BIOS updates from dell too) - so I just manually hit the power button and powered it back up a few seconds later. It booted up, and all was well

 

In simple terms yes, this thread applies to you, if you're looking to do it yourself. No, the pre-made modded BIOS that I posted in the first post will not work for you (1645 w/ 5730 only).

If you don't feel comfortable doing this yourself, and you want us to make one for the 1647, just give me the clocks you want and your .rw file (instructions earlier in the thread) and I'll make it. It is fairly easy to do yourself if you wanted.

 

There's always a risk when flashing any BIOS (modded or not), but it's very minimal. That said, I've flashed BIOSes probably about 100 times on 10 different computers / video cards, and have never had a problem. Also, the XPS 16 has a built-in BIOS recovery ability, so even if you brick your laptop, it's fairly easy to recover it.

 

@Da_G
Holy crap! I actually read all of your post and I understand the "theory". Thank you very much!

@seeker_moc
That'd be awesome! I downloaded the RW Everything app but cannot locate the ACPI button! v1.4.7

 

While I'm here...

Win7 x64, Dell A10 BIOS.

I assume I can "restore" stock settings by just reflashing with a Dell BIOS?

How can I tell the new BIOS works?

As far as clock speeds, I'll stick with what you posted in the OP... 750/1000. I don't game too much but I'd like to see if this'll allow me to run SC2 at higher resolution and/or settings.

 

From your sig, it seems that you're using a 1647. The BIOS posted here is for 1645's, which would probably cause problems for your system.

 

You're correct... which is why seeker_moc posted the above

 

Yes, reflashing with the standard Dell BIOS will put everything back to normal.

Run GPU-Z, it will tell you what the clocks are after the flash.

 

This would be wonderful if you could manage it, im sure the many 1645 4670 owners would much appreciate it

 

Ahhh I was looking at that before... in my version of RW, its called ACPI Table. PM sent.

EDIT. Nvm uploaded RW file here as a zip file.

 

Modded BIOS added to first post. Enjoy

 

Wow that was extremely fast! Trying now.

Success!

 

Modded BIOS added to first post. Please, let me know how it works.

 

Thanks alot, seems to work as expected... so far.

VBIOS version in ccc says

BIOS version 011.022.009.003
BIOS part number BR036993-001
BIOS date 2010/03/28

 

This is a great thread.. haven't tried it myself yet (interested about the A12 BIOS with A09 vBIOS).

Maybe the OP could look up the BIOS recovery thread from somewhere here and attach it as a link.. just incase anything goes wrong, it should be recoverable via that same method..

add:
This is the original post I think (at least the one I found), but the link to the ZIP doesn't work anymore:
http://forum.notebookreview.com/dell-xps-studio-xps/451601-bricked-xps-1645-help.html#post5749174

That file is still here (flash tools and the crisis recovery):
http://forum.notebookreview.com/del...p-downgrading-your-1645-bios.html#post5734472

 

Awesome, it worked then, as the standard A12 4670 vBIOS is dated 5/17/10

 

just for the hell of it, i tried OC'ing my 5730 using the AMD GPU tool. i set it at 750/1000 and ran 3dmark in the background of my machine for a few hours solid. didn't notice anything (though my machine was a little bit laggy while i was using it). GPU-Z says that my max temp was 70.5C (with cooler and screen closed). that's a whole half degree higher than my original temperatures before OC'ing....

i take it that i can handle the modded BIOS without any problems?

 

Yeah, you should have no problems at all. The 5730 takes to OCing very well, even when boosting my clocks up to 830/1105 I only have a 3C difference from stock clocks. If anything your temps with BIOS OC will be lower than with a software OC, as the GPU will still downclock itself when not running at max load, something it won't do with a software OC.

 

Been doing some further studying on potential BIOS mods yesterday, I tried re-compiling the DSDT after dumping it from the BIOS (using the kernel in linux, but RW Everything outputs the same thing)

Upon trying to recompile it, I noticed a handful of bugs in the stock BIOS! It took quite a bit of reading of the official ACPI specifications, but it's very well written, and I've got those bugs fixed up now, by changing it to meet the spec (several of the issues were with how the system describes the virtual usb ports the bluetooth chipset creates to allow bt mouse/kb control prior to the OS booting/bt stack loading) What i'm really looking for in here is how to bump up the TDP/TDC values to allow some more headroom for turbo boost (since judging by the intel_ips driver reports, somewhere in the BIOS the chips TDP is being overridden to lower it as I mentioned before)

There are also functions in here to determine the temperature levels that the fans are kicked on to intermediate, high, or passive, which might be useful to tweak. I'm sure there's many more interesting things, the specification is 720+ pages, still reading

I'll try out the fixed up DSDT after I add the _BQC function (I noticed the linux ACPI backlight driver reporting that the BIOS is missing the _BQC function, which tells the system the current backlight level, so linux can set the backlight level but it isn't ever aware of what the current one is, it just guesses as to what it was last set at) - From what i'm reading Windows is much more leniant with BIOSen that don't quite meet the specification and so that bit works fine.

Fortunately the linux kernel allows a software-override of the DSDT by either recompiling the kernel or setting up an initrd/initramfs - so I don't have to mod the BIOS each time I make a change. I have my bootloader set up with an easy menu to boot a known good kernel in case I break it too. That makes the fiddling much easier

Errors I ran into on the stock BIOS:

Code:

DSDT.dsl  4119:                     0x00000000,         // Length
Error    4122 -                               ^ Invalid combination of Length and Min/Max fixed flags

DSDT.dsl  4133:                     0x00000000,         // Length
Error    4122 -                               ^ Invalid combination of Length and Min/Max fixed flags

DSDT.dsl  8696:                             Name (_PLD, Buffer (0x10)
Error    4080 -              Invalid object type for reserved name ^  (found BUFFER, requires Package)

DSDT.dsl  9512:                             Name (_PLD, Buffer (0x10)
Error    4080 -              Invalid object type for reserved name ^  (found BUFFER, requires Package)

DSDT.dsl  9529:                             Name (_PLD, Buffer (0x10)
Error    4080 -              Invalid object type for reserved name ^  (found BUFFER, requires Package)

DSDT.dsl  9546:                             Name (_PLD, Buffer (0x10)
Error    4080 -              Invalid object type for reserved name ^  (found BUFFER, requires Package)

The first 2 are memory allocation errors, they are intended to allocate a block of memory of size xxxxx, and instead allocate nothing. I didn't yet pay attention to what particular function those memory blocks belong to, just fixed the allocator to actually allocate the memory. The other 4 errors are descriptors for the USB ports (EHCI Bus 1: Port 2, EHCI Bus 2: Port 1, Port 2, Port 4) - Those errors are in non-critical fields used to describe the physical location and size of the ports on the machine. ( Section 6.1.6 Page 203 _PLD definition)

 

Awesome, Da_G, this could really go a long way to improving our systems. Could you send me a link to the resources you're using in your research?

 

This one was helpful to understand the memory allocation errors:

InsanelyMac Forum > DSDT disass+compile: newer IASL=less compile errors+more opti

Google for "DSDT" and "DSDT -mac" (to drop the mac os x specific pages, which make up a large amount of them, people trying to get the ACPI BIOS compliant to work with "Hackintosh")

Using the iasl compiler/decompiler to dump/rebuild the DSDT picked up several pages of warnings/errors, many of those weren't found googling around so I referred to the ACPI specification in that case. Usually the error was something simple like the spec is expecting a package containing several buffers, but the dell BIOS instead is returning only a single buffer.

The specification covers what each function does, and the expected return values really well, so I plan to give the entire DSDT a once-over with my eyeballs using the ACPI spec as a reference to ensure compliance. Unfortunately the DSDT serves as an intermediary layer between the OS and the BIOS assembly code, so in many cases the most you can do is supply a workaround to meet the spec rather than making the function actually operate 100% what it's supposed to do (since the function doesnt exist in the ASM part) - but even that's much better than it not meeting spec

The ASL is psuedo-c code, so being familiar with C will help alot to understanding the layout.

The linux kernel also provides a number of useful diagnostic messages:

Code:

daglaptop64 linux # dmesg | grep ACPI
 BIOS-e820: 00000000bf470000 - 00000000bf4f1000 (ACPI NVS)
 BIOS-e820: 00000000bf77e000 - 00000000bf79f000 (ACPI NVS)
 BIOS-e820: 00000000bf7e2000 - 00000000bf7ff000 (ACPI data)
ACPI: RSDP 00000000000f70f0 00024 (v02 PTLTD )
ACPI: XSDT 00000000bf7f3e42 00064 (v01 DELL    QA09    06040000  LTP 00000000)
ACPI: FACP 00000000bf7e4000 000F4 (v03 INTEL  CRESTLNE 06040000 ALAN 00000001)
ACPI: DSDT 00000000bf7e5000 0ACB4 (v02 Intel  CALPELLA 06040000 INTL 20060912)
ACPI: FACS 00000000bf79bfc0 00040
ACPI: HPET 00000000bf7fecfa 00038 (v01 INTEL  CRESTLNE 06040000 LOHR 0000005A)
ACPI: MCFG 00000000bf7fed32 0003C (v01 INTEL  CRESTLNE 06040000 LOHR 0000005A)
ACPI: APIC 00000000bf7fed6e 00084 (v01 PTLTD  ? APIC   06040000  LTP 00000000)
ACPI: BOOT 00000000bf7fedf2 00028 (v01 PTLTD  $SBFTBL$ 06040000  LTP 00000001)
ACPI: SLIC 00000000bf7fee1a 00176 (v01 DELL    QA09    06040000  LTP 00000000)
ACPI: OSFR 00000000bf7fef90 00070 (v01 DELL   DELL     06040000 ASL  00000061)
ACPI: SSDT 00000000bf7e3000 009F1 (v01  PmRef    CpuPm 00003000 INTL 20060912)
ACPI: Local APIC address 0xfee00000
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x04] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x05] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a201 base: 0xfed00000
  #5 [0000003000 - 0000007000]     ACPI WAKEUP
ACPI: Core revision 20100702
ACPI: bus type pci registered
ACPI: EC: Look up EC in DSDT
ACPI: BIOS _OSI(Linux) query ignored
ACPI: SSDT 00000000bf71a918 00432 (v01  PmRef  Cpu0Ist 00003000 INTL 20060912)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT (null) 00432 (v01  PmRef  Cpu0Ist 00003000 INTL 20060912)
ACPI: SSDT 00000000bf718018 008B0 (v01  PmRef  Cpu0Cst 00003001 INTL 20060912)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT (null) 008B0 (v01  PmRef  Cpu0Cst 00003001 INTL 20060912)
ACPI: SSDT 00000000bf719a98 00303 (v01  PmRef    ApIst 00003000 INTL 20060912)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT (null) 00303 (v01  PmRef    ApIst 00003000 INTL 20060912)
ACPI: SSDT 00000000bf717d98 00119 (v01  PmRef    ApCst 00003000 INTL 20060912)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT (null) 00119 (v01  PmRef    ApCst 00003000 INTL 20060912)
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62
ACPI: Power Resource [FN00] (off)
ACPI: Power Resource [FN01] (off)
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-fe])
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP04._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP05._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP06._PRT]
ACPI: PCI Root Bridge [CPBG] (domain 0000 [bus ff])
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 *5 6 7 10 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 *7 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 11 12 14 15) *10
ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 10 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 7 10 12 14 15) *11
ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 5 6 7 *11 12 14 15)
ACPI: WMI: Mapper loaded
PCI: Using ACPI for IRQ routing
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
ACPI: AC Adapter [ADP1] (on-line)
ACPI: Power Button [PWRB]
ACPI: Sleep Button [SLPB]
ACPI: Lid Switch [LID0]
ACPI: Power Button [PWRF]
ACPI: Fan [FAN0] (off)
ACPI: Fan [FAN1] (off)
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
ACPI: Video Device [M86] (multi-head: yes  rom: no  post: no)
ACPI: acpi_idle yielding to intel_idle
ACPI: Thermal Zone [TZ00] (27 C)
ACPI: Thermal Zone [TZ01] (0 C)
ACPI: Battery Slot [BAT0] (battery present)
tg3 0000:09:00.0: wake-up capability enabled by ACPI
ACPI handle has no context!
ACPI handle has no context!
ACPI: Preparing to enter system sleep state S3
ACPI: Waking up from system sleep state S3
tg3 0000:09:00.0: wake-up capability disabled by ACPI

One interesting thing is that the Thermal Zone 00 and 01 always report 27c and 0c, respectively. These are supposed to be thermal triggers for events in the ACPI code (i.e. when TZ01 is higher than 45c, trigger passive cooling through enhanced sleep states, higher than 60c, trigger intermediate level fan speed, higher than 80c, trigger high level fan speed, etc)

Dell may have implemented those features outside of ACPI's control (since the system seems to control the fan as expected) and these values are just dummy values. It'll take alot more reading for me to figure that out

 

Hi all,

I just got home a short while ago, to find Windows 7 waiting for me with a "Windows just recovered from a system crash" dialogue box. Under the Problem Reporting window, I have these details:

In the WERInternalMetaData.xml file that accompanies the system crash log are these details: (formatted the original text since the forum doesn't like to post XML in its own formatting.)

what caught my attention was that the system still thinks I am running BIOS A09, when in fact I upgraded to seeker_moc's modded A11 with the OC'd GPU values.

any idea if this crash is due to my installing the modded BIOS, or just a general crash? i haven't had a single crash since receiving and fresh-installing Win7 Ultimate, so my first thought was maybe the modded BIOS. I almost never have crashes in general so I'm just trying to pinpoint the cause, but i'm also not trying to say that the modded BIOS is faulty.

 

Strange. It could just be something random. I'd leave unless it happens again. If it does, try going back to the standard BIOS. If not, then it's just random computer magic.

 

i was thinking the same thing too. i played my first multi-hour gaming session (probably 4 hours?) the other night, on L4D2 (just bought it) with some old friends, but i didn't suffer any strange artifacts or glitches. that i think would be enough to put the modded BIOS and GPU through its paces and force any major problems to rear their ugly heads.

i think that it's a random occurrence as well, but i wanted to check to see if anybody else had come across this as well, at least with the modded BIOS.

 

What does CPU-Z tell you the BIOS version is?

 

shows that i'm running A11, as it should

 

Hey seeker, thanks so much for you contribution here. I'm definitely going to use the A12/A09 bios combo you've put up...but was just wondering before I do that, whether there is still any potential for 4670 users to have a A12 bios/A09 vbios combined with a slight overclock as well? Or is it just too hot stock?

 

Try it out yourself (try Rivatuner before BIOS mod). The OC only makes a little difference in temp. I was able to increase GPU performance by 20% by bumping the core and clock by 20%, with pretty high stability. (Be careful.)

I think I was 100% stable at 800/925. Everyone's is a little different, so you really should find the right values before doing a BIOS mod.

 

Just tell me what clocks you want and I can make it. It only takes a minute to do.

 

Great job with the BIOS work, I will definitely take a look at it...my laptop is currently waiting for me at home(just got here today!)

Been out of the computer world for a while (Marine Corps/ bought a Subaru STi) but jumped back into it buying a 1647. Hope to have a good core for OC'ing, but we all know that is as stated before a total "crapshoot"

I only got a i5, I have no real need for the i7 so I hope to keep my temps down. I need to edit my sig...just too lazy right now

Did you guys just optimize the original OS or did you perform a clean install?

 

Random... but could I talk you into making a BIOS that underclocks? I never game, I use this for simulation modelling using ANSYS and C++ code. I have upgraded to the bigger battery, and replaced the hard drive with an x25-160g2 and still the battery life is terrible.... I would love to have the gpu stay lower, I used rivatuner with some success at this, but its annoying to have to remember to use it all the time.

I would LOVE something that keeps it clocked low!!!

 

Unless you change the voltages, you won't get much of an improvement.

 

What's your system, 1640, 45 or 47? What GPU do you have, 3670, 4670, or 5730?

 

Xps 1645, Ati 4670

Xps 1645, Ati 4670

 

In the 1645/4670/A09 BIOS, the possible clock/memory/voltage combinations are:

220/300/0.9
300/300/0.9
300/500/0.9
300/400/1
450/600/1
300/800/1.2
400/800/1.2
675/800/1.2

The BIOS selects from these possibilities depending on GPU load, power play setting, and whether plugged in or on battery. I don't know how to change the logic of which option the BIOS picks, but changing the values themselves is easy.

Let me know what you want to have changed to what.
Voltmods are easy to do, but there's no way to test them beforehand, so you will be assuming some risk to try it.

 

Im confused, I havent modded anything. Ive used riva tuner to clock down to 180/250/0.9 but thats the lowest ive done.

So couldnt you just make it stay at say 220/300/0.9 and not move? Will that help out or do I need to undervolt as well?

 

Yes, I could do that. Or you could pick two, say 220/300/0.9 for most of the slots, and 450/600/1 for the 675/800/1.2 slot. That way it will still give you a small boost when performance is required, but will stick to the lower clocks for most possibilities. It would reduce temps (by keeping them from ever increasing), but you'd have to use the clock tool to overclock for any situation where you need more power.

Undervolting would further lower temps, but I can't promise you that anything less than 0.9 will be stable, so you'd be testing something in unknown territory.

 

For those curious, all the stock possibilities for the 5730 are:

100 150 0.9
100 300 0.9
300 300 0.9
375 400 0.9
400 800 0.95
450 800 0.95
550 800 1
650 800 1.1

 

Id love that. 220/300/0.9 low, and the higher one you recommended. So you could set it that it wouldnt ever really jump to the higher one on its own, and I could spice it up if I needed to?