* Re: [PATCH 01/02] r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard
From: Stephen Hemminger @ 2007-11-06 23:20 UTC (permalink / raw)
To: Francois Romieu
Cc: jgarzik, netdev, Andrew Morton, Edward Hsu, Ciaran McCreesh
In-Reply-To: <20071106231908.GB18076@electric-eye.fr.zoreil.com>
On Wed, 7 Nov 2007 00:19:08 +0100
Francois Romieu <romieu@fr.zoreil.com> wrote:
> Stephen Hemminger <shemminger@linux-foundation.org> :
> [...]
> > Really, vendor_id is 1 ?
>
> Yes, the bug seems to be commonly set in hardware.
>
> > How about a comment about which board this is.
>
> B3w4r3 0f Th3 3v1l Fatal1ty M0b0 ?
>
> Imho 'git log/blame' will provide enough information for this hack.
>
0k F1ne
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH 01/02] r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard
From: Francois Romieu @ 2007-11-06 23:19 UTC (permalink / raw)
To: Stephen Hemminger
Cc: jgarzik, netdev, Andrew Morton, Edward Hsu, Ciaran McCreesh
In-Reply-To: <20071106143729.2625f464@freepuppy.rosehill>
Stephen Hemminger <shemminger@linux-foundation.org> :
[...]
> Really, vendor_id is 1 ?
Yes, the bug seems to be commonly set in hardware.
> How about a comment about which board this is.
B3w4r3 0f Th3 3v1l Fatal1ty M0b0 ?
Imho 'git log/blame' will provide enough information for this hack.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] remove claim balance_rr won't reorder on many to one
From: Rick Jones @ 2007-11-06 22:59 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <25756.1194389384@death>
Jay Vosburgh wrote:
> Rick Jones <rick.jones2@hp.com> wrote:
>
>
>>So, where do you and I stand wrt the proposed changes to bonding.txt? Are
>>we at an impass?
>
> Nope, I'm doing a doc update next to incorporate several things,
> the reordering stuff included (which I plan to change to describe the
> levels of badness, as it were). Needed to fix a couple "no workee"
> things first.
OK. I look forward to applying my critical eye to that section :)
rick jones
^ permalink raw reply
* Re: [PATCH] remove claim balance_rr won't reorder on many to one
From: Jay Vosburgh @ 2007-11-06 22:49 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4730DF40.6090606@hp.com>
Rick Jones <rick.jones2@hp.com> wrote:
>So, where do you and I stand wrt the proposed changes to bonding.txt? Are
>we at an impass?
Nope, I'm doing a doc update next to incorporate several things,
the reordering stuff included (which I plan to change to describe the
levels of badness, as it were). Needed to fix a couple "no workee"
things first.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 01/02] r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard
From: Stephen Hemminger @ 2007-11-06 22:37 UTC (permalink / raw)
To: Francois Romieu
Cc: jgarzik, netdev, Andrew Morton, Edward Hsu, Ciaran McCreesh
In-Reply-To: <20071106222354.GB22170@electric-eye.fr.zoreil.com>
On Tue, 6 Nov 2007 23:23:54 +0100
Francois Romieu <romieu@fr.zoreil.com> wrote:
> Signed-off-by: Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Edward Hsu <edward_hsu@realtek.com.tw>
> ---
> drivers/net/r8169.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index b94fa7e..702334e 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -171,6 +171,8 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
> { PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
> { PCI_VENDOR_ID_LINKSYS, 0x1032,
> PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
> + { 0x0001, 0x8168,
> + PCI_ANY_ID, 0x2410, 0, 0, RTL_CFG_2 },
> {0,},
> };
>
Really, vendor_id is 1? How about a comment about which board this is.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* [PATCH] [AF_PACKET]: Allow multicast traffic to be caught by ORIGDEV when bonded
From: PJ Waskiewicz @ 2007-11-06 15:25 UTC (permalink / raw)
To: davem; +Cc: netdev
The socket option for packet sockets to return the original ifindex instead
of the bonded ifindex will not match multicast traffic. Since this socket
option is the most useful for layer 2 traffic and multicast traffic, make
the option multicast-aware.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
net/packet/af_packet.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 4cb2dfb..23eef6f 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -515,7 +515,7 @@ static int packet_rcv(struct sk_buff *skb, struct net_device *dev, struct packet
sll->sll_hatype = dev->type;
sll->sll_protocol = skb->protocol;
sll->sll_pkttype = skb->pkt_type;
- if (unlikely(po->origdev) && skb->pkt_type == PACKET_HOST)
+ if (unlikely(po->origdev))
sll->sll_ifindex = orig_dev->ifindex;
else
sll->sll_ifindex = dev->ifindex;
@@ -661,7 +661,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev, struct packe
sll->sll_hatype = dev->type;
sll->sll_protocol = skb->protocol;
sll->sll_pkttype = skb->pkt_type;
- if (unlikely(po->origdev) && skb->pkt_type == PACKET_HOST)
+ if (unlikely(po->origdev))
sll->sll_ifindex = orig_dev->ifindex;
else
sll->sll_ifindex = dev->ifindex;
^ permalink raw reply related
* [PATCH 01/02] r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard
From: Francois Romieu @ 2007-11-06 22:23 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Andrew Morton, Edward Hsu, Ciaran McCreesh
In-Reply-To: <20071106222213.GA22170@electric-eye.fr.zoreil.com>
Signed-off-by: Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b94fa7e..702334e 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -171,6 +171,8 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS, 0x1032,
PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
+ { 0x0001, 0x8168,
+ PCI_ANY_ID, 0x2410, 0, 0, RTL_CFG_2 },
{0,},
};
--
1.5.3.3
^ permalink raw reply related
* [PATCH 02/02] r8169: do not enable the TBI for the 8168 and the 81x0
From: Francois Romieu @ 2007-11-06 22:25 UTC (permalink / raw)
To: jgarzik
Cc: netdev, Andrew Morton, Edward Hsu, Matthias Winkler,
Maarten Vanraes
In-Reply-To: <20071106222213.GA22170@electric-eye.fr.zoreil.com>
The 8168c and the 8100e choke on it. I have not seen an indication
nor received a report that the TBI is being actively used on the
remaining 8168b and 8110. Let's disable it for now until someone
complains.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Matthias Winkler <m.winkler@unicon-ka.de>
Cc: Maarten Vanraes <maarten.vanraes@gmail.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
drivers/net/r8169.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 702334e..9dbab3f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1741,7 +1741,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->features |= rtl_try_msi(pdev, ioaddr, cfg);
RTL_W8(Cfg9346, Cfg9346_Lock);
- if (RTL_R8(PHYstatus) & TBI_Enable) {
+ if ((tp->mac_version <= RTL_GIGA_MAC_VER_06) &&
+ (RTL_R8(PHYstatus) & TBI_Enable)) {
tp->set_speed = rtl8169_set_speed_tbi;
tp->get_settings = rtl8169_gset_tbi;
tp->phy_reset_enable = rtl8169_tbi_reset_enable;
--
1.5.3.3
^ permalink raw reply related
* [PATCH 00/02] pull request for 'upstream-jeff' branch
From: Francois Romieu @ 2007-11-06 22:22 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, Andrew Morton, Edward Hsu
Please pull from branch 'upstream-jeff' in repository
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git upstream-jeff
to get the changes below.
Distance from 'master' (f2511f13daaf00fdd206bee7b108f75923a613c6)
-----------------------------------------------------------------
69b4d070ea49bd7f589776ea471a6988345eeee5
db1470271c581050dcacc6ed681b9166d30bdba0
Diffstat
--------
drivers/net/r8169.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
Shortlog
--------
Ciaran McCreesh (1):
r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard
Francois Romieu (1):
r8169: do not enable the TBI for the 8168 and the 81x0
Patch
-----
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b94fa7e..9dbab3f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -171,6 +171,8 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS, 0x1032,
PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
+ { 0x0001, 0x8168,
+ PCI_ANY_ID, 0x2410, 0, 0, RTL_CFG_2 },
{0,},
};
@@ -1739,7 +1741,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->features |= rtl_try_msi(pdev, ioaddr, cfg);
RTL_W8(Cfg9346, Cfg9346_Lock);
- if (RTL_R8(PHYstatus) & TBI_Enable) {
+ if ((tp->mac_version <= RTL_GIGA_MAC_VER_06) &&
+ (RTL_R8(PHYstatus) & TBI_Enable)) {
tp->set_speed = rtl8169_set_speed_tbi;
tp->get_settings = rtl8169_gset_tbi;
tp->phy_reset_enable = rtl8169_tbi_reset_enable;
--
Ueimor
^ permalink raw reply related
* Re: [PATCH] remove claim balance_rr won't reorder on many to one
From: Rick Jones @ 2007-11-06 21:40 UTC (permalink / raw)
To: Rick Jones; +Cc: Jay Vosburgh, netdev
In-Reply-To: <4727D583.90807@hp.com>
Jay -
So, where do you and I stand wrt the proposed changes to bonding.txt? Are we at
an impass?
sincerely,
rick jones
^ permalink raw reply
* [PATCH 2/2] bonding: don't validate address at device open
From: Jay Vosburgh @ 2007-11-06 21:33 UTC (permalink / raw)
To: netdev; +Cc: jgarzik, Jay Vosburgh
In-Reply-To: <11943848132752-git-send-email-fubar@us.ibm.com>
The standard validate_addr handler refuses to accept the all zeroes address
as valid. However, it's common historical practice for the bonding
master to be configured up prior to having any slaves, at which time the
master will have a MAC address of all zeroes.
Resolved by setting the dev->validate_addr to NULL. The master still can't
end up with an invalid address, as the set_mac_address function tests
for validity.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
---
drivers/net/bonding/bond_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 6937ef0..a198404 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4405,6 +4405,7 @@ static int bond_init(struct net_device *bond_dev, struct bond_params *params)
bond_dev->set_multicast_list = bond_set_multicast_list;
bond_dev->change_mtu = bond_change_mtu;
bond_dev->set_mac_address = bond_set_mac_address;
+ bond_dev->validate_addr = NULL;
bond_set_mode_ops(bond, bond->params.mode);
--
1.5.3.4.206.g58ba4-dirty
^ permalink raw reply related
* [PATCH 0/2] bonding: Two small fixes
From: Jay Vosburgh @ 2007-11-06 21:33 UTC (permalink / raw)
To: netdev; +Cc: jgarzik
Two small fixes to bonding for the mainline.
1: Mishandling of RTNL due to what looks like a merge error.
2: Turn off the new validate_addr check when devices are set
up. For backwards compatibility, the bonding master must be able to be
set up with a MAC address of all zeroes.
Patches are against linux-2.6, and apply cleanly
to netdev-2.6#upstream-linus. Please apply for 2.6.24.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* [PATCH 1/2] bonding: fix rtnl locking merge error
From: Jay Vosburgh @ 2007-11-06 21:33 UTC (permalink / raw)
To: netdev; +Cc: jgarzik, Jay Vosburgh
In-Reply-To: <11943848091427-git-send-email-fubar@us.ibm.com>
Looks like I incorrectly merged one of the rtnl lock changes,
so that one function, bonding_show_active_slave, held rtnl but didn't
release it, and another, bonding_store_active_slave, never held rtnl but
did release it.
Fixed so the first function doesn't mess with rtnl, and the
second correctly acquires and releases rtnl.
Bug reported by Moni Shoua <monis@voltaire.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
---
drivers/net/bonding/bond_sysfs.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 7a06ade..b29330d 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -1193,8 +1193,6 @@ static ssize_t bonding_show_active_slave(struct device *d,
struct bonding *bond = to_bond(d);
int count;
- rtnl_lock();
-
read_lock(&bond->curr_slave_lock);
curr = bond->curr_active_slave;
read_unlock(&bond->curr_slave_lock);
@@ -1216,7 +1214,9 @@ static ssize_t bonding_store_active_slave(struct device *d,
struct slave *new_active = NULL;
struct bonding *bond = to_bond(d);
+ rtnl_lock();
write_lock_bh(&bond->lock);
+
if (!USES_PRIMARY(bond->params.mode)) {
printk(KERN_INFO DRV_NAME
": %s: Unable to change active slave; %s is in mode %d\n",
--
1.5.3.4.206.g58ba4-dirty
^ permalink raw reply related
* Re: bizarre network timing problem
From: Rick Jones @ 2007-11-06 21:12 UTC (permalink / raw)
To: Felix von Leitner; +Cc: Chuck Ebbert, linux-kernel, Netdev
In-Reply-To: <20071102232332.GA5739@codeblau.de>
Felix von Leitner wrote:
> Thus spake Rick Jones (rick.jones2@hp.com):
>
>>Past performance is no guarantee of current correctness :) And over an
>>Ethernet, there will be a very different set of both timings and TCP
>>segment sizes compared to loopback.
>
>>My guess is that you will find setting the lo mtu to 1500 a very
>>interesting experiment.
>
> Setting the MTU on lo to 1500 eliminates the problem and gives me double
> digit MB/sec throughput.
I'm not in a position at the moment to test it as my IPoIB systems are offline,
and not sure you are either, but I will note that with IPoIB bits circa OFED1.2
the default MTU for IPoIB goes up to 65520 bytes. If indeed the problem you
were seeing was related to sub-mss sends and window probing and such, it might
appear on IPoIB in addition to loopback.
rick jones
^ permalink raw reply
* Stack Trace. Bad?
From: Jon Nelson @ 2007-11-06 20:23 UTC (permalink / raw)
To: netdev
In-Reply-To: <cccedfc60711061222o6c4599fcyf71265c126568395@mail.gmail.com>
[linux-raid was also emailed this same information]
I was testing some network throughput today and ran into this.
I should note that I've this motherboard has 2x MCP55 Ethernet and one
of them works fine and the other one gives lots and lots of frame
errors under load.
The following is only an harmless informational message.
Unless you get a _continuous_flood_ of these messages it means
everything is working fine. Allocations from irqs cannot be
perfectly reliable and the kernel is designed to handle that.
md0_raid5: page allocation failure. order:2, mode:0x20
Call Trace:
<IRQ> [<ffffffff802684c2>] __alloc_pages+0x324/0x33d
[<ffffffff80283147>] kmem_getpages+0x66/0x116
[<ffffffff8028367a>] fallback_alloc+0x104/0x174
[<ffffffff80283330>] kmem_cache_alloc_node+0x9c/0xa8
[<ffffffff80396984>] __alloc_skb+0x65/0x138
[<ffffffff8821d82a>] :forcedeth:nv_alloc_rx_optimized+0x4d/0x18f
[<ffffffff88220fca>] :forcedeth:nv_napi_poll+0x61f/0x71c
[<ffffffff8039ce93>] net_rx_action+0xb2/0x1c5
[<ffffffff8023625e>] __do_softirq+0x65/0xce
[<ffffffff8020adbc>] call_softirq+0x1c/0x28
[<ffffffff8020bef5>] do_softirq+0x2c/0x7d
[<ffffffff8020c180>] do_IRQ+0xb6/0xd6
[<ffffffff8020a141>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff80265d8e>] mempool_free_slab+0x0/0xe
[<ffffffff803fac0b>] _spin_unlock_irqrestore+0x8/0x9
[<ffffffff803892d8>] bitmap_daemon_work+0xee/0x2f3
[<ffffffff80386571>] md_check_recovery+0x22/0x4b9
[<ffffffff88118e10>] :raid456:raid5d+0x1b/0x3a2
[<ffffffff8023978b>] del_timer_sync+0xc/0x16
[<ffffffff803f98db>] schedule_timeout+0x92/0xad
[<ffffffff80239612>] process_timeout+0x0/0x5
[<ffffffff803f98ce>] schedule_timeout+0x85/0xad
[<ffffffff80387e62>] md_thread+0xf2/0x10e
[<ffffffff80243353>] autoremove_wake_function+0x0/0x2e
[<ffffffff80387d70>] md_thread+0x0/0x10e
[<ffffffff8024322c>] kthread+0x47/0x73
[<ffffffff8020aa48>] child_rip+0xa/0x12
[<ffffffff802431e5>] kthread+0x0/0x73
[<ffffffff8020aa3e>] child_rip+0x0/0x12
Mem-info:
Node 0 DMA per-cpu:
CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Node 0 DMA32 per-cpu:
CPU 0: Hot: hi: 186, btch: 31 usd: 115 Cold: hi: 62, btch: 15 usd: 31
CPU 1: Hot: hi: 186, btch: 31 usd: 128 Cold: hi: 62, btch: 15 usd: 56
Active:111696 inactive:116497 dirty:31 writeback:0 unstable:0
free:1850 slab:19676 mapped:3608 pagetables:1217 bounce:0
Node 0 DMA free:3988kB min:40kB low:48kB high:60kB active:232kB
inactive:5496kB present:10692kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 994 994
Node 0 DMA32 free:3412kB min:4012kB low:5012kB high:6016kB
active:446552kB inactive:460492kB present:1018020kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Node 0 DMA: 29*4kB 2*8kB 1*16kB 0*32kB 0*64kB 0*128kB 1*256kB 1*512kB
1*1024kB 1*2048kB 0*4096kB = 3988kB
Node 0 DMA32: 419*4kB 147*8kB 19*16kB 0*32kB 1*64kB 0*128kB 1*256kB
0*512kB 0*1024kB 0*2048kB 0*4096kB = 3476kB
Swap cache: add 57, delete 57, find 0/0, race 0+0
Free swap = 979608kB
Total swap = 979832kB
Free swap: 979608kB
262128 pages of RAM
4938 reserved pages
108367 pages shared
0 pages swap cached
--
Jon
^ permalink raw reply
* Stack Trace. Bad?
From: Jon Nelson @ 2007-11-06 20:22 UTC (permalink / raw)
To: netdev
In-Reply-To: <cccedfc60711061139r11a5e8c6raf6cd64c575ec453@mail.gmail.com>
[linux-raid was also emailed this same information]
I was testing some network throughput today and ran into this.
I should note that I've this motherboard has 2x MCP55 Ethernet and one
of them works fine and the other one gives lots and lots of frame
errors under load.
The following is only an harmless informational message.
Unless you get a _continuous_flood_ of these messages it means
everything is working fine. Allocations from irqs cannot be
perfectly reliable and the kernel is designed to handle that.
md0_raid5: page allocation failure. order:2, mode:0x20
Call Trace:
<IRQ> [<ffffffff802684c2>] __alloc_pages+0x324/0x33d
[<ffffffff80283147>] kmem_getpages+0x66/0x116
[<ffffffff8028367a>] fallback_alloc+0x104/0x174
[<ffffffff80283330>] kmem_cache_alloc_node+0x9c/0xa8
[<ffffffff80396984>] __alloc_skb+0x65/0x138
[<ffffffff8821d82a>] :forcedeth:nv_alloc_rx_optimized+0x4d/0x18f
[<ffffffff88220fca>] :forcedeth:nv_napi_poll+0x61f/0x71c
[<ffffffff8039ce93>] net_rx_action+0xb2/0x1c5
[<ffffffff8023625e>] __do_softirq+0x65/0xce
[<ffffffff8020adbc>] call_softirq+0x1c/0x28
[<ffffffff8020bef5>] do_softirq+0x2c/0x7d
[<ffffffff8020c180>] do_IRQ+0xb6/0xd6
[<ffffffff8020a141>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff80265d8e>] mempool_free_slab+0x0/0xe
[<ffffffff803fac0b>] _spin_unlock_irqrestore+0x8/0x9
[<ffffffff803892d8>] bitmap_daemon_work+0xee/0x2f3
[<ffffffff80386571>] md_check_recovery+0x22/0x4b9
[<ffffffff88118e10>] :raid456:raid5d+0x1b/0x3a2
[<ffffffff8023978b>] del_timer_sync+0xc/0x16
[<ffffffff803f98db>] schedule_timeout+0x92/0xad
[<ffffffff80239612>] process_timeout+0x0/0x5
[<ffffffff803f98ce>] schedule_timeout+0x85/0xad
[<ffffffff80387e62>] md_thread+0xf2/0x10e
[<ffffffff80243353>] autoremove_wake_function+0x0/0x2e
[<ffffffff80387d70>] md_thread+0x0/0x10e
[<ffffffff8024322c>] kthread+0x47/0x73
[<ffffffff8020aa48>] child_rip+0xa/0x12
[<ffffffff802431e5>] kthread+0x0/0x73
[<ffffffff8020aa3e>] child_rip+0x0/0x12
Mem-info:
Node 0 DMA per-cpu:
CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Node 0 DMA32 per-cpu:
CPU 0: Hot: hi: 186, btch: 31 usd: 115 Cold: hi: 62, btch: 15 usd: 31
CPU 1: Hot: hi: 186, btch: 31 usd: 128 Cold: hi: 62, btch: 15 usd: 56
Active:111696 inactive:116497 dirty:31 writeback:0 unstable:0
free:1850 slab:19676 mapped:3608 pagetables:1217 bounce:0
Node 0 DMA free:3988kB min:40kB low:48kB high:60kB active:232kB
inactive:5496kB present:10692kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 994 994
Node 0 DMA32 free:3412kB min:4012kB low:5012kB high:6016kB
active:446552kB inactive:460492kB present:1018020kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 0 0
Node 0 DMA: 29*4kB 2*8kB 1*16kB 0*32kB 0*64kB 0*128kB 1*256kB 1*512kB
1*1024kB 1*2048kB 0*4096kB = 3988kB
Node 0 DMA32: 419*4kB 147*8kB 19*16kB 0*32kB 1*64kB 0*128kB 1*256kB
0*512kB 0*1024kB 0*2048kB 0*4096kB = 3476kB
Swap cache: add 57, delete 57, find 0/0, race 0+0
Free swap = 979608kB
Total swap = 979832kB
Free swap: 979608kB
262128 pages of RAM
4938 reserved pages
108367 pages shared
0 pages swap cached
--
Jon
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: Jarek Poplawski @ 2007-11-06 20:28 UTC (permalink / raw)
To: Radu Rendec; +Cc: hadi, netdev
In-Reply-To: <1194368416.2987.218.camel@localhost.localdomain>
Radu Rendec wrote, On 11/06/2007 06:00 PM:
> On Tue, 2007-11-06 at 09:43 -0500, jamal wrote:
>> On Tue, 2007-06-11 at 15:25 +0100, Jarek Poplawski wrote:
>>
>>> Yes, it saves one htonl() on the slow path!
>> Would it feel better to say grew down exponentially from version 1 to
>> 3? ;->
Sure, but I felt much better after this:
> Actually I'm not impatient at all, because the shaping machine at the
> ISP where I work is already patched with my original patch, and cpu
> usage has gone from 100% to 8% after implementing hashes ;->
I'm not so lucky to see this code working, so I didn't expect earlier
this place could be so meaningful. As a matter of fact I've thought
Jamal exaggerates about this fast path... Now, I try to understand
why it didn't come out earlier. Anyway, Radu - my congratulations!
>>>> Please give yourself a little pat on the back for me.
>>> Wait a minute! Don't forget to take a picture or something!
>> He needs the other arm for balance;-> so unless someone else takes the
>> photo, i would say that should he be successful taking the photo, that
>> achievement itself needs a double-self-pat-on-the-back (which i am going
>> to say if he can also take a photo of needs to go on some records book)
>
> I'm sorry to disappoint you, guys, but most probably I'll pat myself on
> the back here at work, after I get enthusiastic about the patches. So my
> fellow colleagues will take the picture for me. If I get really
> enthusiastic, then I'll have my both arms available for patting :)
Alas, I don't take pictures either, but, it seems, any way should be
good if it's visible for whom are you patted by!
Cheers,
Jarek P.
^ permalink raw reply
* Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: Krzysztof Halasa @ 2007-11-06 20:08 UTC (permalink / raw)
To: Ben Greear
Cc: Patrick McHardy, David Miller, djohnson+linux-kernel, jes, mchan,
ram.vepa, linux-kernel, netdev, bguo
In-Reply-To: <4730B8ED.7020301@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> Bridging eth0 to eth1 should not pay attention to VLAN tags
> at all (if the pkt comes in on VLAN 7, it should go out on VLAN 7),
> in my opinion. If the NIC is stripping the VLAN header, then this
> cannot work unless something re-builds the VLAN header. If the stripped
> VLAN header is placed into the skb, then any code that does need to
> rebuild it can do so. It may be less efficient, but users can just
> not use that NIC hardware for high-end solutions, and at any rate,
> less efficient is better than broken.
That is all true. The problem arises when you receive a tagged frame
on eth0, the chip removes the tag, and then the bridge sends it
out untagged on eth1.
I think there are two valid models for VLAN + bridging:
a) bridging works on "physical" interfaces, all tags are transmitted
unchanged.
b) every VLAN is a different logical interface, packets from unknown
VLANs are dropped on RX (and thus don't show up anywhere, except
counters), bridging uses logical interfaces. VLAN 100 on eth0 may
become VLAN 200 on eth1 and may be untagged on eth2.
"a" requires "soft" VLANs and/or adding the tags back (with
accelerated VLANs). This is how unmanaged switches labeled
"802.1Q - transparent" work. Not very flexible but usually good
enough.
"b" is how switches supporting VLANs (and 802.1Q) usually work.
I know ability to see exactly all packets as they are received
(including tags) is a really nice thing. But maybe we should change
the model? Making the ethX only carry untagged frames (even without
hw VLAN acceleration)?
--
Krzysztof Halasa
^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2007-11-06 20:07 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-wireless
Jeff,
Here are a few fixes for 2.6.24. The iwlwifi "is_power_of_2" patch is
a little questionable as a fix. But it does bring the buildtime check
in iwl_tx_queue_init in-line with the runtime check in iwl_queue_init,
and it is 2x a one-liner -- so I think it is worthwhile.
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub//linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
The following changes since commit 2655e2cee2d77459fcb7e10228259e4ee0328697:
Alan Cox (1):
ata_piix: Add additional PCI identifier for 40 wire short cable
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
Holger Schurig (1):
libertas: fixes for slow hardware
Ivo van Doorn (1):
rt2x00: Block adhoc & master mode
John W. Linville (1):
hermes: clarify Intel reference in Kconfig help
Marcelo Tosatti (1):
libertas: properly account for queue commands
Michael Buesch (1):
b43: pcmcia-host initialization bugfixes
Pierre Ossman (1):
libertas: make if_sdio align packets
Randy Dunlap (1):
hostap: fix section mismatch warning
Robert P. J. Day (1):
iwlwifi: Use more obvious "is_power_of_2" macro.
Roel Kluin (1):
ipw2100: fix postfix decrement errors
drivers/net/wireless/Kconfig | 2 +-
drivers/net/wireless/b43/pcmcia.c | 44 +++++++++++++++-----------
drivers/net/wireless/hostap/hostap_pci.c | 6 ++--
drivers/net/wireless/ipw2100.c | 4 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 3 +-
drivers/net/wireless/iwlwifi/iwl4965-base.c | 3 +-
drivers/net/wireless/libertas/cmd.c | 10 ++++--
drivers/net/wireless/libertas/if_cs.c | 7 +++-
drivers/net/wireless/libertas/if_sdio.c | 4 ++-
drivers/net/wireless/rt2x00/rt2x00mac.c | 8 +++++
10 files changed, 58 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index dae5c8d..2b733c5 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -325,7 +325,7 @@ config HERMES
Cabletron/EnteraSys Roamabout, ELSA AirLancer, MELCO Buffalo, Avaya,
IBM High Rate Wireless, Farralon Syyline, Samsung MagicLAN, Netgear
MA401, LinkSys WPC-11, D-Link DWL-650, 3Com AirConnect, Intel
- PRO/Wireless, and Symbol Spectrum24 High Rate amongst others.
+ IPW2011, and Symbol Spectrum24 High Rate amongst others.
This option includes the guts of the driver, but in order to
actually use a card you will also need to enable support for PCMCIA
diff --git a/drivers/net/wireless/b43/pcmcia.c b/drivers/net/wireless/b43/pcmcia.c
index b242a9a..4b6648f 100644
--- a/drivers/net/wireless/b43/pcmcia.c
+++ b/drivers/net/wireless/b43/pcmcia.c
@@ -65,12 +65,12 @@ static int __devinit b43_pcmcia_probe(struct pcmcia_device *dev)
tuple_t tuple;
cisparse_t parse;
int err = -ENOMEM;
- int res;
+ int res = 0;
unsigned char buf[64];
ssb = kzalloc(sizeof(*ssb), GFP_KERNEL);
if (!ssb)
- goto out;
+ goto out_error;
err = -ENODEV;
tuple.DesiredTuple = CISTPL_CONFIG;
@@ -96,10 +96,12 @@ static int __devinit b43_pcmcia_probe(struct pcmcia_device *dev)
dev->io.NumPorts2 = 0;
dev->io.Attributes2 = 0;
- win.Attributes = WIN_MEMORY_TYPE_CM | WIN_ENABLE | WIN_USE_WAIT;
+ win.Attributes = WIN_ADDR_SPACE_MEM | WIN_MEMORY_TYPE_CM |
+ WIN_ENABLE | WIN_DATA_WIDTH_16 |
+ WIN_USE_WAIT;
win.Base = 0;
win.Size = SSB_CORE_SIZE;
- win.AccessSpeed = 1000;
+ win.AccessSpeed = 250;
res = pcmcia_request_window(&dev, &win, &dev->win);
if (res != CS_SUCCESS)
goto err_kfree_ssb;
@@ -108,21 +110,26 @@ static int __devinit b43_pcmcia_probe(struct pcmcia_device *dev)
mem.Page = 0;
res = pcmcia_map_mem_page(dev->win, &mem);
if (res != CS_SUCCESS)
- goto err_kfree_ssb;
+ goto err_disable;
res = pcmcia_request_configuration(dev, &dev->conf);
if (res != CS_SUCCESS)
goto err_disable;
err = ssb_bus_pcmciabus_register(ssb, dev, win.Base);
+ if (err)
+ goto err_disable;
dev->priv = ssb;
- out:
- return err;
- err_disable:
+ return 0;
+
+err_disable:
pcmcia_disable_device(dev);
- err_kfree_ssb:
+err_kfree_ssb:
kfree(ssb);
+out_error:
+ printk(KERN_ERR "b43-pcmcia: Initialization failed (%d, %d)\n",
+ res, err);
return err;
}
@@ -131,22 +138,21 @@ static void __devexit b43_pcmcia_remove(struct pcmcia_device *dev)
struct ssb_bus *ssb = dev->priv;
ssb_bus_unregister(ssb);
- pcmcia_release_window(dev->win);
pcmcia_disable_device(dev);
kfree(ssb);
dev->priv = NULL;
}
static struct pcmcia_driver b43_pcmcia_driver = {
- .owner = THIS_MODULE,
- .drv = {
- .name = "b43-pcmcia",
- },
- .id_table = b43_pcmcia_tbl,
- .probe = b43_pcmcia_probe,
- .remove = b43_pcmcia_remove,
- .suspend = b43_pcmcia_suspend,
- .resume = b43_pcmcia_resume,
+ .owner = THIS_MODULE,
+ .drv = {
+ .name = "b43-pcmcia",
+ },
+ .id_table = b43_pcmcia_tbl,
+ .probe = b43_pcmcia_probe,
+ .remove = __devexit_p(b43_pcmcia_remove),
+ .suspend = b43_pcmcia_suspend,
+ .resume = b43_pcmcia_resume,
};
int b43_pcmcia_init(void)
diff --git a/drivers/net/wireless/hostap/hostap_pci.c b/drivers/net/wireless/hostap/hostap_pci.c
index 7da3664..fc876ba 100644
--- a/drivers/net/wireless/hostap/hostap_pci.c
+++ b/drivers/net/wireless/hostap/hostap_pci.c
@@ -444,7 +444,7 @@ static int prism2_pci_resume(struct pci_dev *pdev)
MODULE_DEVICE_TABLE(pci, prism2_pci_id_table);
-static struct pci_driver prism2_pci_drv_id = {
+static struct pci_driver prism2_pci_driver = {
.name = "hostap_pci",
.id_table = prism2_pci_id_table,
.probe = prism2_pci_probe,
@@ -458,13 +458,13 @@ static struct pci_driver prism2_pci_drv_id = {
static int __init init_prism2_pci(void)
{
- return pci_register_driver(&prism2_pci_drv_id);
+ return pci_register_driver(&prism2_pci_driver);
}
static void __exit exit_prism2_pci(void)
{
- pci_unregister_driver(&prism2_pci_drv_id);
+ pci_unregister_driver(&prism2_pci_driver);
}
diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index 8d53d08..fc6cdd8 100644
--- a/drivers/net/wireless/ipw2100.c
+++ b/drivers/net/wireless/ipw2100.c
@@ -1267,7 +1267,7 @@ static int ipw2100_start_adapter(struct ipw2100_priv *priv)
IPW2100_INTA_FATAL_ERROR |
IPW2100_INTA_PARITY_ERROR);
}
- } while (i--);
+ } while (--i);
/* Clear out any pending INTAs since we aren't supposed to have
* interrupts enabled at this point... */
@@ -1339,7 +1339,7 @@ static int ipw2100_power_cycle_adapter(struct ipw2100_priv *priv)
if (reg & IPW_AUX_HOST_RESET_REG_MASTER_DISABLED)
break;
- } while (i--);
+ } while (--i);
priv->status &= ~STATUS_RESET_PENDING;
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 4f22a71..53b4b4e 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -50,6 +50,7 @@
#include <linux/firmware.h>
#include <linux/etherdevice.h>
#include <linux/if_arp.h>
+#include <linux/log2.h>
#include <net/ieee80211_radiotap.h>
#include <net/mac80211.h>
@@ -343,7 +344,7 @@ int iwl_tx_queue_init(struct iwl_priv *priv,
/* TFD_QUEUE_SIZE_MAX must be power-of-two size, otherwise
* iwl_queue_inc_wrap and iwl_queue_dec_wrap are broken. */
- BUILD_BUG_ON(TFD_QUEUE_SIZE_MAX & (TFD_QUEUE_SIZE_MAX - 1));
+ BUILD_BUG_ON(!is_power_of_2(TFD_QUEUE_SIZE_MAX));
iwl_queue_init(priv, &txq->q, TFD_QUEUE_SIZE_MAX, slots_num, txq_id);
iwl_hw_tx_queue_init(priv, txq);
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index d60adcb..5f3bcb3 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -50,6 +50,7 @@
#include <linux/firmware.h>
#include <linux/etherdevice.h>
#include <linux/if_arp.h>
+#include <linux/log2.h>
#include <net/ieee80211_radiotap.h>
#include <net/mac80211.h>
@@ -342,7 +343,7 @@ int iwl_tx_queue_init(struct iwl_priv *priv,
/* TFD_QUEUE_SIZE_MAX must be power-of-two size, otherwise
* iwl_queue_inc_wrap and iwl_queue_dec_wrap are broken. */
- BUILD_BUG_ON(TFD_QUEUE_SIZE_MAX & (TFD_QUEUE_SIZE_MAX - 1));
+ BUILD_BUG_ON(!is_power_of_2(TFD_QUEUE_SIZE_MAX));
iwl_queue_init(priv, &txq->q, TFD_QUEUE_SIZE_MAX, slots_num, txq_id);
iwl_hw_tx_queue_init(priv, txq);
diff --git a/drivers/net/wireless/libertas/cmd.c b/drivers/net/wireless/libertas/cmd.c
index 1cbbd96..be5cfd8 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -912,6 +912,10 @@ static int wlan_cmd_set_boot2_ver(wlan_private * priv,
return 0;
}
+/*
+ * Note: NEVER use libertas_queue_cmd() with addtail==0 other than for
+ * the command timer, because it does not account for queued commands.
+ */
void libertas_queue_cmd(wlan_adapter * adapter, struct cmd_ctrl_node *cmdnode, u8 addtail)
{
unsigned long flags;
@@ -941,10 +945,11 @@ void libertas_queue_cmd(wlan_adapter * adapter, struct cmd_ctrl_node *cmdnode, u
spin_lock_irqsave(&adapter->driver_lock, flags);
- if (addtail)
+ if (addtail) {
list_add_tail((struct list_head *)cmdnode,
&adapter->cmdpendingq);
- else
+ adapter->nr_cmd_pending++;
+ } else
list_add((struct list_head *)cmdnode, &adapter->cmdpendingq);
spin_unlock_irqrestore(&adapter->driver_lock, flags);
@@ -1412,7 +1417,6 @@ int libertas_prepare_and_send_command(wlan_private * priv,
cmdnode->cmdwaitqwoken = 0;
libertas_queue_cmd(adapter, cmdnode, 1);
- adapter->nr_cmd_pending++;
wake_up_interruptible(&priv->waitq);
if (wait_option & CMD_OPTION_WAITFORRSP) {
diff --git a/drivers/net/wireless/libertas/if_cs.c b/drivers/net/wireless/libertas/if_cs.c
index 0360cad..ec89dab 100644
--- a/drivers/net/wireless/libertas/if_cs.c
+++ b/drivers/net/wireless/libertas/if_cs.c
@@ -148,11 +148,11 @@ static int if_cs_poll_while_fw_download(struct if_cs_card *card, uint addr, u8 r
{
int i;
- for (i = 0; i < 500; i++) {
+ for (i = 0; i < 1000; i++) {
u8 val = if_cs_read8(card, addr);
if (val == reg)
return i;
- udelay(100);
+ udelay(500);
}
return -ETIME;
}
@@ -878,6 +878,9 @@ static int if_cs_probe(struct pcmcia_device *p_dev)
goto out3;
}
+ /* Clear any interrupt cause that happend while sending
+ * firmware/initializing card */
+ if_cs_write16(card, IF_CS_C_INT_CAUSE, IF_CS_C_IC_MASK);
if_cs_enable_ints(card);
/* And finally bring the card up */
diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index a8e1707..b24425f 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -182,12 +182,14 @@ static int if_sdio_handle_data(struct if_sdio_card *card,
goto out;
}
- skb = dev_alloc_skb(MRVDRV_ETH_RX_PACKET_BUFFER_SIZE);
+ skb = dev_alloc_skb(MRVDRV_ETH_RX_PACKET_BUFFER_SIZE + NET_IP_ALIGN);
if (!skb) {
ret = -ENOMEM;
goto out;
}
+ skb_reserve(skb, NET_IP_ALIGN);
+
data = skb_put(skb, size);
memcpy(data, buffer, size);
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index 4a6a0bd..85ea8a8 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -196,6 +196,14 @@ int rt2x00mac_add_interface(struct ieee80211_hw *hw,
struct rt2x00_dev *rt2x00dev = hw->priv;
struct interface *intf = &rt2x00dev->interface;
+ /* FIXME: Beaconing is broken in rt2x00. */
+ if (conf->type == IEEE80211_IF_TYPE_IBSS ||
+ conf->type == IEEE80211_IF_TYPE_AP) {
+ ERROR(rt2x00dev,
+ "rt2x00 does not support Adhoc or Master mode");
+ return -EOPNOTSUPP;
+ }
+
/*
* Don't allow interfaces to be added while
* either the device has disappeared or when
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* [PATCH] sky2: netpoll on port 0 only
From: Stephen Hemminger @ 2007-11-06 19:45 UTC (permalink / raw)
To: Jeff Garzik, David S. Miller; +Cc: netdev
Netpoll will only work on port 0 because of the restrictive
relationship between NAPI and netpoll.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2007-11-06 09:09:18.000000000 -0800
+++ b/drivers/net/sky2.c 2007-11-06 11:42:48.000000000 -0800
@@ -3995,7 +3995,8 @@ static __devinit struct net_device *sky2
dev->tx_timeout = sky2_tx_timeout;
dev->watchdog_timeo = TX_WATCHDOG;
#ifdef CONFIG_NET_POLL_CONTROLLER
- dev->poll_controller = sky2_netpoll;
+ if (port == 0)
+ dev->poll_controller = sky2_netpoll;
#endif
sky2 = netdev_priv(dev);
^ permalink raw reply
* Re: netfilter: nf_conntrack_ipv4 does not show nf_nat as a user
From: Chuck Ebbert @ 2007-11-06 19:29 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netdev
In-Reply-To: <472FB162.7050507@trash.net>
On 11/05/2007 07:12 PM, Patrick McHardy wrote:
> Chuck Ebbert wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=333481#c3
>>
>> This is netfilter kernel problem. There is a usage count for the
>> conntrack_ipv4
>> module from the nf_nat module, which is not reported by lsmod.
>>
>
> This is "fixed" in the current kernel.
By this hack?
[NETFILTER]: Fix/improve deadlock condition on module removal netfilter
^ permalink raw reply
* Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: Ben Greear @ 2007-11-06 18:56 UTC (permalink / raw)
To: Krzysztof Halasa
Cc: Patrick McHardy, David Miller, djohnson+linux-kernel, jes, mchan,
ram.vepa, linux-kernel, netdev, bguo
In-Reply-To: <m3y7db45ga.fsf@maximus.localdomain>
Krzysztof Halasa wrote:
> Patrick McHardy <kaber@trash.net> writes:
>
>> I think there is one more case that matters, which is briding
>> from a device with VLAN stripping for a VLAN not configured
>> locally. The tag will be stripped and will be lost for forwarded
>> packets.
>
> I think we should drop such packets on RX. Anyway we shouldn't
> forward them.
Bridging eth0 to eth1 should not pay attention to VLAN tags
at all (if the pkt comes in on VLAN 7, it should go out on VLAN 7),
in my opinion. If the NIC is stripping the VLAN header, then this
cannot work unless something re-builds the VLAN header. If the stripped
VLAN header is placed into the skb, then any code that does need to
rebuild it can do so. It may be less efficient, but users can just
not use that NIC hardware for high-end solutions, and at any rate,
less efficient is better than broken.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Scott Wood @ 2007-11-06 18:46 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <1194339117.3467.8.camel@p60635-ste.ids.de>
On Tue, Nov 06, 2007 at 09:51:57AM +0100, Sergej Stepanov wrote:
> The patch updates the booting-without-of.txt-file.
> There is a description for the case
> if mdio data and clock pins are on different processor ports.
> It is a extending for e-mail "[PATCH v3] using mii-bitbang on different processor ports".
>
> Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
> --
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index a96e853..497d8d8 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1956,6 +1956,12 @@ platforms are moved over to use the flattened-device-tree model.
> fsl,mdc-pin = <13>;
> };
>
> + The "reg"-property may have also depending on board design
> + the following form:
> + reg = <10d40 14 10d60 14>;
> + In that case the pin for mdio data controlling is on the port C,
> + and the pin for mdio clock controlling is on the port D.
It'd be better to explicitly say that the first resource is mdio, and the
second resource is mdc, rather than require the reader to know/look up which
corresponds to 10d40 and which to 10d60.
-Scott
^ permalink raw reply
* RE: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: Dave Johnson @ 2007-11-06 18:34 UTC (permalink / raw)
To: Ramkrishna Vepa; +Cc: David Miller, linux-kernel, netdev, bguo
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77027E9E9E@nekter>
Ramkrishna Vepa writes:
> Dave,
>
> If you can remove the patch for the s2io driver, we can submit a patch
> that can dynamically program Xframe to strip or not strip the vlan tag
> based on whether the vlan group is not NULL or NULL respectively. For
> this, we have to modify the initialization as well as the vlan
> registration.
Sure, not having this hardware I didn't want to attempt a complicated
change. I'll let you take care of this.
--
Dave Johnson
Starent Networks
^ permalink raw reply
* RE: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: Ramkrishna Vepa @ 2007-11-06 18:28 UTC (permalink / raw)
To: Dave Johnson, David Miller, jes, mchan, ram.vepa, <linux-ke
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77027E9D5E@nekter>
Dave,
If you can remove the patch for the s2io driver, we can submit a patch
that can dynamically program Xframe to strip or not strip the vlan tag
based on whether the vlan group is not NULL or NULL respectively. For
this, we have to modify the initialization as well as the vlan
registration.
With regards to the question on the Vlan id received not added to the
group, I think we should drop these packets. This change requires
additional changes to support multiple receive rings. But will add it to
the driver on our website, which supports multiple rx rings, tx fifos,
multiqueue etc, and is a very small incremental change.
Thanks,
Ram
> -----Original Message-----
> From: Ramkrishna Vepa [mailto:Ramkrishna.Vepa@neterion.com]
> Sent: Monday, November 05, 2007 6:40 PM
> To: Dave Johnson; David Miller; jes@trained-monkey.org;
> mchan@broadcom.com; ram.vepa@neterion.com;
linux-kernel@vger.kernel.org;
> netdev@vger.kernel.org; bguo@sw.starentnetworks.com
> Subject: RE: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of
> keeping it
>
> The Xframe (S2io) adapter can be programmed dynamically to either,
> always strip the vlan tag or not. In this case, if the vlan group is
> NULL, it can be programmed at run time to NOT strip the vlan tag.
>
> When a packet with a Vlan id is received that is not added to the
group,
> should it be dropped or indicated up? Either can be handled by the
> hardware. The vlan tag in this particular case will be stripped as the
> vlan group is not NULL.
>
> Ram
>
> > -----Original Message-----
> > From: Dave Johnson
> [mailto:djohnson+linux-kernel@sw.starentnetworks.com]
> > Sent: Monday, November 05, 2007 9:47 AM
> > To: David Miller; jes@trained-monkey.org; mchan@broadcom.com;
> > ram.vepa@neterion.com; linux-kernel@vger.kernel.org;
> > netdev@vger.kernel.org; bguo@sw.starentnetworks.com
> > Subject: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of
> keeping
> > it
> >
> >
> > This patch changes the following drivers to use vlan_hwaccel_rx()
> > and/or vlan_hwaccel_receive_skb() with a NULL vlan group if needed
as
> > they are not setup to dynamically enable/disable vlan removal in
> > their MAC based on the vlan group:
> >
> > drivers/net/tg3.c Tested on BCM5704, looks good
> > drivers/net/bnx2.c Tested on BCM5708, looks good
> > drivers/net/acenic.c Not tested, I don't have one of these
> > drivers/net/s2io.c Not tested, I don't have one of these
> >
> > In addition, these drivers might also need changes, but should
> > probably be done by the maintainer as it's not clear exactly what
> > change is needed:
> >
> > drivers/net/amd8111e.c
> > drivers/net/cxgb3/*
> >
> > Signed-off-by: Dave Johnson <djohnson@sw.starentnetworks.com>
> >
> > ===== drivers/net/acenic.c 1.77 vs edited =====
> > --- 1.77/drivers/net/acenic.c 2007-07-24 16:28:41 -04:00
> > +++ edited/drivers/net/acenic.c 2007-11-03 12:27:40 -04:00
> > @@ -2036,7 +2036,7 @@
> >
> > /* send it up */
> > #if ACENIC_DO_VLAN
> > - if (ap->vlgrp && (bd_flags & BD_FLG_VLAN_TAG)) {
> > + if (bd_flags & BD_FLG_VLAN_TAG) {
> > vlan_hwaccel_rx(skb, ap->vlgrp, retdesc->vlan);
> > } else
> > #endif
> > ===== drivers/net/bnx2.c 1.135 vs edited =====
> > --- 1.135/drivers/net/bnx2.c 2007-09-20 15:14:21 -04:00
> > +++ edited/drivers/net/bnx2.c 2007-11-05 09:34:26 -05:00
> > @@ -2493,7 +2493,8 @@
> > }
> >
> > #ifdef BCM_VLAN
> > - if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) && (bp->vlgrp
> != 0))
> > {
> > + if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) &&
> > + (bp->vlgrp || (bp->flags & ASF_ENABLE_FLAG))) {
> > vlan_hwaccel_receive_skb(skb, bp->vlgrp,
> > rx_hdr->l2_fhdr_vlan_tag);
> > }
> > ===== drivers/net/s2io.c 1.124 vs edited =====
> > --- 1.124/drivers/net/s2io.c 2007-08-03 18:10:44 -04:00
> > +++ edited/drivers/net/s2io.c 2007-11-03 12:29:09 -04:00
> > @@ -6834,8 +6834,7 @@
> > sp->mac_control.stats_info->sw_stat.mem_freed += skb->truesize;
> > if (!sp->lro) {
> > skb->protocol = eth_type_trans(skb, dev);
> > - if ((sp->vlgrp && RXD_GET_VLAN_TAG(rxdp->Control_2) &&
> > - vlan_strip_flag)) {
> > + if (RXD_GET_VLAN_TAG(rxdp->Control_2) &&
> vlan_strip_flag) {
> > /* Queueing the vlan frame to the upper layer */
> > if (napi)
> > vlan_hwaccel_receive_skb(skb, sp->vlgrp,
> > ===== drivers/net/tg3.c 1.523 vs edited =====
> > --- 1.523/drivers/net/tg3.c 2007-09-11 04:28:44 -04:00
> > +++ edited/drivers/net/tg3.c 2007-11-05 09:38:33 -05:00
> > @@ -3417,7 +3417,7 @@
> >
> > skb->protocol = eth_type_trans(skb, tp->dev);
> > #if TG3_VLAN_TAG_USED
> > - if (tp->vlgrp != NULL &&
> > + if ((tp->vlgrp || (tp->tg3_flags & TG3_FLAG_ENABLE_ASF))
> &&
> > desc->type_flags & RXD_FLAG_VLAN) {
> > tg3_vlan_rx(tp, skb,
> > desc->err_vlan & RXD_VLAN_MASK);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox