Booting the latest 4.15-rc8-next kernel with i915.fastboot=1 causing the screen to turn off completely and the kernel to lockup. Booting with fastboot off works fine, albeit with a couple of extra flickers (which is usual). Since the kernel locks up, and my machine has no pstore support, I sadly have no way of getting any logs :( Last tested version that I believe worked was somewhere around 4.14-next-20171124. I might bisect if I find some free time and try to get the exact commit. Sysinfo: - Gentoo x86_64 - Intel HD 4400 Gen7.5 Haswell - Laptop screen connected over eDP
(In reply to Rafael Ristovski from comment #0) > Since the kernel locks up, and my machine has no pstore support, I sadly > have no way of getting any logs :( Netconsole? > I might bisect if I find some free time and try to get the exact commit. Bisect would indeed be useful.
This could be related to bug 103781.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Closing, please re-open is issue still exists. See also https://bugs.freedesktop.org/show_bug.cgi?id=103781 if related.
Greetings, I apologize for the inactivity, I have been quite busy and thus have not used any of the new -next versions. I can confirm the issue is *still* present as of 4.17.0-rc2-next-20180424. I might do some debugging/bisecting this weekend, will update with any progress.
Ok, thanks for the feedback, all help appreciated.
Rafael, any updates on this issue? Do you still have the issue with latest drm-tip?
(In reply to Lakshmi from comment #7) > Rafael, any updates on this issue? Do you still have the issue with latest > drm-tip? Hello, sorry for not debugging this as I've been on vacation and quite busy. I can confirm the issue still persists with 4.18.0-next-20180823 (just tested). I might try latest master and drm-tip tomorrow or the day after that.
> > I might try latest master and drm-tip tomorrow or the day after that. Thanks for the quick response, if problem persists with latest drm-tip (https://cgit.freedesktop.org/drm-tip) attach the full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
(In reply to Lakshmi from comment #9) > > > > I might try latest master and drm-tip tomorrow or the day after that. > > Thanks for the quick response, if problem persists with latest drm-tip > (https://cgit.freedesktop.org/drm-tip) > attach the full dmesg from boot with kernel parameters drm.debug=0x1e > log_buf_len=4M. As I stated in the issue, getting the logs would be an issue as the kernel locks up. My machine has no pstore and the only alternative would be a netconsole (as suggested by Jani) which *MIGHT* work. I will see if I can set netconsole up, depending on if I find the time. If not, expect me to issue the logs on the weekend.
Can confirm still happens with latest -next (next-20180912) and drm-tip. Will try ssh/netconsole later today most likely.
CAn you attach the full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
Just as I thought - no luck, even with netconsole. If I leave i915 compiled in, it hangs the kernel but that's before the network initializes (yes, I have the network driver built-in), so netconsole won't even start. If I load i915 afterwards, it works normally, both with fastboot enabled and disabled, with no errors in dmesg. If anyone has any ideas, please tell.
Seems like the kernel does resume booting after some time, log here: [ 11.593506] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:39:pipe A] flip_done timed out [ 11.595804] Console: switching to colour frame buffer device 170x48 [ 21.833519] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:39:pipe A] flip_done timed out [ 32.073510] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:65:eDP-1] flip_done timed out [ 42.313515] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:28:primary A] flip_done timed out [ 52.553510] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:39:pipe A] flip_done timed out [ 52.605850] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
Rafael, can you please attach the full log?
Since fastboot isn't the default, we don't have a fix yet.
I think https://patchwork.freedesktop.org/series/59950/ will fix this.
Forgot to put the bugzilla link into the commit msg, but I think this is now fixed. commit 13b7648b7eab7e8259a2fb267b498bd9eba81ca0 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Apr 25 19:29:05 2019 +0300 drm/i915: Fix fastset vs. pfit on/off on HSW EDP transcoder
Please forgive my ignorance, I couldn't find this out from the linked commits. Which kernel version will this be part of? If I wanted to test it on my machine, which branch should I build?
The commit has been merged upstream in linux-next as of 5 days ago https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20190517&id=da471250706e2f103a1627d1d279c9de44325993 If you want to test it, compile linux-next or wait for the commit to reach a stable kernel version.
I tested linux-next 20190517 on my Thinkpad S1 Yoga with an i7-4500U HSW, and I still get a blank screen with fastboot=1. The same happens on a Thinkpad T440s using an i7-4600U. See bug#108773 for details and log files.
(In reply to Julius B. from comment #21) > I tested linux-next 20190517 on my Thinkpad S1 Yoga with an i7-4500U HSW, > and I still get a blank screen with fastboot=1. The same happens on a > Thinkpad T440s using an i7-4600U. See bug#108773 for details and log files. Can you please verify with drmtip (https://cgit.freedesktop.org/drm-tip)?
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.