[3.16.0-23] Resume from suspend/hibernation, GPU lock - possible regression

[N1ck 7h0m4d4k15]

SRU Justification

Impact: systems resume from suspend with no graphics.

Test Case: suspend/resume (on affected hardware)

Regression Potential: all upstream changes, triggering suspend/resume handling for these devices from a safer context, regression potential is relatively low.

===

I'm testing the new development branch (Vivid Vervet), which currently has the Utopic kernel 3.16.0-23-generic installed.
(proposed repositories are enabled)

This problem might be a regression, and it has been reported

upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=81136

Problem:

When I try to resume from hibernation the screen hangs and the GPU is locked. It cannot load the graphics properly. The monitor loses its signal completely.

Testing:

Blacklisting the nouveau driver and perform the following hibernate/resume test, seems to indicate that indeed the problem is nouveau, because the test has been completed successfully:

# echo platform > /sys/power/disk
# echo devices > /sys/power/pm_test
# echo disk > /sys/power/state

Mainline:

The problem seems to be fixed in latest stable mainline kernel, for now
3.17.1-031701-generic (Utopic).

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: linux-image-3.16.0-23-generic 3.16.0-23.31 [modified: boot/vmlinuz-3.16.0-23-generic]
ProcVersionSignature: Ubuntu 3.16.0-23.31-generic 3.16.4
Uname: Linux 3.16.0-23-generic x86_64
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC3: nikos 1690 F.... pulseaudio
 /dev/snd/controlC1: nikos 1690 F.... pulseaudio
 /dev/snd/controlC2: nikos 1690 F.... pulseaudio
 /dev/snd/controlC0: nikos 1690 F.... pulseaudio
