* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Sridhar Samudrala @ 2010-07-02 18:01 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Tejun Heo, Oleg Nesterov, Michael S. Tsirkin, Ingo Molnar, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <1277996135.1917.198.camel@laptop>
On 7/1/2010 7:55 AM, Peter Zijlstra wrote:
> On Thu, 2010-07-01 at 16:53 +0200, Tejun Heo wrote:
>
>> Hello,
>>
>> On 07/01/2010 04:46 PM, Oleg Nesterov wrote:
>>
>>>> It might be a good idea to make the function take extra clone flags
>>>> but anyways once created cloned task can be treated the same way as
>>>> other kthreads, so nothing else needs to be changed.
>>>>
>>> This makes kthread_stop() work. Otherwise the new thread is just
>>> the CLONE_VM child of the caller, and the caller is the user-mode
>>> task doing ioctl() ?
>>>
>> Hmmm, indeed. It makes the attribute inheritance work but circumvents
>> the whole reason there is kthreadd.
>>
> I thought the whole reason there was threadd was to avoid the
> inheritance? So avoiding the avoiding of inheritance seems like the goal
> here, no?
>
I think so. Does it (Tejun's kthread_clone() patch) also inherit the
cgroup of the caller? or do we still need the explicit
call to attach the thread to the current task's cgroup?
I am on vacation next week and cannot look into this until Jul 12. Hope
this will be resoved by then.
If not, i will look into after i am back.
Thanks
Sridhar
^ permalink raw reply
* [PATCH 5/6] atm/suni.c: call atm_dev_signal_change() when signal changes.
From: Karl Hiramoto @ 2010-07-02 17:47 UTC (permalink / raw)
To: linux-atm-general, netdev, chas; +Cc: nathan, Karl Hiramoto
In-Reply-To: <1278092830-10473-1-git-send-email-karl@hiramoto.org>
Propagate changes to upper atm layer.
Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
---
drivers/atm/suni.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/suni.c b/drivers/atm/suni.c
index da4b91f..41c56ea 100644
--- a/drivers/atm/suni.c
+++ b/drivers/atm/suni.c
@@ -291,8 +291,9 @@ static int suni_ioctl(struct atm_dev *dev,unsigned int cmd,void __user *arg)
static void poll_los(struct atm_dev *dev)
{
- dev->signal = GET(RSOP_SIS) & SUNI_RSOP_SIS_LOSV ? ATM_PHY_SIG_LOST :
- ATM_PHY_SIG_FOUND;
+ atm_dev_signal_change(dev,
+ GET(RSOP_SIS) & SUNI_RSOP_SIS_LOSV ?
+ ATM_PHY_SIG_LOST : ATM_PHY_SIG_FOUND);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 6/6] atm/adummy: add syfs DEVICE_ATTR to change signal
From: Karl Hiramoto @ 2010-07-02 17:47 UTC (permalink / raw)
To: linux-atm-general, netdev, chas; +Cc: nathan, Karl Hiramoto
In-Reply-To: <1278092830-10473-1-git-send-email-karl@hiramoto.org>
Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
---
drivers/atm/adummy.c | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/atm/adummy.c b/drivers/atm/adummy.c
index 6d44f07..46b9476 100644
--- a/drivers/atm/adummy.c
+++ b/drivers/atm/adummy.c
@@ -40,6 +40,42 @@ struct adummy_dev {
static LIST_HEAD(adummy_devs);
+static ssize_t __set_signal(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct atm_dev *atm_dev = container_of(dev, struct atm_dev, class_dev);
+ int signal;
+
+ if (sscanf(buf, "%d", &signal) == 1) {
+
+ if (signal < ATM_PHY_SIG_LOST || signal > ATM_PHY_SIG_FOUND)
+ signal = ATM_PHY_SIG_UNKNOWN;
+
+ atm_dev_signal_change(atm_dev, signal);
+ return 1;
+ }
+ return -EINVAL;
+}
+
+static ssize_t __show_signal(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct atm_dev *atm_dev = container_of(dev, struct atm_dev, class_dev);
+ return sprintf(buf, "%d\n", atm_dev->signal);
+}
+static DEVICE_ATTR(signal, 0644, __show_signal, __set_signal);
+
+static struct attribute *adummy_attrs[] = {
+ &dev_attr_signal.attr,
+ NULL
+};
+
+static struct attribute_group adummy_group_attrs = {
+ .name = NULL, /* We want them in dev's root folder */
+ .attrs = adummy_attrs
+};
+
static int __init
adummy_start(struct atm_dev *dev)
{
@@ -128,6 +164,9 @@ static int __init adummy_init(void)
adummy_dev->atm_dev = atm_dev;
atm_dev->dev_data = adummy_dev;
+ if (sysfs_create_group(&atm_dev->class_dev.kobj, &adummy_group_attrs))
+ dev_err(&atm_dev->class_dev, "Could not register attrs for adummy\n");
+
if (adummy_start(atm_dev)) {
printk(KERN_ERR DEV_LABEL ": adummy_start() failed\n");
err = -ENODEV;
--
1.7.1
^ permalink raw reply related
* [PATCH 1/6] atm: add hooks to propagate signal changes to netdevice
From: Karl Hiramoto @ 2010-07-02 17:47 UTC (permalink / raw)
To: linux-atm-general, netdev, chas; +Cc: nathan, Karl Hiramoto
In-Reply-To: <1278092830-10473-1-git-send-email-karl@hiramoto.org>
On DSL and ATM devices it's usefull to have a know if you have a carrier signal.
netdevice LOWER_UP changes can be propagated to userspace via netlink monitor.
Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
---
include/linux/atmdev.h | 5 +++++
net/atm/common.c | 33 +++++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/include/linux/atmdev.h b/include/linux/atmdev.h
index 817b237..c6958ec 100644
--- a/include/linux/atmdev.h
+++ b/include/linux/atmdev.h
@@ -311,6 +311,7 @@ struct atm_vcc {
void (*pop)(struct atm_vcc *vcc,struct sk_buff *skb); /* optional */
int (*push_oam)(struct atm_vcc *vcc,void *cell);
int (*send)(struct atm_vcc *vcc,struct sk_buff *skb);
+ void (*signal_change)(struct atm_vcc *vcc); /* optional. to propagate LOWER_UP */
void *dev_data; /* per-device data */
void *proto_data; /* per-protocol data */
struct k_atm_aal_stats *stats; /* pointer to AAL stats group */
@@ -431,6 +432,10 @@ struct atm_dev *atm_dev_register(const char *type,const struct atmdev_ops *ops,
int number,unsigned long *flags); /* number == -1: pick first available */
struct atm_dev *atm_dev_lookup(int number);
void atm_dev_deregister(struct atm_dev *dev);
+/**
+* Propagate lower layer signal change in atm_dev->signal to netdevice.
+*/
+void atm_dev_signal_change(struct atm_dev *dev, char signal);
void vcc_insert_socket(struct sock *sk);
diff --git a/net/atm/common.c b/net/atm/common.c
index b43feb1..ccf09f2 100644
--- a/net/atm/common.c
+++ b/net/atm/common.c
@@ -212,6 +212,39 @@ void vcc_release_async(struct atm_vcc *vcc, int reply)
}
EXPORT_SYMBOL(vcc_release_async);
+void atm_dev_signal_change(struct atm_dev *dev, char signal)
+{
+ int i;
+ pr_debug("%s signal=%d dev=%p number=%d dev->signal=%d\n",
+ __func__, signal, dev, dev->number, dev->signal);
+
+ if (dev->signal == signal)
+ return; /* no change */
+
+ dev->signal = signal;
+
+ read_lock_irq(&vcc_sklist_lock);
+ for (i = 0; i < VCC_HTABLE_SIZE; i++) {
+ struct hlist_head *head = &vcc_hash[i];
+ struct hlist_node *node, *tmp;
+ struct sock *s;
+ struct atm_vcc *vcc;
+ sk_for_each_safe(s, node, tmp, head) {
+ vcc = atm_sk(s);
+ pr_debug("%s signal=%d vcc=%p dev=%p vcc->dev=%p %d.%d itf=%d meta=%d\n",
+ __func__, signal, vcc, dev, vcc->dev,
+ vcc->vpi, vcc->vci, vcc->itf, test_bit(ATM_VF_META, &vcc->flags));
+ /* if there is a signal change callback and dev matches,
+ or if this is a meta dev (clip atm_dev is arpd) */
+ if (vcc->signal_change && (vcc->dev == dev
+ || test_bit(ATM_VF_META, &vcc->flags))) {
+ vcc->signal_change(vcc);
+ }
+ }
+ }
+ read_unlock_irq(&vcc_sklist_lock);
+}
+EXPORT_SYMBOL(atm_dev_signal_change);
void atm_dev_release_vccs(struct atm_dev *dev)
{
--
1.7.1
^ permalink raw reply related
* [PATCH 4/6] atm/solos-pci: call atm_dev_signal_change() when signal changes.
From: Karl Hiramoto @ 2010-07-02 17:47 UTC (permalink / raw)
To: linux-atm-general, netdev, chas; +Cc: nathan, Karl Hiramoto
In-Reply-To: <1278092830-10473-1-git-send-email-karl@hiramoto.org>
Propagate changes to upper atm layer, so userspace netmontor knows when DSL showtime reached.
Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
---
drivers/atm/solos-pci.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index ded76c4..6174965 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -383,7 +383,7 @@ static int process_status(struct solos_card *card, int port, struct sk_buff *skb
/* Anything but 'Showtime' is down */
if (strcmp(state_str, "Showtime")) {
- card->atmdev[port]->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
release_vccs(card->atmdev[port]);
dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
return 0;
@@ -401,7 +401,7 @@ static int process_status(struct solos_card *card, int port, struct sk_buff *skb
snr[0]?", SNR ":"", snr, attn[0]?", Attn ":"", attn);
card->atmdev[port]->link_rate = rate_down / 424;
- card->atmdev[port]->signal = ATM_PHY_SIG_FOUND;
+ atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_FOUND);
return 0;
}
@@ -1246,7 +1246,7 @@ static int atm_init(struct solos_card *card)
card->atmdev[i]->ci_range.vci_bits = 16;
card->atmdev[i]->dev_data = card;
card->atmdev[i]->phy_data = (void *)(unsigned long)i;
- card->atmdev[i]->signal = ATM_PHY_SIG_UNKNOWN;
+ atm_dev_signal_change(card->atmdev[i], ATM_PHY_SIG_UNKNOWN);
skb = alloc_skb(sizeof(*header), GFP_ATOMIC);
if (!skb) {
--
1.7.1
^ permalink raw reply related
* [PATCH 0/6] atm: propagate atm_dev signal carrier to LOWER_UP of netdevice
From: Karl Hiramoto @ 2010-07-02 17:47 UTC (permalink / raw)
To: linux-atm-general, netdev, chas; +Cc: nathan, Karl Hiramoto
In userspace it's helpfull to know if a network device has a carrier signal.
Often it is monitored via netlink. This patchset allows a way for the
struct atm_dev drivers to pass carrier on/off to the netdevice.
For DSL, carrier is on when the line has reached showtime state.
Currently this patchset only propagates the changes to br2684 vccs,
as this is the only type of hardware I have to test.
If you prefer git you can pull from:
git://github.com/karlhiramoto/linux-2.6.git linux-atm
Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
Karl Hiramoto (6):
atm: add hooks to propagate signal changes to netdevice
atm br2684: add callback for carrier signal changes.
atm/idt77105.c: call atm_dev_signal_change() when signal changes.
atm/solos-pci: call atm_dev_signal_change() when signal changes.
atm/suni.c: call atm_dev_signal_change() when signal changes.
atm/adummy: add syfs DEVICE_ATTR to change signal
drivers/atm/adummy.c | 39 +++++++++++++++++++++++++++++++++++++++
drivers/atm/idt77105.c | 11 ++++++-----
drivers/atm/solos-pci.c | 6 +++---
drivers/atm/suni.c | 5 +++--
include/linux/atmdev.h | 5 +++++
net/atm/br2684.c | 13 +++++++++++++
net/atm/common.c | 33 +++++++++++++++++++++++++++++++++
7 files changed, 102 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 2/6] atm br2684: add callback for carrier signal changes.
From: Karl Hiramoto @ 2010-07-02 17:47 UTC (permalink / raw)
To: linux-atm-general, netdev, chas; +Cc: nathan, Karl Hiramoto
In-Reply-To: <1278092830-10473-1-git-send-email-karl@hiramoto.org>
When a signal change event occurs call netif_carrier_on/off.
Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
---
net/atm/br2684.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 6719af6..e0136ec 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -448,6 +448,17 @@ free_skb:
dev_kfree_skb(skb);
}
+static void br2684_signal_change(struct atm_vcc *atmvcc)
+{
+ struct br2684_vcc *brvcc = BR2684_VCC(atmvcc);
+ struct net_device *net_dev = brvcc->device;
+
+ if (atmvcc->dev->signal == ATM_PHY_SIG_LOST)
+ netif_carrier_off(net_dev);
+ else
+ netif_carrier_on(net_dev);
+}
+
/*
* Assign a vcc to a dev
* Note: we do not have explicit unassign, but look at _push()
@@ -514,6 +525,7 @@ static int br2684_regvcc(struct atm_vcc *atmvcc, void __user * arg)
barrier();
atmvcc->push = br2684_push;
atmvcc->pop = br2684_pop;
+ atmvcc->signal_change = br2684_signal_change;
__skb_queue_head_init(&queue);
rq = &sk_atm(atmvcc)->sk_receive_queue;
@@ -530,6 +542,7 @@ static int br2684_regvcc(struct atm_vcc *atmvcc, void __user * arg)
br2684_push(atmvcc, skb);
}
+ br2684_signal_change(atmvcc); /* initialize netdev carrier state */
__module_get(THIS_MODULE);
return 0;
--
1.7.1
^ permalink raw reply related
* [PATCH 3/6] atm/idt77105.c: call atm_dev_signal_change() when signal changes.
From: Karl Hiramoto @ 2010-07-02 17:47 UTC (permalink / raw)
To: linux-atm-general, netdev, chas; +Cc: nathan, Karl Hiramoto
In-Reply-To: <1278092830-10473-1-git-send-email-karl@hiramoto.org>
Propagate changes to upper atm layer.
Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
---
drivers/atm/idt77105.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/atm/idt77105.c b/drivers/atm/idt77105.c
index dab5cf5..bca9cb8 100644
--- a/drivers/atm/idt77105.c
+++ b/drivers/atm/idt77105.c
@@ -126,7 +126,7 @@ static void idt77105_restart_timer_func(unsigned long dummy)
istat = GET(ISTAT); /* side effect: clears all interrupt status bits */
if (istat & IDT77105_ISTAT_GOODSIG) {
/* Found signal again */
- dev->signal = ATM_PHY_SIG_FOUND;
+ atm_dev_signal_change(dev, ATM_PHY_SIG_FOUND);
printk(KERN_NOTICE "%s(itf %d): signal detected again\n",
dev->type,dev->number);
/* flush the receive FIFO */
@@ -222,7 +222,7 @@ static void idt77105_int(struct atm_dev *dev)
/* Rx Signal Condition Change - line went up or down */
if (istat & IDT77105_ISTAT_GOODSIG) { /* signal detected again */
/* This should not happen (restart timer does it) but JIC */
- dev->signal = ATM_PHY_SIG_FOUND;
+ atm_dev_signal_change(dev, ATM_PHY_SIG_FOUND);
} else { /* signal lost */
/*
* Disable interrupts and stop all transmission and
@@ -235,7 +235,7 @@ static void idt77105_int(struct atm_dev *dev)
IDT77105_MCR_DRIC|
IDT77105_MCR_HALTTX
) & ~IDT77105_MCR_EIP, MCR);
- dev->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(dev, ATM_PHY_SIG_LOST);
printk(KERN_NOTICE "%s(itf %d): signal lost\n",
dev->type,dev->number);
}
@@ -272,8 +272,9 @@ static int idt77105_start(struct atm_dev *dev)
memset(&PRIV(dev)->stats,0,sizeof(struct idt77105_stats));
/* initialise dev->signal from Good Signal Bit */
- dev->signal = GET(ISTAT) & IDT77105_ISTAT_GOODSIG ? ATM_PHY_SIG_FOUND :
- ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(dev,
+ GET(ISTAT) & IDT77105_ISTAT_GOODSIG ?
+ ATM_PHY_SIG_FOUND : ATM_PHY_SIG_LOST);
if (dev->signal == ATM_PHY_SIG_LOST)
printk(KERN_WARNING "%s(itf %d): no signal\n",dev->type,
dev->number);
--
1.7.1
^ permalink raw reply related
* [PATCHv2] xfrm: fix xfrm by MARK logic
From: Peter Kosyh @ 2010-07-02 17:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
From: Peter Kosyh <p.kosyh@gmail.com>
While using xfrm by MARK feature in
2.6.34 - 2.6.35 kernels, the mark
is always cleared in flowi structure via memset in
_decode_session4 (net/ipv4/xfrm4_policy.c), so
the policy lookup fails.
IPv6 code is affected by this bug too.
Signed-off-by: Peter Kosyh <p.kosyh@gmail.com>
---
diff -uprN linux-2.6.35-rc3.orig/net/ipv4/xfrm4_policy.c linux-2.6.35-rc3/net/ipv4/xfrm4_policy.c
--- linux-2.6.35-rc3.orig/net/ipv4/xfrm4_policy.c 2010-06-12 06:14:04.000000000 +0400
+++ linux-2.6.35-rc3/net/ipv4/xfrm4_policy.c 2010-07-02 20:20:49.000000000 +0400
@@ -108,6 +108,8 @@ _decode_session4(struct sk_buff *skb, st
u8 *xprth = skb_network_header(skb) + iph->ihl * 4;
memset(fl, 0, sizeof(struct flowi));
+ fl->mark = skb->mark;
+
if (!(iph->frag_off & htons(IP_MF | IP_OFFSET))) {
switch (iph->protocol) {
case IPPROTO_UDP:
diff -uprN linux-2.6.35-rc3.orig/net/ipv6/xfrm6_policy.c linux-2.6.35-rc3/net/ipv6/xfrm6_policy.c
--- linux-2.6.35-rc3.orig/net/ipv6/xfrm6_policy.c 2010-06-12 06:14:04.000000000 +0400
+++ linux-2.6.35-rc3/net/ipv6/xfrm6_policy.c 2010-07-02 20:20:22.000000000 +0400
@@ -124,6 +124,8 @@ _decode_session6(struct sk_buff *skb, st
u8 nexthdr = nh[IP6CB(skb)->nhoff];
memset(fl, 0, sizeof(struct flowi));
+ fl->mark = skb->mark;
+
ipv6_addr_copy(&fl->fl6_dst, reverse ? &hdr->saddr : &hdr->daddr);
ipv6_addr_copy(&fl->fl6_src, reverse ? &hdr->daddr : &hdr->saddr);
^ permalink raw reply
* [PATCH net-2.6] net: Fix definition of netif_vdbg() when VERBOSE_DEBUG is defined
From: Ben Hutchings @ 2010-07-02 17:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Joe Perches
netif_vdbg() was originally defined as entirely equivalent to
netdev_vdbg(), but I assume that it was intended to take the same
parameters as netif_dbg() etc. (Currently it is only used by the
sfc driver, in which I worked on that assumption.)
In commit a4ed89c I changed the definition used when VERBOSE_DEBUG is
not defined, but I failed to notice that the definition used when
VERBOSE_DEBUG is defined was also not as I expected. Change that to
match netif_dbg() as well.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Since there are no users of this macro in net-2.6, this should be safe
to change. If you don't want to make this change in net-2.6 then please
revert a4ed89c in net-2.6 and apply this in net-next-2.6 so that the two
alternate definitions are consistent in each tree.
Ben.
include/linux/netdevice.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8fa5e5a..f823fd8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2352,7 +2352,7 @@ do { \
#endif
#if defined(VERBOSE_DEBUG)
-#define netif_vdbg netdev_dbg
+#define netif_vdbg netif_dbg
#else
#define netif_vdbg(priv, type, dev, format, args...) \
({ \
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: [PATCH] xfrm bugs with mark logic
From: Eric Dumazet @ 2010-07-02 16:59 UTC (permalink / raw)
To: Peter Kosyh; +Cc: netdev
In-Reply-To: <20100702162403.GA10809@myhost>
Le vendredi 02 juillet 2010 à 20:24 +0400, Peter Kosyh a écrit :
> >
> > Hi Peter
> >
> > XFRMA_MARK part already in net-2.6 tree :
> >
> > http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=4efd7e833591721bec21cc4730a7f6261417840f
> >
> > Please submit another patch the second problem you spotted ?
> >
>
> Yes, i see. Here it is, but i am little unsure about ipv6 fix.
>
Seems fine, but please read Documentation/SubmittingPatches to submit an
official patch.
Thanks !
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/3] ethtool: Change ethtool_op_set_flags to validate flags
From: Randy Dunlap @ 2010-07-02 16:55 UTC (permalink / raw)
To: Ben Hutchings
Cc: Amit Salecha, linux-net-drivers, Dimitris Michailidis,
Stanislaw Gruszka, Amerigo Wang, Jeff, e1000-devel, netdev,
Anirban Chakraborty, Garzik, Vasanthy Kolluri, Brice Goglin,
Andrew Gallatin, Scott Feldman, Stephen Hemminger, David Miller,
Lennert Buytenhek, Roopa Prabhu
In-Reply-To: <1277901872.2082.10.camel@achroite.uk.solarflarecom.com>
On Wed, 30 Jun 2010 13:44:32 +0100 Ben Hutchings wrote:
> ethtool_op_set_flags() does not check for unsupported flags, and has
> no way of doing so. This means it is not suitable for use as a
> default implementation of ethtool_ops::set_flags.
>
> Add a 'supported' parameter specifying the flags that the driver and
> hardware support, validate the requested flags against this, and
> change all current callers to pass this parameter.
>
> Change some other trivial implementations of ethtool_ops::set_flags to
> call ethtool_op_set_flags().
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
> ---
> drivers/net/cxgb4/cxgb4_main.c | 9 +--------
> drivers/net/enic/enic_main.c | 1 -
> drivers/net/ixgbe/ixgbe_ethtool.c | 5 ++++-
> drivers/net/mv643xx_eth.c | 7 ++++++-
> drivers/net/myri10ge/myri10ge.c | 10 +++++++---
> drivers/net/niu.c | 9 +--------
> drivers/net/sfc/ethtool.c | 5 +----
> drivers/net/sky2.c | 16 ++++++----------
> include/linux/ethtool.h | 2 +-
> net/core/ethtool.c | 28 +++++-----------------------
> 10 files changed, 32 insertions(+), 60 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 2c8af09..084ddb3 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -457,7 +457,7 @@ int ethtool_op_set_tso(struct net_device *dev, u32 data);
> u32 ethtool_op_get_ufo(struct net_device *dev);
> int ethtool_op_set_ufo(struct net_device *dev, u32 data);
> u32 ethtool_op_get_flags(struct net_device *dev);
> -int ethtool_op_set_flags(struct net_device *dev, u32 data);
> +int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported);
That one-line change is missing from linux-next-20100702, causing:
drivers/infiniband/ulp/ipoib/ipoib_ethtool.c:157: warning: initialization from incompatible pointer type
but the change (below) to net/core/ethtool.c is merged.
I don't quite see how this happened...
> void ethtool_ntuple_flush(struct net_device *dev);
>
> /**
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index a0f4964..5d42fae 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -144,31 +144,13 @@ u32 ethtool_op_get_flags(struct net_device *dev)
> }
> EXPORT_SYMBOL(ethtool_op_get_flags);
>
> -int ethtool_op_set_flags(struct net_device *dev, u32 data)
> +int ethtool_op_set_flags(struct net_device *dev, u32 data, u32 supported)
> {
> - const struct ethtool_ops *ops = dev->ethtool_ops;
> - unsigned long features = dev->features;
> -
> - if (data & ETH_FLAG_LRO)
> - features |= NETIF_F_LRO;
> - else
> - features &= ~NETIF_F_LRO;
> -
> - if (data & ETH_FLAG_NTUPLE) {
> - if (!ops->set_rx_ntuple)
> - return -EOPNOTSUPP;
> - features |= NETIF_F_NTUPLE;
> - } else {
> - /* safe to clear regardless */
> - features &= ~NETIF_F_NTUPLE;
> - }
> -
> - if (data & ETH_FLAG_RXHASH)
> - features |= NETIF_F_RXHASH;
> - else
> - features &= ~NETIF_F_RXHASH;
> + if (data & ~supported)
> + return -EINVAL;
>
> - dev->features = features;
> + dev->features = ((dev->features & ~flags_dup_features) |
> + (data & flags_dup_features));
> return 0;
> }
> EXPORT_SYMBOL(ethtool_op_set_flags);
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: iwl3945: HARDWARE GONE??
From: Stephen Hemminger @ 2010-07-02 16:48 UTC (permalink / raw)
To: John W. Linville; +Cc: Priit Laes, netdev, linux-kernel
In-Reply-To: <20100702162650.GC2381@tuxdriver.com>
On Fri, 2 Jul 2010 12:26:50 -0400
"John W. Linville" <linville@tuxdriver.com> wrote:
> On Fri, Jul 02, 2010 at 07:02:55PM +0300, Priit Laes wrote:
> > Heya!
> >
> > Bumped my kernel to version 2.6.35-rc3-00391-g97e0214 and ran into
> > HARDWARE GONE error message..
> >
> > Hardware is Lenovo x60s and wireless card is intel 3945:
> >
> > 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
> > Subsystem: Intel Corporation ThinkPad R60e/X60s
> > Flags: bus master, fast devsel, latency 0, IRQ 47
> > Memory at edf00000 (32-bit, non-prefetchable) [size=4K]
> > Capabilities: [c8] Power Management version 2
> > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> > Capabilities: [e0] Express Legacy Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [140] Device Serial Number 00-xx-xx-xx-xx-xx-xx-xx
> > Kernel driver in use: iwl3945
> > Kernel modules: iwl3945
> >
> > I have attached dmesg error message...
> >
> > Cheers,
> > Priit :)
>
> > [13813.347617] Uhhuh. NMI received for unknown reason a1 on CPU 0.
> > [13813.347617] You have some hardware problem, likely on the PCI bus.
> > [13813.347617] Dazed and confused, but trying to continue
> > [13813.347617] iwl3945 0000:03:00.0: HARDWARE GONE?? INTA == 0xffffffff
>
> We've been seeing this sort of thing a lot -- somehow the iwl3945 gets
> disconnected from the PCI bus. Anyone have any clue how that happens?
Usually this kind of problem is a power management issue.
^ permalink raw reply
* soft lockup with conntrackd / keepalived / VLAN
From: Adam Gundy @ 2010-07-02 16:04 UTC (permalink / raw)
To: netdev
I've built a pair of router boxes which are using keepalived and conntrackd to
provide a redundant router setup. we're also using a single 802.1Q VLAN on the
box.
occasionally, the box will lockup for 5 minutes, during which time routed
traffic is extremely delayed (2 or 3 second ping times). initially, there were
no log messages about the lockup. we switched from using an internal nvidia
(forcedeth) NIC in the belief that it may have been causing the problem..
however: with the new gigabit NICs, we still see the hangs, but we also get
this in the kernel log:
> Jul 2 07:50:12 cerberus1 kernel: [31895.510006] BUG: soft lockup - CPU#0 stuck for 61s! [conntrackd:1951]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] Modules linked in: authenc xfrm_user ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_tr
> ansport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm6_tunnel af_key cls_u32 sch_sfq sch_htb nf_conntrack_netlink nfnetli
> nk deflate zlib_deflate ctr camellia cast5 rmd160 sha1_generic crypto_null ccm serpent blowfish twofish twofish_common xcbc sha256_generic sha512_generic des_generi
> c cryptd aes_x86_64 aes_generic tunnel4 xfrm_ipcomp tunnel6 xt_MARK xt_tcpudp xt_esp ipt_ah xt_TCPMSS xt_HL xt_DSCP ipt_MASQUERADE ipt_REDIRECT ipt_LOG ipt_REJECT x
> t_mac xt_length xt_hl xt_dscp xt_tcpmss nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp ip_queue iptable_mangle ip
> table_filter xt_mark xt_recent xt_iprange xt_multiport xt_state xt_limit xt_conntrack iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_t
> ables 8021q fbcon tileblit font bitblit garp s
> Jul 2 07:50:17 cerberus1 kernel: oftcursor stp vga16fb vgastate lp shpchp sis_agp parport 8139too 8139cp r8169 mii sata_sis [last unloaded: af_key]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] CPU 0:
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] Modules linked in: authenc xfrm_user ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_tr
> ansport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm6_tunnel af_key cls_u32 sch_sfq sch_htb nf_conntrack_netlink nfnetli
> nk deflate zlib_deflate ctr camellia cast5 rmd160 sha1_generic crypto_null ccm serpent blowfish twofish twofish_common xcbc sha256_generic sha512_generic des_generi
> c cryptd aes_x86_64 aes_generic tunnel4 xfrm_ipcomp tunnel6 xt_MARK xt_tcpudp xt_esp ipt_ah xt_TCPMSS xt_HL xt_DSCP ipt_MASQUERADE ipt_REDIRECT ipt_LOG ipt_REJECT x
> t_mac xt_length xt_hl xt_dscp xt_tcpmss nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp ip_queue iptable_mangle ip
> table_filter xt_mark xt_recent xt_iprange xt_multiport xt_state xt_limit xt_conntrack iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_t
> ables 8021q fbcon tileblit font bitblit garp s
> Jul 2 07:50:17 cerberus1 kernel: oftcursor stp vga16fb vgastate lp shpchp sis_agp parport 8139too 8139cp r8169 mii sata_sis [last unloaded: af_key]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] Pid: 1951, comm: conntrackd Not tainted 2.6.32-23-server #37-Ubuntu ps6002
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] RIP: 0010:[<ffffffff814e9f52>] [<ffffffff814e9f52>] __xfrm4_find_bundle+0x52/0xc0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] RSP: 0018:ffff880001c03a88 EFLAGS: 00000282
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] RAX: 0000000000000000 RBX: ffff880001c03ab8 RCX: ffff880001c00000
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] RDX: 000000180c2813ac RSI: ffff880073f9e800 RDI: ffff880073f9e828
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] RBP: ffffffff81013cb3 R08: 0000000000000000 R09: ffff880001c03c44
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880001c03a00
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] R13: ffff880001c03c08 R14: ffff88000c299980 R15: ffffffff8155effc
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] FS: 00007fdec3db5700(0000) GS:ffff880001c00000(0000) knlGS:0000000000000000
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] CR2: 0000000000f1d078 CR3: 00000000715c0000 CR4: 00000000000006f0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] Call Trace:
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] <IRQ> [<ffffffff814e9f28>] ? __xfrm4_find_bundle+0x28/0xc0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814ee91e>] ? __xfrm_lookup+0x14e/0x4e0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8146c591>] ? __skb_checksum_complete+0x11/0x20
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814ee71d>] ? __xfrm_policy_check+0x57d/0x630
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814e9ee5>] ? _decode_session4+0x245/0x260
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814eecc6>] ? xfrm_lookup+0x16/0x40
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814eed5b>] ? __xfrm_route_forward+0x6b/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a355d>] ? ip_forward+0x2ed/0x420
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a15ed>] ? ip_rcv_finish+0x12d/0x440
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a1b75>] ? ip_rcv+0x275/0x360
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8153043d>] ? packet_rcv_spkt+0x4d/0x190
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8147236a>] ? netif_receive_skb+0x38a/0x5d0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81534be0>] ? __vlan_hwaccel_rx+0x140/0x230
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa0012596>] ? rtl8169_rx_interrupt+0x216/0x5b0 [r8169]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa0012aad>] ? rtl8169_poll+0x3d/0x270 [r8169]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81472e5f>] ? net_rx_action+0x10f/0x250
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8106e2f7>] ? __do_softirq+0xb7/0x1e0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff810142ec>] ? call_softirq+0x1c/0x30
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] <EOI> [<ffffffff81015cb5>] ? do_softirq+0x65/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8106e77a>] ? local_bh_enable+0x9a/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00b6185>] ? ipt_do_table+0x295/0x678 [ip_tables]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8106e77a>] ? local_bh_enable+0x9a/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00b6185>] ? ipt_do_table+0x295/0x678 [ip_tables]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8110ce7b>] ? __krealloc+0x3b/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00cb983>] ? __nf_ct_ext_add+0x143/0x180 [nf_conntrack]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff811330fd>] ? ksize+0x1d/0xd0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8110ce7b>] ? __krealloc+0x3b/0xa0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00f91d4>] ? nf_nat_rule_find+0x24/0x80 [iptable_nat]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00f9469>] ? nf_nat_fn+0x109/0x1b0 [iptable_nat]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffffa00f9558>] ? nf_nat_local_fn+0x48/0xe0 [iptable_nat]
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814997cc>] ? nf_iterate+0x6c/0xb0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a4b40>] ? dst_output+0x0/0x20
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81499884>] ? nf_hook_slow+0x74/0x100
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a4b40>] ? dst_output+0x0/0x20
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a6c9f>] ? __ip_local_out+0x9f/0xb0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a6cc6>] ? ip_local_out+0x16/0x30
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814a6f72>] ? ip_push_pending_frames+0x292/0x420
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814c9210>] ? udp_push_pending_frames+0x170/0x410
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814c9ef2>] ? udp_sendmsg+0x4e2/0x850
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814d2249>] ? inet_sendmsg+0x29/0x60
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff812862ed>] ? aa_revalidate_sk+0x6d/0x90
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81283bb9>] ? apparmor_socket_sendmsg+0x19/0x20
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff814618ab>] ? sock_sendmsg+0x10b/0x140
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81085090>] ? autoremove_wake_function+0x0/0x40
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81085090>] ? autoremove_wake_function+0x0/0x40
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8113f3d5>] ? __mem_cgroup_try_charge+0x55/0x1f0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff810fa819>] ? __alloc_pages_nodemask+0xd9/0x180
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81461a65>] ? sys_sendto+0x125/0x180
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff81115d7f>] ? handle_mm_fault+0x31f/0x3c0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff8155c883>] ? do_page_fault+0x153/0x3b0
> Jul 2 07:50:17 cerberus1 kernel: [31895.510006] [<ffffffff810131b2>] ? system_call_fastpath+0x16/0x1b
note, currently the second machine in the cluster is turned off.. same
behavior with or without it.
I'm seriously inclined to think that the VLAN is a big factor:
the reason for the VLAN is to separate VOIP phones (nothing else on that
VLAN). this morning, it was possible to trigger the lockup by placing a call.
as soon as the call was hungup, everything returned to normal...
it's not repeatable, exactly. what seems to happen is that pings through the
machine get slower and slower over the course of a few hours (from say 15ms to
50ms), then all of a sudden the machine will throw a five minute 'fit'.
PS: this is a Ubuntu Lucid kernel - 2.6.32. I'm working on a stock kernel to
see if it still happens..
^ permalink raw reply
* Re: iwl3945: HARDWARE GONE??
From: John W. Linville @ 2010-07-02 16:26 UTC (permalink / raw)
To: Priit Laes; +Cc: netdev, linux-kernel
In-Reply-To: <1278086575.2889.8.camel@chi>
On Fri, Jul 02, 2010 at 07:02:55PM +0300, Priit Laes wrote:
> Heya!
>
> Bumped my kernel to version 2.6.35-rc3-00391-g97e0214 and ran into
> HARDWARE GONE error message..
>
> Hardware is Lenovo x60s and wireless card is intel 3945:
>
> 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
> Subsystem: Intel Corporation ThinkPad R60e/X60s
> Flags: bus master, fast devsel, latency 0, IRQ 47
> Memory at edf00000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [c8] Power Management version 2
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [e0] Express Legacy Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Device Serial Number 00-xx-xx-xx-xx-xx-xx-xx
> Kernel driver in use: iwl3945
> Kernel modules: iwl3945
>
> I have attached dmesg error message...
>
> Cheers,
> Priit :)
> [13813.347617] Uhhuh. NMI received for unknown reason a1 on CPU 0.
> [13813.347617] You have some hardware problem, likely on the PCI bus.
> [13813.347617] Dazed and confused, but trying to continue
> [13813.347617] iwl3945 0000:03:00.0: HARDWARE GONE?? INTA == 0xffffffff
We've been seeing this sort of thing a lot -- somehow the iwl3945 gets
disconnected from the PCI bus. Anyone have any clue how that happens?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] xfrm bugs with mark logic
From: Peter Kosyh @ 2010-07-02 16:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1278082898.2530.37.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
>
> Hi Peter
>
> XFRMA_MARK part already in net-2.6 tree :
>
> http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=4efd7e833591721bec21cc4730a7f6261417840f
>
> Please submit another patch the second problem you spotted ?
>
Yes, i see. Here it is, but i am little unsure about ipv6 fix.
--
w.b.r. Peter Kosyh
[-- Attachment #2: linux-2.6.36-xfrm-mark.patch --]
[-- Type: text/plain, Size: 1036 bytes --]
diff -Nur linux-2.6.35-rc3.orig/net/ipv4/xfrm4_policy.c linux-2.6.35-rc3/net/ipv4/xfrm4_policy.c
--- linux-2.6.35-rc3.orig/net/ipv4/xfrm4_policy.c 2010-06-12 06:14:04.000000000 +0400
+++ linux-2.6.35-rc3/net/ipv4/xfrm4_policy.c 2010-07-02 20:20:49.000000000 +0400
@@ -108,6 +108,8 @@
u8 *xprth = skb_network_header(skb) + iph->ihl * 4;
memset(fl, 0, sizeof(struct flowi));
+ fl->mark = skb->mark;
+
if (!(iph->frag_off & htons(IP_MF | IP_OFFSET))) {
switch (iph->protocol) {
case IPPROTO_UDP:
diff -Nur linux-2.6.35-rc3.orig/net/ipv6/xfrm6_policy.c linux-2.6.35-rc3/net/ipv6/xfrm6_policy.c
--- linux-2.6.35-rc3.orig/net/ipv6/xfrm6_policy.c 2010-06-12 06:14:04.000000000 +0400
+++ linux-2.6.35-rc3/net/ipv6/xfrm6_policy.c 2010-07-02 20:20:22.000000000 +0400
@@ -124,6 +124,8 @@
u8 nexthdr = nh[IP6CB(skb)->nhoff];
memset(fl, 0, sizeof(struct flowi));
+ fl->mark = skb->mark;
+
ipv6_addr_copy(&fl->fl6_dst, reverse ? &hdr->saddr : &hdr->daddr);
ipv6_addr_copy(&fl->fl6_src, reverse ? &hdr->daddr : &hdr->saddr);
^ permalink raw reply
* iwl3945: HARDWARE GONE??
From: Priit Laes @ 2010-07-02 16:02 UTC (permalink / raw)
To: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
Heya!
Bumped my kernel to version 2.6.35-rc3-00391-g97e0214 and ran into
HARDWARE GONE error message..
Hardware is Lenovo x60s and wireless card is intel 3945:
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
Subsystem: Intel Corporation ThinkPad R60e/X60s
Flags: bus master, fast devsel, latency 0, IRQ 47
Memory at edf00000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-xx-xx-xx-xx-xx-xx-xx
Kernel driver in use: iwl3945
Kernel modules: iwl3945
I have attached dmesg error message...
Cheers,
Priit :)
[-- Attachment #2: Type: text/plain, Size: 14319 bytes --]
[13813.347617] Uhhuh. NMI received for unknown reason a1 on CPU 0.
[13813.347617] You have some hardware problem, likely on the PCI bus.
[13813.347617] Dazed and confused, but trying to continue
[13813.347617] iwl3945 0000:03:00.0: HARDWARE GONE?? INTA == 0xffffffff
[13813.846039] iwl3945 0000:03:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
[13814.740056] iwl3945 0000:03:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.
[13815.516037] iwl3945 0000:03:00.0: queue 4 stuck 3 time. Fw reload.
[13815.516043] iwl3945 0000:03:00.0: On demand firmware reload
[13815.517024] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.538452] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.559845] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.581247] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.602649] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.624045] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.645451] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.666844] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.688249] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.709654] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.731066] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.752493] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.774006] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.795593] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.817023] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.838460] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.967302] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13815.987649] ieee80211 phy0: U iwl3945_nic_config SW RF KILL supported in EEPROM.
[13815.987654] ieee80211 phy0: U iwl3945_nic_config HW RF KILL supported in EEPROM.
[13815.988614] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.010153] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.031442] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.052709] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.073984] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.095257] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.116550] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.137824] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.159097] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.180368] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.201635] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.222901] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.244176] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.265448] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.288031] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.308002] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.329273] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.350609] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.371874] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.393154] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.414471] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.435737] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.457005] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.478340] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.499622] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.520902] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.542226] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.563495] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.584779] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.606071] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.627334] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.648597] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.669891] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.691175] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.712452] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.733736] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.755435] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.775720] iwl3945 0000:03:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
[13816.775724] iwl3945 0000:03:00.0: Unable to set up bootstrap uCode: -5
[13816.776714] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.797992] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.819257] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.841984] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.861813] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.883526] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.903809] iwl3945 0000:03:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
[13816.903813] iwl3945 0000:03:00.0: Unable to set up bootstrap uCode: -5
[13816.904803] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.926079] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.947349] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.968622] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13816.990258] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.011587] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.031866] iwl3945 0000:03:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
[13817.031870] iwl3945 0000:03:00.0: Unable to set up bootstrap uCode: -5
[13817.032860] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.063144] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.075525] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.096811] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.118256] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.141274] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.160076] iwl3945 0000:03:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
[13817.160080] iwl3945 0000:03:00.0: Unable to set up bootstrap uCode: -5
[13817.161068] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.182349] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.203619] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.224884] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.246257] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.267876] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.288161] iwl3945 0000:03:00.0: BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xffffffff, s/b 0xf802020
[13817.288165] iwl3945 0000:03:00.0: Unable to set up bootstrap uCode: -5
[13817.289155] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.310441] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.331715] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.352986] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.374266] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.395539] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.416831] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.438105] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.459382] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.480665] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.501954] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.533431] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.544529] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.567553] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.587377] iwl3945 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0xFFFFFFFF
[13817.607688] iwl3945 0000:03:00.0: Unable to initialize device after 5 attempts.
[13818.268038] No probe response from AP 00:13:10:15:0e:27 after 500ms, disconnecting.
[13818.268067] BUG: unable to handle kernel NULL pointer dereference at 0000000000000168
[13818.268076] IP: [<ffffffff812a88d2>] iwl_enqueue_hcmd+0xd5/0x54e
[13818.268088] PGD 0
[13818.268093] Oops: 0000 [#1] SMP
[13818.268099] last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq
[13818.268104] CPU 1
[13818.268107] Modules linked in: ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc option usb_wwan usbserial sdhci_pci sdhci iwl3945 mmc_core
[13818.268131]
[13818.268138] Pid: 1382, comm: phy0 Not tainted 2.6.35-rc3-00391-g97e0214 #12 1702M3G/1702M3G
[13818.268143] RIP: 0010:[<ffffffff812a88d2>] [<ffffffff812a88d2>] iwl_enqueue_hcmd+0xd5/0x54e
[13818.268153] RSP: 0018:ffff8800bb2efbb0 EFLAGS: 00010006
[13818.268157] RAX: 0000000000000200 RBX: 0000000000000160 RCX: 0000000000000000
[13818.268162] RDX: 0000000000000020 RSI: 0000000000000024 RDI: 0000000000000013
[13818.268168] RBP: ffff8800bb991380 R08: 0000000000000000 R09: ffff8800bb991380
[13818.268173] R10: ffff8800bb999b78 R11: 0000000000000001 R12: ffff8800bb2efc90
[13818.268178] R13: ffffffff8158d563 R14: 0000000000000000 R15: ffff8800bb990460
[13818.268184] FS: 0000000000000000(0000) GS:ffff880001b00000(0000) knlGS:0000000000000000
[13818.268190] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[13818.268195] CR2: 0000000000000168 CR3: 0000000001625000 CR4: 00000000000006e0
[13818.268200] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[13818.268205] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[13818.268211] Process phy0 (pid: 1382, threadinfo ffff8800bb2ee000, task ffff8800bae31bc0)
[13818.268215] Stack:
[13818.268218] ffff880001b124c0 0000000000000001 ffff880001b124c0 ffff8800bae31bc0
[13818.268225] <0> ffff8800bae31bf8 ffff880001b124c0 ffff8800bb2efc20 ffffffff8104869f
[13818.268233] <0> ffff880001b124c0 ffff880000283e70 0000000000000000 0000000000000001
[13818.268242] Call Trace:
[13818.268253] [<ffffffff8104869f>] ? check_preempt_wakeup+0xf6/0x16e
[13818.268261] [<ffffffff812a3dcd>] ? iwl_send_cmd_async+0x4d/0xbd
[13818.268267] [<ffffffff812a3e76>] ? iwl_send_cmd_pdu_async+0x39/0x3e
[13818.268274] [<ffffffff812a3e7b>] ? iwl_generic_cmd_callback+0x0/0x13c
[13818.268283] [<ffffffff8129eb6b>] ? iwl_mac_config+0x644/0x842
[13818.268292] [<ffffffff8146d4c0>] ? _raw_spin_lock_bh+0x9/0x1f
[13818.268299] [<ffffffff81453fc0>] ? ieee80211_set_wmm_default+0x132/0x13d
[13818.268309] [<ffffffff8131f722>] ? led_trigger_event+0x22/0x5c
[13818.268317] [<ffffffff81444f39>] ? ieee80211_set_disassoc+0x116/0x1a5
[13818.268324] [<ffffffff81447c0d>] ? ieee80211_sta_work+0x584/0x5d3
[13818.268331] [<ffffffff814471ce>] ? ieee80211_beacon_connection_loss_work+0xaa/0xb5
[13818.268338] [<ffffffff81447689>] ? ieee80211_sta_work+0x0/0x5d3
[13818.268346] [<ffffffff810643ef>] ? worker_thread+0x13d/0x1c2
[13818.268354] [<ffffffff8106789b>] ? autoremove_wake_function+0x0/0x2a
[13818.268361] [<ffffffff810642b2>] ? worker_thread+0x0/0x1c2
[13818.268367] [<ffffffff810674e1>] ? kthread+0x75/0x7d
[13818.268376] [<ffffffff81022d94>] ? kernel_thread_helper+0x4/0x10
[13818.268383] [<ffffffff8106746c>] ? kthread+0x0/0x7d
[13818.268390] [<ffffffff81022d90>] ? kernel_thread_helper+0x0/0x10
[13818.268393] Code: e9 48 89 c6 48 89 da 48 c7 c7 5e df 5a 81 31 c0 e8 1d 27 1c 00 b8 fb ff ff ff e9 76 04 00 00 48 8b 5c 24 50 48 81 c3 60 01 00 00 <8b> 4b 08 8b 53 04 89 c8 29 d0 39 d1 7e 0b 48 8b 54 24 50 2b 82
[13818.268454] RIP [<ffffffff812a88d2>] iwl_enqueue_hcmd+0xd5/0x54e
[13818.268462] RSP <ffff8800bb2efbb0>
[13818.268465] CR2: 0000000000000168
[13818.268471] ---[ end trace a77a3dc99e96ee11 ]---
^ permalink raw reply
* Practical performance change to qdisc_lookup
From: Bart @ 2010-07-02 15:51 UTC (permalink / raw)
To: netdev@vger.kernel.org
While looking to speed up our batch processing of many-thousands of TC
rules I stumbled across a usage-based optimization of qdisc_lookup().
while not a algorithmic optimization, I would wager that future rules
are likely to refer to the more recently created qdiscs and not the
oldest ones.
It is silly, but I thought I'd survey opinions on the change. It is far
less code entropy than say, implementing a hash lookup.
sch_api.c:
@@ -197,7 +197,7 @@
root->handle == handle)
return root;
- list_for_each_entry(q, &root->list, list) {
+ list_for_each_entry_reverse(q, &root->list, list) {
if (q->handle == handle)
return q;
}
^ permalink raw reply
* Re: [PATCH] xfrm bugs with mark logic
From: Eric Dumazet @ 2010-07-02 15:01 UTC (permalink / raw)
To: Peter Kosyh; +Cc: netdev
In-Reply-To: <AANLkTimsVHoNk3B1oTI6awlNtrmNED7vwe2flzTap9aP@mail.gmail.com>
Le vendredi 02 juillet 2010 à 14:40 +0400, Peter Kosyh a écrit :
> Hello! I am currently working with 2.6.34, trying to use iptables ...
> -j MARK with XFRM policy. So, i found at least
> two bugs in 2.6.34 kernel.
>
> First bug is just typo in xfrm_mark_get (net/xfrm.h):
>
> memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
>
> must be:
>
> memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(*m));
>
> The second one, is clearing mark in flowi structure via memset in
> _decode_session4 (net/ipv4/xfrm4_policy.c).
> (see net/ipv4/netfilter.c, ip_route_me_harder function)
> int ip_route_me_harder(struct sk_buff *skb, unsigned addr_type)
> /* ... */
> if (addr_type == RTN_LOCAL) {
> /* ... */
> fl.mark = skb->mark; /* here, set mark from skb */
> /* ... */
> #ifdef CONFIG_XFRM
> if (!(IPCB(skb)->flags & IPSKB_XFRM_TRANSFORMED) &&
> xfrm_decode_session(skb, &fl, AF_INET) == 0) { /* here
> fl->mark will be zeroed */
> /* ... */
> if (xfrm_lookup(net, &dst, &fl, skb->sk, 0)) /* here
> policy lookup will fail */
>
> Do not know about ipv6 anything, but it's like that it affected by
> this bug too. :(
>
> P.S. Sorry for my bad English. :)
>
> w.b.r. Peter Kosyh
>
> diff -Nur linux-2.6.34/include/net/xfrm.h linux-2.6.34.fix/include/net/xfrm.h
> --- linux-2.6.34/include/net/xfrm.h 2010-05-16 21:17:36.000000000 +0000
> +++ linux-2.6.34.fix/include/net/xfrm.h 2010-07-02 10:05:33.000000000 +0000
> @@ -1587,7 +1587,7 @@
> static inline int xfrm_mark_get(struct nlattr **attrs, struct xfrm_mark *m)
> {
> if (attrs[XFRMA_MARK])
> - memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(m));
> + memcpy(m, nla_data(attrs[XFRMA_MARK]), sizeof(*m));
> else
> m->v = m->m = 0;
> diff -Nur linux-2.6.34/net/ipv4/xfrm4_policy.c
> linux-2.6.34.fix/net/ipv4/xfrm4_policy.c
> --- linux-2.6.34/net/ipv4/xfrm4_policy.c 2010-05-16 21:17:36.000000000 +0000
> +++ linux-2.6.34.fix/net/ipv4/xfrm4_policy.c 2010-07-02 10:17:51.000000000 +0000
> @@ -186,6 +186,7 @@
> fl->fl4_dst = reverse ? iph->saddr : iph->daddr;
> fl->fl4_src = reverse ? iph->daddr : iph->saddr;
> fl->fl4_tos = iph->tos;
> + fl->mark = skb->mark;
> }
>
> static inline int xfrm4_garbage_collect(struct dst_ops *ops)
> --
Hi Peter
XFRMA_MARK part already in net-2.6 tree :
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=4efd7e833591721bec21cc4730a7f6261417840f
Please submit another patch the second problem you spotted ?
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-07-01
From: John W. Linville @ 2010-07-02 14:08 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100701.173550.172604489.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, Jul 01, 2010 at 05:35:50PM -0700, David Miller wrote:
> From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Date: Thu, 1 Jul 2010 14:15:27 -0400
>
> > Two weeks since the last request, plenty of new stuff intended for
> > 2.6.36...
> >
> > Included are the usual bunch of driver updates, including a big
> > dump from the rt2x00 team. This also includes cfg80211 support
> > for libertas, a flurry of (mostly trivial) stuff from me, and a
> > wireless-2.6 pull to resolve some patch dependencies.
> >
> > Please let me know if there are problems!
>
> This failed to pull cleanly, I got a conflict in
> drivers/net/wireless/libertas/host.h It was the
> usual "__packed" vs. "__attribute__((packed))" thing.
>
> I resolved it but I wonder if this happened because you
> did the wireless-2.6 --> wireless-next-2.6 merge here.
Sorry, Dave! I probably should have done 'for-davem' branch for you.
Thanks for resolving it!
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [PATCH 1/9] netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
From: Patrick McHardy @ 2010-07-02 14:07 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <alpine.LSU.2.01.1007021452430.11763@obet.zrqbmnf.qr>
Jan Engelhardt wrote:
> On Friday 2010-07-02 14:35, Patrick McHardy wrote:
>
>>>> Sure they do, if they are destined for the host itself. I'm not sure
>>>> what's so hard to understand about this patch, you have f.i. multiple
>>>> tunnels using the same remote network, on INPUT and POSTROUTING you SNAT
>>>> them to seperate networks based on criteria like the network device or
>>>> the IPsec tunnel to be able to distinguish them.
>>>>
>>>>
>>> But they are already distinguishable by the ctmark that is applied
>>> to these connections to do routing of the reply, are they not?
>>>
>>>
>> Its not (only) about routing, you simply can't have two connections using
>> the same identity.
>>
>
> Which is why the zone thing is added.
>
I'm not talking about conntrack at all. A connection needs
a unique identity. Just look at the socket lookup code.
> Ah, but I now see that you need to select a zone for it first.. touché.
>
> Still this SNAT-on-INPUT leaves a second taste. Adding another address
> to the tunnel master and using DNAT-on-PREROUTING for local deliveries
> would have also made the connections unambiguous
^ permalink raw reply
* [PATCH] usbnet: remove direct access to urb->status
From: Oliver Neukum @ 2010-07-02 13:58 UTC (permalink / raw)
To: netdev; +Cc: davem
>From a2e8da61490cba876b1b4814c4832822527c43dd Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oliver@neukum.org>
Date: Fri, 2 Jul 2010 15:51:55 +0200
Subject: [PATCH] usbnet: remove direct access to urb->status
USB drivers should not use urb->status directly because
it is scheduled to become a parameter. This does the conversion
for drivers/net/usb
Signed-off-by: Oliver Neukum <oneukum@suse.de>
---
drivers/net/usb/cdc-phonet.c | 8 +++++---
drivers/net/usb/ipheth.c | 13 +++++++------
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/cdc-phonet.c b/drivers/net/usb/cdc-phonet.c
index dc94445..109751b 100644
--- a/drivers/net/usb/cdc-phonet.c
+++ b/drivers/net/usb/cdc-phonet.c
@@ -97,8 +97,9 @@ static void tx_complete(struct urb *req)
struct sk_buff *skb = req->context;
struct net_device *dev = skb->dev;
struct usbpn_dev *pnd = netdev_priv(dev);
+ int status = req->status;
- switch (req->status) {
+ switch (status) {
case 0:
dev->stats.tx_bytes += skb->len;
break;
@@ -109,7 +110,7 @@ static void tx_complete(struct urb *req)
dev->stats.tx_aborted_errors++;
default:
dev->stats.tx_errors++;
- dev_dbg(&dev->dev, "TX error (%d)\n", req->status);
+ dev_dbg(&dev->dev, "TX error (%d)\n", status);
}
dev->stats.tx_packets++;
@@ -150,8 +151,9 @@ static void rx_complete(struct urb *req)
struct page *page = virt_to_page(req->transfer_buffer);
struct sk_buff *skb;
unsigned long flags;
+ int status = req->status;
- switch (req->status) {
+ switch (status) {
case 0:
spin_lock_irqsave(&pnd->rx_lock, flags);
skb = pnd->rx_skb;
diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index 197c352..08e7b6a 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -193,7 +193,7 @@ static void ipheth_rcvbulk_callback(struct urb *urb)
case 0:
break;
default:
- err("%s: urb status: %d", __func__, urb->status);
+ err("%s: urb status: %d", __func__, status);
return;
}
@@ -222,16 +222,17 @@ static void ipheth_rcvbulk_callback(struct urb *urb)
static void ipheth_sndbulk_callback(struct urb *urb)
{
struct ipheth_device *dev;
+ int status = urb->status;
dev = urb->context;
if (dev == NULL)
return;
- if (urb->status != 0 &&
- urb->status != -ENOENT &&
- urb->status != -ECONNRESET &&
- urb->status != -ESHUTDOWN)
- err("%s: urb status: %d", __func__, urb->status);
+ if (status != 0 &&
+ status != -ENOENT &&
+ status != -ECONNRESET &&
+ status != -ESHUTDOWN)
+ err("%s: urb status: %d", __func__, status);
dev_kfree_skb_irq(dev->tx_skb);
netif_wake_queue(dev->net);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/9] netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
From: Jan Engelhardt @ 2010-07-02 12:58 UTC (permalink / raw)
To: Patrick McHardy; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <4C2DDD29.7030503@trash.net>
On Friday 2010-07-02 14:35, Patrick McHardy wrote:
>>> Sure they do, if they are destined for the host itself. I'm not sure
>>> what's so hard to understand about this patch, you have f.i. multiple
>>> tunnels using the same remote network, on INPUT and POSTROUTING you SNAT
>>> them to seperate networks based on criteria like the network device or
>>> the IPsec tunnel to be able to distinguish them.
>>>
>>
>> But they are already distinguishable by the ctmark that is applied
>> to these connections to do routing of the reply, are they not?
>>
>
> Its not (only) about routing, you simply can't have two connections using
> the same identity.
Which is why the zone thing is added.
Ah, but I now see that you need to select a zone for it first.. touché.
Still this SNAT-on-INPUT leaves a second taste. Adding another address
to the tunnel master and using DNAT-on-PREROUTING for local deliveries
would have also made the connections unambiguous.
^ permalink raw reply
* Re: [PATCH 1/9] netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
From: Patrick McHardy @ 2010-07-02 12:35 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <alpine.LSU.2.01.1007021416120.30410@obet.zrqbmnf.qr>
Jan Engelhardt wrote:
> On Friday 2010-07-02 12:17, Patrick McHardy wrote:
>
>>> I still have not grasped why SNAT is needed in the INPUT path. For the
>>> tunnel scenario that you wanted to build I could not find a reason to
>>> do SNAT in that place - since the non-encapsulated packets don't go
>>> through INPUT anyway.
>>>
>> Sure they do, if they are destined for the host itself. I'm not sure
>> what's so hard to understand about this patch, you have f.i. multiple
>> tunnels using the same remote network, on INPUT and POSTROUTING you SNAT
>> them to seperate networks based on criteria like the network device or
>> the IPsec tunnel to be able to distinguish them.
>>
>
> But they are already distinguishable by the ctmark that is applied
> to these connections to do routing of the reply, are they not?
>
Its not (only) about routing, you simply can't have two connections using
the same identity.
^ permalink raw reply
* Re: [PATCH 1/9] netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN
From: Jan Engelhardt @ 2010-07-02 12:17 UTC (permalink / raw)
To: Patrick McHardy; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <4C2DBCD3.20208@trash.net>
On Friday 2010-07-02 12:17, Patrick McHardy wrote:
>>
>> I still have not grasped why SNAT is needed in the INPUT path. For the
>> tunnel scenario that you wanted to build I could not find a reason to
>> do SNAT in that place - since the non-encapsulated packets don't go
>> through INPUT anyway.
>
> Sure they do, if they are destined for the host itself. I'm not sure
> what's so hard to understand about this patch, you have f.i. multiple
> tunnels using the same remote network, on INPUT and POSTROUTING you SNAT
> them to seperate networks based on criteria like the network device or
> the IPsec tunnel to be able to distinguish them.
But they are already distinguishable by the ctmark that is applied
to these connections to do routing of the reply, are they not?
^ 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