network slowdown on Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

[Ranga]

 I have a problem with network speed throttling down unexpectedly. The machine connects through a wireless N router as wired gigE. The router is performing fine since another machine in Windows that connects wirelessly to the same router doesn't see this speed drop when it is occuring on this machine in question. I am running Karmic 2.6.31-4. When I restart my network using /etc/init.d/networking restart, there is no change.

  I tried defining the /etc/network/interfaces to include eth0 and wlan0 but that didn't help either. The only way I can get the speed back to the original 6 mbps range is by rebooting the machine. Even then not all reboots restore the network speed. The speed drops to as low as 200 kbps. I am using a bandwidth testing site to measure. I don't see any errors that I can spot in "dmesg".

 lsb_release -rd
Description: Ubuntu karmic (development branch)
Release: 9.10

lspci -v

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
 Subsystem: Giga-byte Technology Device e000
 Flags: bus master, fast devsel, latency 0, IRQ 28
 I/O ports at ce00 [size=256]
 Memory at fddff000 (64-bit, prefetchable) [size=4K]
 Memory at fddf8000 (64-bit, prefetchable) [size=16K]
 [virtual] Expansion ROM at fdd00000 [disabled] [size=128K]
 Capabilities: [40] Power Management version 3
 Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
 Capabilities: [70] Express Endpoint, MSI 01
 Capabilities: [ac] MSI-X: Enable- Mask- TabSize=4
 Capabilities: [cc] Vital Product Data <?>
 Capabilities: [100] Advanced Error Reporting <?>
 Capabilities: [140] Virtual Channel <?>
 Capabilities: [160] Device Serial Number 00-e0-4c-68-00-00-00-03
 Kernel driver in use: r8169
 Kernel modules: r8169

ProblemType: Bug
Architecture: amd64
Date: Sat Aug 1 07:54:40 2009
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=bc715c58-c9c7-4be4-bb15-7df18c9fc12e
MachineType: Gigabyte Technology Co., Ltd. GA-MA790XT-UD4P
NonfreeKernelModules: nvidia
Package: linux-image-2.6.31-4-generic 2.6.31-4.23
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.31-4-generic root=UUID=3638bbdf-2cb8-4f6c-9fc6-3750cefe3461 ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-4.23-generic
RelatedPackageVersions: linux-backports-modules-2.6.31-4-generic N/A
SourcePackage: linux
Uname: Linux 2.6.31-4-generic x86_64
dmi.bios.date: 05/22/2009
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F4G
dmi.board.name: GA-MA790XT-UD4P
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF4G:bd05/22/2009:svnGigabyteTechnologyCo.,Ltd.:pnGA-MA790XT-UD4P:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-MA790XT-UD4P:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: GA-MA790XT-UD4P
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

[moose (snyderra)]

I have the same thing happen with a slightly different card.
On initial boot it goes to 1000 but after resume it will only connect at 100. it must be forced with ethtool back to 1000 and then it works fine.

notice how the first run of ethtool shows that the 1000 speeds are missing from the advertised link modes...

lsb_release -rd
Description: Ubuntu 9.10
Release: 9.10

uname -a
Linux redyns 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux

01:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
 Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17
 I/O ports at b000 [size=256]
 Memory at fa008000 (32-bit, non-prefetchable) [size=256]
 [virtual] Expansion ROM at fc000000 [disabled] [size=128K]
 Capabilities: [dc] Power Management version 2
 Kernel driver in use: r8169
 Kernel modules: r8169

sudo ethtool eth1
Settings for eth1:
 Supported ports: [ TP MII ]
 Supported link modes: 10baseT/Half 10baseT/Full
                         100baseT/Half 100baseT/Full
                         1000baseT/Half 1000baseT/Full
 Supports auto-negotiation: Yes
 Advertised link modes: 10baseT/Half 10baseT/Full
                         100baseT/Half 100baseT/Full
 Advertised auto-negotiation: Yes
 Speed: 100Mb/s
 Duplex: Full
 Port: MII
 PHYAD: 0
 Transceiver: internal
 Auto-negotiation: on
 Supports Wake-on: pumbg
 Wake-on: g
 Current message level: 0x00000033 (51)
 Link detected: yes
