RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

I have an Acer Aspire One notebook, and it has a NIC as shown below:

# lspci |grep -i Realtek
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

The driver module that I use is r8169. It works with 2.6 series of
kernels, but it does *not* with the recent 3.x of kernels.

Here is the output of ethtool with the 2.6.38 kernel:

# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	Link partner advertised pause frame use: No
	Link partner 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)
			       drv probe ifdown ifup
	Link detected: yes

Question: Should I stick with 2.6 kernels, or are there any directions
on how to make the NIC work with recent 3.x kernels?

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Bjorn Helgaas]

On Thu, Sep 20, 2012 at 11:28 AM, Thanasis <thanasis@asyr.hopto.org> wrote:
> I have an Acer Aspire One notebook, and it has a NIC as shown below:
>
> # lspci |grep -i Realtek
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
>
> The driver module that I use is r8169. It works with 2.6 series of
> kernels, but it does *not* with the recent 3.x of kernels.
>
> Here is the output of ethtool with the 2.6.38 kernel:
>
> # ethtool eth0
> Settings for eth0:
>         Supported ports: [ TP MII ]
>         Supported link modes:   10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>         Supported pause frame use: No
>         Supports auto-negotiation: Yes
>         Advertised link modes:  10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>         Advertised pause frame use: No
>         Advertised auto-negotiation: Yes
>         Link partner advertised link modes:  10baseT/Half 10baseT/Full
>                                              100baseT/Half 100baseT/Full
>         Link partner advertised pause frame use: No
>         Link partner 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)
>                                drv probe ifdown ifup
>         Link detected: yes
>
> Question: Should I stick with 2.6 kernels, or are there any directions
> on how to make the NIC work with recent 3.x kernels?

Can you collect the complete dmesg logs from both 2.6.38 and the 3.x
kernel?  This should just work, so maybe something got broken.

Bjorn

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

on 09/20/2012 08:47 PM Bjorn Helgaas wrote the following:
> On Thu, Sep 20, 2012 at 11:28 AM, Thanasis <thanasis@asyr.hopto.org> wrote:
>> I have an Acer Aspire One notebook, and it has a NIC as shown below:
>>
>> # lspci |grep -i Realtek
>> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>> RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
>>
>> The driver module that I use is r8169. It works with 2.6 series of
>> kernels, but it does *not* with the recent 3.x of kernels.
>> Question: Should I stick with 2.6 kernels, or are there any directions
>> on how to make the NIC work with recent 3.x kernels?
> 
> Can you collect the complete dmesg logs from both 2.6.38 and the 3.x
> kernel?  This should just work, so maybe something got broken.

Attached are the dmesg outputs from 2.6.38 and 3.5.4 kernels (file
dmesg.tar.bz2)


[-- Attachment #2: dmesg.tar.bz2 --]
[-- Type: application/x-bzip, Size: 18162 bytes --]

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Bjorn Helgaas]

On Thu, Sep 20, 2012 at 12:10 PM, Thanasis <thanasis@asyr.hopto.org> wrote:
> on 09/20/2012 08:47 PM Bjorn Helgaas wrote the following:
>> On Thu, Sep 20, 2012 at 11:28 AM, Thanasis <thanasis@asyr.hopto.org> wrote:
>>> I have an Acer Aspire One notebook, and it has a NIC as shown below:
>>>
>>> # lspci |grep -i Realtek
>>> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>>> RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
>>>
>>> The driver module that I use is r8169. It works with 2.6 series of
>>> kernels, but it does *not* with the recent 3.x of kernels.
>>> Question: Should I stick with 2.6 kernels, or are there any directions
>>> on how to make the NIC work with recent 3.x kernels?
>>
>> Can you collect the complete dmesg logs from both 2.6.38 and the 3.x
>> kernel?  This should just work, so maybe something got broken.
>
> Attached are the dmesg outputs from 2.6.38 and 3.5.4 kernels (file
> dmesg.tar.bz2)

Thanks.  I don't see anything wrong from the PCI core point of view.
But searching for "r8169 transmit queue timed out" found lots of
similar reports.

+cc 8169 driver folks

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Francois Romieu]

Bjorn Helgaas <bhelgaas@google.com> :
[...]
> Thanks.  I don't see anything wrong from the PCI core point of view.
> But searching for "r8169 transmit queue timed out" found lots of
> similar reports.

It's a rather common symptom when things go wrong :o/

> +cc 8169 driver folks

(thanks)

Thanasis, can you narrow down a bit the failing revision ?

I'm ok with building a set of ad-hoc backported r8169 drivers to find
the culprit - if the problem lays there - but I won't mind avoiding
a few tens of unneeded changesets.

-- 
Ueimor

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

[-- Attachment #1: Type: text/plain, Size: 204 bytes --]

on 09/21/2012 02:20 AM Francois Romieu wrote the following:

> 
> Thanasis, can you narrow down a bit the failing revision ?

Sure, let me know how to do it please.
FWIW , attached full lspci -k output.


[-- Attachment #2: lspci-k --]
[-- Type: text/plain, Size: 4101 bytes --]

00:00.0 Host bridge: Intel Corporation Mobile 945GSE Express Memory Controller Hub (rev 03)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller (rev 03)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: i915
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
	Subsystem: Acer Incorporated [ALI] Device 015b
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: HDA Intel
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
	Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02)
	Kernel driver in use: pcieport
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02)
	Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02)
	Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: uhci_hcd
00:1d.1 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: uhci_hcd
00:1d.2 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: uhci_hcd
00:1d.3 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: uhci_hcd
00:1d.7 USB controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
	Subsystem: Acer Incorporated [ALI] Device 015b
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7-M Family) SATA Controller [IDE mode] (rev 02)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: ata_piix
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: i801_smbus
01:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host Controller
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: sdhci-pci
01:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host Controller
	Subsystem: Acer Incorporated [ALI] Device 015b
01:00.3 System peripheral: JMicron Technology Corp. MS Host Controller
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: jmb38x_ms
01:00.4 System peripheral: JMicron Technology Corp. xD Host Controller
	Subsystem: Acer Incorporated [ALI] Device 015b
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: r8169
03:00.0 Ethernet controller: Atheros Communications Inc. AR242x / AR542x Wireless Network Adapter (PCI-Express) (rev 01)
	Subsystem: Foxconn International, Inc. Device e008
	Kernel driver in use: ath5k
04:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host Controller
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: sdhci-pci
04:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host Controller
	Subsystem: Acer Incorporated [ALI] Device 015b
04:00.3 System peripheral: JMicron Technology Corp. MS Host Controller
	Subsystem: Acer Incorporated [ALI] Device 015b
	Kernel driver in use: jmb38x_ms
04:00.4 System peripheral: JMicron Technology Corp. xD Host Controller
	Subsystem: Acer Incorporated [ALI] Device 015b

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Francois Romieu]

Thanasis <thanasis@asyr.hopto.org> :
> on 09/21/2012 02:20 AM Francois Romieu wrote the following:
[...]
> > Thanasis, can you narrow down a bit the failing revision ?
> 
> Sure, let me know how to do it please.

A rough kernel estimate had been enough. Nevermind.

You will find a hopefully not too quick 2.6.38 backport at :

git://violet.fr.zoreil.com/romieu/r8169

It does not reach the current in-kernel r8169.c state - call me lazy - but
stops somewhere between 3.2 and 3.3. While only 76 commits long, it should
be enough to spot a r8169 regression.

Assuming you run a 2.6.38-something kernel whose build tree lays at the
usual place, the included makefile will build a out-of-kernel r8169 driver.

You can use it as:

git clone git://violet.fr.zoreil.com/romieu/r8169
cd r8169
git rev-list --all | tac | while read c; do
git reset --hard $c
make
rmmod r8169
sync
insmod ./r8169.ko
<insert your ip addr add ... / link up and test sequence here>
done > /tmp/lets-go-shopping.log

^C when things go wrong.

You could do a git bisect but there may be several stupidly broken
commits and I have not checked that the top of the tree works.

Of course you are suggested to check that the code won't try to abuse
your system.

-- 
Ueimor

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

on 09/21/2012 06:28 PM Francois Romieu wrote the following:
> <insert your ip addr add ... / link up and test sequence here>
I don't get what you mean by the above step.
Could you be more explicit please?

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

