Bug#494363: marked as done (thecus nic driver multicast issue)
On Thu, Aug 13, 2009 at 02:00:35AM +0100, Ben Hutchings wrote:
Can you try adding:
dprintk(tmp = %#x mc_filter = { %#x, %#x }\n, tmp, mc_filter[0],
mc_filter[1]);
to rtl_set_rx_mode() and reporting the output?
[1902098.77] r8169: tmp = 0xe60e mc_filter = { 0x8002, 0x4000 }
Can you also get statistics with ethtool -S eth0 before and after
sending multicast packets that the Thecus NIC should receive?
before:
# ethtool -S eth0
NIC statistics:
tx_packets: 198
rx_packets: 250
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 246
broadcast: 3
multicast: 1
tx_aborted: 0
tx_underrun: 0
#
after:
# ethtool -S eth0
NIC statistics:
tx_packets: 240
rx_packets: 293
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 284
broadcast: 8
multicast: 1
tx_aborted: 0
tx_underrun: 0
#
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494363: marked as done (thecus nic driver multicast issue)
On Wed, Aug 12, 2009 at 01:07:28AM +0100, Ben Hutchings wrote: Now that I've looked at the differences between different controller revisions, it appears that the switch in byte ordering for the multicast hash bitmap was made between the RTL8169 family (PCI) and RTL8168 family (PCI Express). The recent fix applied to some members of the latter family. One difference I noted between the vendor driver and the in-tree driver is in the ordering of register writes. It probably doesn't make a difference, but perhaps you could try changing: RTL_W32(MAR0 + 0, mc_filter[0]); RTL_W32(MAR0 + 4, mc_filter[1]); RTL_W32(RxConfig, tmp); to: RTL_W32(RxConfig, tmp); RTL_W32(MAR0 + 0, mc_filter[0]); RTL_W32(MAR0 + 4, mc_filter[1]); in rtl_set_rx_mode(). Applied, rebuilt; doesn't seem to have fixed the problem. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494363: marked as done (thecus nic driver multicast issue)
On Wed, 2009-08-12 at 17:17 -0700, Steve Langasek wrote:
On Wed, Aug 12, 2009 at 01:07:28AM +0100, Ben Hutchings wrote:
Now that I've looked at the differences between different controller
revisions, it appears that the switch in byte ordering for the multicast
hash bitmap was made between the RTL8169 family (PCI) and RTL8168 family
(PCI Express). The recent fix applied to some members of the latter
family.
One difference I noted between the vendor driver and the in-tree driver
is in the ordering of register writes. It probably doesn't make a
difference, but perhaps you could try changing:
RTL_W32(MAR0 + 0, mc_filter[0]);
RTL_W32(MAR0 + 4, mc_filter[1]);
RTL_W32(RxConfig, tmp);
to:
RTL_W32(RxConfig, tmp);
RTL_W32(MAR0 + 0, mc_filter[0]);
RTL_W32(MAR0 + 4, mc_filter[1]);
in rtl_set_rx_mode().
Applied, rebuilt; doesn't seem to have fixed the problem.
Can you try adding:
dprintk(tmp = %#x mc_filter = { %#x, %#x }\n, tmp, mc_filter[0],
mc_filter[1]);
to rtl_set_rx_mode() and reporting the output?
Can you also get statistics with ethtool -S eth0 before and after
sending multicast packets that the Thecus NIC should receive?
Ben.
--
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.
signature.asc
Description: This is a digitally signed message part
Bug#494363: marked as done (thecus nic driver multicast issue)
On Sun, 2009-08-09 at 07:41 -0700, Steve Langasek wrote: On Fri, Aug 07, 2009 at 01:08:36PM +0100, Ben Hutchings wrote: On Tue, 2009-08-04 at 07:31 -0700, Martin Michlmayr wrote: reopen 494363 thanks vorlon recently tested 2.6.30 and said this bug is still there. Can you build the module with RTL8169_DEBUG defined and send the kernel log messages it generates on load? Given a configured kernel build tree, you should be able to do this with: rm -f drivers/net/r8169.ko make EXTRA_CFLAGS=-DRTL8169_DEBUG drivers/net/r8169.ko Here you are: [1573779.78] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [1573779.79] r8169 :00:01.0: no PCI Express capability [1573779.79] r8169: mac_version = 0x04 [1573779.79] eth0: RTL8169sb/8110sb at 0xc8ec0200, 00:14:fd:30:2b:d6, XID 1000 IRQ 27 [1573779.80] r8169: mac_version = 0x04 [1573779.80] r8169: Set MAC Reg C+CR Offset 0x82h = 0x01h [1573779.80] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [1573779.81] r8169 :00:02.0: no PCI Express capability [1573779.82] r8169: mac_version = 0x04 [1573779.82] eth1: RTL8169sb/8110sb at 0xc8ec4300, 00:14:fd:30:2b:d7, XID 1000 IRQ 30 [1573779.83] r8169: mac_version = 0x04 [1573779.83] r8169: Set MAC Reg C+CR Offset 0x82h = 0x01h [1573780.57] r8169: eth0: link down [1573780.57] ADDRCONF(NETDEV_UP): eth0: link is not ready [1573781.34] r8169: eth0: link up [1573781.34] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Now that I've looked at the differences between different controller revisions, it appears that the switch in byte ordering for the multicast hash bitmap was made between the RTL8169 family (PCI) and RTL8168 family (PCI Express). The recent fix applied to some members of the latter family. One difference I noted between the vendor driver and the in-tree driver is in the ordering of register writes. It probably doesn't make a difference, but perhaps you could try changing: RTL_W32(MAR0 + 0, mc_filter[0]); RTL_W32(MAR0 + 4, mc_filter[1]); RTL_W32(RxConfig, tmp); to: RTL_W32(RxConfig, tmp); RTL_W32(MAR0 + 0, mc_filter[0]); RTL_W32(MAR0 + 4, mc_filter[1]); in rtl_set_rx_mode(). Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Bug#494363: marked as done (thecus nic driver multicast issue)
On Fri, Aug 07, 2009 at 01:08:36PM +0100, Ben Hutchings wrote: On Tue, 2009-08-04 at 07:31 -0700, Martin Michlmayr wrote: reopen 494363 thanks vorlon recently tested 2.6.30 and said this bug is still there. Can you build the module with RTL8169_DEBUG defined and send the kernel log messages it generates on load? Given a configured kernel build tree, you should be able to do this with: rm -f drivers/net/r8169.ko make EXTRA_CFLAGS=-DRTL8169_DEBUG drivers/net/r8169.ko Here you are: [1573779.78] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [1573779.79] r8169 :00:01.0: no PCI Express capability [1573779.79] r8169: mac_version = 0x04 [1573779.79] eth0: RTL8169sb/8110sb at 0xc8ec0200, 00:14:fd:30:2b:d6, XID 1000 IRQ 27 [1573779.80] r8169: mac_version = 0x04 [1573779.80] r8169: Set MAC Reg C+CR Offset 0x82h = 0x01h [1573779.80] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [1573779.81] r8169 :00:02.0: no PCI Express capability [1573779.82] r8169: mac_version = 0x04 [1573779.82] eth1: RTL8169sb/8110sb at 0xc8ec4300, 00:14:fd:30:2b:d7, XID 1000 IRQ 30 [1573779.83] r8169: mac_version = 0x04 [1573779.83] r8169: Set MAC Reg C+CR Offset 0x82h = 0x01h [1573780.57] r8169: eth0: link down [1573780.57] ADDRCONF(NETDEV_UP): eth0: link is not ready [1573781.34] r8169: eth0: link up [1573781.34] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494363: marked as done (thecus nic driver multicast issue)
On Tue, 2009-08-04 at 07:31 -0700, Martin Michlmayr wrote: reopen 494363 thanks vorlon recently tested 2.6.30 and said this bug is still there. Can you build the module with RTL8169_DEBUG defined and send the kernel log messages it generates on load? Given a configured kernel build tree, you should be able to do this with: rm -f drivers/net/r8169.ko make EXTRA_CFLAGS=-DRTL8169_DEBUG drivers/net/r8169.ko Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Bug#494363: marked as done (thecus nic driver multicast issue)
reopen 494363 thanks vorlon recently tested 2.6.30 and said this bug is still there. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
