8086:0a16 [UX302LG] black screen on boot 3.12.0-7

[tehownt]

Same description/workaround as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1263015

I tried both Enable CSM and non-CSM boot.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.12.0-7-generic 3.12.0-7.15
ProcVersionSignature: Ubuntu 3.12.0-7.15-generic 3.12.4
Uname: Linux 3.12.0-7-generic x86_64
ApportVersion: 2.12.7-0ubuntu3
Architecture: amd64
Date: Thu Jan 2 09:59:33 2014
HibernationDevice: RESUME=UUID=e6458b44-fdb9-4db5-8cac-40ee0bbf9cf6
InstallationDate: Installed on 2013-12-31 (1 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20131231)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 004: ID 03eb:8a03 Atmel Corp.
 Bus 001 Device 003: ID 1bcf:2987 Sunplus Innovation Technology Inc.
 Bus 001 Device 002: ID 8087:07dc Intel Corp.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: ASUSTeK COMPUTER INC. UX302LG
ProcFB: 0 simple
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.12.0-7-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro recovery nomodeset
RelatedPackageVersions:
 linux-restricted-modules-3.12.0-7-generic N/A
 linux-backports-modules-3.12.0-7-generic N/A
 linux-firmware 1.117
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/30/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: UX302LG.207
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: UX302LG
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX302LG.207:bd10/30/2013:svnASUSTeKCOMPUTERINC.:pnUX302LG:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX302LG:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.name: UX302LG
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

[Brad Figg (brad-figg)]

This change was made by a bot.

[tehownt (tehownt)]

Bug present in v3.13-rc6 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc6-trusty/ (cannot use Ubuntu-bug w/ that kernel though).

[penalvch (penalvch)]

tehownt, thank you for testing the latest mainline kernel. Given we now know that the potential fix patch is still in drm-intel-next, would you happen to know which commit specifically fixes your issue?

[tehownt (tehownt)]

Christopher, no I don't.

Plus, it's important to note, the drm-intel-nightly doesn't _fix_ the issue, it's merely a slight workaround allowing the system to boot, as mentionned in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1263015 as soon as the screen goes blank, the system is lost and reboot is needed.
Also, the system comes with nvidia 730m yet installing nvidia-331 (on drm-intel-next kernel patch) makes boot fail again (might have to create a new bugreport on that though).

[penalvch (penalvch)]

tehownt, thank you for your comments. Regarding them https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1265544/comments/6 :
>"Christopher, no I don't."

Fair enough.

>"Plus, it's important to note, the drm-intel-nightly doesn't _fix_ the issue, it's merely a slight workaround allowing the system to boot, as mentionned in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1263015 as soon as the screen goes blank, the system is lost and reboot is needed."

