I'm using LMDE system (http://linuxmint.com/start/debian/). Initially the kernel was 3.2.32, and ddccontrol worked perfectly with my Philips 232E2SB. I was able to change monitor brightness through ddccontrol commands. Then I upgraded my system to Update Pack 7, and the new kernel became of version 3.10.5. On new kernel ddccontrol doesn't work anymore, but it still works on the old one (so this isn't software issue). I have checked kernel configs - for the old kernel and for the new one. Both configs are identical at i2c sections. I've tried to use old (3.2.32's one) config with the new kernel, but there was no success. To be absolutely sure that the problem isn't in the this specific kernel version (3.10.5), I've downloaded the latest one (3.11.3) from kernel.org and tried to use old config on this new kernel, but the issue is still reproducing... Additional info: ---------------------------- The output of 'i2cdetect -l' on the old kernel (3.2.32): http://pastebin.com/SqDPcwS9 The same on the new one (3.10.5): http://pastebin.com/YCTmX90m The output of 'ddccontrol -p' on the old kernel (3.2.32): http://pastebin.com/QL0fAZVC The same on the new one (3.10.5): http://pastebin.com/vZ4bALmt And dmesg outputs for both 3.2.32 and 3.10.5 kernels: - 3.2.32: http://pastebin.com/7ijujvkA - 3.10.5: http://pastebin.com/t1wdKrAd Also very often ddccontrol says that there is some error with ioctl(): I'm using LMDE system (http://linuxmint.com/start/debian/). Initially the kernel was 3.2.32, and ddccontrol worked perfectly with my Philips 232E2SB. I was able to change monitor brightness through ddccontrol commands. Then I upgraded my system to Update Pack 7, and the new kernel became of version 3.10.5. On new kernel ddccontrol doesn't work anymore, but it still works on the old one (so this isn't software issue). I have checked kernel configs - for the old kernel and for the new one. Both configs are identical at i2c sections. I've tried to use old (3.2.32's one) config with the new kernel, but there was no success. To be absolutely sure that the problem isn't in the this specific kernel version (3.10.5), I've downloaded the latest one (3.11.3) from kernel.org and tried to use old config on this new kernel, but the issue is still reproducing... Additional info: ---------------------------- The output of 'i2cdetect -l' on the old kernel (3.2.32): http://pastebin.com/SqDPcwS9 The same on the new one (3.10.5): http://pastebin.com/YCTmX90m The output of 'ddccontrol -p' on the old kernel (3.2.32): http://pastebin.com/QL0fAZVC The same on the new one (3.10.5): http://pastebin.com/vZ4bALmt And dmesg outputs for both 3.2.32 and 3.10.5 kernels: - 3.2.32: http://pastebin.com/7ijujvkA - 3.10.5: http://pastebin.com/t1wdKrAd Also very often ddccontrol says that there is some error with ioctl(): I'm using LMDE system (http://linuxmint.com/start/debian/). Initially the kernel was 3.2.32, and ddccontrol worked perfectly with my Philips 232E2SB. I was able to change monitor brightness through ddccontrol commands. Then I upgraded my system to Update Pack 7, and the new kernel became of version 3.10.5. On new kernel ddccontrol doesn't work anymore, but it still works on the old one (so this isn't software issue). I have checked kernel configs - for the old kernel and for the new one. Both configs are identical at i2c sections. I've tried to use old (3.2.32's one) config with the new kernel, but there was no success. To be absolutely sure that the problem isn't in the this specific kernel version (3.10.5), I've downloaded the latest one (3.11.3) from kernel.org and tried to use old config on this new kernel, but the issue is still reproducing... Additional info: ---------------------------- The output of 'i2cdetect -l' on the old kernel (3.2.32): http://pastebin.com/SqDPcwS9 The same on the new one (3.10.5): http://pastebin.com/YCTmX90m The output of 'ddccontrol -p' on the old kernel (3.2.32): http://pastebin.com/QL0fAZVC The same on the new one (3.10.5): http://pastebin.com/vZ4bALmt And dmesg outputs for both 3.2.32 and 3.10.5 kernels: - 3.2.32: http://pastebin.com/7ijujvkA - 3.10.5: http://pastebin.com/t1wdKrAd Also very often ddccontrol says that there is some error with ioctl(): http://pastebin.com/LzPjuLM8
UPD: on kernel 3.7 I've watched the same behavior as on 3.10, so, the breakage isn't at 3.10 but a bit earlier
Looks like an issue with the i915 graphics driver. I have no reason to believe the i2c core has anything to do with it at this time. Please attach the output of "ddccontrol -pv" and "strace ddccontrol -p" in both the working case and the non-working case.
Hello, Jean 3.2.32 (working): http://pastebin.com/YJfTPQEV 3.10.5 (broken): http://pastebin.com/bDYemf0N
And the same from root: 3.2.32 (working): http://pastebin.com/S8DiQQrK 3.10.5 (broken): http://pastebin.com/4bg61JjD
(In reply to Jean Delvare from comment #2) > Looks like an issue with the i915 graphics driver. I have no reason to > believe the i2c core has anything to do with it at this time. Jean, based on what? (I'm not saying it *isn't* an i915 problem, I just couldn't find anything in the logs to that effect!) dbzix, please always prefer attaching logs as text/plain in the bug. The pastebins vanish over time. dbzix, please attach dmesg running a recent kernel, such as v3.12, with drm.debug=0xe module parameter, and reproduce the issue.
Jani, the i915 driver exposes different I2C adapters in 3.10+ than it did in 3.2. This is the interface used by ddccontrol, so it seems reasonable to assume that the regression reported here is related to that change. Also, ddccontrol works for me with a recent kernel and a Radeon graphics card. This hints at the problem coming from a change in the i915 driver. dbzix, please provide the output of "i2cdetect 3" and "i2cdetect 4" for the working kernel, and the output of "i2cdetect 1" for the non-working kernel.
Hello, Jani Please, give me a tip how will I do that: "dbzix, please attach dmesg running a recent kernel, such as v3.12, with drm.debug=0xe module parameter, and reproduce the issue." Do I need to run kernel passing it 'drm.debug=0xe' as kernel param?
Hello, Jean Kernel 3.2.32 (working): ------------------------ 17:50:51 dbz@dbzix ~ $ sudo i2cdetect 3 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-3. 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: -- -- -- -- -- -- -- 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- 49 -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- 59 -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- 17:51:14 dbz@dbzix ~ $ sudo i2cdetect 4 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-4. 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: -- -- -- -- -- -- -- 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- 49 -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- 59 -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- 17:51:18 dbz@dbzix ~ $ uname -a Linux dbzix 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux 17:51:23 dbz@dbzix ~ $
Kernel 3.10.5 (broken): ----------------------- 18:14:30 dbz@dbzix ~ $ sudo i2cdetect 1 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-1. 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: -- -- -- -- -- -- -- 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- 49 -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- 59 -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- 18:15:22 dbz@dbzix ~ $ uname -a Linux dbzix 3.10-2-amd64 #1 SMP Debian 3.10.5-1 (2013-08-07) x86_64 GNU/Linux 18:15:24 dbz@dbzix ~ $
Jani, This is a dmesg output for current distro NON-WORKING kernel (3.10.5) with kernel boot param 'drm.debug=0xe' (pastebin because of comment size restriction): http://pastebin.com/CuaSqGft. If it's needed then I can build the latest kernel from kernel.org and do the same for it.
Jani, After running 'ddccontrol -p' on this kernel, above dmesg output appended with: [ 599.453745] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x7143003f [ 599.453749] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 599.456156] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x7143003f [ 599.456159] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 599.456160] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return -110 [ 599.458580] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x7143003f [ 599.458583] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 599.460988] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x7143003f [ 599.460991] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 599.460992] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return -110 [ 599.463406] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x7143003f [ 599.463409] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 599.465987] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x7143003f [ 599.466156] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 599.466159] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return -110 [ 599.466607] [drm:gmbus_xfer], GMBUS [i915 gmbus dpd] NAK for addr: 0050 w(1) [ 599.470596] [drm:gmbus_xfer], GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1) [ 599.542499] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 [ 599.571185] [drm:gmbus_xfer], GMBUS [i915 gmbus vga] NAK for addr: 0037 w(6) [ 599.616207] [drm:gmbus_xfer], GMBUS [i915 gmbus vga] NAK for addr: 0037 w(6) [ 599.661346] [drm:gmbus_xfer], GMBUS [i915 gmbus vga] NAK for addr: 0037 w(6) [ 599.706341] [drm:gmbus_xfer], GMBUS [i915 gmbus vga] NAK for addr: 0037 w(4) [ 599.762281] [drm] GMBUS [i915 gmbus ssc] timed out, falling back to bit banging on pin 1 Hope it helps.
ddccontrol works for me on my Intel laptop with kernel 3.7.10, so the bug must be hardware-specific.
Jean, Can we somehow identify the roots of this problem? "Works for me" isn't good cause for closing a bug :)
dbzix, the log in comment #11 pretty much says it I think, you get I2C nacks on address 0x37 on the VGA DDC channel. By "it works for me" I never wanted to suggest that we close the bug. I tried to reproduce the bug to help with debugging, but I couldn't reproduce it, so I'll let Jani drive from here.
Hello, Jean 'By "it works for me" I never wanted to suggest that we close the bug.' - sorry about that :) 'you get I2C nacks on address 0x37 on the VGA DDC channel' - what does it mean for me in common words? Is it somehow related to VGA-cable connection?
(In reply to dbzix from comment #10) > This is a dmesg output for current distro NON-WORKING kernel (3.10.5) with > kernel boot param 'drm.debug=0xe' (pastebin because of comment size > restriction): http://pastebin.com/CuaSqGft. Don't try add dmesgs as comments, please add them as attachments.
Works for me too, kernel v3.12 and DP.
Jani: on Sandy Bridge? Mine is Ivy Bridge.
dbzix: Address 0x37 is where the DCC/CI interface is implemented, so this is the address ddccontrol attempts to talk to. It should get an ack for every message there, and it does for you with kernel 3.2 but no longer for kernel 3.10. Oddly enough the i2cdetct output shows address 0x37 as responsive, so most likely it's not completely dead but message transmission between the master (the Intel chip) and the slave (the display) fails to complete. I have no idea why, sorry.
Hello, Jean Thank you for the response. Looks like I really have some HW problem, maybe it's somehow related to my monitor... This is very sad that we can't find a root of this problem. There are a lot of similar questions over the web, some of them are very old, and all of them still without an answer. It would be great if we can resolve this old and (maybe) common bug. Thank you anyway. If we can do something more to investigate - just tell me. If not then I'll try other methods to control my monitor.
Well, if it works with one kernel and fails with another, it can't be a problem with your monitor, it has to be a kernel driver regression. Most likely it is unrelated to the other issues you may have found on the web - every bug is different.
(In reply to Jean Delvare from comment #18) > Jani: on Sandy Bridge? Mine is Ivy Bridge. Coincidentally yes, but should not make a difference.
Guys, can we do something else to identify my problem?
I don't. If nobody else does, I'm afraid your only chance is to bisect the git kernel tree to find out the commit which broke it.
(In reply to dbzix from comment #23) > Guys, can we do something else to identify my problem? Please try kernel v3.13 and attach the output of 'ddccontrol -p -v'.
Hello, Jani. Why 3.13? Does it fix any DDC-related bugs?
Timeout. Please reopen if the problem persists with recent kernels.