on 09/21/2012 06:28 PM Francois Romieu wrote the following:
> Thanasis <thanasis@asyr.hopto.org> :
>> on 09/21/2012 02:20 AM Francois Romieu wrote the following:
> [...]
>>> Thanasis, can you narrow down a bit the failing revision ?
>>
>> Sure, let me know how to do it please.
> 
> A rough kernel estimate had been enough. Nevermind.
> 
> You will find a hopefully not too quick 2.6.38 backport at :
> 
> git://violet.fr.zoreil.com/romieu/r8169
> 
> It does not reach the current in-kernel r8169.c state - call me lazy - but
> stops somewhere between 3.2 and 3.3. While only 76 commits long, it should
> be enough to spot a r8169 regression.
> 
> Assuming you run a 2.6.38-something kernel whose build tree lays at the
> usual place, the included makefile will build a out-of-kernel r8169 driver.

In order to run the following steps, should I be running (should I boot)
the system with the 2.6.38-8 or the 3.5.4 kernel?
What kernel source trees do I need to have under /usr/src ?
Do I need to run make clean/mrproper beforehand?
Does it matter which source tree the /usr/src/linux symlink points to?

> 
> You can use it as:
> 
> git clone git://violet.fr.zoreil.com/romieu/r8169
> cd r8169
> git rev-list --all | tac | while read c; do
> git reset --hard $c
> make
> rmmod r8169
> sync
> insmod ./r8169.ko
> <insert your ip addr add ... / link up and test sequence here>
> done > /tmp/lets-go-shopping.log
> 
> ^C when things go wrong.
> 
> You could do a git bisect but there may be several stupidly broken
> commits and I have not checked that the top of the tree works.
> 
> Of course you are suggested to check that the code won't try to abuse
> your system.
> 

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

on 09/21/2012 07:30 PM Thanasis wrote the following:
> on 09/21/2012 06:28 PM Francois Romieu wrote the following:
>> <insert your ip addr add ... / link up and test sequence here>
> I don't get what you mean by the above step.
> Could you be more explicit please?

Hmm, think I got it ... Here is what I put there:

ifconfig eth0 192.168.0.19 up ; ping -c 3 192.168.0.1

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Francois Romieu]

Thanasis <thanasis@asyr.hopto.org> :
[...]
> Hmm, think I got it ... Here is what I put there:
>
> ifconfig eth0 192.168.0.19 up ; ping -c 3 192.168.0.1

If it fails with the r8169 driver included in the 3.5 tree, that's what
you can use, yes (you may add a second ping with -q -f -l and more
packets to wrap the descriptor rings quickly as well).

[...]
> In order to run the following steps, should I be running (should I boot)
> the system with the 2.6.38-8 or the 3.5.4 kernel?

2.6.38-8

> What kernel source trees do I need to have under /usr/src ?

Please take a look at the Makefile:
[...]
KDIR := /lib/modules/$(shell uname -r)/build

It's more a matter of "what do I have under /lib/modules/$(uname -r)/build ?"
(namely your 2.6.38-8 tree or a symlink to it).

> Do I need to run make clean/mrproper beforehand?

As long as it matches your running config, no.

> Does it matter which source tree the /usr/src/linux symlink points to ?

See above ?

-- 
Ueimor

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

So far, ping has failed *only* at this iteration of the make loop:

HEAD is now at b087148 r8169: support control of advertising.
make -C /lib/modules/2.6.38-r8/build
M=/mnt/usb-disk/atom/usr/src/test-r8169/r8169 modules
make[1]: Entering directory `/usr/src/linux-2.6.38-r8'
  CC [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.mod.o
  LD [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.ko
make[1]: Leaving directory `/usr/src/linux-2.6.38-r8'
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
>From 192.168.0.19: icmp_seq=1 Destination Host Unreachable
>From 192.168.0.19: icmp_seq=2 Destination Host Unreachable
>From 192.168.0.19: icmp_seq=3 Destination Host Unreachable

--- 192.168.0.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms
pipe 3


Now, after 74 iterations, it looks as if the loop is stuck at the following:

HEAD is now at 1ce4b16 r8169: spinlock redux.
make -C /lib/modules/2.6.38-r8/build
M=/mnt/usb-disk/atom/usr/src/test-r8169/r8169 modules
make[1]: Entering directory `/usr/src/linux-2.6.38-r8'
  CC [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.mod.o
  LD [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.ko
make[1]: Leaving directory `/usr/src/linux-2.6.38-r8'


Should I wait for it to end?
Do you want me to post the whole log so far?

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

