Created attachment 92233 [details] Xorg.0.log -- chipset: Intel Corporation ValleyView Gen7 [8086:0f31] -- system architecture: x86_64 -- Linux distribution: Ubuntu 12.04.2 -- libdrm 2.4.43 -- Kernel versions affected: 3.13-rc4 -- xf86-video-intel: 2.20.9 The internal display on this all-in-one form factor machine stopped working after a recent bios update, no other components changed. [ 15.390698] ------------[ cut here ]------------ [ 15.390728] WARNING: at /var/lib/dkms/drm-dkms-i915/3.13.0rc4hwe1somerville1/build/backports/drivers/gpu/drm/i915/intel_dp.c:1805 intel_enable_dp+0x8e/0x90 [i915]() [ 15.390731] Hardware name: Foo [ 15.390732] Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi coretemp snd_rawmidi snd_seq_midi_event ath9k(O) snd_seq kvm_intel mac80211(O) i915(O) ath9k_common(O) kvm snd_timer uv$ [ 15.390788] Pid: 299, comm: plymouthd Tainted: G O 3.5.0-44-generic #67~precise1-Ubuntu [ 15.390791] Call Trace: [ 15.390800] [<ffffffff81052e9f>] warn_slowpath_common+0x7f/0xc0 [ 15.390804] [<ffffffff81052efa>] warn_slowpath_null+0x1a/0x20 [ 15.390822] [<ffffffffa05e250e>] intel_enable_dp+0x8e/0x90 [i915] [ 15.390839] [<ffffffffa05e265a>] vlv_pre_enable_dp+0x11a/0x170 [i915] [ 15.390856] [<ffffffffa05ca59c>] valleyview_crtc_enable+0x11c/0x420 [i915] [ 15.390873] [<ffffffffa05cc837>] __intel_set_mode+0x747/0x1570 [i915] [ 15.390889] [<ffffffffa05cfaf6>] intel_set_mode+0x16/0x30 [i915] [ 15.390906] [<ffffffffa05d0349>] intel_crtc_set_config+0x839/0xa50 [i915] [ 15.390924] [<ffffffffa029f25c>] drm_mode_set_config_internal+0x5c/0xe0 [drm] [ 15.390931] [<ffffffffa044b323>] drm_fb_helper_restore_fbdev_mode+0xb3/0xe0 [drm_kms_helper] [ 15.390951] [<ffffffffa060c71a>] intel_fbdev_restore_mode+0x4a/0x84 [i915] [ 15.390964] [<ffffffffa0592835>] i915_driver_lastclose+0x45/0x60 [i915] [ 15.390974] [<ffffffffa0294b09>] drm_lastclose+0x49/0x1a0 [drm] [ 15.390985] [<ffffffffa029509c>] drm_release+0x43c/0x600 [drm] [ 15.390990] [<ffffffff81189e7e>] __fput+0xbe/0x240 [ 15.390994] [<ffffffff8118a025>] fput+0x25/0x30 [ 15.390998] [<ffffffff81186ca6>] filp_close+0x66/0x90 [ 15.391002] [<ffffffff81186d6e>] sys_close+0x9e/0x110 [ 15.391008] [<ffffffff816a7729>] system_call_fastpath+0x16/0x1b [ 15.391010] ---[ end trace 4516aee112870a3a ]--- [ 15.526414] [drm:intel_pipe_config_compare] *ERROR* mismatch in dpll_hw_state.dpll_md (expected 0x00000000, found 0x00000003)
Created attachment 92234 [details] dmesg from 3.13-rc4 It says 3.5 but has drm backported from 3.13-rc4
Robert, same machine as bug 73477?
Different machine, this one is a dell AIO and that one is a traditional desktop tower from HP.
Could you try the latest nightly kernel? There's been quite a lot of BYT related fixes since -rc4: git://people.freedesktop.org/~danvet/drm [drm-intel-nightly] If that doesn't work could you provide a register dump both with and without i915.modeset=0, before any client (plymouthd) would access the driver? The required tool is at: git://anongit.freedesktop.org/xorg/app/intel-gpu-tools and (with debugfs mounted) you need to run as root: # tools/quick_dump/quick_dump.py -a Thanks.
No luck with today's drm-intel-next, still working how how to get you the other information remotely but should have it soon.
(In reply to comment #5) > No luck with today's drm-intel-next, still working how how to get you the > other information remotely but should have it soon. Sorry, that's drm-intel-nightly
Created attachment 92871 [details] quick_dump.py -a with i915.modeset=1, no plymouth
Created attachment 92872 [details] quick_dump.py -a with i915.modeset=0, no plymouth
So, you are not getting the display? full blank screen, right? What is dmesg from nightly? same slowpath x fastpath with mismatch on dpll? What bios/vbios version are you using? Before the bios update same system was working?
Created attachment 92909 [details] [review] force PP sequencing for DP Could you try the attached patch applied on -nightly? It is just a wild guess, but it seems to fix similar issues for me, so it's worth a try.
Created attachment 92937 [details] comment #10 backported to 3.13 I haven't been able to use drm-intel-nightly because it hard locks the machine and I can't access it remotely, but backporting the patch in comment #10 (attached) to 3.13 seems to have worked. I won't have confirmation that the display is actually working properly until someone is in the office tomorrow though. No more explosions in dmesg at least :)
Created attachment 92938 [details] dmesg from 3.13-rc4 with the patch in comment #11
I was just told that the "internal" display on the AIO is working fine with this patch. Is this something that could be sent to stable so these machines can work on released kernels?
(In reply to comment #13) > I was just told that the "internal" display on the AIO is working fine with > this patch. Is this something that could be sent to stable so these machines > can work on released kernels? Thanks for checking. The root cause is still a bit unclear, once that's found we'll get back with a proper solution.
Robert, could you answer Rodrigo's questions in comment 9? Also (an idea from Jesse) that even though our driver detects your display as DP (external monitor) you might actually have an embedded panel (eDP). Could you confirm this somehow? Also please provide the content of /sys/kernel/debug/dri/0/i915_opregion with your current BIOS, and if you can the same with the earlier BIOS that used to work. Thanks.
(In reply to comment #15) > Robert, could you answer Rodrigo's questions in comment 9? > > Also (an idea from Jesse) that even though our driver detects your display > as DP (external monitor) you might actually have an embedded panel (eDP). > Could you confirm this somehow? > > Also please provide the content of /sys/kernel/debug/dri/0/i915_opregion > with your current BIOS, and if you can the same with the earlier BIOS that > used to work. > > Thanks. Could you also try if the following patch fixes the problem? https://patchwork.kernel.org/patch/3557501/ In any case I'll ask danvet to cc this patch to stable.
Robert, the fix that I think fixes this bug too, is now merged to -nightly, could you give it a try? If you want to try it on 3.13 too it's the following commit: drm/i915: vlv: fix DP PHY lockup due to invalid PP sequencer setup If things work, we don't need the answers in the previous comments.
Closing this based on comment 13 and comment 17.
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.