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
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. |