In 14.04.04, r8169.ko cannot recover wired Ethernet connection after resume from suspend

[Richard Elkins]

Whenever my laptop suspends (desirable) and then resumes, the r8169 module cannot reconnect the wired Ethernet line. This is consistent. I can see network_manager trying over and over to get a reconnection.

WORKAROUND: After resume:
sudo rmmod r8169
sudo insmod /lib/modules/`uname --kernel-release`/kernel/drivers/net/ethernet/realtek/r8169.ko

---
ApportVersion: 2.14.1-0ubuntu3.19
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: elkins 1902 F.... pulseaudio
 /dev/snd/controlC0: elkins 1902 F.... pulseaudio
CurrentDesktop: XFCE
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=UUID=869e6cc9-952c-4e2a-9714-d8412bbc6dd1
InstallationDate: Installed on 2016-02-21 (27 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
MachineType: Hewlett-Packard HP Pavilion dv3 Notebook PC
NonfreeKernelModules: wl
Package: linux (not installed)
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-83-generic root=UUID=2a7c05c7-3728-4f32-aac3-9dbd721a4fa0 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.13.0-83.127-generic 3.13.11-ckt35
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-83-generic N/A
 linux-backports-modules-3.13.0-83-generic N/A
 linux-firmware 1.127.20
Tags: trusty
Uname: Linux 3.13.0-83-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 08/25/2009
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: F.15
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 1506
dmi.board.vendor: Compal
dmi.board.version: 14.31
dmi.chassis.type: 10
dmi.chassis.vendor: Compal
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnHewlett-Packard:bvrF.15:bd08/25/2009:svnHewlett-Packard:pnHPPaviliondv3NotebookPC:pvr1:rvnCompal:rn1506:rvr14.31:cvnCompal:ct10:cvrN/A:
dmi.product.name: HP Pavilion dv3 Notebook PC
dmi.product.version: 1
dmi.sys.vendor: Hewlett-Packard

[Richard Elkins (texadactyl)]

Probably the same as #1498692 but a different release.

[Richard Elkins (texadactyl)]

Automated work-around for 14.04.x:

Put the following shell script in /etc/pm/sleep.d:

#!/bin/sh
# ===> /etc/pm/sleep.d

MYNAME=$0

restart_ethernet() {
   /usr/bin/logger $MYNAME 'restart_ethernet(r8169) BEGIN'
   /sbin/modprobe -v -r r8169
   /sbin/modprobe -v r8169
   /usr/bin/logger $MYNAME 'restart_ethernet(r8169) END'
}

/usr/bin/logger $MYNAME 'case=[' ${1} ']'
case "${1}" in
   hibernate|suspend) ;;
   resume|thaw) restart_ethernet;;
esac

[penalvch (penalvch)]

Richard Elkins, thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:
apport-collect 1556676

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

apport information

[Richard Elkins (texadactyl)]

Christopher,

I always use `ubuntu-bug` to create a report. However, until I saw your mail, I did not have the python-apport package installed. Maybe, since it is not very big, it should always be installed as part of *buntu base in case it is needed.

Please let me know if anything else is needed. I do not mind unusual requests if needed.

[penalvch (penalvch)]

Richard Elkins, in order to allow additional upstream developers to examine the issue, at your earliest convenience, could you please test the latest upstream kernel available from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D ? Please keep in mind the following:
1) The one to test is at the very top line at the top of the page (not the daily folder).
2) The release names are irrelevant.
3) The folder time stamps aren't indicative of when the kernel actually was released upstream.
4) Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds .

If testing on your main install would be inconvenient, one may:
1) Install Ubuntu to a different partition and then test this there.
2) Backup, or clone the primary install.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, and Y are the first two numbers of the kernel version, and Z is the release candidate number if it exists.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Also, you don't need to apport-collect further unless specifically requested to do so.

Once testing of the latest upstream kernel is complete, please mark this report Status Confirmed. Please let us know your results.

Thank you for your understanding.

[Richard Elkins (texadactyl)]

Successfully installed 4.4.6.
Symptom of this report exists in the 4.4.6 kernel.

[Richard Elkins (texadactyl)]

In my previous attempt with 4.5, I downloaded the wrong header file. I should have grabbed the "all" one.

Successfully installed 4.5.
Symptom of this report exists in the 4.5 kernel.

[penalvch (penalvch)]

Richard Elkins, the issue you are reporting is an upstream one. Could you please report this problem following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel to the appropriate mailing list (TO Realtek linux nic maintainers CC netdev)?

Please provide a direct URL to your post to the mailing list when it becomes available so that it may be tracked.

Thank you for your understanding.

[Richard Elkins (texadactyl)]

Please note that if a build has an issue installing 100%, then the reporter should not proceed with a test.

I thought that I observed a totally successful install of the 4.5 kernel image and headers yesterday but I missed seeing that the make of bcmwl failed to make even though the installation was successful according to the final state of the repository:

ii linux-headers-4.5.0-040500 4.5.0-040500.20160314013 all Header files related to Linux kernel version 4.5.0
ii linux-headers-4.5.0-040500-generic 4.5.0-040500.20160314013 amd64 Linux kernel headers for version 4.5.0 on 64 bit x86 SMP
ii linux-image-4.5.0-040500-generic 4.5.0-040500.20160314013 amd64 Linux kernel image for version 4.5.0 on 64 bit x86 SMP

