* atl1 driver corrupting memory?
From: Chuck Ebbert @ 2007-07-25 18:33 UTC (permalink / raw)
To: Jay Cliburn; +Cc: Netdev
I have a report of random errors when using the atl1 driver
with kernel 2.6.22.1. Could that be a problem fixed by the
recent changes to DMA setup in 2.6.23-rc?
^ permalink raw reply
* 2.6.23-rc1-mm1: net/ipv4/fib_trie.c compile error
From: Adrian Bunk @ 2007-07-25 18:15 UTC (permalink / raw)
To: Andrew Morton, Paul E. McKenney, Ingo Molnar, Josh Triplett
Cc: linux-kernel, netdev
In-Reply-To: <20070725040304.111550f4.akpm@linux-foundation.org>
On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.22-rc6-mm1:
>...
> +immunize-rcu_dereference-against-crazy-compiler-writers.patch
>...
> Misc new patches
>...
This patch causes the following compile error:
<-- snip -->
...
CC net/ipv4/fib_trie.o
/home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm1/net/ipv4/fib_trie.c: In function ‘trie_rebalance’:
/home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm1/net/ipv4/fib_trie.c:969: error: lvalue required as unary ‘&’ operand
/home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm1/net/ipv4/fib_trie.c:971: error: lvalue required as unary ‘&’ operand
/home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm1/net/ipv4/fib_trie.c:977: error: lvalue required as unary ‘&’ operand
/home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm1/net/ipv4/fib_trie.c:980: error: lvalue required as unary ‘&’ operand
...
make[3]: *** [net/ipv4/fib_trie.o] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [RFC 0/1] lro: Generic Large Receive Offload for TCP traffic
From: Andrew Gallatin @ 2007-07-25 17:17 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: netdev, Christoph Raisch, Jan-Bernd Themann, linux-kernel,
linux-ppc, Marcus Eder, Thomas Klein, Stefan Roscher,
David Miller, Jeff Garzik, Evgeniy Polyakov
In-Reply-To: <200707201741.45079.ossthema@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 6259 bytes --]
Hi,
I've ported myri10ge to use the new LRO interface. I have attached a
preliminary patch to myri10ge. I'm very pleased to note that the
performance is on-par with my own LRO used by our out-of-tree driver.
(except when using mixed MTUS, see performance data below).
As I expected, actually porting our driver to use the LRO interface
gave me a far better understanding of the interface, and allowed for
better feedback. I have attached a patch to the LRO code which
addresses some of the issues I mention below.
Please find below a performance summary, as well as my comments
on the LRO code, and patches to myri10ge and inet_lro. Both patches
are Signed-off-by: Andrew J. Gallatin <gallatin@myri.com>
Cheers,
Drew
===================
Performance:
===================
Here is a performance summary taken on my very low-end 2.0GHz AMD
Athlon(tm) 64 X2 Dual Core Processor 3800+ running 2.6.23-rc1 and
receiving a netperf TCP_SENDFILE test from an identical sender (which
was running 2.6.22 and our 1.3.1 "out of tree" driver). The netserver
process was bound to a different core than the interrupt handler. The
data reported is from the median of 5 60 second netperf tests. The
following settings were in /etc/sysctl.conf on both machines:
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.netdev_max_backlog = 2500
net.ipv4.tcp_timestamps = 0
RX Performance for Sender MTU=1500, Receiver MTU=1500 expressed as
"x Gb/s, y %CPU receiver utilization":
rxbuf(1) 1.3.1(2) inet_lro no LRO
----- ------- ------- --------
4K pg 8.9 78% 8.8 77% 3.7 89%
8K pg 9.2 77% 9.1 77% 3.7 89%
16Kpg 9.4 73% 9.4 73% 3.8 89%
32Kpg 9.4 72% 9.4 72% 3.9 89%
skb N/A N/A 5.5 90% 4.1 92%
RX Performance for Sender MTU=1500, Receiver MTU=9000 expressed as
"x Gb/s, y %CPU receiver utilization":
rxbuf(1) 1.3.1(2) inet_lro no LRO
----- ------- ------- --------
4K pg 8.9 78% 7.3 79% 3.7 89%
8K pg 9.2 77% 7.6 79% 3.7 89%
16Kpg 9.4 73% 8.0 78% 3.8 89%
32Kpg 9.4 72% 8.2 79% 3.9 89%
skb N/A N/A 4.9 92% 4.1 92%
RX Performance for Sender MTU=9000, Receiver MTU=9000 expressed as
"x Gb/s, y %CPU receiver utilization":
rxbuf(1) 1.3.1(2) inet_lro no LRO
----- ------- ------- --------
4K pg 9.9 63% 9.6 66% 8.3 71%
8K pg 9.9 60% 9.9 63% 8.4 72%
16Kpg 9.9 55% 9.9 55% 8.7 70%
32Kpg 9.9 53% 9.9 53% 8.9 67%
skb N/A N/A 9.9 68% 8.7 72%
(1) "xK pg" means the driver was configured to adjust the receive page
size using MYRI10GE_ALLOC_ORDER. "skb" means an internal variant
of our driver which receives into skbs rather than pages was used.
(2) "1.3.1" is our latest out of tree driver which uses the myri10ge
specific frags-based LRO code previously submitted and rejected.
===================
Code review / comments:
===================
1) Checksum information for CHECKSUM_COMPLETE drivers.
Our NIC passes partial checksums to our driver. In the current code,
it seems impossible for page based CHECKSUM_COMPLETE drivers to behave
correctly in the case of "rejected" frames. Eg, there is no way
to pass the partial checksum to the LRO module so that it gets
set in the skb header and passed up the stack.
Further, there seems to be no (easy) way to use CHECKSUM_COMPLETE
on an aggregated packet at LRO flush time. By the time a packet
is aggregated, the partial checksum from the first segment is
out of date.
I think it would make sense to require that a CHECKSUM_COMPLETE style
driver verify the checksum in its get_frag_header / get_skb_header
callback. This allows the LRO code to unconditionally set
CHECKSUM_UNNECESSARY.
The attached a patch modifies the code to do this.
2) Non-accelerated VLAN tags
Our firmware currently does not do vlan tag insertion
and removal. This causes a problem in __lro_proc_segment()
where the tcp and ip headers are setup to point into the
newly created skb. A frame containing an unstripped vlan
tag will cause the headers to be garbage.
The attached patch modifies __lro_proc_segment() to offset
those pointers by VLAN_HLEN when required.
3) Padded frames.
I may be missing something, but I don't see where you
either strip padding from frames or reject padded frames.
(see the pskb_trim_rcsum() in net/ipv4/ip_input.c:ip_rcv()
I did not add such a feature as I was confused about the intended
use of len/true_size.
Also, trimming is a pain when dealing with pure frags (without a
containing skb). We have code in our out-of-kernel driver to deal
with it which you are welcome to use.
4) LRO_MIN_PG_HLEN (== 80)
This confuses me. Can you please explain what you're trying to do?
Because of this, I kept getting crashes in the skb_pull() done by
eth_type_trans() because I was passing segments which were 60 bytes
and the skb->data_len of the skb constructed by lro_gen_skb() was -20.
I added my own code to bump the length to a magic 80 bytes, and the
panics disappeared. This may cause data corruption because of
#3 above!
5) NAPI/non-NAPI
The LRO code assumes the underlying driver uses NAPI, and calls
netif_receive_skb() rather than netif_rx(). Perhaps there should be a
field in the lro_mgr struct to specify napi / non-napi.
6) The checks for when to stop aggregating and flush in
__lro_proc_{segment|skb} need some improvement.
The skb variant currently uses a pure count (max_aggr). In order to
keep the resulting aggregated frame below 64KB, the underlying driver
computes max_aggr as 0xffff / MTU. This reduces the effectiveness of
LRO on mixed MTU networks. Eg, this causes packets coming from a
source with a 1500b MTU to be aggregated after 7 frames when using a
9000b MTU on the receiver, rather than after 43 frames. As you can
see from the differences in inet_lro's performance in the table
above, this is a real problem.
I believe that a hybrid byte / max_aggr model should be used. The
__lro_proc_segment takes this approach. Note that there is a subtle
bug in that the maximum aggregated bytes should not be be 0xffff.
Rather, one must leave room for the next frame to arrive by setting
the max aggregated bytes to 0xffff - dev->mtu. This is masked
by the driver computing max_aggr as above.
[-- Attachment #2: inet_lro.diff --]
[-- Type: text/plain, Size: 3544 bytes --]
--- linux-2.6.23-rc1.orig/include/linux/inet_lro.h 2007-07-25 12:48:48.000000000 -0400
+++ linux-2.6.23-rc1/include/linux/inet_lro.h 2007-07-24 15:07:28.000000000 -0400
@@ -132,7 +132,7 @@ void lro_vlan_hwaccel_receive_skb(struct
void lro_receive_frags(struct net_lro_mgr *lro_mgr,
struct skb_frag_struct *frags,
- int len, int true_size, void *priv);
+ int len, int true_size, void *priv, __wsum sum);
void lro_vlan_hwaccel_receive_frags(struct net_lro_mgr *lro_mgr,
struct skb_frag_struct *frags,
@@ -140,7 +140,8 @@ void lro_vlan_hwaccel_receive_frags(stru
int true_size,
struct vlan_group *vgrp,
u16 vlan_tag,
- void *priv);
+ void *priv,
+ __wsum sum);
/*
* Forward all aggregated SKBs held by lro_mgr to network stack
--- linux-2.6.23-rc1.orig/net/ipv4/inet_lro.c 2007-07-25 12:48:48.000000000 -0400
+++ linux-2.6.23-rc1/net/ipv4/inet_lro.c 2007-07-25 10:23:31.000000000 -0400
@@ -341,6 +341,10 @@ int __lro_proc_skb(struct net_lro_mgr *l
if (!(flags & LRO_IPV4) || !(flags & LRO_TCP))
goto out;
+ /* checksum has been verified by get_frag_header() */
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+ skb->csum = 0;
+
lro_desc = lro_get_desc(lro_mgr, lro_mgr->lro_arr, iph, tcph);
if (!lro_desc)
goto out;
@@ -437,7 +441,8 @@ struct sk_buff *__lro_proc_segment(struc
struct skb_frag_struct *frags,
int len, int true_size,
struct vlan_group *vgrp,
- u16 vlan_tag, void *priv)
+ u16 vlan_tag, void *priv,
+ __wsum sum)
{
struct net_lro_desc *lro_desc;
struct iphdr *iph;
@@ -446,6 +451,7 @@ struct sk_buff *__lro_proc_segment(struc
void *mac_hdr;
u64 flags;
int hdr_len = 0;
+ int vlan_hdr_len;
if (!lro_mgr->get_frag_header
|| lro_mgr->get_frag_header(frags, (void *)&mac_hdr, (void *)&iph,
@@ -473,8 +479,17 @@ struct sk_buff *__lro_proc_segment(struc
if (!skb)
goto out;
- iph = (void *)(skb->data);
- tcph = (void *)((u8 *)skb->data + IP_HDR_LEN(iph));
+ /* checksum has been verified by get_frag_header() */
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+ skb->csum = 0;
+
+ if (skb->protocol == htons(ETH_P_8021Q))
+ vlan_hdr_len = VLAN_HLEN;
+ else
+ vlan_hdr_len = 0;
+
+ iph = (void *)(skb->data + vlan_hdr_len);
+ tcph = (void *)((u8 *)skb->data + vlan_hdr_len + IP_HDR_LEN(iph));
lro_init_desc(lro_desc, skb, iph, tcph, 0, NULL);
return 0;
@@ -501,17 +516,20 @@ out1: /* Original packet has to be post
skb = lro_gen_skb(lro_mgr, frags,
len, true_size, mac_hdr,
max(hdr_len, LRO_MIN_PG_HLEN));
+ skb->ip_summed = lro_mgr->ip_summed;
+ skb->csum = sum;
out:
return skb;
}
void lro_receive_frags(struct net_lro_mgr *lro_mgr,
struct skb_frag_struct *frags,
- int len, int true_size, void *priv)
+ int len, int true_size, void *priv, __wsum sum)
{
struct sk_buff *skb;
- skb = __lro_proc_segment(lro_mgr, frags, len, true_size, NULL, 0, priv);
+ skb = __lro_proc_segment(lro_mgr, frags, len, true_size, NULL, 0,
+ priv, sum);
if(skb)
netif_receive_skb(skb);
}
@@ -524,12 +542,13 @@ void lro_vlan_hwaccel_receive_frags(stru
int true_size,
struct vlan_group *vgrp,
u16 vlan_tag,
- void *priv)
+ void *priv,
+ __wsum sum)
{
struct sk_buff *skb;
skb = __lro_proc_segment(lro_mgr, frags, len, true_size, vgrp,
- vlan_tag, priv);
+ vlan_tag, priv, sum);
if(skb)
vlan_hwaccel_receive_skb(skb, vgrp, vlan_tag);
}
[-- Attachment #3: myri10ge_lro.diff --]
[-- Type: text/plain, Size: 5467 bytes --]
diff -urNp a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
--- a/drivers/net/myri10ge/myri10ge.c 2007-07-24 15:57:12.000000000 -0400
+++ b/drivers/net/myri10ge/myri10ge.c 2007-07-25 13:10:54.000000000 -0400
@@ -48,6 +48,7 @@
#include <linux/etherdevice.h>
#include <linux/if_ether.h>
#include <linux/if_vlan.h>
+#include <linux/inet_lro.h>
#include <linux/ip.h>
#include <linux/inet.h>
#include <linux/in.h>
@@ -62,6 +63,8 @@
#include <linux/io.h>
#include <linux/log2.h>
#include <net/checksum.h>
+#include <net/ip.h>
+#include <net/tcp.h>
#include <asm/byteorder.h>
#include <asm/io.h>
#include <asm/processor.h>
@@ -89,6 +92,7 @@ MODULE_LICENSE("Dual BSD/GPL");
#define MYRI10GE_EEPROM_STRINGS_SIZE 256
#define MYRI10GE_MAX_SEND_DESC_TSO ((65536 / 2048) * 2)
+#define MYRI10GE_MAX_LRO_DESCRIPTORS 8
#define MYRI10GE_NO_CONFIRM_DATA htonl(0xffffffff)
#define MYRI10GE_NO_RESPONSE_RESULT 0xffffffff
@@ -151,6 +155,8 @@ struct myri10ge_rx_done {
dma_addr_t bus;
int cnt;
int idx;
+ struct net_lro_mgr lro_mgr;
+ struct net_lro_desc lro_desc[MYRI10GE_MAX_LRO_DESCRIPTORS];
};
struct myri10ge_priv {
@@ -276,6 +282,14 @@ static int myri10ge_debug = -1; /* defau
module_param(myri10ge_debug, int, 0);
MODULE_PARM_DESC(myri10ge_debug, "Debug level (0=none,...,16=all)");
+static int myri10ge_lro = 1;
+module_param(myri10ge_lro, int, S_IRUGO);
+MODULE_PARM_DESC(myri10ge_lro, "Enable large receive offload\n");
+
+static int myri10ge_lro_max_pkts = MYRI10GE_LRO_MAX_PKTS;
+module_param(myri10ge_lro_max_pkts, int, S_IRUGO);
+MODULE_PARM_DESC(myri10ge_lro, "Number of LRO packets to be aggregated\n");
+
static int myri10ge_fill_thresh = 256;
module_param(myri10ge_fill_thresh, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(myri10ge_fill_thresh, "Number of empty rx slots allowed\n");
@@ -1001,6 +1015,8 @@ myri10ge_rx_done(struct myri10ge_priv *m
struct net_device *dev = mgp->dev;
u8 *va;
+ if (len < 80)
+ len = 80; /* XXX LRO hack XXX */
len += MXGEFW_PAD;
idx = rx->cnt & rx->mask;
va = page_address(rx->info[idx].page) + rx->info[idx].page_offset;
@@ -1019,6 +1035,15 @@ myri10ge_rx_done(struct myri10ge_priv *m
remainder -= MYRI10GE_ALLOC_SIZE;
}
+ if (mgp->csum_flag && myri10ge_lro) {
+ rx_frags[0].page_offset += MXGEFW_PAD;
+ rx_frags[0].size -= MXGEFW_PAD;
+ len -= MXGEFW_PAD;
+ lro_receive_frags(&mgp->rx_done.lro_mgr, rx_frags,
+ len, len, (void *)(unsigned long)csum, csum);
+ return 1;
+ }
+
hlen = MYRI10GE_HLEN > len ? len : MYRI10GE_HLEN;
/* allocate an skb to attach the page(s) to. */
@@ -1137,6 +1162,9 @@ static inline void myri10ge_clean_rx_don
mgp->stats.rx_packets += rx_packets;
mgp->stats.rx_bytes += rx_bytes;
+ if (myri10ge_lro)
+ lro_flush_all(&rx_done->lro_mgr);
+
/* restock receive rings if needed */
if (mgp->rx_small.fill_cnt - mgp->rx_small.cnt < myri10ge_fill_thresh)
myri10ge_alloc_rx_pages(mgp, &mgp->rx_small,
@@ -1717,10 +1745,69 @@ static void myri10ge_free_irq(struct myr
pci_disable_msi(pdev);
}
+static int
+myri10ge_get_frag_header(struct skb_frag_struct *frag, void **mac_hdr,
+ void **ip_hdr, void **tcpudp_hdr,
+ u64 * hdr_flags, void *priv)
+{
+ struct ethhdr *eh;
+ struct vlan_ethhdr *veh;
+ struct iphdr *iph;
+ u8 *va = page_address(frag->page) + frag->page_offset;
+ unsigned long ll_hlen;
+ __wsum csum = (__wsum) (unsigned long)priv;
+
+ /* find the mac header, aborting if not IPv4 */
+
+ eh = (struct ethhdr *)va;
+ *mac_hdr = eh;
+ ll_hlen = ETH_HLEN;
+ if (eh->h_proto != htons(ETH_P_IP)) {
+ if (eh->h_proto == htons(ETH_P_8021Q)) {
+ veh = (struct vlan_ethhdr *)va;
+ if (veh->h_vlan_encapsulated_proto != htons(ETH_P_IP))
+ return -1;
+
+ ll_hlen += VLAN_HLEN;
+
+ /*
+ * HW checksum starts ETH_HLEN bytes into
+ * frame, so we must subtract off the VLAN
+ * header's checksum before csum can be used
+ */
+ csum = csum_sub(csum, csum_partial(va + ETH_HLEN,
+ VLAN_HLEN, 0));
+ } else {
+ return -1;
+ }
+ }
+ *hdr_flags = LRO_IPV4;
+
+ iph = (struct iphdr *)(va + ll_hlen);
+ *ip_hdr = iph;
+ if (iph->protocol != IPPROTO_TCP)
+ return -1;
+ *hdr_flags |= LRO_TCP;
+ *tcpudp_hdr = (u8 *) (*ip_hdr) + (iph->ihl << 2);
+
+ /* verify the IP checksum */
+ if (unlikely(ip_fast_csum((u8 *) iph, iph->ihl)))
+ return -1;
+
+ /* verify the checksum */
+ if (unlikely(csum_tcpudp_magic(iph->saddr, iph->daddr,
+ ntohs(iph->tot_len) - (iph->ihl << 2),
+ IPPROTO_TCP, csum)))
+ return -1;
+
+ return 0;
+}
+
static int myri10ge_open(struct net_device *dev)
{
struct myri10ge_priv *mgp;
struct myri10ge_cmd cmd;
+ struct net_lro_mgr *lro_mgr;
int status, big_pow2;
mgp = netdev_priv(dev);
@@ -1852,6 +1939,18 @@ static int myri10ge_open(struct net_devi
mgp->link_state = htonl(~0U);
mgp->rdma_tags_available = 15;
+ lro_mgr = &mgp->rx_done.lro_mgr;
+ lro_mgr->dev = dev;
+ lro_mgr->ip_summed = CHECKSUM_COMPLETE;
+ lro_mgr->max_desc = MYRI10GE_MAX_LRO_DESCRIPTORS;
+ lro_mgr->lro_arr = mgp->rx_done.lro_desc;
+ lro_mgr->get_frag_header = myri10ge_get_frag_header;
+ lro_mgr->max_aggr = 0xffff / dev->mtu;
+ if (lro_mgr->max_aggr > myri10ge_lro_max_pkts)
+ lro_mgr->max_aggr = myri10ge_lro_max_pkts;
+ if (lro_mgr->max_aggr > MAX_SKB_FRAGS)
+ lro_mgr->max_aggr = MAX_SKB_FRAGS;
+
netif_poll_enable(mgp->dev); /* must happen prior to any irq */
status = myri10ge_send_cmd(mgp, MXGEFW_CMD_ETHERNET_UP, &cmd, 0);
^ permalink raw reply
* [PATCH 2/2] [POWERPC] Remove dummy network phy from MPC8313E-RDB
From: Vitaly Bordug @ 2007-07-25 17:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, netdev, linux-kernel, linuxppc-dev
In-Reply-To: <20070725174312.5818.61155.stgit@localhost.localdomain>
Cleaned up inexistent network phy from the target dts, added
necessary property to gianfar node there.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/boot/dts/mpc8313erdb.dts | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
index a1533cc..b602a8b 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -98,12 +98,6 @@
reg = <24520 20>;
#address-cells = <1>;
#size-cells = <0>;
- phy1: ethernet-phy@1 {
- interrupt-parent = < &ipic >;
- interrupts = <13 8>;
- reg = <1>;
- device_type = "ethernet-phy";
- };
phy4: ethernet-phy@4 {
interrupt-parent = < &ipic >;
interrupts = <14 8>;
@@ -120,7 +114,7 @@
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <25 8 24 8 23 8>;
interrupt-parent = < &ipic >;
- phy-handle = < &phy1 >;
+ fixed_speed = <1 1000>;
};
ethernet@25000 {
^ permalink raw reply related
* [PATCH 1/2] [POWERPC] Add support of platforms without PHY to gianfar driver
From: Vitaly Bordug @ 2007-07-25 17:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, netdev, linux-kernel, linuxppc-dev
Gianfar driver is now able to work without real phy subnode,
that is necessary to cope with fixed-link situation, when
SoC is connected to the Ethernet inteface or embedded switch
without any PHY. In this case, fixed-speed property will
describe such a situation for gianfar driver.
The property is in form <duplexity speed>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/sysdev/fsl_soc.c | 39 +++++++++++++++++++++++----------------
drivers/net/gianfar.c | 17 ++++++++++++++---
2 files changed, 37 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index cad1757..6864534 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -255,29 +255,36 @@ static int __init gfar_of_init(void)
FSL_GIANFAR_DEV_HAS_EXTENDED_HASH;
ph = of_get_property(np, "phy-handle", NULL);
- phy = of_find_node_by_phandle(*ph);
+ if (ph == NULL) {
+ unsigned int *bus_id;
- if (phy == NULL) {
- ret = -ENODEV;
- goto unreg;
- }
+ bus_id = of_get_property(np, "fixed_speed",NULL);
+ gfar_data.bus_id = (bus_id[0]<<16) | bus_id[1];
+ } else {
+ phy = of_find_node_by_phandle(*ph);
- mdio = of_get_parent(phy);
+ if (phy == NULL) {
+ ret = -ENODEV;
+ goto unreg;
+ }
+
+ mdio = of_get_parent(phy);
+
+ id = of_get_property(phy, "reg", NULL);
+ ret = of_address_to_resource(mdio, 0, &res);
+ if (ret) {
+ of_node_put(phy);
+ of_node_put(mdio);
+ goto unreg;
+ }
+
+ gfar_data.phy_id = *id;
+ gfar_data.bus_id = res.start;
- id = of_get_property(phy, "reg", NULL);
- ret = of_address_to_resource(mdio, 0, &res);
- if (ret) {
of_node_put(phy);
of_node_put(mdio);
- goto unreg;
}
- gfar_data.phy_id = *id;
- gfar_data.bus_id = res.start;
-
- of_node_put(phy);
- of_node_put(mdio);
-
ret =
platform_device_add_data(gfar_dev, &gfar_data,
sizeof(struct
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 1b854bf..cf08ced 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -93,6 +93,7 @@
#include <linux/crc32.h>
#include <linux/mii.h>
#include <linux/phy.h>
+#include <linux/phy_fixed.h>
#include "gianfar.h"
#include "gianfar_mii.h"
@@ -445,11 +446,21 @@ static int init_phy(struct net_device *dev)
priv->oldspeed = 0;
priv->oldduplex = -1;
- snprintf(phy_id, BUS_ID_SIZE, PHY_ID_FMT, priv->einfo->bus_id, priv->einfo->phy_id);
-
interface = gfar_get_interface(dev);
- phydev = phy_connect(dev, phy_id, &adjust_link, 0, interface);
+ if (priv->einfo->phy_id) {
+ snprintf(phy_id, BUS_ID_SIZE, PHY_ID_FMT, priv->einfo->bus_id, priv->einfo->phy_id);
+ phydev = phy_connect(dev, phy_id, &adjust_link, 0, interface);
+ } else {
+ struct fixed_info *phyinfo;
+ int phy_addr = (priv->einfo->bus_id >> 16);
+
+ phyinfo = fixed_mdio_get_phydev(phy_addr-1);
+ phydev = phyinfo->phydev;
+ snprintf(phydev->dev.bus_id, BUS_ID_SIZE, PHY_ID_FMT,
+ (priv->einfo->bus_id & 0xffff) , phy_addr);
+ memset(phyinfo->regs,0xff,sizeof(phyinfo->regs[0])*phyinfo->regs_num);
+ }
if (IS_ERR(phydev)) {
printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name);
^ permalink raw reply related
* RE: Tc filtering: broken 802_3 classifier?
From: Waskiewicz Jr, Peter P @ 2007-07-25 17:34 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <46A7884F.70707@trash.net>
> Waskiewicz Jr, Peter P wrote:
> >>The protocol match is on skb->protocol, so it case of
> ethernet its on
> >>the ethernet protocol, which is ETH_P_IP or "ip" for IPv4.
> >
> >
> > I see that in the code, but the reason I started worrying was when I
> > added the 802_3 classifier on 8 flows, it would shove all
> traffic into
> > flowid 1:1, no matter if it matched or not.
> >
> > I'll keep investigating and see if I can narrow down what
> I'm seeing.
>
>
> I'm not sure what you're expecting. skb->protocol is usually not set
> to ETH_P_802_3, which is why the filter is not matching.
I understand that. I had two issues, which you cleared up one by
reminding me that the protocol matches on skb->protocol before it tries
to run the ->classify() routine. The other issue I am seeing is with 8
bands, an 802_3 filter is affecting classification of IP traffic. For
example, I have an 802_3 filter to look for dst MAC address, but an ssh
packet, which without any filters should go into flowid 1:3 on my
system, is getting pushed into flowid 1:1. I remove the 802_3 filter,
and ssh traffic starts going back into 1:3. No other filters on the
system. That's the main issue I'm seeing, so I'll keep investigating to
see what's going on.
-PJ
^ permalink raw reply
* Re: Tc filtering: broken 802_3 classifier?
From: Patrick McHardy @ 2007-07-25 17:28 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P; +Cc: netdev
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC329034BF7D3@orsmsx414.amr.corp.intel.com>
Waskiewicz Jr, Peter P wrote:
>>The protocol match is on skb->protocol, so it case of
>>ethernet its on the ethernet protocol, which is ETH_P_IP or
>>"ip" for IPv4.
>
>
> I see that in the code, but the reason I started worrying was when I
> added the 802_3 classifier on 8 flows, it would shove all traffic into
> flowid 1:1, no matter if it matched or not.
>
> I'll keep investigating and see if I can narrow down what I'm seeing.
I'm not sure what you're expecting. skb->protocol is usually not set
to ETH_P_802_3, which is why the filter is not matching.
^ permalink raw reply
* RE: Tc filtering: broken 802_3 classifier?
From: Waskiewicz Jr, Peter P @ 2007-07-25 17:24 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <46A699E3.2000609@trash.net>
> The protocol match is on skb->protocol, so it case of
> ethernet its on the ethernet protocol, which is ETH_P_IP or
> "ip" for IPv4.
I see that in the code, but the reason I started worrying was when I
added the 802_3 classifier on 8 flows, it would shove all traffic into
flowid 1:1, no matter if it matched or not.
I'll keep investigating and see if I can narrow down what I'm seeing.
Thanks Patrick,
-PJ
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 0/10] ps3: fixes for ps3_gelic driver
From: Joel Schopp @ 2007-07-25 16:11 UTC (permalink / raw)
To: Masakazu Mokuno; +Cc: Jeff Garzik, netdev, cbe-oss-dev, Linas Vepstas
In-Reply-To: <20070720162345.6775.MOKUNO@sm.sony.co.jp>
Since gelic and spidernet are 95% identical it would be a good idea to cc the
spidernet maintainer Linas on these patches (ccd on this reply).
Masakazu Mokuno wrote:
> This patchset are fixes and updates incorporating the comments from Jeff
> Garzik and Stephen Hemminger.
> Please accept the following patches for the ps3_gelic driver. Thanks.
>
> [1] ps3: fix wrong calculation of rx descriptor address
> [2] ps3: some minor cleanups
> [3] ps3: tx descriptor handling cleanup
> [4] ps3: removed defines no longer used
> [5] ps3: removed conditional ethtool support
> [6] ps3: use net_device_stats of net_device structure
> [7] ps3: use ethX as the name of irq
> [8] ps3: removed calling netif_poll_enable() in open()
> [9] ps3: fix rare issue that reenabling rx DMA fails
> [10] ps3: reduce allocation size of rx skb buffers
>
>
> --
> Masakazu MOKUNO
>
> _______________________________________________
> cbe-oss-dev mailing list
> cbe-oss-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/cbe-oss-dev
^ permalink raw reply
* Re: [-mm patch] one e1000 driver should be enough for everyone
From: Jeff Garzik @ 2007-07-25 15:23 UTC (permalink / raw)
To: Kok, Auke; +Cc: Adrian Bunk, Andrew Morton, linux-kernel, e1000-devel, netdev
In-Reply-To: <46A76A66.9000304@intel.com>
Kok, Auke wrote:
> I'm working on "e1000e" right now...
Cool :)
> I'll submit it with only ich9 id's at first, but it will be able to
> drive (sysfs bind) to some other devices too. This allows me to keep an
> eye out on the future structure that I want to give it without removing
> too much code that I might then later have to add back.
Sounds good to me...
Jeff
^ permalink raw reply
* Re: [RESEND 1/2] netxen: re-init station address after h/w init
From: Jeff Garzik @ 2007-07-25 15:21 UTC (permalink / raw)
To: dhananjay; +Cc: netdev, rob
In-Reply-To: <20070725144515.533385702@netxen.com>
Since we had a problem before, just wanted to let you know I received
these two patches.
Jeff
^ permalink raw reply
* Re: [-mm patch] one e1000 driver should be enough for everyone
From: Kok, Auke @ 2007-07-25 15:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Adrian Bunk, Andrew Morton, linux-kernel, e1000-devel, netdev
In-Reply-To: <46A7669C.5010104@garzik.org>
Jeff Garzik wrote:
> Adrian Bunk wrote:
>> I found the discussion, and Christoph's e1000e sounds like the best name
>> ("new" doesn't say whether it's a new driver for old hardware or a
>> driver for new hardware).
>
> Yeah, I think "e1000new" is a lame name.
Moreover, Andrew should probably just drop this driver from -mm for now.
> e1000e is good, or even e1001e if we wanted even more symmetry :)
I'm working on "e1000e" right now...
>> No problem for me, but this obviously implies that global code in the
>> new driver has to be renamed.
>
> Yes. A global namespace is a global namespace.
yes, these are some of the kinks I still need to address. Allthough minor, it's
going to take me some time to get it to the first step before I want to submit
it (patience :))
>> And please ensure that they will always support distinct PCI IDs, or
>> there will be the following common pattern if both drivers support
>> a card:
>
> IIRC I think Auke said there is some minor PCI ID overlap that must be
> addressed in the transition. Disappointing and it raises transition
> issues, but that's the way the split falls out naturally AFAICS.
I'll submit it with only ich9 id's at first, but it will be able to drive (sysfs
bind) to some other devices too. This allows me to keep an eye out on the future
structure that I want to give it without removing too much code that I might
then later have to add back.
Auke
^ permalink raw reply
* Re: [-mm patch] one e1000 driver should be enough for everyone
From: Jeff Garzik @ 2007-07-25 15:05 UTC (permalink / raw)
To: Adrian Bunk; +Cc: e1000-devel, netdev, Andrew Morton, Auke Kok, linux-kernel
In-Reply-To: <20070725144615.GC3572@stusta.de>
Adrian Bunk wrote:
> I found the discussion, and Christoph's e1000e sounds like the best name
> ("new" doesn't say whether it's a new driver for old hardware or a
> driver for new hardware).
Yeah, I think "e1000new" is a lame name.
e1000e is good, or even e1001e if we wanted even more symmetry :)
> No problem for me, but this obviously implies that global code in the
> new driver has to be renamed.
Yes. A global namespace is a global namespace.
> And please ensure that they will always support distinct PCI IDs, or
> there will be the following common pattern if both drivers support
> a card:
IIRC I think Auke said there is some minor PCI ID overlap that must be
addressed in the transition. Disappointing and it raises transition
issues, but that's the way the split falls out naturally AFAICS.
Jeff
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* [PATCH][v2] Netfilter Kconfig: Expose IPv4/6 connection tracking options by selecting NF_CONNTRACK_ENABLED
From: Al Boldi @ 2007-07-25 15:02 UTC (permalink / raw)
To: netfilter-devel, netdev
Cc: Andrew Morton, Sam Ravnborg, Patrick McHardy, David Miller
Make NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6 select NF_CONNTRACK_ENABLED.
This exposes IPv4/6 connection tracking options for easier Kconfig setup.
Signed-off-by: Al Boldi <a1426z@gawab.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
--- a/net/netfilter/Kconfig 2007-07-09 06:38:52.000000000 +0300
+++ b/net/netfilter/Kconfig 2007-07-25 17:37:16.000000000 +0300
@@ -28,6 +28,7 @@ config NETFILTER_NETLINK_LOG
# Rename this to NF_CONNTRACK in a 2.6.25
config NF_CONNTRACK_ENABLED
tristate "Netfilter connection tracking support"
+ select NF_CONNTRACK
help
Connection tracking keeps a record of what packets have passed
through your machine, in order to figure out how they are related
--- a/net/ipv4/netfilter/Kconfig 2007-07-09 06:38:50.000000000 +0300
+++ b/net/ipv4/netfilter/Kconfig 2007-07-25 17:37:39.000000000 +0300
@@ -7,7 +7,7 @@ menu "IP: Netfilter Configuration"
config NF_CONNTRACK_IPV4
tristate "IPv4 connection tracking support (required for NAT)"
- depends on NF_CONNTRACK
+ select NF_CONNTRACK_ENABLED
---help---
Connection tracking keeps a record of what packets have passed
through your machine, in order to figure out how they are related
--- a/net/ipv6/netfilter/Kconfig 2007-07-09 06:38:51.000000000 +0300
+++ b/net/ipv6/netfilter/Kconfig 2007-07-25 17:37:57.000000000 +0300
@@ -7,7 +7,8 @@ menu "IPv6: Netfilter Configuration (EXP
config NF_CONNTRACK_IPV6
tristate "IPv6 connection tracking support (EXPERIMENTAL)"
- depends on INET && IPV6 && EXPERIMENTAL && NF_CONNTRACK
+ depends on INET && IPV6 && EXPERIMENTAL
+ select NF_CONNTRACK_ENABLED
---help---
Connection tracking keeps a record of what packets have passed
through your machine, in order to figure out how they are related
^ permalink raw reply
* [RESEND 1/2] netxen: re-init station address after h/w init
From: dhananjay @ 2007-07-25 14:43 UTC (permalink / raw)
To: netdev; +Cc: rob, jeff
In-Reply-To: <20070725144310.500691352@netxen.com>
[-- Attachment #1: dma.patch --]
[-- Type: text/plain, Size: 1076 bytes --]
This is a workaround for firmware bug with 2nd port of multiport adapter,
where MAC address is reset. Driver just needs to overwrite it with the
value read from PROM.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===================================================================
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -895,8 +895,6 @@ static int netxen_nic_open(struct net_de
/* Done here again so that even if phantom sw overwrote it,
* we set it */
- if (adapter->macaddr_set)
- adapter->macaddr_set(adapter, netdev->dev_addr);
if (adapter->init_port
&& adapter->init_port(adapter, adapter->portnum) != 0) {
del_timer_sync(&adapter->watchdog_timer);
@@ -904,6 +902,8 @@ static int netxen_nic_open(struct net_de
netxen_nic_driver_name, adapter->portnum);
return -EIO;
}
+ if (adapter->macaddr_set)
+ adapter->macaddr_set(adapter, netdev->dev_addr);
netxen_nic_set_link_parameters(adapter);
--
^ permalink raw reply
* [RESEND 0/2] netxen: bug fixes for IMEZ adapters on pblades
From: dhananjay @ 2007-07-25 14:43 UTC (permalink / raw)
To: netdev; +Cc: rob, jeff
Resending the earlier patches, since the old patch got committed.
drivers/net/netxen/netxen_nic_main.c | 40 +++++++++++++++++----------------
1 files changed, 21 insertions(+), 19 deletions(-)
^ permalink raw reply
* [RESEND 2/2] netxen: Fix interrupt handling for multiport adapters
From: dhananjay @ 2007-07-25 14:43 UTC (permalink / raw)
To: netdev; +Cc: rob, jeff
In-Reply-To: <20070725144310.500691352@netxen.com>
[-- Attachment #1: intr.patch --]
[-- Type: text/plain, Size: 2563 bytes --]
This patch fixes masking of interrupts on multiport adapters. Also disables
interrupts upon ifdown interface. The wrong mask could result in interrupt
flood after interface is down.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===================================================================
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -930,6 +930,8 @@ static int netxen_nic_close(struct net_d
netif_carrier_off(netdev);
netif_stop_queue(netdev);
+ netxen_nic_disable_int(adapter);
+
cmd_buff = adapter->cmd_buf_arr;
for (i = 0; i < adapter->max_tx_desc_count; i++) {
buffrag = cmd_buff->frag_array;
@@ -1243,28 +1245,12 @@ static int
netxen_handle_int(struct netxen_adapter *adapter, struct net_device *netdev)
{
u32 ret = 0;
- u32 our_int = 0;
DPRINTK(INFO, "Entered handle ISR\n");
adapter->stats.ints++;
- if (!(adapter->flags & NETXEN_NIC_MSI_ENABLED)) {
- our_int = readl(NETXEN_CRB_NORMALIZE(adapter, CRB_INT_VECTOR));
- /* not our interrupt */
- if ((our_int & (0x80 << adapter->portnum)) == 0)
- return ret;
- }
-
netxen_nic_disable_int(adapter);
- if (adapter->intr_scheme == INTR_SCHEME_PERPORT) {
- /* claim interrupt */
- if (!(adapter->flags & NETXEN_NIC_MSI_ENABLED)) {
- writel(our_int & ~((u32)(0x80 << adapter->portnum)),
- NETXEN_CRB_NORMALIZE(adapter, CRB_INT_VECTOR));
- }
- }
-
if (netxen_nic_rx_has_work(adapter) || netxen_nic_tx_has_work(adapter)) {
if (netif_rx_schedule_prep(netdev)) {
/*
@@ -1298,6 +1284,7 @@ irqreturn_t netxen_intr(int irq, void *d
{
struct netxen_adapter *adapter;
struct net_device *netdev;
+ u32 our_int = 0;
if (unlikely(!irq)) {
return IRQ_NONE; /* Not our interrupt */
@@ -1305,7 +1292,22 @@ irqreturn_t netxen_intr(int irq, void *d
adapter = (struct netxen_adapter *)data;
netdev = adapter->netdev;
- /* process our status queue (for all 4 ports) */
+
+ if (!(adapter->flags & NETXEN_NIC_MSI_ENABLED)) {
+ our_int = readl(NETXEN_CRB_NORMALIZE(adapter, CRB_INT_VECTOR));
+ /* not our interrupt */
+ if ((our_int & (0x80 << adapter->portnum)) == 0)
+ return IRQ_NONE;
+ }
+
+ if (adapter->intr_scheme == INTR_SCHEME_PERPORT) {
+ /* claim interrupt */
+ if (!(adapter->flags & NETXEN_NIC_MSI_ENABLED)) {
+ writel(our_int & ~((u32)(0x80 << adapter->portnum)),
+ NETXEN_CRB_NORMALIZE(adapter, CRB_INT_VECTOR));
+ }
+ }
+
if (netif_running(netdev))
netxen_handle_int(adapter, netdev);
--
^ permalink raw reply
* Re: [-mm patch] one e1000 driver should be enough for everyone
From: Adrian Bunk @ 2007-07-25 14:46 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, Auke Kok, linux-kernel, e1000-devel, netdev
In-Reply-To: <46A754C7.9080004@garzik.org>
On Wed, Jul 25, 2007 at 09:48:55AM -0400, Jeff Garzik wrote:
> Adrian Bunk wrote:
>> BTW:
>> Unless I'm misunderstanding anything, the new driver should support a
>> superset of what the old driver supported.
>> Therefore, it would be good if the final merge into Linus' tree will
>> do an
>> rm -r drivers/net/e1000
>> mv drivers/net/e1000new drivers/net/e1000
>
> Based on the most recent discussion, e1000new (or whatever it will be
> called) should support only the newer PCI-Express chips, while e1000 will
> retain support for the older chips.
I found the discussion, and Christoph's e1000e sounds like the best name
("new" doesn't say whether it's a new driver for old hardware or a
driver for new hardware).
> Over the long term this will allow e1000new to grow without affecting
> support for the older, stable chips.
>
> So, e1000 is not going away.
No problem for me, but this obviously implies that global code in the
new driver has to be renamed.
And please ensure that they will always support distinct PCI IDs, or
there will be the following common pattern if both drivers support
a card:
- user tries driver A
- driver A doesn't work (although it should have worked)
- user tries driver B
- driver B works
- a later kernel removes support for this card from driver B
- user tries driver A
- driver A still doesn't work
- user writes bug report
Users should report bugs early instead of bouncing between different
drivers.
> Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Alan Cox @ 2007-07-25 14:46 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Thomas Gleixner, Ingo Molnar, Linus Torvalds, Marcin ??lusarz,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton
In-Reply-To: <20070725135718.GB1843@ff.dom.local>
> > The code in question lib8390.c does
> >
> > disable_irq();
> > fiddle_with_the_network_card_hardware()
> > enable_irq();
> ...
> >
> > No idea how this affects the network card, as the code there must be
> > able to handle interrupts, which are not originated from the card due to
> > interrupt sharing.
>
> I think, in this last yesterday's patch Ingo could be right, yet!
> The comment at the beginnig points this is done like that because
> of chip's slowness. And problems with timing are mysterious.
>
> On the other hand author of this code didn't use spin_lock_irqsave
> for some reason, probably after testing this option too. So, I hope
> this is the right path, but alas, I'm not sure this patch has to
> prove this 100%.
The author (me) didn't use spin_lock_irqsave because the slowness of the
card means that approach caused horrible problems like losing serial data
at 38400 baud on some chips. Rememeber many 8390 nics on PCI were ISA
chips with FPGA front ends.
> Anyway, in my opinion this situation where interrupts could/have_to
> be used for such strange things should confirm the need of more
> options for handling irqs individually.
Ok the logic behind the 8390 is very simple:
Things to know
- IRQ delivery is asynchronous to the PCI bus
- Blocking the local CPU IRQ via spin locks was too slow
- The chip has register windows needing locking work
So the path was once (I say once as people appear to have changed it
in the mean time and it now looks rather bogus if the changes to use
disable_irq_nosync_irqsave are disabling the local IRQ)
Take the page lock
Mask the IRQ on chip
Disable the IRQ (but not mask locally- someone seems to have
broken this with the lock validator stuff)
[This must be _nosync as the page lock may otherwise
deadlock us]
Drop the page lock and turn IRQs back on
At this point an existing IRQ may still be running but we can't
get a new one
Take the lock (so we know the IRQ has terminated) but don't mask
the IRQs on the processor
Set irqlock [for debug]
Transmit (slow as ****)
re-enable the IRQ
We have to use disable_irq because otherwise you will get delayed
interrupts on the APIC bus deadlocking the transmit path.
Quite hairy but the chip simply wasn't designed for SMP and you can't
even ACK an interrupt without risking corrupting other parallel
activities on the chip.
Alan
^ permalink raw reply
* Re: [PATCH 1/1] netxen: Load firmware during probe, dma watchdog fix.
From: Jeff Garzik @ 2007-07-25 14:29 UTC (permalink / raw)
To: Dhananjay Phadke; +Cc: netdev, rob, Wen Xiong
In-Reply-To: <ab901500707242118q27cb9eddqe69f01275b809b3@mail.gmail.com>
Dhananjay Phadke wrote:
> Jeff,
>
> You committed old patch, which I had asked to ignore for two newer patches.
>
> [PATCH 1/1] netxen: Load firmware during probe, dma watchdog fix.
>
> is wrong patch that went in, instead please commit:
>
> [PATCH 1/2] netxen: IMEZ multiport card 2nd port issue, dma watchdog fix
> [PATCH 2/2] netxen: Fix interrupt handling for multiport adapters
Two responses:
1) I never received the two patches you mention. It helps (though not
required) to CC me, in addition to sending patches to netdev.
2) Kernel history is fixed in stone, once committed upstream. Thus, you
must regenerate your patches based on the fact that old-patch is now
upstream.
Jeff
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Jarek Poplawski @ 2007-07-25 13:57 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ingo Molnar, Linus Torvalds, Marcin ??lusarz,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton
In-Reply-To: <1185322771.4175.102.camel@chaos>
On Wed, Jul 25, 2007 at 02:19:31AM +0200, Thomas Gleixner wrote:
...
> Looking into the IO_APIC code, the resend via send_IPI_self() happens
> unconditionally. So the resend is done for level and edge interrupts.
> This makes the problem more mysterious.
>
> The code in question lib8390.c does
>
> disable_irq();
> fiddle_with_the_network_card_hardware()
> enable_irq();
...
>
> No idea how this affects the network card, as the code there must be
> able to handle interrupts, which are not originated from the card due to
> interrupt sharing.
I think, in this last yesterday's patch Ingo could be right, yet!
The comment at the beginnig points this is done like that because
of chip's slowness. And problems with timing are mysterious.
On the other hand author of this code didn't use spin_lock_irqsave
for some reason, probably after testing this option too. So, I hope
this is the right path, but alas, I'm not sure this patch has to
prove this 100%.
Anyway, in my opinion this situation where interrupts could/have_to
be used for such strange things should confirm the need of more
options for handling irqs individually.
Thanks,
Jarek P.
^ permalink raw reply
* Re: [-mm patch] one e1000 driver should be enough for everyone
From: Jeff Garzik @ 2007-07-25 13:48 UTC (permalink / raw)
To: Adrian Bunk; +Cc: e1000-devel, netdev, Andrew Morton, Auke Kok, linux-kernel
In-Reply-To: <20070725133650.GB3572@stusta.de>
Adrian Bunk wrote:
> BTW:
> Unless I'm misunderstanding anything, the new driver should support a
> superset of what the old driver supported.
> Therefore, it would be good if the final merge into Linus' tree will
> do an
> rm -r drivers/net/e1000
> mv drivers/net/e1000new drivers/net/e1000
Based on the most recent discussion, e1000new (or whatever it will be
called) should support only the newer PCI-Express chips, while e1000
will retain support for the older chips.
Over the long term this will allow e1000new to grow without affecting
support for the older, stable chips.
So, e1000 is not going away.
Jeff
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* [-mm patch] one e1000 driver should be enough for everyone
From: Adrian Bunk @ 2007-07-25 13:36 UTC (permalink / raw)
To: Andrew Morton, Auke Kok, jgarzik; +Cc: linux-kernel, e1000-devel, netdev
In-Reply-To: <20070725040304.111550f4.akpm@linux-foundation.org>
On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.22-rc6-mm1:
>...
> git-e1000new.patch
>...
> git trees
>...
Both e1000 drivers compiled into the kernel resulted in the following
compile error:
<-- snip -->
...
LD drivers/net/built-in.o
drivers/net/e1000/built-in.o: In function `e1000_read_mac_addr':
(.text+0xb9f2): multiple definition of `e1000_read_mac_addr'
drivers/net/e1000new/built-in.o:(.text+0x821a): first defined here
drivers/net/e1000/built-in.o: In function `e1000_phy_setup_autoneg':
(.text+0x8799): multiple definition of `e1000_phy_setup_autoneg'
drivers/net/e1000new/built-in.o:(.text+0xa9bd): first defined here
...
make[3]: *** [drivers/net/built-in.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
BTW:
Unless I'm misunderstanding anything, the new driver should support a
superset of what the old driver supported.
Therefore, it would be good if the final merge into Linus' tree will
do an
rm -r drivers/net/e1000
mv drivers/net/e1000new drivers/net/e1000
--- linux-2.6.23-rc1-mm1/drivers/net/Kconfig.old 2007-07-25 15:06:13.000000000 +0200
+++ linux-2.6.23-rc1-mm1/drivers/net/Kconfig 2007-07-25 15:09:59.000000000 +0200
@@ -2036,7 +2036,7 @@
config E1000
tristate "Intel(R) PRO/1000 Gigabit Ethernet support"
- depends on PCI
+ depends on PCI && E1000NEW=n
---help---
This driver supports Intel(R) PRO/1000 gigabit ethernet family of
adapters. For more information on how to identify your adapter, go
^ permalink raw reply
* Re: [PATCH RFC]: napi_struct V4
From: jamal @ 2007-07-25 12:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger, jgarzik, rusty
In-Reply-To: <20070725.013154.34764933.davem@davemloft.net>
On Wed, 2007-25-07 at 01:31 -0700, David Miller wrote:
> We're getting there, slowly...
>
> 1) netif_napi_init() is added, the workqueue/requeue stuff
> as discussed is not needed so you won't see that here
..
....
> Another thing that's really apparent now is all the wacky
> napi->weight values various drivers use. Just grep for
> netif_napi_init() in the patch or a patched tree to see what
> I mean. So much of it doesn't make any sense and I'm tempted
> to just remove the argument and make everyone use 32 or 64
> or something like that :-) Or, default to some value across
> the board, and let drivers override that on a case by case
> basis with a BIG FAT COMMENT above the override describing
> why the different value is being used and precisely what
> tests were performed to validate that different value.
Sounds reasonable.
32-64 for Gige seemed to work well as i recall. 10/100 was around 16.
But that shouldnt matter i think: because the poll from the core is
based on Varghese's DRR, it probably will be fine if you just gave all
the same value and the "deficit" part will kick in when needed. Some
testing maybe required but theoretically i dont see a problem.
BTW: The current kernel code has a "bug" - where if a driver
forgot to set its weight it would be indeterminate, so even for this
reason it will be a good idea to enforce a default.
Sorry, havent been following the thread - thanks for CCing me, will try
to catch up at some point.
cheers,
jamal
^ permalink raw reply
* Re: modpost warning question
From: Sam Ravnborg @ 2007-07-25 11:45 UTC (permalink / raw)
To: chengong; +Cc: Kumar Gala, linuxppc-dev, linux-kernel, Jeff Garzik, netdev
In-Reply-To: <1185358083.4996.6.camel@localhost.localdomain>
On Wed, Jul 25, 2007 at 06:08:03PM +0800, chengong wrote:
> On Wed, 2007-07-25 at 09:27 +0200, Sam Ravnborg wrote:
> > On Wed, Jul 25, 2007 at 02:14:12AM -0500, Kumar Gala wrote:
> > > I'm seeing the following warning:
> > >
> > > WARNING: vmlinux.o(.init.text+0x1acdc): Section mismatch: reference to
> > > .exit.text:gfar_mdio_exit (between 'gfar_init' and 'gfar_mdio_init')
> > >
> > > I don't understand why its not ok to access .exit.text from .init.text
> >
> > Several architectures discards .exit.text in the final linker
> > script (arch/$(ARCH)/kernel/vmlinux.lds.S
> >
> > So any references to .exit.text will when a module is build-in result
> > in a linker error because ld will flag it as an error when we reference
> > a symbol in a discarded section.
> But why? Just make kernel size smaller?
Yes - that the whole goal of init/exit sections.
> >
> > For the popular architectures (i386,x86_64) we discard .exit.text at
> > runtime so here we do not see the error from ld (sadly).
> >From which version? On my machine I have seen the same problem when
> building i386 target with the version 2.6.21.
modpost has started to warn about it. I assume you did not see link errors.
Sam
^ 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