*** Windows 10 + NVIDIA WHQL Drivers are Killing Alienware and Clevo LCD Panels ***

As far as LCD bricking, no problems yet. As far as Windoze OS X in general, it's still an abortion... a real pile of crap OS.

 

I'm also running W10 without issue. Fully updated running 145.2 drivers (yes they actually work). I'm using Nvidia inspector for overclocking now. It's not as pretty as precision X but at least it doesn't brick my M18x lol


Sent from my iPhone using Tapatalk

 

I up-dated my drivers for my 970 NVidia card on windows 10 and installed evga overclocking program, re-booted lap top and got black screen with 8 beeps.

 

145.2? Which drivers are you talking about if I may ask? Nvidia graphic drivers?

My Alienware is fixed up. Everything is wiped clean ready for fresh install now. Staying with Windows 7 and Windows Updates off is safest bet on Alienware now.

I'm willing to give Windows 10 one more chance on my P750ZM. I've read in this thread that the P7xxZM/DM are "safe" from this LCD atrocity but can you confirm it @Mr. Fox? My model has the Sharp IGZO screen, which I haven't seen being killed anywhere beside Samsung and LG counterparts.

 

Well, at least if anyone wants to brick his laptop right before warranty expires to get a better machine - here you go. Just install Windows 10 and EVGA, BOOM, you got new lappy.

And I don't think it's fraudulent. Alienware didn't manage to create a fix for like quarter?

 

Very good idea. Everyone should brick the screen right before warranty. This one deserves Dell 100%. A lesson that everyone should give Dell. If you get a Crippled BGA laptop as a replacement; Sell it immediately as new. Use the money you get for the sale to something decent. Dell can continue with their modern garbage. Let Dell continue to create trash to someone who does not appreciate performance/quality.

 

Sorry to hear man! Its a very unfortunate thing to happen to anyone. from all the previous post and reports you should know to stay well away from evga PX and even MSI afterburner (just to be safe)!
Use RTSS + HWiNFO64 once you get ur rig fixed. Good luck

Sent from my LG-D855 using Tapatalk

 

You would've thought by going private they would be able to improve quality control and engineering/design. Nope...seems like they want to increase profit margins and continue the corporate shenanigans. Well played Michael Dell...well played

 

Mine did, but I didn't have an edp display (lvds chimei). That is the only display it has happened to. Also had win 10 + g-sync ready driver + evga px. So steer clear of the trio or ask @jaybee83. I believe he has the same config...

 

edp display, nvidia inspector, win10 with all updates (aside from drivers), 353.63 driver, have never used precision x before. so far so good

Sent from my Nexus 5 using Tapatalk

 

Try this awesome game and let me know how your system performs

http://store.steampowered.com/app/268850/

 

Fixed that for ya
Promo action of MS, Nvidia and Alienware: Free Windows Upgrade + Free EVGA Precision on Nvidia-based hardware = Free bricking your notebook! No need to rush, it seems it's endless.

 

@Mr. Fox , which method of windows 10 installation did you choose? Just wondering if it actually changes anything in the way the OS behaves.

 

I installed it clean (no upgrade) in pure UEFI mode and left it that way until the first LCD bricking, then later on enabled Legacy Option ROM/CSM. I did that to see if I could boot using an external display with a bricked LCD in pure UEFI mode like a couple of people can. But, I couldn't... doesn't work at all when the screen is bricked, doesn't matter whether Legacy or UEFI, internal or external display.

My normal and preferred way of installing is with the BIOS set to no-UEFI pure Legacy mode (not UEFI or UEFI with Legacy Option ROM/CSM). That's how it was when the bricking started and there was zero benefit to going with pure UEFI. If I do another clean install, it will be set back to pure Legacy BIOS.

 

Okay. By the way, my battery keeps on disconnecting after a couple of minutes. I have to manually remove it and insert it again for it to only briefly work. This just happened to me and I don't know what is causing it. I am windows 10 ready if you are wondering.

 

