* Re: [iproute2] iproute2: Fix 'addr flush secondary' logic.
From: Ben Greear @ 2010-08-11 20:53 UTC (permalink / raw)
To: Brian Haley; +Cc: netdev
In-Reply-To: <4C630B0A.9010304@hp.com>
On 08/11/2010 01:41 PM, Brian Haley wrote:
> On 08/11/2010 01:19 PM, Ben Greear wrote:
>> @@ -648,7 +648,7 @@ int print_addrinfo_secondary(const struct sockaddr_nl *who, struct nlmsghdr *n,
>> {
>> struct ifaddrmsg *ifa = NLMSG_DATA(n);
>>
>> - if (ifa->ifa_flags& IFA_F_SECONDARY)
>> + if (!ifa->ifa_flags& IFA_F_SECONDARY)
>> return 0;
>
> Shouldn't this be:
>
> if (!(ifa->ifa_flags& IFA_F_SECONDARY))
Yes, that looks like a bug. Let me re-test to make sure
it wasn't hiding other bugs and will re-submit.
Thanks,
Ben
>
> -Brian
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] netpoll: use non-BH variant of RCU
From: Paul E. McKenney @ 2010-08-11 22:00 UTC (permalink / raw)
To: David Miller; +Cc: herbert, linville, netdev
In-Reply-To: <20100810.163117.241919476.davem@davemloft.net>
On Tue, Aug 10, 2010 at 04:31:17PM -0700, David Miller wrote:
> From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Date: Tue, 10 Aug 2010 14:19:32 -0700
>
> > Your suggestion of providing another API rcu_read_lock_irqsoff()
> > and rcu_read_unlock_irqsoff() is the best I can think of right offhand.
> >
> > What tree/commit do you need the patch against?
>
> Linus's tree is fine for this.
>
> But we need this fix for 2.6.35-stable too. Herbert would
> you object to putting John's more simple fix there?
>
> John, when referencing other commits in commit messages,
> please provide the SHA1 ID as well as the commit message
> header line.
And here is an interim patch. I have queued a slightly different
patch that takes advantage of the more sophisticated PROVE_RCU handling
currently in -tip, but the API is the same, so code written against
this patch will work against the upcoming patch.
Thoughts?
Thanx, Paul
commit 8934f3fd1092b7ef6a1524e1d2356baeec9f330e
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Wed Aug 11 14:54:33 2010 -0700
rcu: add rcu_read_lock_bh_irqsoff() and rcu_read_unlock_bh_irqsoff()
The rcu_read_lock_bh() and rcu_read_unlock_bh() functions can no
longer be used when interrupts are disabled due to new debug checks in
the _local_bh_enable() function. This commit therefore supplies new
functions that may only be called with either interrupts disabled or
from interrupt handlers, and this is checked for under CONFIG_PROVE_RCU.
Requested-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 9fbc54a..08cdc58 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -270,10 +270,13 @@ extern int rcu_my_thread_group_empty(void);
(p); \
})
+void rcu_read_unlock_bh_irqsoff_check(void);
+
#else /* #ifdef CONFIG_PROVE_RCU */
#define rcu_dereference_check(p, c) rcu_dereference_raw(p)
#define rcu_dereference_protected(p, c) (p)
+#define rcu_read_unlock_bh_irqsoff_check() do { } while (0)
#endif /* #else #ifdef CONFIG_PROVE_RCU */
@@ -361,13 +364,13 @@ static inline void rcu_read_unlock(void)
*/
static inline void rcu_read_lock_bh(void)
{
- __rcu_read_lock_bh();
+ local_bh_disable();
__acquire(RCU_BH);
rcu_read_acquire_bh();
}
/*
- * rcu_read_unlock_bh - marks the end of a softirq-only RCU critical section
+ * rcu_read_unlock_bh() - marks the end of a softirq-only RCU critical section
*
* See rcu_read_lock_bh() for more information.
*/
@@ -375,7 +378,34 @@ static inline void rcu_read_unlock_bh(void)
{
rcu_read_release_bh();
__release(RCU_BH);
- __rcu_read_unlock_bh();
+ local_bh_enable();
+}
+
+/**
+ * rcu_read_lock_bh_irqsoff() - mark the beginning of an RCU-bh critical section
+ *
+ * This is equivalent of rcu_read_lock_bh(), but to be used where the
+ * caller either is in an irq handler or has irqs disabled. Note that
+ * this function assumes that PREEMPT_RT kernels run irq handlers at
+ * higher priority than softirq handlers!
+ */
+static inline void rcu_read_lock_bh_irqsoff(void)
+{
+ rcu_read_unlock_bh_irqsoff_check();
+ __acquire(RCU_BH);
+ rcu_read_acquire_bh();
+}
+
+/*
+ * rcu_read_unlock_bh_irqsoff - marks the end of an RCU-bh critical section
+ *
+ * See rcu_read_lock_bh_irqsoff() for more information.
+ */
+static inline void rcu_read_unlock_bh_irqsoff(void)
+{
+ rcu_read_release_bh();
+ __release(RCU_BH);
+ rcu_read_unlock_bh_irqsoff_check();
}
/**
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index e2e8931..009c7f3 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -36,8 +36,6 @@ static inline void rcu_note_context_switch(int cpu)
#define __rcu_read_lock() preempt_disable()
#define __rcu_read_unlock() preempt_enable()
-#define __rcu_read_lock_bh() local_bh_disable()
-#define __rcu_read_unlock_bh() local_bh_enable()
#define call_rcu_sched call_rcu
#define rcu_init_sched() do { } while (0)
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index c0ed1c0..98b50d8 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -75,15 +75,6 @@ static inline int rcu_preempt_depth(void)
#endif /* #else #ifdef CONFIG_TREE_PREEMPT_RCU */
-static inline void __rcu_read_lock_bh(void)
-{
- local_bh_disable();
-}
-static inline void __rcu_read_unlock_bh(void)
-{
- local_bh_enable();
-}
-
extern void call_rcu_sched(struct rcu_head *head,
void (*func)(struct rcu_head *rcu));
extern void synchronize_rcu_bh(void);
diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
index 4d16983..d159835 100644
--- a/kernel/rcupdate.c
+++ b/kernel/rcupdate.c
@@ -113,6 +113,12 @@ int rcu_my_thread_group_empty(void)
return thread_group_empty(current);
}
EXPORT_SYMBOL_GPL(rcu_my_thread_group_empty);
+
+void rcu_read_unlock_bh_irqsoff_check(void)
+{
+ WARN_ON_ONCE(in_irq() || irqs_disabled());
+}
+EXPORT_SYMBOL_GPL(rcu_read_unlock_bh_irqsoff_check);
#endif /* #ifdef CONFIG_PROVE_RCU */
#ifdef CONFIG_DEBUG_OBJECTS_RCU_HEAD
^ permalink raw reply related
* Re: Problem with non aligned DMA in usbnet on ARM
From: Martin Fuzzey @ 2010-08-11 22:20 UTC (permalink / raw)
To: Russell King - ARM Linux, Gary King
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-usb, netdev-u79uwXL29TY76Z2rM5mHXA, Greg KH
In-Reply-To: <20100811203505.GA463-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
[Gary, you forgot to copy -usb and netdev so adding them again to try to
keep this thread joined up]
Russell King - ARM Linux wrote:
> On Wed, Aug 11, 2010 at 08:54:27AM -0700, Gary King wrote:
>
>> I sent a patch to the list about 2 weeks ago that added support to
>> DMA bounce to bounce for misaligned buffers. We have a similar
>> problem with URB alignment for usbnet on Tegra's HCD:
>> http://lists.arm.linux.org.uk/lurker/message/20100729.005746.b43fa1d9.en.html
>>
Nice to know someone else has the same problem :)
What is the Tegra hcd?
I can't find it in the kernel sources.
> We don't want to add support for this to DMA bounce. DMA bounce is already
> a pain in the backside and causes its own set of problems - please let it
> die a long slow but quite death.
>
> If you want to see the kind of pain dmabounce causes, look at this long
> standing and as yet unsolved bug:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=7760
>
>
Well I don't know the dmabounce code but why is using it likely to cause
OOM problems (at least why more so than copying the buffer in the HCD or
the usb core). In both cases there will be two copies of the buffer in
memory which could I agree be a problem in memory constrained systems.
But if we _do_ want to accept unaligned buffers from usb drivers I can't
see a way round that.
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Problem with non aligned DMA in usbnet on ARM
From: Martin Fuzzey @ 2010-08-11 22:31 UTC (permalink / raw)
To: Greg KH
Cc: Russell King - ARM Linux, linux-usb,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20100811201332.GB10379-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
Greg KH wrote:
> Can you fix this in the host controller driver?
>
>
Technically yes (by copying the unaligned buffers).
But if we do decide that USB must support unaligned buffers wouldn't it
be better to have the HCD indicate it's alignment requirement to the
core and have the core do the copying?
Gary King sent a message to this thread but only to the arm list saying
he has the same problem with the tegra hcd (which doesn't seem to be in
the tree yet.) I don't know if any of the other in tree HCDs have this
problem.
Also if this is a new requirement for HCDs usbtest probably needs a new
test...
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Problem with non aligned DMA in usbnet on ARM
From: Russell King - ARM Linux @ 2010-08-11 22:47 UTC (permalink / raw)
To: Martin Fuzzey
Cc: Gary King, linux-arm-kernel@lists.infradead.org, linux-usb,
netdev, Greg KH
In-Reply-To: <4C632217.9000608@gmail.com>
On Thu, Aug 12, 2010 at 12:20:07AM +0200, Martin Fuzzey wrote:
> [Gary, you forgot to copy -usb and netdev so adding them again to try to
> keep this thread joined up]
>
> Russell King - ARM Linux wrote:
> > On Wed, Aug 11, 2010 at 08:54:27AM -0700, Gary King wrote:
> >
> >> I sent a patch to the list about 2 weeks ago that added support to
> >> DMA bounce to bounce for misaligned buffers. We have a similar
> >> problem with URB alignment for usbnet on Tegra's HCD:
> >> http://lists.arm.linux.org.uk/lurker/message/20100729.005746.b43fa1d9.en.html
>
> Nice to know someone else has the same problem :)
> What is the Tegra hcd?
> I can't find it in the kernel sources.
>
> > We don't want to add support for this to DMA bounce. DMA bounce is already
> > a pain in the backside and causes its own set of problems - please let it
> > die a long slow but quite death.
> >
> > If you want to see the kind of pain dmabounce causes, look at this long
> > standing and as yet unsolved bug:
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=7760
>
> Well I don't know the dmabounce code but why is using it likely to cause
> OOM problems (at least why more so than copying the buffer in the HCD or
> the usb core).
The problem in that bug appears to be that there's soo much pressure on
the first 64MB of memory that we run out of sufficiently large blocks
of memory to be able to satisfy the requirements to do DMA bouncing via
the dmabounce code. I don't think anyone got to the bottom of why the
DMA zone was exhausted first before the DMA32 zone ran out of pages.
However, as something using dma_map_single/dma_map_page has to return a
contiguous buffer, we do need to use high order allocations for them - a
driver on the other hand can make a decision about whether its possible
to break up the buffer into smaller (and therefore easier to allocate)
buffers.
> In both cases there will be two copies of the buffer in
> memory which could I agree be a problem in memory constrained systems.
> But if we _do_ want to accept unaligned buffers from usb drivers I can't
> see a way round that.
One thing we have done in the past (eg, SMC91x network driver on PXA) is
to PIO the first couple of bytes to the device, and DMA the remainder -
the DMA can't do non-word aligned start addresses. This gives us the
benefit of being able to deal with buffers containing IP packets without
copying them, while preserving the performance of using DMA.
^ permalink raw reply
* Re: [iproute2] iproute2: Fix 'addr flush secondary' logic.
From: Ben Greear @ 2010-08-11 22:48 UTC (permalink / raw)
To: Brian Haley; +Cc: netdev
In-Reply-To: <4C630B0A.9010304@hp.com>
[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]
On 08/11/2010 01:41 PM, Brian Haley wrote:
> On 08/11/2010 01:19 PM, Ben Greear wrote:
>> @@ -648,7 +648,7 @@ int print_addrinfo_secondary(const struct sockaddr_nl *who, struct nlmsghdr *n,
>> {
>> struct ifaddrmsg *ifa = NLMSG_DATA(n);
>>
>> - if (ifa->ifa_flags& IFA_F_SECONDARY)
>> + if (!ifa->ifa_flags& IFA_F_SECONDARY)
>> return 0;
>
> Shouldn't this be:
>
> if (!(ifa->ifa_flags& IFA_F_SECONDARY))
>
> -Brian
Looks like the code was broken in several different places.
* It ran only a single filter if there were multiple.
* Don't want to flush in a loop if you are doing primary
because otherwise promoted seconaries will get deleted
for each additional loop (10 in upstream code).
* No idea what a while (0); statement at the end of a for
loop does, but I don't think it needed to be there!
The attached patch makes it work for me, supporting
flushing primary or secondary addresses.
It could certainly use some review, however.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
[-- Attachment #2: iproute_flush.patch --]
[-- Type: text/plain, Size: 2813 bytes --]
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 5f0789c..803df17 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -637,7 +637,7 @@ int print_addrinfo_primary(const struct sockaddr_nl *who, struct nlmsghdr *n,
{
struct ifaddrmsg *ifa = NLMSG_DATA(n);
- if (!ifa->ifa_flags & IFA_F_SECONDARY)
+ if (ifa->ifa_flags & IFA_F_SECONDARY)
return 0;
return print_addrinfo(who, n, arg);
@@ -648,7 +648,7 @@ int print_addrinfo_secondary(const struct sockaddr_nl *who, struct nlmsghdr *n,
{
struct ifaddrmsg *ifa = NLMSG_DATA(n);
- if (ifa->ifa_flags & IFA_F_SECONDARY)
+ if (!(ifa->ifa_flags & IFA_F_SECONDARY))
return 0;
return print_addrinfo(who, n, arg);
@@ -865,6 +865,13 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
printf("\n*** Round %d, deleting %d addresses ***\n", round, filter.flushed);
fflush(stdout);
}
+
+ /* If we are flushing, and specifying primary, then we want to flush only a single round.
+ * Otherwise, we'll start flushing secondaries that were promoted to primaries
+ */
+ if (!(filter.flags & IFA_F_SECONDARY) && (filter.flagmask & IFA_F_SECONDARY)) {
+ return 0;
+ }
}
fprintf(stderr, "*** Flush remains incomplete after %d rounds. ***\n", max_flush_loops);
fflush(stderr);
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index cfeb894..d18e8a0 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -189,6 +189,8 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
while (1) {
int status;
const struct rtnl_dump_filter_arg *a;
+ int found_done = 0;
+ int msglen = 0;
iov.iov_len = sizeof(buf);
status = recvmsg(rth->fd, &msg, 0);
@@ -208,8 +210,9 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
for (a = arg; a->filter; a++) {
struct nlmsghdr *h = (struct nlmsghdr*)buf;
+ msglen = status;
- while (NLMSG_OK(h, status)) {
+ while (NLMSG_OK(h, msglen)) {
int err;
if (nladdr.nl_pid != 0 ||
@@ -224,8 +227,10 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
goto skip_it;
}
- if (h->nlmsg_type == NLMSG_DONE)
- return 0;
+ if (h->nlmsg_type == NLMSG_DONE) {
+ found_done = 1;
+ break; /* process next filter */
+ }
if (h->nlmsg_type == NLMSG_ERROR) {
struct nlmsgerr *err = (struct nlmsgerr*)NLMSG_DATA(h);
if (h->nlmsg_len < NLMSG_LENGTH(sizeof(struct nlmsgerr))) {
@@ -242,14 +247,18 @@ int rtnl_dump_filter_l(struct rtnl_handle *rth,
return err;
skip_it:
- h = NLMSG_NEXT(h, status);
+ h = NLMSG_NEXT(h, msglen);
}
- } while (0);
+ }
+
+ if (found_done)
+ return 0;
+
if (msg.msg_flags & MSG_TRUNC) {
fprintf(stderr, "Message truncated\n");
continue;
}
- if (status) {
+ if (msglen) {
fprintf(stderr, "!!!Remnant of size %d\n", status);
exit(1);
}
^ permalink raw reply related
* Re: [PATCH] can: add limit for nframes and clean up signed/unsigned variables
From: David Miller @ 2010-08-11 23:12 UTC (permalink / raw)
To: socketcan; +Cc: hawkes, urs.thuermann, netdev
In-Reply-To: <4C627102.1080205@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Wed, 11 Aug 2010 11:44:34 +0200
> This patch adds a limit for nframes as the number of frames in TX_SETUP and
> RX_SETUP are derived from a single byte multiplex value by default.
> Use-cases that would require to send/filter more than 256 CAN frames should
> be implemented in userspace for complexity reasons anyway.
>
> Additionally the assignments of unsigned values from userspace to signed
> values in kernelspace and vice versa are fixed by using unsigned values in
> kernelspace consistently.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> Reported-by: Ben Hawkes <hawkes@google.com>
> Acked-by: Urs Thuermann <urs.thuermann@volkswagen.de>
Applied and I'll queue this up for -stable, thanks.
^ permalink raw reply
* [PATCH -next] phylib: available for any speed ethernet
From: Randy Dunlap @ 2010-08-11 23:26 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <randy.dunlap@oracle.com>
Several gigabit network drivers (SB1250_MAC, TIGON3, FSL, GIANFAR,
UCC_GETH, MV643XX_ETH, XILINX_LL_TEMAC, S6GMAC, STMMAC_ETH, PASEMI_MAC,
and OCTEON_ETHERNET) select PHYLIB. These drivers are not under
NET_ETHERNET (10/100 mbit), so this warning is generated (long, irrelevant
parts are omitted):
warning: (NET_DSA && NET && EXPERIMENTAL && NET_ETHERNET && !S390 || ... || SB1250_MAC && NETDEVICES && NETDEV_1000 && SIBYTE_SB1xxx_SOC || TIGON3 && NETDEVICES && NETDEV_1000 && PCI || FSL_PQ_MDIO && NETDEVICES && NETDEV_1000 && FSL_SOC || GIANFAR && NETDEVICES && NETDEV_1000 && FSL_SOC || UCC_GETH && NETDEVICES && NETDEV_1000 && QUICC_ENGINE || MV643XX_ETH && NETDEVICES && NETDEV_1000 && (MV64X60 || PPC32 || PLAT_ORION) || XILINX_LL_TEMAC && NETDEVICES && NETDEV_1000 && (PPC || MICROBLAZE) || S6GMAC && NETDEVICES && NETDEV_1000 && XTENSA_VARIANT_S6000 || STMMAC_ETH && NETDEV_1000 && NETDEVICES && CPU_SUBTYPE_ST40 || PASEMI_MAC && NETDEVICES && NETDEV_10000 && PPC_PASEMI && PCI || OCTEON_ETHERNET && STAGING && !STAGING_EXCLUDE_BUILD && CPU_CAVIUM_OCTEON) selects PHYLIB which has unmet dir
ect dependencies (!S390 && NET_ETHERNET)
PHYLIB is used by non-10/100 mbit ethernet drivers, so change the dependencies
to be NETDEVICES instead of NET_ETHERNET.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/net/phy/Kconfig | 2 +-
net/dsa/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20100810.orig/drivers/net/phy/Kconfig
+++ linux-next-20100810/drivers/net/phy/Kconfig
@@ -5,7 +5,7 @@
menuconfig PHYLIB
tristate "PHY Device support and infrastructure"
depends on !S390
- depends on NET_ETHERNET
+ depends on NETDEVICES
help
Ethernet controllers are usually attached to PHY
devices. This option provides infrastructure for
--- linux-next-20100810.orig/net/dsa/Kconfig
+++ linux-next-20100810/net/dsa/Kconfig
@@ -1,7 +1,7 @@
menuconfig NET_DSA
bool "Distributed Switch Architecture support"
default n
- depends on EXPERIMENTAL && NET_ETHERNET && !S390
+ depends on EXPERIMENTAL && NETDEVICES && !S390
select PHYLIB
---help---
This allows you to use hardware switch chips that use
^ permalink raw reply
* Re: [PATCH 2/2] ipw2100: add WEXT scan capabilities
From: Dan Williams @ 2010-08-11 23:32 UTC (permalink / raw)
To: Christoph Fritz
Cc: John W. Linville, Zhu Yi, David S. Miller, Joe Perches,
Rafael J. Wysocki, linux-wireless, netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <1281555195.4367.3.camel@lovely.krouter>
On Wed, 2010-08-11 at 21:33 +0200, Christoph Fritz wrote:
> NetworkManager claims: "driver does not support SSID scans (scan_capa
> 0x00)". This patch adds scan capabilities.
NAK
It just doesn't. Take a look at ipw2100_wx_set_scan(); there's no
handling of any SSID stuff in there. The driver does not support
probe-scans; I'm not sure if the firmware does, but even if it does, the
driver doesn't send the SSID down to the firmware.
Compare this to the ipw2200.c set_scan() function. It just does not
appear that the ipw2100 supports arbitrary SSIDs for direct scans, which
is why I didn't include this capability when I went around patching the
drivers a few years ago.
Dan
> Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
> ---
> drivers/net/wireless/ipw2x00/ipw2100.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c b/drivers/net/wireless/ipw2x00/ipw2100.c
> index df8e535..c330da4 100644
> --- a/drivers/net/wireless/ipw2x00/ipw2100.c
> +++ b/drivers/net/wireless/ipw2x00/ipw2100.c
> @@ -6982,12 +6982,15 @@ static int ipw2100_wx_get_range(struct net_device *dev,
>
> /* Event capability (kernel + driver) */
> range->event_capa[0] = (IW_EVENT_CAPA_K_0 |
> - IW_EVENT_CAPA_MASK(SIOCGIWAP));
> + IW_EVENT_CAPA_MASK(SIOCGIWAP) |
> + IW_EVENT_CAPA_MASK(SIOCGIWSCAN));
> range->event_capa[1] = IW_EVENT_CAPA_K_1;
>
> range->enc_capa = IW_ENC_CAPA_WPA | IW_ENC_CAPA_WPA2 |
> IW_ENC_CAPA_CIPHER_TKIP | IW_ENC_CAPA_CIPHER_CCMP;
>
> + range->scan_capa = IW_SCAN_CAPA_ESSID | IW_SCAN_CAPA_TYPE;
> +
> IPW_DEBUG_WX("GET Range\n");
>
> return 0;
^ permalink raw reply
* [036/111] arp_notify: allow drivers to explicitly request a notification event.
From: Greg KH @ 2010-08-11 23:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Ian Campbell,
Stephen Hemminger, Jeremy Fitzhardinge, David S. Miller, netdev
In-Reply-To: <20100811235623.GA24440@kroah.com>
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <Ian.Campbell@citrix.com>
commit 06c4648d46d1b757d6b9591a86810be79818b60c upstream.
Currently such notifications are only generated when the device comes up or the
address changes. However one use case for these notifications is to enable
faster network recovery after a virtual machine migration (by causing switches
to relearn their MAC tables). A migration appears to the network stack as a
temporary loss of carrier and therefore does not trigger either of the current
conditions. Rather than adding carrier up as a trigger (which can cause issues
when interfaces a flapping) simply add an interface which the driver can use
to explicitly trigger the notification.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/netdevice.h | 2 ++
include/linux/notifier.h | 1 +
net/ipv4/devinet.c | 1 +
net/sched/sch_generic.c | 18 ++++++++++++++++++
4 files changed, 22 insertions(+)
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1560,6 +1560,8 @@ extern void netif_carrier_on(struct net_
extern void netif_carrier_off(struct net_device *dev);
+extern void netif_notify_peers(struct net_device *dev);
+
/**
* netif_dormant_on - mark device as dormant.
* @dev: network device
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -201,6 +201,7 @@ static inline int notifier_to_errno(int
#define NETDEV_PRE_UP 0x000D
#define NETDEV_BONDING_OLDTYPE 0x000E
#define NETDEV_BONDING_NEWTYPE 0x000F
+#define NETDEV_NOTIFY_PEERS 0x0012
#define SYS_DOWN 0x0001 /* Notify of system down */
#define SYS_RESTART SYS_DOWN
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1076,6 +1076,7 @@ static int inetdev_event(struct notifier
}
ip_mc_up(in_dev);
/* fall through */
+ case NETDEV_NOTIFY_PEERS:
case NETDEV_CHANGEADDR:
/* Send gratuitous ARP to notify of link change */
if (IN_DEV_ARP_NOTIFY(in_dev)) {
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -330,6 +330,24 @@ void netif_carrier_off(struct net_device
}
EXPORT_SYMBOL(netif_carrier_off);
+/**
+ * netif_notify_peers - notify network peers about existence of @dev
+ * @dev: network device
+ *
+ * Generate traffic such that interested network peers are aware of
+ * @dev, such as by generating a gratuitous ARP. This may be used when
+ * a device wants to inform the rest of the network about some sort of
+ * reconfiguration such as a failover event or virtual machine
+ * migration.
+ */
+void netif_notify_peers(struct net_device *dev)
+{
+ rtnl_lock();
+ call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, dev);
+ rtnl_unlock();
+}
+EXPORT_SYMBOL(netif_notify_peers);
+
/* "NOOP" scheduler: the best scheduler, recommended for all interfaces
under all circumstances. It is difficult to invent anything faster or
cheaper.
^ permalink raw reply
* [037/111] xen: netfront: explicitly generate arp_notify event after migration.
From: Greg KH @ 2010-08-11 23:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jeremy Fitzhardinge, xen-devel, Ian Campbell, torvalds,
David S. Miller, netdev, akpm, Stephen Hemminger, stable-review,
alan
In-Reply-To: <20100811235623.GA24440@kroah.com>
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <Ian.Campbell@citrix.com>
commit 592970675c9522bde588b945388c7995c8b51328 upstream.
Use newly introduced netif_notify_peers() method to ensure a gratuitous ARP is
generated after a migration.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1619,6 +1619,7 @@ static void backend_changed(struct xenbu
if (xennet_connect(netdev) != 0)
break;
xenbus_switch_state(dev, XenbusStateConnected);
+ netif_notify_peers(netdev);
break;
case XenbusStateClosing:
^ permalink raw reply
* [45/54] arp_notify: allow drivers to explicitly request a notification event.
From: Greg KH @ 2010-08-12 0:01 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Ian Campbell,
Stephen Hemminger, Jeremy Fitzhardinge, David S. Miller, netdev
In-Reply-To: <20100812000249.GA30948@kroah.com>
2.6.34-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <Ian.Campbell@citrix.com>
commit 06c4648d46d1b757d6b9591a86810be79818b60c upstream.
Currently such notifications are only generated when the device comes up or the
address changes. However one use case for these notifications is to enable
faster network recovery after a virtual machine migration (by causing switches
to relearn their MAC tables). A migration appears to the network stack as a
temporary loss of carrier and therefore does not trigger either of the current
conditions. Rather than adding carrier up as a trigger (which can cause issues
when interfaces a flapping) simply add an interface which the driver can use
to explicitly trigger the notification.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/netdevice.h | 2 ++
include/linux/notifier.h | 1 +
net/ipv4/devinet.c | 1 +
net/sched/sch_generic.c | 18 ++++++++++++++++++
4 files changed, 22 insertions(+)
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1661,6 +1661,8 @@ extern void netif_carrier_on(struct net_
extern void netif_carrier_off(struct net_device *dev);
+extern void netif_notify_peers(struct net_device *dev);
+
/**
* netif_dormant_on - mark device as dormant.
* @dev: network device
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -203,6 +203,7 @@ static inline int notifier_to_errno(int
#define NETDEV_BONDING_NEWTYPE 0x000F
#define NETDEV_POST_INIT 0x0010
#define NETDEV_UNREGISTER_BATCH 0x0011
+#define NETDEV_NOTIFY_PEERS 0x0012
#define SYS_DOWN 0x0001 /* Notify of system down */
#define SYS_RESTART SYS_DOWN
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1081,6 +1081,7 @@ static int inetdev_event(struct notifier
}
ip_mc_up(in_dev);
/* fall through */
+ case NETDEV_NOTIFY_PEERS:
case NETDEV_CHANGEADDR:
/* Send gratuitous ARP to notify of link change */
if (IN_DEV_ARP_NOTIFY(in_dev)) {
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -325,6 +325,24 @@ void netif_carrier_off(struct net_device
}
EXPORT_SYMBOL(netif_carrier_off);
+/**
+ * netif_notify_peers - notify network peers about existence of @dev
+ * @dev: network device
+ *
+ * Generate traffic such that interested network peers are aware of
+ * @dev, such as by generating a gratuitous ARP. This may be used when
+ * a device wants to inform the rest of the network about some sort of
+ * reconfiguration such as a failover event or virtual machine
+ * migration.
+ */
+void netif_notify_peers(struct net_device *dev)
+{
+ rtnl_lock();
+ call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, dev);
+ rtnl_unlock();
+}
+EXPORT_SYMBOL(netif_notify_peers);
+
/* "NOOP" scheduler: the best scheduler, recommended for all interfaces
under all circumstances. It is difficult to invent anything faster or
cheaper.
^ permalink raw reply
* [46/54] xen: netfront: explicitly generate arp_notify event after migration.
From: Greg KH @ 2010-08-12 0:01 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jeremy Fitzhardinge, xen-devel, Ian Campbell, torvalds,
David S. Miller, netdev, akpm, Stephen Hemminger, stable-review,
alan
In-Reply-To: <20100812000249.GA30948@kroah.com>
2.6.34-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ian Campbell <Ian.Campbell@citrix.com>
commit 592970675c9522bde588b945388c7995c8b51328 upstream.
Use newly introduced netif_notify_peers() method to ensure a gratuitous ARP is
generated after a migration.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1621,6 +1621,7 @@ static void backend_changed(struct xenbu
if (xennet_connect(netdev) != 0)
break;
xenbus_switch_state(dev, XenbusStateConnected);
+ netif_notify_peers(netdev);
break;
case XenbusStateClosing:
^ permalink raw reply
* sky2 driver fails to handle "rx length error: status 0x5d60100 length 2982" gracefully
From: Maciej Żenczykowski @ 2010-08-12 0:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux NetDev
[See https://bugzilla.redhat.com/show_bug.cgi?id=592398 ]
Latest tested kernel (from koji for Fedora 13):
2.6.34.3-35.rc1.fc13.x86_64
Basically occasionally, but possibly more and more often with recent
kernels (I think .33 and .34 are worse then .32) the sky2 driver locks
up.
During this time the nic functions like a DSL line with a 95% drop
rate. ie. sometimes something does get through, but mostly it's dead.
"ip link set eth0 down && ip link set eth0 up" is enough to fix it.
Here's the initial occurrence of this problem on the above kernel.
Aug 11 16:21:19 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
status 0x5d60100 length 2982
Aug 11 16:21:27 nike kernel: eth0: hw csum failure.
Aug 11 16:21:27 nike kernel: Pid: 0, comm: swapper Not tainted
2.6.34.3-35.rc1.fc13.x86_64 #1
Aug 11 16:21:27 nike kernel: Call Trace:
Aug 11 16:21:27 nike kernel: <IRQ> [<ffffffff813a5c5b>]
netdev_rx_csum_fault+0x3b/0x3f
Aug 11 16:21:27 nike kernel: [<ffffffff8139f909>]
__skb_checksum_complete_head+0x51/0x65
Aug 11 16:21:27 nike kernel: [<ffffffff8139f92e>]
__skb_checksum_complete+0x11/0x13
Aug 11 16:21:27 nike kernel: [<ffffffff8140c339>] nf_ip_checksum+0xdd/0xe3
Aug 11 16:21:27 nike kernel: [<ffffffff813cc791>] udp_error+0x130/0x18a
Aug 11 16:21:27 nike kernel: [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
Aug 11 16:21:27 nike kernel: [<ffffffff81037c67>] ? activate_task+0x2f/0x37
Aug 11 16:21:27 nike kernel: [<ffffffff813c7d69>] nf_conntrack_in+0x180/0x90e
Aug 11 16:21:27 nike kernel: [<ffffffff8103ea37>] ? enqueue_task_fair+0x44/0x87
Aug 11 16:21:27 nike kernel: [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
Aug 11 16:21:27 nike kernel: [<ffffffff8140c995>] ipv4_conntrack_in+0x21/0x23
Aug 11 16:21:27 nike kernel: [<ffffffff813c4c56>] nf_iterate+0x46/0x89
Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
Aug 11 16:21:27 nike kernel: [<ffffffff813c4d03>] nf_hook_slow+0x6a/0xcb
Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
Aug 11 16:21:27 nike kernel: [<ffffffff813d4e51>] NF_HOOK.clone.1+0x46/0x58
Aug 11 16:21:27 nike kernel: [<ffffffff8106e106>] ? getnstimeofday+0x63/0xb9
Aug 11 16:21:27 nike kernel: [<ffffffff813d510b>] ip_rcv+0x256/0x283
Aug 11 16:21:27 nike kernel: [<ffffffff813a53de>] netif_receive_skb+0x493/0x4b9
Aug 11 16:21:27 nike kernel: [<ffffffff813a5baa>] napi_skb_finish+0x29/0x40
Aug 11 16:21:27 nike kernel: [<ffffffff813a5bf0>] napi_gro_receive+0x2f/0x34
Aug 11 16:21:27 nike kernel: [<ffffffffa0160381>] sky2_poll+0x9c5/0xc58 [sky2]
Aug 11 16:21:27 nike kernel: [<ffffffff813a568f>] net_rx_action+0xaf/0x1ca
Aug 11 16:21:27 nike kernel: [<ffffffff81053244>] __do_softirq+0xe5/0x1a6
Aug 11 16:21:27 nike kernel: [<ffffffff8109e119>] ? handle_IRQ_event+0x60/0x121
Aug 11 16:21:27 nike kernel: [<ffffffff8100ab5c>] call_softirq+0x1c/0x30
Aug 11 16:21:27 nike kernel: [<ffffffff8100c342>] do_softirq+0x46/0x83
Aug 11 16:21:27 nike kernel: [<ffffffff810530b5>] irq_exit+0x3b/0x7d
Aug 11 16:21:27 nike kernel: [<ffffffff81452434>] do_IRQ+0xac/0xc3
Aug 11 16:21:27 nike kernel: [<ffffffff8144cb93>] ret_from_intr+0x0/0x11
Aug 11 16:21:27 nike kernel: <EOI> [<ffffffff8127ef7b>] ?
acpi_idle_enter_bm+0x288/0x2bc
Aug 11 16:21:27 nike kernel: [<ffffffff8127ef74>] ?
acpi_idle_enter_bm+0x281/0x2bc
Aug 11 16:21:27 nike kernel: [<ffffffff81379458>] cpuidle_idle_call+0x99/0xf1
Aug 11 16:21:27 nike kernel: [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
Aug 11 16:21:27 nike kernel: [<ffffffff8144553e>] start_secondary+0x253/0x294
Aug 11 16:21:34 nike kernel: eth0: hw csum failure.
Aug 11 16:21:34 nike kernel: Pid: 0, comm: swapper Not tainted
2.6.34.3-35.rc1.fc13.x86_64 #1
Aug 11 16:21:34 nike kernel: Call Trace:
Aug 11 16:21:34 nike kernel: <IRQ> [<ffffffff813a5c5b>]
netdev_rx_csum_fault+0x3b/0x3f
Aug 11 16:21:34 nike kernel: [<ffffffff8139f909>]
__skb_checksum_complete_head+0x51/0x65
Aug 11 16:21:34 nike kernel: [<ffffffff8139f92e>] __skb_checksum_complete+0x11/0
...
etc, 700 messages over the course of the next hour (until I came back
and ip link down/up fixed it).
# cat /var/log/messages | egrep 'rx len'
Aug 11 16:21:19 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
status 0x5d60100 length 2982
(also seen on an older kernel [ 2.6.33.5-112.fc13.x86_64 ]:
Jul 17 12:43:10 nike kernel: sky2 eth0: rx length error: status
0x5ea0100 length 3018
Jul 28 02:34:46 nike kernel: sky2 eth0: rx length error: status
0x5ea0100 length 1642
Jul 30 09:49:16 nike kernel: sky2 eth0: rx length error: status
0x5ea0100 length 3018
Jul 31 00:20:26 nike kernel: sky2 eth0: rx length error: status
0x5ea0100 length 3018
and kernels before that, including 2.6.32.12-115.fc12.x86_64, but I
think I might have seen the problem even further back than 2.6.32).
# cat /var/log/messages | egrep 'eth0: hw csum failure\.$' | wc -l
694
The call stacks differ, here's the most common symbols with the number
of times they occur
(although this probably isn't particularly useful):
# cat /var/log/messages | egrep ffffffff | sed -rn 's@^^Aug ..
..:..:.. nike kernel: @@p' | sort | uniq -c | egrep -v '^ [
1-9][0-9] '
602 <EOI> [<ffffffff8127ef7b>] ? acpi_idle_enter_bm+0x288/0x2bc
630 [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
694 [<ffffffff8100ab5c>] call_softirq+0x1c/0x30
693 [<ffffffff8100c342>] do_softirq+0x46/0x83
273 [<ffffffff81010261>] ? sched_clock+0x9/0xd
105 [<ffffffff8101038f>] ? native_sched_clock+0x2d/0x5f
254 [<ffffffff810205a8>] ? lapic_next_event+0x1d/0x21
190 [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
285 [<ffffffff81037c67>] ? activate_task+0x2f/0x37
144 [<ffffffff8103ea37>] ? enqueue_task_fair+0x44/0x87
693 [<ffffffff810530b5>] irq_exit+0x3b/0x7d
694 [<ffffffff81053244>] __do_softirq+0xe5/0x1a6
103 [<ffffffff8106b281>] ? sched_clock_local+0x1c/0x82
693 [<ffffffff8106e106>] ? getnstimeofday+0x63/0xb9
202 [<ffffffff8107148d>] ? clockevents_program_event+0x7a/0x83
255 [<ffffffff810725e5>] ? tick_dev_program_event+0x3c/0xfc
703 [<ffffffff8109e119>] ? handle_IRQ_event+0x60/0x121
348 [<ffffffff810fe9af>] ? virt_to_head_page+0xe/0x2f
528 [<ffffffff81216662>] ? __bitmap_weight+0x40/0x8f
602 [<ffffffff8127ef74>] ? acpi_idle_enter_bm+0x281/0x2bc
629 [<ffffffff81379458>] cpuidle_idle_call+0x99/0xf1
115 [<ffffffff8139cffd>] ? __kfree_skb+0x7d/0x81
694 [<ffffffff8139f909>] __skb_checksum_complete_head+0x51/0x65
694 [<ffffffff8139f92e>] __skb_checksum_complete+0x11/0x13
694 [<ffffffff813a53de>] netif_receive_skb+0x493/0x4b9
694 [<ffffffff813a568f>] net_rx_action+0xaf/0x1ca
694 [<ffffffff813a5baa>] napi_skb_finish+0x29/0x40
694 [<ffffffff813a5bf0>] napi_gro_receive+0x2f/0x34
695 [<ffffffff813c4c56>] nf_iterate+0x46/0x89
695 [<ffffffff813c4d03>] nf_hook_slow+0x6a/0xcb
145 [<ffffffff813c4d20>] ? nf_hook_slow+0x87/0xcb
694 [<ffffffff813c7d69>] nf_conntrack_in+0x180/0x90e
690 [<ffffffff813cc791>] udp_error+0x130/0x18a
2083 [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
163 [<ffffffff813d4c58>] ? ip_local_deliver_finish+0x0/0x1b3
694 [<ffffffff813d4e51>] NF_HOOK.clone.1+0x46/0x58
694 [<ffffffff813d510b>] ip_rcv+0x256/0x283
694 [<ffffffff8140c339>] nf_ip_checksum+0xdd/0xe3
694 [<ffffffff8140c995>] ipv4_conntrack_in+0x21/0x23
338 [<ffffffff81434d5a>] rest_init+0x7e/0x80
295 [<ffffffff8144553e>] start_secondary+0x253/0x294
151 [<ffffffff8144c8a6>] ? _raw_spin_unlock_bh+0x15/0x17
687 [<ffffffff8144cb93>] ret_from_intr+0x0/0x11
687 [<ffffffff81452434>] do_IRQ+0xac/0xc3
338 [<ffffffff81bae2c8>] x86_64_start_reservations+0xb3/0xb7
338 [<ffffffff81bae3c4>] x86_64_start_kernel+0xf8/0x107
338 [<ffffffff81baee6f>] start_kernel+0x413/0x41e
694 [<ffffffffa0160381>] sky2_poll+0x9c5/0xc58 [sky2]
150 [<ffffffffa05850ea>] ? nf_nat_cleanup_conntrack+0x69/0x6d [nf_nat]
694 <IRQ> [<ffffffff813a5c5b>] netdev_rx_csum_fault+0x3b/0x3f
^ permalink raw reply
* RE: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Wang, Qi @ 2010-08-12 1:42 UTC (permalink / raw)
To: Daniel Baluta, Masayuki Ohtak
Cc: meego-dev@meego.com, Wolfgang Grandegger,
socketcan-core@lists.berlios.de, netdev@vger.kernel.org,
Khor, Andrew Chih Howe, gregkh@suse.de, arjan@linux.intel.com,
Wang, Yong Y
In-Reply-To: <AANLkTinZ510_k2E5JFxa8jcuv8gRABFakyrcfzsg2vm1@mail.gmail.com>
> -----Original Message-----
> From: Daniel Baluta [mailto:daniel.baluta@gmail.com]
> Sent: Wednesday, August 11, 2010 6:37 PM
> To: Masayuki Ohtak
> Cc: meego-dev@meego.com; Wolfgang Grandegger;
> socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor, Andrew Chih
> Howe; gregkh@suse.de; arjan@linux.intel.com; Wang, Qi; Wang, Yong Y
> Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
>
> Hi,
>
> 2010/8/11 Masayuki Ohtak <masa-korg@dsn.okisemi.com>:
> > CAN driver of Topcliff PCH
> >
> > Topcliff PCH is the platform controller hub that is going to be used in
> > Intel's upcoming general embedded platform. All IO peripherals in
> > Topcliff PCH are actually devices sitting on AMBA bus.
> > Topcliff PCH has CAN I/F. This driver enables CAN function.
> >
> > Signed-off-by: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
>
> I have a few questions:
>
> 1. Is your code based on Intel's CAN EP80579 ([1]) ?
No.
> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
Just take a look at kfifo.h. This structure has been changed. I remembered there was a spin_lock from kfifo previously. Currently it's been removed, good.
OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
Daniel,
We're anxious to integrate those codes now. Perhaps it'll take us quite a long time to use kfifo. How about implementing it with the next version?
Best Regards,
Qi.
> 3. Can you provide a pointer to Topcliff PCH CAN I/F datasheet ?
Currently this datasheet isn't open.
>
> thanks,
> Daniel.
>
> [1] http://www.intel.com/design/intarch/ep80579/sw_tools.htm
> [2] http://lxr.linux.no/#linux+v2.6.35/kernel/kfifo.c
^ permalink raw reply
* Re: sky2 driver fails to handle "rx length error: status 0x5d60100 length 2982" gracefully
From: Stephen Hemminger @ 2010-08-12 1:59 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: Stephen Hemminger, Linux NetDev
In-Reply-To: <AANLkTinMK7n51v4uBPYChYV7KOye8WEvdCFDanfd2mVL@mail.gmail.com>
On Wed, 11 Aug 2010 17:48:59 -0700
Maciej Żenczykowski <zenczykowski@gmail.com> wrote:
> [See https://bugzilla.redhat.com/show_bug.cgi?id=592398 ]
>
> Latest tested kernel (from koji for Fedora 13):
>
> 2.6.34.3-35.rc1.fc13.x86_64
>
> Basically occasionally, but possibly more and more often with recent
> kernels (I think .33 and .34 are worse then .32) the sky2 driver locks
> up.
>
> During this time the nic functions like a DSL line with a 95% drop
> rate. ie. sometimes something does get through, but mostly it's dead.
> "ip link set eth0 down && ip link set eth0 up" is enough to fix it.
>
> Here's the initial occurrence of this problem on the above kernel.
>
> Aug 11 16:21:19 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
> status 0x5d60100 length 2982
> Aug 11 16:21:27 nike kernel: eth0: hw csum failure.
> Aug 11 16:21:27 nike kernel: Pid: 0, comm: swapper Not tainted
> 2.6.34.3-35.rc1.fc13.x86_64 #1
> Aug 11 16:21:27 nike kernel: Call Trace:
> Aug 11 16:21:27 nike kernel: <IRQ> [<ffffffff813a5c5b>]
> netdev_rx_csum_fault+0x3b/0x3f
> Aug 11 16:21:27 nike kernel: [<ffffffff8139f909>]
> __skb_checksum_complete_head+0x51/0x65
> Aug 11 16:21:27 nike kernel: [<ffffffff8139f92e>]
> __skb_checksum_complete+0x11/0x13
> Aug 11 16:21:27 nike kernel: [<ffffffff8140c339>] nf_ip_checksum+0xdd/0xe3
> Aug 11 16:21:27 nike kernel: [<ffffffff813cc791>] udp_error+0x130/0x18a
> Aug 11 16:21:27 nike kernel: [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
> Aug 11 16:21:27 nike kernel: [<ffffffff81037c67>] ? activate_task+0x2f/0x37
> Aug 11 16:21:27 nike kernel: [<ffffffff813c7d69>] nf_conntrack_in+0x180/0x90e
> Aug 11 16:21:27 nike kernel: [<ffffffff8103ea37>] ? enqueue_task_fair+0x44/0x87
> Aug 11 16:21:27 nike kernel: [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
> Aug 11 16:21:27 nike kernel: [<ffffffff8140c995>] ipv4_conntrack_in+0x21/0x23
> Aug 11 16:21:27 nike kernel: [<ffffffff813c4c56>] nf_iterate+0x46/0x89
> Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
> Aug 11 16:21:27 nike kernel: [<ffffffff813c4d03>] nf_hook_slow+0x6a/0xcb
> Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
> Aug 11 16:21:27 nike kernel: [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
> Aug 11 16:21:27 nike kernel: [<ffffffff813d4e51>] NF_HOOK.clone.1+0x46/0x58
> Aug 11 16:21:27 nike kernel: [<ffffffff8106e106>] ? getnstimeofday+0x63/0xb9
> Aug 11 16:21:27 nike kernel: [<ffffffff813d510b>] ip_rcv+0x256/0x283
> Aug 11 16:21:27 nike kernel: [<ffffffff813a53de>] netif_receive_skb+0x493/0x4b9
> Aug 11 16:21:27 nike kernel: [<ffffffff813a5baa>] napi_skb_finish+0x29/0x40
> Aug 11 16:21:27 nike kernel: [<ffffffff813a5bf0>] napi_gro_receive+0x2f/0x34
> Aug 11 16:21:27 nike kernel: [<ffffffffa0160381>] sky2_poll+0x9c5/0xc58 [sky2]
> Aug 11 16:21:27 nike kernel: [<ffffffff813a568f>] net_rx_action+0xaf/0x1ca
> Aug 11 16:21:27 nike kernel: [<ffffffff81053244>] __do_softirq+0xe5/0x1a6
> Aug 11 16:21:27 nike kernel: [<ffffffff8109e119>] ? handle_IRQ_event+0x60/0x121
> Aug 11 16:21:27 nike kernel: [<ffffffff8100ab5c>] call_softirq+0x1c/0x30
> Aug 11 16:21:27 nike kernel: [<ffffffff8100c342>] do_softirq+0x46/0x83
> Aug 11 16:21:27 nike kernel: [<ffffffff810530b5>] irq_exit+0x3b/0x7d
> Aug 11 16:21:27 nike kernel: [<ffffffff81452434>] do_IRQ+0xac/0xc3
> Aug 11 16:21:27 nike kernel: [<ffffffff8144cb93>] ret_from_intr+0x0/0x11
> Aug 11 16:21:27 nike kernel: <EOI> [<ffffffff8127ef7b>] ?
> acpi_idle_enter_bm+0x288/0x2bc
> Aug 11 16:21:27 nike kernel: [<ffffffff8127ef74>] ?
> acpi_idle_enter_bm+0x281/0x2bc
> Aug 11 16:21:27 nike kernel: [<ffffffff81379458>] cpuidle_idle_call+0x99/0xf1
> Aug 11 16:21:27 nike kernel: [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
> Aug 11 16:21:27 nike kernel: [<ffffffff8144553e>] start_secondary+0x253/0x294
> Aug 11 16:21:34 nike kernel: eth0: hw csum failure.
> Aug 11 16:21:34 nike kernel: Pid: 0, comm: swapper Not tainted
> 2.6.34.3-35.rc1.fc13.x86_64 #1
> Aug 11 16:21:34 nike kernel: Call Trace:
> Aug 11 16:21:34 nike kernel: <IRQ> [<ffffffff813a5c5b>]
> netdev_rx_csum_fault+0x3b/0x3f
> Aug 11 16:21:34 nike kernel: [<ffffffff8139f909>]
> __skb_checksum_complete_head+0x51/0x65
> Aug 11 16:21:34 nike kernel: [<ffffffff8139f92e>] __skb_checksum_complete+0x11/0
> ...
> etc, 700 messages over the course of the next hour (until I came back
> and ip link down/up fixed it).
>
> # cat /var/log/messages | egrep 'rx len'
> Aug 11 16:21:19 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
> status 0x5d60100 length 2982
>
> (also seen on an older kernel [ 2.6.33.5-112.fc13.x86_64 ]:
> Jul 17 12:43:10 nike kernel: sky2 eth0: rx length error: status
> 0x5ea0100 length 3018
> Jul 28 02:34:46 nike kernel: sky2 eth0: rx length error: status
> 0x5ea0100 length 1642
> Jul 30 09:49:16 nike kernel: sky2 eth0: rx length error: status
> 0x5ea0100 length 3018
> Jul 31 00:20:26 nike kernel: sky2 eth0: rx length error: status
> 0x5ea0100 length 3018
> and kernels before that, including 2.6.32.12-115.fc12.x86_64, but I
> think I might have seen the problem even further back than 2.6.32).
>
> # cat /var/log/messages | egrep 'eth0: hw csum failure\.$' | wc -l
> 694
>
> The call stacks differ, here's the most common symbols with the number
> of times they occur
> (although this probably isn't particularly useful):
>
> # cat /var/log/messages | egrep ffffffff | sed -rn 's@^^Aug ..
> ..:..:.. nike kernel: @@p' | sort | uniq -c | egrep -v '^ [
> 1-9][0-9] '
> 602 <EOI> [<ffffffff8127ef7b>] ? acpi_idle_enter_bm+0x288/0x2bc
> 630 [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
> 694 [<ffffffff8100ab5c>] call_softirq+0x1c/0x30
> 693 [<ffffffff8100c342>] do_softirq+0x46/0x83
> 273 [<ffffffff81010261>] ? sched_clock+0x9/0xd
> 105 [<ffffffff8101038f>] ? native_sched_clock+0x2d/0x5f
> 254 [<ffffffff810205a8>] ? lapic_next_event+0x1d/0x21
> 190 [<ffffffff81037b51>] ? enqueue_task+0x5f/0x6a
> 285 [<ffffffff81037c67>] ? activate_task+0x2f/0x37
> 144 [<ffffffff8103ea37>] ? enqueue_task_fair+0x44/0x87
> 693 [<ffffffff810530b5>] irq_exit+0x3b/0x7d
> 694 [<ffffffff81053244>] __do_softirq+0xe5/0x1a6
> 103 [<ffffffff8106b281>] ? sched_clock_local+0x1c/0x82
> 693 [<ffffffff8106e106>] ? getnstimeofday+0x63/0xb9
> 202 [<ffffffff8107148d>] ? clockevents_program_event+0x7a/0x83
> 255 [<ffffffff810725e5>] ? tick_dev_program_event+0x3c/0xfc
> 703 [<ffffffff8109e119>] ? handle_IRQ_event+0x60/0x121
> 348 [<ffffffff810fe9af>] ? virt_to_head_page+0xe/0x2f
> 528 [<ffffffff81216662>] ? __bitmap_weight+0x40/0x8f
> 602 [<ffffffff8127ef74>] ? acpi_idle_enter_bm+0x281/0x2bc
> 629 [<ffffffff81379458>] cpuidle_idle_call+0x99/0xf1
> 115 [<ffffffff8139cffd>] ? __kfree_skb+0x7d/0x81
> 694 [<ffffffff8139f909>] __skb_checksum_complete_head+0x51/0x65
> 694 [<ffffffff8139f92e>] __skb_checksum_complete+0x11/0x13
> 694 [<ffffffff813a53de>] netif_receive_skb+0x493/0x4b9
> 694 [<ffffffff813a568f>] net_rx_action+0xaf/0x1ca
> 694 [<ffffffff813a5baa>] napi_skb_finish+0x29/0x40
> 694 [<ffffffff813a5bf0>] napi_gro_receive+0x2f/0x34
> 695 [<ffffffff813c4c56>] nf_iterate+0x46/0x89
> 695 [<ffffffff813c4d03>] nf_hook_slow+0x6a/0xcb
> 145 [<ffffffff813c4d20>] ? nf_hook_slow+0x87/0xcb
> 694 [<ffffffff813c7d69>] nf_conntrack_in+0x180/0x90e
> 690 [<ffffffff813cc791>] udp_error+0x130/0x18a
> 2083 [<ffffffff813d4790>] ? ip_rcv_finish+0x0/0x362
> 163 [<ffffffff813d4c58>] ? ip_local_deliver_finish+0x0/0x1b3
> 694 [<ffffffff813d4e51>] NF_HOOK.clone.1+0x46/0x58
> 694 [<ffffffff813d510b>] ip_rcv+0x256/0x283
> 694 [<ffffffff8140c339>] nf_ip_checksum+0xdd/0xe3
> 694 [<ffffffff8140c995>] ipv4_conntrack_in+0x21/0x23
> 338 [<ffffffff81434d5a>] rest_init+0x7e/0x80
> 295 [<ffffffff8144553e>] start_secondary+0x253/0x294
> 151 [<ffffffff8144c8a6>] ? _raw_spin_unlock_bh+0x15/0x17
> 687 [<ffffffff8144cb93>] ret_from_intr+0x0/0x11
> 687 [<ffffffff81452434>] do_IRQ+0xac/0xc3
> 338 [<ffffffff81bae2c8>] x86_64_start_reservations+0xb3/0xb7
> 338 [<ffffffff81bae3c4>] x86_64_start_kernel+0xf8/0x107
> 338 [<ffffffff81baee6f>] start_kernel+0x413/0x41e
> 694 [<ffffffffa0160381>] sky2_poll+0x9c5/0xc58 [sky2]
> 150 [<ffffffffa05850ea>] ? nf_nat_cleanup_conntrack+0x69/0x6d [nf_nat]
> 694 <IRQ> [<ffffffff813a5c5b>] netdev_rx_csum_fault+0x3b/0x3f
What is the dmesg and lspci info. Looks like a timing issue which
is unique to your machine/bus hardware combination. could
you just turn off hardware rx checksum (with ethtool).
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Greg KH @ 2010-08-12 2:04 UTC (permalink / raw)
To: Wang, Qi
Cc: Daniel Baluta, Masayuki Ohtak, meego-dev@meego.com,
Wolfgang Grandegger, socketcan-core@lists.berlios.de,
netdev@vger.kernel.org, Khor, Andrew Chih Howe,
arjan@linux.intel.com, Wang, Yong Y
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A28EA26EB@shsmsx501.ccr.corp.intel.com>
On Thu, Aug 12, 2010 at 09:42:27AM +0800, Wang, Qi wrote:
> > -----Original Message-----
> > From: Daniel Baluta [mailto:daniel.baluta@gmail.com]
> > Sent: Wednesday, August 11, 2010 6:37 PM
> > To: Masayuki Ohtak
> > Cc: meego-dev@meego.com; Wolfgang Grandegger;
> > socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor, Andrew Chih
> > Howe; gregkh@suse.de; arjan@linux.intel.com; Wang, Qi; Wang, Yong Y
> > Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> >
> > Hi,
> >
> > 2010/8/11 Masayuki Ohtak <masa-korg@dsn.okisemi.com>:
> > > CAN driver of Topcliff PCH
> > >
> > > Topcliff PCH is the platform controller hub that is going to be used in
> > > Intel's upcoming general embedded platform. All IO peripherals in
> > > Topcliff PCH are actually devices sitting on AMBA bus.
> > > Topcliff PCH has CAN I/F. This driver enables CAN function.
> > >
> > > Signed-off-by: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
> >
> > I have a few questions:
> >
> > 1. Is your code based on Intel's CAN EP80579 ([1]) ?
> No.
> > 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> Just take a look at kfifo.h. This structure has been changed. I
> remembered there was a spin_lock from kfifo previously. Currently it's
> been removed, good.
> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
>
> Daniel,
>
> We're anxious to integrate those codes now. Perhaps it'll take us
> quite a long time to use kfifo. How about implementing it with the
> next version?
What do you mean by this? Code isn't merged into the tree unless it is
correct. Please fix this now, it's not that big of a deal.
> > 3. Can you provide a pointer to Topcliff PCH CAN I/F datasheet ?
> Currently this datasheet isn't open.
Even under NDA? The Linux foundation offers a service to allow
developers access to data sheets so that they can do kernel development
and code review.
thanks,
greg k-h
^ permalink raw reply
* RE: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Wang, Qi @ 2010-08-12 2:13 UTC (permalink / raw)
To: Khor, Andrew Chih Howe, Masayuki Ohtak
Cc: Daniel Baluta, meego-dev@meego.com, Wolfgang Grandegger,
socketcan-core@lists.berlios.de, netdev@vger.kernel.org,
arjan@linux.intel.com, Wang, Yong Y, Greg KH
In-Reply-To: <20100812020414.GD14121@suse.de>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Thursday, August 12, 2010 10:04 AM
> To: Wang, Qi
> Cc: Daniel Baluta; Masayuki Ohtak; meego-dev@meego.com; Wolfgang
> Grandegger; socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor,
> Andrew Chih Howe; arjan@linux.intel.com; Wang, Yong Y
> Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
>
> On Thu, Aug 12, 2010 at 09:42:27AM +0800, Wang, Qi wrote:
> > > -----Original Message-----
> > > From: Daniel Baluta [mailto:daniel.baluta@gmail.com]
> > > Sent: Wednesday, August 11, 2010 6:37 PM
> > > To: Masayuki Ohtak
> > > Cc: meego-dev@meego.com; Wolfgang Grandegger;
> > > socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor, Andrew
> Chih
> > > Howe; gregkh@suse.de; arjan@linux.intel.com; Wang, Qi; Wang, Yong Y
> > > Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to
> 2.6.35
> > >
> > > Hi,
> > >
> > > 2010/8/11 Masayuki Ohtak <masa-korg@dsn.okisemi.com>:
> > > > CAN driver of Topcliff PCH
> > > >
> > > > Topcliff PCH is the platform controller hub that is going to be used in
> > > > Intel's upcoming general embedded platform. All IO peripherals in
> > > > Topcliff PCH are actually devices sitting on AMBA bus.
> > > > Topcliff PCH has CAN I/F. This driver enables CAN function.
> > > >
> > > > Signed-off-by: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
> > >
> > > I have a few questions:
> > >
> > > 1. Is your code based on Intel's CAN EP80579 ([1]) ?
> > No.
> > > 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> > Just take a look at kfifo.h. This structure has been changed. I
> > remembered there was a spin_lock from kfifo previously. Currently it's
> > been removed, good.
> > OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to
> use this structure and APIs?
> >
> > Daniel,
> >
> > We're anxious to integrate those codes now. Perhaps it'll take us
> > quite a long time to use kfifo. How about implementing it with the
> > next version?
>
> What do you mean by this? Code isn't merged into the tree unless it is
> correct. Please fix this now, it's not that big of a deal.
Hi Ohtak-san,
Would you please use kfifo structure? It'll take you some time to study it, but it's a good structure.
>
> > > 3. Can you provide a pointer to Topcliff PCH CAN I/F datasheet ?
> > Currently this datasheet isn't open.
>
> Even under NDA? The Linux foundation offers a service to allow
> developers access to data sheets so that they can do kernel development
> and code review.
Hi Andrew,
Can ECG share those datasheet to the open source? Only with that datasheet, the upstream can review the source codes from OKI.
Best Regards,
Qi
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Masayuki Ohtake @ 2010-08-12 2:39 UTC (permalink / raw)
To: Daniel Baluta, Wang, Qi
Cc: Wang, Yong Y, arjan, gregkh, Khor, Andrew Chih Howe, netdev,
socketcan-core, Wolfgang Grandegger, meego-dev
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A28EA26EB@shsmsx501.ccr.corp.intel.com>
Hi Qi-san
> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
Thank you for your answer.
We will start doing the above next week.
Thanks, Ohtake
----- Original Message -----
From: "Wang, Qi" <qi.wang@intel.com>
To: "Daniel Baluta" <daniel.baluta@gmail.com>; "Masayuki Ohtak" <masa-korg@dsn.okisemi.com>
Cc: <meego-dev@meego.com>; "Wolfgang Grandegger" <wg@grandegger.com>; <socketcan-core@lists.berlios.de>;
<netdev@vger.kernel.org>; "Khor, Andrew Chih Howe" <andrew.chih.howe.khor@intel.com>; <gregkh@suse.de>;
<arjan@linux.intel.com>; "Wang, Yong Y" <yong.y.wang@intel.com>
Sent: Thursday, August 12, 2010 10:42 AM
Subject: RE: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> > -----Original Message-----
> > From: Daniel Baluta [mailto:daniel.baluta@gmail.com]
> > Sent: Wednesday, August 11, 2010 6:37 PM
> > To: Masayuki Ohtak
> > Cc: meego-dev@meego.com; Wolfgang Grandegger;
> > socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor, Andrew Chih
> > Howe; gregkh@suse.de; arjan@linux.intel.com; Wang, Qi; Wang, Yong Y
> > Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> >
> > Hi,
> >
> > 2010/8/11 Masayuki Ohtak <masa-korg@dsn.okisemi.com>:
> > > CAN driver of Topcliff PCH
> > >
> > > Topcliff PCH is the platform controller hub that is going to be used in
> > > Intel's upcoming general embedded platform. All IO peripherals in
> > > Topcliff PCH are actually devices sitting on AMBA bus.
> > > Topcliff PCH has CAN I/F. This driver enables CAN function.
> > >
> > > Signed-off-by: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
> >
> > I have a few questions:
> >
> > 1. Is your code based on Intel's CAN EP80579 ([1]) ?
> No.
> > 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> Just take a look at kfifo.h. This structure has been changed. I remembered there was a spin_lock from kfifo
previously. Currently it's been removed, good.
> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
>
> Daniel,
>
> We're anxious to integrate those codes now. Perhaps it'll take us quite a long time to use kfifo. How about
implementing it with the next version?
>
> Best Regards,
> Qi.
>
> > 3. Can you provide a pointer to Topcliff PCH CAN I/F datasheet ?
> Currently this datasheet isn't open.
> >
> > thanks,
> > Daniel.
> >
> > [1] http://www.intel.com/design/intarch/ep80579/sw_tools.htm
> > [2] http://lxr.linux.no/#linux+v2.6.35/kernel/kfifo.c
>
^ permalink raw reply
* RE: [PATCH NEXT 0/8]qlcnic: enhancement and fixes
From: Amit Salecha @ 2010-08-12 3:41 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org, Ameen Rahman
In-Reply-To: <1281528329-8812-1-git-send-email-amit.salecha@qlogic.com>
>> Series of 8 patches to fix minor bugs and to add statistics support.
Don't apply these patches, I will send you updated one.
-----Original Message-----
From: Amit Kumar Salecha [mailto:amit.salecha@qlogic.com]
Sent: Wednesday, August 11, 2010 5:35 PM
To: davem@davemloft.net
Cc: netdev@vger.kernel.org; Ameen Rahman
Subject: [PATCH NEXT 0/8]qlcnic: enhancement and fixes
Hi
Series of 8 patches to fix minor bugs and to add statistics
support. Please apply them on net-next branch.
-Amit
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Daniel Baluta @ 2010-08-12 5:17 UTC (permalink / raw)
To: Wang, Qi
Cc: Khor, Andrew Chih Howe,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
gregkh-l3A5Bk7waGM@public.gmane.org, Wang, Yong Y, Masayuki Ohtak,
meego-dev-WXzIur8shnEAvxtiuMwx3w@public.gmane.org,
arjan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
Wolfgang Grandegger
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A28EA26EB-QQHDSDV1ERZpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
>> 1. Is your code based on Intel's CAN EP80579 ([1]) ?
> No.
I want in the near future to write a Socket-CAN based driver for CAN EP80579.
As far as I've seen from your implementation there are a lot of
similarities between these
two drivers. Perhaps we can built a core part to both benefit from it.
>> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> Just take a look at kfifo.h. This structure has been changed. I remembered there was a spin_lock from kfifo previously. Currently it's been removed, good.
Inded, the kfifo infrastructure has suffered great reworkings in the
latest kernel versions, but this
is not an excuse to not use it.
> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to use this structure and APIs?
>
> Daniel,
>
> We're anxious to integrate those codes now. Perhaps it'll take us quite a long time to use kfifo. How about implementing it with the next version?
In my opinion, as it looks now your code will never be accepted by the
SocketCAN maintainers.
thanks,
Daniel.
^ permalink raw reply
* Re: [PATCH NEXT 0/8]qlcnic: enhancement and fixes
From: David Miller @ 2010-08-12 5:23 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80F86E68D08@MNEXMB2.qlogic.org>
From: Amit Salecha <amit.salecha@qlogic.com>
Date: Wed, 11 Aug 2010 22:41:39 -0500
>>> Series of 8 patches to fix minor bugs and to add statistics support.
>
> Don't apply these patches, I will send you updated one.
Ok.
^ permalink raw reply
* Re: sky2 driver fails to handle "rx length error: status 0x5d60100 length 2982" gracefully
From: Maciej Żenczykowski @ 2010-08-12 5:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Hemminger, Linux NetDev
In-Reply-To: <20100811215932.26414efe@s6510>
Here's lspci (it's an otherwise stock MacBook Pro 4,1 with a
non-standard wireless atheros mini-pci nic, replacing the std
broadcom.)
$ lspci
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory
Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI
Express Root Port (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 1 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 3 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 5 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB
UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface
Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E)
SATA IDE Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation G84 [GeForce
8600M GT] (rev a1)
0b:00.0 Network controller: Atheros Communications Inc. AR928X
Wireless Network Adapter (PCI-Express) (rev 01)
0c:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8058
PCI-E Gigabit Ethernet Controller (rev 13)
0d:03.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b
Link Layer Controller (rev 02)
(more verbose lspci included in bugzilla entry)
At least one other person has seen this on a desktop non-mac machine
(see bugzilla) entry.
What would you like from dmesg?
Is the following enough?
Aug 9 12:09:11 nike kernel: sky2: driver version 1.27
Aug 9 12:09:11 nike kernel: sky2 0000:0c:00.0: PCI INT A -> GSI 17
(level, low) -> IRQ 17
Aug 9 12:09:11 nike kernel: sky2 0000:0c:00.0: Yukon-2 EC Ultra chip revision 3
Aug 9 12:09:11 nike kernel: sky2 0000:0c:00.0: eth0: addr 00:1f:5b:xx:xx:xx
...
Aug 9 12:09:22 nike kernel: sky2 0000:0c:00.0: eth0: enabling interface
Aug 9 12:09:22 nike kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
...
Aug 9 12:09:25 nike kernel: sky2 0000:0c:00.0: eth0: Link is up at
1000 Mbps, full duplex, flow control rx
Aug 9 12:09:25 nike kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
...
Aug 11 16:21:19 nike kernel: sky2 0000:0c:00.0: eth0: rx length error:
status 0x5d60100 length 2982
Aug 11 16:21:27 nike kernel: eth0: hw csum failure.
...
I'd just like to point out that this has happened something like 5
times in the past 30 days on a machine which is on 24/7 with wired
ethernet plugged in nearly 100% of the time.
^ permalink raw reply
* Re: [PATCH -next] phylib: available for any speed ethernet
From: David Miller @ 2010-08-12 6:04 UTC (permalink / raw)
To: randy.dunlap; +Cc: netdev
In-Reply-To: <20100811162657.cfb767a7.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Wed, 11 Aug 2010 16:26:57 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Several gigabit network drivers (SB1250_MAC, TIGON3, FSL, GIANFAR,
> UCC_GETH, MV643XX_ETH, XILINX_LL_TEMAC, S6GMAC, STMMAC_ETH, PASEMI_MAC,
> and OCTEON_ETHERNET) select PHYLIB. These drivers are not under
> NET_ETHERNET (10/100 mbit), so this warning is generated (long, irrelevant
> parts are omitted):
>
> warning: (NET_DSA && NET && EXPERIMENTAL && NET_ETHERNET && !S390 || ... || SB1250_MAC && NETDEVICES && NETDEV_1000 && SIBYTE_SB1xxx_SOC || TIGON3 && NETDEVICES && NETDEV_1000 && PCI || FSL_PQ_MDIO && NETDEVICES && NETDEV_1000 && FSL_SOC || GIANFAR && NETDEVICES && NETDEV_1000 && FSL_SOC || UCC_GETH && NETDEVICES && NETDEV_1000 && QUICC_ENGINE || MV643XX_ETH && NETDEVICES && NETDEV_1000 && (MV64X60 || PPC32 || PLAT_ORION) || XILINX_LL_TEMAC && NETDEVICES && NETDEV_1000 && (PPC || MICROBLAZE) || S6GMAC && NETDEVICES && NETDEV_1000 && XTENSA_VARIANT_S6000 || STMMAC_ETH && NETDEV_1000 && NETDEVICES && CPU_SUBTYPE_ST40 || PASEMI_MAC && NETDEVICES && NETDEV_10000 && PPC_PASEMI && PCI || OCTEON_ETHERNET && STAGING && !STAGING_EXCLUDE_BUILD && CPU_CAVIUM_OCTEON) selects PHYLIB which has unmet d
irect dependencies (!S390 && NET_ETHERNET)
>
> PHYLIB is used by non-10/100 mbit ethernet drivers, so change the dependencies
> to be NETDEVICES instead of NET_ETHERNET.
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Fair enough, applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH] netpoll: use non-BH variant of RCU
From: David Miller @ 2010-08-12 6:09 UTC (permalink / raw)
To: paulmck; +Cc: herbert, linville, netdev
In-Reply-To: <20100811220047.GH2516@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date: Wed, 11 Aug 2010 15:00:47 -0700
> @@ -113,6 +113,12 @@ int rcu_my_thread_group_empty(void)
> return thread_group_empty(current);
> }
> EXPORT_SYMBOL_GPL(rcu_my_thread_group_empty);
> +
> +void rcu_read_unlock_bh_irqsoff_check(void)
> +{
> + WARN_ON_ONCE(in_irq() || irqs_disabled());
> +}
> +EXPORT_SYMBOL_GPL(rcu_read_unlock_bh_irqsoff_check);
> #endif /* #ifdef CONFIG_PROVE_RCU */
Is this WARN_ON_ONCE() test inverted? It seems to be called where we
"should be" in an IRQ or have IRQs disabled.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox