Bug 196233

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.