* [lm-sensors] Trouble with sensors-detect probing ASUS 1015E-DS03 laptop
@ 2013-08-25 0:32 Larry Lade
2013-08-25 1:51 ` Guenter Roeck
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Larry Lade @ 2013-08-25 0:32 UTC (permalink / raw)
To: lm-sensors
Hi,
I wanted to report an alarming issue running sensors-detect on my new
(Ubuntu 12.04 out of the box!) laptop.
sensors-detect revision 5984 (2011-07-10 21:22:53 +0200)
System:ASUSTeK COMPUTER INC. 1015E (laptop)
I take the default "YES" to all detections. The only thing that comes
up is "coretemp", until it tries to probe I2C/SMBus adapters.
Found unknown SMBus adapter 8086:1e22 at 0000:00:1f.3.
Sorry, no supported PCI bus adapters found
...
Next adapter: i915 gmbus panel (i2c-5)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x4f
Probing for `National Semiconductor LM75'... No
Probing for `National Semiconductor LM75A'... No
Probing for `Dallas Semiconductor DS75'... No
Probing for `Dallas Semiconductor DS1621/DS1631'... No
Probing for `Maxim MAX6642'... No
Probing for `Texas Instruments TMP421'... No
Probing for `Texas Instruments TMP422'... No
Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
Probing for `NXP/Philips SA56004'... No
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Probing for `EDID EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Next adapter: i915 GPIOC (i2c-6)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x4f
Probing for `National Semiconductor LM75'... No
Probing for `National Semiconductor LM75A'... No
Probing for `Dallas Semiconductor DS75'... No
Probing for `Dallas Semiconductor DS1621/DS1631'... No
Probing for `Maxim MAX6642'... No
Probing for `Texas Instruments TMP421'... No
Probing for `Texas Instruments TMP422'... No
Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
Probing for `NXP/Philips SA56004'... No
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... No
Probing for `EDID EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
At some point during one of these scans, there's a flash and SOMETHING
happens to the built-in LCD screen. I noticed it's as though the gamma
was all out of whack, the colors were washed out, and dithering
becomes notable everywhere. (Bad even for an 18-bit LCD.) Display
looks fine on an LCD connected by VGA port.
This change survived the re-install of the operating system.
I was getting desperate, thinking I had just zapped something and
voided the hardware, so I ran sensors-detect again. Probing either of
the two above adapters (they both seem to reference the same bit of
hardware) seemed to toggle something, restoring or corrupting the
screen quality.
Or at least it did. It seems to have it stuck in "ugly" mode again,
and nothing on the display toggles any more when I run sensors-detect
any more. Is anyone able to help?
The LCD seems to be an AUO B101XTN01 (as reported by the EDID)
http://www.panelook.com/B101XTN01.0_AUO_10.1_LCM_parameter_19387.html
lm-sensors 1:3.3.1-2ubuntu1
linux 3.2.0-52-generic #78-Ubuntu SMP x86_64
$ sudo get-edid | parse-edid:
# EDID version 1 revision 4
Section "Monitor"
# Block type: 2:0 3:f
# Block type: 2:0 3:fe
# Block type: 2:0 3:fe
Identifier "AUO:dc11"
VendorName "AUO"
ModelName "AUO:dc11"
# Block type: 2:0 3:f
# Block type: 2:0 3:fe
# Block type: 2:0 3:fe
# DPMS capabilities: Active off:no Suspend:no Standby:no
Mode "1366x768" # vfreq 60.041Hz, hfreq 47.913kHz
DotClock 76.660000
HTimings 1366 1404 1426 1600
VTimings 768 771 777 798
Flags "-HSync" "-VSync"
EndMode
# Block type: 2:0 3:f
# Block type: 2:0 3:fe
# Block type: 2:0 3:fe
EndSection
$ sudo i2cdetect 5
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-5.
I will probe address range 0x03-0x77.
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4f
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
$ sudo i2cdump 5 0x4f
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-5, address 0x4f, mode byte
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
$ sudo i2cdump 5 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-5, address 0x50, mode byte
Continue? [Y/n]
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 06 af dc 11 00 00 00 00 ........????....
10: 00 16 01 04 90 16 0d 78 02 bb f5 94 55 54 90 27 .??????x????UT?'
20: 23 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 #PT...??????????
30: 01 01 01 01 01 01 f2 1d 56 ea 50 00 1e 30 26 16 ????????V?P.?0&?
40: 36 00 de 7d 00 00 00 18 00 00 00 0f 00 00 00 00 6.?}...?...?....
50: 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41 ......... ...?.A
60: 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe UO? ...?
70: 00 42 31 30 31 58 54 4e 30 31 2e 31 20 0a 00 dd .B101XTN01.1 ?.?
80: ff ff ff ff ff ff ff ff ff ff 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 ................
$ lsmod
Module Size Used by
pci_stub 12622 1
vboxpci 23237 0
vboxnetadp 13382 0
uvcvideo 72627 0
vboxnetflt 23478 0
videodev 98259 1 uvcvideo
vboxdrv 287130 3 vboxpci,vboxnetadp,vboxnetflt
v4l2_compat_ioctl32 17128 1 videodev
snd_hda_codec_hdmi 36727 1
snd_hda_codec_realtek 78471 1
bcma 26696 0
arc4 12529 2
joydev 17693 0
dm_multipath 23275 0
snd_hda_intel 39382 3
snd_hda_codec 140267 3
snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 17764 1 snd_hda_codec
snd_pcm 97275 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_seq_midi 13324 0
snd_rawmidi 30748 1 snd_seq_midi
snd_seq_midi_event 14899 1 snd_seq_midi
snd_seq 61929 2 snd_seq_midi,snd_seq_midi_event
snd_timer 29990 2 snd_pcm,snd_seq
snd_seq_device 14540 3 snd_seq_midi,snd_rawmidi,snd_seq
snd 79041 16
snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
psmouse 97519 0
brcmsmac 570930 0
mac80211 506862 1 brcmsmac
alx 81350 0
serio_raw 13211 0
i915 461962 3
compat 13447 1 alx
soundcore 15091 1 snd
brcmutil 15139 1 brcmsmac
cfg80211 205774 2 brcmsmac,mac80211
crc8 12893 1 brcmsmac
cordic 12574 1 brcmsmac
drm_kms_helper 46978 1 i915
snd_page_alloc 18529 2 snd_hda_intel,snd_pcm
drm 241971 4 i915,drm_kms_helper
mei 41616 0
i2c_algo_bit 13423 1 i915
rfcomm 47604 0
bnep 18281 2
parport_pc 32866 0
bluetooth 180113 10 rfcomm,bnep
ppdev 17113 0
video 19651 1 i915
binfmt_misc 17540 1
nls_iso8859_1 12713 2
nls_cp437 16991 2
mac_hid 13253 0
vfat 17585 2
fat 61512 1 vfat
asus_nb_wmi 16990 0
asus_wmi 24392 1 asus_nb_wmi
wmi 19256 1 asus_wmi
sparse_keymap 13890 1 asus_wmi
lp 17799 0
parport 46562 3 parport_pc,ppdev,lp
usb_storage 49198 1
dm_raid45 78155 0
xor 12894 1 dm_raid45
dm_mirror 22203 0
dm_region_hash 20961 1 dm_mirror
dm_log 18564 3 dm_raid45,dm_mirror,dm_region_hash
dmesg currently dumping this during probe of 0x4f:
[ 783.847244] i2c i2c-6: sendbytes: NAK bailout.
[ 783.848321] i2c i2c-6: sendbytes: NAK bailout.
[ 783.849399] i2c i2c-6: sendbytes: NAK bailout.
[ 783.850497] i2c i2c-6: sendbytes: NAK bailout.
[ 783.851666] i2c i2c-6: sendbytes: NAK bailout.
[ 783.852746] i2c i2c-6: sendbytes: NAK bailout.
[ 783.853827] i2c i2c-6: sendbytes: NAK bailout.
[ 783.854908] i2c i2c-6: sendbytes: NAK bailout.
[ 783.855988] i2c i2c-6: sendbytes: NAK bailout.
[ 783.857065] i2c i2c-6: sendbytes: NAK bailout.
[ 783.858150] i2c i2c-6: sendbytes: NAK bailout.
[ 783.859230] i2c i2c-6: sendbytes: NAK bailout.
[ 783.860306] i2c i2c-6: sendbytes: NAK bailout.
[ 783.861383] i2c i2c-6: sendbytes: NAK bailout.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [lm-sensors] Trouble with sensors-detect probing ASUS 1015E-DS03 laptop
2013-08-25 0:32 [lm-sensors] Trouble with sensors-detect probing ASUS 1015E-DS03 laptop Larry Lade
@ 2013-08-25 1:51 ` Guenter Roeck
2013-08-29 10:02 ` Jean Delvare
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Guenter Roeck @ 2013-08-25 1:51 UTC (permalink / raw)
To: lm-sensors
On 08/24/2013 05:32 PM, Larry Lade wrote:
> Hi,
>
> I wanted to report an alarming issue running sensors-detect on my new
> (Ubuntu 12.04 out of the box!) laptop.
>
> sensors-detect revision 5984 (2011-07-10 21:22:53 +0200)
> System:ASUSTeK COMPUTER INC. 1015E (laptop)
>
> I take the default "YES" to all detections. The only thing that comes
> up is "coretemp", until it tries to probe I2C/SMBus adapters.
>
Problem is most likely that sensors-detect tried to access an i2c chip
on one of the i915 i2c busses which programs lcd parameters.
Reading from its register space may have re-programmed it.
I am not the expert on this - Jean may be able to help.
Scanning of i2c busses on graphics cards is now disabled by default
in sensors-detect, but that version of sensors-detect does not ship
with Ubuntu 12.4.
> Found unknown SMBus adapter 8086:1e22 at 0000:00:1f.3.
> Sorry, no supported PCI bus adapters found
>
This adapter is supported with the i2c-i801 driver. It was already supported
with kernel version 3.2, so it should work for you. More recent versions
of sensors-detect detect it correctly.
Guenter
> ...
>
> Next adapter: i915 gmbus panel (i2c-5)
> Do you want to scan it? (YES/no/selectively):
> Client found at address 0x4f
> Probing for `National Semiconductor LM75'... No
> Probing for `National Semiconductor LM75A'... No
> Probing for `Dallas Semiconductor DS75'... No
> Probing for `Dallas Semiconductor DS1621/DS1631'... No
> Probing for `Maxim MAX6642'... No
> Probing for `Texas Instruments TMP421'... No
> Probing for `Texas Instruments TMP422'... No
> Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
> Probing for `NXP/Philips SA56004'... No
> Client found at address 0x50
> Probing for `Analog Devices ADM1033'... No
> Probing for `Analog Devices ADM1034'... No
> Probing for `SPD EEPROM'... No
> Probing for `EDID EEPROM'... Yes
> (confidence 8, not a hardware monitoring chip)
>
> Next adapter: i915 GPIOC (i2c-6)
> Do you want to scan it? (YES/no/selectively):
> Client found at address 0x4f
> Probing for `National Semiconductor LM75'... No
> Probing for `National Semiconductor LM75A'... No
> Probing for `Dallas Semiconductor DS75'... No
> Probing for `Dallas Semiconductor DS1621/DS1631'... No
> Probing for `Maxim MAX6642'... No
> Probing for `Texas Instruments TMP421'... No
> Probing for `Texas Instruments TMP422'... No
> Probing for `Maxim MAX6633/MAX6634/MAX6635'... No
> Probing for `NXP/Philips SA56004'... No
> Client found at address 0x50
> Probing for `Analog Devices ADM1033'... No
> Probing for `Analog Devices ADM1034'... No
> Probing for `SPD EEPROM'... No
> Probing for `EDID EEPROM'... Yes
> (confidence 8, not a hardware monitoring chip)
>
>
> At some point during one of these scans, there's a flash and SOMETHING
> happens to the built-in LCD screen. I noticed it's as though the gamma
> was all out of whack, the colors were washed out, and dithering
> becomes notable everywhere. (Bad even for an 18-bit LCD.) Display
> looks fine on an LCD connected by VGA port.
>
> This change survived the re-install of the operating system.
>
> I was getting desperate, thinking I had just zapped something and
> voided the hardware, so I ran sensors-detect again. Probing either of
> the two above adapters (they both seem to reference the same bit of
> hardware) seemed to toggle something, restoring or corrupting the
> screen quality.
>
> Or at least it did. It seems to have it stuck in "ugly" mode again,
> and nothing on the display toggles any more when I run sensors-detect
> any more. Is anyone able to help?
>
>
>
>
> The LCD seems to be an AUO B101XTN01 (as reported by the EDID)
> http://www.panelook.com/B101XTN01.0_AUO_10.1_LCM_parameter_19387.html
>
> lm-sensors 1:3.3.1-2ubuntu1
>
> linux 3.2.0-52-generic #78-Ubuntu SMP x86_64
>
>
> $ sudo get-edid | parse-edid:
>
> # EDID version 1 revision 4
> Section "Monitor"
> # Block type: 2:0 3:f
> # Block type: 2:0 3:fe
> # Block type: 2:0 3:fe
> Identifier "AUO:dc11"
> VendorName "AUO"
> ModelName "AUO:dc11"
> # Block type: 2:0 3:f
> # Block type: 2:0 3:fe
> # Block type: 2:0 3:fe
> # DPMS capabilities: Active off:no Suspend:no Standby:no
>
> Mode "1366x768" # vfreq 60.041Hz, hfreq 47.913kHz
> DotClock 76.660000
> HTimings 1366 1404 1426 1600
> VTimings 768 771 777 798
> Flags "-HSync" "-VSync"
> EndMode
> # Block type: 2:0 3:f
> # Block type: 2:0 3:fe
> # Block type: 2:0 3:fe
> EndSection
>
>
> $ sudo i2cdetect 5
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-5.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4f
> 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
>
> $ sudo i2cdump 5 0x4f
> 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-5, address 0x4f, mode byte
> Continue? [Y/n]
> 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
> 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
>
> $ sudo i2cdump 5 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-5, address 0x50, mode byte
> Continue? [Y/n]
> 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 06 af dc 11 00 00 00 00 ........????....
> 10: 00 16 01 04 90 16 0d 78 02 bb f5 94 55 54 90 27 .??????x????UT?'
> 20: 23 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 #PT...??????????
> 30: 01 01 01 01 01 01 f2 1d 56 ea 50 00 1e 30 26 16 ????????V?P.?0&?
> 40: 36 00 de 7d 00 00 00 18 00 00 00 0f 00 00 00 00 6.?}...?...?....
> 50: 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41 ......... ...?.A
> 60: 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe UO? ...?
> 70: 00 42 31 30 31 58 54 4e 30 31 2e 31 20 0a 00 dd .B101XTN01.1 ?.?
> 80: ff ff ff ff ff ff ff ff ff ff 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 ................
>
>
> $ lsmod
>
> Module Size Used by
> pci_stub 12622 1
> vboxpci 23237 0
> vboxnetadp 13382 0
> uvcvideo 72627 0
> vboxnetflt 23478 0
> videodev 98259 1 uvcvideo
> vboxdrv 287130 3 vboxpci,vboxnetadp,vboxnetflt
> v4l2_compat_ioctl32 17128 1 videodev
> snd_hda_codec_hdmi 36727 1
> snd_hda_codec_realtek 78471 1
> bcma 26696 0
> arc4 12529 2
> joydev 17693 0
> dm_multipath 23275 0
> snd_hda_intel 39382 3
> snd_hda_codec 140267 3
> snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
> snd_hwdep 17764 1 snd_hda_codec
> snd_pcm 97275 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
> snd_seq_midi 13324 0
> snd_rawmidi 30748 1 snd_seq_midi
> snd_seq_midi_event 14899 1 snd_seq_midi
> snd_seq 61929 2 snd_seq_midi,snd_seq_midi_event
> snd_timer 29990 2 snd_pcm,snd_seq
> snd_seq_device 14540 3 snd_seq_midi,snd_rawmidi,snd_seq
> snd 79041 16
> snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
> psmouse 97519 0
> brcmsmac 570930 0
> mac80211 506862 1 brcmsmac
> alx 81350 0
> serio_raw 13211 0
> i915 461962 3
> compat 13447 1 alx
> soundcore 15091 1 snd
> brcmutil 15139 1 brcmsmac
> cfg80211 205774 2 brcmsmac,mac80211
> crc8 12893 1 brcmsmac
> cordic 12574 1 brcmsmac
> drm_kms_helper 46978 1 i915
> snd_page_alloc 18529 2 snd_hda_intel,snd_pcm
> drm 241971 4 i915,drm_kms_helper
> mei 41616 0
> i2c_algo_bit 13423 1 i915
> rfcomm 47604 0
> bnep 18281 2
> parport_pc 32866 0
> bluetooth 180113 10 rfcomm,bnep
> ppdev 17113 0
> video 19651 1 i915
> binfmt_misc 17540 1
> nls_iso8859_1 12713 2
> nls_cp437 16991 2
> mac_hid 13253 0
> vfat 17585 2
> fat 61512 1 vfat
> asus_nb_wmi 16990 0
> asus_wmi 24392 1 asus_nb_wmi
> wmi 19256 1 asus_wmi
> sparse_keymap 13890 1 asus_wmi
> lp 17799 0
> parport 46562 3 parport_pc,ppdev,lp
> usb_storage 49198 1
> dm_raid45 78155 0
> xor 12894 1 dm_raid45
> dm_mirror 22203 0
> dm_region_hash 20961 1 dm_mirror
> dm_log 18564 3 dm_raid45,dm_mirror,dm_region_hash
>
> dmesg currently dumping this during probe of 0x4f:
> [ 783.847244] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.848321] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.849399] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.850497] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.851666] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.852746] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.853827] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.854908] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.855988] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.857065] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.858150] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.859230] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.860306] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.861383] i2c i2c-6: sendbytes: NAK bailout.
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
>
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [lm-sensors] Trouble with sensors-detect probing ASUS 1015E-DS03 laptop
2013-08-25 0:32 [lm-sensors] Trouble with sensors-detect probing ASUS 1015E-DS03 laptop Larry Lade
2013-08-25 1:51 ` Guenter Roeck
@ 2013-08-29 10:02 ` Jean Delvare
2013-09-05 1:17 ` Larry Lade
2013-09-05 9:20 ` Jean Delvare
3 siblings, 0 replies; 5+ messages in thread
From: Jean Delvare @ 2013-08-29 10:02 UTC (permalink / raw)
To: lm-sensors
Hi Larry,
On Sat, 24 Aug 2013 19:32:41 -0500, Larry Lade wrote:
> I wanted to report an alarming issue running sensors-detect on my new
> (Ubuntu 12.04 out of the box!) laptop.
> (...)
> At some point during one of these scans, there's a flash and SOMETHING
> happens to the built-in LCD screen. I noticed it's as though the gamma
> was all out of whack, the colors were washed out, and dithering
> becomes notable everywhere. (Bad even for an 18-bit LCD.) Display
> looks fine on an LCD connected by VGA port.
>
> This change survived the re-install of the operating system.
>
> I was getting desperate, thinking I had just zapped something and
> voided the hardware, so I ran sensors-detect again. Probing either of
> the two above adapters (they both seem to reference the same bit of
> hardware) seemed to toggle something, restoring or corrupting the
> screen quality.
>
> Or at least it did. It seems to have it stuck in "ugly" mode again,
> and nothing on the display toggles any more when I run sensors-detect
> any more. Is anyone able to help?
I'm very sorry about this. As Guenter said, we have changed the code
meanwhile to skip graphics adapters by default, and I can only urge
Linux distributions to include that change.
You may try to ask the hardware vendor for help. After all they did
ship the software which broke the laptop, right? Even though they did
not write it. I am willing to help but the problem is that it will be
very difficult, if not impossible, to do so without intimate knowledge
of the hardware, which only the vendor can provide. I would be very
happy to cooperate with Asus on that matter if they want to. Only Asus
knows exactly which I2C chips are connected to the graphics chip, at
what address, and if any of them could be responsible for what you
observe.
Meanwhile, the first thing to try here is:
* Shut down the machine.
* Remove the battery.
* Unplug the AC adapter.
* Let the laptop rest that way for a moment, at least 10 minutes.
* Plug everything back and start the machine.
This has restored systems for me and others in the past, I can only
hope it helps for you as well.
If it does not, then if the laptop is new, I think I would just play
the support/warranty card.
You can also try changing the gamma setting with xrandr.
> The LCD seems to be an AUO B101XTN01 (as reported by the EDID)
> http://www.panelook.com/B101XTN01.0_AUO_10.1_LCM_parameter_19387.html
>
> lm-sensors 1:3.3.1-2ubuntu1
>
> linux 3.2.0-52-generic #78-Ubuntu SMP x86_64
>
>
> $ sudo get-edid | parse-edid:
>
> # EDID version 1 revision 4
> Section "Monitor"
> # Block type: 2:0 3:f
> # Block type: 2:0 3:fe
> # Block type: 2:0 3:fe
> Identifier "AUO:dc11"
> VendorName "AUO"
> ModelName "AUO:dc11"
> # Block type: 2:0 3:f
> # Block type: 2:0 3:fe
> # Block type: 2:0 3:fe
> # DPMS capabilities: Active off:no Suspend:no Standby:no
>
> Mode "1366x768" # vfreq 60.041Hz, hfreq 47.913kHz
> DotClock 76.660000
> HTimings 1366 1404 1426 1600
> VTimings 768 771 777 798
> Flags "-HSync" "-VSync"
> EndMode
> # Block type: 2:0 3:f
> # Block type: 2:0 3:fe
> # Block type: 2:0 3:fe
> EndSection
>
>
> $ sudo i2cdetect 5
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-5.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4f
> 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
>
> $ sudo i2cdump 5 0x4f
> 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-5, address 0x4f, mode byte
> Continue? [Y/n]
> 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
> 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> 90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
No idea what this is, it might as well be the "chip" which caused the
problem, or maybe it is completely unrelated.
> $ sudo i2cdump 5 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-5, address 0x50, mode byte
> Continue? [Y/n]
> 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 06 af dc 11 00 00 00 00 ........????....
> 10: 00 16 01 04 90 16 0d 78 02 bb f5 94 55 54 90 27 .??????x????UT?'
> 20: 23 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 #PT...??????????
> 30: 01 01 01 01 01 01 f2 1d 56 ea 50 00 1e 30 26 16 ????????V?P.?0&?
> 40: 36 00 de 7d 00 00 00 18 00 00 00 0f 00 00 00 00 6.?}...?...?....
> 50: 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41 ......... ...?.A
> 60: 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe UO? ...?
> 70: 00 42 31 30 31 58 54 4e 30 31 2e 31 20 0a 00 dd .B101XTN01.1 ?.?
> 80: ff ff ff ff ff ff ff ff ff ff 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 ................
This is the EEPROM with the EDID monitor information. Should be read
only. If it was somehow corrupted then X should complain repeatedly
about it (it does complain every now and then on many systems due to
occasional I2C bus timeouts, but I would expect it to be much louder if
the EEPROM is corrupted.)
That being said the above dump does NOT look corrupted to me, at least
the checksum is correct and the available data looks good to me -
except for the claim that the display is monochrome and doesn't support
DPMS.
> dmesg currently dumping this during probe of 0x4f:
> [ 783.847244] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.848321] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.849399] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.850497] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.851666] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.852746] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.853827] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.854908] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.855988] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.857065] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.858150] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.859230] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.860306] i2c i2c-6: sendbytes: NAK bailout.
> [ 783.861383] i2c i2c-6: sendbytes: NAK bailout.
This suggests that the chip in question does not like the format of the
messages used by the probe / dump. This explains the XX's but is not
necessarily bad. I've seen a lot of these in the past on various
systems, without any hardware issue resulting from that.
Note that the messages are for i2c bus 6 while your dumps where on i2c
bus 5.
One thing which comes to my mind is DCC/CI: the ability to control the
monitor settings through the OS rather than by pressing physical
buttons on the screen. Your observations could be the result of
(uncontrolled) DCC/CI commands having been sent to the screen as part
of the sensors detection.
Unfortunately I am not aware of any recent Linux tool that can send
DCC/CI commands. The projects I found are old and look abandoned:
http://jaffar.cs.msu.su/oleg/ddcci/
http://ddccontrol.sourceforge.net/
You may still want to give them a try.
AFAIK DCC/CI operates on I2C address 0x37. Can you remember if you did
see anything respond to that address on one of the graphics chip I2C
buses during the initial run of sensors-detect?
http://www.boichat.ch/nicolas/ddcci/specs.html is a good read as well
but unfortunately most commands appear to be vendor specific, plus I
wouldn't even know what setting needs to be tweaked in your case, as we
don't know what the settings were before the problem happened.
But it is also possible that your problem has nothing to do with DCC/CI
and sensors-detect touched a completely different chip which is
controlling some voltages or clock frequencies and what you are seeing
is the result of this now incorrect voltage or frequency.
Good luck,
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [lm-sensors] Trouble with sensors-detect probing ASUS 1015E-DS03 laptop
2013-08-25 0:32 [lm-sensors] Trouble with sensors-detect probing ASUS 1015E-DS03 laptop Larry Lade
2013-08-25 1:51 ` Guenter Roeck
2013-08-29 10:02 ` Jean Delvare
@ 2013-09-05 1:17 ` Larry Lade
2013-09-05 9:20 ` Jean Delvare
3 siblings, 0 replies; 5+ messages in thread
From: Larry Lade @ 2013-09-05 1:17 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1.1: Type: text/plain, Size: 11079 bytes --]
Thank you Jean and Guenter for taking the time to reply.
Since it was still new, I decided to work with the retailer to replace the
device.
I have an suspicion there's a EEPROM in this device that is shipping
without write-protection set, and the sensors-detect probe rakes over it at
random before eventually eventually setting the chip into read-only mode.
If that's the case, then it's probably a lost cause. But EEPROM programming
is all very much over my head! I'm happy to not solve the mystery if I
don't have to.
Perhaps the thing to do is file a bug with Ubuntu to push out a more
up-to-date version of lm-sensors to their long-term support release.
On Thu, Aug 29, 2013 at 5:02 AM, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Larry,
>
> On Sat, 24 Aug 2013 19:32:41 -0500, Larry Lade wrote:
> > I wanted to report an alarming issue running sensors-detect on my new
> > (Ubuntu 12.04 out of the box!) laptop.
> > (...)
> > At some point during one of these scans, there's a flash and SOMETHING
> > happens to the built-in LCD screen. I noticed it's as though the gamma
> > was all out of whack, the colors were washed out, and dithering
> > becomes notable everywhere. (Bad even for an 18-bit LCD.) Display
> > looks fine on an LCD connected by VGA port.
> >
> > This change survived the re-install of the operating system.
> >
> > I was getting desperate, thinking I had just zapped something and
> > voided the hardware, so I ran sensors-detect again. Probing either of
> > the two above adapters (they both seem to reference the same bit of
> > hardware) seemed to toggle something, restoring or corrupting the
> > screen quality.
> >
> > Or at least it did. It seems to have it stuck in "ugly" mode again,
> > and nothing on the display toggles any more when I run sensors-detect
> > any more. Is anyone able to help?
>
> I'm very sorry about this. As Guenter said, we have changed the code
> meanwhile to skip graphics adapters by default, and I can only urge
> Linux distributions to include that change.
>
> You may try to ask the hardware vendor for help. After all they did
> ship the software which broke the laptop, right? Even though they did
> not write it. I am willing to help but the problem is that it will be
> very difficult, if not impossible, to do so without intimate knowledge
> of the hardware, which only the vendor can provide. I would be very
> happy to cooperate with Asus on that matter if they want to. Only Asus
> knows exactly which I2C chips are connected to the graphics chip, at
> what address, and if any of them could be responsible for what you
> observe.
>
> Meanwhile, the first thing to try here is:
> * Shut down the machine.
> * Remove the battery.
> * Unplug the AC adapter.
> * Let the laptop rest that way for a moment, at least 10 minutes.
> * Plug everything back and start the machine.
>
> This has restored systems for me and others in the past, I can only
> hope it helps for you as well.
>
> If it does not, then if the laptop is new, I think I would just play
> the support/warranty card.
>
> You can also try changing the gamma setting with xrandr.
>
> > The LCD seems to be an AUO B101XTN01 (as reported by the EDID)
> > http://www.panelook.com/B101XTN01.0_AUO_10.1_LCM_parameter_19387.html
> >
> > lm-sensors 1:3.3.1-2ubuntu1
> >
> > linux 3.2.0-52-generic #78-Ubuntu SMP x86_64
> >
> >
> > $ sudo get-edid | parse-edid:
> >
> > # EDID version 1 revision 4
> > Section "Monitor"
> > # Block type: 2:0 3:f
> > # Block type: 2:0 3:fe
> > # Block type: 2:0 3:fe
> > Identifier "AUO:dc11"
> > VendorName "AUO"
> > ModelName "AUO:dc11"
> > # Block type: 2:0 3:f
> > # Block type: 2:0 3:fe
> > # Block type: 2:0 3:fe
> > # DPMS capabilities: Active off:no Suspend:no Standby:no
> >
> > Mode "1366x768" # vfreq 60.041Hz, hfreq 47.913kHz
> > DotClock 76.660000
> > HTimings 1366 1404 1426 1600
> > VTimings 768 771 777 798
> > Flags "-HSync" "-VSync"
> > EndMode
> > # Block type: 2:0 3:f
> > # Block type: 2:0 3:fe
> > # Block type: 2:0 3:fe
> > EndSection
> >
> >
> > $ sudo i2cdetect 5
> > WARNING! This program can confuse your I2C bus, cause data loss and
> worse!
> > I will probe file /dev/i2c-5.
> > I will probe address range 0x03-0x77.
> > Continue? [Y/n]
> > 0 1 2 3 4 5 6 7 8 9 a b c d e f
> > 00: -- -- -- -- -- -- -- -- -- -- -- -- --
> > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4f
> > 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 70: -- -- -- -- -- -- -- --
> >
> >
> > $ sudo i2cdump 5 0x4f
> > 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-5, address 0x4f, mode byte
> > Continue? [Y/n]
> > 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
> > 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > 70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > 80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > 90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
> > f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
>
> No idea what this is, it might as well be the "chip" which caused the
> problem, or maybe it is completely unrelated.
>
> > $ sudo i2cdump 5 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-5, address 0x50, mode byte
> > Continue? [Y/n]
> > 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 06 af dc 11 00 00 00 00 ........????....
> > 10: 00 16 01 04 90 16 0d 78 02 bb f5 94 55 54 90 27 .??????x????UT?'
> > 20: 23 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 #PT...??????????
> > 30: 01 01 01 01 01 01 f2 1d 56 ea 50 00 1e 30 26 16 ????????V?P.?0&?
> > 40: 36 00 de 7d 00 00 00 18 00 00 00 0f 00 00 00 00 6.?}...?...?....
> > 50: 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41 ......... ...?.A
> > 60: 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe UO? ...?
> > 70: 00 42 31 30 31 58 54 4e 30 31 2e 31 20 0a 00 dd .B101XTN01.1 ?.?
> > 80: ff ff ff ff ff ff ff ff ff ff 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 ................
>
> This is the EEPROM with the EDID monitor information. Should be read
> only. If it was somehow corrupted then X should complain repeatedly
> about it (it does complain every now and then on many systems due to
> occasional I2C bus timeouts, but I would expect it to be much louder if
> the EEPROM is corrupted.)
>
> That being said the above dump does NOT look corrupted to me, at least
> the checksum is correct and the available data looks good to me -
> except for the claim that the display is monochrome and doesn't support
> DPMS.
>
> > dmesg currently dumping this during probe of 0x4f:
> > [ 783.847244] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.848321] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.849399] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.850497] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.851666] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.852746] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.853827] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.854908] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.855988] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.857065] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.858150] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.859230] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.860306] i2c i2c-6: sendbytes: NAK bailout.
> > [ 783.861383] i2c i2c-6: sendbytes: NAK bailout.
>
> This suggests that the chip in question does not like the format of the
> messages used by the probe / dump. This explains the XX's but is not
> necessarily bad. I've seen a lot of these in the past on various
> systems, without any hardware issue resulting from that.
>
> Note that the messages are for i2c bus 6 while your dumps where on i2c
> bus 5.
>
> One thing which comes to my mind is DCC/CI: the ability to control the
> monitor settings through the OS rather than by pressing physical
> buttons on the screen. Your observations could be the result of
> (uncontrolled) DCC/CI commands having been sent to the screen as part
> of the sensors detection.
>
> Unfortunately I am not aware of any recent Linux tool that can send
> DCC/CI commands. The projects I found are old and look abandoned:
> http://jaffar.cs.msu.su/oleg/ddcci/
> http://ddccontrol.sourceforge.net/
> You may still want to give them a try.
>
> AFAIK DCC/CI operates on I2C address 0x37. Can you remember if you did
> see anything respond to that address on one of the graphics chip I2C
> buses during the initial run of sensors-detect?
>
> http://www.boichat.ch/nicolas/ddcci/specs.html is a good read as well
> but unfortunately most commands appear to be vendor specific, plus I
> wouldn't even know what setting needs to be tweaked in your case, as we
> don't know what the settings were before the problem happened.
>
> But it is also possible that your problem has nothing to do with DCC/CI
> and sensors-detect touched a completely different chip which is
> controlling some voltages or clock frequencies and what you are seeing
> is the result of this now incorrect voltage or frequency.
>
> Good luck,
> --
> Jean Delvare
>
[-- Attachment #1.2: Type: text/html, Size: 13337 bytes --]
[-- Attachment #2: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [lm-sensors] Trouble with sensors-detect probing ASUS 1015E-DS03 laptop
2013-08-25 0:32 [lm-sensors] Trouble with sensors-detect probing ASUS 1015E-DS03 laptop Larry Lade
` (2 preceding siblings ...)
2013-09-05 1:17 ` Larry Lade
@ 2013-09-05 9:20 ` Jean Delvare
3 siblings, 0 replies; 5+ messages in thread
From: Jean Delvare @ 2013-09-05 9:20 UTC (permalink / raw)
To: lm-sensors
Hi Larry,
On Wed, 4 Sep 2013 20:17:41 -0500, Larry Lade wrote:
> Thank you Jean and Guenter for taking the time to reply.
>
> Since it was still new, I decided to work with the retailer to replace the
> device.
I think it was the best move, indeed. Not only for you, but it will
also show the hardware vendor that they probably should go for a more
robust design.
> I have an suspicion there's a EEPROM in this device that is shipping
> without write-protection set, and the sensors-detect probe rakes over it at
> random before eventually eventually setting the chip into read-only mode.
This is a possibility, yes. But there are many other possibilities and
we are pretty clueless at the moment :(
> If that's the case, then it's probably a lost cause. But EEPROM programming
> is all very much over my head! I'm happy to not solve the mystery if I
> don't have to.
I understand.
> Perhaps the thing to do is file a bug with Ubuntu to push out a more
> up-to-date version of lm-sensors to their long-term support release.
Yes, this should be fixed by distributions. I have added a note about
that on the main page of lm-sensors.org:
http://www.lm-sensors.org/wiki
Distributions don't have to upgrade to lm-sensors 3.3.3+, but they
should at least backport the two critical fixes that were added to
3.3.3 to avoid further hardware breakage:
http://www.lm-sensors.org/changeset/6040
http://www.lm-sensors.org/changeset/6084
So if you can get Ubuntu to backport these to affected products still
under maintenance, that would be great. I'll do the same for openSUSE.
I also have plans to make sensors-detect even safer by default, I'll
discuss these on this list in a separate thread.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-09-05 9:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-25 0:32 [lm-sensors] Trouble with sensors-detect probing ASUS 1015E-DS03 laptop Larry Lade
2013-08-25 1:51 ` Guenter Roeck
2013-08-29 10:02 ` Jean Delvare
2013-09-05 1:17 ` Larry Lade
2013-09-05 9:20 ` Jean Delvare
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.