Here's this... No POST issue with 8 beeps on Alienware systems using Samsung/LG LCD panels and running NVIDIA graphics after upgrading to Windows 10. | Dell US

 

i don't think we've heard the end of this....i still call it BS!

 

Yeah that was posted a while back and ManuelG from Nvidia posted about it too. I wish they could just write protect the edid.

 

Dells new policy. Nothing is better than zero Fixes. You shouldn't Oc a Dell product anyway.

 

Maybe you have Desktop Mode charging enabled. Kind of a wonky feature to help the battery not wear out as fast by never fully charging it.

Right click the system tray battery icon and check. If that's not it, then you can try removing AC, disconnecting the battery and holding down the power button 30 second to reset it. That might help. If neither of those things corrects the issue, then I don't know what's going on.

 

Didn't mentioned how I 'fixed' the system, but it was a bit more than just buying a new panel. It seems whatever 'infected' the LCD resulting in 8 beeps also infected the graphic card. After buying a new panel for my AW 17 I still had 8 beeps, but then I managed to 'grab' a secondhand 780M locally. So new panel with infected 880: backlights on, but still 8 beeps. Being afraid of burning yet another screen I switched off immediately. Popped in the 780M, and 'It's ALIVE' time . So now that 880M is either destined for the bin or, if anyone here is interested, eBay.

 

troll

what i forgot to mention: 92nd day today and counting...

Sent from my Nexus 5 using Tapatalk

 

Disabled desktop charging mode and everything is back to normal. Thanks

 

I didn't even know such mode existed lol. Is there any benefits besides prolonging battery lifespan? Mine is always plugged in

Sent from my LG-D855 using Tapatalk

 

Cool. Glad it's OK now.

Nope. I don't like it. I disable it. I don't care about prolonging the battery lifespan. It's just a built-in UPS on all of my laptops. I almost never use them on battery either.

 

so it is ok to use win 10 just with the updates disabled?

 

With the AW18, it is ok to use it with Intel Integrated Graphics all Win10 updates, including latest 10576 build. No word yet with discrete AMD.

 

I'm fully updated on Windows 10. No precision X and you should be fine. I wouldn't use Samsung magician either. I have no proof yet but I'm pretty damn sure it's another trigger.


Sent from my iPhone using Tapatalk

 

ok, i have magician but i installed it when i got ssds installed and that's after my win 10 dabbling.

 

Whatever Samsung Magician does to optimise SSDs can also be done manually. I just follow these steps on Windows 7

https://www.maketecheasier.com/12-things-you-must-do-when-running-a-solid-state-drive-in-windows-7/

 

It's never been proven so you can give it a try I suppose. I'm not that ballsy unfortunately lol


Sent from my iPhone using Tapatalk

 

If you are using Win 10 then I wouldn't disable updates. That's how you get new builds as part of the design. The TH2 build is coming out for everyone I think at the end of the month. Insiders get it this week.

 

I think we need some site that will list which KB are suspicious and which are safe.

 

Jericho2015, new builds bring new bugs along with new features and fixes, if you are happy with a particular build and you are stable, it might be wise to wait for a while before taking a new build to see what kind of new bugs are being reported.

New isn't always better, and in fact in the software / hardware world, standing off at first is a good idea, so you can get a good look at it all before letting it in the door.

Taking control of your environment, to make sure it is stable, and turning the updates on and off is the only way you have control over it all.

That is assuming the computer in question is meant for doing actual work / play, and it isn't dedicated to only testing new OS/patches.

If you are building a test machine for vetting updates to test out before rolling out to other computers, you would still have to control what updates are installed - to preserve the integrity of the testing environment focusing on only certain new patches, drivers, updates.

Letting updates come in unchecked and uncontrolled is a bad idea no matter how you look at it.

 

