* Su dirección de correo electrónico ha ganado $ 1 millón de dólares en la final del año de concesión de subvenciones donación, enviar por correo a esta oficina para retreival o llame al +2348051809752.
From: FDV @ 2011-11-20 2:13 UTC (permalink / raw)
Your email address has won $1 million dollars in our end of year grant donation award, Mail back to this office for retreival or call +2348051809752.
^ permalink raw reply
* Re: [PATCH net-next 4/4] net: Add Open vSwitch kernel components.
From: John Fastabend @ 2011-11-20 4:55 UTC (permalink / raw)
To: Jesse Gross
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David S. Miller
In-Reply-To: <CAEP_g=8EpR_Z54ZvGZzFAeCVwVED3SUrddvLt7-aQ76Q919ekQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/19/2011 3:06 PM, Jesse Gross wrote:
> On Fri, Nov 18, 2011 at 9:30 PM, John Fastabend
> <john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> On 11/18/2011 3:12 PM, Jesse Gross wrote:
>>> + */
>>> +enum ovs_frag_type {
>>> + OVS_FRAG_TYPE_NONE,
>>> + OVS_FRAG_TYPE_FIRST,
>>> + OVS_FRAG_TYPE_LATER,
>>> + __OVS_FRAG_TYPE_MAX
>>> +};
>>> +
>>> +#define OVS_FRAG_TYPE_MAX (__OVS_FRAG_TYPE_MAX - 1)
>>> +
>>> +struct ovs_key_ethernet {
>>> + __u8 eth_src[6];
>>> + __u8 eth_dst[6];
>>> +};
>>> +
>>> +struct ovs_key_ipv4 {
>>> + __be32 ipv4_src;
>>> + __be32 ipv4_dst;
>>> + __u8 ipv4_proto;
>>> + __u8 ipv4_tos;
>>> + __u8 ipv4_ttl;
>>> + __u8 ipv4_frag; /* One of OVS_FRAG_TYPE_*. */
>>> +};
>>> +
>>> +struct ovs_key_ipv6 {
>>> + __be32 ipv6_src[4];
>>> + __be32 ipv6_dst[4];
>>> + __be32 ipv6_label; /* 20-bits in least-significant bits. */
>>> + __u8 ipv6_proto;
>>> + __u8 ipv6_tclass;
>>> + __u8 ipv6_hlimit;
>>> + __u8 ipv6_frag; /* One of OVS_FRAG_TYPE_*. */
>>> +};
>>> +
>>> +struct ovs_key_tcp {
>>> + __be16 tcp_src;
>>> + __be16 tcp_dst;
>>> +};
>>> +
>>> +struct ovs_key_udp {
>>> + __be16 udp_src;
>>> + __be16 udp_dst;
>>> +};
>>> +
>>> +struct ovs_key_icmp {
>>> + __u8 icmp_type;
>>> + __u8 icmp_code;
>>> +};
>>> +
>>> +struct ovs_key_icmpv6 {
>>> + __u8 icmpv6_type;
>>> + __u8 icmpv6_code;
>>> +};
>>> +
>>> +struct ovs_key_arp {
>>> + __be32 arp_sip;
>>> + __be32 arp_tip;
>>> + __be16 arp_op;
>>> + __u8 arp_sha[6];
>>> + __u8 arp_tha[6];
>>> +};
>>> +
>>> +struct ovs_key_nd {
>>> + __u32 nd_target[4];
>>> + __u8 nd_sll[6];
>>> + __u8 nd_tll[6];
>>> +};
>>> +
>>
>> We already have defines for many of these headers
>> struct arphdr {
>> __be16 ar_hrd; /* format of hardware address */
>> __be16 ar_pro; /* format of protocol address */
>> unsigned char ar_hln; /* length of hardware address */
>> unsigned char ar_pln; /* length of protocol address */
>> __be16 ar_op; /* ARP opcode (command) */
>>
>> #if 0
>> /*
>> * Ethernet looks like this : This bit is variable sized however...
>> */
>> unsigned char ar_sha[ETH_ALEN]; /* sender hardware address */
>> unsigned char ar_sip[4]; /* sender IP address */
>> unsigned char ar_tha[ETH_ALEN]; /* target hardware address */
>> unsigned char ar_tip[4]; /* target IP address */
>> #endif
>>
>> };
>>
>> Do we have to redefine them here?
>
> These aren't packet format definitions, they're keys for describing a
> flow to userspace. For example, they don't contain checksums or
> lengths because those vary on a per-packet basis.
OK thanks for explaining. I get it now, the other responses seem reasonable
as well.
Thanks,
John.
^ permalink raw reply
* [PATCH for 2.6.32 (untested)] netns: Add quota for number of NET_NS instances.
From: Tetsuo Handa @ 2011-11-20 7:22 UTC (permalink / raw)
To: ebiederm; +Cc: netdev
In order to solve below problems, can we add sysctl variable for
restricting number of NET_NS instances?
--------------------------------------------------
[PATCH for 2.6.32 (untested)] netns: Add quota for number of NET_NS instances.
CONFIG_NET_NS support in 2.6.32 has a problem that leads to OOM killer when
clone(CLONE_NEWNET) is called instantly.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/720095
But disabling CONFIG_NET_NS broke lxc containers.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/790863
This patch introduces /proc/sys/net/core/netns_max interface that limits
max number of network namespace instances.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
include/net/sock.h | 4 ++++
net/core/net_namespace.c | 9 +++++++++
net/core/sysctl_net_core.c | 10 ++++++++++
3 files changed, 23 insertions(+)
--- linux-2.6.32.48.orig/include/net/sock.h
+++ linux-2.6.32.48/include/net/sock.h
@@ -1598,4 +1598,8 @@ extern int sysctl_optmem_max;
extern __u32 sysctl_wmem_default;
extern __u32 sysctl_rmem_default;
+#ifdef CONFIG_NET_NS
+extern int max_netns_count;
+#endif
+
#endif /* _SOCK_H */
--- linux-2.6.32.48.orig/net/core/net_namespace.c
+++ linux-2.6.32.48/net/core/net_namespace.c
@@ -81,12 +81,18 @@ static struct net_generic *net_alloc_gen
#ifdef CONFIG_NET_NS
static struct kmem_cache *net_cachep;
static struct workqueue_struct *netns_wq;
+static atomic_t used_netns_count = ATOMIC_INIT(0);
+unsigned int max_netns_count;
static struct net *net_alloc(void)
{
struct net *net = NULL;
struct net_generic *ng;
+ atomic_inc(&used_netns_count);
+ if (atomic_read(&used_netns_count) > max_netns_count)
+ goto out;
+
ng = net_alloc_generic();
if (!ng)
goto out;
@@ -96,7 +102,9 @@ static struct net *net_alloc(void)
goto out_free;
rcu_assign_pointer(net->gen, ng);
+ return net;
out:
+ atomic_dec(&used_netns_count);
return net;
out_free:
@@ -115,6 +123,7 @@ static void net_free(struct net *net)
#endif
kfree(net->gen);
kmem_cache_free(net_cachep, net);
+ atomic_dec(&used_netns_count);
}
static struct net *net_create(void)
--- linux-2.6.32.48.orig/net/core/sysctl_net_core.c
+++ linux-2.6.32.48/net/core/sysctl_net_core.c
@@ -89,6 +89,16 @@ static struct ctl_table net_core_table[]
.mode = 0644,
.proc_handler = proc_dointvec
},
+#ifdef CONFIG_NET_NS
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "netns_max",
+ .data = &max_netns_count,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+#endif
#endif /* CONFIG_NET */
{
.ctl_name = NET_CORE_BUDGET,
^ permalink raw reply
* Re: [PATCH 5/5] tcp: skip cwnd moderation in TCP_CA_Open in tcp_try_to_open
From: Ilpo Järvinen @ 2011-11-20 8:38 UTC (permalink / raw)
To: Neal Cardwell
Cc: David Miller, Netdev, Nandita Dukkipati, Yuchung Cheng,
Tom Herbert
In-Reply-To: <CADVnQymPTWsD0Hx060qYUMrFPxgQPdJWwPA9oDce6qMVL4tVpA@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2230 bytes --]
On Sat, 19 Nov 2011, Neal Cardwell wrote:
> On Thu, Nov 17, 2011 at 12:14 AM, Ilpo Järvinen
> <ilpo.jarvinen@helsinki.fi> wrote:
>
> > I think it's intentional. Because of receiver lying bandwidth cheats all
> > unlimited undos are bit dangerous.
>
> If your concern is receivers lying, then there are other easy ways
> that a misbehaving receiver can get a sender to send too fast
> (e.g. cumulatively ACKing the highest sequence number seen,
> irrespective of holes). IMHO it would be a shame to penalize the vast
> majority of well-behaved users to plug one potential attack vector
> when there are other easy holes that an attacker would use.
I disagree... there is huge difference as the receiver then has to gamble
with the reliability of the flow. DSACK attack is nasty in that that it
allows maintaining reliability while cheating bw.
> > Wouldn't it be enough if tcp max burst is increased to match IW (iirc we
> > had 3 still there as a magic number)?
>
> Yes, tcp_max_burst() returns tp->reordering now. Changing it to return
> max(tp->reordering, TCP_INIT_CWND) sounds good to me. I think that's
> an excellent idea in any case, regardless of the outcome of this undo
> discussion.
Feel free to provide a patch then as I'm likely to forget :).
> However, I don't think this is sufficient for request-response
> protocols (e.g. RPC) running over long-lived connections over a path
> with a large bandwidth-delay product. In such cases, the cwnd will
> grow quite large (hundreds of packets). The DSACKs will often arrive
> after the entire response is sent, so that cwnd moderation will
> typically pull the cwnd down to 3 (or, with your proposal, 10)
> packets. IMHO that seems like an unnecessarily steep price to pay.
Sounds rather hypotetical scenario that you'd happen to get those DSACKs
in such scenario... DSACK would only be sent when receiver and sender were
out of sync due to heavy ACK loss that exceeds SACK redundancy or heavy
reordering... the later prevents large window in the first place (or
reordering has already adapted). Honestly I don't believe this is likely
scenario. ...And FRTO handles single unnecesary rexmit in case of spurious
RTO even before DSACK could be seen.
--
i.
^ permalink raw reply
* Meaning of "handle" when using tc filter ... flow hash
From: Andrew Beverley @ 2011-11-20 9:00 UTC (permalink / raw)
To: netdev
Hi,
I've been using the "flow hash keys" feature of tc to evenly distribute
bandwidth across client IP addresses.
In order to get it to work, I have to specify a "handle" value:
$TC filter add dev eth0 parent 4101: protocol ip \
handle 10 flow hash keys dst divisor 1024
^^^^
However, the handle doesn't seem to do anything. No matter what value I
specify, the rule works. If I leave it out, I get an "RTNETLINK answers:
Invalid argument" error.
I would normally expect the handle parameter to specify a netfilter mark
value. In this case though, it doesn't seem to make any difference. Is
there a reason that it needs to be specified?
Thanks,
Andy
^ permalink raw reply
* Re: [PATCH 5/5] tcp: skip cwnd moderation in TCP_CA_Open in tcp_try_to_open
From: Alexander Zimmermann @ 2011-11-20 10:19 UTC (permalink / raw)
To: Neal Cardwell
Cc: Ilpo Järvinen, David Miller, netdev, Nandita Dukkipati,
Yuchung Cheng, Tom Herbert, Carsten Wolff
In-Reply-To: <CADVnQymPTWsD0Hx060qYUMrFPxgQPdJWwPA9oDce6qMVL4tVpA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]
Hi Neal,
Am 19.11.2011 um 22:08 schrieb Neal Cardwell:
> On Thu, Nov 17, 2011 at 12:14 AM, Ilpo Järvinen
> <ilpo.jarvinen@helsinki.fi> wrote:
>
>> I think it's intentional. Because of receiver lying bandwidth cheats all
>> unlimited undos are bit dangerous.
>
> If your concern is receivers lying, then there are other easy ways
> that a misbehaving receiver can get a sender to send too fast
> (e.g. cumulatively ACKing the highest sequence number seen,
> irrespective of holes). IMHO it would be a shame to penalize the vast
> majority of well-behaved users to plug one potential attack vector
> when there are other easy holes that an attacker would use.
>
>> Wouldn't it be enough if tcp max burst is increased to match IW (iirc we
>> had 3 still there as a magic number)?
>
> Yes, tcp_max_burst() returns tp->reordering now. Changing it to return
> max(tp->reordering, TCP_INIT_CWND) sounds good to me. I think that's
> an excellent idea in any case, regardless of the outcome of this undo
> discussion.
For my Phd thesis - based on the Linux reordering detection we implemented
an adaptive Version of TCP-NCR (RFC 4653) - we change tcp_max_burst() to
return TCP_INIT_CWND. If the reordering delay is high, tp->reordering is
high as well, allowing to send a huge burst. In 2008 John Heffner* changed
tcp_max_burst() to return tp->reordering according to problem for reordering
on the reverse path. However, I never was be able to reproduce old problem...
Due to my experience I recommend to use TCP_INIT_CWND directly.
(*)http://git.kernel.org/linus/dd9e0dda66ba38a2ddd140 5ac279894260dc5c36.
>
> However, I don't think this is sufficient for request-response
> protocols (e.g. RPC) running over long-lived connections over a path
> with a large bandwidth-delay product. In such cases, the cwnd will
> grow quite large (hundreds of packets). The DSACKs will often arrive
> after the entire response is sent, so that cwnd moderation will
> typically pull the cwnd down to 3 (or, with your proposal, 10)
> packets. IMHO that seems like an unnecessarily steep price to pay.
>
> neal
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
^ permalink raw reply
* -C O N G R A T U L A T I O N S-
From: CARLSBERG MALAYSIA @ 2011-11-20 11:18 UTC (permalink / raw)
-C O N G R A T U L A T I O N S-
-CARLSBERG MALAYSIA 2011 AWARD-
-YOUR EMAIL HAS BEEN SELECTED & HAVE BEEN AWARDED $500,000.00 USD BY CARLSBERG MALAYSIA.
To Claim Your Prize, Immediately Contact:
Name: MR.FADIL BIN HASSAN
Email: carlsberg.claim@kimo.com
Phone: :+60164671274
Also Provide the Information below:
FULL NAME:.............
TELEPHONE:.............
COUNTRY/STATE:.........
Congratulations To You From CARLSBERG!
Regards,
Dato'Gamal Al sayeed Rumsah
^ permalink raw reply
* Just Read This
From: Barrister Peters Smith @ 2011-11-20 11:31 UTC (permalink / raw)
--
God bless you my friend,
I am Barrister Peters Smith, a layer and a Chattered Accountant by
profession.
I am working as External Accounts Auditor for the bank, Ziraat Bankasi
Bank here in Turkey.
A very large and abandoned sum amounting to 11,300,000.00 Million GBP,
about 19 million United States Dollars in this account for twelve years
I discovered recently. Now I just got your email address and contacted
you to apply as the next-of-kin to claim the entire 11.3 Million GBP
since the original owner is dead with his whole family. All the funds
will come to your by bank transfer after I process all the documents for
you. I wrote you since the late customer is from your country.
If you are interested then you should contact me on
barr.peters_smith2@yahoo.com or call; +44-70-4573-9682. Thank you I
will be waiting for you. This is no joking matter, if you do not want
it, then do not reply,and then the bank will send it to the Bank's
Treasury.
I will be waiting for you with more information and to proceed. Barr.
Peters Smith
^ permalink raw reply
* Re: [RFC][PATCH] Export all RA options that we don't handle to userspace
From: Pierre Ossman @ 2011-11-20 14:00 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI <yosh
Cc: netdev
In-Reply-To: <20110120091505.165737a1@mjolnir.ossman.eu>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
Reping!
On Thu, 20 Jan 2011 09:15:05 +0100
Pierre Ossman <pierre-list@ossman.eu> wrote:
> Ping!
>
> The userspace support is rather useless without these kernel bits...
>
> On Sun, 12 Dec 2010 14:47:06 +0100
> Pierre Ossman <pierre-list@ossman.eu> wrote:
>
> > Second patch that exports everything. If noone objects to this model,
> > then merge the two patches and just use the commit message from the
> > second one.
> >
> > Pros:
> > - Kernel doesn't need to be updated for every new RA option that might
> > show up.
> >
> > Cons:
> > - Possible security issue if it requires less privilege to read these
> > netlink messages than to open a raw ICMPv6 socket.
> > - List of types the kernel is interested in is now in two places in the
> > code, creating a risk for getting out of sync. I tried to come up
> > with a structure that would prevent this, but couldn't think of
> > anything that wouldn't require large changes. Ideas welcome...
> >
> > Rgds
>
>
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by FRA, a
Swedish intelligence agency. Make sure your server uses
encryption for SMTP traffic and consider using PGP for
end-to-end encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: change email address for shemminger
From: David Miller @ 2011-11-16 23:00 UTC (permalink / raw)
To: shemminger; +Cc: netdev, stable
In-Reply-To: <20111116145445.3313b826@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 16 Nov 2011 14:54:45 -0800
> My old email account at linux-foundation is no longer usable after
> the LF breakin.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/6 v4] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-11-20 16:30 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev, davem, chrisw, sri, dragos.tatulea, kvm, arnd, mst,
gregory.v.rose, mchan, dwang2, shemminger, eric.dumazet, kaber,
benve
In-Reply-To: <1321575301.2749.51.camel@bwh-desktop>
On 11/17/11 4:15 PM, "Ben Hutchings" <bhutchings@solarflare.com> wrote:
> Sorry to come to this rather late.
>
> On Tue, 2011-11-08 at 23:55 -0800, Roopa Prabhu wrote:
> [...]
>> v2 -> v3
>> - Moved set and get filter ops from rtnl_link_ops to netdev_ops
>> - Support for SRIOV VFs.
>> [Note: The get filters msg (in the way current get rtnetlink handles
>> it) might get too big for SRIOV vfs. This patch follows existing
>> sriov
>> vf get code and tries to accomodate filters for all VF's in a PF.
>> And for the SRIOV case I have only tested the fact that the VF
>> arguments are getting delivered to rtnetlink correctly. The code
>> follows existing sriov vf handling code so rest of it should work
>> fine]
> [...]
>
> This is already broken for large numbers of VFs, and increasing the
> amount of information per VF is going to make the situation worse. I am
> no netlink expert but I think that the current approach of bundling all
> information about an interface in a single message may not be
> sustainable.
Yes agreed. I have the same concern.
>
> Also, I'm unclear on why this interface is to be used to set filtering
> for the (PF) net device as well as for related VFs. Doesn't that
> duplicate the functionality of ndo_set_rx_mode and
> ndo_vlan_rx_{add,kill}_vid?
>
Yes..I have thought about this. But the reason the final version is the way
it is because its trying to accommodate sriov and non sriov cases because I
was just trying to make the netlink interface available to as many use cases
that might need it.
I just wanted to bring up the original intent of this patch.
Which was to add support for TUNSETTXFILTER to macvtap so that it can do
filtering instead of putting the lower dev (physical dev) in promiscuous
mode (This part really does not care if the lowerdev is an SRIOV VF or not).
And the focus was on macvlan passthru mode because it is the simplest case
to solve (you have to just pass the filters to lowerdev device/driver).
Now this may seem like It can be done with existing set_rx_mode/add_vlan_id
etc (which are essentially the mechanisms I am using in the macvlan driver
to send the filters to lowerdev for passthru mode), but it might not be the
case for other macvlan modes. Macvlan device might need to maintain and do a
filter lookup like the tap driver does today. And the only reason SRIOV came
up in the original patch was because PASSTHRU mode of macvlan was added for
SRIOV use case, though it really does not care if the lowerdev is an SRIOV
VF or not.
Instead of implementing TUNSETTXFILTER, michael had suggested netlink
interface instead.
When implementing the netlink interface, I did go back and forth in deciding
whether this should be on every netdev or only virtual devices that support
rtnl link ops. And the existence of set_rx_mode and add_vlan_id netdev ops
Was the reason for confusion. So the next version implemented it as rtnl
link ops because all I really want is a mechanism like TUNSETTXFILTER which
can set/get filters for virtual devices that need to do filtering by
themselves. But restricting this interface for only virtual devices did not
make great sense so when greg pointed it out that he will need it for VF
netdevs, I was happy to move it to netdev ops.
And the only reason this patch works on both PF and VF if the final version
is because, its trying to accommodate both SRIOV and non-SRIOV devices.
So by saying PF and VF, for me it really means SRIOV VF and any other netdev
devices. So I intentionally did not put PF or VF in the name of the op.
Thanks,
Roopa
^ permalink raw reply
* Re: [RFC][PATCH] Export all RA options that we don't handle to userspace
From: David Miller @ 2011-11-20 16:29 UTC (permalink / raw)
To: pierre-list; +Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <20111120150046.03c91963@mjolnir.ossman.eu>
From: Pierre Ossman <pierre-list@ossman.eu>
Date: Sun, 20 Nov 2011 15:00:46 +0100
> Reping!
You ping like this 1,000 times, it won't make anything happen.
Instead, you need to formally make fresh resubmission of the patch
you wish us to consider.
^ permalink raw reply
* Re: [PATCH 1/1] net/macb: add DT support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-11-20 16:47 UTC (permalink / raw)
To: Jamie Iles; +Cc: devicetree-discuss, netdev, Nicolas Ferre
In-Reply-To: <20111118155824.GA9981@totoro>
On 15:58 Fri 18 Nov , Jamie Iles wrote:
> Hi Jean-Christophe,
>
> On Fri, Nov 18, 2011 at 03:29:25PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > allow the DT to pass the mac address and the phy mode
> >
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > Cc: Jamie Iles <jamie@jamieiles.com>
> > Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> This looks OK to me in principle. I can't easily test this at the
> moment, but as I don't have a DT platform that has the clk framework up
> and running. A couple of nits/questions inline, but thanks for doing
> this!
>
> Jamie
>
> > ---
> > Documentation/devicetree/bindings/net/macb.txt | 22 ++++++++
> > drivers/net/ethernet/cadence/macb.c | 65 +++++++++++++++++++++---
> > drivers/net/ethernet/cadence/macb.h | 2 +
> > 3 files changed, 81 insertions(+), 8 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/net/macb.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
> > new file mode 100644
> > index 0000000..2b727ec
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/macb.txt
> > @@ -0,0 +1,22 @@
> > +* Cadence EMACB
> > +
> > +Implemeted on Atmel AT91 & AVR32 SoC
>
> I think something along the lines of "Binding for the Cadence MACB
> Ethernet controller" rather than listing specific parts might be
> clearer.
I prefer as we will have implementation detail in the binding
>
> > +
> > +Required properties:
> > +- compatible : Should be "atmel,macb" for Atmel
> > +- reg : Address and length of the register set for the device
> > +- interrupts : Should contain macb interrupt
> > +- phy-mode : String, operation mode of the PHY interface.
> > + Supported values are: "mii", "rmii",
> > +
> > +Optional properties:
> > +- local-mac-address : 6 bytes, mac address
> > +
> > +Examples:
> > +
> > + macb0: macb@fffc4000 {
>
> Rob pointed out to me a little while ago that the preferred naming from
> the ePAPR document would be:
>
> macb0: ethernet@fffc4000
>
> so it might be worth being consistent here.
ok
>
> > + compatible = "atmel,macb";
>
> This should be "cdns,macb" as it isn't Atmel specific. I believe cdns
> is the correct stock ticker symbol for Cadence.
here I put "atmel,macb" on purpose to specify the difference of the IP between
the soc, in fact it should have been atmel-at91,macb
>
> > + reg = <oxfffc4000 0x4000>;
> > + interrupts = <21>;
> > + phy-mode = "mii";
> > + };
> > diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> > index a437b46..2c345bc 100644
> > --- a/drivers/net/ethernet/cadence/macb.c
> > +++ b/drivers/net/ethernet/cadence/macb.c
> > @@ -20,6 +20,9 @@
> > #include <linux/etherdevice.h>
> > #include <linux/dma-mapping.h>
> > #include <linux/platform_device.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/of_net.h>
> > #include <linux/phy.h>
> >
> > #include <mach/board.h>
> > @@ -81,6 +84,20 @@ static void __init macb_get_hwaddr(struct macb *bp)
> > addr[4] = top & 0xff;
> > addr[5] = (top >> 8) & 0xff;
> >
> > +#ifdef CONFIG_OF
> > + /*
> > + * 2) from device tree data
> > + */
> > + if (!is_valid_ether_addr(addr)) {
> > + struct device_node *np = bp->pdev->dev.of_node;
> > + if (np) {
> > + const char *mac = of_get_mac_address(np);
> > + if (mac)
> > + memcpy(addr, mac, sizeof(addr));
> > + }
> > + }
> > +#endif
>
> I'm a bit conflicted here. I think we should always use the MAC address
> from the device tree if it is present even if the current MAC address is
> valid.
if the mac is already programmed in the register we just keep it
I prefer this way if the bootloader set it we keep it
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 1/1] net/macb: add DT support
From: Jamie Iles @ 2011-11-20 17:11 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Jamie Iles, devicetree-discuss, netdev, Nicolas Ferre
In-Reply-To: <20111120164740.GC21480@game.jcrosoft.org>
On Sun, Nov 20, 2011 at 05:47:40PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 15:58 Fri 18 Nov , Jamie Iles wrote:
> > Hi Jean-Christophe,
> >
> > On Fri, Nov 18, 2011 at 03:29:25PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > allow the DT to pass the mac address and the phy mode
> > >
> > > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > > Cc: Jamie Iles <jamie@jamieiles.com>
> > > Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> >
> > This looks OK to me in principle. I can't easily test this at the
> > moment, but as I don't have a DT platform that has the clk framework up
> > and running. A couple of nits/questions inline, but thanks for doing
> > this!
> >
> > Jamie
> >
> > > ---
> > > Documentation/devicetree/bindings/net/macb.txt | 22 ++++++++
> > > drivers/net/ethernet/cadence/macb.c | 65 +++++++++++++++++++++---
> > > drivers/net/ethernet/cadence/macb.h | 2 +
> > > 3 files changed, 81 insertions(+), 8 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/net/macb.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
> > > new file mode 100644
> > > index 0000000..2b727ec
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/net/macb.txt
> > > @@ -0,0 +1,22 @@
> > > +* Cadence EMACB
> > > +
> > > +Implemeted on Atmel AT91 & AVR32 SoC
> >
> > I think something along the lines of "Binding for the Cadence MACB
> > Ethernet controller" rather than listing specific parts might be
> > clearer.
> I prefer as we will have implementation detail in the binding
I can't see any Atmel specific implementation detail here though so lets
keep it generic for now. There isn't a benefit to keeping a list of
SoC's that the device is implemented in here as it'll only become out of
date. We need to make it easy for other vendors to reuse the binding +
driver.
> > > + compatible = "atmel,macb";
> >
> > This should be "cdns,macb" as it isn't Atmel specific. I believe cdns
> > is the correct stock ticker symbol for Cadence.
> here I put "atmel,macb" on purpose to specify the difference of the IP between
> the soc, in fact it should have been atmel-at91,macb
Well if we really can't detect the difference from the revision register
then we should have "cdns,macb" *and* "atmel,at91-macb" at least then
where platforms could claim compatibility as:
compatible = "atmel,at91-macb", "cdns,macb";
If we consider that another vendor integrates the Cadence IP, then it
makes much more sense to claim compatibility with a Cadence string
rather than an Atmel one...
> >
> > > + reg = <oxfffc4000 0x4000>;
> > > + interrupts = <21>;
> > > + phy-mode = "mii";
> > > + };
> > > diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> > > index a437b46..2c345bc 100644
> > > --- a/drivers/net/ethernet/cadence/macb.c
> > > +++ b/drivers/net/ethernet/cadence/macb.c
> > > @@ -20,6 +20,9 @@
> > > #include <linux/etherdevice.h>
> > > #include <linux/dma-mapping.h>
> > > #include <linux/platform_device.h>
> > > +#include <linux/of.h>
> > > +#include <linux/of_device.h>
> > > +#include <linux/of_net.h>
> > > #include <linux/phy.h>
> > >
> > > #include <mach/board.h>
> > > @@ -81,6 +84,20 @@ static void __init macb_get_hwaddr(struct macb *bp)
> > > addr[4] = top & 0xff;
> > > addr[5] = (top >> 8) & 0xff;
> > >
> > > +#ifdef CONFIG_OF
> > > + /*
> > > + * 2) from device tree data
> > > + */
> > > + if (!is_valid_ether_addr(addr)) {
> > > + struct device_node *np = bp->pdev->dev.of_node;
> > > + if (np) {
> > > + const char *mac = of_get_mac_address(np);
> > > + if (mac)
> > > + memcpy(addr, mac, sizeof(addr));
> > > + }
> > > + }
> > > +#endif
> >
> > I'm a bit conflicted here. I think we should always use the MAC address
> > from the device tree if it is present even if the current MAC address is
> > valid.
> if the mac is already programmed in the register we just keep it
> I prefer this way if the bootloader set it we keep it
But I don't think that makes sense - if there is a MAC address in the
DT, which is an optional property then the DT author must want to set
the MAC address from the DT. We should really prefer an explicit
assignment over an implicit one.
Jamie
^ permalink raw reply
* Re: skb->tstamp == 0.00000 ?
From: Oliver Hartkopp @ 2011-11-20 17:15 UTC (permalink / raw)
To: Felipe Dias; +Cc: netdev
In-Reply-To: <CAJX4=r1nz4Wq00tmJKUsJNLb41Bh4=-V1ixLcS05mXm0tpek9g@mail.gmail.com>
On 19.11.2011 22:18, Felipe Dias wrote:
> Hi..
>
> Please let me know if this isnt right list to this kind of question.
>
> I'm registering a new protocol handler with dev_add_pack. I would like
> to know only the difference between timestamp on skb->tstamp and the
> time of reception by my module.
Hello Felipe,
tstamp is a ktime_t type, which is a timestamp in nanosecs
http://lxr.linux.no/#linux+v3.1.1/include/linux/ktime.h#L28
The value in the skbuff
http://lxr.linux.no/#linux+v3.1.1/include/linux/skbuff.h#L347
is usually set at PDU reception time -> see netif_rx().
http://lxr.linux.no/#linux+v3.1.1/net/core/dev.c#L2879
where net_timestamp_check(skb) is executed which usually sets the timestamp
when timestamping is activated.
So when your netdevice creates a proper skbuff (e.g. using skb_alloc) the
timestamp is set to zero and therefore set to the receive time in
net_timestamp_check().
>
> So I do:
> ----
> struct timeval time_skb, time_module;
> do_gettimeofday(&time_module):
> skb_get_timestamp(skb, &time_skb);
> ---
>
> And time_skb.tv_sec and time_skb.tv_usec are equal to 0;
>
> I'm doing some wrong ?
Hm, i don't see, why you convert ktime_t to timeval.
You better work on skb->tstamp with the ktime functions directly, e.g. with
skb_get_ktime().
I hope this gives you a bit more insight in skb->tstamp - even if i don't know
your problem in detail %-)
Regards,
Oliver
^ permalink raw reply
* [bug] af_unix: Reading from a stream socket may lock the concurrent poll() call
From: Alexey Moiseytsev @ 2011-11-20 20:19 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, mtk.manpages, linux-man
Hello,
The following program shows how the poll() call hangs on a non-empty
stream socket.
#include <sys/types.h>
#include <sys/socket.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <poll.h>
int sockets[2];
int poll_socket(void) {
struct pollfd pfd = {
.fd = sockets[1],
.events = POLLIN
};
return poll(&pfd, 1, -1);
}
/* observer routine doesn't modify amount of data available in the
socket buffer */
void* observer(void* arg) {
char buffer;
for (int j = 0; j < 2000; j++) {
recv(sockets[1], &buffer, sizeof(buffer), MSG_PEEK);
sched_yield();
}
return NULL;
}
int main(void) {
if (socketpair(PF_UNIX, SOCK_STREAM, 0, sockets) == -1)
return 1;
int rc, data[250] = {0};
if ((rc = send(sockets[0], &data, sizeof(data), MSG_DONTWAIT)) <= 0)
return 2;
poll_socket();
/* If the first poll_socket() call didn't hang then the following
message will be printed */
fprintf(stderr, "%d bytes available in input buffer\n", rc);
pthread_t observer_thread;
pthread_create(&observer_thread, NULL, observer, NULL);
for (int j = 0; j < 20000; j++) {
/* If the first poll_socket() call didn't hang then all the following
calls should do the same */
poll_socket();
}
fprintf(stderr, "Well done\n");
pthread_join(observer_thread, NULL);
close(sockets[0]);
close(sockets[1]);
return 0;
}
Expected output: two lines or nothing (in case of error).
Observed output: only the first line (and the process never exits).
So the first poll() said that there is some data available in the
socket. And one of the following poll() said that there is no data
available in the socket. But this is false because the observer thread
didn't actually consume any data from then socket.
I assume that this bug can be eliminated by adding
sk->sk_data_ready(...) call right after each call to
skb_queue_head(..) in the unix_stream_recvmsg(...) routine
(net/unix/af_unix.c)
Other info:
$ uname -srmo
Linux 2.6.32-5-amd64 x86_64 GNU/Linux
--
Alexey
^ permalink raw reply
* Re: [bug] af_unix: Reading from a stream socket may lock the concurrent poll() call
From: David Miller @ 2011-11-20 20:31 UTC (permalink / raw)
To: himeraster-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAHjqzy7dhqi22yPJX=DP4x916hVXDY2WaDbdmnTEQ54n6qpMXw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Alexey Moiseytsev <himeraster-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 21 Nov 2011 00:19:02 +0400
> Other info:
> $ uname -srmo
> Linux 2.6.32-5-amd64 x86_64 GNU/Linux
There have been numerous AF_UNIX bug fixes since that release, please try
to reproduce your problem with current kernels.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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
* [GIT] Networking
From: David Miller @ 2011-11-20 20:33 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
It's been about two weeks since the last batch of networking fixes.
The majority is driver stuff, as is usually the case.
Some small corrections here and there for the drivers/net/
rearrangement. And then the usual collection of fixes for core crashes
and misbehaviors.
1) Kill references to removed NET_ETHERNET kconfig variable, this was removed
during Jeff Kirsher's drivers/net/ rearrangement during this merge window.
2) Revert L2CAP connection establishment change as it causes regressions,
from Arek Lichwa.
3) Bluetooth's l2cap_set_timer() expects timeouts in miliseconds, but callers
were not adjusted correctly. Fix from Andrzej Kaczmarek.
4) pm_schedule_suspend() in r8169 needs an increased delay parameter in order
to handle all cases properly, from Hayes Wang.
5) IPV6 must drop all packets using a multicast source address, fix from
Brian Haley.
6) NET_IP_ALIGN is not a fixed vlaue, but the smsc75xx USB driver treated it
as such. It wants to use a fixed value of '2' so create and use a local
macro in this driver to achieve that. From Nico Erfurth.
7) l2tp_udp_recv_core() needs to sample skb->data after any potential header
reallocation, otherwise we could be referencing free'd up data. Fix
from Eric Dumazet.
8) Don't accidently report a negative PMTU expire time in rt_fill_info(), fix
from Steffen Klassert.
9) Wireless connection monitor can race with suspend, cancel the monitor work
earlier in STA quiesce to avoid the problem. Fix from Johannes Berg.
10) TEMAC driver enables interrupts before the chip is fully programmed and
ready, fix from Ricardo Ribalda.
11) IPSEC AH code doesn't propagate error codes correctly, breaking things
when using async crypto hashing. Fixes from Nick Bowler.
12) Fix crash when using RF kill to disable the radio in iwlwifi, from
Emmanuel Grumbach.
13) ipv6 tunnel driver doesn't record the right device name in it's
parameters due to how the driver now makes use of register_netdevice()
to take care of what explicit calls to dev_alloc_name() use to do.
Fix by copying out the name at a later point in time, from Josh Boyer.
14) Bridge needs to take ->multicast_lock with softirq disabled in order
to avoid deadlocks, fix from Andrey Vagin.
15) IPV6 has a completely seperate type-of-service value it maintains, so we
need to report this using a seperate netlink attribute alongsize ipv4's TOS
in the socket dumping code. Fix from Maciej Żenczyowski.
16) Missing includes lead to compiler error of MIPS lantiq driver.
From John Crispin.
17) A set of bug fixes to the long maligned and not well maintained ASIX
driver from Grant Grundler. The good news is that the vendor is working
together with Grant and others to get this driver back into well-maintained
shape.
18) The "missing bh_unlock_sock()" fix in tcp_v4_syn_recv_sock() was not
complete, timers could be running too so we have to kill those off as
well otherwise we crash. Fix from Eric Dumazet, tested by Simon Kirby
who could reproduce these timer crashes.
19) Partial checksums aren't adjusted corrected after pulling the ipv6
multicast headers in the bridging code. Fix from Stephen Hemminger
and tested by Martin Volf.
20) r6040 uses "&&" instead of "&" in bitwise test, fix from Florian Fainelli.
21) SKY2 bug fixes from Stephen Hemminger, in particular failed shutdowns should
be fixed now.
22) stmmac timeout loop depends upon the time it takes readl() to occur, use
a proper mdelay() instead. Fix from Francesco Virlinzi.
23) stmmac cannot take the priv->lock in stmmac_ioctl()'s PHY layer calls,
because those sleep. Thankfully the priv->lock isn't actually needed
here, so simply stop taking it. Fix from Srinivas Kandagatla.
24) f_phonet driver appends page to the wrong SKB fragment slot, fix from
Rémi Denis-Courmont.
25) ICMP redirect in ipv4 were not propagating properly into all existing
routing cache entries. Flavio Leitner earlier tried to cure this problem
but his fix turned out to be insufficient. From Eric Dumazet.
Please pull, thanks a lot!
The following changes since commit a767835f6dc85277e40fbfe69a29c18817d6c00b:
Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (2011-11-19 10:56:01 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
Amitkumar Karwar (1):
mwifiex: fix association issue with AP configured in hidden SSID mode
Andrey Vagin (1):
bridge: Fix potential deadlock on br->multicast_lock
Andrzej Kaczmarek (1):
Bluetooth: Use miliseconds for L2CAP channel timeouts
Arek Lichwa (1):
Bluetooth: Revert: Fix L2CAP connection establishment
Arend van Spriel (1):
brcm80211: smac: eliminate a null pointer dereference in dma.c
Brian Haley (1):
ipv6: drop packets when source address is multicast
Christian Borntraeger (1):
qeth: remove WARN_ON leftover
David S. Miller (4):
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
net: Fix references to deleted NET_ETHERNET Kconfig setting.
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
Dmitry Kravkov (1):
bnx2x: cache-in compressed fw image
Einar Lueck (1):
qeth: Reduce CPU consumption through less SIGA-r calls
Eliad Peller (1):
mac80211: use min rate as basic rate for buggy APs
Emmanuel Grumbach (1):
iwlwifi: avoid a panic when unloading the module with RF Kill
Eric Dumazet (5):
l2tp: fix l2tp_udp_recv_core()
net: min_pmtu default is 552
tcp: clear xmit timers in tcp_v4_syn_recv_sock()
ping: dont increment ICMP_MIB_INERRORS
ipv4: fix redirect handling
Eyal Shapira (1):
wl12xx: fix wl12xx_scan_sched_scan_ssid_list() check that all given ssids are in filters
Feng King (1):
tcp: Fix comments for Nagle algorithm
Florian Fainelli (1):
r6040: fix check against MCRO_HASHEN bit in r6040_multicast_list
Francesco Virlinzi (2):
stmmac: use mdelay on timeout of sw reset
stmmac: fix pm functions avoiding sleep on spinlock
Frank Blaschka (1):
qeth: l3 fix rcu splat in xmit
Gertjan van Wingerde (2):
rt2x00: Add USB device ID of Buffalo WLI-UC-GNHP.
rt2x00: Fix sleep-while-atomic bug in powersaving code.
Giuseppe CAVALLARO (1):
stmmac: parameters auto-tuning through HW cap reg
Grant Grundler (5):
net-next:asix:PHY_MODE_RTL8211CL should be 0xC
net-next:asix:poll in asix_get_phyid in case phy not ready
net-next:asix: reduce AX88772 init time by about 2 seconds
net-next:asix: V2 more fixes for ax88178 phy init sequence
net-next:asix: V2 Update VERSION
Helmut Schaa (1):
ath: Fix NULL ptr dereference in ath_reg_apply_world_flags
Janusz.Dziedzic@tieto.com (1):
mac80211: uAPSD - fix IEEE80211_FCTL_MOREDATA bit setting
Jean-Christophe PLAGNIOL-VILLARD (1):
net/cadence: enable by default NET_ATMEL
Jesper Juhl (4):
net, wireless, mwifiex: Fix mem leak in mwifiex_update_curr_bss_params()
net/packet: remove dead code and unneeded variable from prb_setup_retire_blk_timer()
net/packet: Revert incorrect dead-code changes to prb_setup_retire_blk_timer
Net, libertas: Resolve memory leak in if_spi_host_to_card()
Joe Perches (1):
pch_gbe: Move #include of module.h
Johannes Berg (7):
nl80211: fix HT capability attribute validation
cfg80211: allow setting TXQ parameters only in AP mode
cfg80211: fix cmp_ies
cfg80211: fix missing kernel-doc
mac80211: fix NULL dereference in radiotap code
mac80211: fix bug in ieee80211_build_probe_req
mac80211: fix race between connection monitor & suspend
John Crispin (1):
NET: MIPS: lantiq: fix etop compile error
John W. Linville (4):
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth
Merge branch 'master' of ssh://ra.kernel.org/.../linville/wireless into for-davem
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Josh Boyer (1):
ip6_tunnel: copy parms.name after register_netdevice
Li Wei (1):
ipv4: fix for ip_options_rcv_srr() daddr update.
Luis R. Rodriguez (1):
cfg80211: fix bug on regulatory core exit on access to last_request
Maciej Żenczykowski (1):
net-netlink: Add a new attribute to expose TCLASS values via netlink
Mark Kamichoff (1):
net/usb: Misc. fixes for the LG-VL600 LTE USB modem
Nick Bowler (3):
ah: Correctly pass error codes in ahash output callback.
ah: Read nexthdr value before overwriting it in ahash input callback.
ah: Don't return NET_XMIT_DROP on input.
Nico Erfurth (1):
Fix incorrect usage of NET_IP_ALIGN
Paul Bolle (2):
net: drivers/net/hippi/Kconfig should be sourced
rds: drop "select LLIST"
Rafał Miłecki (2):
b43: fill ctl1 word on all newer PHYs, fix PHY errors
b43: HT-PHY: report signal to mac80211
Ricardo Ribalda (2):
net/temac: FIX segfault when process old irqs
net/ll_temac: FIX : Wait for indirect wait to end
Robert Marklund (1):
net/smsc911x: Always wait for the chip to be ready
Rémi Denis-Courmont (1):
f_phonet: fix page offset of first received fragment
Srinivas Kandagatla (2):
stmmac: fix advertising 1000Base capabilties for non GMII iface
stmmac: remove spin_lock in stmmac_ioctl.
Steffen Klassert (1):
ipv4: Fix inetpeer expire time information
Stephen Hemminger (1):
MAINTAINERS: change email address for shemminger
Steven Miao (1):
wireless: libertas: fix unaligned le64 accesses
Ursula Braun (2):
qeth: return with -EPERM if sniffing is not enabled
netiucv: reinsert dev_alloc_name for device naming
Veaceslav Falico (1):
bonding: Don't allow mode change via sysfs with slaves present
Wen-chien Jesse Sung (1):
Bluetooth: Add support for Broadcom BCM20702A0
Yevgeny Petrilin (1):
mlx4_en: Remove FCS bytes from packet length.
david decotigny (1):
forcedeth: fix stats on hardware without extended stats support
hayeswang (1):
r8169: increase the delay parameter of pm_schedule_suspend
oftedal (1):
sunhme: Allow usage on SBI based SBus systems
stephen hemminger (9):
bridge: correct IPv6 checksum after pull
sky2: fix hang on shutdown (and other irq issues)
sky2: pci posting issues
sky2: rename up/down functions
sky2: reduce default Tx ring size
sky2: used fixed RSS key
sky2: version 1.30
sky2: enforce minimum ring size
sky2: fix hang in napi_disable
Documentation/networking/ip-sysctl.txt | 2 +-
MAINTAINERS | 6 +-
arch/cris/arch-v10/drivers/Kconfig | 2 +-
arch/cris/arch-v32/drivers/Kconfig | 2 +-
drivers/bluetooth/btusb.c | 3 +
drivers/net/Kconfig | 2 +
drivers/net/bonding/bond_sysfs.c | 7 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 50 +++++----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 15 +--
drivers/net/ethernet/cadence/Kconfig | 1 +
drivers/net/ethernet/lantiq_etop.c | 2 +
drivers/net/ethernet/marvell/sky2.c | 106 +++++++++++------
drivers/net/ethernet/marvell/sky2.h | 1 +
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +-
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 +
drivers/net/ethernet/nvidia/forcedeth.c | 36 +++++--
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_param.c | 2 +-
drivers/net/ethernet/rdc/r6040.c | 2 +-
drivers/net/ethernet/realtek/r8169.c | 2 +-
drivers/net/ethernet/smsc/smsc911x.c | 12 ++
.../net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 3 +-
drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 +-
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 6 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 117 ++++++++++++-------
drivers/net/ethernet/sun/sunhme.c | 2 +-
drivers/net/ethernet/xilinx/ll_temac_main.c | 7 +-
drivers/net/hippi/Kconfig | 2 +-
drivers/net/usb/asix.c | 68 +++++++++---
drivers/net/usb/cdc_ether.c | 2 +-
drivers/net/usb/lg-vl600.c | 25 ++---
drivers/net/usb/smsc75xx.c | 7 +-
drivers/net/wireless/ath/regd.c | 2 +
drivers/net/wireless/b43/xmit.c | 15 ++-
drivers/net/wireless/b43/xmit.h | 16 +++-
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 33 +++---
drivers/net/wireless/libertas/cfg.c | 2 +-
drivers/net/wireless/libertas/if_spi.c | 1 +
drivers/net/wireless/mwifiex/scan.c | 9 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
drivers/net/wireless/rt2x00/rt2x00.h | 1 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 22 ++++-
drivers/net/wireless/wl12xx/scan.c | 2 +-
drivers/s390/net/Kconfig | 2 +-
drivers/s390/net/lcs.c | 6 +-
drivers/s390/net/netiucv.c | 2 +
drivers/s390/net/qeth_core.h | 3 +-
drivers/s390/net/qeth_core_main.c | 1 -
drivers/s390/net/qeth_l3_main.c | 7 +
drivers/s390/net/qeth_l3_sys.c | 4 +-
drivers/usb/gadget/f_phonet.c | 2 +-
include/linux/inet_diag.h | 3 +-
include/net/bluetooth/l2cap.h | 7 +-
include/net/cfg80211.h | 4 +
net/bluetooth/hci_conn.c | 2 +-
net/bluetooth/l2cap_core.c | 16 ++--
net/bridge/br_multicast.c | 6 +-
net/ipv4/ah4.c | 8 +-
net/ipv4/inet_diag.c | 4 +-
net/ipv4/ip_options.c | 1 +
net/ipv4/ping.c | 2 -
net/ipv4/route.c | 120 +++++++++++---------
net/ipv4/tcp_ipv4.c | 1 +
net/ipv4/tcp_output.c | 2 +-
net/ipv6/ah6.c | 8 +-
net/ipv6/ip6_input.c | 8 ++
net/ipv6/ip6_tunnel.c | 8 +-
net/l2tp/l2tp_core.c | 8 +-
net/mac80211/mlme.c | 21 ++++-
net/mac80211/rx.c | 9 +-
net/mac80211/sta_info.c | 8 +-
net/mac80211/util.c | 4 +
net/rds/Kconfig | 1 -
net/wireless/nl80211.c | 9 +-
net/wireless/reg.c | 3 +
net/wireless/scan.c | 13 ++-
77 files changed, 604 insertions(+), 312 deletions(-)
^ permalink raw reply
* [PATCH] net, sja1000: Don't include version.h in peak_pci.c when not needed
From: Jesper Juhl @ 2011-11-20 21:07 UTC (permalink / raw)
To: linux-can, netdev
Cc: linux-kernel, Marc Kleine-Budde, David S. Miller,
Wolfgang Grandegger
It was pointed out by "make versioncheck" that we do not need to include
version.h in drivers/net/can/sja1000/peak_pci.c
This patch removes the unneeded include.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/can/sja1000/peak_pci.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
note: patch is compile tested only.
diff --git a/drivers/net/can/sja1000/peak_pci.c b/drivers/net/can/sja1000/peak_pci.c
index 905bce0..2c7f503 100644
--- a/drivers/net/can/sja1000/peak_pci.c
+++ b/drivers/net/can/sja1000/peak_pci.c
@@ -20,7 +20,6 @@
*/
#include <linux/kernel.h>
-#include <linux/version.h>
#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/netdevice.h>
--
1.7.7.3
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH V2] Add ethtool to mii advertisment conversion helpers
From: Eric Dumazet @ 2011-11-20 21:11 UTC (permalink / raw)
To: David Miller; +Cc: mcarlson, netdev, mchan
In-Reply-To: <20111116.184032.1176336205445892405.davem@davemloft.net>
Le mercredi 16 novembre 2011 à 18:40 -0500, David Miller a écrit :
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Wed, 16 Nov 2011 15:27:37 -0800
>
> > Translating between ethtool advertisement settings and MII
> > advertisements are common operations for ethernet drivers. This patch
> > adds a set of helper functions that implements the conversion. The
> > patch then modifies a couple of the drivers to use the new functions.
> >
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> Looks better, applied, thanks :)
For an unknown reason I had to revert this commit to make my tg3 working
again on my laptop connected with a cross cable to one IGB NIC.
Before my revert, link was constantly flapping
(Should be running at 1000Mbps, full duplex)
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755M Gigabit Ethernet PCI Express (rev 02)
Subsystem: Dell Device 01f9
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 45
Region 0: Memory at f1ef0000 (64-bit, non-prefetchable) [size=64K]
Expansion ROM at <ignored> [disabled]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
Product Name: Broadcom NetXtreme Gigabit Ethernet Controller
Read-only fields:
[PN] Part number: BCM95755m
[EC] Engineering changes: 01f9.004
[SN] Serial number: 0123456789
[MN] Manufacture ID: 31 34 65 34
[RV] Reserved: checksum good, 28 byte(s) reserved
Read/write fields:
[YA] Asset tag: XYZ01234567
[RW] Read-write area: 107 byte(s) free
End
Capabilities: [58] Vendor Specific Information: Len=78 <?>
Capabilities: [e8] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41b1
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP+ BadDLLP+ Rollover- Timeout+ NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 0e, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-21-70-ff-fe-b0-e4-89
Capabilities: [16c v1] Power Budgeting <?>
Kernel driver in use: tg3
Kernel modules: tg3
For reference, the revert on tg3 :
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 024ca1d..365cd47 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -3594,7 +3594,15 @@ static int tg3_phy_autoneg_cfg(struct tg3 *tp, u32 advertise, u32 flowctrl)
u32 val, new_adv;
new_adv = ADVERTISE_CSMA;
- new_adv |= ethtool_adv_to_mii_100bt(advertise);
+ if (advertise & ADVERTISED_10baseT_Half)
+ new_adv |= ADVERTISE_10HALF;
+ if (advertise & ADVERTISED_10baseT_Full)
+ new_adv |= ADVERTISE_10FULL;
+ if (advertise & ADVERTISED_100baseT_Half)
+ new_adv |= ADVERTISE_100HALF;
+ if (advertise & ADVERTISED_100baseT_Full)
+ new_adv |= ADVERTISE_100FULL;
+
new_adv |= tg3_advert_flowctrl_1000T(flowctrl);
err = tg3_writephy(tp, MII_ADVERTISE, new_adv);
@@ -3604,7 +3612,11 @@ static int tg3_phy_autoneg_cfg(struct tg3 *tp, u32 advertise, u32 flowctrl)
if (tp->phy_flags & TG3_PHYFLG_10_100_ONLY)
goto done;
- new_adv = ethtool_adv_to_mii_1000T(advertise);
+ new_adv = 0;
+ if (advertise & ADVERTISED_1000baseT_Half)
+ new_adv |= ADVERTISE_1000HALF;
+ if (advertise & ADVERTISED_1000baseT_Full)
+ new_adv |= ADVERTISE_1000FULL;
if (tp->pci_chip_rev_id == CHIPREV_ID_5701_A0 ||
tp->pci_chip_rev_id == CHIPREV_ID_5701_B0)
@@ -3778,7 +3790,14 @@ static int tg3_copper_is_advertising_all(struct tg3 *tp, u32 mask)
{
u32 adv_reg, all_mask = 0;
- all_mask = ethtool_adv_to_mii_100bt(mask);
+ if (mask & ADVERTISED_10baseT_Half)
+ all_mask |= ADVERTISE_10HALF;
+ if (mask & ADVERTISED_10baseT_Full)
+ all_mask |= ADVERTISE_10FULL;
+ if (mask & ADVERTISED_100baseT_Half)
+ all_mask |= ADVERTISE_100HALF;
+ if (mask & ADVERTISED_100baseT_Full)
+ all_mask |= ADVERTISE_100FULL;
if (tg3_readphy(tp, MII_ADVERTISE, &adv_reg))
return 0;
@@ -3789,7 +3808,11 @@ static int tg3_copper_is_advertising_all(struct tg3 *tp, u32 mask)
if (!(tp->phy_flags & TG3_PHYFLG_10_100_ONLY)) {
u32 tg3_ctrl;
- all_mask = ethtool_adv_to_mii_1000T(mask);
+ all_mask = 0;
+ if (mask & ADVERTISED_1000baseT_Half)
+ all_mask |= ADVERTISE_1000HALF;
+ if (mask & ADVERTISED_1000baseT_Full)
+ all_mask |= ADVERTISE_1000FULL;
if (tg3_readphy(tp, MII_CTRL1000, &tg3_ctrl))
return 0;
@@ -4880,19 +4903,23 @@ static int tg3_setup_fiber_mii_phy(struct tg3 *tp, int force_reset)
(tp->phy_flags & TG3_PHYFLG_PARALLEL_DETECT)) {
/* do nothing, just check for link up at the end */
} else if (tp->link_config.autoneg == AUTONEG_ENABLE) {
- u32 adv, newadv;
+ u32 adv, new_adv;
err |= tg3_readphy(tp, MII_ADVERTISE, &adv);
- newadv = adv & ~(ADVERTISE_1000XFULL | ADVERTISE_1000XHALF |
- ADVERTISE_1000XPAUSE |
- ADVERTISE_1000XPSE_ASYM |
- ADVERTISE_SLCT);
+ new_adv = adv & ~(ADVERTISE_1000XFULL | ADVERTISE_1000XHALF |
+ ADVERTISE_1000XPAUSE |
+ ADVERTISE_1000XPSE_ASYM |
+ ADVERTISE_SLCT);
+
+ new_adv |= tg3_advert_flowctrl_1000X(tp->link_config.flowctrl);
- newadv |= tg3_advert_flowctrl_1000X(tp->link_config.flowctrl);
- newadv |= ethtool_adv_to_mii_1000X(tp->link_config.advertising);
+ if (tp->link_config.advertising & ADVERTISED_1000baseT_Half)
+ new_adv |= ADVERTISE_1000XHALF;
+ if (tp->link_config.advertising & ADVERTISED_1000baseT_Full)
+ new_adv |= ADVERTISE_1000XFULL;
- if ((newadv != adv) || !(bmcr & BMCR_ANENABLE)) {
- tg3_writephy(tp, MII_ADVERTISE, newadv);
+ if ((new_adv != adv) || !(bmcr & BMCR_ANENABLE)) {
+ tg3_writephy(tp, MII_ADVERTISE, new_adv);
bmcr |= BMCR_ANENABLE | BMCR_ANRESTART;
tg3_writephy(tp, MII_BMCR, bmcr);
^ permalink raw reply related
* Firmware errors and warnings with Centrino Advanced-N 6205
From: Udo Steinberg @ 2011-11-20 20:50 UTC (permalink / raw)
To: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 20689 bytes --]
Hi,
I'm repeatedly getting firmware errors and warnings on my Centrino 6205 WiFi
card with Linux 3.1. These warnings keep filling the logs at a rate that is
not funny. Any idea how to fix this issue or at least rate-limit those
messages?
Cheers,
- Udo
Excerpt from syslog:
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Microcode SW error detected. Restarting 0x82000000.
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump:
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x01008035 | data1
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000005A7 | line
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x00480303 | board version
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR values:
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_IF_CONFIG_REG: 0X00480303
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT_COALESCING: 0X0000ff40
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_INT_MASK: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_FH_INT_STATUS: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GPIO_IN: 0X00000030
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_RESET: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_CNTRL: 0X080403c5
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_REV: 0X000000b0
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_EEPROM_REG: 0X07d60ffd
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_EEPROM_GP: 0X90000001
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_OTP_GP_REG: 0X00030001
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GIO_REG: 0X00080044
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_UCODE_REG: 0X000093bb
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GP_DRIVER_REG: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP1: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP2: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_LED_REG: 0X00000078
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_DRAM_INT_TBL_REG: 0X88214dd2
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_ANA_PLL_CFG: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_HW_REV_WA_REG: 0X0001001a
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0010
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH register values:
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_WPTR: 0X00000060
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_ERROR_REG: 0X00000000
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695219435:0x028a001c:0217
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221022:0x028b001c:0206
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221023:0x00000001:0204
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221026:0x00000001:0214
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221027:0x01001110:0205
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221051:0x00000020:0208
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221070:0x00000000:0302
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221104:0x00000001:0203
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221109:0x028b001c:0206
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221110:0x00000040:0204
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221113:0x01000110:0211
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221117:0x00000000:0212
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221159:0x00000000:0215
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221162:0x00000008:0220
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221179:0x00000000:0302
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221211:0x000000d4:0303
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221215:0x0000128c:0217
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221215:0x028b001c:0217
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221224:0x09e8004e:0401
Nov 20 20:47:40 x220 kernel: iwlagn 0000:03:00.0: EVT_LOGT:0695221234:0x00000000:0125
Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Error sending REPLY_ADD_STA: time out after 2000ms.
Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Adding station 00:24:fe:41:8d:0e failed.
Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Unable to add station 00:24:fe:41:8d:0e (-110)
Nov 20 20:47:42 x220 kernel: ------------[ cut here ]------------
Nov 20 20:47:42 x220 kernel: WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407()
Nov 20 20:47:42 x220 kernel: Hardware name: 4290W4H
Nov 20 20:47:42 x220 kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2
Nov 20 20:47:42 x220 kernel: Call Trace:
Nov 20 20:47:42 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
Nov 20 20:47:42 x220 kernel: [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407
Nov 20 20:47:42 x220 kernel: [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32
Nov 20 20:47:42 x220 kernel: [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87
Nov 20 20:47:42 x220 kernel: [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3
Nov 20 20:47:42 x220 kernel: [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a
Nov 20 20:47:42 x220 kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
Nov 20 20:47:42 x220 kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba97>] ? kthread+0x7a/0x82
Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b0>] ? gs_change+0xb/0xb
Nov 20 20:47:42 x220 kernel: ---[ end trace c69a09b105aa81ab ]---
Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Invalid station for AGG tid 0
Nov 20 20:47:42 x220 kernel: iwlagn 0000:03:00.0: Attempting to modify non-existing station 0
Nov 20 20:47:42 x220 kernel: ------------[ cut here ]------------
Nov 20 20:47:42 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
Nov 20 20:47:42 x220 kernel: Hardware name: 4290W4H
Nov 20 20:47:42 x220 kernel: Pid: 3, comm: ksoftirqd/0 Tainted: G W 3.1.0 #2
Nov 20 20:47:42 x220 kernel: Call Trace:
Nov 20 20:47:42 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
Nov 20 20:47:42 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
Nov 20 20:47:42 x220 kernel: [<ffffffff8102adde>] ? update_curr+0x77/0xd0
Nov 20 20:47:42 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
Nov 20 20:47:42 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
Nov 20 20:47:42 x220 kernel: [<ffffffff813b5f55>] ? ieee80211_tx_pending+0x14b/0x20a
Nov 20 20:47:42 x220 kernel: [<ffffffff8103ab0a>] ? tasklet_action+0x67/0xa7
Nov 20 20:47:42 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
Nov 20 20:47:42 x220 kernel: [<ffffffff8103af96>] ? run_ksoftirqd+0xab/0x193
Nov 20 20:47:42 x220 kernel: [<ffffffff8103aeeb>] ? __do_softirq+0x106/0x106
Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba97>] ? kthread+0x7a/0x82
Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
Nov 20 20:47:42 x220 kernel: [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
Nov 20 20:47:42 x220 kernel: [<ffffffff813d21b0>] ? gs_change+0xb/0xb
Nov 20 20:47:42 x220 kernel: ---[ end trace c69a09b105aa81ac ]---
Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
Nov 20 20:47:43 x220 kernel: Pid: 1902, comm: firefox Tainted: G W 3.1.0 #2
Nov 20 20:47:43 x220 kernel: Call Trace:
Nov 20 20:47:43 x220 kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
Nov 20 20:47:43 x220 kernel: [<ffffffff813609d3>] ? tcp_write_xmit+0x7c8/0x8b0
Nov 20 20:47:43 x220 kernel: [<ffffffff81328188>] ? __alloc_skb+0x5f/0x114
Nov 20 20:47:43 x220 kernel: [<ffffffff81360b04>] ? __tcp_push_pending_frames+0x18/0x73
Nov 20 20:47:43 x220 kernel: [<ffffffff81356ab0>] ? tcp_close+0x157/0x390
Nov 20 20:47:43 x220 kernel: [<ffffffff81370c00>] ? inet_release+0x77/0x80
Nov 20 20:47:43 x220 kernel: [<ffffffff81322d65>] ? sock_release+0x10/0x54
Nov 20 20:47:43 x220 kernel: [<ffffffff81322dcb>] ? sock_close+0x22/0x29
Nov 20 20:47:43 x220 kernel: [<ffffffff810a89cf>] ? fput+0xea/0x194
Nov 20 20:47:43 x220 kernel: [<ffffffff810a6d0f>] ? filp_close+0x62/0x6a
Nov 20 20:47:43 x220 kernel: [<ffffffff810a6da8>] ? sys_close+0x91/0xd5
Nov 20 20:47:43 x220 kernel: [<ffffffff813d0e3b>] ? system_call_fastpath+0x16/0x1b
Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81ad ]---
Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
Nov 20 20:47:43 x220 kernel: Pid: 0, comm: swapper Tainted: G W 3.1.0 #2
Nov 20 20:47:43 x220 kernel: Call Trace:
Nov 20 20:47:43 x220 kernel: <IRQ> [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
Nov 20 20:47:43 x220 kernel: [<ffffffff8102adde>] ? update_curr+0x77/0xd0
Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
Nov 20 20:47:43 x220 kernel: [<ffffffff8135a3f9>] ? tcp_fin.clone.31+0x5c/0x18f
Nov 20 20:47:43 x220 kernel: [<ffffffff8135a94e>] ? tcp_data_queue+0x2de/0xb46
Nov 20 20:47:43 x220 kernel: [<ffffffff8135dca3>] ? tcp_validate_incoming+0x1bb/0x28b
Nov 20 20:47:43 x220 kernel: [<ffffffff8135ec3b>] ? tcp_rcv_state_process+0x8f5/0x96e
Nov 20 20:47:43 x220 kernel: [<ffffffff81363d0d>] ? tcp_v4_do_rcv+0x240/0x284
Nov 20 20:47:43 x220 kernel: [<ffffffff8133f9f4>] ? sk_filter+0x6d/0x78
Nov 20 20:47:43 x220 kernel: [<ffffffff81365aa1>] ? tcp_v4_rcv+0x416/0x65e
Nov 20 20:47:43 x220 kernel: [<ffffffff8134b6b0>] ? ip_local_deliver+0xa5/0xfe
Nov 20 20:47:43 x220 kernel: [<ffffffff8132ee96>] ? __netif_receive_skb+0x279/0x2af
Nov 20 20:47:43 x220 kernel: [<ffffffff810b3a0a>] ? send_sigio_to_task+0xf6/0x108
Nov 20 20:47:43 x220 kernel: [<ffffffff81331f3c>] ? netif_receive_skb+0x7e/0x84
Nov 20 20:47:43 x220 kernel: [<ffffffff8104033b>] ? mod_timer+0x189/0x1a1
Nov 20 20:47:43 x220 kernel: [<ffffffff813b1201>] ? ieee80211_deliver_skb+0xc3/0x104
Nov 20 20:47:43 x220 kernel: [<ffffffff813b20c8>] ? ieee80211_rx_handlers+0xe86/0x17e2
Nov 20 20:47:43 x220 kernel: [<ffffffff810b42fd>] ? send_sigio+0x91/0xa7
Nov 20 20:47:43 x220 kernel: [<ffffffff8102f3b6>] ? __wake_up+0x35/0x46
Nov 20 20:47:43 x220 kernel: [<ffffffff813b30d5>] ? ieee80211_prepare_and_rx_handle+0x6b1/0x734
Nov 20 20:47:43 x220 kernel: [<ffffffff813b39f8>] ? ieee80211_rx+0x735/0x7ac
Nov 20 20:47:43 x220 kernel: [<ffffffff81285f46>] ? iwl_rx_reply_rx+0x467/0x47e
Nov 20 20:47:43 x220 kernel: [<ffffffff813a021b>] ? ieee80211_tx_status+0x72d/0x73f
Nov 20 20:47:43 x220 kernel: [<ffffffff8128c444>] ? iwl_irq_tasklet+0x402/0x675
Nov 20 20:47:43 x220 kernel: [<ffffffff8103ab0a>] ? tasklet_action+0x67/0xa7
Nov 20 20:47:43 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
Nov 20 20:47:43 x220 kernel: [<ffffffff813d22ac>] ? call_softirq+0x1c/0x26
Nov 20 20:47:43 x220 kernel: [<ffffffff810033fe>] ? do_softirq+0x31/0x67
Nov 20 20:47:43 x220 kernel: [<ffffffff8103b118>] ? irq_exit+0x44/0xb0
Nov 20 20:47:43 x220 kernel: [<ffffffff8100313f>] ? do_IRQ+0x94/0xad
Nov 20 20:47:43 x220 kernel: [<ffffffff813d07eb>] ? common_interrupt+0x6b/0x6b
Nov 20 20:47:43 x220 kernel: <EOI> [<ffffffff8104f02c>] ? __hrtimer_start_range_ns+0x2c6/0x2d9
Nov 20 20:47:43 x220 kernel: [<ffffffff8118a94a>] ? intel_idle+0xcd/0xe9
Nov 20 20:47:43 x220 kernel: [<ffffffff8118a926>] ? intel_idle+0xa9/0xe9
Nov 20 20:47:43 x220 kernel: [<ffffffff812dca4d>] ? cpuidle_idle_call+0xa0/0xdb
Nov 20 20:47:43 x220 kernel: [<ffffffff81000699>] ? cpu_idle+0x53/0x7c
Nov 20 20:47:43 x220 kernel: [<ffffffff816879fa>] ? start_kernel+0x2be/0x2c9
Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81ae ]---
Nov 20 20:47:43 x220 kernel: ------------[ cut here ]------------
Nov 20 20:47:43 x220 kernel: WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.h:134 iwlagn_tx_skb+0xd2/0x68d()
Nov 20 20:47:43 x220 kernel: Hardware name: 4290W4H
Nov 20 20:47:43 x220 kernel: Pid: 0, comm: swapper Tainted: G W 3.1.0 #2
Nov 20 20:47:43 x220 kernel: Call Trace:
Nov 20 20:47:43 x220 kernel: <IRQ> [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
Nov 20 20:47:43 x220 kernel: [<ffffffff8127ca3a>] ? iwlagn_tx_skb+0xd2/0x68d
Nov 20 20:47:43 x220 kernel: [<ffffffff81276029>] ? iwlagn_mac_tx+0xd/0x1c
Nov 20 20:47:43 x220 kernel: [<ffffffff813b4360>] ? __ieee80211_tx+0x18c/0x1ea
Nov 20 20:47:43 x220 kernel: [<ffffffff813b54ba>] ? ieee80211_tx+0x95/0xad
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5618>] ? ieee80211_xmit+0x146/0x159
Nov 20 20:47:43 x220 kernel: [<ffffffff813b5dbb>] ? ieee80211_subif_start_xmit+0x5b8/0x5d5
Nov 20 20:47:43 x220 kernel: [<ffffffff81330ef8>] ? dev_hard_start_xmit+0x3f2/0x4f0
Nov 20 20:47:43 x220 kernel: [<ffffffff81048223>] ? queue_work_on+0x16/0x20
Nov 20 20:47:43 x220 kernel: [<ffffffff81048274>] ? queue_work+0x47/0x52
Nov 20 20:47:43 x220 kernel: [<ffffffff81342978>] ? sch_direct_xmit+0x67/0x18d
Nov 20 20:47:43 x220 kernel: [<ffffffff810b42fd>] ? send_sigio+0x91/0xa7
Nov 20 20:47:43 x220 kernel: [<ffffffff813313b5>] ? dev_queue_xmit+0x2fe/0x4fc
Nov 20 20:47:43 x220 kernel: [<ffffffff8107a785>] ? free_one_page+0x24e/0x264
Nov 20 20:47:43 x220 kernel: [<ffffffff8134f3b4>] ? ip_finish_output+0x216/0x267
Nov 20 20:47:43 x220 kernel: [<ffffffff8134ea04>] ? ip_queue_xmit+0x2c8/0x304
Nov 20 20:47:43 x220 kernel: [<ffffffff81051ff1>] ? getnstimeofday+0x54/0xa5
Nov 20 20:47:43 x220 kernel: [<ffffffff8136014b>] ? tcp_transmit_skb+0x6b4/0x6f4
Nov 20 20:47:43 x220 kernel: [<ffffffff81360f7b>] ? tcp_retransmit_skb+0x41c/0x505
Nov 20 20:47:43 x220 kernel: [<ffffffff81285f46>] ? iwl_rx_reply_rx+0x467/0x47e
Nov 20 20:47:43 x220 kernel: [<ffffffff81362ca0>] ? tcp_retransmit_timer+0x4f8/0x4f8
Nov 20 20:47:43 x220 kernel: [<ffffffff81362b02>] ? tcp_retransmit_timer+0x35a/0x4f8
Nov 20 20:47:43 x220 kernel: [<ffffffff81362d3b>] ? tcp_write_timer+0x9b/0x18d
Nov 20 20:47:43 x220 kernel: [<ffffffff8103fe83>] ? run_timer_softirq+0x19b/0x230
Nov 20 20:47:43 x220 kernel: [<ffffffff8103ae64>] ? __do_softirq+0x7f/0x106
Nov 20 20:47:43 x220 kernel: [<ffffffff813d22ac>] ? call_softirq+0x1c/0x26
Nov 20 20:47:43 x220 kernel: [<ffffffff810033fe>] ? do_softirq+0x31/0x67
Nov 20 20:47:43 x220 kernel: [<ffffffff8103b118>] ? irq_exit+0x44/0xb0
Nov 20 20:47:43 x220 kernel: [<ffffffff81014a09>] ? smp_apic_timer_interrupt+0x85/0x95
Nov 20 20:47:43 x220 kernel: [<ffffffff813d184b>] ? apic_timer_interrupt+0x6b/0x70
Nov 20 20:47:43 x220 kernel: <EOI> [<ffffffff8118a94a>] ? intel_idle+0xcd/0xe9
Nov 20 20:47:43 x220 kernel: [<ffffffff8118a926>] ? intel_idle+0xa9/0xe9
Nov 20 20:47:43 x220 kernel: [<ffffffff812dca4d>] ? cpuidle_idle_call+0xa0/0xdb
Nov 20 20:47:43 x220 kernel: [<ffffffff81000699>] ? cpu_idle+0x53/0x7c
Nov 20 20:47:43 x220 kernel: [<ffffffff816879fa>] ? start_kernel+0x2be/0x2c9
Nov 20 20:47:43 x220 kernel: ---[ end trace c69a09b105aa81af ]---
... and it goes on and on
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH V2] Add ethtool to mii advertisment conversion helpers
From: David Miller @ 2011-11-20 21:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: mcarlson, netdev, mchan
In-Reply-To: <1321823497.4984.4.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 20 Nov 2011 22:11:37 +0100
> For reference, the revert on tg3 :
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 024ca1d..365cd47 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -3594,7 +3594,15 @@ static int tg3_phy_autoneg_cfg(struct tg3 *tp, u32 advertise, u32 flowctrl)
> u32 val, new_adv;
>
> new_adv = ADVERTISE_CSMA;
> - new_adv |= ethtool_adv_to_mii_100bt(advertise);
> + if (advertise & ADVERTISED_10baseT_Half)
> + new_adv |= ADVERTISE_10HALF;
> + if (advertise & ADVERTISED_10baseT_Full)
> + new_adv |= ADVERTISE_10FULL;
> + if (advertise & ADVERTISED_100baseT_Half)
> + new_adv |= ADVERTISE_100HALF;
> + if (advertise & ADVERTISED_100baseT_Full)
> + new_adv |= ADVERTISE_100FULL;
> +
> new_adv |= tg3_advert_flowctrl_1000T(flowctrl);
>
Well, for one thing the flow control handling is subtly changed here.
ethtool_adv_to_mii_100bt() does it's own setting of the flow control
advertisement bits. It sets ADVERTISE_PAUSE_CAP and
ADVERTISE_PAUSE_ASYM.
But here in tg3, tg3_advert_flowctrl_1000T() has it's own seperate
logic for setting those bits.
I cannot say for certain that this is what it causing your problems,
but it is clear now that these transformations were not done carefully
enough.
^ permalink raw reply
* MPLS for Linux kernel
From: Igor Maravić @ 2011-11-20 21:59 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Hi all,
I've been working on implementation of MPLS for Linux kernel, for a
some time now.
I continued the work of James Leu
(https://sourceforge.net/projects/mpls-linux/) and used some fixes of
Jorge Boncompte
(http://mpls-linux.git.sourceforge.net/git/gitweb.cgi?p=mpls-linux/net-next;a=shortlog;h=refs/heads/net-next-mpls).
I fixed a lot of bugs, so now it can be compiled and run with all
Kernel Hacking options enabled.
My code could be found on this sites:
https://github.com/i-maravic/MPLS-Linux
https://github.com/i-maravic/iproute2
Any feedback is appreciated :)
On Dave's blog I read that MPLS is one of the things that should be
implemented in to the Linux kernel.
What is the procedure to do that with this code?
BR
Igor Maravić
^ permalink raw reply
* [PATCH net-next] tg3: Fix advertisement handling
From: Hiroaki SHIMODA @ 2011-11-20 23:07 UTC (permalink / raw)
To: davem, mcarlson, mchan; +Cc: netdev
Commit 28011cf19b (net: Add ethtool to mii advertisment conversion
helpers) added a helper function ethtool_adv_to_mii_100bt() and
tg3_copper_is_advertising_all(), tg3_phy_autoneg_cfg() were
modified to use this.
Before that commit, ethtool to mii advertisement conversion was
done wrt speed, but now pause operation is also taken account.
So, in tg3_copper_is_advertising_all(), below condition becomes
true and this makes link up fails.
if ((adv_reg & ADVERTISE_ALL) != all_mask)
return 0;
To fix this add ADVERTISE_ALL bit and operation to cap speed.
Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
---
drivers/net/ethernet/broadcom/tg3.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 024ca1d..c00e648 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -3594,7 +3594,7 @@ static int tg3_phy_autoneg_cfg(struct tg3 *tp, u32 advertise, u32 flowctrl)
u32 val, new_adv;
new_adv = ADVERTISE_CSMA;
- new_adv |= ethtool_adv_to_mii_100bt(advertise);
+ new_adv |= ethtool_adv_to_mii_100bt(advertise) & ADVERTISE_ALL;
new_adv |= tg3_advert_flowctrl_1000T(flowctrl);
err = tg3_writephy(tp, MII_ADVERTISE, new_adv);
@@ -3783,7 +3783,7 @@ static int tg3_copper_is_advertising_all(struct tg3 *tp, u32 mask)
if (tg3_readphy(tp, MII_ADVERTISE, &adv_reg))
return 0;
- if ((adv_reg & ADVERTISE_ALL) != all_mask)
+ if ((adv_reg & ADVERTISE_ALL) != (all_mask & ADVERTISE_ALL))
return 0;
if (!(tp->phy_flags & TG3_PHYFLG_10_100_ONLY)) {
^ permalink raw reply related
* Re: [PATCH for 2.6.32 (untested)] netns: Add quota for number of NET_NS instances.
From: Eric W. Biederman @ 2011-11-20 23:13 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: netdev
In-Reply-To: <201111201622.FDJ51567.VLFHQFMFOOSOtJ@I-love.SAKURA.ne.jp>
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> writes:
> In order to solve below problems, can we add sysctl variable for
> restricting number of NET_NS instances?
I don't have any particular problems with patch but I don't think it
will result in a working system that is easy to keep working. Tuning
static limits can be fickle.
Simply throttling the number of processes as anything reasonable will do
should keep the problem in check. The practical issue is that we have
a huge build of network namespaces that don't get cleaned up.
My inclination in this case the practical fix is that during network
namespace allocation someone take a look at the cleanup_list. See
that there is ongoing cleanup activity, and wait until at least one
network namespace has cleaned up. Perhaps by creating a work struct
and waiting for it to cycle through the netns workqueue.
That should throttle network namespace creation to the same speed as
network namespace deletion and prevent the problem of too many
dead network namespaces building up and taking resources.
Eric
> --------------------------------------------------
> [PATCH for 2.6.32 (untested)] netns: Add quota for number of NET_NS instances.
>
> CONFIG_NET_NS support in 2.6.32 has a problem that leads to OOM killer when
> clone(CLONE_NEWNET) is called instantly.
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/720095
> But disabling CONFIG_NET_NS broke lxc containers.
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/790863
>
> This patch introduces /proc/sys/net/core/netns_max interface that limits
> max number of network namespace instances.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> include/net/sock.h | 4 ++++
> net/core/net_namespace.c | 9 +++++++++
> net/core/sysctl_net_core.c | 10 ++++++++++
> 3 files changed, 23 insertions(+)
>
> --- linux-2.6.32.48.orig/include/net/sock.h
> +++ linux-2.6.32.48/include/net/sock.h
> @@ -1598,4 +1598,8 @@ extern int sysctl_optmem_max;
> extern __u32 sysctl_wmem_default;
> extern __u32 sysctl_rmem_default;
>
> +#ifdef CONFIG_NET_NS
> +extern int max_netns_count;
> +#endif
> +
> #endif /* _SOCK_H */
> --- linux-2.6.32.48.orig/net/core/net_namespace.c
> +++ linux-2.6.32.48/net/core/net_namespace.c
> @@ -81,12 +81,18 @@ static struct net_generic *net_alloc_gen
> #ifdef CONFIG_NET_NS
> static struct kmem_cache *net_cachep;
> static struct workqueue_struct *netns_wq;
> +static atomic_t used_netns_count = ATOMIC_INIT(0);
> +unsigned int max_netns_count;
>
> static struct net *net_alloc(void)
> {
> struct net *net = NULL;
> struct net_generic *ng;
>
> + atomic_inc(&used_netns_count);
> + if (atomic_read(&used_netns_count) > max_netns_count)
> + goto out;
> +
> ng = net_alloc_generic();
> if (!ng)
> goto out;
> @@ -96,7 +102,9 @@ static struct net *net_alloc(void)
> goto out_free;
>
> rcu_assign_pointer(net->gen, ng);
> + return net;
> out:
> + atomic_dec(&used_netns_count);
> return net;
>
> out_free:
> @@ -115,6 +123,7 @@ static void net_free(struct net *net)
> #endif
> kfree(net->gen);
> kmem_cache_free(net_cachep, net);
> + atomic_dec(&used_netns_count);
> }
>
> static struct net *net_create(void)
> --- linux-2.6.32.48.orig/net/core/sysctl_net_core.c
> +++ linux-2.6.32.48/net/core/sysctl_net_core.c
> @@ -89,6 +89,16 @@ static struct ctl_table net_core_table[]
> .mode = 0644,
> .proc_handler = proc_dointvec
> },
> +#ifdef CONFIG_NET_NS
> + {
> + .ctl_name = CTL_UNNUMBERED,
> + .procname = "netns_max",
> + .data = &max_netns_count,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> + },
> +#endif
> #endif /* CONFIG_NET */
> {
> .ctl_name = NET_CORE_BUDGET,
^ 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