info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
18 views
Skip to first unread message
Thanasis
Sep 20, 2012, 1:40:02 PM9/20/12
to
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
# 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Bjorn Helgaas
Sep 20, 2012, 1:50:02 PM9/20/12
to
kernel? This should just work, so maybe something got broken.
Bjorn
Bjorn Helgaas
Sep 20, 2012, 3:10:01 PM9/20/12
to
On Thu, Sep 20, 2012 at 12:10 PM, Thanasis <than...@asyr.hopto.org> wrote:
> 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
> on 09/20/2012 08:47 PM Bjorn Helgaas wrote the following:
>> On Thu, Sep 20, 2012 at 11:28 AM, Thanasis <than...@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.
>> On Thu, Sep 20, 2012 at 11:28 AM, Thanasis <than...@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
>>> 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.
>
> 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
Francois Romieu
Sep 20, 2012, 7:40:02 PM9/20/12
to
Bjorn Helgaas <bhel...@google.com> :
[...]
> +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
[...]
> 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/
> But searching for "r8169 transmit queue timed out" found lots of
> similar reports.
> +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
Francois Romieu
Sep 21, 2012, 11:50:01 AM9/21/12
to
Thanasis <than...@asyr.hopto.org> :
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.
> 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.
>
> Sure, let me know how to do it please.
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.
Thanasis
Sep 21, 2012, 12:40:01 PM9/21/12
to
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.
> <insert your ip addr add ... / link up and test sequence here>
Could you be more explicit please?
Thanasis
Sep 21, 2012, 12:50:02 PM9/21/12
to
on 09/21/2012 06:28 PM Francois Romieu wrote the following:
> Thanasis <than...@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)
> Thanasis <than...@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.
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.
>
--
Thanasis
Sep 21, 2012, 1:40:02 PM9/21/12
to
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:
> 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?
ifconfig eth0 192.168.0.19 up ; ping -c 3 192.168.0.1
Francois Romieu
Sep 21, 2012, 2:20:02 PM9/21/12
to
Thanasis <than...@asyr.hopto.org> :
[...]
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).
[...]
> 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
[...]
> 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
>
> ifconfig eth0 192.168.0.19 up ; ping -c 3 192.168.0.1
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
> 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 ?
[...]
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?
> Does it matter which source tree the /usr/src/linux symlink points to ?
--
Ueimor
Thanasis
Sep 21, 2012, 3:30:02 PM9/21/12
to
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?
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?
Francois Romieu
Sep 21, 2012, 4:50:02 PM9/21/12
to
Thanasis <than...@asyr.hopto.org> :
Without the usual netdev watchdog message I presume ?
[...]
> 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
> 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.
>
> 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?
welcome too.
Could you perform a test with your vendor's 3.2-something kernel and its
r8169 driver ?
--
Ueimor
Francois Romieu
Sep 21, 2012, 7:20:02 PM9/21/12
to
Thanasis <than...@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
[...]
You did experience a failure with a 3.5.4 kernel. Can you try a 3.2.x if
your vendor provides one ?
Thanks.
> 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.
> > r8169 driver ?
> >
You did experience a failure with a 3.5.4 kernel. Can you try a 3.2.x if
your vendor provides one ?
Thanks.
Thanasis
Sep 22, 2012, 2:30:02 AM9/22/12
to
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.
> You did experience a failure with a 3.5.4 kernel. Can you try a 3.2.x if
> your vendor provides one ?
>
Do you want me to run the r8169 make tests, if the r8169 of the 3.2.x works?
Thanasis
Sep 22, 2012, 4:30:01 AM9/22/12
to
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.
>
> You did experience a failure with a 3.5.4 kernel. Can you try a 3.2.x
It worked. The r8169 driver of the latest (22 Sep 2012) stable 3.2.30
source tree for the NIC in subject works.
Thanasis
Sep 22, 2012, 4:50:01 AM9/22/12
to
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
>>> 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
Francois Romieu
Sep 24, 2012, 7:40:01 PM9/24/12
to
Thanasis <than...@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.
> 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.
Francois Romieu
Sep 25, 2012, 6:20:02 AM9/25/12
to
Thanasis <than...@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.
[...]
> 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.
Francois Romieu
Sep 25, 2012, 5:20:02 PM9/25/12
to
Thanasis <than...@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) ?
[...]
> 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) ?
Thanasis
Sep 30, 2012, 4:10:01 AM9/30/12
to
on 09/26/2012 08:41 AM Thanasis wrote the following:
> 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?
> on 09/25/2012 11:53 PM Francois Romieu wrote the following:
>> Thanasis <than...@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...
>> Thanasis <than...@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) ?
>>
>
> I changed /sys/class/pci_bus/0000\:02/power/control from auto to on,
>> 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) ?
>>
>
> 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?
0 new messages