[lm-sensors] sensors-detect changed screen's vertical rate

[Numan DEMİRDÖĞEN]

After using sensors-detect for the first time, screen's vertical rate
turned to 1023 from 800. The original resolution of screen is
1280x800 at 60Hzt but now it is 1280x1023 and I can not change it
whatever I did. I tried xrandr to revert it to original but if I
choose a different rate other than 1280x1023, resolution looks
horrible. It looks like its EDID was also changed.

Could you help me to solve this issue?

Thank and sincerely
Numan DEM?RD??EN

uname -a
Linux else 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 17:34:21 UTC 2012
i686 i686 i386 GNU/Linux

sudo i2cdetect -l
i2c-0 i2c Radeon i2c bit bus DVI_DDC I2C adapter
i2c-1 i2c Radeon i2c bit bus VGA_DDC I2C adapter
i2c-2 i2c Radeon i2c hw bus MM_I2C I2C adapter
i2c-3 i2c Radeon i2c bit bus MONID I2C adapter

lspci output: http://pastebin.com/hmREjFgu
xrandr output: http://pastebin.com/abGqSApj
i2cdump output: http://pastebin.com/bCtKEFMq
get-edid | read | edid output: http://pastebin.com/Z5dM2WFW
dmesg | grep drm output: http://pastebin.com/S9fF8CuA
dmesg output: http://pastebin.com/h3UVmxVs

[Jean Delvare]

Hi Numan,

Post by Numan DEMİRDÖĞEN
After using sensors-detect for the first time, screen's vertical rate
turned to 1023 from 800. The original resolution of screen is
1280x800 at 60Hzt but now it is 1280x1023 and I can not change it
whatever I did. I tried xrandr to revert it to original but if I
choose a different rate other than 1280x1023, resolution looks
horrible. It looks like its EDID was also changed.

I'm very sorry about that. Needless to say sensors-detect isn't
supposed to do that. This is the first report ever of EDID corruption,
if that's what it is. This could be caused by a specific uncommon chip
on one of your graphics chip I2C buses, or by a bug in the graphics chip
driver.

Post by Numan DEMİRDÖĞEN
Could you help me to solve this issue?

I'll do my best.

Post by Numan DEMİRDÖĞEN
uname -a
Linux else 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 17:34:21 UTC 2012
i686 i686 i386 GNU/Linux

For the records, please also tell us:
* Which version of sensors-detect you used?
* Did you leave the default answer to every question, or did you ask
for probing which was disabled by default?

I see you're using the radeon driver on a RV380 chip. Do I understand
correctly that this is a laptop and the screen you're talking about is
the laptop's own screen? Fujitsu-Siemens Amilo Pro V2045, right?

It would be great if you could dig your logs for a dump of your EDID
_before_ the corruption. The radeon driver logs this
to /var/log/Xorg.0.log. If you can't find that, it would be great to
find another user with the same laptop who could provide this dump.

Post by Numan DEMİRDÖĞEN
sudo i2cdetect -l
i2c-0 i2c Radeon i2c bit bus DVI_DDC I2C adapter
i2c-1 i2c Radeon i2c bit bus VGA_DDC I2C adapter
i2c-2 i2c Radeon i2c hw bus MM_I2C I2C adapter
i2c-3 i2c Radeon i2c bit bus MONID I2C adapter
lspci output: http://pastebin.com/hmREjFgu
xrandr output: http://pastebin.com/abGqSApj

First modeline looks pretty wrong, and physical dimensions too.

You could try xrandr's --newmode option. First run xrandr --verbose to
have the detailed timings for 1280x1023, and then use --newmode with
1023 replaced by 800 (and all other relevant values shifted
accordingly.) This might at least make the machine usable until we find
how fix your EDID.

Post by Numan DEMİRDÖĞEN
i2cdump output: http://pastebin.com/bCtKEFMq

I'd be more interested in the output of i2cdetect for each but for now.

Post by Numan DEMİRDÖĞEN
i2cdump 2 0x60

I suspect you meant 0x50, not 0x60. Please try that and report. I would
also need the (bogus) EDID dump from /var/log/Xorg.0.log.

Post by Numan DEMİRDÖĞEN
get-edid | read | edid output: http://pastebin.com/Z5dM2WFW
dmesg | grep drm output: http://pastebin.com/S9fF8CuA
dmesg output: http://pastebin.com/h3UVmxVs

Meanwhile I'll refresh my knowledge of how timings are encoded in the
EDID. Hopefully we can write the right contents back to it.

Meanwhile I'll see if I can change sensors-detect to skip probing
address 0x50 on graphics chip I2C buses. It serves no purpose, so if
it's going to cause huge trouble on some systems, we should just not do
it.

[Guenter Roeck]

Post by Jean Delvare
Hi Numan,

Post by Numan DEMİRDÖĞEN
After using sensors-detect for the first time, screen's vertical rate
turned to 1023 from 800. The original resolution of screen is
1280x800 at 60Hzt but now it is 1280x1023 and I can not change it
whatever I did. I tried xrandr to revert it to original but if I
choose a different rate other than 1280x1023, resolution looks
horrible. It looks like its EDID was also changed.

I'm very sorry about that. Needless to say sensors-detect isn't
supposed to do that. This is the first report ever of EDID corruption,
if that's what it is. This could be caused by a specific uncommon chip
on one of your graphics chip I2C buses, or by a bug in the graphics chip
driver.

[ ... ]

Post by Jean Delvare

Post by Numan DEMİRDÖĞEN
i2cdump output: http://pastebin.com/bCtKEFMq

I'd be more interested in the output of i2cdetect for each but for now.

Post by Numan DEMİRDÖĞEN
i2cdump 2 0x60

Some PMBus chips react very angry to commands like this, and end up
clearing their configuration space to the default factory configuration.
The usual result is that the affected board is dead. Maybe something
similar happened here.

Guenter

[Numan DEMİRDÖĞEN]

Post by Guenter Roeck
Some PMBus chips react very angry to commands like this, and end up
clearing their configuration space to the default factory configuration.
The usual result is that the affected board is dead. Maybe something
similar happened here.
Guenter

Hi Guenter,

Thank you for your interest on my problem.
I gave that command after the problem accured just to provide
information that can be useful to solve the problem.

Sincerely,
Numan

[Numan DEMİRDÖĞEN]

Post by Jean Delvare
Hi Numan,

Hi Jean,

Thank you for your concer on this problem and kindness.

Post by Jean Delvare
* Which version of sensors-detect you used?

Version that I used is:

libsensors4 1:3.3.0-4ubuntu1
lm-sensors 1:3.3.0-4ubuntu1

Post by Jean Delvare
* Did you leave the default answer to every question, or did you ask
?for probing which was disabled by default?

I answered all questions to yes.

Post by Jean Delvare
I see you're using the radeon driver on a RV380 chip. Do I understand
correctly that this is a laptop and the screen you're talking about is
the laptop's own screen? Fujitsu-Siemens Amilo Pro V2045, right?

Yes, it is a laptop and I am talking about it's screen. It is a
Fujitsu-Siemens Amilo Pro V2045.

Post by Jean Delvare
It would be great if you could dig your logs for a dump of your EDID _before_ the corruption. The radeon driver logs this
to /var/log/Xorg.0.log. If you can't find that, it would be great to find another user with the same laptop who could provide > this dump.

Unfortunately, there is no dump of EDID in the Xorg.0.log. My screen
is a SAMSUNG LTN 154X3-L01.
Here is the Xorg.0.log output: http://pastebin.com/7Y2wRWpg
But, fortunately, I found some dump of EDID: http://pastebin.com/HDTG4T2W
There are 3 more of like this and they belong to same monitor, SAMSUNG
LTN 154X3-L01. They have same manufacturer, model, EDID version and
product year. All of this dump of EDID are exactly same.

Post by Jean Delvare
First run xrandr --verbose to have the detailed timings for 1280x1023, and then use --newmode with 1023 replaced by > > 800

I took your advice and gave xrandr --newmode "try" 68.9 1280 1296 1544
1408 800 1024 1027 1039 command ( replaced 1023 with 800) Now, it is
better. I mean before this command, I could not see the bottom of
applications if I used them maximized but now I can see a little bit
of bottom of applications.
I thought i2cdump output would be usefull so I added them.
I loaded i2c-dev, eeprom and radeonfb modules than gave i2cdetect,
here is the output: http://pastebin.com/4fK1Y4P9

Post by Jean Delvare
I suspect you meant 0x50, not 0x60. Please try that and report. I would also need the (bogus) EDID dump from /var/log
/Xorg.0.log.

Sorry, here is the result that you wanted:

sudo i2cdump 2 0x50
No size specified (using byte-data access)
Error: Could not set address to 0x50: Device or resource busy

[Jean Delvare]

Hi Numan,

Sorry for the late reply, I have a lot of work this week.

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
* Did you leave the default answer to every question, or did you ask
?for probing which was disabled by default?

I answered all questions to yes.

I presume you do not remember which ones defaulted to "no" and you had
to say "yes" explicitly?

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
I see you're using the radeon driver on a RV380 chip. Do I understand
correctly that this is a laptop and the screen you're talking about is
the laptop's own screen? Fujitsu-Siemens Amilo Pro V2045, right?

Yes, it is a laptop and I am talking about it's screen. It is a
Fujitsu-Siemens Amilo Pro V2045.

Post by Jean Delvare
It would be great if you could dig your logs for a dump of your EDID _before_ the corruption. The radeon driver logs this
to /var/log/Xorg.0.log. If you can't find that, it would be great to find another user with the same laptop who could provide > this dump.

Unfortunately, there is no dump of EDID in the Xorg.0.log.

It's strange, I do see it in mine with the radeon driver:

[ 7.942] (II) RADEON(0): EDID for output DVI-0
(...)
[ 7.943] (II) RADEON(0): EDID (in hex):
[ 7.943] (II) RADEON(0): 00ffffffffffff001e6d7d58c3750600
[ 7.943] (II) RADEON(0): 0915010380331d78ea5ea5a2554da026
[ 7.943] (II) RADEON(0): 115054a76b80b30081808140714f0101
[ 7.943] (II) RADEON(0): 010101010101023a801871382d40582c
[ 7.943] (II) RADEON(0): 4500fe221100001e000000fd00384b1e
[ 7.943] (II) RADEON(0): 530f000a202020202020000000fc0049
[ 7.943] (II) RADEON(0): 50533233350a202020202020000000ff
[ 7.943] (II) RADEON(0): 003130394d41464343463336330a008c

Maybe there is a verbosity level to set somewhere, my X server is
started with -verbose, maybe you have to do the same. Or

Post by Numan DEMİRDÖĞEN
My screen is a SAMSUNG LTN 154X3-L01.
Here is the Xorg.0.log output: http://pastebin.com/7Y2wRWpg
But, fortunately, I found some dump of EDID: http://pastebin.com/HDTG4T2W
There are 3 more of like this and they belong to same monitor, SAMSUNG
LTN 154X3-L01. They have same manufacturer, model, EDID version and
product year. All of this dump of EDID are exactly same.

Good, so at least we have a reference. Now we need to find out which
bytes in your own EDID have been altered.

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
First run xrandr --verbose to have the detailed timings for 1280x1023, and then use --newmode with 1023 replaced by
800

I took your advice and gave xrandr --newmode "try" 68.9 1280 1296 1544
1408 800 1024 1027 1039 command ( replaced 1023 with 800) Now, it is
better. I mean before this command, I could not see the bottom of
applications if I used them maximized but now I can see a little bit
of bottom of applications.

You also have to offset the 3 other vertical timings:

$ xrandr --newmode "try" 68.94 1280 1296 1344 1408 800 801 804 816 -HSync -VSync

Post by Numan DEMİRDÖĞEN
I thought i2cdump output would be usefull so I added them.
I loaded i2c-dev, eeprom and radeonfb modules than gave i2cdetect,
here is the output: http://pastebin.com/4fK1Y4P9

Post by Jean Delvare
I suspect you meant 0x50, not 0x60. Please try that and report. I would also need the (bogus) EDID dump from /var/log
/Xorg.0.log.

sudo i2cdump 2 0x50
No size specified (using byte-data access)
Error: Could not set address to 0x50: Device or resource busy

That's because you have loaded the eeprom driver. Either provide the
contents of file /sys/bus/i2c/devices/i2c-2/2-0050/eeprom or unload the
eeprom driver and provide the output of the i2cdump command above.

[Numan DEMİRDÖĞEN]

Post by Jean Delvare
Sorry for the late reply, I have a lot of work this week.

It is ok, take your time:)

Post by Jean Delvare
I presume you do not remember which ones defaulted to "no" and you had
to say "yes" explicitly?

Yes, that is what I did.

