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

Bug #1265544 reported by tehownt
80
This bug affects 16 people
Affects Status Importance Assigned to Milestone
Linux
Fix Released
Medium
linux (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

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.

Revision history for this message
tehownt (tehownt) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
penalvch (penalvch)
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
tags: added: latest-bios-207 needs-upstream-testing
tags: added: regression-potential
1 comments hidden view all 118 comments
Revision history for this message
tehownt (tehownt) wrote :

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).

tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream-v3.13-rc6
removed: needs-upstream-testing
Revision history for this message
penalvch (penalvch) wrote :

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?

summary: - UX302LG black screen on boot 3.12.0-7
+ 8086:0a16 [UX302LG] black screen on boot 3.12.0-7
Revision history for this message
tehownt (tehownt) wrote :

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).

Revision history for this message
penalvch (penalvch) wrote :

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?

Revision history for this message
tehownt (tehownt) wrote :

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.

Revision history for this message
tehownt (tehownt) wrote :

>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.

penalvch (penalvch)
tags: added: raring
1 comments hidden view all 118 comments
Revision history for this message
tehownt (tehownt) wrote :

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

1 comments hidden view all 118 comments
Revision history for this message
tehownt (tehownt) wrote :

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.

Revision history for this message
penalvch (penalvch) wrote :

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

Revision history for this message
tehownt (tehownt) wrote :

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 ?

Revision history for this message
penalvch (penalvch) wrote :

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

Revision history for this message
tehownt (tehownt) wrote :

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 ?

Revision history for this message
penalvch (penalvch) wrote :

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 ?

description: updated
Revision history for this message
tehownt (tehownt) wrote :

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.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

@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.

tags: added: performing-bisect
Changed in linux (Ubuntu):
status: Incomplete → In Progress
assignee: nobody → Joseph Salisbury (jsalisbury)
Revision history for this message
Stéphane Graber (stgraber) wrote :

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.

Revision history for this message
Stéphane Graber (stgraber) wrote :

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.

Revision history for this message
tehownt (tehownt) wrote :

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.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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

Revision history for this message
tehownt (tehownt) wrote :

Thank you.

Problem still present for 3.12.0-031200 representing commit ad071acb53110c8efd26ff1e5b5d57449b43833b.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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

Revision history for this message
ouaibe (ouaibe-) wrote :

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 ?

Revision history for this message
tehownt (tehownt) wrote :

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

Revision history for this message
penalvch (penalvch) wrote :

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

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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

Revision history for this message
tehownt (tehownt) wrote :

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 !

Revision history for this message
Joel Wirāmu Pauling (aenertia) (aenertia) wrote :

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.

Revision history for this message
Joel Wirāmu Pauling (aenertia) (aenertia) wrote :

/es/ed

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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

Revision history for this message
tehownt (tehownt) wrote :

Hello,

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

Thanks for the help !

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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

Revision history for this message
tehownt (tehownt) wrote :

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.

Revision history for this message
tehownt (tehownt) wrote :

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.

Revision history for this message
Alberto Aguirre (albaguirre) wrote :

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.

tags: added: patch
Changed in linux (Ubuntu):
assignee: Joseph Salisbury (jsalisbury) → nobody
status: In Progress → Triaged
tags: added: kernel-da-key
removed: performing-bisect
Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in linux:
status: Confirmed → Incomplete
41 comments hidden view all 118 comments
Revision history for this message
In , Alberto Aguirre (albaguirre) wrote :

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

Revision history for this message
In , Jani-nikula (jani-nikula) wrote :

(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.

Revision history for this message
In , tehownt (tehownt) wrote :

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.

Revision history for this message
In , Alberto Aguirre (albaguirre) wrote :

(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.

5 comments hidden view all 118 comments
Revision history for this message
Alberto Aguirre (albaguirre) wrote :

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!

Revision history for this message
Aurélien MANCA (aurelien-manca) wrote :

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

5 comments hidden view all 118 comments
Revision history for this message
In , Jani-nikula (jani-nikula) wrote :

(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.

Revision history for this message
In , Daniel-ffwll (daniel-ffwll) wrote :

(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.

Revision history for this message
In , tehownt (tehownt) wrote :

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.

Revision history for this message
In , Jani-nikula (jani-nikula) wrote :

(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?

Revision history for this message
In , tehownt (tehownt) wrote :

(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 :)

Revision history for this message
In , Jani-nikula (jani-nikula) wrote :

(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?

Revision history for this message
In , tehownt (tehownt) wrote :

(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.

10 comments hidden view all 118 comments
Revision history for this message
Aurélien MANCA (aurelien-manca) wrote :

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

11 comments hidden view all 118 comments
Revision history for this message
In , Alberto Aguirre (albaguirre) wrote :

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.

Revision history for this message
In , tehownt (tehownt) wrote :

(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.

Revision history for this message
In , Alberto Aguirre (albaguirre) wrote :

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

Changed in linux:
status: Incomplete → Confirmed
Revision history for this message
Alberto Aguirre (albaguirre) wrote :

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.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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.

Revision history for this message
In , tehownt (tehownt) wrote :

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 ?

Revision history for this message
In , Jani-nikula (jani-nikula) wrote :

(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.

Revision history for this message
Chris Kankiewicz (phlak) wrote :

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

Revision history for this message
Marco Chiodo (marcochio94) wrote :

Any updates?

Revision history for this message
tehownt (tehownt) wrote :

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.

Revision history for this message
In , Jani-nikula (jani-nikula) wrote :

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.

Changed in linux:
status: Confirmed → Incomplete
Revision history for this message
In , Alberto Aguirre (albaguirre) wrote :

(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/

Revision history for this message
In , tehownt (tehownt) wrote :

(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.

Revision history for this message
In , tehownt (tehownt) wrote :

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.

Revision history for this message
In , Jani-nikula (jani-nikula) wrote :

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.

Changed in linux:
status: Incomplete → Fix Released
Revision history for this message
Emmanuel (eprochasson) wrote :

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

Brilliant!

Revision history for this message
Marco Chiodo (marcochio94) wrote :

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

Revision history for this message
Christofer Bäcklin (christofer-backlin) wrote :

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!

Revision history for this message
Christofer Bäcklin (christofer-backlin) wrote :

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.

Revision history for this message
Chris Kankiewicz (phlak) wrote :

Has this fix been merged into a stable kernel yet?

Revision history for this message
Ondergetekende (kvdveer) wrote :

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.

Revision history for this message
Chris Kankiewicz (phlak) wrote :

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.

Revision history for this message
Alberto Aguirre (albaguirre) wrote :

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

Revision history for this message
Justin Penka (jpenka) wrote :

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?

Revision history for this message
penalvch (penalvch) wrote :

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

tigre (tigreofearth)
Changed in linux (Ubuntu):
status: Triaged → Confirmed
status: Confirmed → Invalid
Revision history for this message
penalvch (penalvch) wrote :

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 .

Changed in linux (Ubuntu):
status: Invalid → Triaged
Displaying first 40 and last 40 comments. View all 118 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.