CurrentDesktop: Unity
Date: Tue Oct 28 15:24:09 2014
HibernationDevice: RESUME=UUID=f0688f3d-9938-4cb3-b79e-7c67f7593350
InstallationDate: Installed on 2014-10-24 (4 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MachineType: MSI MS-7623
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-23-generic root=UUID=170bb898-7aa9-4678-8e80-58a445647f93 ro resume=/dev/disk/by-uuid/f0688f3d-9938-4cb3-b79e-7c67f7593350
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-23-generic N/A
 linux-backports-modules-3.16.0-23-generic N/A
 linux-firmware 1.138
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/06/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: V17.9
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 880GMA-E45 (MS-7623)
dmi.board.vendor: MSI
dmi.board.version: 3.0
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: MSI
dmi.chassis.version: 3.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV17.9:bd12/06/2010:svnMSI:pnMS-7623:pvr3.0:rvnMSI:rn880GMA-E45(MS-7623):rvr3.0:cvnMSI:ct3:cvr3.0:
dmi.product.name: MS-7623
dmi.product.version: 3.0
dmi.sys.vendor: MSI

[Agustin-6 (agustin-6)]

Created attachment 102508
Logs for git kernel

After a suspend I get messages such as these:

<3>[ 39.550435] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle timeout fail
<3>[ 39.550435] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_STATUS : 0x01000001 BUSY ROP
<3>[ 39.550435] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS0: 0x00000000
<3>[ 39.550435] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS1: 0x00000000
<3>[ 39.550435] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH_VSTATUS2: 0x00200000 ROP
<3>[ 41.685486] nouveau E[ DRM] GPU lockup - switching to software fbcon

And if I was running X it crashes and the screen ends up looking like this: http://imgur.com/a/D3VKw

This is always reproducible but only since Linux 3.15, so I ran a git bisect. The first bad commit is [ecf24de071f4f6cea79ecef5d990794df5875ee1] drm/nouveau: fix fbcon not being accelerated after suspend. After reverting the commmit the machine resumes properly.

The issue persists in drm-nouveau-next (last commit 0b4e8e7... from Jul 8), even if I boot with noaccel=1 nofbaccel=1.

Relevant IRC logs: http://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&highlight_names=Nitsuga&date=2014-07-09

[Agustin-6 (agustin-6)]

Created attachment 102509
Logs for git kernel with noaccel=1 nofbaccel=1

[Agustin-6 (agustin-6)]

Created attachment 102510
Logs for Linux 3.15.4 with commit ecf24de reverted

[Dr4-bugzilla (dr4-bugzilla)]

I've experienced a similar issue when resuming from suspend-to-ram status. The screen was blank and in dmesg, I have several kernel messages from the nouveau module. I'm running Linux 3.16.0 (gentoo-sources package from Gentoo) with xorg-server 1.16.0, x11-drivers/xf86-video-nouveau-1.10.0-r1 and libdrm-2.4.54.

I will attach part of /var/log/messages with the nouveau errors.

[Dr4-bugzilla (dr4-bugzilla)]

Created attachment 104373
kernel messages during wake-up from resume

[Dr4-bugzilla (dr4-bugzilla)]

Forgot to mention my card model:

# lspci -v|fgrep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1) (prog-if 00 [VGA controller])

[Sven Joachim (svenjoac)]

Same problem here on NV86 [GeForce 8500 GT], reverting commit ecf24de071f4f6cea79ecef5d990794df5875ee1 in 3.16.0 helps.

[Agustin-6 (agustin-6)]

Update: I got tired of reverting the ecf24de commit on every linux update, so I tried booting with nouveau.nofbaccel=1 (instead of nofbaccel=1). It works fine. The system still does not resume properly without it on Linux v3.16.1, but that boot option is a better workaround than reverting.

[Freedesktop-7 (freedesktop-7)]

Same issue. Dell M4800 with QHD+ display -- NVIDIA Corporation GK106GLM [Quadro K2100M] (rev a1), 3.16.6-gentoo (I tried 3.17, that didn't even give me a usable display).

None of the workarounds were effective for me: nouveau.nofbaccel=1 causes suspend to fail, and so did reverting ecf24de071f4f6cea79ecef5d990794df5875ee1:

   A dependency job for suspend.target failed. See 'journalctl -xn' for details.
   ...
   Oct 25 15:21:16 hostname kernel: WARNING: CPU: 0 PID: 2852 at lib/iomap.c:43 bad_io_access+0x36/0x38()
   Oct 25 15:21:16 hostname kernel: Bad IO access at port 0x24 (outl(val,port))

[Agustin-6 (agustin-6)]

Another update:

I tried running with a secondary monitor. Unfortunately under that setup the nouveau.nofbaccel=1 workaround doesn't cut it anymore, and only one monitor works after resume. Trying to unplug and replug or use xrandr after this has happened doesn't make the other monitor work and once even left me with no screen. I found some new kernel messages, in particular:

<6>[ 0.336621] nouveau [ PFB][0000:01:00.0] RAM type: GDDR3
<6>[ 0.336623] nouveau [ PFB][0000:01:00.0] RAM size: 512 MiB
<3>[ 0.336620] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000007 FAULT at 0x00e180
--snip--
<6>[ 0.365519] nouveau [ DRM] VRAM: 512 MiB
<6>[ 0.365521] nouveau [ DRM] GART: 1048576 MiB
--snip--
<3>[ 0.366886] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000000 FAULT at 0x00e070
<3>[ 0.368257] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000000 FAULT at 0x00e070

right after nouveau loads, another:

<6>[ 75.935933] nouveau [ DRM] suspending console...
<6>[ 75.935944] nouveau [ DRM] suspending display...
<6>[ 75.936012] nouveau [ DRM] evicting buffers...
<6>[ 76.206568] nouveau [ DRM] waiting for kernel channels to go idle...
<6>[ 76.206573] nouveau [ DRM] suspending client object trees...
<6>[ 76.207261] nouveau [ DRM] suspending kernel object tree...
<3>[ 76.267516] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000000 FAULT at 0x00e070

immediately before suspend and:

<6>[ 78.110864] nouveau [ DRM] re-enabling device...
<6>[ 78.110870] nouveau [ DRM] resuming kernel object tree...
<6>[ 78.110882] nouveau [ VBIOS][0000:01:00.0] running init tables
<3>[ 78.200040] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000000 FAULT at 0x00e074
<6>[ 78.274292] nouveau [ VOLT][0000:01:00.0] GPU voltage: 1000000uv
<6>[ 78.274303] nouveau [ PTHERM][0000:01:00.0] fan management: automatic
<6>[ 78.274378] nouveau [ CLK][0000:01:00.0] --: core 399 MHz shader 810 MHz memory 499 MHz
<3>[ 78.275977] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000000 FAULT at 0x00e070
<3>[ 78.277301] nouveau E[ PBUS][0000:01:00.0] MMIO write of 0x00000000 FAULT at 0x00e070
<6>[ 78.277474] nouveau [ DRM] resuming client object trees...
<6>[ 78.277902] nouveau [ DRM] resuming display...

on resume. Maybe this is another bug?

So now I'm using linux-lts 3.14.22. No problems there, suspend and multi monitor setups work great.

[Emil-l-velikov (emil-l-velikov)]

Ed,
Considering that the workarounds mentioned do not work in your case and that you have a different card (reporter has nv92, while yours is gk106) we can safely conclude that you're having a different issue.
Please open another bug report and let us know if it is a regression, and if so which commit broke it.

Agustín,
These two should be non-fatal and the fix for them is in 3.18. Should end up in 3.16, 3.17 as well.
> FAULT at 0x00e070
> FAULT at 0x00e074

Now this one, I have no idea. Do you get this error with 3.14 and dual monitors ?
> FAULT at 0x00e180

Linux 3.17 includes quite a few fixes in the area of s/r, can you give it a try.

[Agustin-6 (agustin-6)]

On 3.14.22 I get no FAULTs and suspend works fine.

On linux 3.17.1 I get a FAULT at 0x00e070 and 0x00e074 on boot, suspend, resume, and when plugging the second monitor for the first time. But I can't reproduce a FAULT at 0x00e180 in any way. Checking the logs it looks like it's quite rare (it happens every twenty or so FAULTs) and unrelated to the second monitor.
If I use the nouveau.nofbaccel=1 (only) one of the monitors comes back after resume. If I don't I get the gabled display, 'GPU lockup' and PGRAPH errors as in the original post.

I'm downloading linux mainline now to test.

[Emil-l-velikov (emil-l-velikov)]

The upstream commit addressing the e07{0,4} messages (ignore the typo in the commit message) is
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/nouveau?id=b485a7005faba38286bc02ab1d80e2cbf61c1002

^^ is just in case 3.18 causes some other unwanted behaviour.

[Agustin-6 (agustin-6)]

Brilliant, Linux 3.18-rc2 resumes both monitors with nouveau.nofbaccel=1. :D

So it indeed was a different issue. The original GPU lockup bug is still there, though.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream stable kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.13 stable kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11.9-trusty/

[Joseph Salisbury (jsalisbury)]

Actually could you test the latest 3.16 upstream stable kernel, which is 3.13.6:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16.6-utopic/

The 3.13 kernel would be for Trusty, but you reported this against Utopic. Sorry for the confusion.

[N1ck 7h0m4d4k15 (nicktux)]

Unfortunately it does not work with 3.16.6 . I've tested with and without the "nouveau.nofbaccel=1" parameter, but in both cases I had the same behavior as of 3.16.4 (Ubuntu 3.16.0-23-generic).

I'm attaching the part of the log with the hibernation and resume messages.

[N1ck 7h0m4d4k15 (nicktux)]

I really cannot spot any difference in logs, but maybe it's just me.

Here is the log from the 3.17.1 kernel, where resume works as it should.

[penalvch (penalvch)]

Nik. Th. the next step is to fully reverse commit bisect the kernel in order to identify the fix commit. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ?

[N1ck 7h0m4d4k15 (nicktux)]

It seems I'm unable to narrow down the commit.

I can assure (because I have tested this twice) the last bad kernel is

3.17.0-rc7-utopic (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17-rc7-utopic/)

and the first good one

3.17.0-utopic (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17-utopic/)

I did all the steps to spot the good commit.

Here is the bisect log from git:

git bisect start
# good: [fe82dcec644244676d55a1384c958d5f67979adb] Linux 3.17-rc7
git bisect good fe82dcec644244676d55a1384c958d5f67979adb
# bad: [bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9] Linux 3.17
git bisect bad bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9
# bad: [abc40bd2eeb77eb7c2effcaf63154aad929a1d5f] mm: numa: Do not mark PTEs pte_numa when splitting huge pages
git bisect bad abc40bd2eeb77eb7c2effcaf63154aad929a1d5f
# bad: [17c9c8232663a47f074b7452b9b034efda868ca7] ematch: Fix matching of inverted containers.
git bisect bad 17c9c8232663a47f074b7452b9b034efda868ca7
# bad: [445f7f4d62628cb2971db884084d162ecb622ec7] r8152: fix the carrier off when autoresuming
git bisect bad 445f7f4d62628cb2971db884084d162ecb622ec7
# bad: [6c0fd0df0c44d1129ab65fc28d17f23a1c006a0c] qlcnic: Remove __QLCNIC_DEV_UP bit check to read TX queues statistics.
git bisect bad 6c0fd0df0c44d1129ab65fc28d17f23a1c006a0c
# bad: [4324414f8ccae4997dd1e91646683679a4436959] qlcnic: Use qlcnic_83xx_flash_read32() API instead of lockless version of the API.
git bisect bad 4324414f8ccae4997dd1e91646683679a4436959
# bad: [d61746b2e71bf612fb397b00242de5df5ba7f29a] ip_tunnel: Don't allow to add the same tunnel multiple times.
git bisect bad d61746b2e71bf612fb397b00242de5df5ba7f29a
# first bad commit: [d61746b2e71bf612fb397b00242de5df5ba7f29a] ip_tunnel: Don't allow to add the same tunnel multiple times.

Built and tested all the commits, but none of them worked.

Any ideas ?

Thanks.

[Andy Whitcroft (apw)]

git bisect looks for a commit which introduces an issue. You are trying to find a commit which _fixes_ and issue. This makes it a reverse bisect, and for "reasons" that means you have to use good and bad backwards, non-intuitive and confusing I know. In your log you seem to have correctly swapped good and bad for the initial commits but then not for the later ones?

[Joseph Salisbury (jsalisbury)]

Would you like me to assist you with the reverse bisect? I can perform the bisect and build the test kernel, which you can use to test.

[N1ck 7h0m4d4k15 (nicktux)]

@jsalisbury

thanks for offering assistance and willing to help.

I've finished the process of reverse bisecting and I have spotted some good(bad) commits.

With the **priceless** help of @apw in IRC I have learned the correct procedure of reverse bisecting (it was a real learning curve!)

Here is the new log

git bisect start
# good: [fe82dcec644244676d55a1384c958d5f67979adb] Linux 3.17-rc7
git bisect good fe82dcec644244676d55a1384c958d5f67979adb
# bad: [bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9] Linux 3.17
git bisect bad bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9
# good: [abc40bd2eeb77eb7c2effcaf63154aad929a1d5f] mm: numa: Do not mark PTEs pte_numa when splitting huge pages
git bisect good abc40bd2eeb77eb7c2effcaf63154aad929a1d5f
# good: [58586869599f6bb38aeca71a847cd77bfea74808] Merge tag 'pm+acpi-3.17-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect good 58586869599f6bb38aeca71a847cd77bfea74808
# bad: [7d1419f30cc5106196e54a282d7e115e698c95f6] Merge branch 'for-linus' of git://git.samba.org/sfrench/cifs-2.6
git bisect bad 7d1419f30cc5106196e54a282d7e115e698c95f6
# bad: [eee0815dabbdd7d584bea8275f5758d25c97cb9b] Merge tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel into drm-fixes
git bisect bad eee0815dabbdd7d584bea8275f5758d25c97cb9b
# bad: [634ffcccfbe59d77652804e1beb415d3329b1bc6] drm/nouveau: punt fbcon resume out to a workqueue
git bisect bad 634ffcccfbe59d77652804e1beb415d3329b1bc6
# bad: [f2f9a2cbaf019481feefe231f996d3602612fa99] drm/nouveau: fix regression on original nv50 board
git bisect bad f2f9a2cbaf019481feefe231f996d3602612fa99
# bad: [5838ae610ff36777b8fce6f353c2417980c1a1fa] drm/nv50/disp: fix dpms regression on certain boards
git bisect bad 5838ae610ff36777b8fce6f353c2417980c1a1fa
# first bad commit: [5838ae610ff36777b8fce6f353c2417980c1a1fa] drm/nv50/disp: fix dpms regression on certain boards

Now I have to test the commits beginning by the first bad (good) and building-installing-testing the kernel(s).

But is it possible that in a case, 2 or 3 commits combined would be needed, in order to fix a problem?

The only commits relevant with my problem, as I can understand, are 3 (drm/nouveau/fbcon /nv50 /nv50/disp).

But maybe I need to combine them all together in order to fix the resume problem, I'm not sure.

[N1ck 7h0m4d4k15 (nicktux)]

Ok, further searching showed that the commit that actually solves this problem is a merge branch 'for-linus' .

Specifically this one:

[7d1419f30cc5106196e54a282d7e115e698c95f6] Merge branch 'for-linus' of git://git.samba.org/sfrench/cifs-2.6

I will say the truth that this one tricked me a lot. I didn't look at the merge itself, but from the title and the description of the commit (samba..), I considered this as the last one possible to fix my issue.

BUT, because this is a merge it has a bunch of stuff (patches) there and some of them are directly related with the nouveau_fbcon and nouveau_drm.

We can see the relevant patches here:

https://git.samba.org/?p=sfrench/cifs-2.6.git;a=commitdiff;h=7d1419f30cc5106196e54a282d7e115e698c95f6;hp=1209bbdff2f6bbffa6eb5823033bbd7b8799a5e2

I have “cherry-picked” from the second parent, which actually holds the patches I care, and then built and tested the *real* bad kernel (3.17-rc7) and it's worked as expected.

Do you want me to *try* building an Ubuntu kernel (say the affected one - 3.16.0-23-generic) with this commit(merge) and upload into a PPA,
or is not necessary ?

[N1ck 7h0m4d4k15 (nicktux)]

After another exhausting searching and testing, and again with the **priceless** help of @apw in IRC,

I(we) may have detect the three commits which are "responsible" for the fix. Yes, probably they are three and not one, and certainly the MERGE in which I refer on the above comment #27, it cannot be merged into Ubuntu kernel or any older kernel.

The three commits I have combined(cherry-pick them together) - tested and have been worked are:

5838ae610ff36777b8fce6f353c2417980c1a1fa
f2f9a2cbaf019481feefe231f996d3602612fa99
634ffcccfbe59d77652804e1beb415d3329b1bc6

Changes are not too many (deletions, modification, additions) and they could be merged to an older Ubuntu kernel, but I'm not sure yet. I will try to cherry-pick them into ubuntu-utopic.git and try to build.

[Andy Whitcroft (apw)]

Ok I looked at backporting these three commits. To cut a long story short one of these is not needed because it is only applicable at the higher level (though needed there) and one is actually for dpms issues. This leaves the commit below:

  commit 63621dafc8e140afdfa12c8deadb41af818e455d
  Author: Ben Skeggs <email address hidden>
  Date: Wed Oct 1 11:11:25 2014 +1000

    drm/nouveau: punt fbcon resume out to a workqueue

plus a foundation commit:

  commit b6437dc0bfc8018c4c3a9e36cffdd073a4c1cf70
  Author: Ben Skeggs <email address hidden>
  Date: Sat Jun 28 20:44:07 2014 +1000

    drm/nouveau/kms: take more care when pulling down accelerated fbcon

I produced test kernels for these which @Nik.Th validated. I will submit these to kernel-team@ for review.

[Andy Whitcroft (apw)]

Patches submitted for SRU to utopic.

[Brad Figg (brad-figg)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-utopic' to 'verification-done-utopic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[N1ck 7h0m4d4k15 (nicktux)]

Sorry but I cannot confirm the fix. The latest kernel available (3.16.0-25-33) is not working. Of course the -proposed repositories are always enabled in my testing system.

I really don't know what happened, but I can assume that the latest BIOS update changed something. Yes, I have updated my BIOS (just 2 days ago) to the latest version.

As a conclusion:

1) The 3.16.0-25-33 from Ubuntu repositories is NOT working
2) This kernel here: http://people.canonical.com/~apw/lp1386695-2-utopic/ also NOT working

the only kernel that WORKS without problem is here:
3) http://people.canonical.com/~apw/lp1386695-utopic/

