* RE: [PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
From: Sean Hefty @ 2009-11-11 20:55 UTC (permalink / raw)
To: 'Roland Dreier'
Cc: 'Eric Dumazet', David S. Miller, Linux Netdev List,
Roland Dreier, Hal Rosenstock, linux-rdma
In-Reply-To: <adaocn8x6j7.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
>Would it be possible for you to take Eric's patch as the first in your
>set (keeping his From: of course) and base your fixes on top of that?
Will do.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* [PATCH] iwlwifi: fix iwl1000 "RTS/CTS for HT" merge damage
From: John W. Linville @ 2009-11-11 20:48 UTC (permalink / raw)
To: netdev; +Cc: davem, John W. Linville
I may have botched my merge conflict resolution instructions for Dave...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/iwlwifi/iwl-1000.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-1000.c b/drivers/net/wireless/iwlwifi/iwl-1000.c
index 1e387b9..8f82537 100644
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -170,6 +170,7 @@ struct iwl_cfg iwl1000_bgn_cfg = {
.shadow_ram_support = false,
.ht_greenfield_support = true,
.led_compensation = 51,
+ .use_rts_for_ht = true, /* use rts/cts protection */
.chain_noise_num_beacons = IWL_CAL_NUM_BEACONS,
.support_ct_kill_exit = true,
};
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH] iwlwifi: fix iwl1000 "RTS/CTS for HT" merge damage
From: David Miller @ 2009-11-11 21:04 UTC (permalink / raw)
To: linville; +Cc: netdev
In-Reply-To: <1257972506-14524-1-git-send-email-linville@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 11 Nov 2009 15:48:26 -0500
> I may have botched my merge conflict resolution instructions for Dave...
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Applied, thanks John.
^ permalink raw reply
* Re: sparse noise due to patch "net: fix kmemcheck annotations"
From: Eric Dumazet @ 2009-11-11 21:13 UTC (permalink / raw)
To: Stefan Richter; +Cc: netdev
In-Reply-To: <4AFB217E.2040209@s5r6.in-berlin.de>
Stefan Richter a écrit :
> Hi Eric,
>
> with above mentioned patch, committed as
> 14d18a81b5171d4433e41129619c75748b4f4d26, you changed
>
> struct sk_buff {
> ...
> __be16 protocol;
> ...
> }
> to
> __be16 protocol:16;
>
> This introduces the following warning from sparse:
>
> include/linux/skbuff.h:357:41: error: invalid bitfield specifier for
> type restricted __be16.
>
> So, one checker satisfied, another disturbed? Any idea how to get this
> sparse-clean again?
No problem here... how do you get this error, and what is your sparse version ?
^ permalink raw reply
* Re: [PATCH] [next-next-2.6] net: configurable device name hash
From: Stephen Hemminger @ 2009-11-11 21:33 UTC (permalink / raw)
To: David Miller; +Cc: opurdila, netdev
In-Reply-To: <20091111.124235.243348591.davem@davemloft.net>
On Wed, 11 Nov 2009 12:42:35 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Octavian Purdila <opurdila@ixiacom.com>
> Date: Wed, 11 Nov 2009 21:38:44 +0200
>
> > I don't think we can dynamically size it at boot time since it
> > depends on the usage pattern which is impossible to determine at
> > boot time, right?
>
> We have no idea how many sockets will be used by the system yet we
> dynamically size the socket hash tables.
>
> Please do some research and see how we handle this elsewhere in the
> networking.
dcache also sizes hash bits at boot time on available memory.
See alloc_large_system_hash().
^ permalink raw reply
* Re: sparse noise due to patch "net: fix kmemcheck annotations"
From: Stefan Richter @ 2009-11-11 21:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <4AFB28DE.8070000@gmail.com>
Eric Dumazet wrote:
> Stefan Richter a écrit :
>> include/linux/skbuff.h:357:41: error: invalid bitfield specifier for
>> type restricted __be16.
...
> No problem here... how do you get this error, and what is your sparse version ?
It's sparse 0.4.2.
The note is only logged with 'make ... CF="-D__CHECK_ENDIAN__"'.
I guess sparse could be taught to ignore :_ suffixes if the suffix
covers the whole width of the type... unless there is something that
could be improved in kmemcheck.
--
Stefan Richter
-=====-==--= =-== -=-==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: Andi Kleen @ 2009-11-11 21:43 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <65634d660911102253o2b4f7a19kfed5849e5c88bfe1@mail.gmail.com>
Tom Herbert <therbert@google.com> writes:
> Third version of RPS.
This really needs the text from 0/2 here as git changelog, otherwise
you make David's life hard if he wants to merge this.
> +
> +/*
> * The DEVICE structure.
> * Actually, this whole structure is a big mistake. It mixes I/O
> * data with strictly "high-level" data, and it has to know about
> @@ -807,6 +819,9 @@ struct net_device
> void *ax25_ptr; /* AX.25 specific data */
> struct wireless_dev *ieee80211_ptr; /* IEEE 802.11 specific data,
> assign before registering */
> + void *rps_maps; /* Array of per-NAPI maps for
> + receive packet steeing */
Why is this void * here? This should be a real type.
> + int rps_num_maps; /* Number of RPS maps */
This has a 4 byte hole on 64bit. Better move it somewhere else
where that isn't the case.
>
> /*
> * Cache line mostly used on receive path (including eth_type_trans())
Also make sure you you don't destroy these cache line optimizations.
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 0c68fbd..95feac7 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -396,6 +396,8 @@ struct sk_buff {
>
> __u16 vlan_tci;
>
> + __u32 rxhash;
Similarly here.
> + * get_rps_cpu is called from netif_receive_skb and returns the target
> + * CPU from the RPS map of the receiving NAPI instance for a given skb.
> + */
> +static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb)
> +{
> + u32 addr1, addr2, ports;
> + struct ipv6hdr *ip6;
> + struct iphdr *ip;
> + u32 hash, ihl;
> + u8 ip_proto;
> + int cpu;
> + struct rps_map *map = NULL;
> +
> + if (dev->rps_num_maps) {
> + /*
> + * Locate the map corresponding to the NAPI queue that
> + * the packet was received on.
> + */
> + int index = skb_get_rx_queue(skb);
> + if (index < 0 || index >= dev->rps_num_maps)
> + index = 0;
> +
> + map = (struct rps_map *)
> + (dev->rps_maps + (RPS_MAP_SIZE * index));
> + if (!map->len)
> + map = NULL;
Can this really happen? Better might be to move this out of the fast path.
> + switch (skb->protocol) {
> + case __constant_htons(ETH_P_IP):
> + if (!pskb_may_pull(skb, sizeof(*ip)))
> + return -1;
> +
> + ip = (struct iphdr *) skb->data;
> + ip_proto = ip->protocol;
> + addr1 = ip->saddr;
> + addr2 = ip->daddr;
> + ihl = ip->ihl;
> + break;
> + case __constant_htons(ETH_P_IPV6):
> + if (!pskb_may_pull(skb, sizeof(*ip6)))
> + return -1;
> +
> + ip6 = (struct ipv6hdr *) skb->data;
> + ip_proto = ip6->nexthdr;
> + addr1 = ip6->saddr.s6_addr32[3];
> + addr2 = ip6->daddr.s6_addr32[3];
Why only [3] ? Is this future proof?
> +/**
> + * net_rps_action is called from NET_RPS_SOFTIRQ to do IPIs to schedule RX
> + * softirq on remote CPUs. Called in a separate softirq to allow for
> + * coalescing.
> + */
> +static void net_rps_action(struct softirq_action *h)
> +{
> + int cpu;
> +
> + local_irq_disable();
> +
> + for_each_cpu_mask_nr(cpu, __get_cpu_var(rps_remote_softirq_cpus)) {
> + struct softnet_data *queue = &per_cpu(softnet_data, cpu);
> + __smp_call_function_single(cpu, &queue->csd, 0);
How do you get around the standard deadlocks with IPI called from
irq disabled section?
And why are the interrupts are disabled here anyways?
> @@ -2696,21 +2842,24 @@ static int process_backlog(struct napi_struct
> *napi, int quota)
> int work = 0;
> struct softnet_data *queue = &__get_cpu_var(softnet_data);
> unsigned long start_time = jiffies;
> + unsigned long flags;
>
> napi->weight = weight_p;
> do {
> struct sk_buff *skb;
>
> local_irq_disable();
> + spin_lock_irqsave(&queue->input_pkt_queue.lock, flags);
When you just disabled the irqs you obviously don't need a irqsave
in the next line.
> skb = __skb_dequeue(&queue->input_pkt_queue);
> if (!skb) {
> __napi_complete(napi);
> - local_irq_enable();
> + spin_unlock_irqrestore(&queue->input_pkt_queue.lock,
> + flags);
> break;
This will actually not turn on interrupts again because you only
saved them after disabling them.
> }
> - local_irq_enable();
> + spin_unlock_irqrestore(&queue->input_pkt_queue.lock, flags);
Same
>
> - netif_receive_skb(skb);
> + __netif_receive_skb(skb);
> } while (++work < quota && jiffies == start_time);
>
> return work;
> @@ -5205,6 +5354,8 @@ void free_netdev(struct net_device *dev)
> /* Flush device addresses */
> dev_addr_flush(dev);
>
> + kfree(dev->rps_maps);
> +
> list_for_each_entry_safe(p, n, &dev->napi_list, dev_list)
> netif_napi_del(p);
>
> @@ -5644,6 +5795,10 @@ static int __init net_dev_init(void)
> queue->completion_queue = NULL;
> INIT_LIST_HEAD(&queue->poll_list);
>
> + queue->csd.func = trigger_softirq;
> + queue->csd.info = queue;
> + queue->csd.flags = 0;
> +
> queue->backlog.poll = process_backlog;
> queue->backlog.weight = weight_p;
> queue->backlog.gro_list = NULL;
> @@ -5669,7 +5824,9 @@ static int __init net_dev_init(void)
>
> open_softirq(NET_TX_SOFTIRQ, net_tx_action);
> open_softirq(NET_RX_SOFTIRQ, net_rx_action);
> + open_softirq(NET_RPS_SOFTIRQ, net_rps_action);
>
> + get_random_bytes(&simple_hashrnd, 4);
It's a standard pet peeve of me, but it's quite unlikely you'll
get any useful entropy at this time of kernel startup.
Normally it's always the same.
> +static char *
> +get_token(const char **cp, size_t *len)
> +{
> + const char *bp = *cp, *start;
> +
> + while (isspace(*bp))
> + bp++;
> +
> + start = bp;
> + while (!isspace(*bp) && *bp != '\0')
> + bp++;
> +
> + if (start != bp)
> + *len = bp - start;
> + else
> + start = NULL;
> +
> + *cp = bp;
> + return start;
> +}
> +
> +static ssize_t store_rps_cpus(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t len)
> +{
> + struct net_device *net = to_net_dev(dev);
> + struct napi_struct *napi;
> + cpumask_t mask;
> + int err, cpu, index, i;
> + int cnt = 0;
> + char *token;
> + const char *cp = buf;
> + size_t tlen;
> +
> + if (!capable(CAP_NET_ADMIN))
> + return -EPERM;
> +
> + /*
> + * Pre-check that tokens parse properly before we commit to making
> + * any changes.
> + */
> + while ((token = get_token(&cp, &tlen)))
> + err = bitmap_parse(token, tlen, cpumask_bits(&mask),
> + nr_cpumask_bits);
> +
> + if (err)
> + return err;
> +
> + rtnl_lock();
It seems weird to do user parsing while holding that lock.
Better first set up and allocate and then finally initialize global state.
> + if (dev_isalive(net)) {
Especially since the device is alive. So what happens to interrupts
coming in in parallel? That seems racy.
+
+ queue = &per_cpu(softnet_data, cpu);
+ spin_lock_irqsave(&queue->input_pkt_queue.lock, flags);
+
+ __get_cpu_var(netdev_rx_stat).total++;
+ if (queue->input_pkt_queue.qlen <= netdev_max_backlog) {
It seems weird to do the local counter increase after grabbing
the global lock. Also does someone count on the real receiver anyways?
That might be better, right now the count would be a bit
misleading.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: Andi Kleen @ 2009-11-11 21:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, David Miller, netdev
In-Reply-To: <4AFA73DA.30308@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
>
> Problem of possible cpus is the number can be very large on some arches,
> but yet few cpus online....
Actually that should be rare. Especially not very large compared to online.
The only case left is virtualization, but there the ratio of online
cores vs possible is not that large typically.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Andi Kleen @ 2009-11-11 21:47 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Frans Pop, linux-kernel, netdev
In-Reply-To: <81bfc67a0911111219m1efff30cr3186987f9dbb3d4d@mail.gmail.com>
Caleb Cushing <xenoterracide@gmail.com> writes:
>>
>> I'm attaching the bisection log and a 'good' dmesg output.
>>
>> c9fb3ded7a8a6769f3bcb3ef3d9aed61d3e376a9 is the first bad commit
Just gives fatal: bad object c9fb3ded7a8a6769f3bcb3ef3d9aed61d3e376a9
here on a standard Linus linux-2.6 tree.
It might be also useful if you could describe what kind
of network devices you use and how you determine
the packet loss.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH] [next-next-2.6] net: configurable device name hash
From: Octavian Purdila @ 2009-11-11 21:47 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20091111133342.1011e16a@nehalam>
On Wednesday 11 November 2009 23:33:42 you wrote:
> On Wed, 11 Nov 2009 12:42:35 -0800 (PST)
>
> David Miller <davem@davemloft.net> wrote:
> > From: Octavian Purdila <opurdila@ixiacom.com>
> > Date: Wed, 11 Nov 2009 21:38:44 +0200
> >
> > > I don't think we can dynamically size it at boot time since it
> > > depends on the usage pattern which is impossible to determine at
> > > boot time, right?
> >
> > We have no idea how many sockets will be used by the system yet we
> > dynamically size the socket hash tables.
> >
> > Please do some research and see how we handle this elsewhere in the
> > networking.
>
> dcache also sizes hash bits at boot time on available memory.
> See alloc_large_system_hash().
>
Thanks Stephen.
I was actually taking a look at that but I see that the device hash is
allocated per net namespace which means we can't use
alloc_large_system_hash().
We could use a similar function that will work in the per namespace
initialization context, but this might upset net namespace folks since we will
get a large hash for every namespace.
Not sure what can be done to address that problem now except using a boot
parameter to override the defaults. A better solution would be to be able to
use "namespace create" parameters but it appears we don't have this
possibility, yet.
^ permalink raw reply
* [PATCH] sctp: Set socket source address when additing first transport
From: Vlad Yasevich @ 2009-11-11 21:54 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-sctp, Vlad Yasevich
In-Reply-To: <1257879454-31661-1-git-send-email-vladislav.yasevich@hp.com>
Recent commits
sctp: Get rid of an extra routing lookup when adding a transport
and
sctp: Set source addresses on the association before adding transports
changed when routes are added to the sctp transports. As such,
we didn't set the socket source address correctly when adding the first
transport. The first transport is always the primary/active one, so
when adding it, set the socket source address. This was causing
regression failures in SCTP tests.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
---
net/sctp/transport.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/sctp/transport.c b/net/sctp/transport.c
index c256e48..3b141bb 100644
--- a/net/sctp/transport.c
+++ b/net/sctp/transport.c
@@ -308,7 +308,8 @@ void sctp_transport_route(struct sctp_transport *transport,
/* Initialize sk->sk_rcv_saddr, if the transport is the
* association's active path for getsockname().
*/
- if (asoc && (transport == asoc->peer.active_path))
+ if (asoc && (!asoc->peer.primary_path ||
+ (transport == asoc->peer.active_path)))
opt->pf->af->to_sk_saddr(&transport->saddr,
asoc->base.sk);
} else
--
1.6.0.4
^ permalink raw reply related
* Re: large packet loss take2 2.6.31.x
From: Frans Pop @ 2009-11-11 22:05 UTC (permalink / raw)
To: Andi Kleen; +Cc: Caleb Cushing, linux-kernel, netdev
In-Reply-To: <878wecka3g.fsf@basil.nowhere.org>
On Wednesday 11 November 2009, Andi Kleen wrote:
> Caleb Cushing <xenoterracide@gmail.com> writes:
> >> I'm attaching the bisection log and a 'good' dmesg output.
> >>
> >> c9fb3ded7a8a6769f3bcb3ef3d9aed61d3e376a9 is the first bad commit
>
> Just gives fatal: bad object c9fb3ded7a8a6769f3bcb3ef3d9aed61d3e376a9
> here on a standard Linus linux-2.6 tree.
Looks to be a commit from a stable update:
commit c9fb3ded7a8a6769f3bcb3ef3d9aed61d3e376a9
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Tue Sep 1 11:38:34 2009 -0400
usb-serial: change referencing of port and serial structures
commit 41bd34ddd7aa46dbc03b5bb33896e0fa8100fe7b upstream.
Cheers,
FJP
^ permalink raw reply
* [PATCH] netfilter: Should xt_osf_remove_callback() return negative on errors?
From: Roel Kluin @ 2009-11-11 22:33 UTC (permalink / raw)
To: Andrew Morton, LKML, Patrick McHardy, David S. Miller,
netfilter-devel
Return a negative error value
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
net/netfilter/xt_osf.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
It seems strange that an error return can be positive or
negative, is this maybe required?
diff --git a/net/netfilter/xt_osf.c b/net/netfilter/xt_osf.c
index 63e1905..4d1a41b 100644
--- a/net/netfilter/xt_osf.c
+++ b/net/netfilter/xt_osf.c
@@ -118,7 +118,7 @@ static int xt_osf_remove_callback(struct sock *ctnl, struct sk_buff *skb,
{
struct xt_osf_user_finger *f;
struct xt_osf_finger *sf;
- int err = ENOENT;
+ int err = -ENOENT;
if (!osf_attrs[OSF_ATTR_FINGER])
return -EINVAL;
^ permalink raw reply related
* Re: [PATCH] [next-next-2.6] net: configurable device name hash
From: Stephen Hemminger @ 2009-11-11 22:24 UTC (permalink / raw)
To: Octavian Purdila; +Cc: David Miller, netdev
In-Reply-To: <200911112347.41425.opurdila@ixiacom.com>
On Wed, 11 Nov 2009 23:47:41 +0200
Octavian Purdila <opurdila@ixiacom.com> wrote:
> On Wednesday 11 November 2009 23:33:42 you wrote:
> > On Wed, 11 Nov 2009 12:42:35 -0800 (PST)
> >
> > David Miller <davem@davemloft.net> wrote:
> > > From: Octavian Purdila <opurdila@ixiacom.com>
> > > Date: Wed, 11 Nov 2009 21:38:44 +0200
> > >
> > > > I don't think we can dynamically size it at boot time since it
> > > > depends on the usage pattern which is impossible to determine at
> > > > boot time, right?
> > >
> > > We have no idea how many sockets will be used by the system yet we
> > > dynamically size the socket hash tables.
> > >
> > > Please do some research and see how we handle this elsewhere in the
> > > networking.
> >
> > dcache also sizes hash bits at boot time on available memory.
> > See alloc_large_system_hash().
> >
>
> Thanks Stephen.
>
> I was actually taking a look at that but I see that the device hash is
> allocated per net namespace which means we can't use
> alloc_large_system_hash().
>
> We could use a similar function that will work in the per namespace
> initialization context, but this might upset net namespace folks since we will
> get a large hash for every namespace.
>
> Not sure what can be done to address that problem now except using a boot
> parameter to override the defaults. A better solution would be to be able to
> use "namespace create" parameters but it appears we don't have this
> possibility, yet.
>
Remember though that really hash sizes really don't buy that much more speed.
Going from 256 to 1024 gives a 4x benefit but with 10,000 devices that
just means scanning 10 vs. 40 names. It is not like the file system cache
where name lookup is a major component of overhead.
You can still use alloc_large_system_hash, but just constrain it to a maximum
of order 10 or something.
--
^ permalink raw reply
* Re: r8169: fix driver drop incoming packets >= 1515 if MTU is set between 1515 and 1536
From: Raimonds Cicans @ 2009-11-11 22:36 UTC (permalink / raw)
To: Ben Hutchings; +Cc: romieu, netdev
In-Reply-To: <1257970536.2839.73.camel@achroite.uk.solarflarecom.com>
Ben Hutchings:
> On Wed, 2009-11-11 at 22:05 +0200, Raimonds Cicans wrote:
>> Ben Hutchings:
>>> On Wed, 2009-11-11 at 20:20 +0200, Raimonds Cicans wrote:
>>>> Driver drop incoming packets >= 1515(1) if MTU is set between 1515(1) and 1536.
>>>>
>>>> 1) exact number depends on some factors:
>>>> - VLAN tagged or not
>>>> - patch "r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames"
>>>> applied or not
>>> [...]
>>>
>>> MTU is a limit on transmission; it is not required to limit received
>>> frames.
>> ???
>>
>> In r8169 driver MTU is used to calculate receive buffer size.
>> Receive buffer size is used to configure hardware incoming packet filter.
>>
>> For jumbo frames:
>> Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
>> (vlan header) + 4 (ethernet checksum) = MTU + 22
>>
>> Bug:
>> driver for all MTU up to 1536 use receive buffer size 1536
> [...]
>
> OK, now I understand. The subject line you used is not grammatical and
> I originally thought you considered it a bug that the driver might
> accept packets with payload greater than MTU.
Sorry for my poor English.
> To make it clear, perhaps you could change the subject to:
> 'r8169: Fix receive buffer length when MTU is between 1515 and 1536'
> and then explain the current behaviour below that.
Ok. I will try to make new version tomorrow.
Raimonds Cicans
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-11 22:48 UTC (permalink / raw)
To: Frans Pop; +Cc: Andi Kleen, linux-kernel, netdev
In-Reply-To: <200911112305.54824.elendil@planet.nl>
On Wed, Nov 11, 2009 at 5:05 PM, Frans Pop <elendil@planet.nl> wrote:
> On Wednesday 11 November 2009, Andi Kleen wrote:
>> Caleb Cushing <xenoterracide@gmail.com> writes:
>> >> I'm attaching the bisection log and a 'good' dmesg output.
>> >>
>> >> c9fb3ded7a8a6769f3bcb3ef3d9aed61d3e376a9 is the first bad commit
>>
>> Just gives fatal: bad object c9fb3ded7a8a6769f3bcb3ef3d9aed61d3e376a9
>> here on a standard Linus linux-2.6 tree.
>
> Looks to be a commit from a stable update:
>
> commit c9fb3ded7a8a6769f3bcb3ef3d9aed61d3e376a9
> Author: Alan Stern <stern@rowland.harvard.edu>
> Date: Tue Sep 1 11:38:34 2009 -0400
>
> usb-serial: change referencing of port and serial structures
>
> commit 41bd34ddd7aa46dbc03b5bb33896e0fa8100fe7b upstream.
>
> Cheers,
> FJP
>
yeah it is. it's from greg kroah-hartman's tree.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* [net-next PATCH 0/4] qlge: Fixes and clean up for qlge.
From: Ron Mercer @ 2009-11-11 22:54 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer
Two small fixes, one cleanup and a driver version change for qlge.
1) Remove frame route change in qlge_suspend(). This operation is now
done by the firmware.
2) Add asic reset to force known state at open().
3) Change module parameter to match qlge_xxx convention.
4) Change driver version.
^ permalink raw reply
* [net-next PATCH 2/4] qlge: Add asic reset to open call.
From: Ron Mercer @ 2009-11-11 22:54 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer
In-Reply-To: <1257980046-2420-1-git-send-email-ron.mercer@qlogic.com>
Force asic to known state at open().
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge_main.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index 2bfa783..d2a4bbe 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -3714,6 +3714,10 @@ static int qlge_open(struct net_device *ndev)
int err = 0;
struct ql_adapter *qdev = netdev_priv(ndev);
+ err = ql_adapter_reset(qdev);
+ if (err)
+ return err;
+
err = ql_configure_rings(qdev);
if (err)
return err;
--
1.6.0.2
^ permalink raw reply related
* [net-next PATCH 1/4] qlge: Do not change frame routing during suspend.
From: Ron Mercer @ 2009-11-11 22:54 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer
In-Reply-To: <1257980046-2420-1-git-send-email-ron.mercer@qlogic.com>
We do not need to change the frame routing to direct all frames to the
management fifo during suspend. This is now done by the firmware.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge_main.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index bd8e164..2bfa783 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -3514,9 +3514,6 @@ int ql_wol(struct ql_adapter *qdev)
}
if (qdev->wol) {
- /* Reroute all packets to Management Interface */
- ql_write32(qdev, MGMT_RCV_CFG, (MGMT_RCV_CFG_RM |
- (MGMT_RCV_CFG_RM << 16)));
wol |= MB_WOL_MODE_ON;
status = ql_mb_wol_mode(qdev, wol);
QPRINTK(qdev, DRV, ERR, "WOL %s (wol code 0x%x) on %s\n",
--
1.6.0.2
^ permalink raw reply related
* [net-next PATCH 4/4] qlge: Change version to v1.00.00.23.00.00-01.
From: Ron Mercer @ 2009-11-11 22:54 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer
In-Reply-To: <1257980046-2420-1-git-send-email-ron.mercer@qlogic.com>
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/qlge/qlge.h b/drivers/net/qlge/qlge.h
index 1f59f05..862c1aa 100644
--- a/drivers/net/qlge/qlge.h
+++ b/drivers/net/qlge/qlge.h
@@ -16,7 +16,7 @@
*/
#define DRV_NAME "qlge"
#define DRV_STRING "QLogic 10 Gigabit PCI-E Ethernet Driver "
-#define DRV_VERSION "v1.00.00-b3"
+#define DRV_VERSION "v1.00.00.23.00.00-01"
#define PFX "qlge: "
#define QPRINTK(qdev, nlevel, klevel, fmt, args...) \
--
1.6.0.2
^ permalink raw reply related
* [net-next PATCH 3/4] qlge: Clean up module parameter name.
From: Ron Mercer @ 2009-11-11 22:54 UTC (permalink / raw)
To: davem; +Cc: netdev, ron.mercer
In-Reply-To: <1257980046-2420-1-git-send-email-ron.mercer@qlogic.com>
Change it to match qlge_xxx convention.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
---
drivers/net/qlge/qlge_main.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
index d2a4bbe..e2ee47d 100644
--- a/drivers/net/qlge/qlge_main.c
+++ b/drivers/net/qlge/qlge_main.c
@@ -69,9 +69,9 @@ MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
#define MSIX_IRQ 0
#define MSI_IRQ 1
#define LEG_IRQ 2
-static int irq_type = MSIX_IRQ;
-module_param(irq_type, int, MSIX_IRQ);
-MODULE_PARM_DESC(irq_type, "0 = MSI-X, 1 = MSI, 2 = Legacy.");
+static int qlge_irq_type = MSIX_IRQ;
+module_param(qlge_irq_type, int, MSIX_IRQ);
+MODULE_PARM_DESC(qlge_irq_type, "0 = MSI-X, 1 = MSI, 2 = Legacy.");
static struct pci_device_id qlge_pci_tbl[] __devinitdata = {
{PCI_DEVICE(PCI_VENDOR_ID_QLOGIC, QLGE_DEVICE_ID_8012)},
@@ -2870,7 +2870,7 @@ static void ql_enable_msix(struct ql_adapter *qdev)
int i, err;
/* Get the MSIX vectors. */
- if (irq_type == MSIX_IRQ) {
+ if (qlge_irq_type == MSIX_IRQ) {
/* Try to alloc space for the msix struct,
* if it fails then go to MSI/legacy.
*/
@@ -2878,7 +2878,7 @@ static void ql_enable_msix(struct ql_adapter *qdev)
sizeof(struct msix_entry),
GFP_KERNEL);
if (!qdev->msi_x_entry) {
- irq_type = MSI_IRQ;
+ qlge_irq_type = MSI_IRQ;
goto msi;
}
@@ -2901,7 +2901,7 @@ static void ql_enable_msix(struct ql_adapter *qdev)
QPRINTK(qdev, IFUP, WARNING,
"MSI-X Enable failed, trying MSI.\n");
qdev->intr_count = 1;
- irq_type = MSI_IRQ;
+ qlge_irq_type = MSI_IRQ;
} else if (err == 0) {
set_bit(QL_MSIX_ENABLED, &qdev->flags);
QPRINTK(qdev, IFUP, INFO,
@@ -2912,7 +2912,7 @@ static void ql_enable_msix(struct ql_adapter *qdev)
}
msi:
qdev->intr_count = 1;
- if (irq_type == MSI_IRQ) {
+ if (qlge_irq_type == MSI_IRQ) {
if (!pci_enable_msi(qdev->pdev)) {
set_bit(QL_MSI_ENABLED, &qdev->flags);
QPRINTK(qdev, IFUP, INFO,
@@ -2920,7 +2920,7 @@ msi:
return;
}
}
- irq_type = LEG_IRQ;
+ qlge_irq_type = LEG_IRQ;
QPRINTK(qdev, IFUP, DEBUG, "Running with legacy interrupts.\n");
}
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH 2/2] rps: changes to bnx2x to get device hash
From: Matt Carlson @ 2009-11-11 23:21 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <65634d660911102253lbfc0927i4e4c0eba6d7d765d@mail.gmail.com>
On Tue, Nov 10, 2009 at 10:53:36PM -0800, Tom Herbert wrote:
> @@ -6223,9 +6257,10 @@ static int bnx2x_init_common(struct bnx2x *bp)
> bnx2x_init_block(bp, PBF_BLOCK, COMMON_STAGE);
>
> REG_WR(bp, SRC_REG_SOFT_RST, 1);
> - for (i = SRC_REG_KEYRSS0_0; i <= SRC_REG_KEYRSS1_9; i += 4) {
> - REG_WR(bp, i, 0xc0cac01a);
> - /* TODO: replace with something meaningful */
> + {
> + int i;
> + for (i = SRC_REG_KEYRSS0_0; i <= SRC_REG_KEYRSS1_9; i += 4)
> + REG_WR(bp, i, random32());
> }
> bnx2x_init_block(bp, SRCH_BLOCK, COMMON_STAGE);
> #ifdef BCM_CNIC
Is a random hash key really better than arbitrary static values?
Setting the hash key to random values means, from chip reset to chip
reset, you could get different performance results. Unless we
we understood how the key affects performance, I would think that
reproducable performance numbers would be more desirable, no?
^ permalink raw reply
* [PATCH] X25: Enable setting of cause and diagnostic fields
From: andrew hendry @ 2009-11-12 0:13 UTC (permalink / raw)
To: netdev, linux-x25; +Cc: linux-kernel
Adds SIOCX25SCAUSEDIAG, allowing X.25 programs to set the cause and
diagnostic fields.
Normally used to indicate status upon closing connections.
Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
diff -uprN -X a/Documentation/dontdiff a/include/linux/x25.h
b/include/linux/x25.h
--- a/include/linux/x25.h 2009-11-11 14:03:26.659663301 +1100
+++ b/include/linux/x25.h 2009-11-11 16:05:06.625958557 +1100
@@ -25,6 +25,7 @@
#define SIOCX25SENDCALLACCPT (SIOCPROTOPRIVATE + 9)
#define SIOCX25GDTEFACILITIES (SIOCPROTOPRIVATE + 10)
#define SIOCX25SDTEFACILITIES (SIOCPROTOPRIVATE + 11)
+#define SIOCX25SCAUSEDIAG (SIOCPROTOPRIVATE + 12)
/*
* Values for {get,set}sockopt.
diff -uprN -X a/Documentation/dontdiff a/net/x25/af_x25.c b/net/x25/af_x25.c
--- a/net/x25/af_x25.c 2009-11-11 14:02:44.027061001 +1100
+++ b/net/x25/af_x25.c 2009-11-11 16:22:51.374077963 +1100
@@ -1430,6 +1430,17 @@ static int x25_ioctl(struct socket *sock
break;
}
+ case SIOCX25SCAUSEDIAG: {
+ struct x25_causediag causediag;
+ rc = -EFAULT;
+ if (copy_from_user(&causediag, argp, sizeof(causediag)))
+ break;
+ x25->causediag = causediag;
+ rc = 0;
+ break;
+
+ }
+
case SIOCX25SCUDMATCHLEN: {
struct x25_subaddr sub_addr;
rc = -EINVAL;
diff -uprN -X a/Documentation/dontdiff a/net/x25/x25_subr.c b/net/x25/x25_subr.c
--- a/net/x25/x25_subr.c 2009-11-11 14:02:44.026061128 +1100
+++ b/net/x25/x25_subr.c 2009-11-11 16:28:30.316150252 +1100
@@ -225,6 +225,12 @@ void x25_write_internal(struct sock *sk,
break;
case X25_CLEAR_REQUEST:
+ dptr = skb_put(skb, 3);
+ *dptr++ = frametype;
+ *dptr++ = x25->causediag.cause;
+ *dptr++ = x25->causediag.diagnostic;
+ break;
+
case X25_RESET_REQUEST:
dptr = skb_put(skb, 3);
*dptr++ = frametype;
^ permalink raw reply
* [PATCH net-2.6] Revert "net: Support inclusion of <linux/socket.h> before <sys/socket.h>"
From: Ben Hutchings @ 2009-11-12 2:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, 538372
This reverts commit 9c501935a3cdcf6b1d35aaee3aa11c7a7051a305. That
commit caused <linux/rtnetlink.h> to require that <sys/socket.h> is
included first, breaking autoconf tests for <linux/rtnetlink.h> and
presumably some real programs too.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
Please apply this to net-2.6.
I'm not sure what the proper solution is; maybe make <linux/socket.h>
include <sys/socket.h> if __KERNEL__ is not defined?
Ben.
include/linux/socket.h | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 3273a0c..3b461df 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -16,7 +16,7 @@ struct __kernel_sockaddr_storage {
/* _SS_MAXSIZE value minus size of ss_family */
} __attribute__ ((aligned(_K_SS_ALIGNSIZE))); /* force desired alignment */
-#ifdef __KERNEL__
+#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
#include <asm/socket.h> /* arch-dependent defines */
#include <linux/sockios.h> /* the SIOCxxx I/O controls */
@@ -101,6 +101,21 @@ struct cmsghdr {
((char *)(cmsg) - (char *)(mhdr)->msg_control)))
/*
+ * This mess will go away with glibc
+ */
+
+#ifdef __KERNEL__
+#define __KINLINE static inline
+#elif defined(__GNUC__)
+#define __KINLINE static __inline__
+#elif defined(__cplusplus)
+#define __KINLINE static inline
+#else
+#define __KINLINE static
+#endif
+
+
+/*
* Get the next cmsg header
*
* PLEASE, do not touch this function. If you think, that it is
@@ -113,7 +128,7 @@ struct cmsghdr {
* ancillary object DATA. --ANK (980731)
*/
-static inline struct cmsghdr * __cmsg_nxthdr(void *__ctl, __kernel_size_t __size,
+__KINLINE struct cmsghdr * __cmsg_nxthdr(void *__ctl, __kernel_size_t __size,
struct cmsghdr *__cmsg)
{
struct cmsghdr * __ptr;
@@ -125,7 +140,7 @@ static inline struct cmsghdr * __cmsg_nxthdr(void *__ctl, __kernel_size_t __size
return __ptr;
}
-static inline struct cmsghdr * cmsg_nxthdr (struct msghdr *__msg, struct cmsghdr *__cmsg)
+__KINLINE struct cmsghdr * cmsg_nxthdr (struct msghdr *__msg, struct cmsghdr *__cmsg)
{
return __cmsg_nxthdr(__msg->msg_control, __msg->msg_controllen, __cmsg);
}
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCHv9 3/3] vhost_net: a kernel-level virtio server
From: Rusty Russell @ 2009-11-12 2:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, s.hetze, Daniel Walker, Eric Dumazet
In-Reply-To: <20091110113637.GB6989@redhat.com>
On Tue, 10 Nov 2009 10:06:37 pm Michael S. Tsirkin wrote:
> If tun is a module, vhost must be a module, too.
> If tun is built-in or disabled, vhost can be built-in.
I really like the brainbending :) Keeps readers on their toes...
Applied,
Rusty.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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