Created attachment 82901 [details] Xorg.0.log [drm:drm_pci_agp_init] *ERROR* Cannot initialize the agpgart module. Kernel:http://cgit.freedesktop.org/~danvet/drm-intel/?h=drm-intel-next/drm-intel-fixes-2013-07-22.tar.gz X.Org X Server 1.14.2 mesa-9.2 libdrm-2.4.46 Device: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:0f00] (rev 06) 00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:0f31] (rev 06 Error code: Aug 7 04:41:35 localhost kernel: [ 70.999560] [drm] Initialized drm 1.1.0 20060810 Aug 7 04:41:35 localhost kernel: [ 71.137128] microcode: CPU0 sig=0x30672, pf=0x2, revision=0x213 Aug 7 04:41:35 localhost kernel: [ 71.234888] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the agpgart module. Aug 7 04:41:35 localhost kernel: [ 71.241224] DRM: Fill_in_dev failed Attachment is Xorg.0.log If you need any other information.,please tell me. Thanks!
Change importance.
i915.ko doesn't depend upon the agpgart for Baytrail, the error is just an obnoxious warning from DRM that we need to remove. Paste the full dmesg and remove nomodeset.
Oh, of course nomodeset is not supported on Baytrail - no wonder we abort the module load.
Created attachment 82910 [details] /var/log/messages
We didn't add nomodeset and backlight is off. so can't get dmesg info. attachment is /var/log/messages Thanks! There are another error information. Aug 7 06:18:29 localhost kernel: [ 71.126427] [drm] Memory usable by graphics device = 2048M Aug 7 06:18:29 localhost kernel: [ 71.131560] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver Aug 7 06:18:29 localhost kernel: [ 71.144096] Console: switching to colour dummy device 80x25 Aug 7 06:18:29 localhost kernel: [ 71.189231] microcode: CPU0 sig=0x30672, pf=0x2, revision=0x213 Aug 7 06:18:29 localhost kernel: [ 71.276455] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). Aug 7 06:18:29 localhost kernel: [ 71.276475] [drm] Driver supports precise vblank timestamp query. Aug 7 06:18:29 localhost kernel: [ 71.288301] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem Aug 7 06:18:29 localhost kernel: [ 71.450468] microcode: CPU1 sig=0x30672, pf=0x2, revision=0x213 Aug 7 06:18:29 localhost kernel: [ 71.474402] microcode: CPU2 sig=0x30672, pf=0x2, revision=0x213 Aug 7 06:18:29 localhost kernel: [ 71.498063] microcode: CPU3 sig=0x30672, pf=0x2, revision=0x213 Aug 7 06:18:29 localhost kernel: [ 71.512159] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2 Aug 7 06:18:29 localhost kernel: [ 71.532011] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba Aug 7 06:18:29 localhost kernel: [ 71.544006] fbcon: inteldrmfb (fb0) is primary device Aug 7 06:18:29 localhost kernel: [ 74.204070] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting Aug 7 06:18:29 localhost kernel: [ 74.436645] Console: switching to colour frame buffer device 128x48 Aug 7 06:18:29 localhost kernel: [ 74.455287] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device Aug 7 06:18:29 localhost kernel: [ 74.455412] i915 0000:00:02.0: registered panic notifier Aug 7 06:18:29 localhost kernel: [ 75.162144] acpi device:1c: registered as cooling_device4 Aug 7 06:18:29 localhost kernel: [ 75.285441] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no
Hi Chris, Please help to check the error message. And change the bug summary and Reopen it. Thanks!
(In reply to comment #6) > Please help to check the error message. And change the bug summary and > Reopen it. Thanks! Please add drm.debug=0xe module parameter and attach the dmesg.
Created attachment 83884 [details] /var/log/messages after add drm.debug=0xe
Hi, any update for this issue? if you need any other information, please let me know. Thanks!
We tried latest drm-intel-next-queued from http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=68c8c17f527effba57f4e82efee18a249c6a1b58 it still can't enter to Desktop, LCD can't light on. Could you give us some suggestion for this issue, is it related to LCD HW? Sep 16 11:08:02 localhost rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="259" x-info="http://www.rsyslog.com"] rsyslogd was HUPed Sep 16 11:19:21 localhost kernel: [ 3459.774649] [drm:vlv_enable_pll] *ERROR* DPLL 0 failed to lock Sep 16 11:19:26 localhost kernel: [ 3465.354633] [drm:ironlake_wait_panel_status] *ERROR* Panel status timeout: status 00000000 control abcd000b Sep 16 11:19:26 localhost kernel: [ 3465.461603] ------------[ cut here ]------------ Sep 16 11:19:26 localhost kernel: [ 3465.461729] WARNING: CPU: 1 PID: 335 at drivers/gpu/drm/i915/intel_dp.c:248 intel_dp_check_edp+0x9a/0xf0 [i915]() Sep 16 11:19:26 localhost kernel: [ 3465.461739] eDP powered off while attempting aux channel communication. Sep 16 11:19:26 localhost kernel: [ 3465.461748] Modules linked in: ebtable_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack bnep bluetooth ebtable_filter ebtables ip6table_filter ip6_tables uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm xhci_hcd snd_page_alloc snd_timer ideapad_laptop snd dm_mirror i915 video battery_linpus i2c_algo_bit drm_kms_helper drm i2c_core sparse_keymap pcspkr rfkill soundcore dm_region_hash dm_log mac_hid battery uinput Sep 16 11:19:26 localhost kernel: [ 3465.461912] CPU: 1 PID: 335 Comm: Xorg Tainted: G W 3.11.0-8.11.1.i686.PAE #1 Sep 16 11:19:26 localhost kernel: [ 3465.461923] Hardware name: LENOVO 20109/IdeaPad Flex10, BIOS 93CN07WW 07/30/2013 Sep 16 11:19:26 localhost kernel: [ 3465.461933] 00000000 00000000 f34f9c20 c09f28cc fa8c16b8 f34f9c50 c0444584 fa8c1754 Sep 16 11:19:26 localhost kernel: [ 3465.461969] f34f9c7c 0000014f fa8c16b8 000000f8 fa889efa fa889efa f4930000 001e1204 Sep 16 11:19:26 localhost kernel: [ 3465.462003] 001e1200 f34f9c68 c0444643 00000009 f34f9c60 fa8c1754 f34f9c7c f34f9c98 Sep 16 11:19:26 localhost kernel: [ 3465.462036] Call Trace: Sep 16 11:19:26 localhost kernel: [ 3465.462066] [<c09f28cc>] dump_stack+0x41/0x52 Sep 16 11:19:26 localhost kernel: [ 3465.462092] [<c0444584>] warn_slowpath_common+0x84/0xa0 Sep 16 11:19:26 localhost kernel: [ 3465.462197] [<fa889efa>] ? intel_dp_check_edp+0x9a/0xf0 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.462298] [<fa889efa>] ? intel_dp_check_edp+0x9a/0xf0 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.462318] [<c0444643>] warn_slowpath_fmt+0x33/0x40 Sep 16 11:19:26 localhost kernel: [ 3465.462420] [<fa889efa>] intel_dp_check_edp+0x9a/0xf0 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.462525] [<fa88acb6>] intel_dp_aux_native_write+0x26/0xd0 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.462629] [<fa88ae6d>] intel_dp_set_link_train+0x10d/0x260 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.462839] [<fa88d744>] intel_dp_complete_link_train+0x54/0x260 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.463003] [<fa88ca9f>] ? ironlake_edp_panel_vdd_off+0x9f/0xd0 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.463134] [<fa88d9da>] intel_enable_dp+0x6a/0xe0 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.463231] [<fa877345>] valleyview_crtc_enable+0x365/0x3a0 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.463333] [<fa87c798>] intel_crtc_update_dpms+0x78/0x90 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.463441] [<fa87c84c>] intel_encoder_dpms+0x2c/0x30 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.463539] [<fa87fd55>] intel_connector_dpms+0x35/0x60 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.463676] [<fa87fd20>] ? intel_modeset_check_state+0x780/0x780 [i915] Sep 16 11:19:26 localhost kernel: [ 3465.463787] [<f8724484>] drm_mode_obj_set_property_ioctl+0x3b4/0x3c0 [drm] Sep 16 11:19:26 localhost kernel: [ 3465.463812] [<c09f5598>] ? mutex_lock+0x18/0x37 Sep 16 11:19:26 localhost kernel: [ 3465.463878] [<f87244c7>] drm_mode_connector_property_set_ioctl+0x37/0x50 [drm] Sep 16 11:19:26 localhost kernel: [ 3465.463955] [<f8714e70>] drm_ioctl+0x4b0/0x560 [drm] Sep 16 11:19:26 localhost kernel: [ 3465.464030] [<f8724490>] ? drm_Sep 16 11:22:22 localhost rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="256" x-info="http://www.rsyslog.com"] start Sep 16 11:22:22 localhost systemd[1]: Started Collect Read-Ahead Data. Sep 16 11:22:22 localhost systemd[1]: Started Replay Read-Ahead Data. Sep 16 11:22:22 localhost systemd[1]: Starting Load legacy module configuration... Sep 16 11:22:22 localhost systemd[1]: Starting File System Check on Root Device... Sep 16 11:22:22 localhost systemd[1]: Starting Apply Kernel Variables... Sep 16 11:22:22 localhost systemd[1]: Starting Setup Virtual Console... Sep 16 11:22:22 localhost systemd[1]: Started Load Kernel Modules. Sep 16 11:22:22 localhost systemd[1]: Mounted FUSE Control File System. Sep 16 11:22:22 localhost systemd[1]: Mounting Configuration File System... Sep 16 11:22:22 localhost systemd[1]: Started Set Up Additional Binary Formats. Sep 16 11:22:22 localhost systemd[1]: Started Load legacy module configuration. Sep 16 11:22:22 localhost kernel: [ 0.000000] Initializing cgroup subsys cpuset Sep 16 11:22:22 localhost kernel: [ 0.000000] Initializing cgroup subsys cpu Sep 16 11:22:22 localhost kernel: [ 0.000000] Initializing cgroup subsys cpuacct Sep 16 11:22:22 localhost kernel: [ 0.000000] Linux version 3.11.0-8.11.1.i686.PAE (bruce@brucemao) (gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC) ) #1 SMP Sat Sep 14 14:53:28 CST 2013
Can you test again with current drm-intel-nightly? eDP is coming up for me now, though we still see training failures in multi-head DPMS and when resuming from S3.
Created attachment 86826 [details] /var/log/messages(2013-09-27)
Created attachment 86827 [details] /var/log/messages after add drm.debug=0xe(2013-09-27)
Use drm-intel-8153de8b327e89bad0e36f82b098e37a6e9ef5bb.tar.gz(2012-09-27 nightly),display still can't show. attachment is /var/log/messages and /var/log/messages added drm.debug=0xe, please refer. BTW,did you reproduce the issue in your side? Thanks!
I did see this, before the DPLL fix in commit 559a81bdaee1763313d7305521b9b0ae5a1b99c1 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Oct 1 10:41:38 2013 -0700 i915/vlv: untangle integrated clock source handling v4 but you may also need the backlight fixes from http://www.spinics.net/lists/intel-gfx/msg34027.html if your backlight isn't coming up properly.
So can you try -nightly again now that it has the DPLL fix? And if that doesn't work, try applying the backlight patch on top?
the backlight still can't light on. after i tried drm-intel-7f1bb31c83d2b0e33d39b5390df5c11c535688f7.tar.gz and added the patch http://www.spinics.net/lists/intel-gfx/msg34027.html Please refer attachment messages-1007 with drm.debug=0xe
Created attachment 87262 [details] messages-1007 with drm.debug=0xe
(In reply to comment #18) > Created attachment 87262 [details] > messages-1007 with drm.debug=0xe This log does not have the debugs enabled. Please ensure you really have the drm.debug=0xe module parameter set. Also, the output of 'dmesg' is more relevant than messages (which has plenty of extraneous information), so please provide that.
Created attachment 87440 [details] dmsg.log with drm.debug=0xe I make sure the backlight is not light on with i915 just now and the system is alive. Below is the steps of getting dmesg.log. Power on->backlight is black, then press ctl+alt+F2 to enter to tty2->backlight still is black, I log in step by step, then type dmesg > dmesg.log-> dmesg.log generated. Thanks!
(In reply to comment #20) > Below is the steps of getting dmesg.log. > Power on->backlight is black, then press ctl+alt+F2 to enter to > tty2->backlight still is black, I log in step by step, then type dmesg > > dmesg.log-> dmesg.log generated. Thanks, this is the kind of dmesg I want! And it tells me you're running kernel version "3.11.0-8.11.1.i686.PAE" which clearly isn't drm-intel-nightly branch of [1], which has relevant fixes. Please do try that. Also, I see that you have backlight=vendor kernel parameter. That doesn't exist; it's actually acpi_backlight=vendor. But please try the -nightly branch *without* any backlight parameters first. Thanks. [1] git://people.freedesktop.org/~danvet/drm-intel
Created attachment 87448 [details] dmesg1.log Actually, 3.11.0-8.11.1.i686.PAE build 20131007 drm-intel-nightly and added the patch http://www.spinics.net/lists/intel-gfx/msg34027.html . I didn't change the kernel name. please refer attach dmesg1.log without backlight=vendor.
(In reply to comment #22) > Actually, 3.11.0-8.11.1.i686.PAE build 20131007 drm-intel-nightly and added > the patch http://www.spinics.net/lists/intel-gfx/msg34027.html . Ok. This isn't actually about the backlight, the link training fails before we even get to the backlight part (but we may need to fix that too after we get the link training to succeed). It's odd... clock recover succeeds every time, but channel equalization fails. Adding Todd to CC in case he has some ideas. > I didn't change the kernel name. Ah, okay. That confused me.
What platform is this? A Bayley Bay? Or Bay Lake? Or something else? Also is it a BYT-M, BYT-I or BYT-T SKU?
The platform is BayTrail-M and Model is Lenovo Flex10.
clear NEEDINFO
*** Bug 69693 has been marked as a duplicate of this bug. ***
Two patchsets to try: http://lists.freedesktop.org/archives/intel-gfx/2013-November/035237.html and http://lists.freedesktop.org/archives/intel-gfx/2013-November/035276.html
And a patch: --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1230,9 +1230,7 @@ void ironlake_edp_panel_off(struct intel_dp *intel_dp) WARN(!intel_dp->want_panel_vdd, "Need VDD to turn off panel\n"); pp = ironlake_get_pp_control(intel_dp); - /* We need to switch off panel power _and_ force vdd, for otherwise some - * panels get very unhappy and cease to work. */ - pp &= ~(POWER_TARGET_ON | EDP_FORCE_VDD | PANEL_POWER_RESET | EDP_BLC_EN + pp &= ~(POWER_TARGET_ON | PANEL_POWER_RESET | EDP_BLC_ENABLE); pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
Created attachment 88810 [details] dmesg_1107.log
It can enter to OS successfully after added below three patches, please refer dmesg_1107.log. Thanks a lot! http://lists.freedesktop.org/archives/intel-gfx/2013-November/035237.html http://lists.freedesktop.org/archives/intel-gfx/2013-November/035276.html --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1230,9 +1230,7 @@ void ironlake_edp_panel_off(struct intel_dp *intel_dp) WARN(!intel_dp->want_panel_vdd, "Need VDD to turn off panel\n"); pp = ironlake_get_pp_control(intel_dp); - /* We need to switch off panel power _and_ force vdd, for otherwise some - * panels get very unhappy and cease to work. */ - pp &= ~(POWER_TARGET_ON | EDP_FORCE_VDD | PANEL_POWER_RESET | EDP_BLC_EN + pp &= ~(POWER_TARGET_ON | PANEL_POWER_RESET | EDP_BLC_ENABLE); pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
Can you narrow down which one(s) fixed the problem? The fixes from the first set (the backlight stuff) are already upstream, so if drm-intel-nightly works for you then we can close this out. Thanks!
Created attachment 88874 [details] dmesg_1108.log it also can enter to OS after we tried http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-nightly&id=d996c93e55d51f883f30115eb04b4f28794dcdd2 dmesg_1108.log for your reference. when will you merge to mainline? Thanks for your support!
Patches are heading towards 3.13 (and if they don't blow up too badly we could backport them to older stuff).
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.