I'm curious why no one has pointed out that the LCD corruption still happens AFTER a clean installation of Windows 10/8/7 (without PrecisionX installed) and then installing PrecisionX.

Granted, this may only be the case for folks who already completed a Windows 10 upgrade with PrecisionX installed, but still - WHY DOES IT STILL HAPPEN AFTER A CLEAN INSTALL OF WINDOWS 7 OR 8 when PrecisionX is installed?

There should be ZERO reason why I shouldn't be able to install and use PrecisionX within Windows 7 (or 8) like I used to be able to, yet now I cannot without bricking my LCD?

Million dollar question folks.

EDIT: And what the hell is a NVIDIA 756M graphics card? Did they even bother to proof read? (yeah, stupid question)

 

http://techne.alaya.net/?p=12499 (it's also linked in my signature) are the ones that should definitely be purged.

 

Meh, waste of time. The best way to deal with those pesky Windows Updates...

Well put. That's how big business with hired pros or dedicated IT staff handle this stuff. Letting Micro$loth decide is a recipe for distaster... has been for a long time, but now it's the only way to separate their trojan malware from legitimate patches... full time job. Any more, it is easier to fix the malware that isn't WHQL Certified, LOL.

They also did not list 880M, which was one of the first to surface with the problem along with 780M.

In general terms, their articles have always been hit or miss on technical accuracy, and less than great in terms of grammar, punctuation and spelling accuracy. Part of it probably has something to do with the fact that English is not the primary language of the people that write them, proof-read, and approve publication. To compound the problem, those same individuals are apparently either not very technically savvy, not the sharpest tool in the shed, or dangerous cocktail of all the above.

They do have brilliant people involved with this problem, but they are not involved with media relations or public communications. I'm sure some of the technical gets lost in translation and the articles end up getting diluted as a result.

But, as far as your million dollar question, nobody knows why. Dell and NVIDIA probably not been able to reproduce the problem on systems that don't have EVGA Precision X, and if that's the case, they cannot speak to underlying cause. All they can do is assume, as we have, 1+1=2, connect the dots... Micro$haft is the devil behind the details. They aren't going to do that, and probably could not get away with it if they wanted to.

I think their intent with the article, although poorly written, is to warn their customers of the danger they have been able to verify conclusively, not educate everyone on the nuances of all reported scenarios. Bottom line is they do not have an answer. None of us do.

And, since EVGA doesn't sell MXM cards or laptops, or advertise Precision X support in that space, I'm going to venture a guess they really don't give a rat's butt... it's not their problem. I'm confident Micro$loth doesn't care. They're far too stinking important to care about such a small group of people whose interests are at enmity with their filthy Nazi agenda to have control of us, our software and hardware. All the idiotic high performance notebook haters and anti-overclocking imbeciles will point to this as another example why laptops should not be overclocked.

 

it is a risk one takes i guess.

 