Post by Jean Delvare
Maybe there is a verbosity level to set somewhere, my X server is
started with -verbose, maybe you have to do the same. Or

I stopped X and gave "exec /usr/bin/X -nolisten tcp "$@" -verbose 20
2> /tmp/startx.log" command but still there is no dump of EDID.

Post by Jean Delvare
Good, so at least we have a reference. Now we need to find out which
bytes in your own EDID have been altered.
$ xrandr --newmode "try" 68.94 1280 1296 1344 1408 800 801 804 816 -HSync -VSync

Now I get what you wanted me to do. I tried the command above but
resolution looks bad. Icons, fonts etc. looks blur and bigger.

Post by Jean Delvare
That's because you have loaded the eeprom driver. Either provide the
contents of file /sys/bus/i2c/devices/i2c-2/2-0050/eeprom or unload the
eeprom driver and provide the output of the i2cdump command above.

Sorry, my mistake. This is the output: http://pastebin.com/aSUSR7wX

Best regards,
Numan

[Jean Delvare]

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
Maybe there is a verbosity level to set somewhere, my X server is
started with -verbose, maybe you have to do the same. Or

2> /tmp/startx.log" command but still there is no dump of EDID.

Maybe this is because the EDID is corrupted and thus the checksum is
incorrect.

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
Good, so at least we have a reference. Now we need to find out which
bytes in your own EDID have been altered.
$ xrandr --newmode "try" 68.94 1280 1296 1344 1408 800 801 804 816 -HSync -VSync

Now I get what you wanted me to do. I tried the command above but
resolution looks bad. Icons, fonts etc. looks blur and bigger.

Very odd, given that this is the exact modeline computed from the
original EDID.

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
That's because you have loaded the eeprom driver. Either provide the
contents of file /sys/bus/i2c/devices/i2c-2/2-0050/eeprom or unload the
eeprom driver and provide the output of the i2cdump command above.

Sorry, my mistake. This is the output: http://pastebin.com/aSUSR7wX

Note the XX in the dump, which means an error occurred on the bus.
Please check your kernel logs to see if there is an error message
corresponding to this failure. If the I2C bus is unreliable, this could
explain in part the trouble you had.

Comparing the original EDID with your tampered copy shows 6 bytes that
are now 0xff instead of the value they used to hold:

0x2b: 0x01 -> 0xff
0x2e: 0x01 -> 0xff
0x2f: 0x01 -> 0xff
0x3b: 0x20 -> 0xff
0x3f: 0x30 -> 0xff
0x78: 0x33 -> 0xff

FWIW, this doesn't correspond to a specific pattern for sensors-detect,
which accesses the following offsets for probing this specific address:
0x00-0x07 and 0x3d-0x3f. So I still have no idea what happened and why.

Assuming your EDID EEPROM is writable, the following commands (as root)
should restore its original state:

# rmmod eeprom
# i2cset -y 2 0x50 0x2b 0x01 b
# i2cset -y 2 0x50 0x2e 0x01 b
# i2cset -y 2 0x50 0x2f 0x01 b
# i2cset -y 2 0x50 0x3b 0x20 b
# i2cset -y 2 0x50 0x3f 0x30 b
# i2cset -y 2 0x50 0x78 0x33 b

You can check with i2cdump afterward. I'd even check after fixing the
first byte, as there is no point in going on if the first write failed

Let's hope it does the trick...

[Numan DEMİRDÖĞEN]

Post by Jean Delvare
Note the XX in the dump, which means an error occurred on the bus.
Please check your kernel logs to see if there is an error message
corresponding to this failure. If the I2C bus is unreliable, this could
explain in part the trouble you had.

I read /var/log/dmesg.log and kern.log but I could not see an error or
warning related to anything or I do not have the capability to see.

Post by Jean Delvare
Comparing the original EDID with your tampered copy shows 6 bytes that
0x2b: 0x01 -> 0xff
0x2e: 0x01 -> 0xff
0x2f: 0x01 -> 0xff
0x3b: 0x20 -> 0xff
0x3f: 0x30 -> 0xff
0x78: 0x33 -> 0xff
FWIW, this doesn't correspond to a specific pattern for sensors-detect,
0x00-0x07 and 0x3d-0x3f. So I still have no idea what happened and why.

Maybe, this is a hardware problem and is a coincidence so that the
time I use sensors-detect, the screen is "broken".

