Bug 64371

Summary: [snb] ddccontrol doesn't work on kernels >= 3.10.5
Product: Drivers Reporter: dbzix (dbz.gml)
Component: Video(DRI - Intel)Assignee: Ben Widawsky (ben)
Status: RESOLVED INSUFFICIENT_DATA    
Severity: normal CC: daniel, intel-gfx-bugs, jdelvare
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 3.10.5 Subsystem:
Regression: Yes Bisected commit-id:

Description dbzix 2013-11-04 15:49:56 UTC
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
Comment 1 dbzix 2013-11-09 22:17:16 UTC
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
Comment 2 Jean Delvare 2013-11-10 09:37:35 UTC
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.
Comment 3 dbzix 2013-11-10 20:22:19 UTC
Hello, Jean

3.2.32 (working): http://pastebin.com/YJfTPQEV
3.10.5 (broken):  http://pastebin.com/bDYemf0N
Comment 4 dbzix 2013-11-10 20:29:22 UTC
And the same from root:

3.2.32 (working): http://pastebin.com/S8DiQQrK
3.10.5 (broken):  http://pastebin.com/4bg61JjD
Comment 5 Jani Nikula 2013-11-11 13:18:35 UTC
(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.
Comment 6 Jean Delvare 2013-11-11 14:17:30 UTC
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.
Comment 7 dbzix 2013-11-11 14:50:22 UTC
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?
Comment 8 dbzix 2013-11-11 14:52:22 UTC
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 ~ $
Comment 9 dbzix 2013-11-11 15:15:38 UTC
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 ~ $
Comment 10 dbzix 2013-11-11 15:24:38 UTC
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.
Comment 11 dbzix 2013-11-11 15:30:59 UTC
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.
Comment 12 Jean Delvare 2013-11-11 17:52:44 UTC
ddccontrol works for me on my Intel laptop with kernel 3.7.10, so the bug must be hardware-specific.
Comment 13 dbzix 2013-11-11 20:17:35 UTC
Jean,

Can we somehow identify the roots of this problem?

"Works for me" isn't good cause for closing a bug :)
Comment 14 Jean Delvare 2013-11-11 20:52:37 UTC
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.
Comment 15 dbzix 2013-11-11 22:04:32 UTC
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?
Comment 16 Jani Nikula 2013-11-12 09:29:39 UTC
(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.
Comment 17 Jani Nikula 2013-11-12 12:29:41 UTC
Works for me too, kernel v3.12 and DP.
Comment 18 Jean Delvare 2013-11-12 12:55:15 UTC
Jani: on Sandy Bridge? Mine is Ivy Bridge.
Comment 19 Jean Delvare 2013-11-12 12:59:21 UTC
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.
Comment 20 dbzix 2013-11-12 13:07:09 UTC
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.
Comment 21 Jean Delvare 2013-11-12 13:35:21 UTC
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.
Comment 22 Jani Nikula 2013-11-12 13:56:55 UTC
(In reply to Jean Delvare from comment #18)
> Jani: on Sandy Bridge? Mine is Ivy Bridge.

Coincidentally yes, but should not make a difference.
Comment 23 dbzix 2013-11-20 18:30:14 UTC
Guys, can we do something else to identify my problem?
Comment 24 Jean Delvare 2013-11-20 21:01:43 UTC
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.
Comment 25 Jani Nikula 2014-02-07 08:21:00 UTC
(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'.
Comment 26 dbzix 2014-02-07 08:56:31 UTC
Hello, Jani.

Why 3.13? Does it fix any DDC-related bugs?
Comment 27 Jani Nikula 2014-08-14 08:24:33 UTC
Timeout. Please reopen if the problem persists with recent kernels.