[-- Attachment #1: Type: text/plain, Size: 104 bytes --]

Attached the whole log so far.
(the process looks stuck anyway for more than 30 min at the same point)


[-- Attachment #2: lets-go-shopping.log.bz2 --]
[-- Type: application/x-bzip, Size: 4095 bytes --]

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Francois Romieu]

Thanasis <thanasis@asyr.hopto.org> :
> So far, ping has failed *only* at this iteration of the make loop:

Ok.

Without the usual netdev watchdog message I presume ?

[...]
> Now, after 74 iterations, it looks as if the loop is stuck at the following:
> 
> HEAD is now at 1ce4b16 r8169: spinlock redux.
> make -C /lib/modules/2.6.38-r8/build
> M=/mnt/usb-disk/atom/usr/src/test-r8169/r8169 modules
> make[1]: Entering directory `/usr/src/linux-2.6.38-r8'
>   CC [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.o
>   Building modules, stage 2.
>   MODPOST 1 modules
>   CC      /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.mod.o
>   LD [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.ko
> make[1]: Leaving directory `/usr/src/linux-2.6.38-r8'
> 
> 
> Should I wait for it to end?

No. I surely f*cked up something.

> Do you want me to post the whole log so far?

Please. It should gzip well. The complete dmesg with timestamps would be
welcome too.

Could you perform a test with your vendor's 3.2-something kernel and its
r8169 driver ?

-- 
Ueimor

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

on 09/21/2012 11:29 PM Francois Romieu wrote the following:
> Thanasis <thanasis@asyr.hopto.org> :
>> So far, ping has failed *only* at this iteration of the make loop:
> 
> Ok.
> 
> Without the usual netdev watchdog message I presume ?

What message? What do you mean "the usual netdev watchdog message"?
I used a usb stick to transfer the log to another machine, if that's
what you mean.

> 
> [...]
>> Now, after 74 iterations, it looks as if the loop is stuck at the following:
>>
>> HEAD is now at 1ce4b16 r8169: spinlock redux.
>> make -C /lib/modules/2.6.38-r8/build
>> M=/mnt/usb-disk/atom/usr/src/test-r8169/r8169 modules
>> make[1]: Entering directory `/usr/src/linux-2.6.38-r8'
>>   CC [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.o
>>   Building modules, stage 2.
>>   MODPOST 1 modules
>>   CC      /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.mod.o
>>   LD [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.ko
>> make[1]: Leaving directory `/usr/src/linux-2.6.38-r8'
>>
>>
>> Should I wait for it to end?
> 
> No. I surely f*cked up something.
> 
>> Do you want me to post the whole log so far?
> 
> Please. It should gzip well. The complete dmesg with timestamps would be
> welcome too.

Attached dmesg.gz
> 
> Could you perform a test with your vendor's 3.2-something kernel and its
> r8169 driver ?
> 
The vendor's kernel was a 2.6 series.

[-- Attachment #2: dmesg.gz --]
[-- Type: application/x-gzip, Size: 12605 bytes --]

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Francois Romieu]

Thanasis <thanasis@asyr.hopto.org> :
> on 09/21/2012 11:29 PM Francois Romieu wrote the following:
[...]
> What message? What do you mean "the usual netdev watchdog message"?

No, this one (see your 3.5.4 kernel log):

[   23.712058] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x121/0x1a3(
)
[   23.712062] Hardware name: AOA110
[   23.712067] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out

[...]
> > Could you perform a test with your vendor's 3.2-something kernel and its
> > r8169 driver ?
> > 
> The vendor's kernel was a 2.6 series.

You did experience a failure with a 3.5.4 kernel. Can you try a 3.2.x if
your vendor provides one ?

Thanks.

-- 
Ueimor

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

on 09/22/2012 01:53 AM Francois Romieu wrote the following:

> You did experience a failure with a 3.5.4 kernel. Can you try a 3.2.x if
> your vendor provides one ?
> 

The vendor does not provide a 3.x kernel. But I will compile one.
Do you want me to run the r8169 make tests, if the r8169 of the 3.2.x works?

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

on 09/22/2012 01:53 AM Francois Romieu wrote the following:

> 
> You did experience a failure with a 3.5.4 kernel. Can you try a 3.2.x 

I downloaded the stable 3.2.30 and compiled.
It worked. The r8169 driver of the latest (22 Sep 2012) stable 3.2.30
source tree for the NIC in subject works.

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

on 09/22/2012 01:53 AM Francois Romieu wrote the following:

>>> Could you perform a test with ... 3.2-something kernel and its
>>> r8169 driver ?

As I said in my previous mail, I tried the r8169 of 3.2.30 and it works.

FWIW, while compiling the 3.2.30 kernel I saw this warning:

drivers/usb/storage/realtek_cr.c: In function ‘init_realtek_cr’:
drivers/usb/storage/realtek_cr.c:477:33: warning: ‘buf[15]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[15]’ was declared here
drivers/usb/storage/realtek_cr.c:476:33: warning: ‘buf[14]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[14]’ was declared here
drivers/usb/storage/realtek_cr.c:475:50: warning: ‘buf[13]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[13]’ was declared here
drivers/usb/storage/realtek_cr.c:473:30: warning: ‘buf[12]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[12]’ was declared here
drivers/usb/storage/realtek_cr.c:472:31: warning: ‘buf[11]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[11]’ was declared here
drivers/usb/storage/realtek_cr.c:471:31: warning: ‘buf[10]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[10]’ was declared here
drivers/usb/storage/realtek_cr.c:470:30: warning: ‘buf[9]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[9]’ was declared here
drivers/usb/storage/realtek_cr.c:469:27: warning: ‘buf[8]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[8]’ was declared here
drivers/usb/storage/realtek_cr.c:469:43: warning: ‘buf[7]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[7]’ was declared here
drivers/usb/storage/realtek_cr.c:468:30: warning: ‘buf[6]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[6]’ was declared here
drivers/usb/storage/realtek_cr.c:467:30: warning: ‘buf[5]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[5]’ was declared here
drivers/usb/storage/realtek_cr.c:466:28: warning: ‘buf[4]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[4]’ was declared here
drivers/usb/storage/realtek_cr.c:465:24: warning: ‘buf[3]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[3]’ was declared here
drivers/usb/storage/realtek_cr.c:465:40: warning: ‘buf[2]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[2]’ was declared here
drivers/usb/storage/realtek_cr.c:464:24: warning: ‘buf[1]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[1]’ was declared here
drivers/usb/storage/realtek_cr.c:464:40: warning: ‘buf[0]’ may be used
uninitialized in this function [-Wuninitialized]
drivers/usb/storage/realtek_cr.c:456:5: note: ‘buf[0]’ was declared here

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Francois Romieu]

