Problems? See this thread at archive.org.
@Mr. Fox Is it possible that a "thread link" can be made for the Sager/Clevo section for them to jump straight into the conversation without having to come into the Alienware forum since this problem is affect both Alienware and Clevo (and other brands, but the title of this thread does say Alienware and Clevo)? As in, a thread over there that links to here. Hope you understand my question as I may have not worded it correctly.
The more computers affected, the better to connect the dots.
EDIT: I see Ethrem already made a thread about it with a link to here. Disregard my question.
-
-
No, and neither were the U2 and U3. Either they've been marked too sparsely or, more likely, the eeprom is inside the controller IC, for which a spec. sheet will be difficult to find.
The 'BAD_EDID' isn't odd (quite common), but there's definitely something very fishy going on.
You have two CMO1720 entries and this is regular too; dual gpu and multiple monitors all cause different entries. This is to make sure their parameters match and it'll be possible to make internal+external screen work simultaneously. But this is the strange thing; the panels edids themselves should still be identical (except for the 'edid override'), yet they're clearly different:
![[IMG]](images/storyImages/I2Vcl.png)
Corruption, sure, we've seen that before. But the F4 is not a random corruption, it was changed intentionally, only that went fubar. The DTD entry on the left was inserted and the older two were shifted up on place. These are the changes that have been made:
- all DTDs are now a 21.7" lcd
- the new DTD is 110Hz
- the new DTD has its pixel clock OC'ed by 75%
Either way; we probably wouldn't have seen this if it weren't for the roll-back. Clean install mightn't have left a trace of this disparity. The F3 would, of course, be in use when the screen is working and the F4 when not. Question is; who made the changes? Intel, nvidia or MS? And, strangest of all; why 21.7"??! -
Yes i were using CRU to OC my display succesfully for quite some months now to 110hz, thats correct, but this shouldn't cause my real EDID going berkserk cause it's some sort of softmod only, just by changing drivers and out of the blue? I actually had to use CRU instead of nvidia tools cause dx9 games didn't see the 110hz setting.
Gesendet von meinem Nexus 9 mit Tapatalk
Edit: so now on PC, looks definitely much better. Ok so that i get it right the 110hz is mine thats what i get, but the 40hz and 60hz should still be like the F3 one right? What i don't get then why did the F4 worked in the first place then, or at least before i made the refresh rate changes?
Edit2: added a good CMO1720.bin from a different P771ZM
Attached Files:
Last edited: Sep 14, 2015 -
Busted
!
Well ... at least now you know how CRU works.
Do think there's a few thing wrong with this:
- CRU should shift the panel id to the next DTD block. There's an empty block to spare, anyway.
- It should write only to 'DeviceParametersEDID_OVERRIDE', not 'DeviceParameters'.
- Making it 21.7" isn't necessary, just the increased pixel clock would do.
Now, your problems can be explained by the CRU-overwritten 'DeviceParameters' section. Replace that with the original, checksum F3 edid and the issues should be solved. Or a complete re-install, of course. If you're worried about eeprom corruption, then extract the real, non-registry edid first.Bullrun, PC GAMER, Scerate and 1 other person like this. -
yeah but what i don't get actually, my screen is dead i mean like the AW users here and clevo users, i don't have any screen beside when installing nvidia drivers, so no bios, no safe mode, no dos, doesn't matter with UEFI, UEFI + CSM, and i already reinstalled w8.1 today and had to do it with a HDMI Display or i wouldn't see anything
And about extracting my EDID, that's the reason i actually had to use the registry method, using for example the Phoenix EDID tool doesn't even recognize my display and when i wanted to extract the EDID, the tool just crashed, so i guess there is some real EDID corruption going on.PC GAMER likes this. -
@t456 - I just tried using edid-rw to write the EDID.bin that I saved from the working LCD and I get an I/O error about no such address. I was able to dump the .bin file with Linux the same as using the Windows tools, so I am assuming the I/O error about no such address might indicate no ability to write. May have to wait until I receive the programmer to do it.
Linux enumerates the LCD as device 1 (instead of 0) after a hotswap, which is probably correct since the original LCD (disconnected) was enumerated as device 0 during Linux startup.
sudo ./edid-rw 1 | edid-decode works
sudo ./edid-rw 0 >edid.bin works successfully dumps to .bin before hotswapping
sudo ./edid-rw -w 1 <edid.bin fails produces the I/O error about no such address
Trying sudo ./edid-rw -w 0 <edid.bin also fails with the same I/O error as "1" suggesting write access cannot occur using these tools and the stock LVDS cable.
If I am interpreting this information correctly, that I/O error in Linux is essentially the same as the error I get in Windows when attempting to upload the .bin to the EEPROM (see screen shot below). Does this sound about right to you? (I am flying by the seat of my pants. Sorry for the noob questions.)
-
YAY! It worked! God Bless @t456.
I am typing this from my M18xR1 with one of the hot-swapped display panel that was corrupted by Windows 10 on the M18xR2. Now, the question is, will it stay fixed on the M18xR2 now that the system BIOS has been affected by Windows 10?
I did not need to do this. It flashed without scanning using that command after hot-swapping. The error message was EXACTLY the same bug in that link you posted and the write-edid tool did the trick.
I am using my ADATA USB 3.0 32GB S102 Pro thumb drive with the "Live" bootable Mint Linux distro on it. I did not even need to install Linux to do this. I had to install some packages, including python and the other tools mentioned in the posts for edid-rw and write-edid, but once those were installed everything was easy. I flashed the good .bin file that I had posted last week.
Code:mint@mint ~/Downloads/write-edid-master $ sudo ./write-edid.sh 1 SEC5448.bin
Here are the steps I followed:
- Booted Mint Linux "Live" distro from my USB thumb drive
- Downloaded this and extracted in "Downloads" folder: ChalkElec/write-edid
- Downloaded this and extracted in "Downloads" folder: bulletmark/edid-rw
- Installed these pre-requisite packages:
Using terminal: sudo apt-get install python-smbus edid-decode
Using terminal: sudo apt-get install edid-decode
Using Synaptics Package Manager found and installed i2ctools, edid-decode, read-edid, libparse-edid-perl - Opened terminal in edid-rw folder and ran this command to confirm the right enumeration
Command: sudo ./edid-rw 0 | edid-decode (returned errors and garbage, so display 0 not enumerated)
Command: sudo ./edid-rw 1 | edid-decode (returned good EDID specs, confirmed display 1 was enumerated) - Downloaded my good SEC5448.bin file and put it in the write-edid folder
- Set run permissions for write-edid program using terminal
Command: chmod a+x write-edid.sh
- Hot-swapped corrupted display panel (unplugged good one, plugged in bad one)
- Opened terminal in write-edid folder and ran this command to flash the EDID to EEPROM
Command: sudo ./write-edid.sh 1 SEC5448.bin
OK, corrupt LCD #2 flashed
LCD not found enumerated as display #0
LCD found enumerated as display #1Code:mint@mint ~/Downloads/edid-rw-master $ sudo ./edid-rw 0 | edid-decode Traceback (most recent call last): File "./edid-rw", line 141, in <module> main() File "./edid-rw", line 129, in main edid = [dev.read(i) for i in range(EDID_HDR)] File "./edid-rw", line 48, in read return self.smb.read_byte_data(EDID_ADDR, n) IOError: [Errno 6] No such device or address Extracted contents: header: 00 00 00 00 00 00 00 00 serial number: 00 00 00 00 00 00 00 00 00 00 version: 00 00 basic params: 00 00 00 00 00 chroma info: 00 00 00 00 00 00 00 00 00 00 established: 00 00 00 standard: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 descriptor 1: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 descriptor 2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 descriptor 3: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 descriptor 4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 extensions: 00 checksum: 00 No header found Manufacturer: @@@ Model 0 Serial Number 0 EDID version: 0.0 Analog display, Input voltage level: 0.7/0.3 V Sync: Image size is variable Gamma: 1.00 Monochrome or grayscale display Established timings supported: Standard timings supported: non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) non-conformant standard timing (0 horiz) Manufacturer-specified data, tag 0 Manufacturer-specified data, tag 0 Manufacturer-specified data, tag 0 Manufacturer-specified data, tag 0 Checksum: 0x0 EDID block does not conform at all! Bad year of manufacture Manufacturer name field contains garbage mint@mint ~/Downloads/edid-rw-master $
STOP: Unplug good display and connect LVDS cable for corrupted displayCode:mint@mint ~/Downloads/edid-rw-master $ sudo ./edid-rw 1 | edid-decode Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 4c a3 48 54 00 00 00 00 00 14 version: 01 04 basic params: 90 29 17 78 0a chroma info: c8 95 9e 57 54 92 26 0f 50 54 established: 00 00 00 standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1: 29 36 80 a0 70 38 1f 40 18 10 25 00 99 e6 10 00 00 1a descriptor 2: 1c 24 80 a0 70 38 1f 40 18 10 25 00 99 e6 10 00 00 1a descriptor 3: 00 00 00 fe 00 48 47 54 33 4a 80 31 38 34 48 54 0a 20 descriptor 4: 00 00 00 00 00 00 41 01 9e 00 00 00 00 02 01 0a 20 20 extensions: 00 checksum: a8 Manufacturer: SEC Model 5448 Serial Number 0 Made week 0 of 2010 EDID version: 1.4 Digital display 6 bits per primary color channel Digital interface is not defined Maximum image size: 41 cm x 23 cm Gamma: 2.20 Supported color formats: RGB 4:4:4, YCrCb 4:2:2 First detailed timing is preferred timing Established timings supported: Standard timings supported: Detailed mode: Clock 138.650 MHz, 409 mm x 230 mm 1920 1944 1960 2080 hborder 0 1080 1082 1087 1111 vborder 0 +hsync -vsync Detailed mode: Clock 92.440 MHz, 409 mm x 230 mm 1920 1944 1960 2080 hborder 0 1080 1082 1087 1111 vborder 0 +hsync -vsync ASCII string: HGT3J�184HT Manufacturer-specified data, tag 0 Checksum: 0xa8 EDID block does NOT conform to EDID 1.3! Missing name descriptor Missing monitor ranges mint@mint ~/Downloads/edid-rw-master $
Flash corrupted display with known good EDID (in this example SEC5448.bin for M18xR1/R2)
Code:mint@mint ~/Downloads/write-edid-master $ chmod a+x write-edid.sh mint@mint ~/Downloads/write-edid-master $ sudo ./write-edid.sh 1 SEC5448.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 0x48 to bus 1, chip-adress 0x50, data-adress 0x5f Writing byte 0x47 to bus 1, chip-adress 0x50, data-adress 0x60 Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x61 Writing byte 0x33 to bus 1, chip-adress 0x50, data-adress 0x62 Writing byte 0x4A to bus 1, chip-adress 0x50, data-adress 0x63 Writing byte 0x80 to bus 1, chip-adress 0x50, data-adress 0x64 Writing byte 0x31 to bus 1, chip-adress 0x50, data-adress 0x65 Writing byte 0x38 to bus 1, chip-adress 0x50, data-adress 0x66 Writing byte 0x34 to bus 1, chip-adress 0x50, data-adress 0x67 Writing byte 0x48 to bus 1, chip-adress 0x50, data-adress 0x68 Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x69 Writing byte 0x0A to bus 1, chip-adress 0x50, data-adress 0x6a Writing byte 0x20 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 0x00 to bus 1, chip-adress 0x50, data-adress 0x6f Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x70 Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x71 Writing byte 0x41 to bus 1, chip-adress 0x50, data-adress 0x72 Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x73 Writing byte 0x9E to bus 1, chip-adress 0x50, data-adress 0x74 Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x75 Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x76 Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x77 Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x78 Writing byte 0x02 to bus 1, chip-adress 0x50, data-adress 0x79 Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x7a Writing byte 0x0A to bus 1, chip-adress 0x50, data-adress 0x7b Writing byte 0x20 to bus 1, chip-adress 0x50, data-adress 0x7c Writing byte 0x20 to bus 1, chip-adress 0x50, data-adress 0x7d Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x7e Writing byte 0xA8 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 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??....??? .? 80: ff ff ff ff ff ff ff ff ff 00 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 ................ mint@mint ~/Downloads/write-edid-master $
Update:
Good news (sort of). Unfortunately, the M18xR2 almost immediately re-bricked the display. First reboot was fine, so was the second, but the third reboot the screen did a bright flash, EDID corrupted and 8 beeps. I think the flash might be the writing of corrupt data to EDID. Before rebooting I removed the latest and greatest Intel Chipset and Intel ME drivers and installed those from dell.com/support designed for the M18xR2, not generic versions from the web. I flashed the system BIOS to stock A10, dumped the vBIOS and flashed stock vBIOS. In spite of all that, it still corrupted the EDID and made the machine unbootable.
So, I re-flashed the display again. Got out a spare LVDS cable and my X-acto knife. @t456 was correct (as usual). I severed the wire for pin #5 (fourth wire in from the right) and everything is working. It has not re-bricked itself again. I flashed the A10 unlocked system BIOS and I am about to flash my unlocked vBIOS.
Now, another observation... a couple of times I puckered up my glutimus maximus really hard, almost got a charlie horse, thinking it was going to brick itself. With the 4th wire (pin #5) cut there is a brief pause of black screen, maybe for one second, similar to what it would do before the screen flash and 8 beeps. It's like something is trying to write and can't. So, maybe that is really great news as far as usability. But, it makes me wonder what Windows 10 did even more now. Something got changed and it's still changed. Not happy about that part, but if my gorgeous red banshee beast is back from the dead, then there is reason for everyone affected by this Micro$haft trojan malware cancer OS the way I have been to be happy.
Will report if there are any more issues. I don't want to jump the gun, so let's give it more time to see if this is really a permanent fix.
EDIT: Don't waste your time snipping the LVDS wire. It doesn't do any good and won't stop it from happening again if you are using EVGA Precision X.
Here is a safe version of EVGA Precision X that will not brick the LCD panel.
https://drive.google.com/file/d/0Bwdqi25LDwZyYjJTRHZVbTBXazA/view
Attached Files:
Last edited: May 25, 2016flyingfool, codzor, ole!!! and 17 others like this. -
Nice job
! And good to hear the tools are effective, too
.
Hope you made that export before writing the new edid, as mentioned in the instructions (ahem)? Kinda curious whether it's header was corrupted ... that would neatly explain why the EnTech tools failed.
Also ... you may have found the write-protect bit:
![[IMG]](images/storyImages/DvyCe.png)
Without knowing the exact eeprom it's a bit of a guess, but still ... either that or it was a random corruption. Both would be nice to resolve, so ...
Could also do something else, of course, but since you have that programmer inbound anyway ...Code:sudo i2cset 1 0x50 0x89 0x00
. There's no way to know if this panel uses the same eeprom as the
SEC5044 (LTN173HT01-301 or LTN173HT02-D** version), so
before flipping that bit, make sure to check the pcb. It's possible that '1' = WP-on, but due to a floating WP-pin this would
still result in WP-off (manufacturer's error):
![[IMG]](images/storyImages/hL9At.png)
To be clear: to enable write-protection (for the SEC5044) you need both the right hookup of the physical WP pin on the eeprom itself AND the software SRP bit (inside that same eeprom).
No, don't think so.
The 'BIST' label in the SLB3 spec. sheet gave it away; Dell has simply left enabled a self-test feature normally only available to the panel's manufacturer. Clipping it won't matter either way; the panel will still run, only you'd loose the 'LCD BIST Diagnostics' option. All this does is show a few test-patterns, but there's no consequence to this; the user has to interpret the results. I'd still clip it, unless you were to hard-protect the eeprom; the WP-pin must not be left in limbo.ole!!!, Rotary Heart and Mr. Fox like this. -
That would be useful, too
.
Btw, does anyone have a stock GTX 860M vbios? We have an 860M from an affected system, now just need the same version, except pre-flashed, this time. Or pre-10, at minimum.
Yes, haven't gotten around to this ... its edid is probably fine, but will corrupt it intentionally to see if a Clevo can ignore that. -
-
Update to previous post located here.
Good news (sort of). Unfortunately, the M18xR2 almost immediately re-bricked the display. First reboot was fine, so was the second, but the third reboot the screen did a bright flash, EDID corrupted and 8 beeps. I think the flash might be the writing of corrupt data to EDID. Before rebooting I removed the latest and greatest Intel Chipset and Intel ME drivers and installed those from dell.com/support designed for the M18xR2, not generic versions from the web. I flashed the system BIOS to stock A10, dumped the vBIOS and flashed stock vBIOS. In spite of all that, it still corrupted the EDID and made the machine unbootable.
So, I re-flashed the display again. Got out a spare LVDS cable and my X-acto knife. @t456 was correct (as usual). I severed the wire for pin #5 (fourth wire in from the right) and everything is working. It has not re-bricked itself again. I flashed the A10 unlocked and I am about to flash my unlocked vBIOS.
Now, another observation... a couple of times I puckered up my glutimus maximus really hard, almost got a charlie horse, thinking it was going to brick itself. With the 4th wire (pin #5) cut there is a brief pause of black screen, maybe for one second, similar to what it would do before the screen flash and 8 beeps. It's like something is trying to write and can't. So, maybe that is really great news as far as usability. But, it makes me wonder what Windows 10 did even more now. Something got changed and it's still changed. Not happy about that part, but if my gorgeous red banshee beast is back from the dead, then there is reason for everyone affected by this Micro$haft trojan malware cancer OS the way I have been to be happy.
Will report if there are any more issues. I don't want to jump the gun, so let's give it more time to see if this is really a permanent fix.
I think if I actually sleep tonight, I'm going to sleep well.
TomJGX, deadsmiley, Robbo99999 and 7 others like this. -
*** Windows 10 + NVIDIA WHQL Drivers are Killing Alienware and Clevo LCD Panels ***
Discussion in 'Alienware' started by Mr. Fox, Aug 1, 2015.
