10ec:8139 Network connection rtl8139 lost after some hours of inactivity and comes up again on user interaction

I attach my dmesg output. It can be clearly seen that no interaction is logged for some time and at a certain point the USB mouse was plugged in at the end. That is when the connection came up again.

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/997767/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

I did a new test and it seems the problem manifests only when KDE/X11 is running. I tried to stop X and remaining on the terminal only and it seems it is still up.

I tested with an old kernel (2.6.38-11 was working) and I reproduced this issue.

Is this something as simple as the machine going into suspend/sleep when you aren't typing at it?

I'd go into the KDE system settings->Power Management and check the options; in particular the 'suspend session' option.

Dave

That is the first thing I checked days ago: Settings->Power Management is completely disabled on this system. By disabled, I mean I can do nothing, I get a message saying:

"Power Management configuration module could not be loaded. The Power Management Service appears not to be running. This can be solved by starting or scheduling it inside "Startup and Shutdown"".

Also, I commonly use suspend on my laptop, and it takes something like 8 to 10 seconds to wake up. Here I hear the disk for a second, and the network is up again (and this is an old hardware).

I did the test you suggested: issued while true; do date; ifconfig -a; sleep 60; done. I left it running all night long. Then I tried to ping the machine from another and I confirmed that it was unreachable as usual. So I checked the output of the command and I attached it. I see the system has not gone to sleep and the IP was never lost, but I see a large amount of dropped packets.

I'm setting this to Linux; given the test output it does look like the interface is still up and the machine hasn't gone to sleep; I can't quite see what would happen after user interaction though.

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

apport-collect 997767

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.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

I ran a new test and booting in failsafe mode prevents the network from shutting down.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

The report is when the network card works OK. The failing card is eth1.
I'm thinking to buy a new PCI, as I've read that it may be the device is faulty.
Thanks!

Just a comment, have you tried to add "acpi=no noapic" to GRUB_CMDLINE_LINUX_DEFAULT (in /etc/default/grub)?
I'm trying it now, and it *seems* to work. I'll come back in a few days to tell you if it works.

(I forgot to clarify that when you update /etc/default/grub you should run "sudo update-grub" to apply the changes)
The test I made still doesn't works always. The computer lost connectivity at 06:22 a.m. (the moment when the cron.daily scripts execute), and went back online at 06:47 a.m.
So, although adding "acpi=off noapic" to the startup helped a lot to minimize the problems, it still doesn't work as expected.

Yesterday I started this test. I booted and in grub I added the parameter you suggested. No shutdown yet. I'll continue the test to see if it just minimizes the problem or it solves. The only other way I found so far is to boot from grub in recovery mode.

The test I made still doesn't works always. The computer lost connectivity at 06:22 a.m. (the moment when the cron.daily scripts execute), and went back online at 06:47 a.m.
So, although adding "acpi=off noapic" to the startup helped a lot to minimize the problems, it still doesn't work as expected.

The problem is that it seems the system is not booting correctly with kernel 3.4.0-030400-generic. I get the splash screen reporting Xubuntu (is this correct?) and then I get an error with a shell. KDE is not booted. The last message I see is:

Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
 - Check rootdelay= (did the system wait long enough?)
 - Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/<uuid> does not exist.
Dropping to a shell!

And I have a shell here, which seems to be a shell of the initramfs and not that of my root partition. I'm not sure how, but if you need I can try to extract the kernel output of dmesg from here.

I don't know if I'm doing anything wrong, but I downloaded linux-image-3.5.0-030500rc1-generic_3.5.0-030500rc1.201206022335_i386.deb, I installed it using dpkg -i and booted using the newly added item in grub. The same I described before is happening. Same message and the shell in initramfs is provided.

Luca Carlon, thank you for trying the mainline kernel. The next step is to perform a bisect to identify the offending commit(s). Could you please do so following https://wiki.ubuntu.com/Kernel/KernelBisection ?

I can try to bisect, but do you think it makes sense to bisect even though kernel version 2.6.38-11-generic is failing as well? I think that kernel version was installed with Kubuntu 11.04, and I don't remember I ever encountered issues until 12.04.

@penalvch,

You are really not helping by just spamming bugs telling folks to bisect their kernels. Many people just are not prepared to do so.

@Luca,

Would it be possible for you to test the latest Lucid kernel[0]? It would be good to know if 2.6.32-41 is failing since you reported 2.6.38-11-generic is failing.

[0] https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/3436801/+files/linux-image-2.6.32-41-generic_2.6.32-41.89_i386.deb

There is some confusion here. Luca please correct me if I am wrong ...
1. You were originally running Natty and that was working fine for you.
2. You installed Precise and started to experience the issue.
3. You installed the Natty kernel on your Precise system and that is also
    showing the same problem.

From irc Luca also mentioned that he was running Oneiric just fine. I believe he also said that he is experiencing the issue when using the Oneiric kernel on his Precise install.

@jsalisbury, yes, I can do that. Let me just finish my current test and I can run on that kernel as well.

@brad-figg: Ok, I try to summarize because I created a lot of confusion here:

1. I've been running all the Kubuntu versions since some years, so including Natty, Oneiric etc... I always update to the latest version when it is available. With this hardware I've never had issues with previous versions of Kubuntu.

2. Yes, I installed 12.04 and I started to experience this.

3. I didn't install the Natty kernel, it was installed already since the previous versions of Kubuntu. I had available 2.6.38 and 3.0.0 (and 3.2 of course). None of those worked. I tested more than once.

4. Any test I run so far failed on this installation (network shut down). Also recovery mode and the proposal of mjan.

5. What I noticed so far is that when network load is high, the network seems to shut down sooner. Recovery mode for instance may last for more than a day. If instead I run mldonkey in recovery mode, after some hours I expect to see the network down. But this is only something I noticed, might only be a coincidence.

6. The only thing that I still haven't seen failing is the Precise live CD. I'm trying to load the network using iperf and downloading from the Internet continuously. Still no failure after a couple of days. I'll wait for some more days. But unfortunately, with the live CD I'm not able to run servers like apache, proftpd, svn, mldonkey etc... that I use in my common installation. Booting from USB is not supported by the hardware.

7. I had the chance to try kernel 3.4, thanks to a kind guy on irc. That failed as well. I still have to try 3.5.

@luca, thanks for the detailed description.

I think the point that I was trying to make is that when you had Oneiric installed (before Precise) that everything worked just fine.

When you upgraded to Precise, you encountered this issue. And now with Precise and booting the Oneiric kernel (which was already installed) you are still having the same issue.

Some news in case it could be of any help:

1. Tested kernel 2.6.32 as requested. Network fails.

2. Tried to completely reset BIOS settings, in case this was sonehow related to that, being integrated. No changes.

3. Tried to use RTL-8029 on the same system and that seems to work.

As discussed on IRC, USB seems to stop working with ACPI disabled, but then the network fails with it enabled.

Can you boot the machine with acpi enabled and disabled, and for both of these scenarios please report back the output from:

cat /proc/interrupts

and

dmesg

This way I can compare the two and maybe get an idea of what is going on.

Consider that I kept up to date with new Ubuntu kernels, so now I have 3.5.0-19-generic. I attached the output of the acpi=off.

The last lines in the dmesg for acpi=off are related to an USB hard disk plugged in when booting and a usb mouse plugged after boot: that is interesting because I discovered that sometimes when plugging I get those ehci error messages, sometimes I don't and a couple of times I even got the mouse to work (badly, movement was not smooth).

This is the output when acpi=on.

With acpi=off IRQ 21 is not working and devices hci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4 which are on this interrupt won't work. If you want to run with ACPI disabled you may want to try using:

acpi=off irqpoll

..and see if USB works. This is quite gross though

Great! Seems to work correctly now. And what about the fact that acpi=off is needed to avoid packets being dropped by the interface? Is that supposed to happen?

I've not yet figured out why acpi=off is required, but it should work with acpi enabled, so it is quite perplexing.

You could try by removing acpi=off and using:

pci=use_crs

and see what that does.

Tried that parameter but the network issue manifested again right now. Host was down until I plugged in a USB mouse: in some seconds the host could be contacted again.

It seems that the ACPI IRQ routing may be the cause. Can you try the kernel parameter:

acpi=noirq

I tried with this cmdline:
BOOT_IMAGE=/vmlinuz-3.5.0-19-generic root=UUID=f5d18141-1192-4ba1-91ea-15445600f4ad ro quiet splash acpi=noirq apm=off vt.handoff=7

USB is not working and the network issue just manifested.

Luca, can you try with just the biosirq kernel option just to see if this helps.

With biosirq the network is going down as well.

I suggest we default to using acpi=off irqpoll (which is not optimal) and I will see if I can find any alternative fixes.

Luca, since you said this was working before you upgraded, which release were you using when it worked?

Colin, I've been using this hardware and Ubuntu for years, and only started to fail in the last year. I already tried some older kernels but none seemed to work anymore. Now I just tried kernel 3.2.0-31-generic-pae and it failed (only took a few hours). Do I have a simple way to install older kernels? Maybe 3.0 or 2.6?

Also, I see this bug was marked as "Fix Released", what does this mean? It points to a old bug I see, but shouldn't a fix for it already be included in recent kernels?

Luca, you could try the official older kernels, however, one could try out the daily kernel builds found here:

http://kernel.ubuntu.com/~kernel-ppa/mainline/

..there are plenty to try out.. perhaps from this one can bisect down and see which kernel causes the bug to occur. From this we should be able to figure out which patch causes the regression.

It is very difficult to track this down, connection crash is random, but according to my tests, it seems that kernel 2.6.32-02063258 is ok, 2.6.32-02063259 is not. 2.6.32-02063258 has been running correctly for more than 8 days. Now I'm running it and still seems ok with this command line: BOOT_IMAGE=/vmlinuz-2.6.32-02063258-generic root=UUID=f5d18141-1192-4ba1-91ea-15445600f4ad ro crashkernel=384M-2G:64M,2G-:128M quiet splash apm=off.

Luca Carlon, 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.