[Dell Latitude E6410] Becomes unresponsive after suspending/resuming several times

[Daniel Manrique]

How to reproduce:

- Install fwts
- Run sudo fwts s3 --s3-multiple=50 -r output.log

Expected result:
- System suspends and resumes 50 times
- At the end of the 50 repetitions, system is responsive and usable.

Actual result:
- System fails after a random number of iterations; either it ends up on a dark screen, or a corrupted desktop (it's visible but nothing responds and rebooting is the only way to restore things).

I tried this twice to collect data to report this bug: the first time it failed after 34 iterations, the second time it failed after only 6 iterations. I also tried this twice before (no logs from those attempts), but in both cases it failed after less than 30 iterations.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-23-generic 3.2.0-23.36
ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
Uname: Linux 3.2.0-23-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 2.0.1-0ubuntu5
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: ubuntu 1730 F.... pulseaudio
 /dev/snd/controlC0: ubuntu 1730 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xd9660000 irq 45'
   Mixer name : 'IDT 92HD81B1C5'
   Components : 'HDA:111d76d5,1028040a,00100104 HDA:14f12c06,14f1000f,00100000'
   Controls : 19
   Simple ctrls : 10
Card1.Amixer.info:
 Card hw:1 'NVidia'/'HDA NVidia at 0xd3080000 irq 16'
   Mixer name : 'Nvidia GPU 0b HDMI/DP'
   Components : 'HDA:10de000b,10de0101,00100100'
   Controls : 24
   Simple ctrls : 4
CurrentDmesg:
 [ 44.989478] audit_printk_skb: 21 callbacks suppressed
 [ 44.989484] type=1400 audit(1339603083.152:27): apparmor="DENIED" operation="open" parent=1 profile="/usr/lib/telepathy/mission-control-5" name="/usr/share/gvfs/remote-volume-monitors/" pid=2110 comm="mission-control" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Date: Wed Jun 13 12:04:46 2012
HibernationDevice: RESUME=UUID=b2ec0370-661b-436c-b8b9-711507380f5c
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
MachineType: Dell Inc. Latitude E6410
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic root=UUID=db073b07-6e29-4c98-b852-8721687df43f ro quiet splash initcall_debug vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-23-generic N/A
 linux-backports-modules-3.2.0-23-generic N/A
 linux-firmware 1.79
SourcePackage: linux
StagingDrivers: mei
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/30/2010
dmi.bios.vendor: Dell Inc.
dmi.bios.version: X51
dmi.board.name: RAMDEL
dmi.board.vendor: Dell Inc.
dmi.board.version: 0001
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrX51:bd01/30/2010:svnDellInc.:pnLatitudeE6410:pvr0001:rvnDellInc.:rnRAMDEL:rvr0001:cvnDellInc.:ct9:cvr:
dmi.product.name: Latitude E6410
dmi.product.version: 0001
dmi.sys.vendor: Dell Inc.

[Daniel Manrique (roadmr)]

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Daniel Manrique (roadmr)]

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.5kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

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] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-rc2-quantal/

[Joseph Salisbury (jsalisbury)]

Also, there is a newer version of the kernel than the one you tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not. You can upgrade just your kernel by running the following in a terminal:

sudo apt-get update
sudo apt-get install linux

[Daniel Manrique (roadmr)]

OK, so I tried with 3.5.0-rc2 from the mainline kernels, and this one was able to suspend/resume 50 times without problems. I tried twice, so in all I did 100 suspend/resume cycles without any failures.

I'm now upgrading to the latest 3.2-series kernel (from Precise) and will update as soon as I run the tests.

[Joseph Salisbury (jsalisbury)]

Thanks for the update, Daniel. If you have time, we can perform a reverse bisect with this bug as well. I look forward to hearing about the latest Precise kernel.

[Daniel Manrique (roadmr)]

Hi Joseph,

I did a full dist-upgrade and the latest Precise 3.2.0-25.40 kernel is also not very stable; I tried twice and it froze after 6 cycles. The 3.5 kernel, however, seems very stable, I completed two more 50-cycle tests with no problems.

We can certainly do a bisect (thanks for the offer and for your patience; all I do is run the tests). This one will be a bit more time-consuming as the test does take a while. Moreover, we'd have to agree on how many iterations the system should pass for us to consider the kernel good. I'd go for either 50 or 100.

