Jump to content

AngieAndretti

Registered User
  • Posts

    50
  • Joined

  • Last visited

Everything posted by AngieAndretti

  1. I have two nVidia 1070 MXM cards, one with G-SYNC and the other without but otherwise identical - but because of G-SYNC their device ID's don't match. G-SYNC=1BE1 and NO G-SYNC=1BA1. I'd like to force-flash one of the cards to match the other for the purposes of running SLI without software-level hacks. I've read about others force-flashing 1070's using other SPI Programmers like the SkyPro II but I do not own one. I do own a Raspberry Pi 3 Model B, which I've successfully used as an SPI programmer in the recent past. Problem I'm having is that my 1070 uses a Macronix MX25U8033E chip for VBIOS and this isn't explicitly listed as something supported by the flashrom software. I do know that the 8033U is a 1.8v chip from reading its datasheet, so I cannot use the 3.3v output from the Pi to power the chip as I did with my other flashing experiments, so I connected an external DC power supply to send 1.8v to my chip clip and passed the other pins through to the Pi as normal. Unfortunately flashrom sees no chip connected so I cannot read nor write. Any ideas? Yes I can purchase a SkyPro II if absolutely needed but I'd really love to get this working with the Pi!
  2. Some Successes! Thanks a lot for making me look into this deeper, Qon. I had originally tried something similar without success: I set a negative offset within the OS, at first using Intel XTU, as I find it preferable to the Sager control center software and as I said it would work UNTIL I'd reboot the system. Upon reboot, BIOS would immediately powercycle the system and change that negative to a positive value along with changing the CPU PL1 and PL2 limits to very low values, about 30w limit. When the system then got into Windows, I could see in XTU that we were now running a positive overvolt and this was confirmed with HwInfo64 - the CPU was truly getting more voltage rather than less. I did try that same process once with Sager's control center before my first post and I initially got the same result, but your post made me check deeper... After reading your suggestion that it actually might be possible to get this working, I tried setting a negative offset again using the Sager software but I noticed something strange: When I clicked "Save" after selecting the undervolt, the Save button remained highlighted as it seems to do when it's trying to indicate that there are unsaved settings being displayed. So I clicked it a second time and only then did it become gray, likely indicating the settings had in fact saved. Upon reboot the machine still powercycled that one first time and BIOS did still display a positive offset value but the PL1 and PL2 values remained untouched this time and now when booting to Windows, we actually hold the correct undervolt despite BIOS displaying the positive value. So the takeaway for others is this: If you're having this issue with CPU undervolt not sticking or getting inverted to a positive value when setting it in Sager's Control Center, try clicking Save a second time after selecting your preferred settings, or until the Save button returns to being gray. Now regarding the "Lazy VSYNC" issue I mentioned in which framerate often dropped notably below the chosen refresh rate without the CPU or GPU indicating that they were being taxed significantly at that moment. I don't know for sure if this is a Pascal-specific issue but I can say the same games that exhibited this issue played flawlessly with the same nVidia driver versions installed on my Maxwell-based laptop. I did a lot of tinkering with nVidia Profile Inspector (v.2.1.3.4) and I found the following settings to be a near-perfect fix, at least in the games I was having issues with: Variable Refresh Rate: 0x00000000 VSYNCVRRCONTROL_DISABLE Framerate Limiter 2 Control: 0x00000002 PS_FRAMERATE_LIMITER_2_CONTROL_AVOID_NOOP (or) 0x00000011 PS_FRAMERATE_LIMITER_2_CONTROL_DEFAULT_FOR_GM10X (depending on game) Frame Rate Monitor: 0x00000010 PS_FRAMERATE_LIMITER_GPS_CTRL_TARGET_RENDER_TIME_SHIFT Frame Rate Monitor Control: 0x0080F364 PS_FRAMERATE_MONITOR_CTRL_VSYNC_OPTIMAL_SETTING Note these settings are to be used in conjunction with VSYNC ON, as the issues I was having were specific to VSYNC being ON. These settings also work great with Power Management Mode set to "Optimal Performance" (Profile Inspector) = "Optimal Power" (nVidia Control Panel) which allows the GPU to only clock up as high as it needs to in real-time. They in fact work far better than simply setting Power Management Mode to "Prefer Optimal Performance" which tends to keep the GPU clock rate high at all times, which I find very undesirable on a laptop. I also found the answer to my #4 quirk, in which only the 120hz internal display setting could be used as a template for creating custom refresh rates in between 60 and 120hz. It was because the native 60hz configuration, for some reason, had about 1,000 extra "total pixels" programmed onto the back end of the vertical refresh in the display timings, leading to the 60hz pixel clock being the same as the 120hz pixel clock. Don't ask me why they did that, but if you try to increase the refresh rate using the 60hz template, you end up with a pixel clock that's too high and out-of-range... unless you reduce the "total pixels" vertical setting in the display timings to a lesser amount.
  3. I've recently purchased Sager's new P9872-S laptop with Intel i7-6700K unlocked CPU and a single nVidia 1070 XMX GPU. Let me say that overall I absolutely LOVE this new machine, but I've discovered some strange hardware/BIOS type quirks that I'd like to discuss here. Note: I don't see a version displayed in my BIOS, but HWINFO lists a BIOS date of 10/19/16. The CPU is unlocked and supports overclocking. The stock BIOS also has a section for CPU overclocking. My CPU is quite happy running a moderate 4.5GHz OC across all cores with a 70mV undervolt (offset mode.) Yes it'll do the same clock at stock voltage but I've found that many Skylake CPU's do not need such high voltage as Intel has programmed them for - and my temps run much lower with the undervolt. So I set the undervolt with Intel XTU (I've also tried doing the same with Sager's own utility) and it runs beautifully until I reboot the system. At POST, BIOS then seems to reject the undervolt, forces a power-cycle, and sets CPU PL1 and PL2 power specs to very low "safe" levels. It also changes the negative voltage offset to a positive 70mV, indicating that it's trying to "error correct" the negative value. BIOS itself specifies a valid range of -500 to +500mV for the voltage offset here, and I can change it directly within the BIOS (and then it DOES actually stick through future reboots) but the BIOS does not allow me to enter a negative value here! Instead of -500 to +500, the actual values it allows for entry are 0 to +1000! And no, +500 does not actually equal zero, tried that and it really is +500. Also of note, I can change any multipliers in XTU or Sager's utility without the BIOS objecting but *any change* to the voltage offset gets rejected at reboot - even +1mV. Even applying +1mV and then immediately applying 0mV in either utility gets rejected on the next reboot so it's as if some checksums or something are not calculated the same way by XTU as they are by BIOS, causing a rejection of *any* voltage offset modification made by a utility rather than BIOS itself. Initially I set all my CPU core multipliers to 45x and all was good. Soon I noticed that any time I put the computer to sleep or hibernate, it would limit core speed to a maximum 42x after recovering, despite still reporting 45x as the CPU maximum. I tinkered with it for a while and eventually tried different values. Now I have ONE CORE multi set to 46x and TWO, THREE, and FOUR CORE multi set to the original 45x. That shouldn’t make a lick of difference versus 45x across the board but it does! 46, 45, 45, 45 sticks properly through sleep and hibernate; Weird right? I’m fine with the current settings as an effective workaround but I feel it’s still worth noting here. The VSYNC seems "lazy." I know this may be a driver or settings issue, rather than true hardware quirk, but it really bothers me - and the same behavior exists with nVidia drivers 368.xx to 373.06. Take Dirt Rally for example; I want it to run with VSYNC ON at 1080p, 90Hz. If I turn VSYNC OFF, my average framerate is about 200Hz, and never falls below about 110Hz, but with VSYNC ON it keeps dipping momentarily below 90Hz and skips frames! In a fast-motion racing game this is very distracting! I've observed this same behavior with the internal LCD and with my AOC 144Hz gaming monitor connected via DisplayPort. With VSYNC OFF, even with framerate limiter set at or just above my refresh rate, the game looks terrible so this is not an acceptable workaround either. Yes, the reported refresh rate is on target without VSYNC but there's terrible tearing and stutter. I've never experienced this kind of VSYNC dysfunction before; any thoughts? I have the 1920x1080 120Hz LCD screen. I wanted to set a couple custom refresh rates in nVidia Control Panel for racing games that really stress the system at 120Hz but I still want more than 60Hz. If the LCD starts out set at 60Hz and I test a custom resolution of 1920x1080 at, say, 90Hz, the screen goes kaput until it reverts back to 60Hz. However, if the screen starts out set at 120Hz I can then create any custom refresh rate in between 60 and 120Hz that I want. I wouldn't bother trying to fix this one as there's a perfectly functional workaround - it's just weird to me that starting frequency matters. Any thoughts on these quirks are welcome, and I’d be happy to try/test any good suggestion or curiosity you might have. Especially getting a negative CPU voltage offset to stick permanently, as well as any thoughts on the VSYNC laziness would be greatly appreciated. Thanks everyone!
  4. I own a Gigabyte G1 Gaming Edition of nVidia's massive new 980ti GPU. It's a great card as-is but I do love to tinker and I'm aware that it uses the same core (GM200 I believe) as the new Titan X GPU, the only difference aside from the 6gb GDDR5 RAM versus the Titan's 12GB is that some of the CUDA cores are disabled on the 980ti, giving it 2,816 active cores instead of the full 3,072 on the Titan X. I'm curious if it would be possible to flash a 980ti so it thinks it's a Titan X and would therefore use that additional block of previously disabled cores. I remember it was once very easy to do this with, say, the old ATI Radeon cards - one could buy a certain relatively cheap card, flash it to something better that used the same core, and even bolt on a better cooling fan, overclock, and that's all it would take to build a way stronger rig for a bargain price. Those were the days, right! I'm sure there are safeguards in place now to make this more difficult because companies like nVidia don't like to lose money, and that difference in amount of video RAM might require a "hybrid" modded VBIOS, but do you think it could be done? What obstacles would have to be overcome? Where might I start in researching this further?
  5. I hear you, but it's not the driver that came with THIS system nor is it the version presented by Dell for this system (the secondary components presented for install don't match up either) and I doubt very seriously that its dysfunction is due to anything I've done. No modified driver has ever successfully installed on this system, and any failed attempt has always been followed up with a clean install of 350.12 from the nVidia website. I was under the impression that you believed you were able to modify the vBIOS in a way that would allow any driver to allow overclock - and more so than +135MHz. Now when this thing failed the first time around, system restore to an earlier point also failed (I've found it terribly unreliable on Win8.1 despite being rock-solid on 7) so I had to restore back to the first full system backup I created just after installing all necessary software on the system. That was before any attempts to modify anything, so at this point in the system's lifespan, it's had the original pre-installed Dell driver replaced with 350.12 and that's it; nothing else. Now if I run DDU and install the driver you suggest and it still fails a second time, can we please move on to the vBIOS?
  6. No, nothing is messed up from earlier attempts to modify anything. I went from a fully stock 350.12 to the 347.90 provided and it made a terrible mess. Nothing inf-modded has ever installed on this system - it always fails to install if attempted, and this is not the fault of the existing driver. Furthermore I'm not looking to go through the messy recovery process from installing the 347.90 driver a second time. I'm looking for a modified vBIOS that allows use of the regular old driver from the nVidia website which installs happily without error, as does the slightly earlier, but later than 347.90, version provided on the Dell support downloads site for this machine.
  7. So I downloaded that driver, 347.90 via the link provided, ran it normally, and it actually bolloxed the system. Specifically it appeared to install (clean install) but produced no nVidia icon in the system tray. Upon immediate reboot, Windows appeared to "think" it was working normally behind the scenes, but the display output was all black and the system was unusable. As for the newer nvflash, I just tested it and got the same result as before. Initially I had ran it with an actual game running in the background, but holding the dGPU open with GPU-Z yields the same result: I'd sure appreciate a system BIOS including a vBIOS modded with your "new method!"
  8. I attempted to use the modified nvdmi.inf file, pasted into driver version 347.88 - and it does act like it can install (doesn't say the hardware is incompatible) but the final summary screen indicates it fails to install the graphics driver. This is the same result I got when patching nvdmi.inf from driver version 350.12 into 347.88 before I made contact with you. If you know what's going wrong, let's see if we can tackle it, but let it be known that I'm ultimately looking for a larger overclock capacity than +135MHz. The last thing I want is to sound ungrateful but we're already talking about a chip that achieves a boost speed of 1197MHz out of the box, so +135 is about an 11% increase. I was able to achieve a 70% increase on my 650m (M14xR2) and it was 100% stable. Now I guess it's possible I won the silicon lottery on that machine but that's the kind of testing I want to do on this new unit. If I were modding the vBIOS, which I'm pretty sure will require extracting and pasting back into the main system BIOS (which I'd also love to have unlocked for that matter) I'd set the OC limit to, say, +800MHz and see how high I can go before encountering artifacts or disturbing temperatures. svl7 created something wonderful which I used on my M14x a couple years back. It was a combination of his fully unlocked system BIOS and an integrated vBIOS that was labelled "for testing" which allowed very high OC speeds to be set - and that single download absolutely transformed the capabilities of that little machine, putting it nearly on-par with my AMD 7970m-powered m17xR4! Now I'm not looking to go into this with expectations for similar performance, but I've owned four of these Alienware laptops now and I really get the feeling that this one is not pushing anywhere near its true performance limits. The highest dGPU temperature I've been able to evoke was 64C, and I've never noticed anything higher than 62C in an actual game. Also the fans do not seem to spin at maximum speed, ever. I've observed what they do during Dell's system BIOS update, which locks them to max for the duration of the update, and nothing I can throw at this machine makes them spin nearly that fast! Whether that's a limitation in the BIOS itself, intended to make the machine quieter, or due to it not getting hot enough to need the full cooling power, I can't say at this time... but everything I'm observing tells me the true potential of this machine has yet to be unlocked! I do have a lot of well-rounded knowledge when it comes to the PC platform and I've worked in the industry for fifteen years, but with the exception of changing a POST-screen image once a few years back, BIOS modding is sadly not in my wheelhouse. Now if someone out there is willing to attempt creation of an unlocked BIOS/vBIOS mod for the 960m-based Alienware 13, I'd be willing to pay for that person's time, as well as to provide a test platform. And on that note, if we could roll something out for testing before June 7th, it would be easier for me to recover from the possibility of a bricked machine because I would still be eligible to exchange the machine outright if it failed, which I've found in my own experience to be a lot less painful than dealing with a warranty call for a bad motherboard. Regardless, thank you Prema for your time in this so far!! Have a great weekend everyone!
  9. Yes I'm aware of that, like my previous M11x and M14x. What surprises me is that the vbios alone can not be extracted at least for viewing using either of these tools. Tell me if I'm wrong, but I guess you're suggesting one would open the main system BIOS rom file, as provided by Dell, extract the vbios from that, do their modding, and re-integrate it for flashing when finished?
  10. Prema, Thank you for your reply! Attached is the nvdmi.inf from driver version 347.88. +135MHz sounds like an improvement, for sure, but I was hoping to see just how far you can go on this system - as I've read that Maxwell has extreme overclocking potential, limited by little else than your ability to dissipate heat. For that matter, I do remember being able to successfully overclock my 650m by over 450MHz with a modded system BIOS. On that note, I've also uploaded two screenshots - one attempting to save the current vBIOS with GPU-Z, and another attempting the same with svl7's mnvflash utility. Both fail, as GPU-Z reports "BIOS reading is not supported on this device" and mnvflash throws a more specific error. There does appear to be a key in the registry, under HKLM\System\CurrentControlSet\Control\Class ... nVidia card's key, that appears to be the entire contents of the vBIOS - and I could upload that but even if you could use it in the form of a .reg file to do some modding we'd be left with the question of how to re-flash the product, as mnvflash appears to fail regardless of whether there's an nVidia driver installed or not. My ultimate goal here is obviously a modified vBIOS that allows for a ton of overclocking headroom to play with, and I'd appreciate anything you can do to help me work toward that goal - and for the possibility to create and test something to post and share with the community, but in the meantime I understand and respect that you're busy so a modded inf file would be appreciated as well! ... whenever you have the time; Thank you!! My full hardware ID is as follows: PCI\VEN_10DE&DEV_139B&REV_A2 nvdmi.zip
  11. OK, thank you, you did answer my question in the literal sense but what I'm really after here is a link, download, or a procedure. I mean I'm sure it CAN be done, but as yet I've been unable to come up with anything that works. nVidia has disabled overclocking at the vBIOS and/or driver level, and since this thread is about modded vBIOS for the 970m & 980m, I was hoping to inspire a mod for the 960m as well. I can provide my stock vBIOS if necessary.
  12. Is it possible to unlock overclocking in the 960m's vBIOS, as per Alienware 13?
  13. I just recently received my newest Alienware purchase - the new 13" model with an nVidia GeForce GTX 960m (a Maxwell chip.) I'm aware of the recent debacle in which nVidia disabled all mobile overclocking in their drivers, I believe versions 345.09 and up. It's also been said that they've disabled it in their new vBIOSes as well. However I was able to uncover a link in which users are confirming that version 347.88 enabled overclocking even on cards that are intended to be clock-blocked in vBIOS: NVIDIA 347.88 Game Ready Driver - 17/03 (re-enables overclocking!) | NotebookReview There's even a user who reports having inf-modded that driver to allow installation with the new 960m, and claims to have unlocked overclocking capability. However, as yet I've been unsuccessful in modding that same driver to install on my system. I've copied the main ListDevices.txt file and all the .inf files in the Display.Driver folder over from version 350.12 which naturally supports the 960m but the result reports "required files are missing" and will not install. Could someone with more experience than I when it comes to inf-modding a driver give me some pointers? Any other ideas or solutions for unlocking the likely massive OC potential of the 960m? vBIOS mod perhaps? I've seen a mod for the 970m along with a modified nvflash EXE. I can provide my current vBIOS if anyone is willing to look into it!! Thank you!!
  14. Further Examination reveals that it is display dithering going on on the Intel side, and tweaking the color palette in AMD's CCC can compensate for the color banding that makes the display look interlaced - so the question becomes: How can I tell the AMD 7970m to dither the display colors like the Intel chip does? There are many AMD-specific registry settings that affect how the display looks but I've yet to find a solution there... any thoughts?
  15. Follow-Up: Does it have to do with display dithering or some other technique that Intel is using to fake more colors than my LCD can actually display? My 1600x900 LVDS display is native 6 bits per primary color per pixel. I found an article that stresses how 6bpp can only result in a true representation of 262,144 actual colors - so Intel must be doing something with their GPU to make the display appear to represent more colors than it actually can, right? And when we connect the AMD GPU directly we are not getting this effect. Is there something I can change, perhaps a registry setting or Window display color profile, that would compensate similarly to whatever Intel is up to? Does this make sense?
  16. I noticed this the very first day I received my Alienware M17x R4 two years ago, and I ignored it until now but I now have a reason why I'd like to run with AMD's Enduro Switchable Graphics disabled. Doing so (Fn+F7 or equiv.) causes the built-in LCD to display a reduced color palette, even though it's set to 32-bit color on the desktop. There is also this weird interlaced look to the display in this mode - it's hard to capture with a camera but I'll attach a picture. 16-bit desktop color setting looks normal and there's no interlacing but 16-bit color sucks for Win7. Has anyone else observed this color depth reduction / display interlacing? (Discrete card is AMD Radeon HD 7970m) Why does it occur with Enduro off? Is there a fix or workaround to run in full discrete-only GPU mode and still have full 32-bit color so that Windows looks as good as it does with the Intel GPU? Thank you!
  17. I get WAY better stable clocks on my 7970m (1000mhz vs. 935mhz) with the oldest video BIOS I've ever come across (ironic right?) It's attached to the second reply on this thread here: http://forum.techinferno.com/general-notebook-discussions/1736-amd-7970m-modified-vbios.html As for the driver, I'm mostly happy with AMD's newest release, but missing the option for fixed switching as in the past it had allowed direct access to the discrete card without having to reboot the system.
  18. Since this thread was never properly concluded, I would like to mention that I ultimately resolved the issue (after much tinkering) by purchasing two replacement 2133MHz RAM chips from Kingston, and then experimenting to find the two existing chips that were "weakest" (although they all passed BurnInTest from the start) and I replaced these two existing chips with the ones I purchased later. Since then I've had no issues with POST after changing graphics modes!
  19. Has anyone with the AMD 7970m GPU successfully upgraded to an aftermarket 120hz screen? I know there's no 3d support but otherwise? I've read the guide at 120Hz 3D Screen upgrade for Alienware 17 | NotebookReview and they point out that there would be no support for 3d which is not what I'm looking for anyway, and I know that Enduro must be disabled by setting display to PEG in BIOS, but the writer of the guide seems unsure whether it's otherwise possible for the 7970m to utilize the 120hz screen, stating that it requires testing. There are also posts here mentioning at least two people bricking their systems by connecting the 120hz replacement screen. I assume the cause was that they did not use the N392W replacement video cable mentioned in the notebookreview guide, and just connected the new screen to their existing cable? Has anyone here tried this combination (120hz LCD / 7970m) or know of any further references to it? Thanks guys!
  20. I have a Mushkin Chronos Deluxe 240GB SSD which I've used as my boot drive for the last two years. Recently I began getting BSOD's when trying to write new data of any significant size to the drive. Note: The drive got to 75% capacity before I ever had any problems. The strange thing is that all the SMART data is green across the board, the drive passes all self-tests, and it reports 100% drive life left. There are never any errors found with chkdsk /r, even after the system crashes trying to write something. It passes BurnInTest sequential data write/read but fails with the same BSOD (0x000000F4) when testing using random write, random seek testing. I duplicated these same BurnInTest results on a desktop PC with the drive installed but not being booted. Only difference is when this machine crashes, there is no BSOD - it just freezes at some point during the randomized BurnInTest. Could the end of the drive just be bad flash memory? Could this happen without tripping any of the drive's self monitoring capabilities and not show as bad sectors in chkdsk /r? This is only the second SSD I ever purchased, and the first failure I've experienced to date. Is this as strange a behavior for SSD's as it seems?
  21. Clone it! I've cloned C using EaseUS Partition Master, free version, among other tools, with all partitions intact. You can also resize partitions in the process if you want, such as if your target drive is larger than the source, or if you're like me with a 16GB Dell recovery partition that is less than half occupied in which case you can resize it down to 8GB on the target without corrupting anything; Just be sure to leave a bit of free space intact. If you use the discs Dell provided, not everything is included - just a generic copy of Windows. If you're talking about the discs you can make with AlienRespawn, they're complete but you'll still be set back to factory condition - and when I used mine (twice) it actually generated a new installation that needed to be "startup repaired" using that Windows disc they send you before I could boot it!
  22. The 3740qm and 3840qm are pretty similar. I'd consider a 39xx XM CPU if you can afford it. The 3900's are fully unlocked and can be clocked up to their true limits, whereas the 37xx and 38xx offer some limited overclocking in these laptops but are not fully unlocked. Myself, I have a 3920XM CPU and I run mine at 4.4GHz, 1.35v. You'll just need to download the free Intel XTU tool and you'll be able to increase your CPU voltage and core clocks, up to the theoretical limit of 6.7GHz - although I doubt anyone has gotten above 5GHz successfully. The 39xx will cost you more than the 3800 due to being unlocked but I feel it's worth it in the M17x, and you can find them for sale on eBay. Note: Your system is also capable of running a 29xx CPU from the previous generation (Sandy Bridge.) It'll suck more power and generate more heat doing the same work, but it will be cheaper than the 39xx and can still be clocked higher than the 3840.
  23. Update: I purchased a 1TB SATAII hard drive from Best Buy, so it would be easy to return if I was wrong, and I cloned my existing 1TB data drive onto this new replacement. Unfortunately the problem, which was writing new data of any sizable quantity to the SSD in bay zero, persisted so I had to go back to the drawing board. Now I'm thinking it must simply be the SSD, although all the SMART readouts are green across the board and chkdsk /r repeatedly finds nothing wrong. I've never gone through an SSD failure before so I don't know if that's really as weird as it seems but I'm hoping that's what is going on, as the only other option would be the controller on the motherboard, right? I furthered this new theory using BurnInTest on the drives. The HDD passes all tests. The SSD passes sequential write and verify, but as soon as it switches to random write and verify I get the same 0x000000F4 BSOD I got when attempting to save new large files initially. Next I removed some data from the SSD, adding to the free space, and then I was able to write the same large video files that initially caused the system to crash over and over before clearing space. It's interesting to note that the SSD is exactly 75% full! Think it's possible that the last 25% is just bad flash memory? I've never had the drive this full before so it could have even been defective from the date of purchase! If this were the case, is it normal that all SSD self-tests and chkdsk /r report no issues? Currently I'm awaiting delivery of a replacement SSD. Had to purchase this one online folks so I hope I've got it nailed down this time! I'll know in a few days but what do you think in the meantime?
  24. I run svl7's unlocked BIOS, version A10, on my M17x R4. I ran it for nearly two years with 240GB Mushkin SSD SATAIII in 1st HDD bay, and stock Dell 750GB HDD SATAII in 2nd bay. It worked without issue. Recently I replaced the 750 with a 1TB HDD with a SATAIII interface and I see the laptop bluescreening when accessing both drives simultaneously (i.e. copying files from one drive to the other.) I remember there was an issue with these mobo's where there was instability when both drives were in SATAIII mode so Dell limited the 2nd bay to SATAII in BIOS A05 or A08 I think. However it looks like that restriction was dropped in the unlocked BIOS I'm using and HwINFO confirms that both drives are operating at SATAIII. Assuming I DO NOT want to drop down to the stock BIOS, is there a way I can limit the 2nd drive to SATAII, or do I have to shell out the $$ for a similar 1TB drive with a SATAII interface? Thanks guys.
  25. J95, I see in step #1 you begin by entering BIOS and disable switchable graphics. Curious to know if I could keep switchable graphics (or re-enable it after driver install) on M17x R4, if I were to do this. Myself, I had very good experiences with nVidia's Optimus tech on both an M11x R2 and M14x R2. Also, out of curiousity, what does HWINFO show as your (lowest sustainable) idle battery drain in the PEG-only configuration you're screenshooting in your guide? I can get my system down to about 14w with iGPU @ 400MHz on M17x R4 / 3920xm CPU, and 23w if I boot into straight-PEG mode with 7970m card engaged.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.