Post by Jean Delvare
Assuming your EDID EEPROM is writable, the following commands (as root)
# rmmod eeprom
# i2cset -y 2 0x50 0x2b 0x01 b
# i2cset -y 2 0x50 0x2e 0x01 b
# i2cset -y 2 0x50 0x2f 0x01 b
# i2cset -y 2 0x50 0x3b 0x20 b
# i2cset -y 2 0x50 0x3f 0x30 b
# i2cset -y 2 0x50 0x78 0x33 b
You can check with i2cdump afterward. I'd even check after fixing the
first byte, as there is no point in going on if the first write failed

Those commands worked without any error, I checked with i2cdump after
first and last command. Rebooted but it is still using 1280x1023.

I tried "radeon.modeset=0" parameter in grub and looked at
/var/log/Xorg.0.log, it shows that

II) RADEON(0): Panel Size from BIOS: 1280x1023
[ 16.704] (II) RADEON(0): BIOS provided dividers will be used.
(WW) RADEON(0): LVDS Info:
XRes: 1280, YRes: 1023, DotClock: 68940
HBlank: 128, HOverPlus: 16, HSyncWidth: 248
VBlank: 16, VOverPlus: 1, VSyncWidth: 3

and with radeon enabled

[ 14.238369] [drm] Panel Size 1280x1023
16.560] (II) RADEON(0): Output LVDS using initial mode 1280x1023

If I use xrandr --outpur LVDS --mode "try", /var/log/Xorg.0.log says

[ 1644.860] (II) RADEON(0): Allocate new frame buffer 1280x800 stride 1280
[ 1644.860] (II) RADEON(0): VRAM usage limit set to 50547K

[Jean Delvare]

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
Note the XX in the dump, which means an error occurred on the bus.
Please check your kernel logs to see if there is an error message
corresponding to this failure. If the I2C bus is unreliable, this could
explain in part the trouble you had.

I read /var/log/dmesg.log and kern.log but I could not see an error or
warning related to anything or I do not have the capability to see.

Post by Jean Delvare
Comparing the original EDID with your tampered copy shows 6 bytes that
0x2b: 0x01 -> 0xff
0x2e: 0x01 -> 0xff
0x2f: 0x01 -> 0xff
0x3b: 0x20 -> 0xff
0x3f: 0x30 -> 0xff
0x78: 0x33 -> 0xff
FWIW, this doesn't correspond to a specific pattern for sensors-detect,
0x00-0x07 and 0x3d-0x3f. So I still have no idea what happened and why.

Maybe, this is a hardware problem and is a coincidence so that the
time I use sensors-detect, the screen is "broken".

Coincidence, I don't think. sensors-detect is exercising the I2C buses
a lot, so if there was any latent problem with the I2C bus on your
Radeon graphics chip, I'm not surprised if it was triggered by
sensors-detect.

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
Assuming your EDID EEPROM is writable, the following commands (as root)
# rmmod eeprom
# i2cset -y 2 0x50 0x2b 0x01 b
# i2cset -y 2 0x50 0x2e 0x01 b
# i2cset -y 2 0x50 0x2f 0x01 b
# i2cset -y 2 0x50 0x3b 0x20 b
# i2cset -y 2 0x50 0x3f 0x30 b
# i2cset -y 2 0x50 0x78 0x33 b
You can check with i2cdump afterward. I'd even check after fixing the
first byte, as there is no point in going on if the first write failed

Those commands worked without any error, I checked with i2cdump after
first and last command. Rebooted but it is still using 1280x1023.

What did the i2cdump outputs look like? Did you see the offending
offset values change from 0xff to the values you passed on the command
line?

Did you try i2cdump again after rebooting, to make sure the writes
stuck?

Post by Numan DEMİRDÖĞEN
I tried "radeon.modeset=0" parameter in grub and looked at
/var/log/Xorg.0.log, it shows that
II) RADEON(0): Panel Size from BIOS: 1280x1023
[ 16.704] (II) RADEON(0): BIOS provided dividers will be used.
XRes: 1280, YRes: 1023, DotClock: 68940
HBlank: 128, HOverPlus: 16, HSyncWidth: 248
VBlank: 16, VOverPlus: 1, VSyncWidth: 3
and with radeon enabled
[ 14.238369] [drm] Panel Size 1280x1023
16.560] (II) RADEON(0): Output LVDS using initial mode 1280x1023
If I use xrandr --outpur LVDS --mode "try", /var/log/Xorg.0.log says
[ 1644.860] (II) RADEON(0): Allocate new frame buffer 1280x800 stride 1280
[ 1644.860] (II) RADEON(0): VRAM usage limit set to 50547K