Sorry for the confusion, I mean that I decided to update the BIOS now - during the testing, but this would happen either way, so is better now than future, I guess.

[penalvch (penalvch)]

Nik.Th., just to advise, as per https://launchpad.net/ubuntu/+source/linux the Proposed kernel is 3.16.0-26.34 since 2014-11-25. If you have 3.16.0-25-33, then either you didn't setup the Proposed repository correctly, or you have the software pinned so that you aren't pulling down the Proposed version.

[N1ck 7h0m4d4k15 (nicktux)]

@penalvch I just got the latest Kernel (linux-image-3.16.0-26.34) but unfortunately it does not work either.

The only kernel that still works is listed in comment #33 above.

I have attached the results.

[penalvch (penalvch)]

Not Fix Released as per https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386695/comments/33 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386695/comments/36 . Hence, this bug report will not be closed as advised in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386695/comments/32 because the verification request didn't apply here.

[penalvch (penalvch)]

As per https://bugs.launchpad.net/ubuntu/vivid/+source/linux/+bug/1386695/comments/37 .

[N1ck 7h0m4d4k15 (nicktux)]

@Christopher M. Penalver

sorry, I'll let you hande the tags, it seems we edit them at the same time.
Please fix any errors.

Thanks.

[Andy Whitcroft (apw)]

