Created attachment 117306 [details] dmesg, booting undocked on bat, PSR=1, FBC=0 Enabling PSR -> screen freezes at boot a bit after modesetting, but not exactly at modesetting since the resolution is changed to a high one and I can see graphics. Hardware: lenovo T450s, model 20BX000TBM (see attached dmidecode and lspci_vv). OS: Fedora 22, fully updated (as of 2015-07-23) Kernel: git drm-intel-nightly (as of 2015-07-22 evening). .config attached (config.drm-intel). Tests (attached dmesg -c > ...): dmesg-boot_undocked_psr0_fbc1: - boot with laptop undocked (but on AC), enable_psr=0, enable_psr=1 - laptop seems to work fine dmesg-boot_undocked_psr1_fbc0: - boot with laptop undocked (but on AC), enable_psr=1, enable_psr=0 - screen freezes at encrypted luks password (fedora's lock image shows up, with the password field, but there's no screen feedback to keyboard events). - laptop is responsive though, so I can blindly switch to a vt, log as root, and dump dmesg to a file. dmesg-0-boot_undocked_bat_psr1_fbc0: - boot with laptop undocked (on battery), enable_psr=1, enable_psr=0 - same behavior as on AC (boot_undocked_psr1_fbc0). dmesg-0-boot_undocked_bat_psr1_fbc0-after-suspend: I thought of another test: blindly suspended laptop, resumed, and laptop's panel is now OK and laptop is usable
Created attachment 117307 [details] dmesg, booting undocked on bat, PSR=1, FBC=0, after suspend/resume cycle
Created attachment 117308 [details] dmesg, booting undocked, PSR=0, FBC=1
Created attachment 117309 [details] dmesg, booting undocked, PSR=1, FBC=0
Created attachment 117310 [details] dmidecode
Created attachment 117311 [details] lspci -vv
Created attachment 117312 [details] kernel .config used when compiling drm-intel-nightly
note: there's a chance that this bug is related to two other bugs (bug 91437 and bug 91438) that I found when trying to debug flickering with Rodrigo Vivi when PSR was enabled.
Created attachment 117819 [details] [review] patch Hi Ivan, This issue is probably the same as 91437... or actually that one makes this one un-recoverable. Could you please test this patch by itself fix this issue here? Thanks, Rodrigo
Created attachment 117959 [details] dmesg with debug patch [note: comment redacted from bug 91438] I compiled/tested a kernel from the psr-delayed-enable branch (2015-08-21) Laptop on AC, undocked, psr=1, fbc=0 - at boot after modeset, screen freezes as before - a suspend/resume cycle doesn't help with "unfreezing" the display. At resume the display will show the current laptop state (eg. if I suspend the laptop when the screen is frozen at the luks password prompt, at resume I'll see X's login screen), but the screen will freeze instantly again (can't see the mouse pointer moving). - laptop is responsive though, ssh'ed into it; see attached dmesg with debug output - dmesg -c > boot.dmesg.2; the screen freezes between 5 and 6 seconds after boot - dmesg > boot.dmesg.2.after_resume: dmesg after a suspend/resume cycle
Created attachment 117960 [details] dmesg with debug patch after a suspend/resume cycle
Created attachment 117978 [details] dmesg with psr=0 (OK) just wanted to be sure that the culprit was PSR since I'm a little bit loosing track of all the previous tests I've done for this bug and the other ones. kernel compiled from the psr-delayed-enable branch as above, booting with enable_psr=0: no screen freeze, dmesg attached for comparison. kind regards ivan
Hi Ivan, could you please test 2 different branches on your machine: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=psr-ivan-v5 and http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=psr-ivan-v6 Please let me know if one of them helps all bugs you reported but also please collect dmesg with both of them please. Thanks in advance, Rodrigo.
Created attachment 118222 [details] dmesg - test with psr-v5 and psr-v6 branches Hi Rodrigo, - psr v5: same problem - psr v6: marginally better, in that I could see 4 dots corresponding to the 1st 4 letters when typing my luks password and then it froze as before. Kind regards, Ivan
Hi Ivan, I found your issue. The patch that fixes is: http://cgit.freedesktop.org/~vivijim/drm-intel/commit/?h=display-pm-rework&id=7b5e5f02e32ccc514ecfb3a3237dbd66a844f988 However there are more rework needed on recent kernels with fastboot enabled by default... So if possible I'd like you to give a try at display-pm-rework branch: http://cgit.freedesktop.org/~vivijim/drm-intel/commit/?h=display-pm-rework Thanks, Rodrigo.
Created attachment 119168 [details] dmesg - display-pm-rework branch Hi Rodrigo, No luck with the new branch: I can only type a few letters at the luks prompt and then the screen freezes (same problem as before with the psrv6 branch). The laptop is responsive though, I blindly logged in a VT to save dmesg's output. Thanks, Ivan
Hi Ivan, I noticed you have applied my patches in your 4.2.0-rc8ivan+ tree. I'm afraid this 4.2 doesn't have all psr and atomic modeset changes needed, etc... Anyway, could you please share your tree with me so I can take a look here what is happening? Thanks, Rodrigo.
Created attachment 119204 [details] dmesg - display-pm-rework branch - proper I'm sorry, after reading your comment I found out I hadn't properly updated the git branch, it was still synced to psr-v6. I fixed that and compiled/tested with the new branch, see dmesg attached. The result is marginaly better: the screen freezes for a few seconds, then updates to the current content, then freezes again for a few seconds, and so on. Thanks, Ivan
Hi Ivan, thanks for checking. So, please help me to understand this freeze more... When are you seeing this? at luksopen passphrase, on fedora splash, on console or on openbox? If it is openbox, could you please let me know your custom openbox stuff? Are you running that power/acpi tool? I have a fedora running on a same machine here with same display time and everything works well on my end... Please help me to figure out the differences so we can find out what is the new issue... Thansk, Rodrigo.
Created attachment 119205 [details] kernel .config / display-pm-rework branch It happens as soon as the luks passphrase prompt, so it should exclude any problem related to acpi/power tools, WM/openbox, ... I only tried once - I typed the luks passphrase, saw a few dots on the prompt, then the screen froze (ie. no more dots showing keypresses), then the screen "resumed", I could see a few other dots, then another freeze during which I usually see a fedora splash animation, and then the display showed the X login manager. That behavior was the same after I logged in: I opened a terminal, typed a few things, and would only get intermittent screen feedback. The laptop was on AC. If you have the same laptop as mine and don't have those problems, it could be something with 1- the bios settings 2- my kernel .config 3- my initrd I guess it's probably 2- : maybe some features I've enabled don't play nice with PSR. I'm attaching the .config, I can also send you my kernel build if you'd like to test if you get the same problem. Thanks for your time trying to pinpoint the problem ! Ivan
I had to add EFI support to your config, but after that I was able to boot and everything after that looks good for me... including the luks passprase and splash screen... I don't believe EFI, BIOS or any initrd would affect that much at this point... Will add some debugs and change some value at the branch to see if we can identify what is going on...
Hi Ivan, could you please grab the log of psr-ivan-v7 branch?
Hi Rodrigo, I've tested the psr-ivan-v7 branch, it works well (even with enable_fbc=1) ! I wanted to work a little bit with that kernel to see how power consumption would improve so I compiled the same kernel but with the debug patch reverted (commit cf6e97774936be7e47eb2c0805b14db6412c14ae) But then, with this kernel: - with enable_psr=0 at boot : OK - with enable_psr=1 at boot: intermittent freezes like described before. The problem doesn't go away when I later set enable_psr to 0 (/sys/module/i915/parameters/enable_psr). I could consistently reproduce the problem. I see the debug patch also commented something related to timing. I'll try to keep only those comments and remove the verbose stuff and see if the problems goes away.
So - I tried a kernel with the debug patch reverted but kept the part below, and there's indeed no intermittent freeze. Hope this helps... diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 8d744c3..9ccf988 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -258,8 +258,8 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp) if (intel_dp->psr_dpcd[1] & DP_PSR_NO_TRAIN_ON_EXIT) { /* It doesn't mean we shouldn't send TPS patters, so let's send the minimal TP1 possible and skip TP2. */ - val |= EDP_PSR_TP1_TIME_100us; - val |= EDP_PSR_TP2_TP3_TIME_0us; + // val |= EDP_PSR_TP1_TIME_100us; + //val |= EDP_PSR_TP2_TP3_TIME_0us; /* Sink should be able to train with the 5 or 6 idle patterns */ idle_frames += 4; }
Hi Ivan, All fixes landed on dev branch. Could you please verify you can use i915.enable_psr=1 with drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel ? Thank you very much for the report and all patience.
*** Bug 91437 has been marked as a duplicate of this bug. ***
Hi Ivan, could you please verify PSR is fixed for you on our drm-intel-nightly branch? Thanks in advance, Rodrigo.
Hi Rodrigo, Sorry for taking so much time to test - I wiped out my fedora installation some time ago (moved to Qubes OS) and had to re-install a similar test environment. It looks like the problem is indeed fixed. - installed f23 from scratch (the only difference with the former installation is that there's no encrypted root). - compiled drm-intel-nightly with the same .config as before. I didn't notice a change in power consumption when running on battery though (that said, the power stats in those newer thinkpads take *minutes* to stabilize so maybe I didn't wait enough to see a change). Marking as RESOLVED :) Kind regards, ivan
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.