Did you only reboot the machine? Please try cold booting it, even
remove the battery and unplug the power cord for 10 minutes if needed.
Maybe the BIOS only reads the EDID once at cold boot.

BTW, when the problem happened originally, did it happen while
sensors-detect was running, or after next reboot, or after next cold
boot?

[Numan DEMİRDÖĞEN]

Post by Jean Delvare
What did the i2cdump outputs look like? Did you see the offending
offset values change from 0xff to the values you passed on the command
line?
Did you try i2cdump again after rebooting, to make sure the writes
stuck?

Yes, I saw them changed and after rebooted I gave commands again.
Last i2cdump output: http://pastebin.com/pyC0j5ug
It seems that some values returned ff again.

Post by Jean Delvare
Did you only reboot the machine? Please try cold booting it, even
remove the battery and unplug the power cord for 10 minutes if needed.
Maybe the BIOS only reads the EDID once at cold boot.

I had just rebooted machine but now I did cold boot by removing
battery and unpluging power cord.

Post by Jean Delvare
BTW, when the problem happened originally, did it happen while
sensors-detect was running, or after next reboot, or after next cold
boot?

After next cold boot, the problem happaned. When sensors-detect
finished, I hust read some .pdf files then shut the computer down. The
next boot was after about 8 hours later.

Best regards,
Numan

[Jean Delvare]

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
What did the i2cdump outputs look like? Did you see the offending
offset values change from 0xff to the values you passed on the command
line?
Did you try i2cdump again after rebooting, to make sure the writes
stuck?

Yes, I saw them changed and after rebooted I gave commands again.
Last i2cdump output: http://pastebin.com/pyC0j5ug
It seems that some values returned ff again.

Indeed, two of the 6 writes stuck, but the ones at 0x2b and 0x2f did
not. Can you just try these two again and see if it works better this
time (after a cold boot)?

[Jean Delvare]

Post by Jean Delvare

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
What did the i2cdump outputs look like? Did you see the offending
offset values change from 0xff to the values you passed on the command
line?
Did you try i2cdump again after rebooting, to make sure the writes
stuck?

Yes, I saw them changed and after rebooted I gave commands again.
Last i2cdump output: http://pastebin.com/pyC0j5ug
It seems that some values returned ff again.

Indeed, two of the 6 writes stuck, but the ones at 0x2b and 0x2f did
not. Can you just try these two again and see if it works better this
time (after a cold boot)?

Hm, I meant: at 0x3b and 0x3f.

[Numan DEMİRDÖĞEN]

Post by Jean Delvare

Post by Jean Delvare
Indeed, two of the 6 writes stuck, but the ones at 0x2b and 0x2f did
not. Can you just try these two again and see if it works better this
time (after a cold boot)?

Hm, I meant: at 0x3b and 0x3f.

I gave related commands and after that made a cold boot but resolution
did not changed.
New i2cdump: http://pastebin.com/KExUrapp

[Jean Delvare]

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare

Post by Jean Delvare
Indeed, two of the 6 writes stuck, but the ones at 0x2b and 0x2f did
not. Can you just try these two again and see if it works better this
time (after a cold boot)?

Hm, I meant: at 0x3b and 0x3f.

I gave related commands and after that made a cold boot but resolution
did not changed.
New i2cdump: http://pastebin.com/KExUrapp