For total clarity. The fixes here were not verified (as they did not fix the issue possibly after a BIOS update) and are therefore reverted in the kernel. When this closed shortly on release of the reverted kernel, that will be an error, and the bug will need reopening. We will retest against that base.

[penalvch (penalvch)]

Andy Whitcroft, thanks for your comment. As per the original reporter Nik.Th. the kernel that fixes this problem is http://people.canonical.com/~apw/lp1386695-utopic/ , both before and after the BIOS update. So, while it's unfortunate a BIOS update didn't fix this issue, it certainly didn't regress anything here. Hence, would this fix kernel contain more/less of the commits recently in Utopic Proposed?

[penalvch (penalvch)]

more/less = more or less of the intending fix commits released recently in Utopic Proposed.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.16.0-26.35

---------------
linux (3.16.0-26.35) utopic; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1398118

  [ Upstream Kernel Changes ]

  * Revert "drm/nouveau: punt fbcon resume out to a workqueue"
  * Revert "drm/nouveau/kms: take more care when pulling down accelerated
    fbcon"

linux (3.16.0-26.34) utopic; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1395892

  [ Chris J Arges ]

  * [Config] CONFIG_SCOM_DEBUGFS=y for powerpc/powerpc64-smp ppc64el/generic
    - LP: #1395855

  [ Tim Gardner ]

  * [Config] CONFIG_GENWQE_PLATFORM_ERROR_RECOVERY=1 for powerpc/ppc64el
    - LP: #1392021

  [ Upstream Kernel Changes ]

  * Revert "usb: dwc3: dwc3-omap: Disable/Enable only wrapper interrupts in
    prepare/complete"
    - LP: #1393401
  * Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate"
    - LP: #1393401
  * Revert "block: all blk-mq requests are tagged"
    - LP: #1393401
  * ACPI / blacklist: add Win8 OSI quirks for some Dell laptop models
    - LP: #1339456
  * PCI: Remove "no hotplug settings from platform" warning
    - LP: #1390182
  * drm/nouveau/kms: take more care when pulling down accelerated fbcon
    - LP: #1386695
  * drm/nouveau: punt fbcon resume out to a workqueue
    - LP: #1386695
  * drm/tilcdc: Fix the error path in tilcdc_load()
    - LP: #1393401
  * builddeb: put the dbg files into the correct directory
    - LP: #1393401
  * switch iov_iter_get_pages() to passing maximal number of pages
    - LP: #1393401
  * fuse: honour max_read and max_write in direct_io mode
    - LP: #1393401
  * usb: phy: return -ENODEV on failure of try_module_get
    - LP: #1393401
  * PM / clk: Fix crash in clocks management code if !CONFIG_PM_RUNTIME
    - LP: #1393401
  * rt2x00: support Ralink 5362.
    - LP: #1393401
  * wireless: rt2x00: add new rt2800usb devices
    - LP: #1393401
  * NFS: Fix /proc/fs/nfsfs/servers and /proc/fs/nfsfs/volumes
    - LP: #1393401
  * nfs: fix duplicate proc entries
    - LP: #1393401
  * ext4: check EA value offset when loading
    - LP: #1393401
  * jbd2: free bh when descriptor block checksum fails
    - LP: #1393401
  * ext4: don't check quota format when there are no quota files
    - LP: #1393401
  * target: Fix queue full status NULL pointer for SCF_TRANSPORT_TASK_SENSE
    - LP: #1393401
  * vfs: fix data corruption when blocksize < pagesize for mmaped data
    - LP: #1393401
  * ext4: fix mmap data corruption when blocksize < pagesize
    - LP: #1393401
  * ext4: grab missed write_count for EXT4_IOC_SWAP_BOOT
    - LP: #1393401
  * qla_target: don't delete changed nacls
    - LP: #1393401
  * target: Fix APTPL metadata handling for dynamic MappedLUNs
    - LP: #1393401
  * iser-target: Disable TX completion interrupt coalescing
    - LP: #1393401
  * ext4: don't orphan or truncate the boot loader inode
    - LP: #1393401
  * ext4: add ext4_iget_normal() which is to be used for dir tree lookups
    - LP: #1393401
  * ext4: fix reservation overflow in ext4_da_write_begin
    - LP: #1393401
  * ext4: Replace open coded mdata csum feature to helper function
    - LP: #1393401
  * ext4: move error ...

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.16.0-28.38

---------------
linux (3.16.0-28.38) utopic; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1401966

  [ Upstream Kernel Changes ]

  * net: skb_fclone_busy() needs to detect orphaned skb
    - LP: #1401079
 -- Brad Figg <email address hidden> Fri, 12 Dec 2014 08:35:42 -0800

[Agustin-6 (agustin-6)]

Fixed in Linux 3.19 :)