You might be able to WORKAROUND the dimming+freeze issue by disabling screen dim in System Settings (which may have it's own systemd WORKAROUND to get these to take). I'll let you comment further to this.

>"Also, the system comes with nvidia 730m yet installing nvidia-331 (on drm-intel-next kernel patch) makes boot fail again (might have to create a new bugreport on that though)."

If you patch the default Ubuntu kernel with out of tree branches, especially an experimental testing ground like drm-intel-next, it's not supported. For more on this, please see https://wiki.ubuntu.com/Kernel/MainlineBuilds#Kernel.2BAC8-FAQ.2BAC8-DebuggingMainlineBuildsSupport.Does_the_kernel_team_support_the_mainline_kernel_builds.3F .

Also, did this issue not occur for you personally in a release prior to Trusty?

[tehownt (tehownt)]

After further investigation drm-intel-nightlies up to 2013-12-11 work but 2013-12-10 does _not_ work.

Hence issue/correcting commit has been made on 2013-12-11, but which of the 16 ones, that I don't know.

[tehownt (tehownt)]

>You might be able to WORKAROUND the dimming+freeze issue by disabling screen dim in System Settings (which may have it's own systemd WORKAROUND to get these to take). I'll let you comment further to this.

Yes, this was the easiest workaround but it forbids screen going down. So issue is persistent for that.

>If you patch the default Ubuntu kernel with out of tree branches, especially an experimental testing ground like drm-intel-next, it's not supported. For more on this, please see https://wiki.ubuntu.com/Kernel/MainlineBuilds#Kernel.2BAC8-FAQ.2BAC8-DebuggingMainlineBuildsSupport.Does_the_kernel_team_support_the_mainline_kernel_builds.3F .

I get this, I just wanted to mention it. Once the "fix" from drm-intel-next eventually gets backported, this could be looked upon.

>Also, did this issue not occur for you personally in a release prior to Trusty?

Brand new laptop, installed Trusty directly on it. Tried Saucy but had the same issue so went back to Trusty dev build.

[tehownt (tehownt)]

Using 3.2.54 under trusty, problem exist at boot, though terminal console switched to automatically.

[tehownt (tehownt)]

Laptop is UEFI only, cannot boot/install 12.04.1 since apparently UEFI support arrived in 12.04.2.
Also, there's no DVD drive in the laptop and I tried making a USB stick but 12.04.2+ images aren't recognized in the UEFI.

[penalvch (penalvch)]

tehownt, thank you for providing the requested information. Could you please test Quantal via http://releases.ubuntu.com/quantal/ and advise to the results?

[tehownt (tehownt)]

Finally found the "Enable CSM" option of the laptop that allowed to boot from pre-UEFI devices.
I was able to test 12.04.1 and 12.04.3 in Live mode only (didn't install/replace my trusty install) both using the 3.2.0.29 kernel and display was _working fine_.
Do you still require Quantal testing ?

[penalvch (penalvch)]

tehownt, thank you for your comments. Are you able to successfully boot 14.04 via "Enable CSM"?

[tehownt (tehownt)]

No, I cannot boot successfully using the 14.04 with "Enable CSM" option. For reference CSM is only a pre-UEFI compatibility option in the UEFI : http://wiki.phoenix.com/wiki/index.php/Compatibility_Support_Module and as such, it has no apparent link to the display issue the laptop has.
Do you still require Quantal testing ?

[penalvch (penalvch)]

teownt, thank you for providing the requested information. I was already aware of what CSM is, I was simply interested in if it changed anything.

Despite this, one thing that would be quite helpful is having this fully commit bisected from Precise to Trusty, in order to identify the offending commit. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

[tehownt (tehownt)]

The fix has been narrowed down to 16 commits from drm-intel-next on 2013-12-11. I might look into bisection sice it seem to be the only solution to find the problematic commit, but it's a fairly important ammount of work so I don't know when I'll do.

[Joseph Salisbury (jsalisbury)]

@tehownt

I can assist you with a reverse bisect. I'll start a bisect between those two builds and post the first test kernel shortly. The bisect should be fairly quick, since there is a small number of changes between 2013-12-10 and 2013-12-11.

[Stéphane Graber (stgraber)]

So to clarify based on IRC discussion:
 - Current trusty (3.12.0-7) gives a blank screen from the start
 - mainline drm-intel-nightly build 2013-12-10 does the same
 - mainline drm-intel-nightly build 2013-12-11 and any further one "works"

"works" here refers to the screen lighting up at boot time and the system being usable, however any further blanking or dimming of the screen will blank it for good and require a reboot.

[Stéphane Graber (stgraber)]

To add to the list above, I also had him test the current 3.13.0-0 from the kernel-team PPA, this one doesn't work either.

[tehownt (tehownt)]

Thanks for the help guys, if I'm provided with kernels for commits to test I will make sure to report what works or not.

[Joseph Salisbury (jsalisbury)]

Sorry for the delay. I was unable to find the appropriate nightly build commits in the drm-intel tree from upstream[0]. However, we should have a clone of that tree from when we built those nightly kernels. I should have a test kernel available in a bit.

These are the two commits I'll bisect between:

commit d6b9ab820e826371d6039eee826f73a32e8133e8
Author: Daniel Vetter <email address hidden>
Date: Tue Dec 10 08:19:25 2013 +0100

    drm-intel-nightly: 2013y-12m-10d-08h-19m-03s integration manifest

commit 2e66bdd944361cac615dbad623610b417dd7bca9
Author: Daniel Vetter <email address hidden>
Date: Tue Dec 10 23:31:50 2013 +0100

    drm-intel-nightly: 2013y-12m-10d-23h-31m-33s integration manifest

[0] git://people.freedesktop.org/~danvet/drm-intel

[Joseph Salisbury (jsalisbury)]

I started a kernel bisect between the 2013-12-10 and 2013-12-11 nightly builds.

I built the first test kernel, up to the following commit:
ad071acb53110c8efd26ff1e5b5d57449b43833b

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1265544

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

[tehownt (tehownt)]

Thank you.

Problem still present for 3.12.0-031200 representing commit ad071acb53110c8efd26ff1e5b5d57449b43833b.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
c461562e84d180fb691af57f93a42bd9cc7eb69c

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1265544

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

[ouaibe (ouaibe-)]

Hello and thank you.

Problem still present for 3.13.0-031300rc3 representing commit :

 c461562e84d180fb691af57f93a42bd9cc7eb69c

Quick question : this version was built on top of 3.13 whereas the previous one was named 3.12, is that on purpose ?

[tehownt (tehownt)]

Just to confirm, problem still exists in 3.13.0-031300rc3 representing commit c461562e84d180fb691af57f93a42bd9cc7eb69c.

[penalvch (penalvch)]

ouaibe, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
2a0a016addedd7a7ac489f10c89db503fadb334e

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1265544

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

[tehownt (tehownt)]

Hello,

thanks for the hard work, problem is still present in 3.13.0-031300rc2-generic_3.13.0-031300rc2.201401071301 representing commit
 2a0a016addedd7a7ac489f10c89db503fadb334e

Onto the next !

[Joel Wirāmu Pauling (aenertia) (aenertia)]

I have discusses this bug wirh Keith Packard who happens to be at lca2014 at the moment and he has adviaed to file it upstream on the freedesktop.org trac.

[Joel Wirāmu Pauling (aenertia) (aenertia)]

/es/ed

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
e9cb81a22841908b1c075156b409a538d09c8466

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1265544

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

[tehownt (tehownt)]

Hello,

problem still present for 3.13.0-031300rc3-generic_3.13.0-031300rc3.201401072105 representing commit e9cb81a22841908b1c075156b409a538d09c8466.

Thanks for the help !

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
c26fe8e5eb34c18aa9ab60fcf4c3150663a52306

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1265544

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

[tehownt (tehownt)]

Hello and thanks for the help.

IT WORKS.

I have display for the kernel 3.13.0-031300rc3-generic #201401081512 built against commit c26fe8e5eb34c18aa9ab60fcf4c3150663a52306

I will test the display dim/sleep issue and report.

Messages about driver/module error still present in Xorg.log (same as with intel-994 kernel).

[ 13.946] (EE) Failed to load module "nvidia" (module does not exist, 0)
[ 13.956] (EE) NOUVEAU(G0): Error creating GPU channel: -19
[ 13.957] (EE) NOUVEAU(G0): Error initialising acceleration. Falling back to NoAccel

I will also try to install nvidia driver stack and report.

[tehownt (tehownt)]

Screen going dim still has a wake up issue.

Also, there is some discussions on the intel-gfx ML about a commit that should have been pushed with c26fe8e5eb34c18aa9ab60fcf4c3150663a52306 but got squashed.

https://<email address hidden>/msg30489.html

So when backporting code from drm-intel-next into mainline, it might be helpful to check if another commit should be included as well...

Anyhow, thanks a lot.

[Alberto Aguirre (albaguirre)]

I have an ASUS UX302LA which is essentially the same as the UX302LG except without the NVIDIA gpu that exhibits the same issue - blank screen on boot.

I cherry-picked the commit dff392dbd258381a6c3164f38420593f2d291e3b (same patch as c26fe8e5eb34c18aa9ab60fcf4c3150663a52306) from ~danvet/drm-intel (see http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=dff392dbd258381a6c3164f38420593f2d291e3b ) on top of tag Ubuntu-3.13.0-1.16 in git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git

and rebuilt the i915 kernel module - which fixes the blank screen issue at boot; the issue of blank screen after resuming from sleep is indeed still there after this patch.

[Joseph Salisbury (jsalisbury)]

There are still two or three steps left in the reverse bisect. The following commits were applied before c26fe8e:

commit 9b33600d52fab54df1aa82ea0d70c113060c293a
commit 8771a7f80289bc08eac12c7d4f72627ff6552295
commit 1f2d45319922cdcf1f2a6f1f32f3afb206fdaaf7
commit 6806e63f48f819754f39e1f796e790b377fb6a89

It sounds like there still may be an issue per comment #39? Would you say the test kernel up to commit c26fe8e does not exhibit this bug?

[tehownt (tehownt)]

Hello,

there is still a "as soon as the screen is getting dimmed, then it doesn't light up on wake" issue, in the kernel up to commit c26fe8e.

That issue is present in the nightly drm-intel-next build though that I originally reported the bug with (2013-12-18), so it might not get fixed by backporting commits from this branch, unless it was working before and broken somewhere down the line of that branch (and this I wouldn't know). That bug might need to be opened in freedesktop directly ?

We can test other kernels as much as you want if need be though.

[Joseph Salisbury (jsalisbury)]

Ok, so that sounds like a separate bug, correct? If so, I'll update the bisect that the kernel up to commit c26fe8e is good for the specific issue this bug report addresses.

[tehownt (tehownt)]

The behaviour is exactly the same though (black screen w/ backlight on) and from the comments on the drm-intel-next commits it would seem like it's "somewhat related" eventhough it does not happen at the same time.

My very wild (and uninformed) guess would be that the code that fixed the issue at boot time would need to be compared to what's called upon wake from screen sleep/dim and probably added there too.

But this can be filed as a different bug. Do I need to make it ? With what tags ? In Launchpad ? etc.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
1f2d45319922cdcf1f2a6f1f32f3afb206fdaaf7

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1265544

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

[tehownt (tehownt)]

Thanks,

the problem is present in the latest build 3.13.0-031300rc3-generic_3.13.0-031300rc3.201401091408 representing commit 1f2d45319922cdcf1f2a6f1f32f3afb206fdaaf7 : black screen on boot.

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
9b33600d52fab54df1aa82ea0d70c113060c293a

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1265544

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

[tehownt (tehownt)]

Hello,

problem is still present in the build 3.13.0-031300rc3.201401101125 representing commit 9b33600d52fab54df1aa82ea0d70c113060c293a : black screen on boot.

Thanks.

[Joseph Salisbury (jsalisbury)]

The "Reverse" bisect confirmed the following commit is the fix for this bug:

commit c26fe8e5eb34c18aa9ab60fcf4c3150663a52306
Author: Paulo Zanoni <email address hidden>
Date: Fri Dec 6 17:32:41 2013 -0200

    drm/i915: don't touch the VDD when disabling the panel

    I don't see a reason to touch VDD when we're disabling the panel:
    since the panel is enabled, we don't need VDD. This saves a few sleep
    calls from the vdd_on and vdd_off functions at every modeset.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69693
    Reviewed-by: Rodrigo Vivi <email address hidden>
    Signed-off-by: Paulo Zanoni <email address hidden>
    Signed-off-by: Daniel Vetter <email address hidden>

I'll see if I can cherry-pick this into Trusty and build a test kernel.

[Joseph Salisbury (jsalisbury)]

I built a test kernel with a cherry pick of commit c26fe8e.

Can you give this kernel a test.

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1265544

[tehownt (tehownt)]

Hello,

thanks for the help.

The test kernel fixes the "bla[cn]k screen on boot" problem.

The test kernel does not fix the "bla[cn]k screen when waking from sleep" problem.

[Alberto Aguirre (albaguirre)]

I debugged a bit further on the waking from sleep issue - it actually also happens when changing modes through xrandr so not really related to waking from S3, just turning off/on the display.

The display in the UX302LG/LA needs to be run at 24-bit apparently - the current intel-gfx code (including in drm-intel-nightly) is clamping to 18bpp due to the BIOS advertising such info in the VBT (the same behavior is seen with CSM and nonCSM mode).

If you remove the clamping, then everything works (display up at boot, modesetting works, waking from sleep works)
 - you don't really need commit c26fe8e5eb34c18aa9ab60fcf4c3150663a52306 BTW, just removing the clamping to run the pipe at 24bpp fixes all the blank screen issues.

This behavior was noted on other laptops as described in the intel-gfx bug:
https://bugzilla.kernel.org/show_bug.cgi?id=59841

As you can see in the bug description above, the temporary solution that's been merged in 3.12 was this hack:
https://bugzilla.kernel.org/attachment.cgi?id=111321&action=diff

Not entirely sure why that is not working for the UX302LG/LA yet (in fact I don't see dp_get_config called at all for some reason, so the hack does not go into effect).

[tehownt (tehownt)]

Thanks a lot Alberto, this indeed could be it, I wonder what blocked this upstream, maybe because it's a manufacturer issue that only can get patched using a "big fat ugly hack" instead of having correct VBT...
I now understand better the use of the CSM/Non-CSM test since some laptop apparently advertise different VBT tables in both modes.
I wonder if it would be of any use (or fun) to report this to Asus and see if they come up w/ an updated UEFI :P

[Alberto Aguirre (albaguirre)]

Created attachment 91970
Test ignoring bpp clamping

I have an ASUS UX302LA laptop running Ubuntu 14.04 daily build. I've switched the kernel to the latest drm-intel-nightly from here:

    http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/)

Any sequence that turns off/on the panel (suspend/resume, modesetting) results in a blank screen.

I narrowed it down to the clamping code in intel_dp.c after going through this old bug thread (see attached patch)

   https://bugzilla.kernel.org/show_bug.cgi?id=59841

When ignoring the clamping - no blank screen issues occur.

The hack implemented in intel_dp.c:

   commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
   Author: Jani Nikula <email address hidden>
   Date: Mon Oct 21 10:52:07 2013 +0300W

       drm/i915/dp: workaround BIOS eDP bpp clamping issue

Is not effective on the UX302LA/LG - from logs it looks like intel_dp_get_config is never called - any idea why?

[Alberto Aguirre (albaguirre)]

Created attachment 91971
dmesg of latest intel-drm-nightly after boot

[Alberto Aguirre (albaguirre)]

Created attachment 91972
dmesg of latest intel-drm-nightly after boot with ignore bpp clamp patch

[Alberto Aguirre (albaguirre)]

tehownt: I submitted a ticket to ASUS support, let's see if it results in any BIOS update.

I also submitted a bug to intel-gfx:
https://bugs.freedesktop.org/show_bug.cgi?id=73567

[Alberto Aguirre (albaguirre)]

Created attachment 91975
ASUS ux302la opregion dump

[tehownt (tehownt)]

Alberto: Thanks a lot, I will do the same, hopefully, the more, the merrier.
If you have any special details that you included that were not part of your previous post, could you please send them by mail ?

Joseph: What are next steps for an eventual fix in 14.04 ?

[Daniel-ffwll (daniel-ffwll)]

We've had to duplicate the hack in the hsw code:

commit 1021442098ee9328fdd4d113d63a3a7f2f40c37b
Author: Daniel Vetter <email address hidden>
Date: Mon Nov 18 07:38:16 2013 +0100

    drm/i915: Replicate BIOS eDP bpp clamping hack for hsw

*** This bug has been marked as a duplicate of bug 71049 ***

[Gökçen Eraslan (gkcn)]

BTW, kernel 3.13rc8 must be working.

[tehownt (tehownt)]

(In reply to comment #5)
> BTW, kernel 3.13rc8 must be working.

I just tried 3.13-rc8 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc8-trusty/ and it is NOT working : blank screen on boot.

[Daniel-ffwll (daniel-ffwll)]

Strange ... Can you please attach a drm.debug=0xe dmesg from that kernel?

[Jani-nikula (jani-nikula)]

(In reply to comment #6)
> (In reply to comment #5)
> > BTW, kernel 3.13rc8 must be working.
>
> I just tried 3.13-rc8 from
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc8-trusty/ and it is
> NOT working : blank screen on boot.

Are you the original reporter of this bug? If not, do you have an *identical* machine to the reporter?

[tehownt (tehownt)]

(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > BTW, kernel 3.13rc8 must be working.
> >
> > I just tried 3.13-rc8 from
> > http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc8-trusty/ and it is
> > NOT working : blank screen on boot.
>
> Are you the original reporter of this bug? If not, do you have an
> *identical* machine to the reporter?

I'm not the original reporter of the bug, I have an identical machine : UX302LG w/ the same issue: I'm the reporter of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1265544 that helped/led to this bugreport.

[Jani-nikula (jani-nikula)]

(In reply to comment #9)
> I'm not the original reporter of the bug, I have an identical machine :
> UX302LG w/ the same issue: I'm the reporter of
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1265544 that helped/led
> to this bugreport.

Thanks for verifying this, and apologies; we just have plenty of cases where people chime in with "me too" with totally irrelevant hardware and software.

[tehownt (tehownt)]

(In reply to comment #10)
> (In reply to comment #9)
> > I'm not the original reporter of the bug, I have an identical machine :
> > UX302LG w/ the same issue: I'm the reporter of
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1265544 that helped/led
> > to this bugreport.
>
> Thanks for verifying this, and apologies; we just have plenty of cases where
> people chime in with "me too" with totally irrelevant hardware and software.

This is very understandable, no worries.
I will try to get the dmesg output log using drm.debug=0xe unless somebody does it before me.

[tehownt (tehownt)]

Created attachment 92047
dmesg of 3.13-rc8 on ux302lg with drm.debug=0xe

As requested, dmesg with debug activated using ux302LG and 3.13-rc8

[Alberto Aguirre (albaguirre)]

Daniel,

I'm already running drm-intel-nightly which includes that commit.
That particular hack does indeed run (see attached dmesg log at the beginning) but the panel is still blank. I saw the same hack at intel_dp_get_config, but in my machine intel_dp_get_config does not get called at all.

The culprit is clamping bpp from 24 to 18 bpp at intel_dp_compute_config. When the bpp clamping code is disabled and the panel runs at 24 bpp there are no more blank screen issues.

(In reply to comment #4)
> We've had to duplicate the hack in the hsw code:
>
> commit 1021442098ee9328fdd4d113d63a3a7f2f40c37b
> Author: Daniel Vetter <email address hidden>
> Date: Mon Nov 18 07:38:16 2013 +0100
>
> drm/i915: Replicate BIOS eDP bpp clamping hack for hsw
>
> *** This bug has been marked as a duplicate of bug 71049 ***

[Alberto Aguirre (albaguirre)]

(In reply to comment #5)
> BTW, kernel 3.13rc8 must be working.

With 3.13rc8 I See the same blank screen issues. Note that I'm running drm-intel-nightly already as well (dmesg log already attached at the beginning).

[Jani-nikula (jani-nikula)]

(In reply to comment #13)
> Daniel,
>
> I'm already running drm-intel-nightly which includes that commit.
> That particular hack does indeed run (see attached dmesg log at the
> beginning) but the panel is still blank. I saw the same hack at
> intel_dp_get_config, but in my machine intel_dp_get_config does not get
> called at all.
>
> The culprit is clamping bpp from 24 to 18 bpp at intel_dp_compute_config.
> When the bpp clamping code is disabled and the panel runs at 24 bpp there
> are no more blank screen issues.

Please try this on drm-intel-nightly, and report what the debug says:

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 74749c6..dbc5a16 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1491,6 +1491,10 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
                break;
        }

+ DRM_DEBUG_KMS("encoder type %d, pipe_bpp %d, vbt.edp_bpp %d, ddi ctl %08x\n",
+ encoder->type, pipe_config->pipe_bpp,
+ dev_priv->vbt.edp_bpp, temp);
+
        if (encoder->type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp_bpp &&
            pipe_config->pipe_bpp > dev_priv->vbt.edp_bpp) {
                /*

[Alberto Aguirre (albaguirre)]

It prints out:

 [drm:intel_ddi_get_config], encoder type 8, pipe_bpp 18, vbt.edp_bpp 18, ddi ctl 82210002

[Jani-nikula (jani-nikula)]

(In reply to comment #0)
> Any sequence that turns off/on the panel (suspend/resume, modesetting)
> results in a blank screen.

Wait. Does this mean it works when you first boot it?

Does 'dmesg | grep intel_ddi_get_config' give you multiple results, with possibly different output?

[Jani-nikula (jani-nikula)]

(In reply to comment #17)
> Does 'dmesg | grep intel_ddi_get_config' give you multiple results, with
> possibly different output?

*with* the patch from comment #15, if that wasn't clear.

[Alberto Aguirre (albaguirre)]

(In reply to comment #17)
> (In reply to comment #0)
> > Any sequence that turns off/on the panel (suspend/resume, modesetting)
> > results in a blank screen.
>
> Wait. Does this mean it works when you first boot it?

Yes it works when I first boot it. Which BTW, only started working on boot after this patch in december:
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=dff392dbd258381a6c3164f38420593f2d291e3b

>
> Does 'dmesg | grep intel_ddi_get_config' give you multiple results, with
> possibly different output?

With drm-intel-nightly and patch from comment #15, I get a couple of results but they all look like this:

[drm:intel_ddi_get_config], encoder type 8, pipe_bpp 18, vbt.edp_bpp 18, ddi ctl 82210002

[tehownt (tehownt)]

FWIW Asus has so far refused to provide any help, saying that they do not "support Linux". Getting a new UEFI to fix this is not looking good...

[Aurélien MANCA (aurelien-manca)]

I have an Asus UX302LG with Ubuntu 14.04 and I connected another screen to be able to wor.
Today, I installed the kernel drm-intel-nightly/2014-01-23-trusty (http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-01-23-trusty/) and it seems to work well.

[Alberto Aguirre (albaguirre)]

I just noticed the latest drm-intel-nightly (commit f27f16540be56813df2ebb8e1106dd5c258f07c3) has fixed the issue.

After bisecting, it seems the blank screen issues I was getting after modesetting or suspend/resume have been fixed starting from commit:

commit b2f19d1a1d7b262cf5fbe6033776afcf6d1ab526
Author: Paulo Zanoni <email address hidden>
Date: Thu Dec 19 14:29:44 2013 -0200

    drm/i915: set the backlight panel delays registers to 1

[penalvch (penalvch)]

Aurélien MANCA, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Jani-nikula (jani-nikula)]

(In reply to comment #21)
> I just noticed the latest drm-intel-nightly (commit
> f27f16540be56813df2ebb8e1106dd5c258f07c3) has fixed the issue.
>
> After bisecting, it seems the blank screen issues I was getting after
> modesetting or suspend/resume have been fixed starting from commit:
>
> commit b2f19d1a1d7b262cf5fbe6033776afcf6d1ab526
> Author: Paulo Zanoni <email address hidden>
> Date: Thu Dec 19 14:29:44 2013 -0200
>
> drm/i915: set the backlight panel delays registers to 1

I'm slightly surprised by this outcome. Alberto, would it be too much trouble to double check with the commit before that, and then with that commit, to make sure it's this commit that really fixes the issue for you. Thanks.

[tehownt (tehownt)]

I have to refute this:
trying to modset or suspend using intel-drm-nightly from 2014-01-26 doesn't work with my machine (UX302LG).
Though I have screen from boot using the intel-drm-nightly kernels, for me the issue still is present whatever the branch.

[Alberto Aguirre (albaguirre)]

(In reply to comment #22)
> (In reply to comment #21)
> > I just noticed the latest drm-intel-nightly (commit
> > f27f16540be56813df2ebb8e1106dd5c258f07c3) has fixed the issue.
> >
> > After bisecting, it seems the blank screen issues I was getting after
> > modesetting or suspend/resume have been fixed starting from commit:
> >
> > commit b2f19d1a1d7b262cf5fbe6033776afcf6d1ab526
> > Author: Paulo Zanoni <email address hidden>
> > Date: Thu Dec 19 14:29:44 2013 -0200
> >
> > drm/i915: set the backlight panel delays registers to 1
>
> I'm slightly surprised by this outcome. Alberto, would it be too much
> trouble to double check with the commit before that, and then with that
> commit, to make sure it's this commit that really fixes the issue for you.
> Thanks.

I just double checked again and yes with the commit before b2f19d1a1d7b262cf5fbe6033776afcf6d1ab526 - i.e this one:

commit 412b61d83a2d3e74527633097820db7510f97ce1
Author: Ville Syrjälä <email address hidden>
Date: Fri Jan 17 15:59:39 2014 +0200

    drm/i915: Fix new_config and new_enabled for load detect

suspend/resume and modesetting result in a black screen.

Using b2f19d1a1d7b262cf5fbe6033776afcf6d1ab526 there are no blank screen issues in my machine at least.

[Alberto Aguirre (albaguirre)]

Aurélien MANCA (aurelien-manca):

Can you test modesetting by doing:
sudo xrandr --output eDP1 --mode 1680x1050

And also suspend/resume

using this kernel:
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-01-23-trusty/

and also this one:
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-01-26-trusty/

Do you get a blank-screen or does it work on your machine?

If it doesn't work on your machine can you please add a comment at the intel-gfx bug here:
https://bugs.freedesktop.org/show_bug.cgi?id=73567

Thanks!

[Aurélien MANCA (aurelien-manca)]

Ok, I will send it on my next reboot.

For information, I was unable to suspend the laptop because it was awakening some seconds later.
I made it working by using the following script (/etc/pm/sleep.d/20_zenbook) :

case "${1}" in
    hibernate|suspend)
 # Unbind ehci_hcd for first device 0000:00:14.0:
        echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
        ;;
    resume|thaw)
        # Bind ehci_hcd for first device 0000:00:14.0:
        echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind
        ;;
esac

[Jani-nikula (jani-nikula)]

(In reply to comment #24)
> I just double checked again and yes with the commit before

Alberto, thanks for checking this.

(In reply to comment #23)
> I have to refute this:
> trying to modset or suspend using intel-drm-nightly from 2014-01-26 doesn't
> work with my machine (UX302LG).
> Though I have screen from boot using the intel-drm-nightly kernels, for me
> the issue still is present whatever the branch.

<email address hidden>, please try the patch from comment #15 and attach the dmesg. Thanks.

[Daniel-ffwll (daniel-ffwll)]

(In reply to comment #23)
> I have to refute this:
> trying to modset or suspend using intel-drm-nightly from 2014-01-26 doesn't
> work with my machine (UX302LG).
> Though I have screen from boot using the intel-drm-nightly kernels, for me
> the issue still is present whatever the branch.

-nightly on that day was broken for a few hours, so please also retest with a new -nightly.

[tehownt (tehownt)]

Created attachment 92927
dmesg of 2014-01-28 drm-intel-nightly on ux302LG with drm.debug=0xe

Tried with 2014-01-28 nightly and didn't work (screen on boot, blank on resume from suspend).
Output from dmesg with drm.debug=0xe added.

As for including the patch from comment #15 , I'm unfortunately not set up with a compile/build env on the machine. I can test quickly if I'm provided with a kernel that includes this patch though.

[Jani-nikula (jani-nikula)]

(In reply to comment #27)
> Tried with 2014-01-28 nightly and didn't work (screen on boot, blank on
> resume from suspend).
> Output from dmesg with drm.debug=0xe added.

Why "acpi_osi=" in kernel cmdline?

[tehownt (tehownt)]

(In reply to comment #28)
> (In reply to comment #27)
> > Tried with 2014-01-28 nightly and didn't work (screen on boot, blank on
> > resume from suspend).
> > Output from dmesg with drm.debug=0xe added.
>
> Why "acpi_osi=" in kernel cmdline?

Fixes a couple of other issues : Airplane mode key and Screen backlight control key (doesn't work otherwise, c.f. https://bugs.launchpad.net/ubuntu/+bug/1270661) Yeah, that laptop is a gift :)

[Jani-nikula (jani-nikula)]

(In reply to comment #29)
> (In reply to comment #28)
> > Why "acpi_osi=" in kernel cmdline?
>
> Fixes a couple of other issues : Airplane mode key and Screen backlight
> control key (doesn't work otherwise, c.f.
> https://bugs.launchpad.net/ubuntu/+bug/1270661) Yeah, that laptop is a gift
> :)

Did you try the newer kernels without that, wrt this bug?

[tehownt (tehownt)]

(In reply to comment #30)
> (In reply to comment #29)
>
> Did you try the newer kernels without that, wrt this bug?

Yes, 2014-01-28 drm-intel-next & 3.13.0-5 (Ubuntu) both fail.

[Aurélien MANCA (aurelien-manca)]

Alberto Aguirre :

I submitted the ticket https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1274425

With kernel 3.13.0-5.20 (Ubuntu 14.04), the command "sudo xrandr --output eDP1 --mode 1680x1050" does nothing.
With kernels drm-intel-nightly/2014-01-23-trusty and drm-intel-nightly/2014-01-29-trusty, I am able to use xrandr without any problem. For example, I have the following script on login which works perfectly :

xrandr --newmode "1600x900" 118.25 1600 1696 1856 2112 900 903 908 934 -hsync +vsync
xrandr --addmode eDP1 1600x900
xrandr --output HDMI2 --mode 1920x1080 --pos 1600x0 --rotate normal --output HDMI1 --off --output DP1 --off --output eDP1 --mode 1600x900 --pos 0x180 --rotate normal --output VIRTUAL1 --off

I'm also able to use suspend/resume which was not working with kernel 3.13.0-5.20

[Alberto Aguirre (albaguirre)]

Created attachment 93205
Patch adding quirk to avoid bpp clamping

Since we know that ignoring bpp clamping actually works (tehownt can confirm), can intel consider a quirk based patch for this laptop model as in this patch?

Thanks.

[tehownt (tehownt)]

(In reply to comment #32)
> Created attachment 93205 [details] [review]
> Patch adding quirk to avoid bpp clamping
>
> Since we know that ignoring bpp clamping actually works (tehownt can
> confirm), can intel consider a quirk based patch for this laptop model as in
> this patch?
>
> Thanks.

I can confirm that using custom i915.ko based on this patch under 3.13.0-5 fixes the issue, screen on boot & screen on resume work fine and stable.

[Alberto Aguirre (albaguirre)]

So what can we do to move forward? Any thoughts on the quirk based solution I posted earlier?

[Alberto Aguirre (albaguirre)]

Here's a patch that works on top the current ubuntu kernel (Ubuntu-3.13.0-8.28).

Can this be integrated in the ubuntu kernel? It's quirk based, so it will only effect this laptop model.

[Joseph Salisbury (jsalisbury)]

Can you provide some information on the status of the patch with regards to getting it merged upstream? Has it been sent upstream, what sort of feedback has it received, is it getting applied to a subsystem maintainer's tree, etc?

People affected by this bug are probably wondering why the kernel team doesn't just apply the patch and fix it. The reason is that the kernel team is reluctant (not opposed) to apply any patch to a stable kernel that is not from upstream. Applying patches that don't come from upstream add greatly to the support of the kernel as other upstream patches may touch the same area as the non-upstream patch and may prevent them from applying cleanly.

To submit your patch, send your patch with the detailed description/changelog and your Signoff (ending with Signed-off-by: your name <email>), to the emails listed from ./scripts/get_maintainer.pl drivers/SUBSYSTEM-DETAILS (the get_maintainer.pl is from the kernel sources). Once you have sent the patch upstream and it's accepted, please drop a note here so that we can cherry-pick/include the patch into Ubuntu kernel.

[tehownt (tehownt)]

I notice that the bug hasn't been updated in a while, a patch that fixes the issue exists and can be integrated in the same way as bug 71049 (quirk-based bpp clamping bypass).
Can this patch be reviewed & integrated so that we can consider the issue fixed with this laptop and move on ?

[Jani-nikula (jani-nikula)]

(In reply to comment #35)
> I notice that the bug hasn't been updated in a while, a patch that fixes the
> issue exists and can be integrated in the same way as bug 71049 (quirk-based
> bpp clamping bypass).

The fix for bug 71049 is specifically *not* quirk based.

> Can this patch be reviewed & integrated so that we can consider the issue
> fixed with this laptop and move on ?

Adding quirks instead of finding the root cause is problematic in a few ways.

Only the users of a specific laptop can "move on". There will be others, and there will be no end to it. It's not likely that only a very specific machine would suffer from this. We wouldn't be able to move on.

Working around this on a quirk by quirk basis as the bug reports slowly come in, from a very select group of people, for a very limited selection of machines, is actually counterproductive to making the driver work properly for everybody.

With the quirks in, it's also quite hard to revert those and try to switch to a real fix when one is found. The quirked machines must not regress, but at the same time it's difficult to get testing feedback from the original reporters.

Thanks for your understanding and patience.

[Chris Kankiewicz (phlak)]

Has there been any update to this issue recenlty? I jut got a UX302LA and have this same issue.

[Marco Chiodo (marcochio94)]

Any updates?

[tehownt (tehownt)]

No updates since last reply in the freedesktop bugzilla : https://bugs.freedesktop.org/show_bug.cgi?id=73567 from 02-24-2014, if you have something more to add to the bugreport, please do.

[Jani-nikula (jani-nikula)]

We've merged a number of patches that might affect this since the last comments. Please try recent drm-intel-nightly branch and report back. Thanks.

[Alberto Aguirre (albaguirre)]

(In reply to comment #37)
> We've merged a number of patches that might affect this since the last
> comments. Please try recent drm-intel-nightly branch and report back. Thanks.

No blank screen issues in my UX302LA either at boot, or when mode setting or when suspend/resuming.

Tested via:
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-04-11-trusty/

[tehownt (tehownt)]

(In reply to comment #38)
> (In reply to comment #37)
> > We've merged a number of patches that might affect this since the last
> > comments. Please try recent drm-intel-nightly branch and report back. Thanks.
>
> No blank screen issues in my UX302LA either at boot, or when mode setting or
> when suspend/resuming.
>
> Tested via:
> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-04-11-
> trusty/

Will test & report for UX302LG asap.

[tehownt (tehownt)]

Created attachment 97254
kernel 20140411 dmesg w/ drm.debug=0xe

Hello,

so far it works on the UX302LG, i've attached the dmesg with drm.debug=0xe enabled, I see the screen flashing black after grub but it works thereafter.

[Jani-nikula (jani-nikula)]

So one or some of our fixes has indeed fixed the bug. If anyone wants to reverse bisect from broken to first good, we'd be able to identify and backport the fix(es) to stable kernels.

[Emmanuel (eprochasson)]

Confirmed: works for me as well (UX302LG). Boot is alright and suspend to RAM can now normally resume (screen comes back to life).

Brilliant!

[Marco Chiodo (marcochio94)]

How can I get the intel driver patch alone for testing and helping with backport?

[Christofer Bäcklin (christofer-backlin)]

Could anyone help me understand how to install the bug fix? Should I first install the regular Ubuntu 14.04 LTS and then a patch or should I install an alternative kernel branch (called "drm-intel-nightly"?) from scratch?

Sorry for being such a newbie, any pointers would be much appreciated!

[Christofer Bäcklin (christofer-backlin)]

I got it working, here's what I did:

1. Booted the Ubuntu 14.04 LTS live USB by setting the nomodeset option from the launch menu: Place the cursor over the "try ubuntu" option, press the "e" key, add "nomodeset" after "quite splash", and press F10 to boot.

2. Installed Ubuntu.

3. Booted Ubuntu from disk by again setting the nomodeset option from the launch menu: press Esc during boot, select the right option, press "e" and proceed as in step 1.

4. Download the nightly kernel "linux-image-...-generic-...-amd64.deb" from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-04-24-trusty/. If the link doesn't work go to the parent directory and select the most recent date.

5. Install kernel from software center.

[Chris Kankiewicz (phlak)]

Has this fix been merged into a stable kernel yet?

[Ondergetekende (kvdveer)]

I've just successfully booted my new zenbook with this mainline kernel.

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-utopic/

This suggests this fix (or a fix anyway) has been merged into the stable kernel.
The default 14.04 kernel is still broken, though.

[Chris Kankiewicz (phlak)]

I can confirm waht Ondergetekende said, the 3.15 kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-utopic/ boots (even seems to boot faster) on my UX302LA.

[Alberto Aguirre (albaguirre)]

Yep I confirm with utopic (14.10) and kernel 3.15.0-6-generic it boots and suspend/resumes fine.

[Justin Penka (jpenka)]

I have tried running the 3.15 utopic kernel with 14.04. The system boots up fine, however, i'm still getting the black screen on grub. The only option I added was 'nomodeset'. Is anyone else experiencing this, or did you all move 14.10?

[penalvch (penalvch)]

Justin Penka, thank you for your comment. Unfortunately, this bug report is not scoped to you, or your problem. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into the default Ubuntu kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

As well, please do not announce in this report you created a new bug report.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[penalvch (penalvch)]

tigre, please do not adjust the Status of this report, especially without a justifying comment. For more on Status please see https://wiki.ubuntu.com/Bugs/Status .