Thanasis <thanasis@asyr.hopto.org> :
> Attached the whole log so far.
> (the process looks stuck anyway for more than 30 min at the same point)

You don't need to wait that long.

I have updated git://violet.fr.zoreil.com/romieu/r8169 with a
'3.2.r8169.backport' branch.

You can remove your existing r8169 git tree, clone this one and start
the same tests against a 3.2 kernel.

-- 
Ueimor

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

on 09/25/2012 02:12 AM Francois Romieu wrote the following:
> Thanasis <thanasis@asyr.hopto.org> :
>> Attached the whole log so far.
>> (the process looks stuck anyway for more than 30 min at the same point)
> 
> You don't need to wait that long.
> 
> I have updated git://violet.fr.zoreil.com/romieu/r8169 with a
> '3.2.r8169.backport' branch.
> 
> You can remove your existing r8169 git tree, clone this one and start
> the same tests against a 3.2 kernel.
> 

I don't know what's wrong, but I am getting those errors.
Are you sure about the git tree?



[-- Attachment #2: lets-go-3.2.log.gz --]
[-- Type: application/x-gzip, Size: 3035 bytes --]

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Francois Romieu]

Thanasis <thanasis@asyr.hopto.org> :
[...]
> I don't know what's wrong, but I am getting those errors.
> Are you sure about the git tree?

Yes. Replace 'git rev-list --all' with 'git rev-list --branches'.

It should show something like:
$ git rev-list --branches
a65a9b5d9c4569228909e36bb6e20d33fe208950
35417352eeec6fcfcb92796d3473ea0ed2624f5e
[...]
ec0c1f64e5751d0634c4afad9895c09d9a23da5f
b8a75250cee0d3c36b62038640b66d185c79fe34

Then, when test starts:
[...]
HEAD is now at b8a7525 3.2 r8169 driver and out-of-tree Makefile.

Sorry for the confusion.

-- 
Ueimor

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

