* Re: [PATCH][TG3]Some cleanups
From: Michael Chan @ 2007-10-02 23:33 UTC (permalink / raw)
To: hadi; +Cc: Matt Carlson, netdev
In-Reply-To: <1191328627.4353.15.camel@localhost>
On Tue, 2007-10-02 at 08:37 -0400, jamal wrote:
> The simplest solution seems to me to modify the definition of
> TG3_SKB_CB
> as i did for e1000 from:
> (struct tg3_tx_cbdata *)&((__skb)->cb[0])
> to:
> (struct tg3_tx_cbdata *)&((__skb)->cb[8])
>
> that way the vlan tags are always present and no need to recreate
> them.
> What do you think?
Seems ok to me. I think we should make it more clear that we're
skipping over the VLAN tag:
(struct tg3_tx_cbdata *)&((__skb)->cb[sizeof(struct vlan_skb_tx_cookie)])
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 22:36 UTC (permalink / raw)
To: David Miller; +Cc: rick.jones2, lm, torvalds, herbert, wscott, netdev
In-Reply-To: <20071002.153216.82129058.davem@davemloft.net>
On Tue, Oct 02, 2007 at 03:32:16PM -0700, David Miller wrote:
> I'm starting to have a theory about what the bad case might
> be.
>
> A strong sender going to an even stronger receiver which can
> pull out packets into the process as fast as they arrive.
> This might be part of what keeps the receive window from
> growing.
I can back you up on that. When I straced the receiving side that goes
slowly, all the reads were short, like 1-2K. The way that works the
reads were a lot larger as I recall.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address
From: David Stevens @ 2007-10-02 22:41 UTC (permalink / raw)
To: Brian Haley
Cc: David Miller, netdev@vger.kernel.org, netdev-owner,
YOSHIFUJI Hideaki
In-Reply-To: <4702B2C0.2070004@hp.com>
Brian,
I don't think a few instructions is a performance issue in the
redirect
paths (it'd be pretty broken if you're getting or generating lots of
them), but I
know there are lots of other checks similar to that that will break with
new
attributes, so doing that as a general clean-up separately is ok with me,
too.
With the error message changes, you can add:
Acked-by: David L Stevens <dlstevens@us.ibm.com>
FWIW. :-)
+-DLS
^ permalink raw reply
* Re: tcp bw in 2.6
From: Rick Jones @ 2007-10-02 22:59 UTC (permalink / raw)
To: Larry McVoy; +Cc: David Miller, torvalds, herbert, wscott, netdev
In-Reply-To: <20071002223644.GA14331@bitmover.com>
Larry McVoy wrote:
> On Tue, Oct 02, 2007 at 03:32:16PM -0700, David Miller wrote:
>
>>I'm starting to have a theory about what the bad case might
>>be.
>>
>>A strong sender going to an even stronger receiver which can
>>pull out packets into the process as fast as they arrive.
>>This might be part of what keeps the receive window from
>>growing.
>
>
> I can back you up on that. When I straced the receiving side that goes
> slowly, all the reads were short, like 1-2K. The way that works the
> reads were a lot larger as I recall.
Indeed I was getting more like 8K on each recv() call per netperf's -v 2 stats,
but the system was more than fast enough to stay ahead of the traffic. On the
hunch that it was the interrupt throttling which was keeping the recv's large
rather than the speed of the system(s) I nuked the InterruptThrottleRate to 0
and was able to get between 1900 and 2300 byte recvs on the TCP_STREAM and
TCP_MAERTS tests and still had 940 Mbit/s in each direction.
hpcpc106:~# netperf -H 192.168.7.107 -t TCP_STREAM -v 2 -c -C
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.7.107
(192.168.7.107) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 87380 87380 10.02 940.95 10.75 21.65 3.743 7.540
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 1.179e+09 87386.29 13491 1965.77 599729
Maximum
Segment
Size (bytes)
1448
hpcpc106:~# netperf -H 192.168.7.107 -t TCP_MAERTS -v 2 -c -C
TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.7.107
(192.168.7.107) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 87380 87380 10.02 940.82 20.44 10.61 7.117 3.696
Alignment Offset Bytes Bytes Recvs Bytes Sends
Local Remote Local Remote Xfered Per Per
Recv Send Recv Send Recv (avg) Send (avg)
8 8 0 0 1.178e+09 2352.26 500931 87380.00 13485
Maximum
Segment
Size (bytes)
1448
the systems above had four 1.6 GHz cores, netperf reports CPU as 0 to 100%
regardless of core count.
and then my systems with the 3.0 GHz cores:
[root@s9 netperf2_trunk]# netperf -H sweb20 -v 2 -t TCP_STREAM -c -C
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to sweb20.cup.hp.com
(16.89.133.20) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.03 941.37 6.40 13.26 2.229 4.615
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 1.18e+09 16384.06 72035 1453.85 811793
Maximum
Segment
Size (bytes)
1448
[root@s9 netperf2_trunk]# netperf -H sweb20 -v 2 -t TCP_MAERTS -c -C
TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to sweb20.cup.hp.com
(16.89.133.20) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.03 941.35 12.13 5.80 4.221 2.018
Alignment Offset Bytes Bytes Recvs Bytes Sends
Local Remote Local Remote Xfered Per Per
Recv Send Recv Send Recv (avg) Send (avg)
8 8 0 0 1.181e+09 1452.38 812953 16384.00 72065
Maximum
Segment
Size (bytes)
1448
rick jones
^ permalink raw reply
* [PATCH 2.6.24 1/3][BNX2]: Add missing napi_disable() in bnx2_close().
From: Michael Chan @ 2007-10-03 0:23 UTC (permalink / raw)
To: davem; +Cc: netdev
[BNX2]: Add missing napi_disable() in bnx2_close().
bnx2_close() -> bnx2_netif_stop() will not call napi_disable() because
the netif_state is not running in bnx2_close(). To avoid confusion,
we change it to disable interrupt and napi directly in bnx2_close().
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index cd5f1b7..4887c31 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -5212,8 +5212,8 @@ bnx2_close(struct net_device *dev)
while (bp->in_reset_task)
msleep(1);
- /* This does napi_disable() for us. */
- bnx2_netif_stop(bp);
+ bnx2_disable_int_sync(bp);
+ napi_disable(&bp->napi);
del_timer_sync(&bp->timer);
if (bp->flags & NO_WOL_FLAG)
reset_code = BNX2_DRV_MSG_CODE_UNLOAD_LNK_DN;
^ permalink raw reply related
* [PATCH 2.6.24 2/3][BNX2]: Optimize firmware loading.
From: Michael Chan @ 2007-10-03 0:23 UTC (permalink / raw)
To: davem; +Cc: netdev, vda.linux
[BNX2]: Optimize firmware loading.
This is a follow up to the patches from Denys Vlasenkos
<vda.linux@googlemail.com> to further optimize firmware loading.
1. In bnx2_init_cpus(), we allocate memory for decompression once
and use it repeatedly instead of doing this for every firmware image.
2. We eliminate the BSS and SBSS firmware sections in bnx2_fw*.h since
these are always zeros.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 4887c31..c50e4c8 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -2810,21 +2810,16 @@ load_cpu_fw(struct bnx2 *bp, struct cpu_reg *cpu_reg, struct fw_info *fw)
/* Load the Text area. */
offset = cpu_reg->spad_base + (fw->text_addr - cpu_reg->mips_view_base);
if (fw->gz_text) {
- u32 *text;
int j;
- text = vmalloc(FW_BUF_SIZE);
- if (!text)
- return -ENOMEM;
- rc = zlib_inflate_blob(text, FW_BUF_SIZE, fw->gz_text, fw->gz_text_len);
- if (rc < 0) {
- vfree(text);
+ rc = zlib_inflate_blob(fw->text, FW_BUF_SIZE, fw->gz_text,
+ fw->gz_text_len);
+ if (rc < 0)
return rc;
- }
+
for (j = 0; j < (fw->text_len / 4); j++, offset += 4) {
- REG_WR_IND(bp, offset, cpu_to_le32(text[j]));
+ REG_WR_IND(bp, offset, cpu_to_le32(fw->text[j]));
}
- vfree(text);
}
/* Load the Data area. */
@@ -2839,21 +2834,21 @@ load_cpu_fw(struct bnx2 *bp, struct cpu_reg *cpu_reg, struct fw_info *fw)
/* Load the SBSS area. */
offset = cpu_reg->spad_base + (fw->sbss_addr - cpu_reg->mips_view_base);
- if (fw->sbss) {
+ if (fw->sbss_len) {
int j;
for (j = 0; j < (fw->sbss_len / 4); j++, offset += 4) {
- REG_WR_IND(bp, offset, fw->sbss[j]);
+ REG_WR_IND(bp, offset, 0);
}
}
/* Load the BSS area. */
offset = cpu_reg->spad_base + (fw->bss_addr - cpu_reg->mips_view_base);
- if (fw->bss) {
+ if (fw->bss_len) {
int j;
for (j = 0; j < (fw->bss_len/4); j++, offset += 4) {
- REG_WR_IND(bp, offset, fw->bss[j]);
+ REG_WR_IND(bp, offset, 0);
}
}
@@ -2894,19 +2889,16 @@ bnx2_init_cpus(struct bnx2 *bp)
if (!text)
return -ENOMEM;
rc = zlib_inflate_blob(text, FW_BUF_SIZE, bnx2_rv2p_proc1, sizeof(bnx2_rv2p_proc1));
- if (rc < 0) {
- vfree(text);
+ if (rc < 0)
goto init_cpu_err;
- }
+
load_rv2p_fw(bp, text, rc /* == len */, RV2P_PROC1);
rc = zlib_inflate_blob(text, FW_BUF_SIZE, bnx2_rv2p_proc2, sizeof(bnx2_rv2p_proc2));
- if (rc < 0) {
- vfree(text);
+ if (rc < 0)
goto init_cpu_err;
- }
+
load_rv2p_fw(bp, text, rc /* == len */, RV2P_PROC2);
- vfree(text);
/* Initialize the RX Processor. */
cpu_reg.mode = BNX2_RXP_CPU_MODE;
@@ -2927,6 +2919,7 @@ bnx2_init_cpus(struct bnx2 *bp)
else
fw = &bnx2_rxp_fw_06;
+ fw->text = text;
rc = load_cpu_fw(bp, &cpu_reg, fw);
if (rc)
goto init_cpu_err;
@@ -2950,6 +2943,7 @@ bnx2_init_cpus(struct bnx2 *bp)
else
fw = &bnx2_txp_fw_06;
+ fw->text = text;
rc = load_cpu_fw(bp, &cpu_reg, fw);
if (rc)
goto init_cpu_err;
@@ -2973,6 +2967,7 @@ bnx2_init_cpus(struct bnx2 *bp)
else
fw = &bnx2_tpat_fw_06;
+ fw->text = text;
rc = load_cpu_fw(bp, &cpu_reg, fw);
if (rc)
goto init_cpu_err;
@@ -2996,6 +2991,7 @@ bnx2_init_cpus(struct bnx2 *bp)
else
fw = &bnx2_com_fw_06;
+ fw->text = text;
rc = load_cpu_fw(bp, &cpu_reg, fw);
if (rc)
goto init_cpu_err;
@@ -3017,11 +3013,13 @@ bnx2_init_cpus(struct bnx2 *bp)
if (CHIP_NUM(bp) == CHIP_NUM_5709) {
fw = &bnx2_cp_fw_09;
+ fw->text = text;
rc = load_cpu_fw(bp, &cpu_reg, fw);
if (rc)
goto init_cpu_err;
}
init_cpu_err:
+ vfree(text);
return rc;
}
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index a717459..56c190f 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6738,7 +6738,7 @@ struct fw_info {
const u32 text_addr;
const u32 text_len;
const u32 text_index;
-/* u32 *text;*/
+ u32 *text;
u8 *gz_text;
const u32 gz_text_len;
@@ -6752,13 +6752,11 @@ struct fw_info {
const u32 sbss_addr;
const u32 sbss_len;
const u32 sbss_index;
- const u32 *sbss;
/* BSS section. */
const u32 bss_addr;
const u32 bss_len;
const u32 bss_index;
- const u32 *bss;
/* Read-only section. */
const u32 rodata_addr;
diff --git a/drivers/net/bnx2_fw.h b/drivers/net/bnx2_fw.h
index 30f2f40..a6d7824 100644
--- a/drivers/net/bnx2_fw.h
+++ b/drivers/net/bnx2_fw.h
@@ -1048,8 +1048,6 @@ static const u32 bnx2_COM_b06FwRodata[(0x88/4) + 1] = {
0x08002bd8, 0x08002c08, 0x08002c38, 0x00000000, 0x080060cc, 0x080060cc,
0x080060cc, 0x080060cc, 0x080060cc, 0x08006100, 0x08006100, 0x08006140,
0x0800614c, 0x0800614c, 0x080060cc, 0x00000000, 0x00000000 };
-static const u32 bnx2_COM_b06FwBss[(0x88/4) + 1] = { 0x0 };
-static const u32 bnx2_COM_b06FwSbss[(0x60/4) + 1] = { 0x0 };
static struct fw_info bnx2_com_fw_06 = {
.ver_major = 0x3,
@@ -1072,12 +1070,10 @@ static struct fw_info bnx2_com_fw_06 = {
.sbss_addr = 0x08007e00,
.sbss_len = 0x60,
.sbss_index = 0x0,
- .sbss = bnx2_COM_b06FwSbss,
.bss_addr = 0x08007e60,
.bss_len = 0x88,
.bss_index = 0x0,
- .bss = bnx2_COM_b06FwBss,
.rodata_addr = 0x08007d58,
.rodata_len = 0x88,
@@ -1762,9 +1758,6 @@ static u32 bnx2_RXP_b06FwRodata[(0x278/4) + 1] = {
0x08006030, 0x08006030, 0x08006018, 0x08006030, 0x08006030, 0x08006030,
0x08006024, 0x00000000, 0x00000000 };
-static u32 bnx2_RXP_b06FwBss[(0x13dc/4) + 1] = { 0x0 };
-static u32 bnx2_RXP_b06FwSbss[(0x2c/4) + 1] = { 0x0 };
-
static struct fw_info bnx2_rxp_fw_06 = {
.ver_major = 0x2,
.ver_minor = 0x8,
@@ -1786,12 +1779,10 @@ static struct fw_info bnx2_rxp_fw_06 = {
.sbss_addr = 0x080069c0,
.sbss_len = 0x2c,
.sbss_index = 0x0,
- .sbss = bnx2_RXP_b06FwSbss,
.bss_addr = 0x080069f0,
.bss_len = 0x13dc,
.bss_index = 0x0,
- .bss = bnx2_RXP_b06FwBss,
.rodata_addr = 0x08006728,
.rodata_len = 0x278,
@@ -2257,8 +2248,6 @@ static u8 bnx2_TPAT_b06FwText[] = {
static u32 bnx2_TPAT_b06FwData[(0x0/4) + 1] = { 0x0 };
static u32 bnx2_TPAT_b06FwRodata[(0x0/4) + 1] = { 0x0 };
-static u32 bnx2_TPAT_b06FwBss[(0x250/4) + 1] = { 0x0 };
-static u32 bnx2_TPAT_b06FwSbss[(0x34/4) + 1] = { 0x0 };
static struct fw_info bnx2_tpat_fw_06 = {
.ver_major = 0x1,
@@ -2281,12 +2270,10 @@ static struct fw_info bnx2_tpat_fw_06 = {
.sbss_addr = 0x08001a60,
.sbss_len = 0x34,
.sbss_index = 0x0,
- .sbss = bnx2_TPAT_b06FwSbss,
.bss_addr = 0x08001aa0,
.bss_len = 0x250,
.bss_index = 0x0,
- .bss = bnx2_TPAT_b06FwBss,
.rodata_addr = 0x00000000,
.rodata_len = 0x0,
@@ -2714,8 +2701,6 @@ static u8 bnx2_TXP_b06FwText[] = {
static u32 bnx2_TXP_b06FwData[(0x0/4) + 1] = { 0x0 };
static u32 bnx2_TXP_b06FwRodata[(0x0/4) + 1] = { 0x0 };
-static u32 bnx2_TXP_b06FwBss[(0x1c4/4) + 1] = { 0x0 };
-static u32 bnx2_TXP_b06FwSbss[(0x38/4) + 1] = { 0x0 };
static struct fw_info bnx2_txp_fw_06 = {
.ver_major = 0x1,
@@ -2738,12 +2723,10 @@ static struct fw_info bnx2_txp_fw_06 = {
.sbss_addr = 0x08005760,
.sbss_len = 0x38,
.sbss_index = 0x0,
- .sbss = bnx2_TXP_b06FwSbss,
.bss_addr = 0x080057a0,
.bss_len = 0x1c4,
.bss_index = 0x0,
- .bss = bnx2_TXP_b06FwBss,
.rodata_addr = 0x00000000,
.rodata_len = 0x0,
diff --git a/drivers/net/bnx2_fw2.h b/drivers/net/bnx2_fw2.h
index 74f985d..5bd52be 100644
--- a/drivers/net/bnx2_fw2.h
+++ b/drivers/net/bnx2_fw2.h
@@ -1046,8 +1046,6 @@ static const u32 bnx2_COM_b09FwRodata[(0x88/4) + 1] = {
0x08002b3c, 0x08002b6c, 0x08002b9c, 0x00000000, 0x0800604c, 0x0800604c,
0x0800604c, 0x0800604c, 0x0800604c, 0x08006078, 0x08006078, 0x080060b8,
0x080060c4, 0x080060c4, 0x0800604c, 0x00000000, 0x00000000 };
-static const u32 bnx2_COM_b09FwBss[(0x88/4) + 1] = { 0x0 };
-static const u32 bnx2_COM_b09FwSbss[(0x60/4) + 1] = { 0x0 };
static struct fw_info bnx2_com_fw_09 = {
.ver_major = 0x3,
@@ -1070,12 +1068,10 @@ static struct fw_info bnx2_com_fw_09 = {
.sbss_addr = 0x08007e60,
.sbss_len = 0x60,
.sbss_index = 0x0,
- .sbss = bnx2_COM_b09FwSbss,
.bss_addr = 0x08007ec0,
.bss_len = 0x88,
.bss_index = 0x0,
- .bss = bnx2_COM_b09FwBss,
.rodata_addr = 0x08007dc0,
.rodata_len = 0x88,
@@ -2243,8 +2239,6 @@ static const u32 bnx2_CP_b09FwRodata[(0x118/4) + 1] = {
0x080032e8, 0x08003300, 0x08003320, 0x08003358, 0x08003338, 0x08003338,
0x080050d4, 0x080050d4, 0x080050d4, 0x080050d4, 0x080050d4, 0x080050fc,
0x080050fc, 0x08005124, 0x08005174, 0x08005144, 0x00000000 };
-static const u32 bnx2_CP_b09FwBss[(0x3b0/4) + 1] = { 0x0 };
-static const u32 bnx2_CP_b09FwSbss[(0xa1/4) + 1] = { 0x0 };
static struct fw_info bnx2_cp_fw_09 = {
.ver_major = 0x3,
@@ -2267,12 +2261,10 @@ static struct fw_info bnx2_cp_fw_09 = {
.sbss_addr = 0x08007024,
.sbss_len = 0xa1,
.sbss_index = 0x0,
- .sbss = bnx2_CP_b09FwSbss,
.bss_addr = 0x080070d0,
.bss_len = 0x3b0,
.bss_index = 0x0,
- .bss = bnx2_CP_b09FwBss,
.rodata_addr = 0x08006ee8,
.rodata_len = 0x118,
@@ -2953,8 +2945,6 @@ static const u32 bnx2_RXP_b09FwRodata[(0x278/4) + 1] = {
0x08006058, 0x08006070, 0x08006070, 0x08006070, 0x08006058, 0x08006070,
0x08006070, 0x08006070, 0x08006058, 0x08006070, 0x08006070, 0x08006070,
0x08006064, 0x00000000, 0x00000000 };
-static const u32 bnx2_RXP_b09FwBss[(0x13dc/4) + 1] = { 0x0 };
-static const u32 bnx2_RXP_b09FwSbss[(0x20/4) + 1] = { 0x0 };
static struct fw_info bnx2_rxp_fw_09 = {
.ver_major = 0x3,
@@ -2977,12 +2967,10 @@ static struct fw_info bnx2_rxp_fw_09 = {
.sbss_addr = 0x08006a00,
.sbss_len = 0x20,
.sbss_index = 0x0,
- .sbss = bnx2_RXP_b09FwSbss,
.bss_addr = 0x08006a20,
.bss_len = 0x13dc,
.bss_index = 0x0,
- .bss = bnx2_RXP_b09FwBss,
.rodata_addr = 0x08006768,
.rodata_len = 0x278,
@@ -3245,8 +3233,6 @@ static u8 bnx2_TPAT_b09FwText[] = {
static const u32 bnx2_TPAT_b09FwData[(0x0/4) + 1] = { 0x0 };
static const u32 bnx2_TPAT_b09FwRodata[(0x0/4) + 1] = { 0x0 };
-static const u32 bnx2_TPAT_b09FwBss[(0x850/4) + 1] = { 0x0 };
-static const u32 bnx2_TPAT_b09FwSbss[(0x2c/4) + 1] = { 0x0 };
static struct fw_info bnx2_tpat_fw_09 = {
.ver_major = 0x3,
@@ -3269,12 +3255,10 @@ static struct fw_info bnx2_tpat_fw_09 = {
.sbss_addr = 0x08002088,
.sbss_len = 0x2c,
.sbss_index = 0x0,
- .sbss = bnx2_TPAT_b09FwSbss,
.bss_addr = 0x080020c0,
.bss_len = 0x850,
.bss_index = 0x0,
- .bss = bnx2_TPAT_b09FwBss,
.rodata_addr = 0x00000000,
.rodata_len = 0x0,
@@ -4060,8 +4044,6 @@ static const u32 bnx2_TXP_b09FwRodata[(0x30/4) + 1] = {
0x08004060, 0x0800408c, 0x080040d4, 0x080040d4, 0x08003f60, 0x08003f8c,
0x08003f8c, 0x080040d4, 0x080040d4, 0x080040d4, 0x08003ff4, 0x00000000,
0x00000000 };
-static const u32 bnx2_TXP_b09FwBss[(0xa20/4) + 1] = { 0x0 };
-static const u32 bnx2_TXP_b09FwSbss[(0x8c/4) + 1] = { 0x0 };
static struct fw_info bnx2_txp_fw_09 = {
.ver_major = 0x3,
@@ -4084,12 +4066,10 @@ static struct fw_info bnx2_txp_fw_09 = {
.sbss_addr = 0x08004750,
.sbss_len = 0x8c,
.sbss_index = 0x0,
- .sbss = bnx2_TXP_b09FwSbss,
.bss_addr = 0x080047e0,
.bss_len = 0xa20,
.bss_index = 0x0,
- .bss = bnx2_TXP_b09FwBss,
.rodata_addr = 0x08004638,
.rodata_len = 0x30,
^ permalink raw reply related
* [PATCH 2.6.24 3/3][BNX2]: Update version to 1.6.6.
From: Michael Chan @ 2007-10-03 0:24 UTC (permalink / raw)
To: davem; +Cc: netdev
[BNX2]: Update version to 1.6.6.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index c50e4c8..db14f35 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -56,8 +56,8 @@
#define DRV_MODULE_NAME "bnx2"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "1.6.5"
-#define DRV_MODULE_RELDATE "September 20, 2007"
+#define DRV_MODULE_VERSION "1.6.6"
+#define DRV_MODULE_RELDATE "October 2, 2007"
#define RUN_AT(x) (jiffies + (x))
^ permalink raw reply related
* Re: [PATCH 2.6.24 1/3][BNX2]: Add missing napi_disable() in bnx2_close().
From: David Miller @ 2007-10-02 23:27 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1191370989.5961.31.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 02 Oct 2007 17:23:09 -0700
> [BNX2]: Add missing napi_disable() in bnx2_close().
>
> bnx2_close() -> bnx2_netif_stop() will not call napi_disable() because
> the netif_state is not running in bnx2_close(). To avoid confusion,
> we change it to disable interrupt and napi directly in bnx2_close().
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied to net-2.6.24
^ permalink raw reply
* Re: [PATCH 2.6.24 2/3][BNX2]: Optimize firmware loading.
From: David Miller @ 2007-10-02 23:27 UTC (permalink / raw)
To: mchan; +Cc: netdev, vda.linux
In-Reply-To: <1191371023.5961.32.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 02 Oct 2007 17:23:43 -0700
> [BNX2]: Optimize firmware loading.
>
> This is a follow up to the patches from Denys Vlasenkos
> <vda.linux@googlemail.com> to further optimize firmware loading.
>
> 1. In bnx2_init_cpus(), we allocate memory for decompression once
> and use it repeatedly instead of doing this for every firmware image.
>
> 2. We eliminate the BSS and SBSS firmware sections in bnx2_fw*.h since
> these are always zeros.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks for following up on this Michael.
^ permalink raw reply
* Re: [PATCH 2.6.24 3/3][BNX2]: Update version to 1.6.6.
From: David Miller @ 2007-10-02 23:28 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1191371046.5961.33.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 02 Oct 2007 17:24:06 -0700
> [BNX2]: Update version to 1.6.6.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Also applied to net-2.6.24, thanks!
^ permalink raw reply
* Re: [PATCH 2.6.24 3/3][BNX2]: Update version to 1.6.6.
From: Jeff Garzik @ 2007-10-02 23:29 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev
In-Reply-To: <1191371046.5961.33.camel@dell>
Michael Chan wrote:
> [BNX2]: Update version to 1.6.6.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
ACK patches 1-3
^ permalink raw reply
* Re: [git patches] net driver updates
From: David Miller @ 2007-10-02 23:38 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel
In-Reply-To: <20071002174150.GA29780@havoc.gtf.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Tue, 2 Oct 2007 13:41:50 -0400
> Please pull from the 'upstream' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream
Pulled and pushed back out to net-2.6.24, thanks Jeff!
^ permalink raw reply
* Kernel 2.4 vs 2.6 Traffic Controller Performance
From: Sonny @ 2007-10-03 0:30 UTC (permalink / raw)
To: netdev
Hello
I hope this is the right place to ask this.Does any know if there is a
substantial difference in the performance of the traffic controller
between kernel 2.4 and 2.6. We tested it using 1 iperf server and use
250 and 500 clients, altering the burst. We use the top command to
check the idle time of our router to see this. The results we got from
the 2.4 kernel shows around 65-70% idle time while the 2.6 shows
60-65% idle time. We tried to use MRTG and we're not getting any
results either. We want to know if we could improve the bandwidth by
upgrading the kernel, else we would have to get a new bandwidth
manager. Could anyone have the similar test regarding this or suggest
a better way to do this. Thanks in advance.
^ permalink raw reply
* [PATCH] baycom epp header ops
From: Stephen Hemminger @ 2007-10-03 0:41 UTC (permalink / raw)
To: akpm; +Cc: davem, netdev, akpm
In-Reply-To: <200710022104.l92L4cuE022227@imap1.linux-foundation.org>
Update baycom epp driver for new header ops in net-2.6.24
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
---
drivers/net/hamradio/baycom_epp.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hamradio/baycom_epp.c b/drivers/net/hamradio/baycom_epp.c
index 355c6cf..1a5a75a 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -1159,8 +1159,7 @@ static void baycom_probe(struct net_device *dev)
/* Fill in the fields of the device structure */
bc->skb = NULL;
- dev->hard_header = ax25_hard_header;
- dev->rebuild_header = ax25_rebuild_header;
+ dev->header_ops = &ax25_header_ops;
dev->set_mac_address = baycom_set_mac_address;
dev->type = ARPHRD_AX25; /* AF_AX25 device */
--
1.5.2.5
^ permalink raw reply related
* [PATCH] sky2: jumbo frame regression fix
From: Stephen Hemminger @ 2007-10-03 1:02 UTC (permalink / raw)
To: pomac, Jeff Garzik; +Cc: Linux-kernel, netdev
In-Reply-To: <1191372129.26233.12.camel@localhost>
Remove unneeded check that caused problems with jumbo frame sizes.
The check was recently added and is wrong.
When using jumbo frames the sky2 driver does fragmentation, so
rx_data_size is less than mtu.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2007-10-02 17:56:31.000000000 -0700
+++ b/drivers/net/sky2.c 2007-10-02 17:58:56.000000000 -0700
@@ -2163,9 +2163,6 @@ static struct sk_buff *sky2_receive(stru
sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
prefetch(sky2->rx_ring + sky2->rx_next);
- if (length < ETH_ZLEN || length > sky2->rx_data_size)
- goto len_error;
-
/* This chip has hardware problems that generates bogus status.
* So do only marginal checking and expect higher level protocols
* to handle crap frames.
^ permalink raw reply
* Re: [PATCH] sky2: jumbo frame regression fix
From: Jeff Garzik @ 2007-10-03 1:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: pomac, Linux-kernel, netdev
In-Reply-To: <20071002180209.47c350a3@freepuppy.rosehill>
Stephen Hemminger wrote:
> Remove unneeded check that caused problems with jumbo frame sizes.
> The check was recently added and is wrong.
> When using jumbo frames the sky2 driver does fragmentation, so
> rx_data_size is less than mtu.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>
> --- a/drivers/net/sky2.c 2007-10-02 17:56:31.000000000 -0700
> +++ b/drivers/net/sky2.c 2007-10-02 17:58:56.000000000 -0700
> @@ -2163,9 +2163,6 @@ static struct sk_buff *sky2_receive(stru
> sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
> prefetch(sky2->rx_ring + sky2->rx_next);
>
> - if (length < ETH_ZLEN || length > sky2->rx_data_size)
> - goto len_error;
> -
2.6.23? 2.6.24? enquiring minds want to know...
^ permalink raw reply
* Re: [PATCH] sky2: jumbo frame regression fix
From: Ian Kumlien @ 2007-10-03 1:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, Linux-kernel, netdev
In-Reply-To: <20071002180209.47c350a3@freepuppy.rosehill>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
> Remove unneeded check that caused problems with jumbo frame sizes.
> The check was recently added and is wrong.
> When using jumbo frames the sky2 driver does fragmentation, so
> rx_data_size is less than mtu.
Confirmed working.
Now running with 9k mtu with no errors, =)
It also seems that the FIFO bug was the one that affected me before,
damn odd race that one.
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Tested-by: Ian Kumlien <pomac@vapor.com>
(if that tag exists now)
Btw, Sorry but all mail directly to you will be blocked. I have yet to
fix the relaying properly with isp:s blocking port 25 etc so for some of
you this mail will only show up on the ML.
> --- a/drivers/net/sky2.c 2007-10-02 17:56:31.000000000 -0700
> +++ b/drivers/net/sky2.c 2007-10-02 17:58:56.000000000 -0700
> @@ -2163,9 +2163,6 @@ static struct sk_buff *sky2_receive(stru
> sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
> prefetch(sky2->rx_ring + sky2->rx_next);
>
> - if (length < ETH_ZLEN || length > sky2->rx_data_size)
> - goto len_error;
> -
> /* This chip has hardware problems that generates bogus status.
> * So do only marginal checking and expect higher level protocols
> * to handle crap frames.
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2007-10-03 1:20 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-wireless
The following changes since commit 3146b39c185f8a436d430132457e84fa1d8f8208:
Linus Torvalds (1):
Linux 2.6.23-rc9
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
Joe Perches (1):
bcm43xx: Correct printk with PFX before KERN_
Richard Knutsson (1):
softmac: Fix compiler-warning
drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 2 +-
net/ieee80211/softmac/ieee80211softmac_wx.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index d6d9413..6acfdc4 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -444,7 +444,7 @@ static int bcm43xx_wx_set_xmitpower(struct net_device *net_dev,
u16 maxpower;
if ((data->txpower.flags & IW_TXPOW_TYPE) != IW_TXPOW_DBM) {
- printk(PFX KERN_ERR "TX power not in dBm.\n");
+ printk(KERN_ERR PFX "TX power not in dBm.\n");
return -EOPNOTSUPP;
}
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index 442b987..5742dc8 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -114,7 +114,7 @@ check_assoc_again:
sm->associnfo.associating = 1;
/* queue lower level code to do work (if necessary) */
schedule_delayed_work(&sm->associnfo.work, 0);
-out:
+
mutex_unlock(&sm->associnfo.mutex);
return 0;
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Please pull 'upstream-davem' branch of wireless-2.6
From: John W. Linville @ 2007-10-03 1:25 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 4515 bytes --]
The following changes since commit d3adbde754a9ae7a6f87612055cb20db856f0721:
Ilpo Järvinen (1):
[TCP]: Wrap-safed reordering detection FRTO check
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-davem
Daniel Drake (1):
hostap: set netdev type before registering AP interface
Johannes Berg (9):
mac80211: add "invalid" interface type
mac80211: remove management interface
mac80211: move sta_process rx handler later
mac80211: consolidate decryption more
mac80211: use RX_FLAG_DECRYPTED for sw decrypted as well
mac80211: remove ALG_NONE
mac80211: improve radiotap injection
mac80211: make userspace-mlme a per-interface setting
mac80211: implement cfg80211's change_interface hook
Michael Buesch (9):
rfkill: Add support for an rfkill LED.
rfkill: Add support for hardware-only rfkill buttons
b43: LED triggers support
b43: RF-kill support
b43: Use input-polldev for the rfkill switch
b43: Rewrite pwork locking policy.
mac80211: Check open_count before calling config callback.
mac80211: Add association LED trigger
mac80211: Update beacon_update callback documentation
Tomas Winkler (1):
mac80211: add sta_notify callback
Ulrich Kunitz (1):
zd1211rw: Removed zd_util.c and zd_util.h
Documentation/networking/mac80211-injection.txt | 32 ++-
drivers/net/wireless/adm8211.c | 8 +-
drivers/net/wireless/b43/Kconfig | 12 +
drivers/net/wireless/b43/Makefile | 5 +-
drivers/net/wireless/b43/b43.h | 11 +-
drivers/net/wireless/b43/leds.c | 399 ++++++++++-------------
drivers/net/wireless/b43/leds.h | 63 ++--
drivers/net/wireless/b43/main.c | 205 ++++--------
drivers/net/wireless/b43/phy.c | 13 +-
drivers/net/wireless/b43/phy.h | 2 +-
drivers/net/wireless/b43/rfkill.c | 184 +++++++++++
drivers/net/wireless/b43/rfkill.h | 58 ++++
drivers/net/wireless/hostap/hostap.h | 2 +-
drivers/net/wireless/hostap/hostap_hw.c | 2 +-
drivers/net/wireless/hostap/hostap_main.c | 19 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 4 -
drivers/net/wireless/iwlwifi/iwl4965-base.c | 4 -
drivers/net/wireless/p54common.c | 4 +-
drivers/net/wireless/p54pci.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00.h | 2 +-
drivers/net/wireless/zd1211rw/Makefile | 2 +-
drivers/net/wireless/zd1211rw/zd_chip.c | 1 -
drivers/net/wireless/zd1211rw/zd_mac.c | 4 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 1 -
drivers/net/wireless/zd1211rw/zd_util.c | 82 -----
drivers/net/wireless/zd1211rw/zd_util.h | 29 --
include/linux/rfkill.h | 24 ++
include/net/mac80211.h | 46 +++-
net/mac80211/cfg.c | 75 ++++-
net/mac80211/ieee80211.c | 189 +-----------
net/mac80211/ieee80211_i.h | 17 +-
net/mac80211/ieee80211_iface.c | 68 +----
net/mac80211/ieee80211_ioctl.c | 31 +-
net/mac80211/ieee80211_led.c | 67 +++-
net/mac80211/ieee80211_led.h | 6 +
net/mac80211/ieee80211_rate.c | 3 +-
net/mac80211/ieee80211_rate.h | 2 -
net/mac80211/ieee80211_sta.c | 7 +-
net/mac80211/key.c | 1 -
net/mac80211/rx.c | 122 +++-----
net/mac80211/sta_info.c | 13 +-
net/mac80211/tx.c | 211 ++++++------
net/mac80211/wme.c | 10 +-
net/rfkill/Kconfig | 7 +
net/rfkill/rfkill.c | 49 +++-
45 files changed, 1022 insertions(+), 1078 deletions(-)
create mode 100644 drivers/net/wireless/b43/rfkill.c
create mode 100644 drivers/net/wireless/b43/rfkill.h
delete mode 100644 drivers/net/wireless/zd1211rw/zd_util.c
delete mode 100644 drivers/net/wireless/zd1211rw/zd_util.h
Omnibus patch attached as upstream-davem.patch.bz2
--
John W. Linville
linville@tuxdriver.com
[-- Attachment #2: upstream-davem.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 26503 bytes --]
^ permalink raw reply
* Re: Please pull 'upstream-davem' branch of wireless-2.6
From: John W. Linville @ 2007-10-03 1:45 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071003012552.GE29361-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Of course, these are intended for 2.6.24. Also, I forgot to mention
that the individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem/
I also preserved the net-2.6.24 commit I based from as 'master-davem'
in case you need it for reference.
Hth!
John
On Tue, Oct 02, 2007 at 09:25:52PM -0400, John W. Linville wrote:
> The following changes since commit d3adbde754a9ae7a6f87612055cb20db856f0721:
> Ilpo Järvinen (1):
> [TCP]: Wrap-safed reordering detection FRTO check
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-davem
>
> Daniel Drake (1):
> hostap: set netdev type before registering AP interface
>
> Johannes Berg (9):
> mac80211: add "invalid" interface type
> mac80211: remove management interface
> mac80211: move sta_process rx handler later
> mac80211: consolidate decryption more
> mac80211: use RX_FLAG_DECRYPTED for sw decrypted as well
> mac80211: remove ALG_NONE
> mac80211: improve radiotap injection
> mac80211: make userspace-mlme a per-interface setting
> mac80211: implement cfg80211's change_interface hook
>
> Michael Buesch (9):
> rfkill: Add support for an rfkill LED.
> rfkill: Add support for hardware-only rfkill buttons
> b43: LED triggers support
> b43: RF-kill support
> b43: Use input-polldev for the rfkill switch
> b43: Rewrite pwork locking policy.
> mac80211: Check open_count before calling config callback.
> mac80211: Add association LED trigger
> mac80211: Update beacon_update callback documentation
>
> Tomas Winkler (1):
> mac80211: add sta_notify callback
>
> Ulrich Kunitz (1):
> zd1211rw: Removed zd_util.c and zd_util.h
>
> Documentation/networking/mac80211-injection.txt | 32 ++-
> drivers/net/wireless/adm8211.c | 8 +-
> drivers/net/wireless/b43/Kconfig | 12 +
> drivers/net/wireless/b43/Makefile | 5 +-
> drivers/net/wireless/b43/b43.h | 11 +-
> drivers/net/wireless/b43/leds.c | 399 ++++++++++-------------
> drivers/net/wireless/b43/leds.h | 63 ++--
> drivers/net/wireless/b43/main.c | 205 ++++--------
> drivers/net/wireless/b43/phy.c | 13 +-
> drivers/net/wireless/b43/phy.h | 2 +-
> drivers/net/wireless/b43/rfkill.c | 184 +++++++++++
> drivers/net/wireless/b43/rfkill.h | 58 ++++
> drivers/net/wireless/hostap/hostap.h | 2 +-
> drivers/net/wireless/hostap/hostap_hw.c | 2 +-
> drivers/net/wireless/hostap/hostap_main.c | 19 +-
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 4 -
> drivers/net/wireless/iwlwifi/iwl4965-base.c | 4 -
> drivers/net/wireless/p54common.c | 4 +-
> drivers/net/wireless/p54pci.c | 4 +-
> drivers/net/wireless/rt2x00/rt2x00.h | 2 +-
> drivers/net/wireless/zd1211rw/Makefile | 2 +-
> drivers/net/wireless/zd1211rw/zd_chip.c | 1 -
> drivers/net/wireless/zd1211rw/zd_mac.c | 4 +-
> drivers/net/wireless/zd1211rw/zd_usb.c | 1 -
> drivers/net/wireless/zd1211rw/zd_util.c | 82 -----
> drivers/net/wireless/zd1211rw/zd_util.h | 29 --
> include/linux/rfkill.h | 24 ++
> include/net/mac80211.h | 46 +++-
> net/mac80211/cfg.c | 75 ++++-
> net/mac80211/ieee80211.c | 189 +-----------
> net/mac80211/ieee80211_i.h | 17 +-
> net/mac80211/ieee80211_iface.c | 68 +----
> net/mac80211/ieee80211_ioctl.c | 31 +-
> net/mac80211/ieee80211_led.c | 67 +++-
> net/mac80211/ieee80211_led.h | 6 +
> net/mac80211/ieee80211_rate.c | 3 +-
> net/mac80211/ieee80211_rate.h | 2 -
> net/mac80211/ieee80211_sta.c | 7 +-
> net/mac80211/key.c | 1 -
> net/mac80211/rx.c | 122 +++-----
> net/mac80211/sta_info.c | 13 +-
> net/mac80211/tx.c | 211 ++++++------
> net/mac80211/wme.c | 10 +-
> net/rfkill/Kconfig | 7 +
> net/rfkill/rfkill.c | 49 +++-
> 45 files changed, 1022 insertions(+), 1078 deletions(-)
> create mode 100644 drivers/net/wireless/b43/rfkill.c
> create mode 100644 drivers/net/wireless/b43/rfkill.h
> delete mode 100644 drivers/net/wireless/zd1211rw/zd_util.c
> delete mode 100644 drivers/net/wireless/zd1211rw/zd_util.h
>
> Omnibus patch attached as upstream-davem.patch.bz2
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* Re: [PATCH] baycom epp header ops
From: David Miller @ 2007-10-03 1:48 UTC (permalink / raw)
To: shemminger; +Cc: akpm, netdev
In-Reply-To: <20071002174103.4303b9dc@oldman>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Tue, 2 Oct 2007 17:41:03 -0700
> Update baycom epp driver for new header ops in net-2.6.24
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Applied, thanks Stephen.
^ permalink raw reply
* Re: Please pull 'upstream-davem' branch of wireless-2.6
From: David Miller @ 2007-10-03 2:01 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071003012552.GE29361-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 2 Oct 2007 21:25:52 -0400
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-davem
This doesn't pull cleanly.
Probably you used a recently cloned Linus tree, pulled
net-2.6.24 into that (and resolved the conflicts), and
then put your patches in.
Please don't do it like that, I don't want to pull from
a tree that has linus vs. net-2.6.24 conflict handling
in it. That's why I usually rebase frequently, to minimize
that as much as is humanly possible.
What you can do is figure out what linus's HEAD was at the last rebase
(basically 'origin' or parent of net-2.6.24), clone that then pull in
net-2.6.24, then add your patches.
That way I can always do a clean pull.
My pull from Jeff today was very clean, for example.
I'll add these wireless bits by hand as patches.
Thanks John.
^ permalink raw reply
* Re: [PATCH] sky2: jumbo frame regression fix
From: Stephen Hemminger @ 2007-10-03 4:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: pomac, Linux-kernel, netdev
In-Reply-To: <4702EB4A.4000208@pobox.com>
On Tue, 02 Oct 2007 21:07:22 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:
> Stephen Hemminger wrote:
> > Remove unneeded check that caused problems with jumbo frame sizes.
> > The check was recently added and is wrong.
> > When using jumbo frames the sky2 driver does fragmentation, so
> > rx_data_size is less than mtu.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
> >
> > --- a/drivers/net/sky2.c 2007-10-02 17:56:31.000000000 -0700
> > +++ b/drivers/net/sky2.c 2007-10-02 17:58:56.000000000 -0700
> > @@ -2163,9 +2163,6 @@ static struct sk_buff *sky2_receive(stru
> > sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
> > prefetch(sky2->rx_ring + sky2->rx_next);
> >
> > - if (length < ETH_ZLEN || length > sky2->rx_data_size)
> > - goto len_error;
> > -
>
> 2.6.23? 2.6.24? enquiring minds want to know...
2.6.23, since it is a regression
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH] sky2: jumbo frame regression fix
From: Jeff Garzik @ 2007-10-03 4:58 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: pomac, Linux-kernel, netdev
In-Reply-To: <20071002215316.0faa7676@freepuppy.rosehill>
Stephen Hemminger wrote:
> On Tue, 02 Oct 2007 21:07:22 -0400
> Jeff Garzik <jgarzik@pobox.com> wrote:
>
>> Stephen Hemminger wrote:
>>> Remove unneeded check that caused problems with jumbo frame sizes.
>>> The check was recently added and is wrong.
>>> When using jumbo frames the sky2 driver does fragmentation, so
>>> rx_data_size is less than mtu.
>>>
>>> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>>>
>>> --- a/drivers/net/sky2.c 2007-10-02 17:56:31.000000000 -0700
>>> +++ b/drivers/net/sky2.c 2007-10-02 17:58:56.000000000 -0700
>>> @@ -2163,9 +2163,6 @@ static struct sk_buff *sky2_receive(stru
>>> sky2->rx_next = (sky2->rx_next + 1) % sky2->rx_pending;
>>> prefetch(sky2->rx_ring + sky2->rx_next);
>>>
>>> - if (length < ETH_ZLEN || length > sky2->rx_data_size)
>>> - goto len_error;
>>> -
>> 2.6.23? 2.6.24? enquiring minds want to know...
>
> 2.6.23, since it is a regression
You can have regressions in behavior in net-2.6.24.git, too. _Please_
be specific about where you want your patches to go. Thanks.
Jeff
^ permalink raw reply
* Re: [PATCH] sky2: jumbo frame regression fix
From: Stephen Hemminger @ 2007-10-03 4:59 UTC (permalink / raw)
To: pomac; +Cc: Jeff Garzik, Linux-kernel, netdev
In-Reply-To: <1191375274.26233.17.camel@localhost>
On Wed, 03 Oct 2007 03:34:34 +0200
Ian Kumlien <pomac@vapor.com> wrote:
> On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
> > Remove unneeded check that caused problems with jumbo frame sizes.
> > The check was recently added and is wrong.
> > When using jumbo frames the sky2 driver does fragmentation, so
> > rx_data_size is less than mtu.
>
> Confirmed working.
>
> Now running with 9k mtu with no errors, =)
>
> It also seems that the FIFO bug was the one that affected me before,
> damn odd race that one.
Does the workaround (forced reset work). Ian, you are the first person to
report triggering it. I haven't found a way to make it happen.
What combination of flow control and speeds are you using?
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ 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