|Summary:||Commit 516a49cc19467e298d08a404f73a6e311f4548d1 causes increase in boot time on Sandy Bridge|
|Product:||DRI||Reporter:||Daniel Kamil Kozar <dkk089>|
|Component:||DRM/Intel||Assignee:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|Status:||RESOLVED FIXED||QA Contact:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|i915 platform:||i915 features:|
Description Daniel Kamil Kozar 2019-01-07 17:53:36 UTC
Created attachment 143003 [details] dmesg log with drm.debug=0xe As outlined in https://lkml.org/lkml/2019/1/4/611 , I experienced a significant increase in boot time after moving from kernel 4.19.12 to 4.20. The hardware is a Asus K53SV with a i7-2630QM (Sandy Bridge) with an external display connected via HDMI. Bisecting the commits revealed 516a49cc19467e298d08a404f73a6e311f4548d1 as the cause. The requested dmesg log with drm.debug=0xe is attached to this ticket.
Comment 1 Ville Syrjala 2019-01-08 13:26:14 UTC
The hardware seems to be in a rather weird state when the driver loads. The PLL is on but apparently misconfigured, DP-C is on but not attached to the right pipe, etc. Please reboot without loading i915, then run 'intel_reg dump > regdump' (intel_reg comes from igt-gpu-tools), and attach the results here.
Comment 2 Daniel Kamil Kozar 2019-01-08 17:45:39 UTC
Created attachment 143017 [details] Output of intel_reg dump without i915 loaded Here's the register dump that was taken without i915 loaded, with the monitor attached (but no signal being output), the laptop display turned off, and kernel running in runlevel 1. If it helps, the monitor in question is a Dell U2515H whose native resolution is 2560x1440, which is probably reported in the EDID. The maximum resolution supported by this chip is supposedly 1080p, though I have no problems with running my desktop in 1440p@44 with a custom modeline specified in Xorg.conf. The warning messages visible in the kernel output (attached earlier) also appeared on the old kernel version, and didn't seem to cause any trouble besides being there.
Comment 3 Ville Syrjala 2019-01-08 20:56:39 UTC
Created attachment 143020 [details] [review] [PATCH] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen I think this ought to work around the problem. It's not ideal though since we still get a bunch of WARNs. As mentioned in the patch I think this same problem was seen on some other SNB machine years ago, but it got fixed by a BIOS update. Sadly looks like your machine doesn't have that option (unless I missed something on the ASUS website). Please test and let me know whether this helps.
Comment 4 Daniel Kamil Kozar 2019-01-08 21:56:03 UTC
Works great for me! The boot time, and the messages, are back to what they were in 4.19.12. I applied the patch on top of 5.0-rc1 and only had to change IS_GEN(dev_priv, 6) to IS_GEN6(dev_priv) which I hope does the same thing. Unfortunately, you're right about the BIOS : I'm running the latest revision, which has not been updated since 2011. Thanks for getting this sorted out so quickly.
Comment 5 Ville Syrjala 2019-01-28 14:05:46 UTC
commit 7bed8adcd9f86231bb69bbc02f88ad89330f99e3 (danvet2/for-linux-next, danvet2/drm-intel-next-queued) Author: Ville Syrjälä <firstname.lastname@example.org> Date: Fri Jan 11 19:49:50 2019 +0200 drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen
Comment 6 Annie Salazar 2019-11-15 09:51:24 UTC
Causes increase in boot time on sandy bridge, Do you know why we are giving you importance in boot time. Sandy bridge site material is here on https://topamericanwriters.com/customwritings-com-review/ page. If you really want to know more about it then you must come and get more information about this whole.