[INET]: Introduce tunnel4/tunnel6
Hi Dave:
I've finally finished this stuff.
Basically this patch moves the generic tunnel protocol stuff out of
xfrm4_tunnel/xfrm6_tunnel and moves it into the new files of tunnel4.c
and tunnel6 respectively.
The reason for this is that the problem that Hugo uncovered is only
the tip of the iceberg. The real problem is that when we removed the
dependency of ipip on xfrm4_tunnel we didn't really consider the module
case at all.
For instance, as it is it's possible to build both ipip and xfrm4_tunnel
as modules and if the latter is loaded then ipip simply won't load.
After considering the alternatives I've decided that the best way out of
this is to restore the dependency of ipip on the non-xfrm-specific part
of xfrm4_tunnel. This is acceptable IMHO because the intention of the
removal was really to be able to use ipip without the xfrm subsystem.
This is still preserved by this patch.
So now both ipip/xfrm4_tunnel depend on the new tunnel4.c which handles
the arbitration between the two. The order of processing is determined
by a simple integer which ensures that ipip gets processed before
xfrm4_tunnel.
The situation for ICMP handling is a little bit more complicated since
we may not have enough information to determine who it's for. It's not
a big deal at the moment since the xfrm ICMP handlers are basically
no-ops. In future we can deal with this when we look at ICMP caching
in general.
The user-visible change to this is the removal of the TUNNEL Kconfig
prompts. This makes sense because it can only be used through IPCOMP
as it stands.
The addition of the new modules shouldn't introduce any problems since
module dependency will cause them to be loaded.
Oh and I also turned some unnecessary pskb's in IPv6 related to this
patch to skb's.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
BTW the ICMP sending in case of a non-existant tunnel does not fit here
and will be fixed properly in a subsequent patch.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -864,13 +864,19 @@ struct xfrm_algo_desc {
/* XFRM tunnel handlers. */
struct xfrm_tunnel {
int (*handler)(struct sk_buff *skb);
- void (*err_handler)(struct sk_buff *skb, __u32 info);
+ int (*err_handler)(struct sk_buff *skb, __u32 info);
+
+ struct xfrm_tunnel *next;
+ int priority;
};
struct xfrm6_tunnel {
- int (*handler)(struct sk_buff **pskb);
- void (*err_handler)(struct sk_buff *skb, struct inet6_skb_parm *opt,
- int type, int code, int offset, __u32 info);
+ int (*handler)(struct sk_buff *skb);
+ int (*err_handler)(struct sk_buff *skb, struct inet6_skb_parm *opt,
+ int type, int code, int offset, __u32 info);
+
+ struct xfrm6_tunnel *next;
+ int priority;
};
extern void xfrm_init(void);
@@ -906,7 +912,7 @@ extern int xfrm4_rcv(struct sk_buff *skb
extern int xfrm4_output(struct sk_buff *skb);
extern int xfrm4_tunnel_register(struct xfrm_tunnel *handler);
extern int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler);
-extern int xfrm6_rcv_spi(struct sk_buff **pskb, u32 spi);
+extern int xfrm6_rcv_spi(struct sk_buff *skb, u32 spi);
extern int xfrm6_rcv(struct sk_buff **pskb);
extern int xfrm6_tunnel_register(struct xfrm6_tunnel *handler);
extern int xfrm6_tunnel_deregister(struct xfrm6_tunnel *handler);
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -235,6 +235,7 @@ config IP_PNP_RARP
# bool 'IP: ARP support' CONFIG_IP_PNP_ARP
config NET_IPIP
tristate IP: tunneling
+ select INET_TUNNEL
---help---
Tunneling means encapsulating data of one protocol type within
another protocol and sending it over a channel that understands the
@@ -395,7 +396,7 @@ config INET_ESP
config INET_IPCOMP
tristate IP: IPComp transformation
select XFRM
- select INET_TUNNEL
+ select INET_XFRM_TUNNEL
select CRYPTO
select CRYPTO_DEFLATE
---help---
@@ -404,14 +405,14 @@ config INET_IPCOMP
If unsure, say Y.
+config INET_XFRM_TUNNEL
+ tristate
+ select INET_TUNNEL
+ default n
+
config INET_TUNNEL
- tristate IP: tunnel transformation
- select XFRM
- ---help---
- Support for generic IP tunnel transformation, which is required by
- the IP tunneling module as well as tunnel mode IPComp.
-
- If unsure, say Y.
+ tristate
+ default n
config INET_DIAG
tristate INET: socket monitoring interface
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -22,7 +22,8 @@
Re: [INET]: Introduce tunnel4/tunnel6
Hi Herbert,
I have a couple of comments, please see below.
The reason for this is that the problem that Hugo uncovered is only
the tip of the iceberg. The real problem is that when we removed the
dependency of ipip on xfrm4_tunnel we didn't really consider the module
case at all.
For instance, as it is it's possible to build both ipip and xfrm4_tunnel
as modules and if the latter is loaded then ipip simply won't load.
Yes, this was another problem i pointed out. But the real issue i
wanted to fix was the soft-lockup with module ip6_tunnel being used
when having xfrm6_tunnel compiled as module.
After considering the alternatives I've decided that the best way out of
this is to restore the dependency of ipip on the non-xfrm-specific part
of xfrm4_tunnel. This is acceptable IMHO because the intention of the
removal was really to be able to use ipip without the xfrm subsystem.
This is still preserved by this patch.
This looks OK to me, but i think that maybe not calling the methods
xfrm{4,6}_tunnel_register and deregister would be better as tunnel{4,6}
is not really related to xfrm. Maybe something like tunnel6_register
would be better and more consistent with the file naming.
One small issue with the patch is tunnel6_rcv's return of 0 when no
handler handles the packet which will increase IPSTATS_MIB_INDELIVERS.
I guess -1 should be returned on error. I was checking ip_input and the
expected behaviour there is different, any value != 0 will trigger a
re-submit.
Also, there's a bigger problem which is the ICMP error generation. I
acknowledge you mentioned that this is work for another patch but i
would like to comment it now. Right now you kept the icmpv6_send in
ip6_tunnel's discard path, which doesn't work that well if you have
another tunnel handler following like xfrm6_tunnel. I would suggest
having the icmpv6_send in tunnel6_rcv's error path, so if no handler
was able to process the packet, the source receives the DEST_UNREACH
error. I'm not sure if this is desirable in IPSec but i'm sure you'll
be able to comment on that.
Thanks,
Hugo
signature.asc
Description: Digital signature
Re: [INET]: Introduce tunnel4/tunnel6
On Mon, Mar 27, 2006 at 12:01:41PM +0100, Hugo Santos wrote:
One small issue with the patch is tunnel6_rcv's return of 0 when no
handler handles the packet which will increase IPSTATS_MIB_INDELIVERS.
I guess -1 should be returned on error. I was checking ip_input and the
expected behaviour there is different, any value != 0 will trigger a
re-submit.
Incrementing the counter makes sense because we do have a protocol handler
that looked at the packet and decided that it couldn't be handled. You
can compare this with the case where UDP couldn't find a socket for a
packet.
Also, there's a bigger problem which is the ICMP error generation. I
acknowledge you mentioned that this is work for another patch but i
would like to comment it now. Right now you kept the icmpv6_send in
ip6_tunnel's discard path, which doesn't work that well if you have
another tunnel handler following like xfrm6_tunnel. I would suggest
having the icmpv6_send in tunnel6_rcv's error path, so if no handler
was able to process the packet, the source receives the DEST_UNREACH
error. I'm not sure if this is desirable in IPSec but i'm sure you'll
be able to comment on that.
Yes it will be moved out in a subsequent patch.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
* Francois Romieu [EMAIL PROTECTED] [2006-03-09 23:44]: So when compiling for Cobalt, we work around the hardware bug, while for other platforms, we just disable MWI? Wouldn't it be possible to always (I mean, when a rev 65 chip is detected) work around the bug? Of course it is possible but it is not the same semantic as the initial patch (not that I know if it is right or not). So: - does the issue exist beyond Cobalt hosts ? - is the fix Cobalt-only ? I don't think anyone has replied to this message yet. My understanding is that it's not Cobalt only but a problem in a specific revision of the chip, which the Cobalt happens to use. However, I'd be glad if somone else could comment. Peter, you read the errata right? -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] deinline some larger functions from netdevice.h
On a allyesconfig'ured kernel:
Size Uses Wasted Name and definition
= ==
95 162 12075 netif_wake_queue include/linux/netdevice.h
129 86 9265 dev_kfree_skb_any include/linux/netdevice.h
127 56 5885 netif_device_attach include/linux/netdevice.h
73 86 4505 dev_kfree_skb_irq include/linux/netdevice.h
46 60 1534 netif_device_detach include/linux/netdevice.h
119 16 1485 __netif_rx_schedule include/linux/netdevice.h
1435492 netif_rx_schedule include/linux/netdevice.h
817366 netif_scheduleinclude/linux/netdevice.h
netif_wake_queue is big because __netif_schedule is a big inline:
static inline void __netif_schedule(struct net_device *dev)
{
if (!test_and_set_bit(__LINK_STATE_SCHED, dev-state)) {
unsigned long flags;
struct softnet_data *sd;
local_irq_save(flags);
sd = __get_cpu_var(softnet_data);
dev-next_sched = sd-output_queue;
sd-output_queue = dev;
raise_softirq_irqoff(NET_TX_SOFTIRQ);
local_irq_restore(flags);
}
}
static inline void netif_wake_queue(struct net_device *dev)
{
#ifdef CONFIG_NETPOLL_TRAP
if (netpoll_trap())
return;
#endif
if (test_and_clear_bit(__LINK_STATE_XOFF, dev-state))
__netif_schedule(dev);
}
By de-inlining __netif_schedule we are saving a lot of text
at each callsite of netif_wake_queue and netif_schedule.
__netif_rx_schedule is also big, and it makes more sense to keep
both of them out of line.
Patch also deinlines dev_kfree_skb_any. We can deinline dev_kfree_skb_irq
instead... oh well.
netif_device_attach/detach are not hot paths, we can deinline them too.
Signed-off-by: Denis Vlasenko [EMAIL PROTECTED]
--
vda
diff -urpN linux-2.6.16.org/include/linux/netdevice.h linux-2.6.16.deinline2/include/linux/netdevice.h
--- linux-2.6.16.org/include/linux/netdevice.h Mon Mar 20 07:53:29 2006
+++ linux-2.6.16.deinline2/include/linux/netdevice.h Mon Mar 27 13:46:15 2006
@@ -594,20 +594,7 @@ DECLARE_PER_CPU(struct softnet_data,soft
#define HAVE_NETIF_QUEUE
-static inline void __netif_schedule(struct net_device *dev)
-{
- if (!test_and_set_bit(__LINK_STATE_SCHED, dev-state)) {
- unsigned long flags;
- struct softnet_data *sd;
-
- local_irq_save(flags);
- sd = __get_cpu_var(softnet_data);
- dev-next_sched = sd-output_queue;
- sd-output_queue = dev;
- raise_softirq_irqoff(NET_TX_SOFTIRQ);
- local_irq_restore(flags);
- }
-}
+extern void __netif_schedule(struct net_device *dev);
static inline void netif_schedule(struct net_device *dev)
{
@@ -671,13 +658,7 @@ static inline void dev_kfree_skb_irq(str
/* Use this variant in places where it could be invoked
* either from interrupt or non-interrupt context.
*/
-static inline void dev_kfree_skb_any(struct sk_buff *skb)
-{
- if (in_irq() || irqs_disabled())
- dev_kfree_skb_irq(skb);
- else
- dev_kfree_skb(skb);
-}
+extern void dev_kfree_skb_any(struct sk_buff *skb);
#define HAVE_NETIF_RX 1
extern int netif_rx(struct sk_buff *skb);
@@ -735,22 +716,9 @@ static inline int netif_device_present(s
return test_bit(__LINK_STATE_PRESENT, dev-state);
}
-static inline void netif_device_detach(struct net_device *dev)
-{
- if (test_and_clear_bit(__LINK_STATE_PRESENT, dev-state)
- netif_running(dev)) {
- netif_stop_queue(dev);
- }
-}
+extern void netif_device_detach(struct net_device *dev);
-static inline void netif_device_attach(struct net_device *dev)
-{
- if (!test_and_set_bit(__LINK_STATE_PRESENT, dev-state)
- netif_running(dev)) {
- netif_wake_queue(dev);
- __netdev_watchdog_up(dev);
- }
-}
+extern void netif_device_attach(struct net_device *dev);
/*
* Network interface message level settings
@@ -818,20 +786,7 @@ static inline int netif_rx_schedule_prep
* already been called and returned 1.
*/
-static inline void __netif_rx_schedule(struct net_device *dev)
-{
- unsigned long flags;
-
- local_irq_save(flags);
- dev_hold(dev);
- list_add_tail(dev-poll_list, __get_cpu_var(softnet_data).poll_list);
- if (dev-quota 0)
- dev-quota += dev-weight;
- else
- dev-quota = dev-weight;
- __raise_softirq_irqoff(NET_RX_SOFTIRQ);
- local_irq_restore(flags);
-}
+extern void __netif_rx_schedule(struct net_device *dev);
/* Try to reschedule poll. Called by irq handler. */
diff -urpN linux-2.6.16.org/net/core/dev.c linux-2.6.16.deinline2/net/core/dev.c
--- linux-2.6.16.org/net/core/dev.c Mon Mar 20 07:53:29 2006
+++ linux-2.6.16.deinline2/net/core/dev.c Mon Mar 27 13:47:00 2006
@@ -1073,6 +1073,70 @@ void dev_queue_xmit_nit(struct sk_buff *
rcu_read_unlock();
}
+
+void __netif_schedule(struct net_device *dev)
+{
+ if (!test_and_set_bit(__LINK_STATE_SCHED, dev-state)) {
+ unsigned long flags;
+ struct softnet_data *sd;
+
+ local_irq_save(flags);
+ sd =
Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
Martin Michlmayr wrote: * Francois Romieu [EMAIL PROTECTED] [2006-03-09 23:44]: So when compiling for Cobalt, we work around the hardware bug, while for other platforms, we just disable MWI? Wouldn't it be possible to always (I mean, when a rev 65 chip is detected) work around the bug? Of course it is possible but it is not the same semantic as the initial patch (not that I know if it is right or not). So: - does the issue exist beyond Cobalt hosts ? - is the fix Cobalt-only ? I don't think anyone has replied to this message yet. My understanding is that it's not Cobalt only but a problem in a specific revision of the chip, which the Cobalt happens to use. However, I'd be glad if somone else could comment. Peter, you read the errata right? According to the errata it applies to all DEC 21143-PD and 21143-TD which are the chips with the revision code 0x41 (65). The errata states the receive buffers should not end on a cache aligned boundary when using MWI otherwise the receiver will not close the last descriptor. P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] spidernet : enable tx checksum offloading by default
This enables TX checksum offloading for the spidernet driver by default. Signed-off-by: Jens Osterkamp [EMAIL PROTECTED] Index: linux-2.6.16-rc5/drivers/net/spider_net.c === --- linux-2.6.16-rc5.orig/drivers/net/spider_net.c +++ linux-2.6.16-rc5/drivers/net/spider_net.c @@ -2086,7 +2086,7 @@ spider_net_setup_netdev(struct spider_ne spider_net_setup_netdev_ops(netdev); - netdev-features = 0; + netdev-features = NETIF_F_HW_CSUM; /* some time: NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX | * NETIF_F_HW_VLAN_FILTER */ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix memory allocation in com90xx.c
G'day,
This has been annoying me since git11, since it is not fixed yet,
(git13) I figured I would look at it and send a patch.
Someone has probably fixed this somewhere already, but like I said it
was annoying me.
snip
LD .tmp_vmlinux1
drivers/built-in.o: In function `kzalloc':
include/linux/slab.h:128: undefined reference to
`__you_cannot_kzalloc_that_much'
include/linux/slab.h:128: undefined reference to
`__you_cannot_kzalloc_that_much'
make: *** [.tmp_vmlinux1] Error 1
[EMAIL PROTECTED]:~/linux-2.6.16-git13$ grep -Rn __you_cannot_kzalloc_that_much
*
Binary file drivers/net/arcnet/com90xx.o matches
Binary file drivers/net/arcnet/built-in.o matches
Binary file drivers/net/built-in.o matches
Binary file drivers/built-in.o matches
include/linux/slab.h:127: extern void
__you_cannot_kzalloc _that_much(void);
include/linux/slab.h:128:
__you_cannot_kzalloc_that_much();
The patch below fixes the compilation with 'make allyesconfig'.
Signed-off-by: Darren Jenkins [EMAIL PROTECTED]
--- linux-2.6.16-git13/drivers/net/arcnet/com90xx.c.orig2006-03-28
01:44:44.0 +1100
+++ linux-2.6.16-git13/drivers/net/arcnet/com90xx.c 2006-03-28
01:45:47.0 +1100
@@ -125,11 +125,11 @@ static void __init com90xx_probe(void)
if (!io !irq !shmem !*device com90xx_skip_probe)
return;
- shmems = kzalloc(((0x1-0xa) / 0x800) * sizeof(unsigned long),
+ shmems = kcalloc(((0x1-0xa) / 0x800), sizeof(unsigned long),
GFP_KERNEL);
if (!shmems)
return;
- iomem = kzalloc(((0x1-0xa) / 0x800) * sizeof(void __iomem *),
+ iomem = kcalloc(((0x1-0xa) / 0x800), sizeof(void __iomem *),
GFP_KERNEL);
if (!iomem) {
kfree(shmems);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pcmcia: avoid binding hostap_cs to Orinoco cards
On Mon, Mar 27, 2006 at 01:44:44PM +0200, Sebastian wrote: commit 40e3cad61197fce63853e778db020f7637d988f2 tree 6e086c930e1aef0bb24eb61af42d1f3c1fb7d38c parent f0892b89e3c19c7d805825ca12511d26dcdf6415 author Pavel Roskin [EMAIL PROTECTED] Tue, 28 Feb 2006 11:18:31 -0500 committer Dominik Brodowski [EMAIL PROTECTED] Wed, 01 Mar 2006 11:12:00 +0100 [PATCH] pcmcia: avoid binding hostap_cs to Orinoco cards Don't just use cards with PCMCIA ID 0x0156, 0x0002. Make sure that the vendor string is Intersil or INTERSIL Signed-off-by: Pavel Roskin [EMAIL PROTECTED] Signed-off-by: Dominik Brodowski [EMAIL PROTECTED] drivers/net/wireless/hostap/hostap_cs.c |5 - 1 files changed, 4 insertions(+), 1 deletion(-) this patch seems to break my setup. The hostap_cs driver included in kernel 2.6.16 does not detect my Prism 2 WLAN card anymore, although it is *not* Orinoco. With 2.6.15.5 it still worked. This patch didn't come through me, so I don't know much about it. Hopefully Pavel or Dominik can comment? John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Fri, Mar 24, 2006 at 11:28:05PM +0100, Johannes Berg wrote: On Fri, 2006-03-24 at 09:48 -0800, Jouni Malinen wrote: Is battery use more important than accuracy of results and the amount of time needed to perform the operation? You're going to be using *more* battery when doing a passive scan because the dwell time is much much larger, and you can't power down the rx component during scan. So much for a power issue. Is this issue resolved? Shall I merge David's patch? John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce default rate to 11Mbps.
On Mon, 2006-03-27 at 11:55 -0500, John W. Linville wrote: On Sat, Mar 25, 2006 at 12:58:55AM +, David Woodhouse wrote: On Fri, 2006-03-24 at 08:18 -0800, Jouni Malinen wrote: On Thu, Mar 23, 2006 at 10:43:38PM +, David Woodhouse wrote: This patch makes us default to 11M, which ought to work for most people. Is this code supposed to work with IEEE 802.11a (which would also use OFDM modulation)? If yes, please note that 11 Mbps is not a valid IEEE 802.11a TX rate. Er, well spotted. Let's do it like this instead... Is everyone OK w/ David's latest patch? +1 looks good to me Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Mon, 2006-03-27 at 11:53 -0500, John W. Linville wrote: On Fri, Mar 24, 2006 at 11:28:05PM +0100, Johannes Berg wrote: On Fri, 2006-03-24 at 09:48 -0800, Jouni Malinen wrote: Is battery use more important than accuracy of results and the amount of time needed to perform the operation? You're going to be using *more* battery when doing a passive scan because the dwell time is much much larger, and you can't power down the rx component during scan. So much for a power issue. Is this issue resolved? Shall I merge David's patch? Yes, merge the patch. Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pcmcia: avoid binding hostap_cs to Orinoco cards
On Mon, 2006-03-27 at 11:48 -0500, John W. Linville wrote: this patch seems to break my setup. The hostap_cs driver included in kernel 2.6.16 does not detect my Prism 2 WLAN card anymore, although it is *not* Orinoco. With 2.6.15.5 it still worked. It mean hostap_cs was identifying the card solely by its numeric ID (0x0156, 0x0002) instead of the vendor strings. Since that particular numeric ID was used both by cards that are supported by hostap_cs and those that are not, it cannot be used in hostap_cs. Sebastian, please send me the output of pccardctl ident and I'll submit the patch for hostap_cs. This patch didn't come through me, so I don't know much about it. Hopefully Pavel or Dominik can comment? -- Regards, Pavel Roskin - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.16: assertion (!sk-sk_forward_alloc) failed
On 3/27/06, Phil Oester [EMAIL PROTECTED] wrote: David S. Miller wrote: E1000 has some TSO bug most likely, try reproducing with ethtool -K eth0 tso off, replacing eth0 with your actual e1000 interface name(s). That does seem to have solved the problem. Suggested next steps? Should I leave TSO disabled, or pester the e1000 maintainers? Both, probably 8) - Arnaldo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net TODO
On Mon, 20 Mar 2006 19:36:25 -0800 Stephen Hemminger wrote: On Mon, 20 Mar 2006 19:30:17 -0800 Randy.Dunlap [EMAIL PROTECTED] wrote: in Documentation/networking/TODO, the Jamal netdev Rx polling API change is done, right? (NAPI) Are any of the others done? Should this TODO file be removed or updated or reference http://vger.kernel.org/~davem/net_todo.html ? The updated version of TODO is kept on the wiki: http://linux-net.osdl.org/index.php/TODO so Dave, can you just remove Documentation/networking/TODO ? or do you want a patch for that? or want it to reference the wiki instead? --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32bit compat for rtnetlink wireless extensions?
On Sun, Mar 26, 2006 at 02:08:48PM +0200, Arnd Bergmann wrote:
I stumbled over the 'WE-20 for kernel 2.6.16' and afaict, there is no
way that IW_HEADER_TYPE_POINT rtnetlink messages can work when using
32 bit user tools on a 64 bit kernel.
Please check again ;-) I agree that it's not obvious...
For the ioctl inteface, this gets handled using the do_wireless_ioctl
function in fs/compat_ioctl.c, but we don't have a way to convert
netlink data -- it is supposed to always be compatible between
32 and 64 bit.
What is the reason for having IW_HEADER_TYPE_POINT in the first place?
Does that reason apply to both the ioctl and the netlink interface, or
can the netlink transport for wireless commands be changed so it
does not need user space pointers?
Actually, when things are passed over RtNetlink, the pointer
is removed, and the content of IW_HEADER_TYPE_POINT is moved to not
leave a gap.
The actual code for the commands is a little bit complex,
especially that the buffer is optimised. But, if you check for the
comments, you will find it. Instead, you may want to check the code
for the event, where I do the same, and which is easier to read.
The function is iwe_stream_add_point(), and you will find it
in include/net/iw_handler.h. Copy below...
I was toying with the idea of changing the
IW_HEADER_TYPE_POINT struct itself, but I discarded that because the
amount of fixing in the driver that would require.
Arnd
Thanks for the quick review, have fun...
Jean
/*--*/
/*
* Wrapper to add an short Wireless Event containing a pointer to a
* stream of events.
*/
static inline char *
iwe_stream_add_point(char * stream, /* Stream of events */
char * ends, /* End of stream */
struct iw_event *iwe, /* Payload length + flags */
char * extra) /* More payload */
{
int event_len = IW_EV_POINT_LEN + iwe-u.data.length;
/* Check if it's possible */
if(likely((stream + event_len) ends)) {
iwe-len = event_len;
memcpy(stream, (char *) iwe, IW_EV_LCP_LEN);
memcpy(stream + IW_EV_LCP_LEN,
((char *) iwe) + IW_EV_LCP_LEN + IW_EV_POINT_OFF,
IW_EV_POINT_LEN - IW_EV_LCP_LEN);
memcpy(stream + IW_EV_POINT_LEN, extra, iwe-u.data.length);
stream += event_len;
}
return stream;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Goramo PCI200SYN WAN driver subsystem ID patch
Hi Jeff,
Goramo finally got PCI subsystem ID for their PCI200SYN card. The
attached patch adds support for it - cards with old EEPROM data
will emit a warning with URL for update tool.
I plan to remove support for cards with old config sometime.
Please apply to Linux 2.6.
Thanks.
--
Krzysztof Halasa
diff --git a/drivers/net/wan/pci200syn.c b/drivers/net/wan/pci200syn.c
index eba8e5c..f485a97 100644
--- a/drivers/net/wan/pci200syn.c
+++ b/drivers/net/wan/pci200syn.c
@@ -50,10 +50,6 @@ static const char* devname = PCI200SYN
static int pci_clock_freq = 3300;
#define CLOCK_BASE pci_clock_freq
-#define PCI_VENDOR_ID_GORAMO 0x10B5 /* uses PLX:9050 ID - this card */
-#define PCI_DEVICE_ID_PCI200SYN 0x9050 /* doesn't have its own ID */
-
-
/*
* PLX PCI9052 local configuration and shared runtime registers.
* This structure can be used to access 9052 registers (memory mapped).
@@ -262,7 +258,7 @@ static void pci200_pci_remove_one(struct
int i;
card_t *card = pci_get_drvdata(pdev);
- for(i = 0; i 2; i++)
+ for (i = 0; i 2; i++)
if (card-ports[i].card) {
struct net_device *dev = port_to_dev(card-ports[i]);
unregister_hdlc_device(dev);
@@ -385,6 +381,15 @@ static int __devinit pci200_pci_init_one
%u RX packets rings\n, ramsize / 1024, ramphys,
pdev-irq, card-tx_ring_buffers, card-rx_ring_buffers);
+ if (pdev-subsystem_device == PCI_DEVICE_ID_PLX_9050) {
+ printk(KERN_ERR Detected PCI200SYN card with old
+ configuration data.\n);
+ printk(KERN_ERR See http://www.kernel.org/pub/;
+ linux/utils/net/hdlc/pci200syn/ for update.\n);
+ printk(KERN_ERR The card will stop working with
+ future versions of Linux if not updated.\n);
+ }
+
if (card-tx_ring_buffers 1) {
printk(KERN_ERR pci200syn: RAM test failed\n);
pci200_pci_remove_one(pdev);
@@ -396,7 +401,7 @@ static int __devinit pci200_pci_init_one
writew(readw(p) | 0x0040, p);
/* Allocate IRQ */
- if(request_irq(pdev-irq, sca_intr, SA_SHIRQ, devname, card)) {
+ if (request_irq(pdev-irq, sca_intr, SA_SHIRQ, devname, card)) {
printk(KERN_WARNING pci200syn: could not allocate IRQ%d.\n,
pdev-irq);
pci200_pci_remove_one(pdev);
@@ -406,7 +411,7 @@ static int __devinit pci200_pci_init_one
sca_init(card, 0);
- for(i = 0; i 2; i++) {
+ for (i = 0; i 2; i++) {
port_t *port = card-ports[i];
struct net_device *dev = port_to_dev(port);
hdlc_device *hdlc = dev_to_hdlc(dev);
@@ -425,7 +430,7 @@ static int __devinit pci200_pci_init_one
hdlc-xmit = sca_xmit;
port-settings.clock_type = CLOCK_EXT;
port-card = card;
- if(register_hdlc_device(dev)) {
+ if (register_hdlc_device(dev)) {
printk(KERN_ERR pci200syn: unable to register hdlc
device\n);
port-card = NULL;
@@ -445,8 +450,10 @@ static int __devinit pci200_pci_init_one
static struct pci_device_id pci200_pci_tbl[] __devinitdata = {
- { PCI_VENDOR_ID_GORAMO, PCI_DEVICE_ID_PCI200SYN, PCI_ANY_ID,
- PCI_ANY_ID, 0, 0, 0 },
+ { PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9050, PCI_VENDOR_ID_PLX,
+ PCI_DEVICE_ID_PLX_9050, 0, 0, 0 },
+ { PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9050, PCI_VENDOR_ID_PLX,
+ PCI_DEVICE_ID_PLX_PCI200SYN, 0, 0, 0 },
{ 0, }
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 751eea5..dcc58aa 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -925,6 +925,7 @@
#define PCI_DEVICE_ID_PLX_DJINN_ITOO 0x1151
#define PCI_DEVICE_ID_PLX_R753 0x1152
#define PCI_DEVICE_ID_PLX_OLITEC 0x1187
+#define PCI_DEVICE_ID_PLX_PCI200SYN 0x3196
#define PCI_DEVICE_ID_PLX_9050 0x9050
#define PCI_DEVICE_ID_PLX_9080 0x9080
#define PCI_DEVICE_ID_PLX_GTEK_SERIAL2 0xa001
Please pull 'upstream' branch of wireless-2.6
This is the merge of the bcm43xx driver, along with a variety of smaller changes. I would really like to see this in 2.6.17 if at all possible. Thanks! John --- The following changes since commit 5d5d7727a8cde78f798ecf04bac8031eff536f9d: David S. Miller: [SPARC64]: Kill duplicate exports of string library functions. are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 upstream Adrian Bunk: PCMCIA_SPECTRUM must select FW_LOADER Danny van Dyk: Sync bcm43xx_phy_initb6() with specs David Woodhouse: softmac: reduce scan dwell time softmac: reduce default rate to 11Mbps. Jean Tourrilhes: zd1201 wireless stat update John W. Linville: wireless: import bcm43xx sources bcm43xx: patch Kconfig and wireless/Makefile for import Jouni Malinen: hostap: Make hostap_tx_encrypt() static hostap: Fix EAPOL frame encryption Larry Finger: Minor (janitorial) change to ieee80211 Michael Buesch: bcm43xx: sync with svn.berlios.de bcm43xx: remove linux version compatibility code. bcm43xx: Move README file to Documentation directory. bcm43xx: remove redundant COPYING file. bcm43xx: add DEBUG Kconfig option. Also fix indention. bcm43xx: Fix makefile. Remove all the out-of-tree stuff. bcm43xx: Add more initvals sanity checks and error out, if one sanity check fails. bcm43xx: Remove function bcm43xx_channel_is_allowed() bcm43xx: basic ethtool support bcm43xx: Wireless Ext update bcm43xx: fix txpower reporting in WE. bcm43xx: enable SPROM writing. bcm43xx: heavily increase mac_suspend timeout. bcm43xx: fix compiletime warning (phy_xmitpower) bcm43xx: remove WX debugging. bcm43xx: Partially fix PIO code. Add Kconfig option for PIO or DMA mode (or both). bcm43xx: add a note that not all devices support PIO. Apple Airport: Add Kconfig note that the bcm43xx driver has to be used for Airport Extreme cards. bcm43xx: update README bcm43xx: fix LED code. bcm43xx: rewrite and simplify the periodic task handling. bcm43xx: Code cleanups. This removes various inline statements and reduces codesize. bcm43xx: Move sprom lowlevel reading/writing to its own functions. bcm43xx: make bcm43xx_sprom_crc() static. bcm43xx: split the channel helper functions, so that they can be used without a valid running core. bcm43xx: remove old unused struct. bcm43xx: Fix Kconfig typo (transfer mode default) bcm43xx: Workaround init_board vs IRQ race. bcm43xx: move initialized = 1 to the end of init_board. bcm43xx: add assert(bcm-initialized) to periodic_tasks_setup(). bcm43xx: Move TX/RX related functions to its own file. Add basic RTS/CTS code. bcm43xx: Add sysfs attributes for device specific tunables. bcm43xx: Set both, the DMAmask and the coherent DMAmask. bcm43xx: Abstract the locking mechanism. bcm43xx: Remove the mmio access printing facility overhead. bcm43xx: fix some stuff, add a few missing mmiowb(), remove dead code. bcm43xx: receive TX status on MMIO or DMA unconditionally regarding the 80211 core rev. bcm43xx: add functions bcm43xx_dma_read/write, bcm43xx_dma_tx_suspend/resume. bcm43xx: reduce the size of bcm43xx_private by removing unneeded members. bcm43xx: Fix crash on ifdown, by being careful in pio/dma freeing. bcm43xx: Remove the workaround in dummy_transmission, bcm43xx: Do boardflags workarounds for specific boards. bcm43xx: properly mask txctl1 before writing it to hardware. bcm43xx: remove check for mmio length, as it differs among platforms. (especially embedded) bcm43xx: fix some gpio register trashing (hopefully :D) bcm43xx: merge all iwmode code into the set_iwmode function. bcm43xx: some IRQ handler cleanups. bcm43xx: set default attenuation values. bcm43xx: sync interference mitigation code to the specs. bcm43xx: fix nrssi_threshold calculation. bcm43xx: add useless and broken statistics stuff. People seem to want it. well... bcm43xx: get rid of /* vim: ... lines at the end of several files. bcm43xx: fix include issues on some platforms. bcm43xx: remove some compilerwarnings. bcm43xx: fix the remaining sparse warnings. bcm43xx: sync GPHY init with the specs. bcm43xx: don't set the channel on a device, which is down. Pete Zaitcev: bcm43xx: fix DMA TX skb freeing in case of fragmented packets. Documentation/networking/bcm43xx.txt| 36 drivers/net/wireless/Kconfig|7 drivers/net/wireless/Makefile |1 drivers/net/wireless/bcm43xx/Kconfig| 62 drivers/net/wireless/bcm43xx/Makefile | 12 drivers/net/wireless/bcm43xx/bcm43xx.h | 926 +
Re: net TODO
From: Randy.Dunlap [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 10:40:42 -0800 so Dave, can you just remove Documentation/networking/TODO ? or do you want a patch for that? I'll kill it off. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] acenic: fix section mismatches
Randy == Randy Dunlap [EMAIL PROTECTED] writes: Randy From: Randy Dunlap [EMAIL PROTECTED] Fix section mismatches Randy in acenic driver: WARNING: drivers/net/acenic.o - Section Randy mismatch: reference to .init.data:tigon2FwText from .text between Randy 'acenic_probe_one' (at offset 0x2409) and 'ace_interrupt' Randy WARNING: drivers/net/acenic.o - Section mismatch: reference to Randy .init.data:tigon2FwRodata from .text between 'acenic_probe_one' Randy (at offset 0x2422) and 'ace_interrupt' Randy Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- Acked-by: Jes Sorensen [EMAIL PROTECTED] Jes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] acenic: fix section mismatches
On Mon, Mar 27, 2006 at 12:26:12PM -0800, Randy.Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Fix section mismatches in acenic driver: WARNING: drivers/net/acenic.o - Section mismatch: reference to .init.data:tigon2FwText from .text between 'acenic_probe_one' (at offset 0x2409) and 'ace_interrupt' WARNING: drivers/net/acenic.o - Section mismatch: reference to .init.data:tigon2FwRodata from .text between 'acenic_probe_one' (at offset 0x2422) and 'ace_interrupt' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] I'm glad to see these fixes appear. Did you manage to compile with and without HOTPLUG enabled? This is important since HOTPLUG redefined __dev* to nothing = no section mismatchs. Sam - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.16: assertion (!sk-sk_forward_alloc) failed
On 3/27/06, Arnaldo Carvalho de Melo [EMAIL PROTECTED] wrote: On 3/27/06, Phil Oester [EMAIL PROTECTED] wrote: David S. Miller wrote: E1000 has some TSO bug most likely, try reproducing with ethtool -K eth0 tso off, replacing eth0 with your actual e1000 interface name(s). That does seem to have solved the problem. Suggested next steps? Should I leave TSO disabled, or pester the e1000 maintainers? Both, probably 8) I'm here, and pesterable. I don't understand the connection between the assertions mentioned and TSO. Can someone explain to me the possible relation of e1000 (and maybe TSO) and sk-sk_forward_alloc? I looked through the code and it appears that sk_forward_alloc tracks memory allocations (truesize) for sockets. Its not immediately clear whether its transmit or receive or both. I know I can't ask you to solve our bug, but I'm looking for some clues about a 1) reproducible bug 2) area of the driver I might look at (transmit or receive - TSO implies transmit, but we don't mess with truesize in transmit) The reports of this seem awful intermittent and on the surface it seems like a stack bug. I need some help connecting the dots. Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: via_rhine modules error on 2.6.16 with mii-tool
On Fri, 24 Mar 2006 16:49:10 +0100, Marco Berizzi wrote: Hello evebody. I get this error on linux vanilla 2.6.16 with via_rhine module loaded when I run mii-tool: That was caused by a recent change that replaced an mdelay with msleep. netdev_ioctl and friends (ethtool calls, too) are known to grab a spin lock before they do much of anything, and they hang onto it until they're done. They also call mdio_read/write, which requires millisecond delays on Rhine-I. So on Rhine-I with a 2.6.15+ kernel, the driver ends up calling msleep while holding a spin lock -- hence the stack dump. I wonder if low latency for ancient Rhine-I chips is worth the trouble. Roger - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32bit compat for rtnetlink wireless extensions?
Am Monday 27 March 2006 20:42 schrieb Jean Tourrilhes: Actually, when things are passed over RtNetlink, the pointer is removed, and the content of IW_HEADER_TYPE_POINT is moved to not leave a gap. Ah, that makes sense, thanks for the explanation. So if the wireless ioctl interface ever got retired, that code could get simplified a lot to just pass around a flat data structure, right? Arnd - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] acenic: fix section mismatches
On Mon, 27 Mar 2006 22:36:25 +0200 Sam Ravnborg wrote: On Mon, Mar 27, 2006 at 12:26:12PM -0800, Randy.Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Fix section mismatches in acenic driver: WARNING: drivers/net/acenic.o - Section mismatch: reference to .init.data:tigon2FwText from .text between 'acenic_probe_one' (at offset 0x2409) and 'ace_interrupt' WARNING: drivers/net/acenic.o - Section mismatch: reference to .init.data:tigon2FwRodata from .text between 'acenic_probe_one' (at offset 0x2422) and 'ace_interrupt' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] I'm glad to see these fixes appear. Did you manage to compile with and without HOTPLUG enabled? This is important since HOTPLUG redefined __dev* to nothing = no section mismatchs. Nope, only with HOTPLUG enabled. I can try without also (but disabling it is a pain :). --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Sun RIO Gem xmit underrun problem...
I recently rebuilt a SunBlade 2000 system that was running Solaris 8 to Gentoo 2006.0. The system sports a Sun RIO GEM NIC, and worked quite well for the first few days, however, we didn't hit it hard during that time period either. The systems primary task is to be our source repository, and so needs to be network enabled. The system was initially setup on 3/9/2006, and ran fine until 3/15/2006 when we started getting the below error messages: Mar 15 15:39:25 tsdfft1 NETDEV WATCHDOG: eth0: transmit timed out Mar 15 15:39:25 tsdfft1 eth0: transmit timed out, resetting Mar 15 15:39:25 tsdfft1 eth0: TX_STATE[003ffc05:0001:0019] Mar 15 15:39:25 tsdfft1 eth0: RX_STATE[0100c805:0001:0021] Mar 15 15:39:25 tsdfft1 eth0: Link is up at 100 Mbps, half-duplex. Mar 15 15:39:25 tsdfft1 eth0: Pause is disabled And: Mar 15 16:11:58 tsdfft1 eth0: TX MAC xmit underrun. We're presently using the 2.6.16 kernel (vanilla) with sungem driver version 0.98. We have also seen this issue with the 2.6.15.6 kernel (vanilla) and the 2.4.32_r2 kernel (provided by Gentoo 2006.0). The first one is spuratic, but happens from time to time. (Same error message everytime, save date time.) The second one is the most reproducible as all I have to do is try to pull down source from the repository (hosted on Apache2 via WebDAV), and after about 6 MiB of data transfer, the link will die until an ifconfig down/up is done, when it will go for a while longer and then require a system reboot. In researching the issue, I discovered that there is one of several issues at play - the card is going bad, or there is a driver problem. I found a link to an xmit underrun issue for Solaris, but was unable to access it due to it being locked under sunsolve.sun.com. So I have no guarantee that going back to Solaris will solve the issue either. I have had a hard time finding an xmit underrun issue under Linux, most searches result in references to where the message is generated from and not from users trying to find solutions to the problem. I did, however, notice that there was a similar problem with overflows on the RX portion of the chip, which was solved through resetting the chip's RX unit via gem_rxmac_reset(). My first attempt at a fix was to modify the driver at the point of issue to schedule a reset, based on code elsewhere in the driver. (See sungem-fix1.patch.txt) At first this patch did not seem to work, however, I have been running the kernel with it for about a week now, and at least SSH and Apache seem to keep running. So I do think it at least helped to improve the situation, but it does not solve the problem on the Subversion side (Apache/WebDAV) which still dies after issues (just tested to make sure). I then tried building a solution based on the gem_rxmac_reset() and the various init functions, and produced gem_txmac_reset(). However, my first use locked up the kernel. It might be just that I tried to gain a lock when I shouldn't have (I did try to get the lock and tx_lock for the driver). However, I am not sure that I did it correctly. I would very much appreciate it if someone who is more familiar with the sungem driver would look at the patches and verify that (a) it is the correct thing to do, and (b) I did it correctly. I am aware that the network the system is running on is suppose to be full duplex, 100 Mbps. However, I have noticed that the card/driver seems to think it is half-duplex. Could this simply be a duplexing issue? I have no control of the switch it is plugged into (so far as settings go), but have not been able to find a way to get ifconfig to force it to full-duplex. (We've typically built the driver into the kernel.) If there is any information that I missed which would be helpful, please let me know and I will be glad to pass on what I can. Patches and additional error log information on eth0 are available at the following URL: http://tinyurl.com/hxfbp Summary of system information: System: Sun Microsystem's SunBlade 2000 Purchased: roughly 11/03. Processor: UltraSparcIII+/cheetah+/sparc64 NIC: Sun RIO GEM 10/100, built-in on SunBlade 2000 Linux Distro: Gentoo 2006.0 Kernel Versions: 2.6.16, 2.6.15.6, Gentoo's 2.4.32_r2 Specific error: NETDEV WATCHDOG: eth0: transmit timed out eth0: transmit timed out,resetting eth0: TX_STATE[003ffc05:0001:0019] eth0: RX_STATE[0100c805:0001:0021] eth0: Link is up at 100 Mbps,half-duplex. eth0: Pause is disabled ... eth0: TX MAC xmit underrun. Any advice, help, etc. would be greatly appreciated. TIA, Benjamen R. Meyer - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH netdev-2.6.git] bonding: support carrier state for master
Add support for the bonding master to specify its carrier state
based upon the state of the slaves. For 802.3ad, the bond is up if
there is an active, parterned aggregator. For other modes, the bond is
up if any slaves are up. Updates driver version to 3.0.3.
Based on a patch by jamal [EMAIL PROTECTED].
Signed-off-by: Jay Vosburgh [EMAIL PROTECTED]
--- n26u-carrier/drivers/net/bonding/bond_3ad.c 2006/03/27 19:43:21 1.1
+++ n26u-carrier/drivers/net/bonding/bond_3ad.c 2006/03/27 20:21:19
@@ -2294,6 +2294,34 @@ void bond_3ad_handle_link_change(struct
port-sm_vars |= AD_PORT_BEGIN;
}
+/*
+ * set link state for bonding master: if we have an active partnered
+ * aggregator, we're up, if not, we're down. Presumes that we cannot
+ * have an active aggregator if there are no slaves with link up.
+ *
+ * Called by bond_set_carrier(). Return zero if carrier state does not
+ * change, nonzero if it does.
+ */
+int bond_3ad_set_carrier(struct bonding *bond)
+{
+ struct aggregator *agg;
+
+ agg = __get_active_agg((SLAVE_AD_INFO(bond-first_slave).aggregator));
+ if (agg MAC_ADDRESS_COMPARE(agg-partner_system, null_mac_addr)) {
+ if (!netif_carrier_ok(bond-dev)) {
+ netif_carrier_on(bond-dev);
+ return 1;
+ }
+ return 0;
+ }
+
+ if (netif_carrier_ok(bond-dev)) {
+ netif_carrier_off(bond-dev);
+ return 1;
+ }
+ return 0;
+}
+
/**
* bond_3ad_get_active_agg_info - get information of the active aggregator
* @bond: bonding struct to work on
--- n26u-carrier/drivers/net/bonding/bond_3ad.h 2006/03/27 19:43:21 1.1
+++ n26u-carrier/drivers/net/bonding/bond_3ad.h 2006/03/27 19:43:41
@@ -283,5 +283,6 @@ void bond_3ad_handle_link_change(struct
int bond_3ad_get_active_agg_info(struct bonding *bond, struct ad_info
*ad_info);
int bond_3ad_xmit_xor(struct sk_buff *skb, struct net_device *dev);
int bond_3ad_lacpdu_recv(struct sk_buff *skb, struct net_device *dev, struct
packet_type* ptype, struct net_device *orig_dev);
+int bond_3ad_set_carrier(struct bonding *bond);
#endif //__BOND_3AD_H__
--- n26u-carrier/drivers/net/bonding/bond_main.c2006/03/27 19:43:21
1.1
+++ n26u-carrier/drivers/net/bonding/bond_main.c2006/03/27 21:03:37
@@ -559,6 +559,42 @@ out:
/*--- Link status ---*/
/*
+ * Set the carrier state for the master according to the state of its
+ * slaves. If any slaves are up, the master is up. In 802.3ad mode,
+ * do special 802.3ad magic.
+ *
+ * Returns zero if carrier state does not change, nonzero if it does.
+ */
+static int bond_set_carrier(struct bonding *bond)
+{
+ struct slave *slave;
+ int i;
+
+ if (bond-slave_cnt == 0)
+ goto down;
+
+ if (bond-params.mode == BOND_MODE_8023AD)
+ return bond_3ad_set_carrier(bond);
+
+ bond_for_each_slave(bond, slave, i) {
+ if (slave-link == BOND_LINK_UP) {
+ if (!netif_carrier_ok(bond-dev)) {
+ netif_carrier_on(bond-dev);
+ return 1;
+ }
+ return 0;
+ }
+ }
+
+down:
+ if (netif_carrier_ok(bond-dev)) {
+ netif_carrier_off(bond-dev);
+ return 1;
+ }
+ return 0;
+}
+
+/*
* Get link speed and duplex from the slave's base driver
* using ethtool. If for some reason the call fails or the
* values are invalid, fake speed and duplex to 100/Full
@@ -1074,10 +1110,24 @@ void bond_change_active_slave(struct bon
void bond_select_active_slave(struct bonding *bond)
{
struct slave *best_slave;
+ int rv;
best_slave = bond_find_best_slave(bond);
if (best_slave != bond-curr_active_slave) {
bond_change_active_slave(bond, best_slave);
+ rv = bond_set_carrier(bond);
+ if (!rv)
+ return;
+
+ if (netif_carrier_ok(bond-dev)) {
+ printk(KERN_INFO DRV_NAME
+ : %s: first active interface up!\n,
+ bond-dev-name);
+ } else {
+ printk(KERN_INFO DRV_NAME : %s:
+ now running without any active interface !\n,
+ bond-dev-name);
+ }
}
}
@@ -1458,10 +1508,14 @@ int bond_enslave(struct net_device *bond
if (((!bond-curr_active_slave) ||
(bond-curr_active_slave-dev-priv_flags
IFF_SLAVE_INACTIVE))
(new_slave-link != BOND_LINK_DOWN)) {
- dprintk(This is the first active slave\n);
/* first slave or no active slave yet, and this link
Re: [PATCH] Minor (janitorial) change to ieee80211
On Fri, Mar 03, 2006 at 04:21:55PM -0600, Larry Finger wrote: The attached patch removes a potential problem from ieee80211_wx.c, by changing the name of routine ipw2100_translate_scan to ieee80211_translate_scan. The problem is minor as the routine is declared static; however, if it were made global, it would pollute the namespace. Merged to the 'upstream' branch of wireless-2.6. Thanks! John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce default rate to 11Mbps.
On Mon, Mar 27, 2006 at 12:25:47PM -0500, Dan Williams wrote: On Mon, 2006-03-27 at 11:55 -0500, John W. Linville wrote: On Sat, Mar 25, 2006 at 12:58:55AM +, David Woodhouse wrote: On Fri, 2006-03-24 at 08:18 -0800, Jouni Malinen wrote: On Thu, Mar 23, 2006 at 10:43:38PM +, David Woodhouse wrote: This patch makes us default to 11M, which ought to work for most people. Is this code supposed to work with IEEE 802.11a (which would also use OFDM modulation)? If yes, please note that 11 Mbps is not a valid IEEE 802.11a TX rate. Er, well spotted. Let's do it like this instead... Is everyone OK w/ David's latest patch? +1 looks good to me Merged to the 'upstream' branch of wireless-2.6. Thanks! John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Mon, Mar 27, 2006 at 12:24:37PM -0500, Dan Williams wrote: On Mon, 2006-03-27 at 11:53 -0500, John W. Linville wrote: On Fri, Mar 24, 2006 at 11:28:05PM +0100, Johannes Berg wrote: On Fri, 2006-03-24 at 09:48 -0800, Jouni Malinen wrote: Is battery use more important than accuracy of results and the amount of time needed to perform the operation? You're going to be using *more* battery when doing a passive scan because the dwell time is much much larger, and you can't power down the rx component during scan. So much for a power issue. Is this issue resolved? Shall I merge David's patch? Yes, merge the patch. Merged to the 'upstream' branch of wireless-2.6. Thanks! John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Host AP driver update
On Fri, Mar 24, 2006 at 09:24:53PM -0800, Jouni Malinen wrote: Please apply following two patches to Host AP driver in wireless-2.6. The second patch (Fix EAPOL frame encryption) is a trivial bug fix for a somewhat unfortunate bug and it could be a good candidate for a 2.6.16.x stable release ([EMAIL PROTECTED] cc'ed). Merged to the 'upstream' branch of wireless-2.6. Thanks! John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6-softmac patch: prism54usb update
On Fri, Mar 24, 2006 at 03:26:00PM -0800, Pete Zaitcev wrote: On Fri, 24 Mar 2006 17:52:25 -0500, John W. Linville [EMAIL PROTECTED] wrote: I should be able to take the master-based patches you sent me and massage them into wireless-2.6 -- no need for you to do it. Thanks. BTW, I talked to DaveM a minute ago on an unrelated subject, and we touched on code quality and dead code. Considering his position, prism54usb definitely cannot go to Linus right now, but I'll be working on fixing it and pummeling you with patches. That sounds great. BTW, I massaged the patches you had sent me and got them consolidated with the older patches and pushed out to the 'master' branch of wireless-2.6. Please take a look to make sure that everything looks right. Thanks! John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] acenic: fix section mismatches
On Mon, 27 Mar 2006 13:19:41 -0800 Randy.Dunlap wrote: On Mon, 27 Mar 2006 22:36:25 +0200 Sam Ravnborg wrote: On Mon, Mar 27, 2006 at 12:26:12PM -0800, Randy.Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Fix section mismatches in acenic driver: WARNING: drivers/net/acenic.o - Section mismatch: reference to .init.data:tigon2FwText from .text between 'acenic_probe_one' (at offset 0x2409) and 'ace_interrupt' WARNING: drivers/net/acenic.o - Section mismatch: reference to .init.data:tigon2FwRodata from .text between 'acenic_probe_one' (at offset 0x2422) and 'ace_interrupt' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] I'm glad to see these fixes appear. Did you manage to compile with and without HOTPLUG enabled? This is important since HOTPLUG redefined __dev* to nothing = no section mismatchs. Nope, only with HOTPLUG enabled. I can try without also (but disabling it is a pain :). ugh, FW_LOADER is the beast (not CONFIG_HOTPLUG itself). Sam, I am now seeing this error (not a WARNING like the previous ones were): drivers/net/typhoon.c:137: error: version causes a section type conflict but I don't see a real problem in the driver source file. Ideas, anyone? --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6-softmac patch: prism54usb update
On Mon, 27 Mar 2006 16:59:19 -0500, John W. Linville [EMAIL PROTECTED] wrote: That sounds great. BTW, I massaged the patches you had sent me and got them consolidated with the older patches and pushed out to the 'master' branch of wireless-2.6. Please take a look to make sure that everything looks right. I pulled a couple of hours ago, and it seems like an old version again, though linux/usb/net2280.h is there and is correct. I'm going to send the remainder in smaller, self-consistent chunks. Thanks, -- Pete - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6-softmac patch: prism54usb update
On Mon, Mar 27, 2006 at 02:10:58PM -0800, Pete Zaitcev wrote: On Mon, 27 Mar 2006 16:59:19 -0500, John W. Linville [EMAIL PROTECTED] wrote: That sounds great. BTW, I massaged the patches you had sent me and got them consolidated with the older patches and pushed out to the 'master' branch of wireless-2.6. Please take a look to make sure that everything looks right. I pulled a couple of hours ago, and it seems like an old version again, though linux/usb/net2280.h is there and is correct. I'm going to send the remainder in smaller, self-consistent chunks. I only pushed the updated prism54usb stuff within the last hour... John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 32bit compat for rtnetlink wireless extensions?
On Mon, Mar 27, 2006 at 11:10:44PM +0200, Arnd Bergmann wrote: Am Monday 27 March 2006 20:42 schrieb Jean Tourrilhes: Actually, when things are passed over RtNetlink, the pointer is removed, and the content of IW_HEADER_TYPE_POINT is moved to not leave a gap. Ah, that makes sense, thanks for the explanation. So if the wireless ioctl interface ever got retired, that code could get simplified a lot to just pass around a flat data structure, right? Arnd Actually, it could be removed *now*. You would just have to fix all wireless drivers in existence. I will scratch my head to see if we could plan a smooth transition. Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] PCMCIA_SPECTRUM must select FW_LOADER
On Fri, Mar 24, 2006 at 05:56:19PM +0100, Adrian Bunk wrote: PCMCIA_SPECTRUM must select FW_LOADER. Reported by Alexander E. Patrakov [EMAIL PROTECTED]. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Merged to the 'upstream' branch of wireless-2.6. Thanks! John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.16] zd1201 wireless stat update
On Mon, Mar 27, 2006 at 04:57:01PM -0500, John W. Linville wrote: On Fri, Mar 24, 2006 at 04:45:24PM -0800, Jean Tourrilhes wrote: Hi all, The dev-get_wireless_stats field is deprecated and slowly be surely going away. Most drivers have been updated months ago. Actually, there is an annoying message for driver still using it, but it seems that user of zd1201 were not annoyed enough ;-) Patch was compiled on 2.6.16. I don't have hardware, so it's not tested, but I can't see how I could have messed up. Regards, Jean Merged to the 'upstream' branch of wireless-2.6. Thanks! John Wonderful ;-) Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] acenic: fix section mismatches
On Mon, 27 Mar 2006 13:19:41 -0800 Randy.Dunlap wrote: On Mon, 27 Mar 2006 22:36:25 +0200 Sam Ravnborg wrote: On Mon, Mar 27, 2006 at 12:26:12PM -0800, Randy.Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Fix section mismatches in acenic driver: WARNING: drivers/net/acenic.o - Section mismatch: reference to .init.data:tigon2FwText from .text between 'acenic_probe_one' (at offset 0x2409) and 'ace_interrupt' WARNING: drivers/net/acenic.o - Section mismatch: reference to .init.data:tigon2FwRodata from .text between 'acenic_probe_one' (at offset 0x2422) and 'ace_interrupt' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] I'm glad to see these fixes appear. Did you manage to compile with and without HOTPLUG enabled? This is important since HOTPLUG redefined __dev* to nothing = no section mismatchs. Nope, only with HOTPLUG enabled. I can try without also (but disabling it is a pain :). With HOTPLUG disabled, there are no section warnings before or after this patch. --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] acenic: fix section mismatches
On Mon, 27 Mar 2006 14:11:56 -0800 Randy.Dunlap wrote: On Mon, 27 Mar 2006 13:19:41 -0800 Randy.Dunlap wrote: On Mon, 27 Mar 2006 22:36:25 +0200 Sam Ravnborg wrote: On Mon, Mar 27, 2006 at 12:26:12PM -0800, Randy.Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Fix section mismatches in acenic driver: WARNING: drivers/net/acenic.o - Section mismatch: reference to .init.data:tigon2FwText from .text between 'acenic_probe_one' (at offset 0x2409) and 'ace_interrupt' WARNING: drivers/net/acenic.o - Section mismatch: reference to .init.data:tigon2FwRodata from .text between 'acenic_probe_one' (at offset 0x2422) and 'ace_interrupt' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] I'm glad to see these fixes appear. Did you manage to compile with and without HOTPLUG enabled? This is important since HOTPLUG redefined __dev* to nothing = no section mismatchs. Nope, only with HOTPLUG enabled. I can try without also (but disabling it is a pain :). ugh, FW_LOADER is the beast (not CONFIG_HOTPLUG itself). Sam, I am now seeing this error (not a WARNING like the previous ones were): drivers/net/typhoon.c:137: error: version causes a section type conflict but I don't see a real problem in the driver source file. Ideas, anyone? This happens for typhoon (above) as well as: drivers/net/natsemi.c:241: error: version causes a section type conflict drivers/net/bnx2.c:66: error: version causes a section type conflict drivers/net/starfire.c:338: error: version causes a section type conflict Is this (just) a gcc problem or do other people also see this? Changing version to another name does not help. --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6-softmac patch: prism54usb update
On Mon, 27 Mar 2006 17:12:02 -0500, John W. Linville [EMAIL PROTECTED] wrote: I pulled a couple of hours ago, and it seems like an old version again, though linux/usb/net2280.h is there and is correct. I'm going to send the remainder in smaller, self-consistent chunks. I only pushed the updated prism54usb stuff within the last hour... Heh, a race! Thanks a lot, everything is fine now. -- Pete - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.16: assertion (!sk-sk_forward_alloc) failed
From: Jesse Brandeburg [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 12:39:43 -0800 The reports of this seem awful intermittent and on the surface it seems like a stack bug. I need some help connecting the dots. That assertion would trigger if the driver caused a double-free of the SKB, or somehow otherwise modified the SKB from it's original form at transmit time. For example, if you were to move the page offset and length pointers around (to work around a hw bug or similar), it could break the accounting if not done correctly. There was a recent case of a use-after-free in the transmit path, if you remember, where -EFAULT was being returned from the -hard_start_xmit() method of the e1000 driver instead of a proper NETDEV_TX_* value, which causes the caller to think the packet had not been freed, when in fact it was, so it would loop and try to resend the freed SKB. There may be other kinds of bugs lurking in the e1000 transmit path. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] tg3: Fix probe failure due to invalid MAC address
Some older bootcode in some devices may report 0 MAC address in
SRAM when booting up from low power state. This patch fixes the
problem by checking for a valid MAC address in SRAM and falling back
to NVRAM if necessary.
Thanks to walt [EMAIL PROTECTED] for reporting the problem
and helping to debug it.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index b547332..c41dbb0 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -10531,6 +10531,7 @@ static int __devinit tg3_get_device_addr
{
struct net_device *dev = tp-dev;
u32 hi, lo, mac_offset;
+ int addr_ok = 0;
#ifdef CONFIG_SPARC64
if (!tg3_get_macaddr_sparc(tp))
@@ -10560,29 +10561,34 @@ static int __devinit tg3_get_device_addr
dev-dev_addr[3] = (lo 16) 0xff;
dev-dev_addr[4] = (lo 8) 0xff;
dev-dev_addr[5] = (lo 0) 0xff;
- }
- /* Next, try NVRAM. */
- else if (!(tp-tg3_flags TG3_FLG2_SUN_570X)
-!tg3_nvram_read(tp, mac_offset + 0, hi)
-!tg3_nvram_read(tp, mac_offset + 4, lo)) {
- dev-dev_addr[0] = ((hi 16) 0xff);
- dev-dev_addr[1] = ((hi 24) 0xff);
- dev-dev_addr[2] = ((lo 0) 0xff);
- dev-dev_addr[3] = ((lo 8) 0xff);
- dev-dev_addr[4] = ((lo 16) 0xff);
- dev-dev_addr[5] = ((lo 24) 0xff);
- }
- /* Finally just fetch it out of the MAC control regs. */
- else {
- hi = tr32(MAC_ADDR_0_HIGH);
- lo = tr32(MAC_ADDR_0_LOW);
- dev-dev_addr[5] = lo 0xff;
- dev-dev_addr[4] = (lo 8) 0xff;
- dev-dev_addr[3] = (lo 16) 0xff;
- dev-dev_addr[2] = (lo 24) 0xff;
- dev-dev_addr[1] = hi 0xff;
- dev-dev_addr[0] = (hi 8) 0xff;
+ /* Some old bootcode may report a 0 MAC address in SRAM */
+ addr_ok = is_valid_ether_addr(dev-dev_addr[0]);
+ }
+ if (!addr_ok) {
+ /* Next, try NVRAM. */
+ if (!(tp-tg3_flags TG3_FLG2_SUN_570X)
+ !tg3_nvram_read(tp, mac_offset + 0, hi)
+ !tg3_nvram_read(tp, mac_offset + 4, lo)) {
+ dev-dev_addr[0] = ((hi 16) 0xff);
+ dev-dev_addr[1] = ((hi 24) 0xff);
+ dev-dev_addr[2] = ((lo 0) 0xff);
+ dev-dev_addr[3] = ((lo 8) 0xff);
+ dev-dev_addr[4] = ((lo 16) 0xff);
+ dev-dev_addr[5] = ((lo 24) 0xff);
+ }
+ /* Finally just fetch it out of the MAC control regs. */
+ else {
+ hi = tr32(MAC_ADDR_0_HIGH);
+ lo = tr32(MAC_ADDR_0_LOW);
+
+ dev-dev_addr[5] = lo 0xff;
+ dev-dev_addr[4] = (lo 8) 0xff;
+ dev-dev_addr[3] = (lo 16) 0xff;
+ dev-dev_addr[2] = (lo 24) 0xff;
+ dev-dev_addr[1] = hi 0xff;
+ dev-dev_addr[0] = (hi 8) 0xff;
+ }
}
if (!is_valid_ether_addr(dev-dev_addr[0])) {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] tg3: Fix bug in 40-bit DMA workaround code
Need to check the TG3_FLAG_40BIT_DMA_BUG flag in the workaround code
path instead of device flags.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c41dbb0..0fafc52 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3600,7 +3600,7 @@ static inline int tg3_40bit_overflow_tes
int len)
{
#if defined(CONFIG_HIGHMEM) (BITS_PER_LONG == 64)
- if (tp-tg3_flags2 TG3_FLG2_5780_CLASS)
+ if (tp-tg3_flags TG3_FLAG_40BIT_DMA_BUG)
return (((u64) mapping + len) DMA_40BIT_MASK);
return 0;
#else
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] tg3: Fix PHY loopback on 5700
Fix PHY loopback failure on some 5700 devices.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0fafc52..3c5c9fa 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8399,8 +8399,11 @@ static int tg3_run_loopback(struct tg3 *
}
mac_mode = (tp-mac_mode ~MAC_MODE_PORT_MODE_MASK) |
MAC_MODE_LINK_POLARITY | MAC_MODE_PORT_MODE_GMII;
- if ((tp-phy_id PHY_ID_MASK) == PHY_ID_BCM5401)
+ if ((tp-phy_id PHY_ID_MASK) == PHY_ID_BCM5401) {
mac_mode = ~MAC_MODE_LINK_POLARITY;
+ tg3_writephy(tp, MII_TG3_EXT_CTRL,
+MII_TG3_EXT_CTRL_LNK3_LED_MODE);
+ }
tw32(MAC_MODE, mac_mode);
}
else
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] tg3: Speed up SRAM access
Speed up SRAM read and write functions if possible by using MMIO
instead of config. cycles. With this change, the post reset signature
done at the end of D3 power change must now be moved before the D3
power change.
IBM reported a problem on powerpc blades during ethtool self test
that was caused by the memory test taking excessively long. Config.
cycles are very slow on powerpc and the memory test can take more
than 10 seconds to complete using config. cycles. As a result, NETDEV
WATCHDOG can be triggered during self test and the chip can end up in
a funny state.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 3c5c9fa..c504ff2 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -497,21 +497,20 @@ static void tg3_write_mem(struct tg3 *tp
unsigned long flags;
spin_lock_irqsave(tp-indirect_lock, flags);
- pci_write_config_dword(tp-pdev, TG3PCI_MEM_WIN_BASE_ADDR, off);
- pci_write_config_dword(tp-pdev, TG3PCI_MEM_WIN_DATA, val);
+ if (tp-write32 != tg3_write_indirect_reg32) {
+ tw32_f(TG3PCI_MEM_WIN_BASE_ADDR, off);
+ tw32_f(TG3PCI_MEM_WIN_DATA, val);
- /* Always leave this as zero. */
- pci_write_config_dword(tp-pdev, TG3PCI_MEM_WIN_BASE_ADDR, 0);
- spin_unlock_irqrestore(tp-indirect_lock, flags);
-}
+ /* Always leave this as zero. */
+ tw32_f(TG3PCI_MEM_WIN_BASE_ADDR, 0);
+ } else {
+ pci_write_config_dword(tp-pdev, TG3PCI_MEM_WIN_BASE_ADDR, off);
+ pci_write_config_dword(tp-pdev, TG3PCI_MEM_WIN_DATA, val);
-static void tg3_write_mem_fast(struct tg3 *tp, u32 off, u32 val)
-{
- /* If no workaround is needed, write to mem space directly */
- if (tp-write32 != tg3_write_indirect_reg32)
- tw32(NIC_SRAM_WIN_BASE + off, val);
- else
- tg3_write_mem(tp, off, val);
+ /* Always leave this as zero. */
+ pci_write_config_dword(tp-pdev, TG3PCI_MEM_WIN_BASE_ADDR, 0);
+ }
+ spin_unlock_irqrestore(tp-indirect_lock, flags);
}
static void tg3_read_mem(struct tg3 *tp, u32 off, u32 *val)
@@ -519,11 +518,19 @@ static void tg3_read_mem(struct tg3 *tp,
unsigned long flags;
spin_lock_irqsave(tp-indirect_lock, flags);
- pci_write_config_dword(tp-pdev, TG3PCI_MEM_WIN_BASE_ADDR, off);
- pci_read_config_dword(tp-pdev, TG3PCI_MEM_WIN_DATA, val);
+ if (tp-write32 != tg3_write_indirect_reg32) {
+ tw32_f(TG3PCI_MEM_WIN_BASE_ADDR, off);
+ *val = tr32(TG3PCI_MEM_WIN_DATA);
- /* Always leave this as zero. */
- pci_write_config_dword(tp-pdev, TG3PCI_MEM_WIN_BASE_ADDR, 0);
+ /* Always leave this as zero. */
+ tw32_f(TG3PCI_MEM_WIN_BASE_ADDR, 0);
+ } else {
+ pci_write_config_dword(tp-pdev, TG3PCI_MEM_WIN_BASE_ADDR, off);
+ pci_read_config_dword(tp-pdev, TG3PCI_MEM_WIN_DATA, val);
+
+ /* Always leave this as zero. */
+ pci_write_config_dword(tp-pdev, TG3PCI_MEM_WIN_BASE_ADDR, 0);
+ }
spin_unlock_irqrestore(tp-indirect_lock, flags);
}
@@ -1367,12 +1374,12 @@ static int tg3_set_power_state(struct tg
}
}
+ tg3_write_sig_post_reset(tp, RESET_KIND_SHUTDOWN);
+
/* Finally, set the new power state. */
pci_write_config_word(tp-pdev, pm + PCI_PM_CTRL, power_control);
udelay(100);/* Delay after power state change */
- tg3_write_sig_post_reset(tp, RESET_KIND_SHUTDOWN);
-
return 0;
}
@@ -6537,11 +6544,11 @@ static void tg3_timer(unsigned long __op
if (tp-tg3_flags TG3_FLAG_ENABLE_ASF) {
u32 val;
- tg3_write_mem_fast(tp, NIC_SRAM_FW_CMD_MBOX,
- FWCMD_NICDRV_ALIVE2);
- tg3_write_mem_fast(tp, NIC_SRAM_FW_CMD_LEN_MBOX, 4);
+ tg3_write_mem(tp, NIC_SRAM_FW_CMD_MBOX,
+ FWCMD_NICDRV_ALIVE2);
+ tg3_write_mem(tp, NIC_SRAM_FW_CMD_LEN_MBOX, 4);
/* 5 seconds timeout */
- tg3_write_mem_fast(tp, NIC_SRAM_FW_CMD_DATA_MBOX, 5);
+ tg3_write_mem(tp, NIC_SRAM_FW_CMD_DATA_MBOX, 5);
val = tr32(GRC_RX_CPU_EVENT);
val |= (1 14);
tw32(GRC_RX_CPU_EVENT, val);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] tg3: Skip timer code during full lock
Skip the main timer code if interrupts are disabled in the full lock
state.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c504ff2..b6a6051 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6468,6 +6468,9 @@ static void tg3_timer(unsigned long __op
{
struct tg3 *tp = (struct tg3 *) __opaque;
+ if (tp-irq_sync)
+ goto restart_timer;
+
spin_lock(tp-lock);
if (!(tp-tg3_flags TG3_FLAG_TAGGED_STATUS)) {
@@ -6558,6 +6561,7 @@ static void tg3_timer(unsigned long __op
spin_unlock(tp-lock);
+restart_timer:
tp-timer.expires = jiffies + tp-timer_offset;
add_timer(tp-timer);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] tg3: Update version and reldate
Update version to 3.55. Signed-off-by: Michael Chan [EMAIL PROTECTED] diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c index b6a6051..964c096 100644 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -69,8 +69,8 @@ #define DRV_MODULE_NAMEtg3 #define PFX DRV_MODULE_NAME: -#define DRV_MODULE_VERSION 3.54 -#define DRV_MODULE_RELDATE Mar 23, 2006 +#define DRV_MODULE_VERSION 3.55 +#define DRV_MODULE_RELDATE Mar 27, 2006 #define TG3_DEF_MAC_MODE 0 #define TG3_DEF_RX_MODE0 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] acenic: fix section mismatches
On Mon, Mar 27, 2006 at 02:32:14PM -0800, Randy.Dunlap wrote: Nope, only with HOTPLUG enabled. I can try without also (but disabling it is a pain :). ugh, FW_LOADER is the beast (not CONFIG_HOTPLUG itself). Sam, I am now seeing this error (not a WARNING like the previous ones were): Can you send me your .config. Tried but did not manage to get rid of FW_LOADER. OK - did not try hard though. Sam - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] tg3: Fix bug in 40-bit DMA workaround code
From: Michael Chan [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 17:08:30 -0800 Need to check the TG3_FLAG_40BIT_DMA_BUG flag in the workaround code path instead of device flags. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied. Looks like another 2.6.16.x stable branch candidate? Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] tg3: Fix probe failure due to invalid MAC address
From: Michael Chan [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 17:07:51 -0800 Some older bootcode in some devices may report 0 MAC address in SRAM when booting up from low power state. This patch fixes the problem by checking for a valid MAC address in SRAM and falling back to NVRAM if necessary. Thanks to walt [EMAIL PROTECTED] for reporting the problem and helping to debug it. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied. Do we need to try to get this fix into the 2.6.16.x stable branch? Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] tg3: Fix PHY loopback on 5700
From: Michael Chan [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 17:08:59 -0800 Fix PHY loopback failure on some 5700 devices. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] tg3: Speed up SRAM access
From: Michael Chan [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 17:09:33 -0800 Speed up SRAM read and write functions if possible by using MMIO instead of config. cycles. With this change, the post reset signature done at the end of D3 power change must now be moved before the D3 power change. IBM reported a problem on powerpc blades during ethtool self test that was caused by the memory test taking excessively long. Config. cycles are very slow on powerpc and the memory test can take more than 10 seconds to complete using config. cycles. As a result, NETDEV WATCHDOG can be triggered during self test and the chip can end up in a funny state. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, but that IBM stuff seems bogus. Even a PCI config space access that is implemented via a Hypervisor call should not take that long. Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] tg3: Skip timer code during full lock
From: Michael Chan [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 17:10:10 -0800 Skip the main timer code if interrupts are disabled in the full lock state. Signed-off-by: Michael Chan [EMAIL PROTECTED] Could this wedge the driver while we're trying to quiesce the interrupt? If so, probably a 2.6.16.x stable candidate? Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] tg3: Update version and reldate
From: Michael Chan [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 17:10:42 -0800 Update version to 3.55. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, thanks a lot Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] tg3: Fix probe failure due to invalid MAC address
David S. Miller wrote: From: Michael Chan [EMAIL PROTECTED] Date: Mon, 27 Mar 2006 17:07:51 -0800 Some older bootcode in some devices may report 0 MAC address in SRAM when booting up from low power state. This patch fixes the problem by checking for a valid MAC address in SRAM and falling back to NVRAM if necessary. Thanks to walt [EMAIL PROTECTED] for reporting the problem and helping to debug it. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied. Do we need to try to get this fix into the 2.6.16.x stable branch? 2.6.16 does not power down the chip during tg3_close() so the problem is not exposed. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] tg3: Speed up SRAM access
David S. Miller wrote: Applied, but that IBM stuff seems bogus. Even a PCI config space access that is implemented via a Hypervisor call should not take that long. In the memory test, we are reading and writing different patterns to the entire SRAM, so it's not too surprising to me that it would take this long. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
