On Tue, Dec 13, 2016 at 09:40:51PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 13, 2016 at 05:29:54PM -0200, Paulo Zanoni wrote:
> > Em Ter, 2016-12-13 às 21:17 +0200, Ville Syrjälä escreveu:
> > > On Tue, Dec 13, 2016 at 11:00:50AM -0800, Linus Torvalds wrote:
> > > >
> > > > This isn't new, but I thought I'd report it since it doesn't seem
> > > > to
> > > > get fixed on its own..
> >
> > For me this is new. Ever since September, my SKL SDP booted 100% fine
> > without any sort of error message. In the last few weeks I also noticed
> > this message started appearing. I guess I just assumed we'd end up
> > fixing it since I saw DP patches floating all the time.
> >
> > We should really try to bisect it, especially since it's easy to
> > reproduce this with our SDPs...
>
> No need to bisect since it's been known all along. The actual
> bug was uncovered by dd7880908223 ("drm/i915: Warn about aux
> msg buffer vs. size mismatch") which resulted in tons of
> WARNs, and we put in d4cb3fd9b548 ("drm/i915/dp: add lane_count
> check in intel_dp_check_link_status") to reduce it to just
> this single WARN instead.
>
> > Also, shouldn't our CI have caught this? Why didn't it?
>
> Unfortunately CI doesn't catch anything that happens at boot.
> And we turn off the outputs at driver unload, so the reload
> test won't catch it either. We should really prevent the driver
> from loading until we start the tests.
Tomi has started to look into this, i.e. adding a 0th test that just
checks dmesg on boot. Similar problem, but worse exist if someone disables
lockdep at boot-up already with a locking loop.
At least if you outright kill the machine CI will notice ;-)
-Daniel
>
> >
> > > >
> > > > [drm] Initialized i915 1.6.0 20161121 for 0000:00:02.0 on minor 0
> > > > ------------[ cut here ]------------
> > > > WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_dp.c:4018
> > > > intel_dp_check_link_status+0x1db$
> > > > WARN_ON_ONCE(!intel_dp->lane_count)
> > > > Modules linked in:
> > > > rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul
> > > > crc32c_intel
> > > > i915 ghash_clmulni_intel i2c_$
> > > > CPU: 1 PID: 130 Comm: kworker/u8:7 Not tainted 4.9.0-04822-
> > > > g9439b3710df6 #6
> > > > Hardware name: Dell Inc. XPS 13 9350/09JHRY, BIOS 1.4.4
> > > > 06/14/2016
> > > > Workqueue: events_unbound async_run_entry_fn
> > > > Call Trace:
> > > > intel_dp_check_link_status+0x1db/0x200 [i915]
> > > > intel_dp_detect+0x697/0xa40 [i915]
> > > > drm_helper_probe_single_connector_modes+0x2a3/0x500
> > > > [drm_kms_helper]
> > > > drm_setup_crtcs+0x7b/0x9c0 [drm_kms_helper]
> > > > drm_fb_helper_initial_config+0x79/0x3e0 [drm_kms_helper]
> > > > intel_fbdev_initial_config+0x18/0x30 [i915]
> > > > async_run_entry_fn+0x37/0x150
> > > > process_one_work+0x1f1/0x480
> > > > worker_thread+0x48/0x4d0
> > > > kthread+0x101/0x140
> > > > ret_from_fork+0x22/0x30
> > > > ---[ end trace 10162024459bbe32 ]---
> > > >
> > > > That's obviously my XPS13, and it has nothing attached to it, so
> > > > just
> > > > the internal laptop display.
> > > >
> > > > This is all intel, with the Skylake Iris Graphics 540 (i7-6560U).
> > > >
> > > > Everything seems to work fine, it's just the ugly warning.
> > >
> > > Yeah, it shouldn't really matter as long as the DP link doesn't fall
> > > over during boot. If that were to happen we wouldn't be able to
> > > retrain the link since we didn't copy the link parameters (eg. the
> > > lane count) to the right place.
> > >
> > > I posted a patch a while back that should fix it, but Daniel didn't
> > > like it, and it's looking like no one is volunteering to work on it
> > > further.
> > >
>
> --
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
