Created attachment 93990 [details] kernel output Sometimes (I failed to find any specific triggers) after my DP monitor has been in standby for a couple hours, the system will fail to wake it up. The kernel output with drm debug on is attached. My hardware is a SNB i7 2600K, lspci says 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) I've been occasionally seeing this problem for some time now, with several different kernels. Right now I'm on 3.13.0, libdrm 2.4.52-1 (debian testing), mesa 10.0.2-1 (debian experimental), xf86-video-intel 2.21.15 (debian testing). I'm leaving the machine in this stuck state (using the second GPU), so I should be able to get any other information that might be needed.
Unfortunately the interesting bits before the error are missing.
You can try to increase the dmesg buffer with log_buf_len or grab all kernel log output since boot-up with something like journalctl -b. In any case we need the stuff before the avalanche of link training errors happens.
Well it usually takes weeks for this bug to trigger, and I'm not sure my drives could hold all the debug output. Is there perhaps some simple way to send the drm debug logs to a different channel than the rest, so i can store e.g. the last day or so?
(In reply to comment #3) > Well it usually takes weeks for this bug to trigger, and I'm not sure my > drives could hold all the debug output. > > Is there perhaps some simple way to send the drm debug logs to a different > channel than the rest, so i can store e.g. the last day or so? Okay, please attach the dmesg from early boot, even though it doesn't contain the error. It contains interesting stuff about the driver initializatione etc. The log buffer will wrap. If you have log buffer size increased, just attach the dmesg you have at the point of error when it happens.
Created attachment 96629 [details] early boot log
Please provide the log with drm.debug=0xe module param, not just drm.debug=1. Sorry for not being specific about it before.
Created attachment 96648 [details] early boot log
Created attachment 97463 [details] kernel debug output Finally managed to trigger the bug with drm debugging on. As seen in the log, I turned the monitor off around 10:00, then when I returned around 11:00 the driver started spamming those failures and the monitor stayed off.
(In reply to comment #8) > Created attachment 97463 [details] > kernel debug output > > Finally managed to trigger the bug with drm debugging on. As seen in the > log, I turned the monitor off around 10:00, then when I returned around > 11:00 the driver started spamming those failures and the monitor stayed off. Did it not work even for a few moments between 10:52 and 11:00? There are successful link trainings in between there (but then also failed ones). What type of monitors do you have (DP/HDMI) and do you use some adapters?
Anton, please provide the information requested in comment #9.
Bug reporter seems to have unfortunately disappeared, so closing. If this is still an issue please reopen after having retest on latest kernels, thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.