Network broken after resume

[Jeroen van der Ham]

After a first suspend, it takes ~60 seconds for one to be able to login. We use Dell Optiplex 7010 machines in our student lab. Because of the LDAP authentication, networking is required for authentication. So, restarting network-manager is not an option. I have tried numerous things, such as creating a file /etc/pm/config.d/network-resume with the content:
"SUSPEND_MODULE="e1000e"

However, this seems to break the suspend functionality. When manually entering "suspend" it goes directly to the lock screen.

I also tried creating a file /etc/pm/sleep.d/network-resume with:
 #!/bin/sh

case ${1} in
 resume|thaw)
 nmcli nm sleep false
  ;;
esac

Once resumed networking is disabled, and thus I cannot log in.

* creating a file in /etc/pm/sleep.d with

#!/bin/sh

case "${1}" in
        resume|thaw)
        restart network-manager
                ;;
esac

Outcome: Manually suspending works, resume only works when pressing the power button. Once resumed the networking is still disabled, and thus I cannot log in. After about a full minute networking is restored and I can log in.

---
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: lightdm 1285 F.... pulseaudio
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=UUID=5f5a9253-499b-4d0a-a0ea-903335a5222f
InstallationDate: Installed on 2014-07-08 (27 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MachineType: Dell Inc. OptiPlex 7010
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-30-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.13.0-30.55-generic 3.13.11.2
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-30-generic N/A
 linux-backports-modules-3.13.0-30-generic N/A
 linux-firmware 1.127.4
RfKill:

Tags: trusty
Uname: Linux 3.13.0-30-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True
dmi.bios.date: 03/25/2013
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A13
dmi.board.name: 0MN1TX
dmi.board.vendor: Dell Inc.
dmi.board.version: A01
dmi.chassis.type: 16
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA13:bd03/25/2013:svnDellInc.:pnOptiPlex7010:pvr01:rvnDellInc.:rn0MN1TX:rvrA01:cvnDellInc.:ct16:cvr:
dmi.product.name: OptiPlex 7010
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1352379

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Jeroen van der Ham (y-ubuntu-b)]

apport information

[Brad Figg (brad-figg)]

This change was made by a bot.

[Jeroen van der Ham (y-ubuntu-b)]

We have upgraded the BIOS of the machine:

# sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
A18
04/30/2014

We now find that after a reboot, the first suspend and resume cycle takes long: after pressing enter in the password screen it takes about 60 seconds to either log that the password is incorrect or that the system logs in.

Every subsequent suspend/resume cycle after that is just a couple of seconds.

[Jeroen van der Ham (y-ubuntu-b)]

The first time it takes 60 seconds to log in, and it seems that networking is broken during that time.

Subsequent logins take only three seconds, and also see almost no downtime in networking.

[penalvch (penalvch)]

Jeroen van der Ham, to further clarify, before the BIOS update, on resume from first suspend, networking is not working until restarted. However, after the BIOS update, on resume from first suspend, you would have to wait ~60 seconds but can ultimately log in with functional networking. Correct?

As well, would hibernating provide a WORKAROUND?

[Jeroen van der Ham (y-ubuntu-b)]

Yes, it takes roughly 60 seconds before networking is started. Hibernation would not be an option for us, the hardware is capable of resuming, and the subsequent attempts show that it should be able to do so quickly.

Attached is a log again of login, suspend, and resume cycles.

16:02:27 the machine goes out of suspend
16:03:26 sends a DHCP request
16:04:18 machine is put back into suspend
16:04:26 machine resumes
16:04:30 sends a DHCP request

There is almost a full minute between the first resume and the DHCP request being sent out. In a subsequent resume there is only 4 seconds.

The latter is the behaviour that we want consistently. I do not see why this is not possible.

[Jeroen van der Ham (y-ubuntu-b)]

Just a note, I'm not 100% certain that it was completely broken before the bios update. It could very well be that it had the same 60 second delay. Then again, that long a delay means broken in my eyes anyway. No user is going to wait that long to log back in every time his system suspends.

[penalvch (penalvch)]

Jeroen van der Ham, since you cannot confirm the issue has changed after the BIOS update, the scope of this report will change to what is confirmable, a 60 second delay in logging in after a first suspend.

Hence, could you please test the latest upstream kernel available from the very top line at the top of the page (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. 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-3.16

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.

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

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.

[Jaap van Ginkel (j-a-vanginkel)]

Hi Cristopher

As Jeroen might be less available the comming weeks I will try to debug this

I will test with the latest upstream kernel as soon as I have physical access to this type of machine

The issue affects 44 Dell 7010ś that werre bought with Ubuntu as installed OS.

As such it affects at least 44 users :-)

[Jaap van Ginkel (j-a-vanginkel)]

Upstream kernel seems to fix it, When comming back from resume there is an added glitch of the screen, but networking works right away

Kernel version tested:

Linux os3-OptiPlex-7010 3.16.0-999-generic #201408080205 SMP Fri Aug 8
06:06:19 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[penalvch (penalvch)]

Jaap van Ginkel, thank you for performing the requested test. 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 ?

[Joseph Salisbury (jsalisbury)]

Hi Jaap,

I can assist you with the reverse bisect to find the commit that fixes this. Can you first test the latest upstread 3.13 kernel to see if the fix already made it to stable? It can be downloaded from:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11.5-trusty/

[Joseph Salisbury (jsalisbury)]

Actually the 3.13.11.6 kernel is now published. It would be best to test that:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11.6-trusty/

[Launchpad Janitor (janitor)]

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