Everything causes some form of cancer according to popular science. The air we breathe, the water we drink, and the food we eat, is a risk... just like crossing the street or getting out of bed every morning. We all deserve to die for poisoning the planet and we should all commit harakiri (that's "Harry Carey" for the trailer park dwellers). We need to let the plants and animals have it all back... naughty human beings, we are. All of this is Al Gore's fault for creating the internet.

 

Wow! So deep it touched me on an emotional level. Right now I'm not sure if I'm more worried about Os10 and my laptop not getting along or our planet and its habitats lol

Sent from my LG-D855 using Tapatalk

 

And, the really sad part is, some people actually believe those things. I think it's safe to say the EDID corruption is unrelated to those other unsolved mysteries, but the root cause remains elusive.

Assigning all of the blame to Precision X and calling it a day doesn't find or fix the real problem. That was the point of my metaphorical sarcasm about the other unexplained life scenarios that we encounter. Nobody wants to admit they don't have the answers, so some people just make stuff up and present their guesses as though they are factual.

 

@Prockish03evo - All set... 99% of the credit goes to @t456 because he is the one I learned from. We would all be buying replacement LCD panels and throwing away good ones if not for his help.

Your display was absolutely corrupted like all of the others. I got 8 beeps with it on my M18xR2 as soon as I turned it on.

It's fixed. Will have it on its way to you later today.

Here is the before and after EDID. Notice the row that starts with 10: should be '90' to the left of 29. It had '00' there.

Spoiler: Corrupted EDID - 8 Beeps

Code:

**BEFORE FLASHING**
owner@M18xR2 ~/EDID/write-edid-master $ sudo i2cdump -r 0-127 1 0x50
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x50, mode byte
Probe range limited to 0x00-0x7f.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 4c a3 48 54 00 00 00 00    ........L?HT....
10: 00 14 01 04 00 29 17 78 0a c8 95 9e 57 54 92 26    .???.)?x????WT?&
20: 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01    ?PT...??????????
30: 01 01 01 01 01 01 29 36 80 a0 70 38 1f 40 18 10    ??????)6??p8?@??
40: 25 00 99 e6 10 00 00 1a 1c 24 80 a0 70 38 1f 40    %.???..??$??p8?@
50: 18 10 25 00 99 e6 10 00 00 1a 00 00 00 fe 00 48    ??%.???..?...?.H
60: 47 54 33 4a 80 31 38 34 48 54 0a 20 00 00 00 00    GT3J?184HT? ....
70: 00 00 41 01 9e 00 00 00 00 02 01 0a 20 20 00 a8    ..A??....???  .?

Spoiler: Corrected EDID - No More Beeps :)

Code:

**FLASHED - CORRECTED EDID**
owner@M18xR2 ~/EDID/write-edid-master $ sudo ./write-edid.sh 1 SEC5448-NR.bin
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x00
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x01
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x02
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x03
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x04
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x05
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x06
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x07
Writing byte 0x4C to bus 1, chip-adress 0x50, data-adress 0x08
Writing byte 0xA3 to bus 1, chip-adress 0x50, data-adress 0x09
Writing byte 0x48 to bus 1, chip-adress 0x50, data-adress 0x0a
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x0b
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x0c
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x0d
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x0e
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x0f
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x10
Writing byte 0x14 to bus 1, chip-adress 0x50, data-adress 0x11
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x12
Writing byte 0x04 to bus 1, chip-adress 0x50, data-adress 0x13
Writing byte 0x90 to bus 1, chip-adress 0x50, data-adress 0x14
Writing byte 0x29 to bus 1, chip-adress 0x50, data-adress 0x15
Writing byte 0x17 to bus 1, chip-adress 0x50, data-adress 0x16
Writing byte 0x78 to bus 1, chip-adress 0x50, data-adress 0x17
Writing byte 0x0A to bus 1, chip-adress 0x50, data-adress 0x18
Writing byte 0xC8 to bus 1, chip-adress 0x50, data-adress 0x19
Writing byte 0x95 to bus 1, chip-adress 0x50, data-adress 0x1a
Writing byte 0x9E to bus 1, chip-adress 0x50, data-adress 0x1b
Writing byte 0x57 to bus 1, chip-adress 0x50, data-adress 0x1c
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x1d
Writing byte 0x92 to bus 1, chip-adress 0x50, data-adress 0x1e
Writing byte 0x26 to bus 1, chip-adress 0x50, data-adress 0x1f
Writing byte 0x0F to bus 1, chip-adress 0x50, data-adress 0x20
Writing byte 0x50 to bus 1, chip-adress 0x50, data-adress 0x21
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x22
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x23
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x24
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x25
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x26
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x27
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x28
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x29
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2a
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2b
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2c
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2d
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2e
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2f
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x30
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x31
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x32
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x33
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x34
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x35
Writing byte 0x29 to bus 1, chip-adress 0x50, data-adress 0x36
Writing byte 0x36 to bus 1, chip-adress 0x50, data-adress 0x37
Writing byte 0x80 to bus 1, chip-adress 0x50, data-adress 0x38
Writing byte 0xA0 to bus 1, chip-adress 0x50, data-adress 0x39
Writing byte 0x70 to bus 1, chip-adress 0x50, data-adress 0x3a
Writing byte 0x38 to bus 1, chip-adress 0x50, data-adress 0x3b
Writing byte 0x1F to bus 1, chip-adress 0x50, data-adress 0x3c
Writing byte 0x40 to bus 1, chip-adress 0x50, data-adress 0x3d
Writing byte 0x18 to bus 1, chip-adress 0x50, data-adress 0x3e
Writing byte 0x10 to bus 1, chip-adress 0x50, data-adress 0x3f
Writing byte 0x25 to bus 1, chip-adress 0x50, data-adress 0x40
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x41
Writing byte 0x99 to bus 1, chip-adress 0x50, data-adress 0x42
Writing byte 0xE6 to bus 1, chip-adress 0x50, data-adress 0x43
Writing byte 0x10 to bus 1, chip-adress 0x50, data-adress 0x44
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x45
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x46
Writing byte 0x1A to bus 1, chip-adress 0x50, data-adress 0x47
Writing byte 0x1C to bus 1, chip-adress 0x50, data-adress 0x48
Writing byte 0x24 to bus 1, chip-adress 0x50, data-adress 0x49
Writing byte 0x80 to bus 1, chip-adress 0x50, data-adress 0x4a
Writing byte 0xA0 to bus 1, chip-adress 0x50, data-adress 0x4b
Writing byte 0x70 to bus 1, chip-adress 0x50, data-adress 0x4c
Writing byte 0x38 to bus 1, chip-adress 0x50, data-adress 0x4d
Writing byte 0x1F to bus 1, chip-adress 0x50, data-adress 0x4e
Writing byte 0x40 to bus 1, chip-adress 0x50, data-adress 0x4f
Writing byte 0x18 to bus 1, chip-adress 0x50, data-adress 0x50
Writing byte 0x10 to bus 1, chip-adress 0x50, data-adress 0x51
Writing byte 0x25 to bus 1, chip-adress 0x50, data-adress 0x52
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x53
Writing byte 0x99 to bus 1, chip-adress 0x50, data-adress 0x54
Writing byte 0xE6 to bus 1, chip-adress 0x50, data-adress 0x55
Writing byte 0x10 to bus 1, chip-adress 0x50, data-adress 0x56
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x57
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x58
Writing byte 0x1A to bus 1, chip-adress 0x50, data-adress 0x59
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x5a
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x5b
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x5c
Writing byte 0xFE to bus 1, chip-adress 0x50, data-adress 0x5d
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x5e
Writing byte 0x4C to bus 1, chip-adress 0x50, data-adress 0x5f
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x60
Writing byte 0x4E to bus 1, chip-adress 0x50, data-adress 0x61
Writing byte 0x31 to bus 1, chip-adress 0x50, data-adress 0x62
Writing byte 0x38 to bus 1, chip-adress 0x50, data-adress 0x63
Writing byte 0x34 to bus 1, chip-adress 0x50, data-adress 0x64
Writing byte 0x48 to bus 1, chip-adress 0x50, data-adress 0x65
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x66
Writing byte 0x30 to bus 1, chip-adress 0x50, data-adress 0x67
Writing byte 0x32 to bus 1, chip-adress 0x50, data-adress 0x68
Writing byte 0x53 to bus 1, chip-adress 0x50, data-adress 0x69
Writing byte 0x30 to bus 1, chip-adress 0x50, data-adress 0x6a
Writing byte 0x31 to bus 1, chip-adress 0x50, data-adress 0x6b
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x6c
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x6d
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x6e
Writing byte 0xFE to bus 1, chip-adress 0x50, data-adress 0x6f
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x70
Writing byte 0x4C to bus 1, chip-adress 0x50, data-adress 0x71
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x72
Writing byte 0x4E to bus 1, chip-adress 0x50, data-adress 0x73
Writing byte 0x31 to bus 1, chip-adress 0x50, data-adress 0x74
Writing byte 0x38 to bus 1, chip-adress 0x50, data-adress 0x75
Writing byte 0x34 to bus 1, chip-adress 0x50, data-adress 0x76
Writing byte 0x48 to bus 1, chip-adress 0x50, data-adress 0x77
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x78
Writing byte 0x30 to bus 1, chip-adress 0x50, data-adress 0x79
Writing byte 0x32 to bus 1, chip-adress 0x50, data-adress 0x7a
Writing byte 0x53 to bus 1, chip-adress 0x50, data-adress 0x7b
Writing byte 0x30 to bus 1, chip-adress 0x50, data-adress 0x7c
Writing byte 0x31 to bus 1, chip-adress 0x50, data-adress 0x7d
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x7e
Writing byte 0xA0 to bus 1, chip-adress 0x50, data-adress 0x7f
Writing done, here is the output of i2cdump -y 1 0x50:
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 4c a3 48 54 00 00 00 00    ........L?HT....
10: 00 14 01 04 90 29 17 78 0a c8 95 9e 57 54 92 26    .????)?x????WT?&
20: 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01    ?PT...??????????
30: 01 01 01 01 01 01 29 36 80 a0 70 38 1f 40 18 10    ??????)6??p8?@??
40: 25 00 99 e6 10 00 00 1a 1c 24 80 a0 70 38 1f 40    %.???..??$??p8?@
50: 18 10 25 00 99 e6 10 00 00 1a 00 00 00 fe 00 4c    ??%.???..?...?.L
60: 54 4e 31 38 34 48 54 30 32 53 30 31 00 00 00 fe    TN184HT02S01...?
70: 00 4c 54 4e 31 38 34 48 54 30 32 53 30 31 00 a0    .LTN184HT02S01.?
80: ff ff ff ff ff ff ff ff ff 01 ff ff ff ff ff ff    .........?......
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
owner@M18xR2 ~/EDID/write-edid-master $

 

