* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Tejun Heo @ 2013-10-09 15:41 UTC (permalink / raw)
To: Alexander Gordeev
Cc: Benjamin Herrenschmidt, Ben Hutchings, linux-kernel,
Bjorn Helgaas, Ralf Baechle, Michael Ellerman, Martin Schwidefsky,
Ingo Molnar, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers, "VMw
In-Reply-To: <20131008122215.GA14389@dhcp-26-207.brq.redhat.com>
Hello,
On Tue, Oct 08, 2013 at 02:22:16PM +0200, Alexander Gordeev wrote:
> If we talk about pSeries quota, then the current pSeries pci_enable_msix()
> implementation is racy internally and could fail if the quota went down
> *while* pci_enable_msix() is executing. In this case the loop will have to
> exit rather than retry with a lower number (what number?).
Ah, okay, so that one is already broken.
> In this regard the new scheme does not bring anything new and relies on
> the fact this race does not hit and therefore does not worry.
>
> If we talk about quota as it has to be, then yes - the loop scheme seems
> more preferable.
>
> Overall, looks like we just need to fix the pSeries implementation,
> if the guys want it, he-he :)
If we can't figure out a better interface for the retry case, I think
what can really help is having a simple interface for the simpler
cases.
> > The problem case is where multiple msi(x) allocation fails completely
> > because the global limit went down before inquiry and allocation. In
> > the loop based interface, it'd retry with the lower number.
>
> I am probably missing something here. If the global limit went down before
> inquiry then the inquiry will get what is available and try to allocate with
> than number.
Oh, I should have written between inquiry and allocation. Sorry.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Tejun Heo @ 2013-10-09 15:43 UTC (permalink / raw)
To: Alexander Gordeev
Cc: Benjamin Herrenschmidt, Ben Hutchings, linux-kernel,
Bjorn Helgaas, Ralf Baechle, Michael Ellerman, Martin Schwidefsky,
Ingo Molnar, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers, "VMw
In-Reply-To: <20131009125715.GC32733@dhcp-26-207.brq.redhat.com>
Hello,
On Wed, Oct 09, 2013 at 02:57:16PM +0200, Alexander Gordeev wrote:
> On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote:
> > Hmmm... yean, the race condition could be an issue as multiple msi
> > allocation might fail even if the driver can and explicitly handle
> > multiple allocation if the quota gets reduced inbetween.
>
> BTW, should we care about the quota getting increased inbetween?
> That would entail.. kind of pci_get_msi_limit() :), but IMHO it is
> not worth it.
I think we shouldn't. If the resource was low during a point in time
during allocation, it's fine to base the result on that - the resource
was actually low and which answer we return is just a question of
timing and both are correct. The only reason the existing race
condition is problematic is because it may fail even if the resource
never falls below the failure point.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Tejun Heo @ 2013-10-09 15:46 UTC (permalink / raw)
To: Ben Hutchings
Cc: Alexander Gordeev, Benjamin Herrenschmidt, linux-kernel,
Bjorn Helgaas, Ralf Baechle, Michael Ellerman, Martin Schwidefsky,
Ingo Molnar, Dan Williams, Andy King, Jon Mason, Matt Porter,
linux-pci, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers,
"VMwar
In-Reply-To: <1381178881.1536.28.camel@bwh-desktop.uk.level5networks.com>
On Mon, Oct 07, 2013 at 09:48:01PM +0100, Ben Hutchings wrote:
> > There is one major flaw in min-max approach - the generic MSI layer
> > will have to take decisions on exact number of MSIs to request, not
> > device drivers.
> [...
>
> No, the min-max functions should be implemented using the same loop that
> drivers are expected to use now.
Wheee... earlier in the thread I thought you guys were referring to
yourselves in the third person and was getting a bit worried. :)
--
tejun
^ permalink raw reply
* Re: [PATCH RFC 07/77] PCI/MSI: Re-design MSI/MSI-X interrupts enablement pattern
From: Tejun Heo @ 2013-10-09 15:54 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Dan Williams, Andy King, Jon Mason, Matt Porter, linux-pci,
linux-doc, linux-mips, linuxppc-dev, linux390, linux-s390, x86,
linux-ide, iss_storagedev, linux-nvme, linux-rdma, netdev,
e1000-devel, linux-driver, Solarflare linux maintainers,
"VMware, Inc." <pv-dr
In-Reply-To: <20131008074826.GD10669@dhcp-26-207.brq.redhat.com>
Hello, Alexander.
On Tue, Oct 08, 2013 at 09:48:26AM +0200, Alexander Gordeev wrote:
> > If there are many which duplicate the above pattern, it'd probably be
> > worthwhile to provide a helper? It's usually a good idea to reduce
> > the amount of boilerplate code in drivers.
>
> I wanted to limit discussion in v1 to as little changes as possible.
> I 'planned' those helper(s) for a separate effort if/when the most
> important change is accepted and soaked a bit.
The thing is doing it this way generates more churns and noises. Once
the simpler ones live behind a wrapper which can be built on the
existing interface, we can have both reduced cost and more latitude on
the complex cases.
> > If we do things this way, it breaks all drivers using this interface
> > until they're converted, right?
>
> Right. And the rest of the series does it.
Which breaks bisection which we shouldn't do.
> > Also, it probably isn't the best idea
> > to flip the behavior like this as this can go completely unnoticed (no
> > compiler warning or anything, the same function just behaves
> > differently). Maybe it'd be a better idea to introduce a simpler
> > interface that most can be converted to?
>
> Well, an *other* interface is a good idea. What do you mean with the
> simpler here?
I'm still talking about a simpler wrapper for common cases, which is
the important part anyway.
Thanks.
--
tejun
^ permalink raw reply
* RE: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: David Laight @ 2013-10-09 15:49 UTC (permalink / raw)
To: Antonio Quartulli
Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <20131009143500.GH3544@neomailbox.net>
> > Are you really generating CRC32 of a pile of ethernet MAC addresses
> > and the XORing the CRC together?
> > That gives the same answer as XORing together the MAC addresses and
> > then doing a CRC of the final value.
>
> I was not sure about this since the CRC32 is not a linear operation. However
> this routine is not on the fast path, so we can also live with this order.
All CRC are linear.
Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
The CRC for each bit depends on how far it is from the end of the buffer.
Presetting the CRC to all-ones generates a value that is dependent on
the length of the buffer - otherwise missing/extra leading zeros are
not detected.
David
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Tejun Heo @ 2013-10-09 15:57 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-kernel, Bjorn Helgaas, Ralf Baechle, Michael Ellerman,
Benjamin Herrenschmidt, Martin Schwidefsky, Ingo Molnar,
Dan Williams, Andy King, Jon Mason, Matt Porter, linux-pci,
linux-mips, linuxppc-dev, linux390, linux-s390, x86, linux-ide,
iss_storagedev, linux-nvme, linux-rdma, netdev, e1000-devel,
linux-driver, Solarflare linux maintainers, VMware, Inc.,
linux-sc
In-Reply-To: <20131008090716.GA10561@dhcp-26-207.brq.redhat.com>
Hello,
On Tue, Oct 08, 2013 at 11:07:16AM +0200, Alexander Gordeev wrote:
> Multipe MSIs is just a handful of drivers, really. MSI-X impact still
Yes, so it's pretty nice to try out things there before going full-on.
> will be huge. But if we opt a different name for the new pci_enable_msix()
> then we could first update pci/msi, then drivers (in few stages possibly)
> and finally remove the old implementation.
Yes, that probably should be the steps to follow eventually. My point
was that you don't have to submit patches for all 7x conversions for
an RFC round. Scanning them and seeing what would be necessary
definitely is a good idea but just giving summary of the full
conversion with several examples should be good enough before settling
on the way forward, which should be easier for all involved.
Thanks a lot for your effort!
--
tejun
^ permalink raw reply
* See the attached file
From: Microsoft Promotion @ 2013-10-09 16:04 UTC (permalink / raw)
In-Reply-To: <1381255842.36752.YahooMailNeo@web5706.biz.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 21 bytes --]
See the attached file
[-- Attachment #2: MICROSOFT_AWARD_PROMOTION_2013.doc --]
[-- Type: application/msword, Size: 124416 bytes --]
^ permalink raw reply
* Re: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: Antonio Quartulli @ 2013-10-09 16:10 UTC (permalink / raw)
To: David Laight; +Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7385@saturn3.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
On Wed, Oct 09, 2013 at 04:49:53PM +0100, David Laight wrote:
> > > Are you really generating CRC32 of a pile of ethernet MAC addresses
> > > and the XORing the CRC together?
> > > That gives the same answer as XORing together the MAC addresses and
> > > then doing a CRC of the final value.
> >
> > I was not sure about this since the CRC32 is not a linear operation. However
> > this routine is not on the fast path, so we can also live with this order.
>
> All CRC are linear.
> Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
>
> The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
> The CRC for each bit depends on how far it is from the end of the buffer.
In our tables we cannot make any assumption about the order of the entries: the
node whom generated the table may store the entries in a different order from
what we have got.
This is why I did not implemented it as a simple CRC of the
whole the GlobalTable/buffer but I CRC'd each MAC+VID on its own.
> Presetting the CRC to all-ones generates a value that is dependent on
> the length of the buffer - otherwise missing/extra leading zeros are
> not detected.
Assuming what I said above (that we cannot make assumptions on the order of the
entries), what is your suggestion?
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: Antonio Quartulli @ 2013-10-09 16:15 UTC (permalink / raw)
To: David Laight; +Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <20131009161028.GI3544@neomailbox.net>
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
On Wed, Oct 09, 2013 at 06:10:28PM +0200, Antonio Quartulli wrote:
> On Wed, Oct 09, 2013 at 04:49:53PM +0100, David Laight wrote:
> > All CRC are linear.
> > Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
> >
> > The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
> > The CRC for each bit depends on how far it is from the end of the buffer.
>
> In our tables we cannot make any assumption about the order of the entries: the
> node whom generated the table may store the entries in a different order from
> what we have got.
> This is why I did not implemented it as a simple CRC of the
> whole the GlobalTable/buffer but I CRC'd each MAC+VID on its own.
>
>
> > Presetting the CRC to all-ones generates a value that is dependent on
> > the length of the buffer - otherwise missing/extra leading zeros are
> > not detected.
>
>
> Assuming what I said above (that we cannot make assumptions on the order of the
> entries), what is your suggestion?
Given that CRCs are commutative, the easiest answer to this question is probably to
perform the XOR of all the entries and than computing the CRC32 once
(and when computing the CRC I should start with 0xFFFFFFFF other than 0),
right?
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: David Laight @ 2013-10-09 16:19 UTC (permalink / raw)
To: Antonio Quartulli
Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <20131009161028.GI3544@neomailbox.net>
> On Wed, Oct 09, 2013 at 04:49:53PM +0100, David Laight wrote:
> > > > Are you really generating CRC32 of a pile of ethernet MAC addresses
> > > > and the XORing the CRC together?
> > > > That gives the same answer as XORing together the MAC addresses and
> > > > then doing a CRC of the final value.
> > >
> > > I was not sure about this since the CRC32 is not a linear operation. However
> > > this routine is not on the fast path, so we can also live with this order.
> >
> > All CRC are linear.
> > Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
> >
> > The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
> > The CRC for each bit depends on how far it is from the end of the buffer.
>
> In our tables we cannot make any assumption about the order of the entries: the
> node whom generated the table may store the entries in a different order from
> what we have got.
> This is why I did not implemented it as a simple CRC of the
> whole the GlobalTable/buffer but I CRC'd each MAC+VID on its own.
>
...
>
> Assuming what I said above (that we cannot make assumptions on the order of the
> entries), what is your suggestion?
I'm not sure what you are using this CRC for.
If you are trying to use it to check that the two tables match - so a
full update isn't needed then it just won't work.
If you take out 11:22:33:44:55:60 and 11:22:33:44:55:61 and
change 99:88:77:66:55:40 to 99:88:77:66:55:41 then the XOR of
the CRCs won't change.
For MAC addresses such changes aren't that unlikely.
David
^ permalink raw reply
* Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
From: Tejun Heo @ 2013-10-09 17:04 UTC (permalink / raw)
To: Daniel Borkmann
Cc: pablo-Cap9r6Oaw4JrovVCs/uTlw,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5253BCAE.5060409-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hello,
On Tue, Oct 08, 2013 at 10:05:02AM +0200, Daniel Borkmann wrote:
> Could you elaborate on "Wouldn't it be more logical to implement netfilter
> rule to match the target cgroup paths?". I don't think (or hope) you mean
> some string comparison on the dentry path here? :) With our proposal, we
> have in the network stack's critical path only the following code that is
> being executed here to match the cgroup ...
Comparing path each time obviously doesn't make sense but you can
determine the cgroup on config and hold onto the pointer while the
rule exists.
> ... where ``info->id == skb->sk->sk_cgrp_fwid'' is the actual work, so very
> lightweight, which is good for high loads (1Gbit/s, 10Gbit/s and beyond), of
> course. Also, it would be intuitive for admins familiar with other subsystems
> to just set up and use these cgroup ids in iptabels. I'm not yet quite sure
> how your suggestion would look like, so you would need to setup some "dummy"
> subgroups first just to have a path that you can match on?
Currently, it's tricky because we have multiple hierarchies to
consider and there isn't an efficient way to map from task to cgroup
on a specific hierarchy. I'm not sure whether we should add another
mapping table in css_set or just allow using path matching on the
unified hierarchy. The latter should be cleaner and easier but more
restrictive.
Anyways, it isn't manageable in the long term to keep adding
controllers simply to tag tasks differently. If we want to do this,
let's please work on a way to match a task's cgroup affiliation
efficiently.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 10/16] batman-adv: use CRC32C instead of CRC16 in TT code
From: Antonio Quartulli @ 2013-10-09 17:05 UTC (permalink / raw)
To: David Laight; +Cc: davem, netdev, b.a.t.m.a.n, Antonio Quartulli, Marek Lindner
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7386@saturn3.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]
On Wed, Oct 09, 2013 at 05:19:44PM +0100, David Laight wrote:
> > On Wed, Oct 09, 2013 at 04:49:53PM +0100, David Laight wrote:
> > > > > Are you really generating CRC32 of a pile of ethernet MAC addresses
> > > > > and the XORing the CRC together?
> > > > > That gives the same answer as XORing together the MAC addresses and
> > > > > then doing a CRC of the final value.
> > > >
> > > > I was not sure about this since the CRC32 is not a linear operation. However
> > > > this routine is not on the fast path, so we can also live with this order.
> > >
> > > All CRC are linear.
> > > Because '(a + b) mod c' is the same as '((a mod c) + (b mod c)) mod c'.
> > >
> > > The CRC of a buffer is the XOR of the CRCs generated for each '1' bit.
> > > The CRC for each bit depends on how far it is from the end of the buffer.
> >
> > In our tables we cannot make any assumption about the order of the entries: the
> > node whom generated the table may store the entries in a different order from
> > what we have got.
> > This is why I did not implemented it as a simple CRC of the
> > whole the GlobalTable/buffer but I CRC'd each MAC+VID on its own.
> >
> ...
> >
> > Assuming what I said above (that we cannot make assumptions on the order of the
> > entries), what is your suggestion?
>
> I'm not sure what you are using this CRC for.
> If you are trying to use it to check that the two tables match - so a
> full update isn't needed then it just won't work.
No, we have a sequence number for this purpose.
The CRC is only used to check that (after having applied all the needed changes)
the content of the table is really the same as the one owned by whom generated
it.
Therefore the CRC is practically used only to check that the node memory has not
been corrupted and I can hardly imagine that such a case can lead to the same
CRC as the expected one (of course, probability is not zero, but that's because
it is an hash function..).
The conclusion is that we can live with this patch :-)
Thank you anyway for your explanation. This will surely help in case we decide
to change/improve it.
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] tun: don't look at current when non-blocking
From: David Miller @ 2013-10-09 17:14 UTC (permalink / raw)
To: mst; +Cc: jasowang, netdev, linux-kernel, edumazet, xemul
In-Reply-To: <20131009081354.GA30882@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 9 Oct 2013 11:13:54 +0300
> On Wed, Oct 09, 2013 at 02:25:19PM +0800, Jason Wang wrote:
>> On 10/09/2013 03:46 AM, David Miller wrote:
>> > From: "Michael S. Tsirkin" <mst@redhat.com>
>> > Date: Sun, 6 Oct 2013 21:25:12 +0300
>> >
>> >> We play with a wait queue even if socket is
>> >> non blocking. This is an obvious waste.
>> >> Besides, it will prevent calling the non blocking
>> >> variant when current is not valid.
>> >>
>> >> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> > Applied and queued up for -stable, thanks.
>> > --
>>
>> Michael, I believe this is just an optimization or a required patch of
>> your following patches. So no need go for stable?
>
> I don't think it's required for stable.
Ok, removed from the -stable queue. Thanks.
^ permalink raw reply
* [PATCH 3/3] gianfar: Enable eTSEC-20 erratum w/a for P2020 Rev1
From: Claudiu Manoil @ 2013-10-09 17:20 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linuxppc-dev
In-Reply-To: <1381339242-32030-1-git-send-email-claudiu.manoil@freescale.com>
Enable workaround for P2020/P2010 erratum eTSEC 20,
"Excess delays when transmitting TOE=1 large frames".
The impact is that frames lager than 2500-bytes for which
TOE (i.e. TCP/IP hw accelerations like Tx csum) is enabled
may see excess delay before start of transmission.
This erratum was fixed in Rev 2.0.
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
drivers/net/ethernet/freescale/gianfar.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 329a206..9fbe4dd 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -968,6 +968,9 @@ static void __gfar_detect_errata_85xx(struct gfar_private *priv)
if ((SVR_SOC_VER(svr) == SVR_8548) && (SVR_REV(svr) == 0x20))
priv->errata |= GFAR_ERRATA_12;
+ if (((SVR_SOC_VER(svr) == SVR_P2020) && (SVR_REV(svr) < 0x20)) ||
+ ((SVR_SOC_VER(svr) == SVR_P2010) && (SVR_REV(svr) < 0x20)))
+ priv->errata |= GFAR_ERRATA_76; /* aka eTSEC 20 */
}
static void gfar_detect_errata(struct gfar_private *priv)
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] veth: allow to setup multicast address for veth device
From: David Miller @ 2013-10-09 17:22 UTC (permalink / raw)
To: gaofeng; +Cc: netdev, pablo, edumazet, kaber, hannes
In-Reply-To: <52551ABD.40603@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Wed, 09 Oct 2013 16:58:37 +0800
> Hi David,
>
> On 10/04/2013 04:52 PM, Gao feng wrote:
>> We can only setup multicast address for network device when
>> net_device_ops->ndo_set_rx_mode is not null.
>>
>> Some configurations need to add multicast address for net
>> device, such as netfilter cluster match module.
>>
>> Add a fake ndo_set_rx_mode function to allow this operation.
>>
>> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
>
> I see this patch being marked as "Changes Requested" on patchwork.
> Is there something I missed?
It was a mistake, I put it back in Under Review.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: fix build errors if ipv6 is disabled
From: David Miller @ 2013-10-09 17:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381313148.4971.13.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 09 Oct 2013 03:05:48 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> CONFIG_IPV6=n is still a valid choice ;)
>
> It appears we can remove dead code.
>
> Reported-by: Wu Fengguang <fengguang.wu@intel.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> v2: add the missing right parenthesis in ping_bind()
Applied, thanks.
^ permalink raw reply
* [PATCH 1/3] gianfar: Enable eTSEC-A002 erratum w/a for all parts
From: Claudiu Manoil @ 2013-10-09 17:20 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linuxppc-dev
A002 is still in "no plans to fix" state, and applies to all
the current P1/P2 parts as well, so it's resonable to enable
its workaround by default, for all the soc's with etsec.
The impact of not enabling this workaround for affected parts
is that under certain conditons (runt frames or even frames
with RX error detected at PHY level) during controller reset,
the controller might fail to indicate Rx reset (GRS) completion.
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
drivers/net/ethernet/freescale/gianfar.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index c4eaade..db5fc7b 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -947,6 +947,9 @@ static void gfar_detect_errata(struct gfar_private *priv)
unsigned int mod = (svr >> 16) & 0xfff6; /* w/o E suffix */
unsigned int rev = svr & 0xffff;
+ /* no plans to fix */
+ priv->errata |= GFAR_ERRATA_A002;
+
/* MPC8313 Rev 2.0 and higher; All MPC837x */
if ((pvr == 0x80850010 && mod == 0x80b0 && rev >= 0x0020) ||
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
@@ -957,11 +960,6 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_76;
- /* MPC8313 and MPC837x all rev */
- if ((pvr == 0x80850010 && mod == 0x80b0) ||
- (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
- priv->errata |= GFAR_ERRATA_A002;
-
/* MPC8313 Rev < 2.0, MPC8548 rev 2.0 */
if ((pvr == 0x80850010 && mod == 0x80b0 && rev < 0x0020) ||
(pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020))
@@ -1599,7 +1597,7 @@ static int __gfar_is_rx_idle(struct gfar_private *priv)
/* Normaly TSEC should not hang on GRS commands, so we should
* actually wait for IEVENT_GRSC flag.
*/
- if (likely(!gfar_has_errata(priv, GFAR_ERRATA_A002)))
+ if (!gfar_has_errata(priv, GFAR_ERRATA_A002))
return 0;
/* Read the eTSEC register at offset 0xD1C. If bits 7-14 are
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/3] gianfar: Use mpc85xx support for errata detection
From: Claudiu Manoil @ 2013-10-09 17:20 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linuxppc-dev
In-Reply-To: <1381339242-32030-1-git-send-email-claudiu.manoil@freescale.com>
Use the macros and defines from mpc85xx.h to simplify
and prevent errors in identifying a mpc85xx based SoC
for errata detection.
This should help enabling (and identifying) workarounds
for various mpc85xx based chips and revisions.
For instance, express MPC8548 Rev.2 as:
(SVR_SOC_VER(svr) == SVR_8548) && (SVR_REV(svr) == 0x20)
instead of:
(pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020)
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
drivers/net/ethernet/freescale/gianfar.c | 33 ++++++++++++++++++++++++--------
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index db5fc7b..329a206 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -88,6 +88,7 @@
#include <asm/io.h>
#include <asm/reg.h>
+#include <asm/mpc85xx.h>
#include <asm/irq.h>
#include <asm/uaccess.h>
#include <linux/module.h>
@@ -939,17 +940,13 @@ static void gfar_init_filer_table(struct gfar_private *priv)
}
}
-static void gfar_detect_errata(struct gfar_private *priv)
+static void __gfar_detect_errata_83xx(struct gfar_private *priv)
{
- struct device *dev = &priv->ofdev->dev;
unsigned int pvr = mfspr(SPRN_PVR);
unsigned int svr = mfspr(SPRN_SVR);
unsigned int mod = (svr >> 16) & 0xfff6; /* w/o E suffix */
unsigned int rev = svr & 0xffff;
- /* no plans to fix */
- priv->errata |= GFAR_ERRATA_A002;
-
/* MPC8313 Rev 2.0 and higher; All MPC837x */
if ((pvr == 0x80850010 && mod == 0x80b0 && rev >= 0x0020) ||
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
@@ -960,10 +957,30 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_76;
- /* MPC8313 Rev < 2.0, MPC8548 rev 2.0 */
- if ((pvr == 0x80850010 && mod == 0x80b0 && rev < 0x0020) ||
- (pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020))
+ /* MPC8313 Rev < 2.0 */
+ if (pvr == 0x80850010 && mod == 0x80b0 && rev < 0x0020)
+ priv->errata |= GFAR_ERRATA_12;
+}
+
+static void __gfar_detect_errata_85xx(struct gfar_private *priv)
+{
+ unsigned int svr = mfspr(SPRN_SVR);
+
+ if ((SVR_SOC_VER(svr) == SVR_8548) && (SVR_REV(svr) == 0x20))
priv->errata |= GFAR_ERRATA_12;
+}
+
+static void gfar_detect_errata(struct gfar_private *priv)
+{
+ struct device *dev = &priv->ofdev->dev;
+
+ /* no plans to fix */
+ priv->errata |= GFAR_ERRATA_A002;
+
+ if (pvr_version_is(PVR_VER_E500V1) || pvr_version_is(PVR_VER_E500V2))
+ __gfar_detect_errata_85xx(priv);
+ else /* non-mpc85xx parts, i.e. e300 core based */
+ __gfar_detect_errata_83xx(priv);
if (priv->errata)
dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
--
1.7.11.7
^ permalink raw reply related
* Re: IPv6 kernel warning
From: Yuchung Cheng @ 2013-10-09 17:33 UTC (permalink / raw)
To: dormando
Cc: Michele Baldessari, Russell King - ARM Linux, netdev,
Neal Cardwell, Nandita Dukkipati
In-Reply-To: <CAK6E8=d5VWMoOpDhZR4WaU6V6NJ9YSvJr=mm=rYNir0z644H=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6631 bytes --]
On Tue, Oct 8, 2013 at 1:53 PM, Yuchung Cheng <ycheng@google.com> wrote:
>
> On Tue, Oct 8, 2013 at 11:24 AM, dormando <dormando@rydia.net> wrote:
> > On Mon, 7 Oct 2013, Yuchung Cheng wrote:
> >
> >> On Mon, Oct 7, 2013 at 12:56 PM, dormando <dormando@rydia.net> wrote:
> >> > On Mon, 7 Oct 2013, Yuchung Cheng wrote:
> >> >
> >> >> On Mon, Oct 7, 2013 at 11:13 AM, dormando <dormando@rydia.net> wrote:
> >> >> >
> >> >> > > >
> >> >> > > > there's been multiple reports about this one:
> >> >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=989251
> >> >> > > > http://bugzilla.kernel.org/show_bug.cgi?id=60779
> >> >> > > >
> >> >> > > > Could you try Yuchung's debug patch?
> >> >> > > > http://www.spinics.net/lists/netdev/msg250193.html
> >> >> > > Yes it looks like the same bug. Please try that patch to help identify
> >> >> > > this elusive bug.
> >> >> > >
> >> >> >
> >> >> > Hi!
> >> >> >
> >> >> > We get this one a few times a day in production. Here's a warning with
> >> >> > your debug trace in the line immediately following:
> >> >> > (I censored a few things)
> >> >> >
> >> >> > [125311.721950] ------------[ cut here ]------------
> >> >> > [125311.721961] WARNING: at net/ipv4/tcp_input.c:2776 tcp_fastretrans_alert+0xb58/0xc80()
> >> >> > [125311.721962] Modules linked in: bridge ip_vs macvlan coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog microcode ipmi_devintf sb_edac lpc_ich edac_core mfd_core ipmi_si ipmi_msghandler iptable_nat nf_nat_ipv4 nf_nat ixgbe igb mdio i2c_algo_bit ptp pps_core
> >> >> > [125311.721981] CPU: 11 PID: 0 Comm: swapper/11 Not tainted 3.10.13 #1
> >> >> > [125311.721982] Hardware name: Supermicro XXXXXXXXXXX, BIOS 1.1 10/03/2012
> >> >> > [125311.721984] ffffffff81a82007 ffff88407fc63958 ffffffff816bb9cc ffff88407fc63998
> >> >> > [125311.721986] ffffffff8104b940 00ff8840ad904f82 ffff883b8a165b00 0000000000004120
> >> >> > [125311.721989] 0000000000000001 0000000000000019 0000000000000000 ffff88407fc639a8
> >> >> > [125311.721991] Call Trace:
> >> >> > [125311.721992] <IRQ> [<ffffffff816bb9cc>] dump_stack+0x19/0x1d
> >> >> > [125311.722002] [<ffffffff8104b940>] warn_slowpath_common+0x70/0xa0
> >> >> > [125311.722005] [<ffffffff8104b98a>] warn_slowpath_null+0x1a/0x20
> >> >> > [125311.722007] [<ffffffff81616db8>] tcp_fastretrans_alert+0xb58/0xc80
> >> >> > [125311.722011] [<ffffffff8161891f>] tcp_ack+0x6df/0xe90
> >> >> > [125311.722016] [<ffffffff8164e0ca>] ? ipt_do_table+0x22a/0x680
> >> >> > [125311.722018] [<ffffffff816194b3>] ? tcp_validate_incoming+0x63/0x320
> >> >> > [125311.722021] [<ffffffff8161a55c>] tcp_rcv_established+0x2cc/0x810
> >> >> > [125311.722023] [<ffffffff81622c84>] tcp_v4_do_rcv+0x254/0x4f0
> >> >> > [125311.722025] [<ffffffff816245ac>] tcp_v4_rcv+0x5fc/0x750
> >> >> > [125311.722027] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
> >> >> > [125311.722032] [<ffffffff815df3ad>] ? nf_hook_slow+0x7d/0x160
> >> >> > [125311.722034] [<ffffffff815ffa00>] ? ip_rcv+0x350/0x350
> >> >> > [125311.722036] [<ffffffff815fface>] ip_local_deliver_finish+0xce/0x250
> >> >> > [125311.722037] [<ffffffff815ffc9c>] ip_local_deliver+0x4c/0x80
> >> >> > [125311.722039] [<ffffffff815ff329>] ip_rcv_finish+0x119/0x360
> >> >> > [125311.722040] [<ffffffff815ff8e0>] ip_rcv+0x230/0x350
> >> >> > [125311.722046] [<ffffffff815b4067>] __netif_receive_skb_core+0x477/0x600
> >> >> > [125311.722049] [<ffffffff815b4217>] __netif_receive_skb+0x27/0x70
> >> >> > [125311.722051] [<ffffffff815b4354>] process_backlog+0xf4/0x1e0
> >> >> > [125311.722053] [<ffffffff815b4b45>] net_rx_action+0xf5/0x250
> >> >> > [125311.722056] [<ffffffff81053a5f>] __do_softirq+0xef/0x270
> >> >> > [125311.722058] [<ffffffff81053cb5>] irq_exit+0x95/0xa0
> >> >> > [125311.722062] [<ffffffff816c8f26>] do_IRQ+0x66/0xe0
> >> >> > [125311.722065] [<ffffffff816bf62a>] common_interrupt+0x6a/0x6a
> >> >> > [125311.722065] <EOI> [<ffffffff8100abf1>] ? default_idle+0x21/0xc0
> >> >> > [125311.722082] [<ffffffff8100a54f>] arch_cpu_idle+0xf/0x20
> >> >> > [125311.722086] [<ffffffff8108f353>] cpu_startup_entry+0xb3/0x230
> >> >> > [125311.722091] [<ffffffff816b439e>] start_secondary+0x1dc/0x1e3
> >> >> > [125311.722093] ---[ end trace e77cd5ba583fcbe9 ]---
> >> >> > [125311.722096] 355.355.1.355:22496 F0x4120 S1 s7 IF25+17-1-24f0 ur57 rr3 rt0 um0 hs23120 nxt23120
> >> >> >
> >> >> > It's been happening with all 3.10 kernels, and the one above is .13 as
> >> >> > stated in the trace.
> >> >>
> >> >> Thanks! could you post the output of `sysctl -a |grep tcp`?
> >> >>
> >> >> I suspect tcp_process_tlp_ack() should not revert state to Open
> >> >> directly, but calling tcp_try_keep_open() instead, similar to all the
> >> >> undo processing in the tcp_fastretrans_alert(): after
> >> >> tcp_end_cwnd_reduction(), the process (E) falls back to check other
> >> >> stats before moving to CA_Open.
> >> >>
> >> >>
> >> >> index 9c62257..9012b42 100644
> >> >> --- a/net/ipv4/tcp_input.c
> >> >> +++ b/net/ipv4/tcp_input.c
> >> >> @@ -3314,7 +3314,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack,
> >> >> tcp_init_cwnd_reduction(sk, true);
> >> >> tcp_set_ca_state(sk, TCP_CA_CWR);
> >> >> tcp_end_cwnd_reduction(sk);
> >> >> - tcp_set_ca_state(sk, TCP_CA_Open);
> >> >> + tcp_try_keep_open(sk);
> >> >> NET_INC_STATS_BH(sock_net(sk),
> >> >> LINUX_MIB_TCPLOSSPROBERECOVERY);
> >> >> }
> >> >>
> >> >
> >> > Should I apply this and see if the warning stops?
Hi Dormando,
Could you try this patch to make sure it fixes the warning (with
sysctl net.ipv4.early_retrans=3)?
> >> I'd like to hear what the authors of TLP think. In the mean time could
> >> you help us collect more evidence by disabling TLP with
> >> sysctl net.ipv4.tcp_early_retrans=2
> >> and see if the problem still occurs? (it should not).
> >>
> >> thanks
> >
> > Box hasn't had a warning in the last 24ish hours. A neighboring machine
> > with the default tcp_early_retrans setting has had 5-6 in the same
> > timeframe.
> >
> > Is this a harmful situation to the socket in any way, or is it just
> > informational weirdness?
> It should be fairly harmless. The ack that triggers the warning should
> set the TCP back to the good (non-Open) state, but it's still good to
> get rid of.
[-- Attachment #2: 0001-tcp-fix-incorrect-ca_state-in-tail-loss-probe.patch --]
[-- Type: application/octet-stream, Size: 1356 bytes --]
From 6aacfe24692341ac93c1d153a801c34066b86262 Mon Sep 17 00:00:00 2001
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 9 Oct 2013 10:08:52 -0700
Subject: [PATCH] tcp: fix incorrect ca_state in tail loss probe
On receiving an ACK that covers the loss probe sequence, TLP
immediately sets the congestion state to Open, even though some packets
are not recovered and retransmisssion are on the way. The later ACks
may trigger a WARN_ON check of step D in tcp_fastretrans_alert().
The fix is to follow the similar procedure in recovery by calling
tcp_try_keep_open(). The sender switches to Open state if no packets
are retransmissted. Otherwise it goes to Disorder and let subsequent
ACKs move the state to Recovery or Open.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 113dc5f..53974c7 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3291,7 +3291,7 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack, int flag)
tcp_init_cwnd_reduction(sk, true);
tcp_set_ca_state(sk, TCP_CA_CWR);
tcp_end_cwnd_reduction(sk);
- tcp_set_ca_state(sk, TCP_CA_Open);
+ tcp_try_keep_open(sk);
NET_INC_STATS_BH(sock_net(sk),
LINUX_MIB_TCPLOSSPROBERECOVERY);
}
--
1.8.4
^ permalink raw reply related
* Re: pull request (net): ipsec 2013-10-09
From: David Miller @ 2013-10-09 17:44 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1381316351-14418-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 9 Oct 2013 12:59:04 +0200
> 1) We used the wrong netlink attribute to verify the
> lenght of the replay window on async events. Fix this by
> using the right netlink attribute.
>
> 2) Policy lookups can not match the output interface on forwarding.
> Add the needed informations to the flow informations.
>
> 3) We update the pmtu when we receive a ICMPV6_DEST_UNREACH message
> on IPsec with ipv6. This is wrong and leads to strange fragmented
> packets, only ICMPV6_PKT_TOOBIG messages should update the pmtu.
> Fix this by removing the ICMPV6_DEST_UNREACH check from the IPsec
> protocol error handlers.
>
> 4) The legacy IPsec anti replay mechanism supports anti replay
> windows up to 32 packets. If a user requests for a bigger
> anti replay window, we use 32 packets but pretend that we use
> the requested window size. Fix from Fan Du.
>
> 5) If asynchronous events are enabled and replay_maxdiff is set to
> zero, we generate an async event for every received packet instead
> of checking whether a timeout occurred. Fix from Thomas Egerer.
>
> 6) Policies need a refcount when the state resolution timer is armed.
> Otherwise the timer can fire after the policy is deleted.
>
> 7) We might dreference a NULL pointer if the hold_queue is empty,
> add a check to avoid this.
>
> Please pull or let me know if there are problems.
Pulled, thanks a lot Steffen.
^ permalink raw reply
* Re: pull request: batman-adv 2013-10-09
From: David Miller @ 2013-10-09 17:56 UTC (permalink / raw)
To: antonio; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1381322418-1349-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Wed, 9 Oct 2013 14:40:02 +0200
> Hello David,
>
> this is a set of changes intended for net-next/linux-3.13.
>
> As introduced one year ago (http://article.gmane.org/gmane.org.freifunk.batman/8484)
> in the last period we have been busy working on giving our batman-adv
> protocol/packet-format all those means to get stable and avoid incompatibilities
> in the near future (this is also why we did not send many changes for
> linux-3.12..).
>
> With this patchset we are finally switching to a new compatibility version and
> within this development cycle I will send you all those changes aimed to
> introduce all the needed mechanism to avoid any further compatibility breakage.
>
> First of all, in this batch you have the new TVLV code (Type Version Value
> Length) which is the first very important milestone towards our goal[1].
> With this mechanism we will be able to improve/change the packet contents layout
> (used by the various features) without breaking compatibility with older
> protocol versions anymore.
> The development of this new component has been started by Spyros Gasteratos
> during his Google Summer of Code 2012 and then adjusted, finished and submitted
> by Marek Lindner.
>
> Together with it, you have a set of improvements that we are allowed to apply
> thanks to the switching to the new compat version.
> These changes are:
> - adapt the existing features to make them use the new TVLV mechanism
> - move from CRC16 to CRC32c for table correctness check in the TT component
> - reorder some of the flags sent over the wire
> - remove the __packed attribute from the OGM packet struct.
>
> Moreover, with this patchset we are totally removing our VISualisation component
> that is now implemented in userspace.
>
> Please pull let me know of any problem.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH 1/3] gianfar: Enable eTSEC-A002 erratum w/a for all parts
From: David Miller @ 2013-10-09 18:02 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, linuxppc-dev
In-Reply-To: <1381339242-32030-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Wed, 9 Oct 2013 20:20:40 +0300
> A002 is still in "no plans to fix" state, and applies to all
> the current P1/P2 parts as well, so it's resonable to enable
> its workaround by default, for all the soc's with etsec.
> The impact of not enabling this workaround for affected parts
> is that under certain conditons (runt frames or even frames
> with RX error detected at PHY level) during controller reset,
> the controller might fail to indicate Rx reset (GRS) completion.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] gianfar: Use mpc85xx support for errata detection
From: David Miller @ 2013-10-09 18:02 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, linuxppc-dev
In-Reply-To: <1381339242-32030-2-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Wed, 9 Oct 2013 20:20:41 +0300
> Use the macros and defines from mpc85xx.h to simplify
> and prevent errors in identifying a mpc85xx based SoC
> for errata detection.
> This should help enabling (and identifying) workarounds
> for various mpc85xx based chips and revisions.
> For instance, express MPC8548 Rev.2 as:
> (SVR_SOC_VER(svr) == SVR_8548) && (SVR_REV(svr) == 0x20)
> instead of:
> (pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020)
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] gianfar: Enable eTSEC-20 erratum w/a for P2020 Rev1
From: David Miller @ 2013-10-09 18:02 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, linuxppc-dev
In-Reply-To: <1381339242-32030-3-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Wed, 9 Oct 2013 20:20:42 +0300
> Enable workaround for P2020/P2010 erratum eTSEC 20,
> "Excess delays when transmitting TOE=1 large frames".
> The impact is that frames lager than 2500-bytes for which
> TOE (i.e. TCP/IP hw accelerations like Tx csum) is enabled
> may see excess delay before start of transmission.
> This erratum was fixed in Rev 2.0.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Applied.
^ permalink raw reply
* Re: pull request: wireless 2013-10-09
From: David Miller @ 2013-10-09 18:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20131009152841.GD14381@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 9 Oct 2013 11:28:41 -0400
> Please pull this batch of fixes intended for 3.12...
>
> Most of the bits are for iwlwifi -- Johannes says:
>
> "I have a fix for WoWLAN/D3, a PCIe device fix, we're removing a
> warning, there's a fix for RF-kill while scanning (which goes together
> with a mac80211 fix) and last but not least we have many new PCI IDs."
>
> Also for iwlwifi is a patch from Johannes to correct some merge damage
> that crept into the tree before the last merge window.
>
> On top of that, Felix Fietkau sends an ath9k patch to avoid a Tx
> scheduling hang when changing channels to do a scan.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
^ 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