sudo ethtool -s eth1 speed 1000 duplex full
sudo ethtool eth1
Settings for eth1:
 Supported ports: [ TP MII ]
 Supported link modes: 10baseT/Half 10baseT/Full
                         100baseT/Half 100baseT/Full
                         1000baseT/Half 1000baseT/Full
 Supports auto-negotiation: Yes
 Advertised link modes: 10baseT/Half 10baseT/Full
                         100baseT/Half 100baseT/Full
                         1000baseT/Half 1000baseT/Full
 Advertised auto-negotiation: Yes
 Speed: 1000Mb/s
 Duplex: Full
 Port: MII
 PHYAD: 0
 Transceiver: internal
 Auto-negotiation: on
 Supports Wake-on: pumbg
 Wake-on: g
 Current message level: 0x00000033 (51)
 Link detected: yes

[moose (snyderra)]

still happens with -15 kernel

uname -a
Linux redyns 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 2009 i686 GNU/Linux

see ethtool outputs in tgz

[moose (snyderra)]

workaround: place attached file in /usr/lib/pm-utils/sleep.d/

don't know what will happen if not connected to a gigabit switch...

[Jeremy Foshee (jeremyfoshee)]

Hi Ranga,

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? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

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

apport-collect -p linux 407656

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. 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. Please let us know your results.

Thanks in advance.

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

[Ranga (sivajirangarajan)]

I don't believe this bug is anything on the linux side at all. Whenever
this happened, my other OS also failed to connect on this same
network. I have thereafter isolated this issue to be something
hardware related. I end up having to reset by CMOS by removing the
battery to get the NIC to respond again.

Thanks for the follow up.

-Ranga

On 03/14/2010 01:35 AM, Jeremy Foshee wrote:
> Hi Ranga,
>
> 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? Can you try
> with the latest development release of Ubuntu? ISO CD images are
> available from http://cdimage.ubuntu.com/releases/ .
>
> If it remains an issue, could you run the following command from a
> Terminal (Applications->Accessories->Terminal). It will automatically
> gather and attach updated debug information to this report.
>
> apport-collect -p linux 407656
>
> Also, if you could test the latest upstream kernel available that would
> be great. It will allow additional upstream developers to examine the
> issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once
> you've tested the upstream kernel, please remove the 'needs-upstream-
> testing' tag. 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. Please let us know your
> results.
>
> Thanks in advance.
>
> [This is an automated message. Apologies if it has reached you
> inappropriately; please just reply to this message indicating so.]
>
>
> ** Tags added: needs-kernel-logs
>
> ** Tags added: needs-upstream-testing
>
> ** Tags added: kj-triage
>
> ** Changed in: linux (Ubuntu)
> Status: New => Incomplete
>
>

[moose (snyderra)]

then my report is different as my can be resolved with ethtool
defiantly not a hardware problem on my end. I will check on this with
the the new kernel and report back.

On Sun, Mar 14, 2010 at 2:00 PM, Ranga <email address hidden> wrote:
> I don't believe this bug is anything on the linux side at all.  Whenever
> this happened, my other OS also failed to connect on this same
> network.    I have thereafter isolated this issue to be something
> hardware related.  I end up having to reset by CMOS by removing the
> battery to get the NIC to respond again.
>
> Thanks for the follow up.
>
> -Ranga
>
> On 03/14/2010 01:35 AM, Jeremy Foshee wrote:
>> Hi Ranga,
>>
>> 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? Can you try
>> with the latest development release of Ubuntu?  ISO CD images are
>> available from http://cdimage.ubuntu.com/releases/ .
>>
>> If it remains an issue, could you run the following command from a
>> Terminal (Applications->Accessories->Terminal).  It will automatically
>> gather and attach updated debug information to this report.
>>
>> apport-collect -p linux 407656
>>
>> Also, if you could test the latest upstream kernel available that would
>> be great.  It will allow additional upstream developers to examine the
>> issue.  Refer to https://wiki.ubuntu.com/KernelMainlineBuilds .  Once
>> you've tested the upstream kernel, please remove the 'needs-upstream-
>> testing' tag.  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.  Please let us know your
>> results.
>>
>> Thanks in advance.
>>
>> [This is an automated message.  Apologies if it has reached you
>> inappropriately; please just reply to this message indicating so.]
>>
>>
>> ** Tags added: needs-kernel-logs
>>
>> ** Tags added: needs-upstream-testing
>>
>> ** Tags added: kj-triage
>>
>> ** Changed in: linux (Ubuntu)
>>         Status: New =>  Incomplete
>>
>>
>
> --
> network slowdown on Ethernet controller: Realtek  Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet  controller (rev 03)
> https://bugs.launchpad.net/bugs/407656
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

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