Let me know.

Thanks!

[Joseph Salisbury (jsalisbury)]

Can you test the following upstream kernels to start:

v3.3 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-precise/
v3.4 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-quantal/

[Daniel Manrique (roadmr)]

Hi Joseph,

I tried both kernels you mentioned, with this command:

sudo fwts s3 --s3-multiple=100 -r some-file-to-output-results.log

Both 3.3 and 3.4 were able to suspend/resume 100 times (I think it's a reasonable number, much higher than anything we've tried, so if it manages to complete those 100 iterations we should be fairly confident it's working OK).

So the "stabilizing" changes seem to have happened after 3.2 and before 3.3.

[Joseph Salisbury (jsalisbury)]

Thanks for testing, Daniel.

Can you try testing some of the v3.3 release candidates? For example:

v3.3-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc1-precise/
v3.3-rc2: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc2-precise/
...

That way we can find where to start bisecting. All of the release candidates can be found at:
http://kernel.ubuntu.com/~kernel-ppa/mainline/

[Daniel Manrique (roadmr)]

hi Joseph,

Sorry for the delay in testing this, kernel 3.3-rc5 took me about 3 days to test. Here are the results.

I did a poor man's bisect and found that the last kernel that is able to suspend/resume 100 times is, indeed, 3.3-rc5.

3.3-rc6 crashed after one or, at most, two suspend/resume attempts.

Now, 3.3-rc5 had some very strange behaviors. Somehow it didn't respond to the wakealarm at first, thus needing me to wait until it was suspended, then press the power button manually... 86 times. Strangely, after the 87th iteration, it *started* honoring the wakealarm and completed the last few cycles on its own.

After 100 resume cycles, it's up and running perfectly.

During the testing, it experienced one kernel Oops but managed to recover from it and resume correctly.

So despite the strange behavior, I'd have to say 3.3-rc5 is the last known good kernel, while 3.3-rc6 is the first bad one.

Thanks!

[Joseph Salisbury (jsalisbury)]

Hi Daniel,

This bug was originally reported against v3.2(Precise). So I think we were looking for the first upstream kernel that did not have this bug.

Comment #11 suggests that v3.3 final did not have this bug. Did you mean in comment #13 that 3.3-rc5 did have this bug and v3.3-rc6 did not have this bug?

[Daniel Manrique (roadmr)]

Hi Joseph,

Yes, you're right, I did things backwards/strangely. 3.3 is supposed to work well, while 3.2 fails. I'll have to look at my notes (a post-it note on the system) to see what went wrong.

 I'll retest tomorrow (won't have access to the system until then) and update this again. Sorry!

[Daniel Manrique (roadmr)]

OK, so I rechecked and yes, 3.3 is confirmed good. 3.2 was originally reported as bad, I'm retesting that one to be 200% sure that our start/end points are OK.

3.3-rc4 and rc5 tested as good, *but* 3.3-rc6 was BAD, and I tested several times. So it looks like I'll have to test rc7 as well, just to make sure rc6 is/was a "fluke" of some sort. If so, then the first good kernel would be either rc1, rc2 or rc3.

I'll update with results for all 3.3-rc* kernels when I get them (about 2 hours for each one, heh).

[Daniel Manrique (roadmr)]

Hi Joseph,

It took a bit to update because I tested all the kernels between 3.2 and 3.3, I got some very interesting results:

3.2 - Bad (as reported originally)
3.3-rc1 - Bad (fails after 1 cycle, did 2 tries)
3.3-rc2 - Good (failed on the first try after 8 cycles, it completed 100 cycles on the second try)
3.3-rc3- Good (100 cycles)
3.3-rc4- Good (100 cycles)
3.3-rc5 - Good (100 cycles)
3.3-rc6 - Bad (Tested 3 times, failed after 1 or 2 cycles)
3.3-rc7 - Good (100 iterations)
3.3 - Good (as reported originally)

So I'd say things are failing *until* 3.3-rc1 and they were fixed in 3.3-rc2. The odd result is that for 3.3-rc6. I tried several times so I'm pretty confident about the result. However, there's a 'Good' trend starting with 3.3-rc2 that only breaks briefly with 3.3-rc6, so I think the trend change from 3.3-rc1 to 3.3-rc2 is what we should look at.

Let me know if you agree and where/how to proceed from here.