on 09/25/2012 12:54 PM Francois Romieu wrote the following:
> Thanasis <thanasis@asyr.hopto.org> :
> [...]
>> I don't know what's wrong, but I am getting those errors.
>> Are you sure about the git tree?
> 
> Yes. Replace 'git rev-list --all' with 'git rev-list --branches'.
> 
> It should show something like:
> $ git rev-list --branches
> a65a9b5d9c4569228909e36bb6e20d33fe208950
> 35417352eeec6fcfcb92796d3473ea0ed2624f5e
> [...]
> ec0c1f64e5751d0634c4afad9895c09d9a23da5f
> b8a75250cee0d3c36b62038640b66d185c79fe34
> 
> Then, when test starts:
> [...]
> HEAD is now at b8a7525 3.2 r8169 driver and out-of-tree Makefile.
> 
> Sorry for the confusion.
> 

Ping failed in the following step:

HEAD is now at 3c6ad46 r8169: move rtl_set_rx_mode before its
rtl_hw_start callers.
make -C /lib/modules/3.2.30/build
M=/mnt/usb-disk/atom/usr/src/test-r8169/r8169 modules
make[1]: Entering directory `/usr/src/linux-3.2.30'
  CC [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.mod.o
  LD [M]  /mnt/usb-disk/atom/usr/src/test-r8169/r8169/r8169.ko
make[1]: Leaving directory `/usr/src/linux-3.2.30'
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
>From 192.168.0.19: icmp_seq=1 Destination Host Unreachable
>From 192.168.0.19: icmp_seq=2 Destination Host Unreachable
>From 192.168.0.19: icmp_seq=3 Destination Host Unreachable

--- 192.168.0.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms
pipe 3

(Full log attached)

[-- Attachment #2: 3.2.log.gz --]
[-- Type: application/x-gzip, Size: 2802 bytes --]

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Francois Romieu]

Thanasis <thanasis@asyr.hopto.org> :
[...]
> Ping failed in the following step:
> 
> HEAD is now at 3c6ad46 r8169: move rtl_set_rx_mode before its
> rtl_hw_start callers.

*spleen*

It's a genuine code move without any real change. Imho it's more a
matter of sleeping a few seconds for the link to settle after the
device is brought up.

The differences between the top-most r8169 driver you tried and the
real v3.5.4 r8169 driver are minor : mostly Ben Grear's corrupted
frames rx work (default: disabled) and a skb_timestamp which comes
too late in your setup.

So, either your problem lacks of reproducibility with 3.5.4 - cold reboot,
driver which does not fail the first time - or it needs something else
in the kernel to happen.

The "PME# disabled" messages have disappeared between 2.6 and 3.5.4 in your
dmesg. It's probably due to a dev_dbg/dev_printk + CONFIG_DYNAMIC_DEBUG
change. It's still worth checking runtime pm settings though

Can you check the content of /sys/class/pci_bus/0000:02/power, set it
to "on" if it contains "auto" and plug the cable again (with 3.5.4) ?

-- 
Ueimor

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

on 09/25/2012 11:53 PM Francois Romieu wrote the following:
> Thanasis <thanasis@asyr.hopto.org> :
> [...]
>> Ping failed in the following step:
>>
>> HEAD is now at 3c6ad46 r8169: move rtl_set_rx_mode before its
>> rtl_hw_start callers.
> 
> *spleen*
> 
> It's a genuine code move without any real change. Imho it's more a
> matter of sleeping a few seconds for the link to settle after the
> device is brought up.
> 
> The differences between the top-most r8169 driver you tried and the
> real v3.5.4 r8169 driver are minor : mostly Ben Grear's corrupted
> frames rx work (default: disabled) and a skb_timestamp which comes
> too late in your setup.
> 
> So, either your problem lacks of reproducibility with 3.5.4 - cold reboot,
> driver which does not fail the first time - or it needs something else
> in the kernel to happen.
> 
> The "PME# disabled" messages have disappeared between 2.6 and 3.5.4 in your
> dmesg. It's probably due to a dev_dbg/dev_printk + CONFIG_DYNAMIC_DEBUG
> change. It's still worth checking runtime pm settings though
> 

Sorry but I don't understand much of what you said above...

> Can you check the content of /sys/class/pci_bus/0000:02/power, set it
> to "on" if it contains "auto" and plug the cable again (with 3.5.4) ?
> 

