Created attachment 257273 [details] journalctl of boot in error Asus UX305UA don't boot using Fedora 25 with kernel 4.11.5 and above: - no problem with 4.11.4 and previous - black screen with both 4.11.5, 4.11.6, 4.11.7 and 4.11.8 Many drivers/gpu/drm/i915/intel_pm.c traces in journalctl (see attached file) If I connect an external monitor on HDMI, I get following message on this monitor: [ 1.308240] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 31: Can't calculate constants, dotclock = 0! You are in emergency mode... Asus UX305UA hardware: 00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 08) 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07) 00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 08) 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21) 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21) 00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21) 00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21) 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21) 00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21) 00:1c.0 PCI bridge: Intel Corporation Device 9d10 (rev f1) 00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #6 (rev f1) 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21) 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21) 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21) 02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59) According https://bugzilla.redhat.com/show_bug.cgi?id=1463085 and http://forums.fedoraforum.org/showthread.php?p=1789667 I am not alone to have this problem on Asus UX305UA.
Problem still occur with 4.11.9.... Last working kernel on Asus UX305UA is 4.11.4, all kernel above produce same error... Information about processor: [quote]vendor_id : GenuineIntel cpu family : 6 model : 78 model name : Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz stepping : 3 microcode : 0xba [/quote] Changed Severity from Normal to Blocking (for Asus UX305UA)
I did a test with Live CD of other distrib archlinux-2017.07.01-x86_64.iso who uses kernel 4.11.7... Same result, black screen at boot without external monitor. Is it not possible to see which change between 4.11.4 and 4.11.5 introduce this bug on Asus UX305UA with Intel(R) Core(TM) i7-6500U CPU ?
From the article: Kernel mode setting https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID Forcing modes and EDID In case that your monitor/TV is not sending the appropriate EDID or similar problems, you will notice that the native resolution is not automatically configured or no display at all. The kernel has a provision to load the binary EDID data, and provides as well data to set four of the most typical resolutions. If you have the EDID file for your monitor the process is easy. If you do not have, you can either use one of the built-in resolution-EDID binaries (or generate one during kernel compilation, more info here) or build your own EDID. In case you have an EDID file (e.g. extracted from Windows drivers for your monitor or using get-edid command from read-edid), create a dir edid under /usr/lib/firmware: # mkdir /usr/lib/firmware/edid and then copy your binary into the /usr/lib/firmware/edid directory. To load it at boot, specify the following in the kernel command line: drm_kms_helper.edid_firmware=edid/your_edid.bin You can also specify it only for a specified connection: drm_kms_helper.edid_firmware=VGA-1:edid/your_edid.bin _nobody_
I have the exact issue with kernel 4.11.5 and newer on an Asus UX305U laptop. Kernel 4.11.4 and previous versions have worked fine.
I have the exact same issue with kernel 4.11.6 on an Asus UX306U laptop.
I have the same issue with 4.11.5 and newer on an Asus UX305UA.
I have the same issue since 4.11.5 using Fedora 25 on an Asus Zenbook UX305UA. A clean installation with Fedora 26 don't solve the problem. Updating until kernel 4.11.11-300.fc26.x86_64, still failing.
(In reply to didierg from comment #0) > Asus UX305UA don't boot using Fedora 25 with kernel 4.11.5 and above: > > - no problem with 4.11.4 and previous > - black screen with both 4.11.5, 4.11.6, 4.11.7 and 4.11.8 Which is it, you have a black screen or the machine does not boot? Judging by the git logs, the only thing that looks potentially suspicious between v4.11.4 and v4.11.5 in drm/i915 is commit 6b183d1b84764e81dcb64f6b41151e79db23679c Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Mar 10 15:27:58 2017 +0200 drm/i915/vbt: split out defaults that are set when there is no VBT commit bb1d132935c2f87cd261eb559759fe49d5e5dc43 upstream. Please try reverting that. If it turns out to be a drm/i915 issue, please file the bugs over at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
Created attachment 257773 [details] bug_196233_journalctl_4.11.4_OK bug_196233_journalctl_4.11.4_OK
Created attachment 257775 [details] bug_196233_journalctl_4.11.5_KO_with_no_ext bug_196233_journalctl_4.11.5_KO_with_no_external monitor
Created attachment 257777 [details] bug_196233_journalctl_4.11.5.with_external_on_HDMI bug_196233_journalctl_4.11.5.with_external_monitor on_HDMI
(In reply to Jani Nikula from comment #8) > Which is it, you have a black screen or the machine does not boot? I attached journalctl logs with drm.debug=0xe parameter for three test cases: - with 4.11.4 laptop UX305UA works fines - with 4.11.5 and NO external monitor, I get grub2 messages, blinking cursor during one second then black screen. At this state Alt-Ctl-Del is inoperative and I can only power off the laptop. - with 4.11.5 and external monitor on HDMI, I get gdm them gnome desktop on external monitor > If it turns out to be a drm/i915 issue, please file the bugs over at > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel Already done: https://bugs.freedesktop.org/show_bug.cgi?id=101745
Hello Jani (Finland/Helsinki INTEL Open Source Technology Center GFX member), > Author: Jani Nikula <jani.nikula@intel.com> > Date: Fri Mar 10 15:27:58 2017 +0200 > > drm/i915/vbt: split out defaults that are set when there is no VBT > > commit bb1d132935c2f87cd261eb559759fe49d5e5dc43 upstream. > > Please try reverting that. These people are NOT developers. These people are notebook users. Unfortunately, SKL U and Y have problems with the INTEL based HW platform introduced by ASUS. What exactly is the problem, I just can guess... Here are couple of hints for you, Jani: https://bugzilla.redhat.com/show_bug.cgi?id=1463085#c12 So, there is some problem with VBT.dat table (in other words with BIOS) with Asus UX305UA. And mine comment above reflects the problem(s). Once external monitor is not there (this problem with EDID is somehow fixed), VBT.dat is NOT read or not correctly interpreted from BIOS. You've got all info you need. Good Luck, Jani! ;-) _nobody_
(In reply to Niemand from comment #13) > > Please try reverting that. > > These people are NOT developers. These people are notebook users. Sorry to be blunt, but this bugzilla is not the first line support either. These people are kernel developers. The assumption here (and on the freedesktop.org bugzilla for that matter) is pretty much that you can build and run your own kernels. > So, there is some problem with VBT.dat table (in other words with BIOS) with > Asus UX305UA. And mine comment above reflects the problem(s). Once external > monitor is not there (this problem with EDID is somehow fixed), VBT.dat is > NOT read or not correctly interpreted from BIOS. Are you doing a legacy BIOS boot or a UEFI boot?
Hey everyone, i just built the 4.13.0-rc3 kernel WITHOUT bb1d132935c2f87cd261eb559759fe49d5e5dc43 and that's working for me. To verify i built the same kernel WITH bb1d132935c2f87cd261eb559759fe49d5e5dc43 and got the same error as before. with kind regards Oliver
> Are you doing a legacy BIOS boot or a UEFI boot? It does NOT matter for this discussion/bug. I read (as the matter of fact) what these people write. And, YES, they all probably use UEFI boot (CSM OFF). Native BIOS mode (I assume they all have 64 bit BIOSes, and I assume that ASUS BIOS experts know the differences) for last 5 years. I am very surprised that you, Jani, as INTEL GFX expert, do not understand difference between vBIOS and VBT.dat?! Let me give you a (free of charge) lesson: vBIOS does matter for the mode (it will be loaded for legacy CSM mod). VBT.dat will be loaded to Linux ALWAYS (no matter in which mode BIOS is in). Now, you should go and educate yourself more. ;-) I'll wait here for what you'll find out, and as the outcome, how you'll/INTEL fix this mess. _nobody_
(In reply to Niemand from comment #16) > > Are you doing a legacy BIOS boot or a UEFI boot? > > It does NOT matter for this discussion/bug. I read (as the matter of fact) > what these people write. And, YES, they all probably use UEFI boot (CSM > OFF). Native BIOS mode (I assume they all have 64 bit BIOSes, and I assume > that ASUS BIOS experts know the differences) for last 5 years. > > I am very surprised that you, Jani, as INTEL GFX expert, do not understand > difference between vBIOS and VBT.dat?! > > Let me give you a (free of charge) lesson: vBIOS does matter for the mode > (it will be loaded for legacy CSM mod). VBT.dat will be loaded to Linux > ALWAYS (no matter in which mode BIOS is in). Legacy vs. UEFI boot usually passes on a different VBT to the driver. > Now, you should go and educate yourself more. ;-) > > I'll wait here for what you'll find out, and as the outcome, how > you'll/INTEL fix this mess. > > _nobody_ Your snark here will not help your cause. If anything, it'll bump this bug way down on my list of things to do today.
(In reply to Oliver Weißbarth from comment #15) > Hey everyone, > > i just built the 4.13.0-rc3 kernel WITHOUT > bb1d132935c2f87cd261eb559759fe49d5e5dc43 and that's working for me. > > To verify i built the same kernel WITH > bb1d132935c2f87cd261eb559759fe49d5e5dc43 and got the same error as before. > > with kind regards > > Oliver Thanks Oliver. Moving tracking to https://bugs.freedesktop.org/show_bug.cgi?id=101745 where we deal with drm/i915 bugs. Please follow-up there.
> Your snark here will not help your cause. If anything, it'll bump this bug > way down on my list of things to do today. You see, Jani... This bug has nothing to do with me. I do not have ASUS UX305U laptop, based upon SKL-Y/U Core INTEL CPUs. Lot of owners actually are getting mad on ASUS, and, if they think much more deep, also on INTEL!? OK. Let it be. I rest this case. I see that you can handle this problem by yourself. I'll continue to observe your attempts quietly. BTW, I do not think that moving this bug to https://bugs.freedesktop.org/show_bug.cgi?id=101745 is the right approach/good idea. Well... ;-) Good Luck! _nobody_
(In reply to Oliver Weißbarth from comment #15) > i just built the 4.13.0-rc3 kernel WITHOUT > bb1d132935c2f87cd261eb559759fe49d5e5dc43 and that's working for me. I confirm home made kernel 4.12.4 with revert on commit bb1d132935c2f87cd261eb559759fe49d5e5dc43 works fine on Asus UX305UA using UEFI.
The fix is http://patchwork.freedesktop.org/patch/msgid/20170811113907.6716-1-jani.nikula@intel.com, please follow-up at the fdo bugzilla.