Thanks!

[Joseph Salisbury (jsalisbury)]

Before we bisect, can you test the latest upstream 3.2 stable kernel? It can be downloaded from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2.22-precise/

[Daniel Manrique (roadmr)]

Hi Joseph,

Sorry it took me so long to run the tests, I got some strange results so I wanted to double-check. Long story short: 3.2.22-precise is more unstable than not, I'm inclined to consider this bad, although this is inconsistent with what we did with 3.3-rc2 which had the same behavior in the first two test runs.

Long story: I ran the test three times:
1- FAIL, crashed after 39 iterations.
2- PASS, completed all 100 iterations successfully.
2- FAIL, crashed after 12 iterations (ran this to get a best/worst two out of three).

So out of three attempts, it failed two of them, thus looking somewhat bad to me.

[Joseph Salisbury (jsalisbury)]

I started a "Reverse" bisect between v3.3-rc1 and v3.3-rc2. The first test kernel is up to comit:
84e83c2846ffb42772056a0f825d8578dc92d586

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1012740

Can you test that kernel and report back if it has the bug or not?

Thanks in advance!

[Daniel Manrique (roadmr)]

Hi Joseph,

The first test kernel works well, it was able to suspend/resume 100 times on the first try.

Kernel version is:

Linux 201001-5167 3.3.0-030300rc1-generic #201207191954 SMP Thu Jul 19 18:56:53 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, which is up to commit:
701b259f446be2f3625fb852bceb93afe76e206d

This kernel is available from:
http://people.canonical.com/~jsalisbury/lp1012740/

Can you test that kernel and report back if it has the bug or not?

[Daniel Manrique (roadmr)]

Hi Joseph,

The second test kernel does NOT work well , it was unable to suspend/resume correctly, I tried twice and both attempts failed on the first suspend cycle.

Kernel version is:

Hi Joseph,

Linux 201001-5167 3.3.0-030300rc1-generic #201207202127 SMP Fri Jul 20 20:30:36 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, which is up to commit:
486bc794abfdc10fcb417fbb0b781b46e1e70aef

This kernel is available from:
http://people.canonical.com/~jsalisbury/lp1012740/

Can you test that kernel and report back if it has the bug or not?

[Daniel Manrique (roadmr)]

Hi Joseph,

The latest test kernel does NOT work well, I tested it twice and it failed to resume from even the first iteration.

Version string is:

Linux 201001-5167 3.3.0-030300rc1-generic #201208101927 SMP Fri Aug 10 18:28:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, which is up to commit:
2437dcbf555bff04e4ee8b8dba4587f946c1cd3d

This kernel is available from:
http://people.canonical.com/~jsalisbury/lp1012740/

Can you test that kernel and report back if it has the bug or not?

[Daniel Manrique (roadmr)]

Hi Joseph!

The latest test kernel seems to work well. I did three test runs.

The first one kernel-panicked after 12 iterations.
The second and third ones completed 100 iterations without any problems.

So two out of three seems to indicate it's working.

Version string is: Linux 201001-5167 3.3.0-030300rc1-generic #201208142052 SMP Tue Aug 14 19:54:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Thanks!

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, which is up to commit:
74a7f6a0a61f1f5addd0afa789785f4cefcfcafc

This kernel is available from:
http://people.canonical.com/~jsalisbury/lp1012740/

Can you test that kernel and report back if it has the bug or not?

[Daniel Manrique (roadmr)]

HI Joseph,

The latest test kernel is NOT working well, it very nicely kernel-panics, did so after 12 cycles on the first try, and after 8 on the second.

Version string is:

Linux 201001-5167 3.3.0-030300rc1-generic #201208201536 SMP Mon Aug 20 14:40:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Thanks!

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, which is up to commit:
0dbfe8ddaaab9fe5bc8672c064d3ede6cd66201a

This kernel is available from:
http://people.canonical.com/~jsalisbury/lp1012740/

Can you test that kernel and report back if it has the bug or not?

[Daniel Manrique (roadmr)]

Hi Joseph,

Latest test kernel is NOT working well, it's better than the previous one but still didn't complete 100 iterations. Two attempts crashed with kernel panic; first attempt after 56 cycles, second after 23 cycles.

Version string is:

Linux 201001-5167 3.3.0-030300rc1-generic #201208212013 SMP Tue Aug 21 19:15:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, which is up to commit:
7061ca3b6c99fc78115560b9a10227c8c5fafc45

This kernel is available from:
http://people.canonical.com/~jsalisbury/lp1012740/

Can you test that kernel and report back if it has the bug or not?

[Daniel Manrique (roadmr)]

Hi Joseph,

The latest test kernel was also unable to complete the 100 suspend/resume iterations. I tried twice, it failed after 2 cycles on both attempts.

Kernel string is this:

Linux kernel x86 boot executable bzImage, version 3.2.0-030200-generic (jsalisbury@tangerine) #201208221845 SMP W, RO-rootFS, swap_dev 0x4, Normal VGA

Thanks!

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, which is up to commit:
5d53cb27d849c899136c048ec84c940ac449494b

This kernel is available from:
http://people.canonical.com/~jsalisbury/lp1012740/

Can you test that kernel and report back if it has the bug or not?

[Daniel Manrique (roadmr)]

Hi Joseph,

Latest test kernel is again NOT working well. I ran the test twice, both times it failed on the second iteration.

Kernel version is:

Linux 201001-5167 3.2.0-030200-generic #201208281435 SMP Tue Aug 28 13:38:28 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, which is up to commit:
b64b223aed5f8aeeb6c046f1b050a8f976b87de0

This kernel is available from:
http://people.canonical.com/~jsalisbury/lp1012740/

Can you test that kernel and report back if it has the bug or not?

[Daniel Manrique (roadmr)]

Hi Joseph,

Sorry for the delay. Latest test kernel is again NOT working well. I ran the test twice, both times it failed on the second iteration. Actually it behaved just as the last one (from comment #35).

Kernel version is:
Linux 201001-5167 3.2.0-030200-generic #201208291701 SMP Wed Aug 29 16:04:13 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[Joseph Salisbury (jsalisbury)]

The revers bisect points to the following commit as the fix in v3.6-rc2:
2437dcbf555bff04e4ee8b8dba4587f946c1cd3d

However, that is a merge from Linus:
Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

I built the next test kernel up to commit 2437dcbf555bff04e4ee8b8dba4587f946c1cd3d, so I assume this kernel should not exhibit the bug.

This kernel is available from:
http://people.canonical.com/~jsalisbury/lp1012740/

Can you test that kernel and report back if it has the bug or not?

[Daniel Manrique (roadmr)]

Hi Joseph,

The latest test kernel DOES work correctly, it completed 100 suspend/resume iterations without problems.

Version number is this:

Linux 201001-5167 3.3.0-030300rc1-generic #201209252148 SMP Tue Sep 25 20:50:33 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Let me know what's next. Do we have to go deep into that branch?

Thanks!

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, which is up to commit:
7061ca3b6c99fc78115560b9a10227c8c5fafc45

This commit is part of the merge branch(Commit 2437dcbf). There should only be 3 or so kernels to test in the merge.

This kernel is available from:
http://people.canonical.com/~jsalisbury/lp1012740/

Can you test that kernel and report back if it has the bug or not?

[Daniel Manrique (roadmr)]

Hi Joseph!

Tested the latest kernel and it does NOT work, I tried twice and both attempts failed on the second iteration.

Kernel version is:

Linux 201001-5167 3.2.0-030200-generic #201210011927 SMP Mon Oct 1 18:30:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[Joseph Salisbury (jsalisbury)]

Do you think using the LTS backports kernel might be an acceptable solution for this bug? If so, it might be worth a test. If it is not a good solution, we might have to look at all the bisect steps again to confirm they are all correct.

[Daniel Manrique (roadmr)]

Hi Joseph,

Our initial thought was that the backported kernel would be a reasonable fix for this. However, unfortunately, I have tested 12.04.2 with the 3.5.0-23 kernel, and it's still unable to suspend/resume reliably.

After 2-3 cycles, the system seems to "log out": I get a very garbled lightdm login prompt, but the garbling is so bad that I have to reboot the system. Upon examining the suspend/resume logfile I notice that at most it completed 3 cycles. I tried this several times, always with similar results

I'm not sure what changed between the mainline kernels we tested and this one.

The kernel I'm using is:

Linux 201001-5167 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu Precise) because there has been no activity for 60 days.]

[penalvch (penalvch)]

Daniel Manrique, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]