I changed /sys/class/pci_bus/0000\:02/power/control from auto to on,
did unplug and plug the cable again, also I manually assigned thte IP
address to the NIC, but it did not make it work.

Here is the situation in /sys/class/pci_bus/0000\:02/power:

atom ~ # ls /sys/class/pci_bus/0000\:02/power
autosuspend_delay_ms  control  runtime_active_time  runtime_status
runtime_suspended_time
atom ~ # cat /sys/class/pci_bus/0000\:02/power/*
cat: /sys/class/pci_bus/0000:02/power/autosuspend_delay_ms: Input/output
error
on
0
unsupported
0
atom ~ # cat /sys/class/pci_bus/0000\:02/power/runtime_status
unsupported
atom ~ # cat /sys/class/pci_bus/0000\:02/power/control
on
atom ~ # cat /sys/class/pci_bus/0000\:02/power/runtime_active_time
0
atom ~ # cat /sys/class/pci_bus/0000\:02/power/runtime_suspended_time
0
atom ~ #

I attach the dmesg where it can be seen that the card every few seconds
reports:
r8169 0000:02:00.0: eth0: link up
r8169 0000:02:00.0: eth0: link up
r8169 0000:02:00.0: eth0: link up
r8169 0000:02:00.0: eth0: link up
...







[-- Attachment #2: dmesg.gz --]
[-- Type: application/x-gzip, Size: 14784 bytes --]

Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

[Thanasis]

on 09/26/2012 08:41 AM Thanasis wrote the following:
> on 09/25/2012 11:53 PM Francois Romieu wrote the following:
>> Thanasis <thanasis@asyr.hopto.org> :
>> [...]
>>> Ping failed in the following step:
>>>
>>> HEAD is now at 3c6ad46 r8169: move rtl_set_rx_mode before its
>>> rtl_hw_start callers.
>>
>> *spleen*
>>
>> It's a genuine code move without any real change. Imho it's more a
>> matter of sleeping a few seconds for the link to settle after the
>> device is brought up.
>>
>> The differences between the top-most r8169 driver you tried and the
>> real v3.5.4 r8169 driver are minor : mostly Ben Grear's corrupted
>> frames rx work (default: disabled) and a skb_timestamp which comes
>> too late in your setup.
>>
>> So, either your problem lacks of reproducibility with 3.5.4 - cold reboot,
>> driver which does not fail the first time - or it needs something else
>> in the kernel to happen.
>>
>> The "PME# disabled" messages have disappeared between 2.6 and 3.5.4 in your
>> dmesg. It's probably due to a dev_dbg/dev_printk + CONFIG_DYNAMIC_DEBUG
>> change. It's still worth checking runtime pm settings though
>>
> 
> Sorry but I don't understand much of what you said above...
> 
>> Can you check the content of /sys/class/pci_bus/0000:02/power, set it
>> to "on" if it contains "auto" and plug the cable again (with 3.5.4) ?
>>
> 
> I changed /sys/class/pci_bus/0000\:02/power/control from auto to on,
> did unplug and plug the cable again, also I manually assigned thte IP
> address to the NIC, but it did not make it work.
> 
> Here is the situation in /sys/class/pci_bus/0000\:02/power:
> 
> atom ~ # ls /sys/class/pci_bus/0000\:02/power
> autosuspend_delay_ms  control  runtime_active_time  runtime_status
> runtime_suspended_time
> atom ~ # cat /sys/class/pci_bus/0000\:02/power/*
> cat: /sys/class/pci_bus/0000:02/power/autosuspend_delay_ms: Input/output
> error
> on
> 0
> unsupported
> 0
> atom ~ # cat /sys/class/pci_bus/0000\:02/power/runtime_status
> unsupported
> atom ~ # cat /sys/class/pci_bus/0000\:02/power/control
> on
> atom ~ # cat /sys/class/pci_bus/0000\:02/power/runtime_active_time
> 0
> atom ~ # cat /sys/class/pci_bus/0000\:02/power/runtime_suspended_time
> 0
> atom ~ #
> 
> I attach the dmesg where it can be seen that the card every few seconds
> reports:
> r8169 0000:02:00.0: eth0: link up
> r8169 0000:02:00.0: eth0: link up
> r8169 0000:02:00.0: eth0: link up
> r8169 0000:02:00.0: eth0: link up
> ...
> 

Any news about the issue?
Should we file a bug?