Thanks . Did you also write the 2nd .txt file, same as with the primary card?

Tried old panel + 780M yet? If you have and it's still 8 beeps, then that 880M's vbios might hold a clue. Send me a pm in that case; interested in buying it from you (will read its eeprom with programmer).

 

Yes sir, did them both the same except for the enumeration switch -i0 primary GPU and -i1 for secondary GPU.

Sure do appreciate all your help, bro. You'll be proud to know your encouragement for me to try my hand at SMD soldering has paid off. I have removed three motherboard BIOS chips, programmed them manually, and soldered them back. Bought a new programmer with 64-bit OS support. I've got a socket coming for the Alienware 18 motherboard, so if I can get @svl7 or @Prema to unlock the menus for me I will have the world's first (that I know of) Alienware 18 with a BIOS EEPROM mounted in a socket and a fully unlocked system BIOS like the M18xR1 and M18xR2. Thanks for the encouragement. It was nerve-racking, but easier than I thought. Having a powerful magnifying headset is a big help. I can see everything very clearly and that helped with self-confidence also.

 

I wonder if there's a TLDR version? i am getting confused!

 

How's this? Sell your Alienware and buy a EUROCOM SKY X9.

Just kidding... sort of. A TLDR version of what?

 

just a summary of the findings so far.

 

the OP takes care of that... well kind of ^^

 

not the most recent developments.

 

That is really fascinating feeling when you are the first one to bypass artificial locks and get new undocumented features out of machine, isn't it?
I have similar project in my mind and if all gets as planned... well, can't wait.
P.S. Does it have AMI BIOS? If so it is very easy to unlock hidden submenus. But if it has hidden menu like Chipset or Advanced then it's impossible to unlock it with software, only by hands.