Hmm. I'm afraid I am somewhat out of ideas. I just can't get why you
would be able to write at some offsets and not others :( Unfortunately
the critical one here is 0x3b.

One trick we can try is writing words instead of bytes, but honestly
the hope is rather low that it will work any better:

# i2cset -y 2 0x50 0x3a 0x2050 w
# i2cset -y 2 0x50 0x3e 0x3010 w

[Numan DEMİRDÖĞEN]

Post by Jean Delvare

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare

Post by Jean Delvare
Indeed, two of the 6 writes stuck, but the ones at 0x2b and 0x2f did
not. Can you just try these two again and see if it works better this
time (after a cold boot)?

Hm, I meant: at 0x3b and 0x3f.

I gave related commands and after that made a cold boot but resolution
did not changed.
New i2cdump: http://pastebin.com/KExUrapp

Hmm. I'm afraid I am somewhat out of ideas. I just can't get why you
would be able to write at some offsets and not others :( Unfortunately
the critical one here is 0x3b.
One trick we can try is writing words instead of bytes, but honestly
# i2cset -y 2 0x50 0x3a 0x2050 w
# i2cset -y 2 0x50 0x3e 0x3010 w
--
Jean Delvare

As you said, it did not take an effect on it.
I really appreciate your effort, thank you very much.
I will try to upgrade BIOS. If it solves the issue, I will feed back.

Best regards,
Numan

[Jean Delvare]

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare

Post by Numan DEMİRDÖĞEN
I gave related commands and after that made a cold boot but resolution
did not changed.
New i2cdump: http://pastebin.com/KExUrapp

Hmm. I'm afraid I am somewhat out of ideas. I just can't get why you
would be able to write at some offsets and not others :( Unfortunately
the critical one here is 0x3b.
One trick we can try is writing words instead of bytes, but honestly
# i2cset -y 2 0x50 0x3a 0x2050 w
# i2cset -y 2 0x50 0x3e 0x3010 w

As you said, it did not take an effect on it.
I really appreciate your effort, thank you very much.
I will try to upgrade BIOS. If it solves the issue, I will feed back.

Hm, OK :( Meanwhile I had one more idea. From your original post it seems

Post by Numan DEMİRDÖĞEN
i2c-0 i2c Radeon i2c bit bus DVI_DDC I2C adapter
i2c-1 i2c Radeon i2c bit bus VGA_DDC I2C adapter
i2c-2 i2c Radeon i2c hw bus MM_I2C I2C adapter
i2c-3 i2c Radeon i2c bit bus MONID I2C adapter

i2c-2 is precisely the I2C bus where your EDID is and where the problem
happened. AFAIK hw_i2c is off by default, so please check why and how
it was enabled. Then you may try to turn if off to force software
operation of the I2C bus (i2cdetect -l should show that), and then do
the i2cset commands again and see if it works. Again my hope level is
low but I think it is worth trying.

[Numan DEMİRDÖĞEN]

Post by Jean Delvare
i2c-2 is precisely the I2C bus where your EDID is and where the problem
happened. AFAIK hw_i2c is off by default, so please check why and how
it was enabled. Then you may try to turn if off to force software
operation of the I2C bus (i2cdetect -l should show that), and then do
the i2cset commands again and see if it works. Again my hope level is
low but I think it is worth trying.
--
Jean Delvare

modinfo -p radeon shows that:
hw_i2c:hw i2c engine enable (0 = disable) (int)

So I wrote radeon_hw_i2c=0 to grub command line, then gave the i2cset
commands, but it did not work. I also tried radeon.modeset=0 to find
out whether the culprit radeon's itself, this also did not work.

[Jean Delvare]

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
i2c-2 is precisely the I2C bus where your EDID is and where the problem
happened. AFAIK hw_i2c is off by default, so please check why and how
it was enabled. Then you may try to turn if off to force software
operation of the I2C bus (i2cdetect -l should show that), and then do
the i2cset commands again and see if it works. Again my hope level is
low but I think it is worth trying.
--
Jean Delvare

hw_i2c:hw i2c engine enable (0 = disable) (int)
So I wrote radeon_hw_i2c=0 to grub command line, then gave the i2cset

I hope you did not do that but rather radeon.hw_i2c=0. Did you check
with "i2cdetect -l" that hw_i2c wasn't used?

Post by Numan DEMİRDÖĞEN
commands, but it did not work. I also tried radeon.modeset=0 to find
out whether the culprit radeon's itself, this also did not work.

with modeset=0 I presume you can't see the i2c buses at all so this
doesn't really help.

Meanwhile I found a post from someone who had the same problem:
http://lists.freedesktop.org/archives/xorg/2011-January/052239.html

This would confirm that sensors-detect was only the trigger rather than
the root cause of the corruption. I'll talk to the radeon driver
maintainer on Tuesday.

[Numan DEMİRDÖĞEN]

Post by Jean Delvare
I hope you did not do that but rather radeon.hw_i2c=0. Did you check
with "i2cdetect -l" that hw_i2c wasn't used?

I actually wrote radeon.hw_i2c=0 but wrote wrongly in e-mail.
Although I used redeon.hw_i2c=0 oarameter, i2cdetect -l shows

i2c-2 i2c Radeon i2c hw bus MM_I2C I2C adapter

I read xorg.0.log and dmesg.log to check that whether radeon.hw_i2c=0
works or not, there was not any lien that complaining radeon.hw_i2c=0
was not working. So I presumed it worked.

Post by Jean Delvare
http://lists.freedesktop.org/archives/xorg/2011-January/052239.html
This would confirm that sensors-detect was only the trigger rather than
the root cause of the corruption. I'll talk to the radeon driver
maintainer on Tuesday.
--
Jean Delvare

Thank you Jean, I appreciate your help.

[Jean Delvare]

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
I hope you did not do that but rather radeon.hw_i2c=0. Did you check
with "i2cdetect -l" that hw_i2c wasn't used?

I actually wrote radeon.hw_i2c=0 but wrote wrongly in e-mail.
Although I used redeon.hw_i2c=0 oarameter, i2cdetect -l shows
i2c-2 i2c Radeon i2c hw bus MM_I2C I2C adapter
I read xorg.0.log and dmesg.log to check that whether radeon.hw_i2c=0
works or not, there was not any lien that complaining radeon.hw_i2c=0
was not working. So I presumed it worked.

You can check the value of /sys/module/radeon/parameters/hw_i2c.

[Numan DEMİRDÖĞEN]

Post by Jean Delvare
You can check the value of /sys/module/radeon/parameters/hw_i2c.
Jean Delvare

cat /sys/module/radeon/parameters/hw_i2c
0
So it works. Thank you.

[Jean Delvare]

Hi Numan,

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
You can check the value of /sys/module/radeon/parameters/hw_i2c.

cat /sys/module/radeon/parameters/hw_i2c
0
So it works. Thank you.

OK. But now this makes me very curious about two things (probably
related) :

* Do you see any mention of "i2c hw bus" in the output of
"i2cdetect -l" in the case above (i.e. radeon.hw_i2c=0 has been
passed to grub)?

* What is the value of /sys/module/radeon/parameters/hw_i2c when you do
NOT pass radeon.hw_i2c=0 to grub?

If the radeon driver uses hardware I2C engines when told not to, that
would be a bug.

[Jean Delvare]

Post by Jean Delvare
Hi Numan,

Post by Numan DEMİRDÖĞEN

Post by Jean Delvare
You can check the value of /sys/module/radeon/parameters/hw_i2c.

cat /sys/module/radeon/parameters/hw_i2c
0
So it works. Thank you.

OK. But now this makes me very curious about two things (probably
* Do you see any mention of "i2c hw bus" in the output of
"i2cdetect -l" in the case above (i.e. radeon.hw_i2c=0 has been
passed to grub)?
* What is the value of /sys/module/radeon/parameters/hw_i2c when you do
NOT pass radeon.hw_i2c=0 to grub?
If the radeon driver uses hardware I2C engines when told not to, that
would be a bug.

Scratch this, I discussed with Alex Deucher and he explained that there
is no possibility to access the MM i2c bus with software bit-banging,
the hardware engine is the only way to go and this is why the hw_i2c
option has no effect on this bus.

Unfortunately he didn't have any explanation for what happened. All he
could suggest was that maybe some EEPROM cells went dead when the
problem happened, and that's why we can't write the proper values back.
This is indeed a possibility, which unfortunately means there's nothing
we can do to restore your EDID. Sorry :(

[Numan DEMİRDÖĞEN]

Post by Jean Delvare
Scratch this, I discussed with Alex Deucher and he explained that there
is no possibility to access the MM i2c bus with software bit-banging,
the hardware engine is the only way to go and this is why the hw_i2c
option has no effect on this bus.
Unfortunately he didn't have any explanation for what happened. All he
could suggest was that maybe some EEPROM cells went dead when the
problem happened, and that's why we can't write the proper values back.
This is indeed a possibility, which unfortunately means there's nothing
we can do to restore your EDID. Sorry :(
--
Jean Delvare

Hi Jean,

If that is the case, I will try to get use to use laptop in the
current condition.

I thank you very much for all of your effort and help.

Yours sincerely,
Numan