Logs are attached in a tar.gz file. Specifically, gcc version 4:4.8.2-1ubuntu6 (up-to-date for 14.04.04) flagged the make of bcmwl as follows:

make: Entering directory `/usr/src/linux-headers-4.5.0-040500-generic'
Makefile:666: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
CFG80211 API is prefered for this kernel version
Using CFG80211 API
  LD /var/lib/dkms/bcmwl/6.30.223.248+bdcom/build/built-in.o
  CC [M] /var/lib/dkms/bcmwl/6.30.223.248+bdcom/build/src/shared/linux_osl.o
gcc: error: unrecognized command line option ‘-fstack-protector-strong’
make[1]: *** [/var/lib/dkms/bcmwl/6.30.223.248+bdcom/build/src/shared/linux_osl.o] Error 1
make: *** [_module_/var/lib/dkms/bcmwl/6.30.223.248+bdcom/build] Error 2
make: Leaving directory `/usr/src/linux-headers-4.5.0-040500-generic'

It looks like I would need (at least) an upstream `gcc` to match this kernel. Who knows what else? This might be like peeling an onion.

Keep in mind that my work-around described above is solid. Being a developer, I understand that the kernel developers need to prioritize their time and effort. If the kernel development team would be more comfortable with my retesting under 16.04 (would make sense!), then I can wait until this machine is available for an upgrade in, roughly, one month.

[Richard Elkins (texadactyl)]

I just noticed that this failed make was for the "Broadcom 802.11 Linux STA wireless driver source" (bcmwl). So, maybe this failure is irrelevant since the anomaly I reported concerns wired Ethernet.

Please advise.

[penalvch (penalvch)]

Richard Elkins, please do not compress/tar files, as it makes it harder for folks to review the contents.

Despite this, for more on dealing with out-of-tree modules, please see https://wiki.ubuntu.com/Kernel/MainlineBuilds#Preparing_to_install_an_upstream_kernel .

[Richard Elkins (texadactyl)]

Do not gzip tar files? Every file manager on every desktop automatically opens the folder for you- just double-click on the tar.gz file in the file manager. Using a command line, tar xvfz (added the 'z' for zipped) extracts the folder. Adding the 'z' is hard? But, if that is what you want, I will stop zipping tar files in the future.

I followed those instructions. As I already noted above, there were bcmwl compilation errors due to a missing symbol - probably a version issue in gcc or something else on my 14.04.04 system.

[Richard Elkins (texadactyl)]

Comment #31 was in error.

Finished my project.
Upgraded same laptop (HP Pavilion dv3-1075us Laptop) to 16.04 Beta-2.
This issue is no longer present.

I can only guess that this was not a kernel issue but in upstart/pm or elsewhere because I previously tried the upstream 4.5 kernel in a 14.04.04 environment without success.

[penalvch (penalvch)]

Richard Elkins:
>"Do not gzip tar files? Every file manager..."

Not everyone uses a file manager/GUI, especially developers.

[Richard Elkins (texadactyl)]

I know that. See my comment about the command line using the tar
utility in the back 1/2 of the same paragraph.

On 03/26/2016 01:05 PM, Christopher M. Penalver wrote:
> Richard Elkins:
>> "Do not gzip tar files? Every file manager..."
> Not everyone uses a file manager/GUI, especially developers.
>

[penalvch (penalvch)]

Richard Elkins, it appears you still don't understand, so allow a clarification.

You want folks who are helping you on their free time to have as few obstructions as possible, no matter how one perceives the effort.

[Richard Elkins (texadactyl)]

Christopher,

First of all, I am pleased that I no longer need work-arounds for this issue and the mouse-cursor disappearing. Apparently, both issues were addressed during or prior to 16.04.

I always try to minimize the time spent by investigators to extract information that I supply. As a developer, that is also what I would want. You said that submitting tar files in compressed form makes it harder for folks to review the contents. Let us put the GUI approach aside. Look solely at the command line for extracting the contents of a tar-archive.

1. tar xvf something.tar (uncompressed)
2. tar xvfz something.tar.gz (gzip-compressed)

As I implied in comment #30, to a developer who uses the command line regularly (E.g. me), #2 above is as simple as #1 above. Same level of effort. However, as I also said previously, I will be happy to only attach uncompressed tar-archives in the future. Maybe this is something we should have talked about on the phone or by email instead of in a bug report.

As a developer, I understand that kernel developers are busy. I certainly appreciate the time that they have donated to the various Linux distributions. I also appreciate the time that you spend time looking at the bug reports. That is exactly why I acknowledged that "This issue is no longer present" and marked it "Fix Released" as quickly as I could so that you and others could shift attention elsewhere as soon as possible.

My reporting this issue had the intention of highlighting an issue that people with a laptop who use the Ubuntu base might also run into in 14.04. I published a functional work-around so that (a) you and the kernel developers would know that I was not waiting for a fix and (b) another laptop user still on 14.04 could leverage the same work-around [if needed] by substituting the name of their Ethernet module for "r8169".