Re: [PATCH 2.4.35.3] Fix the "InAddrErrors" increasing problem
Krishna Kumar2 写道:
> Gui Jianfeng wrote on 10/22/2007 11:37:07 AM:
>
>> @@ -310,8 +310,12 @@ static inline int ip_rcv_finish(struct s
>> * how the packet travels inside Linux networking.
>> */
>> if (skb->dst == NULL) {
>> - if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
>> - goto drop;
>> + int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
> dev);
>> + if (unlikely(err)) {
>> + if (err == -EHOSTUNREACH)
>> +IP_INC_STATS_BH(IpInAddrErrors);
>> + }
>> + goto drop;
>> }
>
> Shouldn't the "goto drop" be inside the "if (unlikely(err)) {" case?
yes, you are right :-)
> And normally it is nice to have a blank line after variable declaration.
>
> - KK
>
>
>
--
Regards
Gui Jianfeng
--
Gui Jianfeng
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630566-851
COINS: 79955-851
FAX: +86+25-83317685
MAIL:[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
[RFC][PATCH 1/3][XFRM]: Define packet processing statistics.
This statistics is shown as /proc/net/xfrm_stat about transformation
error (or almost error) factor at packet processing for developer.
It is not a SNMP/MIB specification but a counter designed from
current transformation source code.
- Inbound errors
XfrmInError - all errors which is not matched others
XfrmInBufferError - no buffer is left
XfrmInHdrError- header error
XfrmInNoStates- no state is found
XfrmInStateProtoError - error at transformation protocol
XfrmInStateModeError - error at transformation mode
XfrmInSeqOutOfWindow - sequence out of window
XfrmInStateExpired- state is expired
XfrmInStateMismatch - state has mismatch option
XfrmInStateInvalid- state is invalid
XfrmInTmplMismatch- no matching template for states
XfrmInNoPols - no policy is found for states
XfrmInPolBlock- policy discards
XfrmInPolError- policy error
- Outbound errors
XfrmOutError - all errors which is not matched others
XfrmOutLengthError- length error
XfrmOutBundleError- error at bundle
XfrmOutNoStates - no state is found
XfrmOutStateProtoError- error at transformation protocol
XfrmOutStateModeError - error at transformation mode
XfrmOutStateExpired - state expired
XfrmOutPolBlock - policy discards
XfrmOutPolError - policy error
Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]>
---
include/linux/snmp.h | 30 +++
include/net/snmp.h |5 ++
include/net/xfrm.h | 17
net/xfrm/Makefile |1 +
net/xfrm/xfrm_policy.c | 35 +
net/xfrm/xfrm_proc.c | 96
6 files changed, 184 insertions(+), 0 deletions(-)
diff --git a/include/linux/snmp.h b/include/linux/snmp.h
index 89f0c2b..3fc89f4 100644
--- a/include/linux/snmp.h
+++ b/include/linux/snmp.h
@@ -217,4 +217,34 @@ enum
__LINUX_MIB_MAX
};
+/* xfrm mib definitions */
+enum
+{
+ XFRM_MIB_NUM = 0,
+ XFRM_MIB_INERROR, /* XfrmInError */
+ XFRM_MIB_INBUFFERERROR, /* XfrmInBufferError */
+ XFRM_MIB_INHDRERROR,/* XfrmInHdrError */
+ XFRM_MIB_INNOSTATES,/* XfrmInNoStates */
+ XFRM_MIB_INSTATEPROTOERROR, /* XfrmInStateProtoError */
+ XFRM_MIB_INSTATEMODEERROR, /* XfrmInStateModeError */
+ XFRM_MIB_INSEQOUTOFWINDOW, /* XfrmInSeqOutOfWindow */
+ XFRM_MIB_INSTATEEXPIRED,/* XfrmInStateExpired */
+ XFRM_MIB_INSTATEMISMATCH, /* XfrmInStateMismatch */
+ XFRM_MIB_INSTATEINVALID,/* XfrmInStateInvalid */
+ XFRM_MIB_INTMPLMISMATCH,/* XfrmInTmplMismatch */
+ XFRM_MIB_INNOPOLS, /* XfrmInNoPols */
+ XFRM_MIB_INPOLBLOCK,/* XfrmInPolBlock */
+ XFRM_MIB_INPOLERROR,/* XfrmInPolError */
+ XFRM_MIB_OUTERROR, /* XfrmOutError */
+ XFRM_MIB_OUTLENGTHERROR,/* XfrmOutLengthError */
+ XFRM_MIB_OUTBUNDLEERROR,/* XfrmOutBundleError */
+ XFRM_MIB_OUTNOSTATES, /* XfrmOutNoStates */
+ XFRM_MIB_OUTSTATEPROTOERROR,/* XfrmOutStateProtoError */
+ XFRM_MIB_OUTSTATEMODEERROR, /* XfrmOutStateModeError */
+ XFRM_MIB_OUTSTATEEXPIRED, /* XfrmOutStateExpired */
+ XFRM_MIB_OUTPOLBLOCK, /* XfrmOutPolBlock */
+ XFRM_MIB_OUTPOLERROR, /* XfrmOutPolError */
+ __XFRM_MIB_MAX
+};
+
#endif /* _LINUX_SNMP_H */
diff --git a/include/net/snmp.h b/include/net/snmp.h
index ea206bf..37bcf19 100644
--- a/include/net/snmp.h
+++ b/include/net/snmp.h
@@ -117,6 +117,11 @@ struct linux_mib {
unsigned long mibs[LINUX_MIB_MAX];
};
+/* Xfrm */
+#define XFRM_MIB_MAX __XFRM_MIB_MAX
+struct xfrm_mib {
+ unsigned long mibs[XFRM_MIB_MAX];
+};
/*
* FIXME: On x86 and some other CPUs the split into user and softirq parts
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 688f6f5..679d915 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -19,6 +19,9 @@
#include
#include
#include
+#ifdef CONFIG_XFRM_STATISTICS
+#include
+#endif
#define XFRM_PROTO_ESP 50
#define XFRM_PROTO_AH 51
@@ -34,6 +37,17 @@
#define MODULE_ALIAS_XFRM_TYPE(family, proto) \
MODULE_ALIAS("xfrm-type-" __stringify(family) "-" __stringify(proto))
+#ifdef CONFIG_XFRM_STATISTICS
+DECLARE_SNMP_STAT(struct xfrm_mib, xfrm_statistics);
+#define XFRM_INC_STATS(field) SNMP_INC_STATS(xfrm_statistics, field)
+#define XFRM_INC_STATS_BH(field) SNMP_INC_STATS_BH(xfrm_statistics,
field)
+#define XFRM_INC_STATS_USER(field) SNMP_INC_STATS_USER(xfrm_statistics,
field)
+#else
+#define XFRM_INC_STATS(field)
+#define XFRM_INC_STATS_BH(field)
+#define XFRM_INC_STATS_USER(field)
+#endif
+
extern struct sock *xfrm_nl;
extern u32 sysctl_xfrm_aevent_e
[RFC][PATCH 2/3][XFRM]: Support to increment packet processing statistics.
Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]>
---
net/ipv4/xfrm4_input.c | 48 +++-
net/ipv4/xfrm4_output.c |4 ++-
net/ipv6/xfrm6_input.c | 56 --
net/ipv6/xfrm6_output.c |4 ++-
net/xfrm/xfrm_output.c | 19 +++---
net/xfrm/xfrm_policy.c | 61 +-
6 files changed, 148 insertions(+), 44 deletions(-)
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index 5e95c8a..956e093 100644
--- a/net/ipv4/xfrm4_input.c
+++ b/net/ipv4/xfrm4_input.c
@@ -45,36 +45,52 @@ int xfrm4_rcv_encap(struct sk_buff *skb, int nexthdr,
__be32 spi,
unsigned int nhoff = offsetof(struct iphdr, protocol);
seq = 0;
- if (!spi && (err = xfrm_parse_spi(skb, nexthdr, &spi, &seq)) != 0)
+ if (!spi && (err = xfrm_parse_spi(skb, nexthdr, &spi, &seq)) != 0) {
+ XFRM_INC_STATS(XFRM_MIB_INHDRERROR);
goto drop;
+ }
do {
const struct iphdr *iph = ip_hdr(skb);
- if (xfrm_nr == XFRM_MAX_DEPTH)
+ if (xfrm_nr == XFRM_MAX_DEPTH) {
+ XFRM_INC_STATS(XFRM_MIB_INBUFFERERROR);
goto drop;
+ }
x = xfrm_state_lookup((xfrm_address_t *)&iph->daddr, spi,
nexthdr, AF_INET);
- if (x == NULL)
+ if (x == NULL) {
+ XFRM_INC_STATS(XFRM_MIB_INNOSTATES);
goto drop;
+ }
spin_lock(&x->lock);
- if (unlikely(x->km.state != XFRM_STATE_VALID))
+ if (unlikely(x->km.state != XFRM_STATE_VALID)) {
+ XFRM_INC_STATS(XFRM_MIB_INSTATEINVALID);
goto drop_unlock;
+ }
- if ((x->encap ? x->encap->encap_type : 0) != encap_type)
+ if ((x->encap ? x->encap->encap_type : 0) != encap_type) {
+ XFRM_INC_STATS(XFRM_MIB_INSTATEMISMATCH);
goto drop_unlock;
+ }
- if (x->props.replay_window && xfrm_replay_check(x, seq))
+ if (x->props.replay_window && xfrm_replay_check(x, seq)) {
+ XFRM_INC_STATS(XFRM_MIB_INSEQOUTOFWINDOW);
goto drop_unlock;
+ }
- if (xfrm_state_check_expire(x))
+ if (xfrm_state_check_expire(x)) {
+ XFRM_INC_STATS(XFRM_MIB_INSTATEEXPIRED);
goto drop_unlock;
+ }
nexthdr = x->type->input(x, skb);
- if (nexthdr <= 0)
+ if (nexthdr <= 0) {
+ XFRM_INC_STATS(XFRM_MIB_INSTATEPROTOERROR);
goto drop_unlock;
+ }
skb_network_header(skb)[nhoff] = nexthdr;
@@ -91,8 +107,10 @@ int xfrm4_rcv_encap(struct sk_buff *skb, int nexthdr,
__be32 spi,
xfrm_vec[xfrm_nr++] = x;
- if (x->outer_mode->input(x, skb))
+ if (x->outer_mode->input(x, skb)) {
+ XFRM_INC_STATS(XFRM_MIB_INSTATEMODEERROR);
goto drop;
+ }
if (x->outer_mode->flags & XFRM_MODE_FLAG_TUNNEL) {
decaps = 1;
@@ -100,8 +118,10 @@ int xfrm4_rcv_encap(struct sk_buff *skb, int nexthdr,
__be32 spi,
}
err = xfrm_parse_spi(skb, nexthdr, &spi, &seq);
- if (err < 0)
+ if (err < 0) {
+ XFRM_INC_STATS(XFRM_MIB_INHDRERROR);
goto drop;
+ }
} while (!err);
/* Allocate new secpath or COW existing one. */
@@ -109,14 +129,18 @@ int xfrm4_rcv_encap(struct sk_buff *skb, int nexthdr,
__be32 spi,
if (!skb->sp || atomic_read(&skb->sp->refcnt) != 1) {
struct sec_path *sp;
sp = secpath_dup(skb->sp);
- if (!sp)
+ if (!sp) {
+ XFRM_INC_STATS(XFRM_MIB_INERROR);
goto drop;
+ }
if (skb->sp)
secpath_put(skb->sp);
skb->sp = sp;
}
- if (xfrm_nr + skb->sp->len > XFRM_MAX_DEPTH)
+ if (xfrm_nr + skb->sp->len > XFRM_MAX_DEPTH) {
+ XFRM_INC_STATS(XFRM_MIB_INBUFFERERROR);
goto drop;
+ }
memcpy(skb->sp->xvec + skb->sp->len, xfrm_vec,
xfrm_nr * sizeof(xfrm_vec[0]));
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
index c4a7156..9d1d7b9 100644
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -49,8 +49,10 @@ static inline int xfrm4_output_one(struct sk_buff *skb)
if (x->outer_mode->flags & XFRM_MODE_FLAG_TUNNEL) {
[RFC][PATCH 3/3][XFRM]: Add packet processing statistics option.
Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]> --- net/xfrm/Kconfig | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig index 577a4f8..6b5b50f 100644 --- a/net/xfrm/Kconfig +++ b/net/xfrm/Kconfig @@ -35,6 +35,16 @@ config XFRM_MIGRATE If unsure, say N. +config XFRM_STATISTICS + bool "Transformation statistics (EXPERIMENTAL)" + depends on XFRM && PROC_FS && EXPERIMENTAL + ---help--- + This statistics is not a SNMP/MIB specification but shows + statistics about transformation error (or almost error) factor + at packet processing for developer. + + If unsure, say N. + config NET_KEY tristate "PF_KEY sockets" select XFRM -- 1.4.4.2 - 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
[RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
This patch introduces statistics about transformation error (or almost error) factor at packet processing for developer. It is not a SNMP/MIB specification from IPsec/MIPv6 but a counter designed from current transformation source code. Comment please. - 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] [IPSEC] IPV6: Fix to add tunnel mode SA correctly.
Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]> --- net/ipv6/ah6.c |1 + net/ipv6/esp6.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c index 67cd066..66a9139 100644 --- a/net/ipv6/ah6.c +++ b/net/ipv6/ah6.c @@ -483,6 +483,7 @@ static int ah6_init_state(struct xfrm_state *x) break; case XFRM_MODE_TUNNEL: x->props.header_len += sizeof(struct ipv6hdr); + break; default: goto error; } diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c index b071543..72a6598 100644 --- a/net/ipv6/esp6.c +++ b/net/ipv6/esp6.c @@ -360,6 +360,7 @@ static int esp6_init_state(struct xfrm_state *x) break; case XFRM_MODE_TUNNEL: x->props.header_len += sizeof(struct ipv6hdr); + break; default: goto error; } -- 1.4.4.2 - 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.4.35.3] Fix the "InAddrErrors" increasing problem
Gui Jianfeng wrote on 10/22/2007 11:37:07 AM:
> @@ -310,8 +310,12 @@ static inline int ip_rcv_finish(struct s
> * how the packet travels inside Linux networking.
> */
> if (skb->dst == NULL) {
> - if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
> - goto drop;
> + int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
dev);
> + if (unlikely(err)) {
> + if (err == -EHOSTUNREACH)
> +IP_INC_STATS_BH(IpInAddrErrors);
> + }
> + goto drop;
> }
Shouldn't the "goto drop" be inside the "if (unlikely(err)) {" case?
And normally it is nice to have a blank line after variable declaration.
- KK
-
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.4.35.3] Fix the "InAddrErrors" increasing problem
From: Gui Jianfeng <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 14:07:07 +0800 > When kernel receives a package with a wrong destination ipv4 address, it > can't increase "InAddrErrors" number correctly. > InAddrErrors is located in /proc/net/snmp. > > This is a patch for fixing this problem. > > Signed-off-by: Gui Jianfeng <[EMAIL PROTECTED]> This patch looks fine, but I really don't handle 2.4.x kernel patches for networking as 2.6.x takes enough of my time and effort. - 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.4.35.3] Fix the "InAddrErrors" increasing problem
Hi,
When kernel receives a package with a wrong destination ipv4 address, it can't
increase "InAddrErrors" number correctly.
InAddrErrors is located in /proc/net/snmp.
This is a patch for fixing this problem.
Signed-off-by: Gui Jianfeng <[EMAIL PROTECTED]>
---
diff -Narup linux-2.4.35.3/net/ipv4/ip_input.c
linux-2.4.35.3-prep/net/ipv4/ip_input.c
--- linux-2.4.35.3/net/ipv4/ip_input.c 2007-09-24 06:02:58.0 +0800
+++ linux-2.4.35.3-prep/net/ipv4/ip_input.c 2007-09-26 01:24:08.0
+0800
@@ -310,8 +310,12 @@ static inline int ip_rcv_finish(struct s
* how the packet travels inside Linux networking.
*/
if (skb->dst == NULL) {
- if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
- goto drop;
+ int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
dev);
+ if (unlikely(err)) {
+ if (err == -EHOSTUNREACH)
+ IP_INC_STATS_BH(IpInAddrErrors);
+ }
+ goto drop;
}
#ifdef CONFIG_NET_CLS_ROUTE
diff -Narup linux-2.4.35.3/net/ipv4/route.c linux-2.4.35.3-prep/net/ipv4/route.c
--- linux-2.4.35.3/net/ipv4/route.c 2007-09-24 06:02:58.0 +0800
+++ linux-2.4.35.3-prep/net/ipv4/route.c2007-09-26 01:26:15.0
+0800
@@ -1450,7 +1450,7 @@ int ip_route_input_slow(struct sk_buff *
*/
if ((err = fib_lookup(&key, &res)) != 0) {
if (!IN_DEV_FORWARD(in_dev))
- goto e_inval;
+ goto e_hostunreach;
goto no_route;
}
free_res = 1;
@@ -1499,7 +1499,7 @@ int ip_route_input_slow(struct sk_buff *
}
if (!IN_DEV_FORWARD(in_dev))
- goto e_inval;
+ goto e_hostunreach;
if (res.type != RTN_UNICAST)
goto martian_destination;
@@ -1668,6 +1668,11 @@ martian_destination:
"%u.%u.%u.%u, dev %s\n",
NIPQUAD(daddr), NIPQUAD(saddr), dev->name);
#endif
+
+e_hostunreach:
+ err = -EHOSTUNREACH;
+ goto done;
+
e_inval:
err = -EINVAL;
goto done;
-
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] flush_work_sync vs. flush_scheduled_work Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote: > On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote: > > On 10/18, Jarek Poplawski wrote: > > > > > > +/** > > > + * flush_work_sync - block until a work_struct's callback has terminated > > ^^^ > > Hmm... > > > > > + * Similar to cancel_work_sync() but will only busy wait (without cancel) > > > + * if the work is queued. > > > > Yes, it won't block, but will spin in busy-wait loop until all other works > > scheduled before this work are finished. Not good. After that it really > > blocks waiting for this work to complete. > > > > And I am a bit confused. We can't use flush_workqueue() because some of the > > queued work_structs may take rtnl_lock, yes? But in that case we can't use > > the new flush_work_sync() helper as well, no? OK, I know I'm dumber and dumber everyday, but it seems in a hurry I got it wrong again or miss something (as usual): these all flushes are rtnl lockup vulnerable wrt. other work functions, but cancel_work_sync looks perfectly fine... (Or am I wrong because: ...?) Then, if by any chance I'm right, something like flush_work_sync (or changed flush_scheduled_work, if there is no problem with such a change of implementation) could be safely (if it's called without locks used by flushed work only) done cancel_work_sync() way, by running a work function after try_to_grab_pending() returns 1 (after list_del_init - of course without respecting a queue order). Regards, Jarek 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
Re: net: alignment problem in icmp code
From: Pierre Ossman <[EMAIL PROTECTED]> Date: Mon, 22 Oct 2007 06:54:43 +0200 > On Sun, 21 Oct 2007 16:02:15 -0700 (PDT) > David Miller <[EMAIL PROTECTED]> wrote: > > > You will get a 64-bit load and a 64-bit store emitted by > > the compiler. Here is what we get on sparc64: > > I assume those ops cause a bus error on unaligned addresses? Sure. But the language defines that the types in question must be 64-bit aligned, so it is legal for the compiler to emit this code. It's not a GCC bug. If you want to let the compiler know that a pointer to a type might not be aligned, you have to tell it so. - 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: alignment problem in icmp code
On Sun, 21 Oct 2007 16:02:15 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Pierre Ossman <[EMAIL PROTECTED]> > Date: Sun, 21 Oct 2007 23:21:13 +0200 > > > Not sure that would be valid. memcpy() is defined as having void* > > arguments, and the compiler cannot just ignore that if it chooses to > > inline it. > > Yes it can, there are C language rules about the alignment of types > that the compiler completely can take advantage of in those kinds of > situations. > I'm not debating that. What I'm saying is that calling memcpy() casts your pointers to void* with the included semantical changes. It can't just ignore that because it decides to inline the function. It would be the same thing as when gcc decided to ignore the volatile qualifier on a pointer just because it could optimize away to the real object and discover it wasn't marked with volatile. Something that was considered a bug and was fixed. > If you don't believe me, compile something like the following > with optimizations enabled: gcc has had bugs in the past. > You will get a 64-bit load and a 64-bit store emitted by > the compiler. Here is what we get on sparc64: > I assume those ops cause a bus error on unaligned addresses? > > However, instead of relying upon magic like this, let's just tell the > compiler explicitly what it going on by using get_unaligned(). > It wouldn't be magic: memcpy(&icmp_param.data.icmph, skb_transport_header(skb), sizeof(struct icmphdr)); I believe platforms without alignment requirements could optimize this better than the series of assignments. Not that I think this will be a potential bottle neck, but still. > Next, there are redundant stores being done here since the code and > type are explicitly overwritten in various ways. Indeed. Rgds Pierre signature.asc Description: PGP signature
Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 21:01:17 -0700 > David Miller wrote: > > > I'm not so sure about this. > > > > Perhaps, instead, you should do a pci_msi_disable() and > > pci_msi_enable() in the error detection and recovery sequence. > > If we just detected PCI errors on this slot, I don't think it's > a good idea to continue writing to the config space to disable > MSI. Perhaps we can disable/enable after the slot reset. Right, it would have to be after the slot reset. > > Or, alternatively, save/restore those MSI registers by hand. > > We can do that, but we'll have to do it ahead of time when we enable > MSI, not after errors have been detected. But the address/data can > change as the CPU affinity changes during run time, right? Yes, it can. The core issue is that the ARCH level MSI code invokes write_msi_msg(), not the generic code, exactly because there are platform level issues wherein the firmware is the only legal way to write the MSI settings in PCI config space. However, the MSI state restore code was not architected similarly. It does the write_msi_msg() directly, instead of letting platform level code is in ARCH hooks. Therefore I think we need to attack this in two stages: 1) First changeset moves the write_msi_msg() call currently in __pci_restore_msi_state() into an ARCH overridable handler. This would allow powerpc to deal with this properly. pci_restor_msi_state() can get exported to modules in this change 2) The Tigon3 error recovery changes, as they were. But I have to ask, can anyone see how e1000 handles MSI properly in it's PCI error support? - 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/7] pci: Export the pci_restore_msi_state() function
David Miller wrote: > I'm not so sure about this. > > Perhaps, instead, you should do a pci_msi_disable() and > pci_msi_enable() in the error detection and recovery sequence. If we just detected PCI errors on this slot, I don't think it's a good idea to continue writing to the config space to disable MSI. Perhaps we can disable/enable after the slot reset. > > Or, alternatively, save/restore those MSI registers by hand. We can do that, but we'll have to do it ahead of time when we enable MSI, not after errors have been detected. But the address/data can change as the CPU affinity changes during run time, right? - 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/7] tg3: MII => TP
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 20:49:25 -0700 > MII in this ethtool context means an MII connector on the card > that can connect to an external transceiver, right? > > Or does it mean internal MII interface to the PHY? Good question. Looking at drivers it's set randomly. Probably you are right and it's supposed to mean you can specify PORT_MII in ethtool_cmd->port to select the external MII connector. Please resubmit this change after the PCI error recovery issues are resolved. 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 2/7] tg3: MII => TP
David Miller wrote: > From: "Matt Carlson" <[EMAIL PROTECTED]> > Date: Fri, 19 Oct 2007 14:36:42 -0700 > > > This patch changes the PHY type reported through ethtool for copper > > devices from MII to TP. The latter is more accurate. > > > > Signed-off-by: Matt Carlson <[EMAIL PROTECTED]> > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> > > You should set both MII and TP, since these copper interfaces > have a MII based twisted-pair physical layer. > > MII in this ethtool context means an MII connector on the card that can connect to an external transceiver, right? Or does it mean internal MII interface to the PHY? - 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: e100 problems in .23rc8 ?
On Sun, Oct 21, 2007 at 09:04:40PM -0400, Dave Jones wrote:
>
> I included the patch below in the latest build, but I've not had
> chance to try it on an e100 box yet..
Looks good to me. Thanks Dave!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[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 13/14 v2] nes: kernel build infrastructure
> +config INFINIBAND_NES_DEBUG > +bool "Verbose debugging output" > +depends on INFINIBAND_NES > +default n > +---help--- > + This option causes the NetEffect RNIC driver to produce debug > + messages. Select this if you are developing the driver > + or trying to diagnose a problem. If you make this default n then no distro will have it enabled and you'll have to rebuild to debug anything. Better to have the default be enabled and make it controllable at runtime too with a module parameter. (you can look at what mthca does for an example of what I mean) - 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: [ofa-general] [PATCH 14/14 v2] nes: kernel build infrastructure
> + > +EXTRA_CFLAGS += -DNES_MINICM I don't see anyplace NES_MINICM is used. Delete this line? > + > +obj-$(CONFIG_INFINIBAND_NES) += iw_nes.o > + > +iw_nes-objs := nes.o nes_hw.o nes_nic.o nes_utils.o nes_verbs.o nes_cm.o > + Also the file has an extra blank line at the beginning and end. Might as well kill them. - 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: about multiple network interface
Thanks very much But this does work until I add a ifcfg-eth0 in sysconfig/network-script with the following content: DEVICE=eth0 ONBOOT=yes What is the relationship between these two files? And sometimes, I see this message: Bringing up interface eth0: e100 device does not seem to be present, delaying e th0 initialization. Why?? 2007/10/18, Evgeniy Polyakov <[EMAIL PROTECTED]>: > On Thu, Oct 18, 2007 at 09:06:40PM +0800, wit ([EMAIL PROTECTED]) wrote: > > Hi all, > > > >Sorry, I don't know if this is the right mail list. I got the > > following question: > >I have a e100 card and a e1000 card. Whenever I boot the system, I > > found the eth0 matches the e1000 card, and the eth2 matches the other. > > How can I force the eth0 to match the e100 card and the eth2 to match > > e1000? > > Hi. > > Check your /etc/modprobe.conf and put there > > alias eth0 e100 > alias eth2 e1000 > > > -- > Evgeniy Polyakov > - 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/7] pci: Export the pci_restore_msi_state() function
On Sun, 2007-10-21 at 16:21 -0700, David Miller wrote: > From: "Matt Carlson" <[EMAIL PROTECTED]> > Date: Fri, 19 Oct 2007 14:36:56 -0700 > > > This patch exports the pci_restore_msi_state() function. This function > > is needed to restore the MSI state during PCI error recovery. > > > > Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> > > Signed-off-by: Matt Carlson <[EMAIL PROTECTED]> > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> > > I'm not so sure about this. On pseries there's a chance it will work for PCI error recovery, but if so it's just lucky that firmware has left everything configured the same way. For actual suspend/resume it will never work, we need to ask firmware to configure things. > Perhaps, instead, you should do a pci_msi_disable() and > pci_msi_enable() in the error detection and recovery sequence. Yes I think so. That way we can properly reconfigure via the firmware interface. The other option would be to design some new arch hook to do resume, but just doing a disable/enable seems simpler to me. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: e100 problems in .23rc8 ?
On Thu, Oct 18, 2007 at 10:59:59AM -0700, Kok, Auke wrote:
> David Mack wrote:
> > It appears that the needed e100 fix made it into the Fedora
> > 2.6.23.1-23.fc8 kernel. Boots reliably now.
> >
> > Huge thanks and great work, guys.
>
> DaveJ, I didn't push anything upstream. Can you verify this now works?
There was no e100 changes in the kernel above, so David just
got lucky. (The race doesn't always occur, so it sometimes appears
something got fixed.).
I included the patch below in the latest build, but I've not had
chance to try it on an e100 box yet..
Dave
--- linux-2.6.23.noarch/drivers/net/e100.c~ 2007-10-18 16:10:40.0
-0400
+++ linux-2.6.23.noarch/drivers/net/e100.c 2007-10-18 16:16:02.0
-0400
@@ -2682,6 +2682,8 @@ static int __devinit e100_probe(struct p
if (err)
DPRINTK(PROBE, ERR, "Error clearing wake event\n");
+ netif_poll_disable(netdev);
+
strcpy(netdev->name, "eth%d");
if((err = register_netdev(netdev))) {
DPRINTK(PROBE, ERR, "Cannot register net device, aborting.\n");
--
http://www.codemonkey.org.uk
-
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
Regression in current git - Network Manager fails (bisected)
Network Manager (the freedesktop.org one) fails to work with Linus's current git on a couple of different boxes I have here. All the boxes have different NIC types, with different drivers. I've bisected it down to cd40b7d3983c708aabe3d3008ec64ffce56d33b0 , "[NET]: make netlink user -> kernel interface synchronious". I've double checked this by testing the kernel as of the immediately previous commit; Network Manager works with that one, as it did on all my machines in 2.6.23-mm1. The netlink change seems to confuse N-M, and it somehow decides that there's no link beat, so doesn't try to bring up the interface. If I run "ifconfig eth0 up", N-M will decide there's a carrier after all and takes over. Ethtool detects the link state correctly even with the interface down. If I down the interface again with ifconfig, N-M brings it right back up without a problem, but if I kill N-M, it'll down the interface before it exits, and fail in the same way as before when restarted. N-M also emits this error: "-- Error: Invalid message: type=DONE length=20 flags= sequence-nr=1193012574 pid=1185943630" ...which it doesn't do on kernels where it works normally. strace'ing NetworkManager shows that it prints that message just after talking over a netlink socket. Networking otherwise works fine here with the latest git and N-M, if I use the ifconfig "trick" to get the link up. -- Joseph Fannin [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
CC2420 (802.15.4) Speed Issue
Hi Guys, I'm currently writing my first bit of Linux kernel code so be gentle. It's a driver for TI CC2420 802.15.4 radio and I'm observing strange behavior. I am currently testing just by transferring a ~300kb file over HTTP between two of these devices. The strange thing is, when ever you start the transfer it starts humming along at 5k/s which is not far off what I'd expect these devices to achieve, then at some random point along the transfer or sometimes not at all... it suddenly drops fairly deterministically to 150byte/s and finishes the transfer at that speed, maybe rising to 170bytes/s by the end of the transfer is I'm lucky. I don't really know where to start looking to solve the problem, it seems everything is functioning as it should at least some of the time as in some cases it will complete the whole transfer at the 5k/s speed. Is it just tcp throttling very harshly (i.e. 50x) when it loses a packet? Is it the Xscale chip scaling down the CPU frequency mid-transfer, I've got no idea how to check this? It is some sort of resonance affect happening with the two radios CCA although I'm not seeing any CCA timeouts. Can any one give any hints what to play with or where to look to try find the cause and get the transfers to run reliabily without the sudden bottoming out of speeds? (if you stop the transfer and initiate a new one immediately it will start at full speed again) Thanks, -YT - 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/4] Cut off the queue_mapping field from sk_buff
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 13:05:40 +0400 > Just hide it behind the #ifdef, because nobody wants > it now. > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Also 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 3/4] Hide the queue_mapping field inside netif_subqueue_stopped
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 13:04:13 +0400 > Many places get the queue_mapping field from skb to pass it > to the netif_subqueue_stopped() which will be 0 in any case. > > Make the helper that works with sk_buff > > Signed-off-by: Pavel Emelyanov <[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 2/4] Make and use skb_get_queue_mapping
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 13:02:31 +0400 > Make the helper for getting the field, symmetrical to > the "set" one. Return 0 if CONFIG_NETDEVICES_MULTIQUEUE=n > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Applied. - 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/4] Use the skb_set_queue_mapping where appropriate
From: Pavel Emelyanov <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 13:00:52 +0400 > There's already such a helper to initialize this field. > Use it. > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> Applied. > /* reset queue_mapping to zero */ > - skb->queue_mapping = 0; > + skb_set_queue_mapping(skb, 0); This right here is a great example why I add next to no comments to the code I write. They are %99.999 of the time stating the obvious, and where a comment is needed it's the code's fault and the code in such cases could be rewritten to make what's going on more clear thus making any commentary, again, redundant and stating the obvious. Here the case is the former, it's of the form: /* Add one to 'a'! */ a += 1; Gee thanks for letting me know! How insightful! :-)) - 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 v2] niu: Cleanup PAGE_SIZE checks a bit
From: Olof Johansson <[EMAIL PROTECTED]> Date: Sat, 20 Oct 2007 14:33:57 -0500 > PAGE_SIZE in this case is 64KB, so I don't quite get why gcc can't tell > that the line in question will never be reached. GCC does not do that kind of full flow analysis based upon constant expression simplification to determine if a store like this into a type smaller than the constant value can handle can actually occur. > I suggest the following instead, but I can unfortunately not do anything but > build test it. > > Also, the driver does some other checks to make sure that PAGE_SIZE is a > power of two (BUILD_BUG_ON() in niu_init()), doesn't seem like that could > ever be untrue? Or are there really archs with non-power-of-two PAGE_SIZE? It was just overly-anal assertion checking. I tend to prefer using code instead of comments to describe invariants, but this one is pretty unrealistic and silly. > Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> > > -- > > Ack! It should obviously use min(), not max()! :-) 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: [Bug 9189] New: Oops in kernel 2.6.21-rc4 through 2.6.23, page allocation failure
From: Herbert Xu <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 12:56:01 +0800 > [NET]: Fix SKB_WITH_OVERHEAD calculation > > The calculation in SKB_WITH_OVERHEAD is incorrect in that it can cause > an overflow across a page boundary which is what it's meant to prevent. > In particular, the header length (X) should not be lumped together with > skb_shared_info. The latter needs to be aligned properly while the header > has no choice but to sit in front of wherever the payload is. > > Therefore the correct calculation is to take away the aligned size of > skb_shared_info, and then subtract the header length. The resulting > quantity L satisfies the following inequality: > > SKB_DATA_ALIGN(L + X) + sizeof(struct skb_shared_info) <= PAGE_SIZE > > This is the quantity used by alloc_skb to do the actual allocation. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Applied, I'll push this to -stable too, 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: Bluetooth patches for 2.6.24
From: Marcel Holtmann <[EMAIL PROTECTED]> Date: Sat, 20 Oct 2007 22:01:37 +0200 > Hi Dave, > > > these are the Bluetooth patches for the 2.6.24 kernel release. Please > > pull and send them to Linus. > > one of the cleanup patches slipped through the net. If you already > pulled my tree, then please re-pull. I pushed it on top of it. I think I got it all, thanks. Please get Bluetooth updates to me much sooner than 8 days after the merge window opens up. Otherwise you risk the changes not getting in at all. 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: atm: panic when loading clip 2nd time
From: Randy Dunlap <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 18:02:36 -0700 > From: Randy Dunlap <[EMAIL PROTECTED]> > > net/atm/clip.c crashes the kernel if it (module) is loaded, removed, > and then loaded again. Its exit call to neigh_table_clear() > should destroy the cache after freeing it. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Looks good to me, 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 7/7] tg3: Update version to 3.85
From: "Matt Carlson" <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 14:37:00 -0700 > This patch updates the version number to 3.85. > > Signed-off-by: Matt Carlson <[EMAIL PROTECTED]> > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> I'll apply this, and when we sort out the PCI error recovery with another patch set we can bump it again to 3.86 - 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/7] tg3: Add PCI error recovery
From: "Matt Carlson" <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 14:36:58 -0700 > This patch adds PCI error recovery support. > > Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> > Signed-off-by: Matt Carlson <[EMAIL PROTECTED]> > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Dropped because it depends upon patch 5. - 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/7] pci: Export the pci_restore_msi_state() function
From: "Matt Carlson" <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 14:36:56 -0700 > This patch exports the pci_restore_msi_state() function. This function > is needed to restore the MSI state during PCI error recovery. > > Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> > Signed-off-by: Matt Carlson <[EMAIL PROTECTED]> > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> I'm not so sure about this. Perhaps, instead, you should do a pci_msi_disable() and pci_msi_enable() in the error detection and recovery sequence. Or, alternatively, save/restore those MSI registers by hand. I'm trying to figure out how the E1000 driver handles this correctly, but I can't see it just by reading it over quickly. - 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/7] tg3: PCI command adjustment
From: "Matt Carlson" <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 14:36:53 -0700 > This patch changes the way the driver works with the PCI command > register. It adjusts the access size from dwords to words. This patch > is done both as a PCI configuration space cleanup and as preparatory > work for PCI error recovery. > > Signed-off-by: Matt Carlson <[EMAIL PROTECTED]> > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> I will apply this patch but I can imagine this 32-bit store did things for us that will no longer be done. For example, it might have been clearing error indications in the PCI_STATUS reguster. - 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/7] tg3: Add management FW version to ethtool report
From: "Matt Carlson" <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 14:36:49 -0700 > This patch appends the management firmware version to the bootcode > firmware string reported through ethtool. > > Signed-off-by: Matt Carlson <[EMAIL PROTECTED]> > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied. - 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/7] tg3: MII => TP
From: "Matt Carlson" <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 14:36:42 -0700 > This patch changes the PHY type reported through ethtool for copper > devices from MII to TP. The latter is more accurate. > > Signed-off-by: Matt Carlson <[EMAIL PROTECTED]> > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> You should set both MII and TP, since these copper interfaces have a MII based twisted-pair physical layer. - 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/7] tg3: Add 5723 support
From: "Matt Carlson" <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 14:36:37 -0700 > This patch adds support for upcoming 5723 devices. > > Signed-off-by: Matt Carlson <[EMAIL PROTECTED]> > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied. - 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: alignment problem in icmp code
From: Pierre Ossman <[EMAIL PROTECTED]>
Date: Sun, 21 Oct 2007 23:21:13 +0200
> Not sure that would be valid. memcpy() is defined as having void*
> arguments, and the compiler cannot just ignore that if it chooses to
> inline it.
Yes it can, there are C language rules about the alignment of types
that the compiler completely can take advantage of in those kinds of
situations.
If you don't believe me, compile something like the following
with optimizations enabled:
void foo(unsigned long long *a,
unsigned long long *b)
{
memcpy(a, b, sizeof(*a));
}
You will get a 64-bit load and a 64-bit store emitted by
the compiler. Here is what we get on sparc64:
foo:
ldx [%o1], %g1
jmp %o7+8
stx%g1, [%o0]
Structure assignment is also essentially just another kind of
inline memcpy().
> Still, just give it the char* from the skb and it cannot make any
> assumption on alignment.
Yes, that would make it more likely to work.
However, instead of relying upon magic like this, let's just tell the
compiler explicitly what it going on by using get_unaligned().
Next, there are redundant stores being done here since the code and
type are explicitly overwritten in various ways.
commit 6471862b69e9272125f6a01916e6587523bf91f3
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Sun Oct 21 16:01:49 2007 -0700
[IPV4]: Handle potentially unaligned icmp headers in skb.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 272c69e..2b654b1 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -92,6 +92,7 @@
#include
#include
#include
+#include
/*
* Build xmit assembly blocks
@@ -766,6 +767,17 @@ out_err:
goto out;
}
+static void fill_icmp_param_data(struct icmp_bxm *param,
+struct icmphdr *src,
+u8 type, u8 code)
+{
+ struct icmphdr *dst = ¶m->data.icmph;
+
+ dst->type = type;
+ dst->code = code;
+ dst->un.gateway = get_unaligned(&src->un.gateway);
+}
+
/*
* Handle ICMP_ECHO ("ping") requests.
*
@@ -783,8 +795,10 @@ static void icmp_echo(struct sk_buff *skb)
if (!sysctl_icmp_echo_ignore_all) {
struct icmp_bxm icmp_param;
- icmp_param.data.icmph = *icmp_hdr(skb);
- icmp_param.data.icmph.type = ICMP_ECHOREPLY;
+ fill_icmp_param_data(&icmp_param,
+icmp_hdr(skb),
+ICMP_ECHOREPLY,
+icmp_hdr(skb)->code);
icmp_param.skb = skb;
icmp_param.offset = 0;
icmp_param.data_len= skb->len;
@@ -819,9 +833,8 @@ static void icmp_timestamp(struct sk_buff *skb)
icmp_param.data.times[2] = icmp_param.data.times[1];
if (skb_copy_bits(skb, 0, &icmp_param.data.times[0], 4))
BUG();
- icmp_param.data.icmph = *icmp_hdr(skb);
- icmp_param.data.icmph.type = ICMP_TIMESTAMPREPLY;
- icmp_param.data.icmph.code = 0;
+ fill_icmp_param_data(&icmp_param, icmp_hdr(skb),
+ICMP_TIMESTAMPREPLY, 0);
icmp_param.skb = skb;
icmp_param.offset = 0;
icmp_param.data_len= 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
Re: net: alignment problem in icmp code
On Sun, 21 Oct 2007 12:48:14 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > > You are missing a crucial point. > > The compiler may emit the same exact loads and stores when it inlines > memcpy() if it "knows" the objects are aligned properly. And it very > much will do this. > Not sure that would be valid. memcpy() is defined as having void* arguments, and the compiler cannot just ignore that if it chooses to inline it. Still, just give it the char* from the skb and it cannot make any assumption on alignment. Rgds Pierre signature.asc Description: PGP signature
Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
> That's a pity, but AFAIK it shouldn't be a problem because we don't > enable CONFIG_PM on those machines anyway. If we ever want to we'll need > to sort out with firmware how that will work WRT restoring MSI state. I think the current generic code for pci_restore_msi_state() or whatever it's called wilol directly call into write_msi_msg() etc... might be a problem. Ben. - 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
Fw: net: alignment problem in icmp code
Пересылаемое сообщение 21.10.07, 23:48, David Miller ([EMAIL PROTECTED]): From: Pierre Ossman <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 11:34:05 +0200 > Inlining isn't the problem, but the defined semantics of assignment > versus memcpy(). memcpy() must work on any region of memory, whilst > assignment must only work on a properly aligned object. You are missing a crucial point. The compiler may emit the same exact loads and stores when it inlines memcpy() if it "knows" the objects are aligned properly. And it very much will do this. If the compiler is calling memcpy() in your build, it's only because gcc believes the the object is too big to optimally memcpy() inline. - 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 Завершение пересылаемого сообщения -- Яндекс.Открытки - Анонсы новых открыток: http://cards.yandex.ru/subscribe.xml - 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
Fw: net: alignment problem in icmp code
Пересылаемое сообщение 21.10.07, 23:48, David Miller ([EMAIL PROTECTED]): From: Pierre Ossman <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 11:34:05 +0200 > Inlining isn't the problem, but the defined semantics of assignment > versus memcpy(). memcpy() must work on any region of memory, whilst > assignment must only work on a properly aligned object. You are missing a crucial point. The compiler may emit the same exact loads and stores when it inlines memcpy() if it "knows" the objects are aligned properly. And it very much will do this. If the compiler is calling memcpy() in your build, it's only because gcc believes the the object is too big to optimally memcpy() inline. - 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 Завершение пересылаемого сообщения -- "Краски осени": Новый конкурс на Яндекс.Фотках http://fotki.yandex.ru/contest.xml?id=10 - 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: alignment problem in icmp code
From: Pierre Ossman <[EMAIL PROTECTED]> Date: Sun, 21 Oct 2007 11:34:05 +0200 > Inlining isn't the problem, but the defined semantics of assignment > versus memcpy(). memcpy() must work on any region of memory, whilst > assignment must only work on a properly aligned object. You are missing a crucial point. The compiler may emit the same exact loads and stores when it inlines memcpy() if it "knows" the objects are aligned properly. And it very much will do this. If the compiler is calling memcpy() in your build, it's only because gcc believes the the object is too big to optimally memcpy() inline. - 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/3] [NET_DOC] Document some simple rules for actions
Against net-2.6 cheers, jamal 0003-NET_DOC-Document-some-simple-rules-for-actions.txt Description: application/mbox
[PATCH 2/3] [NET_CLS_ACT] Use skb_act_clone
A resubmit against net-2.6 from about an hour ago. cheers, jamal 0002-NET_CLS_ACT-Use-skb_act_clone.txt Description: application/mbox
[PATCHES] cleanup skb_clone
This a re-submission with the last patch fixed up. Three patches to follow: 1) Introduces skb_act_clone 2) Uses skb_act_clone 3) documents expected behavior of actions in case of cloning or copying skbs. cheers, jamal - 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/3] [NET_CLS_ACT] Introduce skb_act_clone
A resubmit against net-2.6 from about an hour ago. cheers, jamal 0001-NET_CLS_ACT-Introduce-skb_act_clone.txt Description: application/mbox
RE: how to set pppoe source mac address?
> -Original Message-
> From: Patrick McHardy [mailto:[EMAIL PROTECTED]
> Sent: den 21 oktober 2007 19:51
> To: Joakim Tjernlund
> Cc: netdev@vger.kernel.org
> Subject: Re: how to set pppoe source mac address?
>
> Joakim Tjernlund wrote:
> > I have several pppoe i/f's over one eth i/f and I want to set the
> > source mac address used by each pppoe i/f to a unique mac
> address from
> > user space.
> >
> > Is this possible? If so, how do I do that?
>
>
> Try the macvlan driver.
>
Thanks, but I can't see that it will help.
I am looking for something like this that I currently have added
to pppoe_ioctl() in pppoe.c:
case PPPOEIOCSSRCMAC:
{
struct relay_source_mac smac;
err = -EBUSY;
if (sk->sk_state & (PPPOX_BOUND|PPPOX_ZOMBIE|PPPOX_DEAD))
break;
err = -ENOTCONN;
if (!(sk->sk_state & PPPOX_CONNECTED))
break;
err = -EFAULT;
if (copy_from_user(&smac, (void *) arg, sizeof(smac)))
break;
memcpy(po->srcmac, smac.srcmac, ETH_ALEN);
err = 0;
break;
}
then changed the call to hard_header in __pppoe_xmit() to
dev->hard_header(skb, dev, ETH_P_PPP_SES,
po->pppoe_pa.remote,
po->srcmac, data_len);
Would a new ioctl(PPPOEIOCSSRCMAC) to pppoe be acceptable?
Jocke
-
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] ipv6.7: IPV6_ROUTER_ALERT sockopt correction
On Wed, Oct 17, 2007 at 09:19:15AM +0300, Pekka Savola wrote: > Router alert option on a hop-by-hop header means that every router on > the path should process the option. I think I understand what you mean by "process the option", but it is a little ambiguous. The abstract of RFC2711 says: This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path. note the "may require special processing by routers" - there is no expectation that /every/ router will want to do such "special processing". For example, there is no expectation that every router supports RSVP. Non-RSVP routers are simply expected to look the router alert option, decide they aren't interested in it and forward it normally. > You did not mention the rationale why the it would be reasonable for a > packet that would otherwise be forwarded by the Linux router and > expected to be processed by every router on the path to be re-created > at every step, and every user-space application have to do that. I'm confused by your description. There is certainly no expectation that every router on the path would be interested in doing "special processing" on the contents of the packet. The purpose of the IPV6_ROUTER_ALERT sockopt is so that a userspace application can say "I'm here, and I'm interested in packets with a router alert option with value field X." The default case where no application has expressed an interest in this way is to forward the packet normally. Anything else would be horrendously broken (though that does currently apply to some BSD stacks). > In the specific case of RSVP packets, AFAIK (e.g., Path and PathTear > messages), the content of the RSVP packet is expected to be the > same at every hop. > > Your argument might make sense in the case where the payload of the > packet carrying router-alert option is expected to change at every > hop. I believe that's not the intent of any router alert options that > I'm aware of. The first sentence of the introduction of RFC2711 (IPv6 Router Alert Option) clearly indicates that modification of packets can occur: New protocols, such as RSVP, use control datagrams which, while addressed to a particular destination, contain information that needs to be examined, and in some case updated, by routers along the path between the source and destination. To take a couple of examples in RSVP: The RSVP_HOP (PHOP) in a PATH message is expected to change at each RSVP-capable node. Its purpose is to tell the next hop the address of the previous hop, so that the RESV can be sent hop-by-hop back along the path followed by the PATH messages. The ADSPEC is designed to gather up information about available resources along the path, so also has to be mutable along the path in order to fulfil its purpose. I hope that helps to clarify things. -- Andrew McDonald E-mail: [EMAIL PROTECTED] http://www.mcdonald.org.uk/andrew/ - 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: how to set pppoe source mac address?
Joakim Tjernlund wrote: I have several pppoe i/f's over one eth i/f and I want to set the source mac address used by each pppoe i/f to a unique mac address from user space. Is this possible? If so, how do I do that? Try the macvlan driver. - 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: iproute2: git pull request from debian repo.
Andreas Henriksson wrote:
- for (;;) {
+ while (round < MAX_ROUNDS) {
if (rtnl_wilddump_request(&rth, filter.family,
RTM_GETADDR) < 0) {
perror("Cannot send dump request");
exit(1);
@@ -694,6 +696,8 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
fflush(stdout);
}
}
+ fprintf(stderr, "*** Flush remains incomplete after %d rounds.
***\n", MAX_ROUNDS); fflush(stderr);
Again, please make this optional. People might want to make
sure the cache is flushed even if it takes a bit longer.
-
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
how to set pppoe source mac address?
I have several pppoe i/f's over one eth i/f and I want to set the source mac address used by each pppoe i/f to a unique mac address from user space. Is this possible? If so, how do I do that? Jocke - 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: PROBLEM: oops, Linus tree: 2.6.23-g4fa4d23f, BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
Le Sun, 21 Oct 2007 13:16:32 +0800, Coly Li <[EMAIL PROTECTED]> a écrit : > > This should be fixed in recent git by > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9b013e05e0289c190a53d78ca029e2f21c0e4485 > > > Maybe we encounter same condition, at least the symbol name is same -- > sock_setsockopt. > [ 4327.550291] EFLAGS: 00010282 (2.6.23-bigsmp-g4fa4d23f #6) You are testing a kernel that does not contain the aforementioned fix, so you should update your git checkout (using a kernel that can connect to the Internet ;-) ) and test the new kernel. Thanks. -- Guillaume - 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] Fix ethernet multicast for ucc_geth.
> -Original Message- > From: Li Yang-r58472 [mailto:[EMAIL PROTECTED] > Sent: den 18 oktober 2007 16:24 > To: [EMAIL PROTECTED]; Netdev; [EMAIL PROTECTED] > Subject: RE: [PATCH] Fix ethernet multicast for ucc_geth. > > > -Original Message- > > From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, October 17, 2007 5:06 PM > > To: Netdev; Li Yang-r58472 > > Subject: [PATCH] Fix ethernet multicast for ucc_geth. > > > > >From 5761a9e5924b34615c748fba2dcb977ed04c1243 Mon Sep 17 > > 00:00:00 2001 > > From: Joakim Tjernlund <[EMAIL PROTECTED]> > > Date: Wed, 17 Oct 2007 11:01:44 +0200 > > Subject: [PATCH] Fix ethernet multicast for ucc_geth. > > hw_add_addr_in_hash() already swaps byte order, don't do it > > in ucc_geth_set_multi() too. > > > > > > Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]> > > Acked-by: Li Yang <[EMAIL PROTECTED]> > Ping? Did this make into a someones tree? Jocke - 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: alignment problem in icmp code
On Sat, 20 Oct 2007 22:12:57 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: Pierre Ossman <[EMAIL PROTECTED]> > Date: Sat, 20 Oct 2007 23:35:40 +0200 > > > Structure assignment have to be aligned just like any assignment, and the > > skb could point to anything. So take the safe route and use a memcpy(). > > > > Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]> > > Unfortunately this doesn't work, GCC can inline the memcpy just like > the assignment. > > I tried to use a similar trick in the net/xfrm/xfrm_user.c code > but in the end it doesn't work at all. Inlining isn't the problem, but the defined semantics of assignment versus memcpy(). memcpy() must work on any region of memory, whilst assignment must only work on a properly aligned object. Since icmphdr contains a u32, the compiler "knows" the object will always be 32-bit aligned and generates assembly based on this assumption. Of course this is incorrect if the lower layers didn't have a multiple of 4 bytes of headers. Anyway, I discovered the hard way that there are lots and lots of places in the IP code that assumes alignment, so this seems to be a rather daunting task to fix. So this patch will just be one very small piece of the puzzle. :/ (Perhaps something for kernel newbies, to track down and fix all the alignment assumptions in the IP stack?) Rgds Pierre signature.asc Description: PGP signature
Re: [ewg] [PATCH 0/14 v2] nes: NetEffect 10Gb RNIC Driver
[EMAIL PROTECTED] wrote: This is the second posting for the series of patches containing the source code for the NetEffect 10Gb RNIC adapter. The driver is split into two components - a kernel driver module and a userspace library. The code can also be found in the following git trees. git.openfabrics.org/~glenn/libnes.git git.openfabrics.org/~glenn/linux-2.6.git Thanks, Glenn. Can you review the release notes of OFED 1.3 and send me update regarding name of cards you support or anything that should be documented Thanks, Tziporet - 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 13/17] netdrvr irq handler cleanups
commit a9f06dc9fb3caea2c4e9b387974c9f4956434e28
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri Oct 19 19:33:31 2007 -0400
[netdrvr] driver irq handler cleanups
* no need to use 'irq' function arg, its already stored in a data struct
* whitespace cleanups
* delete tests for impossible conditions
* remove pointless casts from void*
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/net/eexpress.c | 11 ++-
drivers/net/irda/smsc-ircc2.c | 17 -
drivers/net/irda/via-ircc.c | 12 +++-
drivers/net/pcmcia/fmvj18x_cs.c |7 +--
drivers/net/wan/sdla.c |5 +++--
5 files changed, 17 insertions(+), 35 deletions(-)
a9f06dc9fb3caea2c4e9b387974c9f4956434e28
diff --git a/drivers/net/eexpress.c b/drivers/net/eexpress.c
index 9c85e50..007de3b 100644
--- a/drivers/net/eexpress.c
+++ b/drivers/net/eexpress.c
@@ -456,8 +456,9 @@ static int eexp_open(struct net_device *dev)
if (!dev->irq || !irqrmap[dev->irq])
return -ENXIO;
- ret = request_irq(dev->irq,&eexp_irq,0,dev->name,dev);
- if (ret) return ret;
+ ret = request_irq(dev->irq, &eexp_irq, 0, dev->name, dev);
+ if (ret)
+ return ret;
if (!request_region(ioaddr, EEXP_IO_EXTENT, "EtherExpress")) {
printk(KERN_WARNING "EtherExpress io port %x, is busy.\n"
@@ -768,7 +769,7 @@ static void eexp_cmd_clear(struct net_device *dev)
}
}
-static irqreturn_t eexp_irq(int irq, void *dev_info)
+static irqreturn_t eexp_irq(int dummy, void *dev_info)
{
struct net_device *dev = dev_info;
struct net_local *lp;
@@ -783,7 +784,7 @@ static irqreturn_t eexp_irq(int irq, void *dev_info)
old_read_ptr = inw(ioaddr+READ_PTR);
old_write_ptr = inw(ioaddr+WRITE_PTR);
- outb(SIRQ_dis|irqrmap[irq],ioaddr+SET_IRQ);
+ outb(SIRQ_dis|irqrmap[dev->irq],ioaddr+SET_IRQ);
status = scb_status(dev);
@@ -851,7 +852,7 @@ static irqreturn_t eexp_irq(int irq, void *dev_info)
eexp_cmd_clear(dev);
- outb(SIRQ_en|irqrmap[irq],ioaddr+SET_IRQ);
+ outb(SIRQ_en|irqrmap[dev->irq],ioaddr+SET_IRQ);
#if NET_DEBUG > 6
printk("%s: leaving eexp_irq()\n", dev->name);
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 7e7b582..1f26da7 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -1505,22 +1505,13 @@ static void smsc_ircc_sir_receive(struct smsc_ircc_cb
*self)
*An interrupt from the chip has arrived. Time to do some work
*
*/
-static irqreturn_t smsc_ircc_interrupt(int irq, void *dev_id)
+static irqreturn_t smsc_ircc_interrupt(int dummy, void *dev_id)
{
- struct net_device *dev = (struct net_device *) dev_id;
- struct smsc_ircc_cb *self;
+ struct net_device *dev = dev_id;
+ struct smsc_ircc_cb *self = netdev_priv(dev);
int iobase, iir, lcra, lsr;
irqreturn_t ret = IRQ_NONE;
- if (dev == NULL) {
- printk(KERN_WARNING "%s: irq %d for unknown device.\n",
- driver_name, irq);
- goto irq_ret;
- }
-
- self = netdev_priv(dev);
- IRDA_ASSERT(self != NULL, return IRQ_NONE;);
-
/* Serialise the interrupt handler in various CPUs, stop Tx path */
spin_lock(&self->lock);
@@ -1565,7 +1556,7 @@ static irqreturn_t smsc_ircc_interrupt(int irq, void
*dev_id)
irq_ret_unlock:
spin_unlock(&self->lock);
- irq_ret:
+
return ret;
}
diff --git a/drivers/net/irda/via-ircc.c b/drivers/net/irda/via-ircc.c
index 126ec7c..58e1287 100644
--- a/drivers/net/irda/via-ircc.c
+++ b/drivers/net/irda/via-ircc.c
@@ -1346,19 +1346,13 @@ static int RxTimerHandler(struct via_ircc_cb *self, int
iobase)
*An interrupt from the chip has arrived. Time to do some work
*
*/
-static irqreturn_t via_ircc_interrupt(int irq, void *dev_id)
+static irqreturn_t via_ircc_interrupt(int dummy, void *dev_id)
{
- struct net_device *dev = (struct net_device *) dev_id;
- struct via_ircc_cb *self;
+ struct net_device *dev = dev_id;
+ struct via_ircc_cb *self = dev->priv;
int iobase;
u8 iHostIntType, iRxIntType, iTxIntType;
- if (!dev) {
- IRDA_WARNING("%s: irq %d for unknown device.\n", driver_name,
-irq);
- return IRQ_NONE;
- }
- self = (struct via_ircc_cb *) dev->priv;
iobase = self->io.fir_base;
spin_lock(&self->lock);
iHostIntType = GetHostStatus(iobase);
diff --git a/drivers/net/pcmcia/fmvj18x_cs.c b/drivers/net/pcmcia/fmvj18x_cs.c
index 6284467..d251bd1 100644
--- a/drivers/net/pcmcia/fmvj18x_cs.c
+++ b/drivers/net/pcmcia/fmvj18x_cs.c
@@ -731,18 +731,13 @@ module_exit(exit_fmvj18x_cs);
/**/
-static irqreturn_t fjn_in
