* Re: [PATCHv1 net] xen-netback: support frontends without feature-rx-notify again
From: David Vrabel @ 2014-12-18 17:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev, xen-devel, ian.campbell, wei.liu2
In-Reply-To: <20141218.125009.1837191564956948256.davem@davemloft.net>
On 18/12/14 17:50, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Thu, 18 Dec 2014 11:13:06 +0000
>
>> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
>> feature-rx-notify mandatory) incorrectly assumed that there were no
>> frontends in use that did not support this feature. But the frontend
>> driver in MiniOS does not and since this is used by (qemu) stubdoms,
>> these stopped working.
>>
>> Netback sort of works as-is in this mode except:
>>
>> - If there are no Rx requests and the internal Rx queue fills, only
>> the drain timeout will wake the thread. The default drain timeout
>> of 10 s would give unacceptable pauses.
>>
>> - If an Rx stall was detected and the internal Rx queue is drained,
>> then the Rx thread would never wake.
>>
>> Handle these two cases (when feature-rx-notify is disabled) by:
>>
>> - Reducing the drain timeout to 30 ms.
>>
>> - Disabling Rx stall detection.
>>
>> Reported-by: John <jw@nuclearfallout.net>
>> Tested-by: John <jw@nuclearfallout.net>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>
> Applied, and I assume that 3.18 -stable needs this as well?
Yes, please. Without it, netback just doesn't work with an important
use case.
Thanks.
David
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: changes for wireless
From: John W. Linville @ 2014-12-18 17:58 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141218.124231.114306102839964827.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, Dec 18, 2014 at 12:42:31PM -0500, David Miller wrote:
> From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Date: Wed, 17 Dec 2014 12:07:05 -0500
>
> > http://marc.info/?l=linux-wireless&m=141883202530292&w=2
> >
> > This makes it official... :-)
> >
> > Signed-off-by: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
>
> Applied, and thank you for all of your tireless work over the many
> years that you have maintained the wireless code.
>
> You have undoubtedly made my life easier and made things run much more
> smoothly than they otherwise would have, and for that I am eternally
> grateful.
>
> Thank you!
Thanks, Dave and everyone else, for the kind words of appreciation.
They are warmly received!
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Varlese, Marco @ 2014-12-18 18:02 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev@vger.kernel.org, Fastabend, John R, Thomas Graf,
Jiri Pirko, sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <549313B8.6050102@cumulusnetworks.com>
Removed unnecessary content for ease of reading...
> >>>>> +/* Switch Port Attributes section */
> >>>>> +
> >>>>> +enum {
> >>>>> + IFLA_ATTR_UNSPEC,
> >>>>> + IFLA_ATTR_LEARNING,
> >>>> Any reason you want learning here ?. This is covered as part of
> >>>> the bridge setlink attributes.
> >>>>
> >>> Yes, because the user may _not_ want to go through a bridge
> >>> interface
> >> necessarily.
> >> But, the bridge setlink/getlink interface was changed to accommodate
> 'self'
> >> for exactly such cases.
> >> I kind of understand your case for the other attributes (these are
> >> per port settings that switch asics provide).
> >>
> >> However, i don't understand the reason to pull in bridge attributes here.
> >>
> > Maybe, I am missing something so you might help. The learning attribute -
> in my case - it is like all other attributes: a port attribute (as you said, port
> settings that the switch provides per port).
> > So, what I was saying is "why the user shall go through a bridge to configure
> the learning attribute"? From my perspective, it is as any other attribute and
> as such configurable on the port.
>
> Thinking about this some more, i don't see why any of these attributes
> (except loopback. I dont understand the loopback attribute) cant be part of
> the birdge port attributes.
>
> With this we will end up adding l2 attributes in two places: the general link
> attributes and bridge attributes.
>
> And since we have gone down the path of using ndo_bridge_setlink/getlink
> with 'self'....we should stick to that for all l2 attributes.
>
> The idea of overloading ndo_bridge_set/getlink, was to have the same set of
> attributes but support both cases where the user wants to go through the
> bridge driver or directly to the switch port driver. So, you are not really going
> through the bridge driver if you use 'self' and ndo_bridge_setlink/getlink.
>
Roopa, one of the comments I got from Thomas Graf on my v1 patch was that your patch and mine were supplementary ("I think Roopa's patches are supplementary. Not all switchdev users will be backed with a Linux Bridge. I therefore welcome your patches very much")... I also understood by others that the patch made sense for the same reason. I simply do not understand why these attributes (and maybe others in the future) could not be configured directly on a standard port but have to go through a bridge.
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Roopa Prabhu @ 2014-12-18 18:14 UTC (permalink / raw)
To: Varlese, Marco
Cc: netdev@vger.kernel.org, Fastabend, John R, Thomas Graf,
Jiri Pirko, sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B104ADA310@IRSMSX108.ger.corp.intel.com>
On 12/18/14, 10:02 AM, Varlese, Marco wrote:
> Removed unnecessary content for ease of reading...
>
>>>>>>> +/* Switch Port Attributes section */
>>>>>>> +
>>>>>>> +enum {
>>>>>>> + IFLA_ATTR_UNSPEC,
>>>>>>> + IFLA_ATTR_LEARNING,
>>>>>> Any reason you want learning here ?. This is covered as part of
>>>>>> the bridge setlink attributes.
>>>>>>
>>>>> Yes, because the user may _not_ want to go through a bridge
>>>>> interface
>>>> necessarily.
>>>> But, the bridge setlink/getlink interface was changed to accommodate
>> 'self'
>>>> for exactly such cases.
>>>> I kind of understand your case for the other attributes (these are
>>>> per port settings that switch asics provide).
>>>>
>>>> However, i don't understand the reason to pull in bridge attributes here.
>>>>
>>> Maybe, I am missing something so you might help. The learning attribute -
>> in my case - it is like all other attributes: a port attribute (as you said, port
>> settings that the switch provides per port).
>>> So, what I was saying is "why the user shall go through a bridge to configure
>> the learning attribute"? From my perspective, it is as any other attribute and
>> as such configurable on the port.
>>
>> Thinking about this some more, i don't see why any of these attributes
>> (except loopback. I dont understand the loopback attribute) cant be part of
>> the birdge port attributes.
>>
>> With this we will end up adding l2 attributes in two places: the general link
>> attributes and bridge attributes.
>>
>> And since we have gone down the path of using ndo_bridge_setlink/getlink
>> with 'self'....we should stick to that for all l2 attributes.
>>
>> The idea of overloading ndo_bridge_set/getlink, was to have the same set of
>> attributes but support both cases where the user wants to go through the
>> bridge driver or directly to the switch port driver. So, you are not really going
>> through the bridge driver if you use 'self' and ndo_bridge_setlink/getlink.
>>
> Roopa, one of the comments I got from Thomas Graf on my v1 patch was that your patch and mine were supplementary ("I think Roopa's patches are supplementary. Not all switchdev users will be backed with a Linux Bridge. I therefore welcome your patches very much")... I also understood by others that the patch made sense for the same reason. I simply do not understand why these attributes (and maybe others in the future) could not be configured directly on a standard port but have to go through a bridge.
>
ok, i am very confused in that case. The whole moving of bridge
attributes from the bridge driver to rtnetlink.c was to make the bridge
attributes accessible to any driver who wants to set l2/bridge
attributes on their switch ports. So, its unclear to me why we are doing
this parallel thing again.
This move to rtnetlink.c was done during the recent rocker support. so,
maybe scott/jiri can elaborate more.
^ permalink raw reply
* Re: [PATCH net 2/2] geneve: Fix races between socket add and release.
From: Jesse Gross @ 2014-12-18 18:34 UTC (permalink / raw)
To: Thomas Graf; +Cc: David Miller, netdev, Andy Zhou, Stephen Hemminger
In-Reply-To: <20141217211513.GF28766@casper.infradead.org>
On Wed, Dec 17, 2014 at 1:15 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 12/17/14 at 10:48am, Jesse Gross wrote:
>> I generally agree (with the exception of kfree_rcu() - I believe that
>> is still needed since incoming packets reference it using RCU).
>
> I didn't inspect this in full detail but seems like the data path
> should only care about gs->sock which is properly refcnt'ed.
The data path (if you include the consumer in OVS), goes from sk to gs
to gs->rcv_data so it does care about the stuff that is being freed
here.
>> for destroying the socket. This was added by Stephen in "vxlan: listen
>> on multiple ports" but it's not obvious to me what problem it is
>> trying to avoid and I don't see a comment. If possible, it would be
>> nice to simplify this as well if the issue doesn't apply to Geneve.
>
> I don't have an explanation for that either. Each entry on the
> vni_list[] takes a vs->refcnt.
I don't think the workqueue is about refcounting - it looks to me like
the issue that is being avoided is either that RTNL is held and a
lower layer tries to take it again or another lock that nests in the
opposite way with RTNL. However, looking through the code, the problem
wasn't obvious to me.
^ permalink raw reply
* Re: [PATCH net] netlink: Don't reorder loads/stores before marking mmap netlink frame as available
From: Linus Torvalds @ 2014-12-18 19:13 UTC (permalink / raw)
To: Thomas Graf
Cc: Eric Dumazet, David Miller, Daniel Borkmann, Andy Lutomirski,
Patrick McHardy, Network Development
In-Reply-To: <20141218103026.GA16239@casper.infradead.org>
On Thu, Dec 18, 2014 at 2:30 AM, Thomas Graf <tgraf@suug.ch> wrote:
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index ef5f77b..2662821 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -550,9 +550,9 @@ static enum nl_mmap_status netlink_get_status(const struct nl_mmap_hdr *hdr)
> static void netlink_set_status(struct nl_mmap_hdr *hdr,
> enum nl_mmap_status status)
> {
> + smp_mb();
> hdr->nm_status = status;
> flush_dcache_page(pgvec_to_page(hdr));
> - smp_wmb();
> }
If this is performance-critical code (I have no idea), then a better
idea might be to use
smp_store_release(&hdr->nm_status, status);
instead of using explicit memory barriers. That's going to generally
be much cheaper than a memory barrier.
Linus
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Bjorn Helgaas @ 2014-12-18 19:15 UTC (permalink / raw)
To: Michael Chan
Cc: Marcelo Ricardo Leitner, Rajat Jain, Nils Holland, David Miller,
netdev, linux-pci@vger.kernel.org, Rafael Wysocki,
Prashant Sreedharan
In-Reply-To: <1418759684.4248.12.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
On Tue, Dec 16, 2014 at 12:54 PM, Michael Chan <mchan@broadcom.com> wrote:
> On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote:
>> It's a
>> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
>> Gigabit Ethernet PCI Express
>> over here
>>
>> I put a WARN_ON(1) after those printks, and this is what I got:
>>
>> [ 1.550640] pci 0000:02:00.0: 1st 1 1
>> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0
>> [ 1.550645] ------------[ cut here ]------------
>> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0()
>> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video
>> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8
>> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013
>> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46
>> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41
>> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000
>> [ 1.550669] Call Trace:
>> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58
>> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0
>> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20
>> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0
>> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50
>> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3]
>> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3]
>> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3]
>
> So does it work if you use a non-zero crs_timeout? The driver has
> called tg3_halt() which may affect configuration read responses. I need
> to check with the hardware team to see if the 5722 will return CRS in
> this scenario.
Any updates from the hardware team?
This is a pretty serious regression, but as far as I can tell, it is
not a PCI bug. The device should respond to a config read of vendor
ID. If the driver does something that make the read return CRS
status, I think the driver is responsible for doing whatever delay or
other fixup is required.
I'm inclined to reassign this bug to the tg3 driver unless you think
the PCI core is doing something wrong here.
Bjorn
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: John Fastabend @ 2014-12-18 19:21 UTC (permalink / raw)
To: Roopa Prabhu, Varlese, Marco
Cc: netdev@vger.kernel.org, Thomas Graf, Jiri Pirko,
sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <54931969.7040209@cumulusnetworks.com>
On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
> On 12/18/14, 10:02 AM, Varlese, Marco wrote:
>> Removed unnecessary content for ease of reading...
>>
>>>>>>>> +/* Switch Port Attributes section */
>>>>>>>> +
>>>>>>>> +enum {
>>>>>>>> + IFLA_ATTR_UNSPEC,
>>>>>>>> + IFLA_ATTR_LEARNING,
>>>>>>> Any reason you want learning here ?. This is covered as part of
>>>>>>> the bridge setlink attributes.
>>>>>>>
>>>>>> Yes, because the user may _not_ want to go through a bridge
>>>>>> interface
>>>>> necessarily.
>>>>> But, the bridge setlink/getlink interface was changed to accommodate
>>> 'self'
>>>>> for exactly such cases.
>>>>> I kind of understand your case for the other attributes (these are
>>>>> per port settings that switch asics provide).
>>>>>
>>>>> However, i don't understand the reason to pull in bridge attributes here.
>>>>>
>>>> Maybe, I am missing something so you might help. The learning attribute -
>>> in my case - it is like all other attributes: a port attribute (as you said, port
>>> settings that the switch provides per port).
>>>> So, what I was saying is "why the user shall go through a bridge to configure
>>> the learning attribute"? From my perspective, it is as any other attribute and
>>> as such configurable on the port.
>>>
>>> Thinking about this some more, i don't see why any of these attributes
>>> (except loopback. I dont understand the loopback attribute) cant be part of
>>> the birdge port attributes.
>>>
>>> With this we will end up adding l2 attributes in two places: the general link
>>> attributes and bridge attributes.
>>>
>>> And since we have gone down the path of using ndo_bridge_setlink/getlink
>>> with 'self'....we should stick to that for all l2 attributes.
>>>
>>> The idea of overloading ndo_bridge_set/getlink, was to have the same set of
>>> attributes but support both cases where the user wants to go through the
>>> bridge driver or directly to the switch port driver. So, you are not really going
>>> through the bridge driver if you use 'self' and ndo_bridge_setlink/getlink.
>>>
>> Roopa, one of the comments I got from Thomas Graf on my v1 patch
>> was that your patch and mine were supplementary ("I think Roopa's
>> patches are supplementary. Not all switchdev users will be backed
>> with a Linux Bridge. I therefore welcome your patches very
>> much")... I also understood by others that the patch made sense for
>> the same reason. I simply do not understand why these attributes
>> (and maybe others in the future) could not be configured directly
>> on a standard port but have to go through a bridge.
>>
> ok, i am very confused in that case. The whole moving of bridge
> attributes from the bridge driver to rtnetlink.c was to make the
> bridge attributes accessible to any driver who wants to set l2/bridge
> attributes on their switch ports. So, its unclear to me why we are
> doing this parallel thing again. This move to rtnetlink.c was done
> during the recent rocker support. so, maybe scott/jiri can elaborate
> more.
Not sure if this will add to the confusion or help. But you do not
need to have the bridge.ko loaded or netdev's attached to a bridge
to use the setlink/getlink ndo ops and netlink messages.
This was intentionally done. Its already used with NIC devices to
configure embedded bridge settings such as VEB/VEPA.
I think I'm just repeating Roopa though.
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Prashant Sreedharan @ 2014-12-18 19:28 UTC (permalink / raw)
To: Bjorn Helgaas, Marcelo Ricardo Leitner
Cc: Michael Chan, Rajat Jain, Nils Holland, David Miller, netdev,
linux-pci@vger.kernel.org, Rafael Wysocki
In-Reply-To: <CAErSpo7sqZS+-4LHo3wbo-pa73mcP_3d0Z37U0tfnASaxp-D_g@mail.gmail.com>
On Thu, 2014-12-18 at 12:15 -0700, Bjorn Helgaas wrote:
> On Tue, Dec 16, 2014 at 12:54 PM, Michael Chan <mchan@broadcom.com> wrote:
> > On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote:
> >> It's a
> >> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
> >> Gigabit Ethernet PCI Express
> >> over here
> >>
> >> I put a WARN_ON(1) after those printks, and this is what I got:
> >>
> >> [ 1.550640] pci 0000:02:00.0: 1st 1 1
> >> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0
> >> [ 1.550645] ------------[ cut here ]------------
> >> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0()
> >> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video
> >> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8
> >> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013
> >> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46
> >> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41
> >> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000
> >> [ 1.550669] Call Trace:
> >> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58
> >> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0
> >> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20
> >> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0
> >> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50
> >> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3]
> >> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3]
> >> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3]
> >
> > So does it work if you use a non-zero crs_timeout? The driver has
> > called tg3_halt() which may affect configuration read responses. I need
> > to check with the hardware team to see if the 5722 will return CRS in
> > this scenario.
>
> Any updates from the hardware team?
>
> This is a pretty serious regression, but as far as I can tell, it is
> not a PCI bug. The device should respond to a config read of vendor
> ID. If the driver does something that make the read return CRS
> status, I think the driver is responsible for doing whatever delay or
> other fixup is required.
>
> I'm inclined to reassign this bug to the tg3 driver unless you think
> the PCI core is doing something wrong here.
>
> Bjorn
We were not able to reproduce this issue, could you please check what is
the value of reg 0x70, before the pci_device_is_present call is made ?
if bit 15 is set config access will be retried.
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -9025,6 +9025,7 @@ static int tg3_chip_reset(struct tg3 *tp)
void (*write_op)(struct tg3 *, u32, u32);
int i, err;
+ printk(KERN_ERR "config state: %x\n", tr32(TG3PCI_PCISTATE));
if (!pci_device_is_present(tp->pdev))
return -ENODEV;
^ permalink raw reply
* Re: [iwlwifi] BUG: unable to handle kernel
From: Grumbach, Emmanuel @ 2014-12-18 19:42 UTC (permalink / raw)
To: Wu, Fengguang
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, lkp@01.org,
linux-leds@vger.kernel.org
In-Reply-To: <20141218171309.GD9298@wfg-t540p.sh.intel.com>
On Thu, 2014-12-18 at 09:13 -0800, Fengguang Wu wrote:
> Hi All,
>
> I don't see any relationship between the BUG and this bisected commit.
> Anyway, it's better to report it to the lists than to ignore.
Right - but I have to say that I have no clue how this comment can cause
the bug you are seeing...
Do you even have an Intel Wireless device the VM could access?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git master
>
> commit 03d6c3b0fa4f5f0379cede079ec828a6c999fe43
> Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> AuthorDate: Wed Dec 3 10:39:07 2014 +0200
> Commit: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> CommitDate: Sun Dec 14 10:20:29 2014 +0200
>
> iwlwifi: pcie: re-ACK all interrupts after device reset
>
> When we reset the device, the CSR_INT gets cleared as well
> as CSR_INT_MASK. Meaning that we shouldn't get any interrupt
> but, due to a hardware bug, recent devices will keep sending
> interrupts. This leads to an interrupt storm while stopping
> the device.
> The way to fix this is to ACK all the interrupts after the
> device is reset so that the value of CSR_INT will stay
> 0xffffffff.
>
> Fixes: 522713c81e4e ("iwlwifi: pcie: properly reset the device")
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>
> +------------------------------------------+------------+------------+------------+
> | | 0a79a0c011 | 03d6c3b0fa | iwlwifi-fi |
> +------------------------------------------+------------+------------+------------+
> | boot_successes | 60 | 19 | 3 |
> | boot_failures | 0 | 1 | 9 |
> | BUG:unable_to_handle_kernel | 0 | 1 | 9 |
> | Oops | 0 | 1 | 9 |
> | RIP:strcmp | 0 | 1 | 9 |
> | Kernel_panic-not_syncing:Fatal_exception | 0 | 1 | 9 |
> | backtrace:led_trigger_register_simple | 0 | 1 | 9 |
> | backtrace:ledtrig_usb_init | 0 | 1 | 9 |
> | backtrace:kernel_init_freeable | 0 | 1 | 9 |
> +------------------------------------------+------------+------------+------------+
>
> [ 5.345018] g_serial gadget: Gadget Serial v2.4
> [ 5.345927] g_serial gadget: g_serial ready
> [ 5.345927] g_serial gadget: g_serial ready
> [ 5.346777] BUG: unable to handle kernel
> [ 5.346777] BUG: unable to handle kernel paging requestpaging request at ffff88000004e5f0
> at ffff88000004e5f0
> [ 5.348183] IP:
> [ 5.348183] IP: [<ffffffff81446a68>] strcmp+0x6/0x20
> [<ffffffff81446a68>] strcmp+0x6/0x20
> [ 5.349183] PGD 37f1067
> [ 5.349183] PGD 37f1067 PUD 37f2067 PUD 37f2067 PMD 37f3067 PMD 37f3067 PTE 800000000004e060PTE 800000000004e060
>
> [ 5.350498] Oops: 0000 [#1]
> [ 5.350498] Oops: 0000 [#1] DEBUG_PAGEALLOCDEBUG_PAGEALLOC
>
> [ 5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> [ 5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> [ 5.352660] task: ffff880012060000 ti: ffff88001204c000 task.ti: ffff88001204c000
> [ 5.352660] task: ffff880012060000 ti: ffff88001204c000 task.ti: ffff88001204c000
> [ 5.354143] RIP: 0010:[<ffffffff81446a68>]
> [ 5.354143] RIP: 0010:[<ffffffff81446a68>] [<ffffffff81446a68>] strcmp+0x6/0x20
> [<ffffffff81446a68>] strcmp+0x6/0x20
> [ 5.354451] RSP: 0000:ffff88001204fe28 EFLAGS: 00010246
> [ 5.354451] RSP: 0000:ffff88001204fe28 EFLAGS: 00010246
> [ 5.354451] RAX: 0000000000000000 RBX: ffff88000c08fe00 RCX: ffffffff81d35310
> [ 5.354451] RAX: 0000000000000000 RBX: ffff88000c08fe00 RCX: ffffffff81d35310
> [ 5.354451] RDX: ffff88000c08fe68 RSI: ffffffff826d05be RDI: ffff88000004e5f0
> [ 5.354451] RDX: ffff88000c08fe68 RSI: ffffffff826d05be RDI: ffff88000004e5f0
> [ 5.354451] RBP: ffff88001204fe28 R08: 0000000000000001 R09: 000000000000033a
> [ 5.354451] RBP: ffff88001204fe28 R08: 0000000000000001 R09: 000000000000033a
> [ 5.354451] R10: 0000000000000000 R11: ffffffff82531cd1 R12: ffff88000c19fa00
> [ 5.354451] R10: 0000000000000000 R11: ffffffff82531cd1 R12: ffff88000c19fa00
> [ 5.354451] R13: 0000000000000000 R14: ffffffff837958b8 R15: 0000000000000000
> [ 5.354451] R13: 0000000000000000 R14: ffffffff837958b8 R15: 0000000000000000
> [ 5.354451] FS: 0000000000000000(0000) GS:ffffffff82789000(0000) knlGS:0000000000000000
> [ 5.354451] FS: 0000000000000000(0000) GS:ffffffff82789000(0000) knlGS:0000000000000000
> [ 5.354451] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 5.354451] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 5.354451] CR2: ffff88000004e5f0 CR3: 0000000002776000 CR4: 00000000000006b0
> [ 5.354451] CR2: ffff88000004e5f0 CR3: 0000000002776000 CR4: 00000000000006b0
> [ 5.354451] Stack:
> [ 5.354451] Stack:
> [ 5.354451] ffff88001204fe58
> [ 5.354451] ffff88001204fe58 ffffffff81d35334 ffffffff81d35334 0000000000000000 0000000000000000 ffff88000c19fa00 ffff88000c19fa00
>
> [ 5.354451] ffffffff826d05be
> [ 5.354451] ffffffff826d05be 0000000000000000 0000000000000000 ffff88001204fe88 ffff88001204fe88 ffffffff81d35648 ffffffff81d35648
>
> [ 5.354451] ffff88000e3bbcc0
> [ 5.354451] ffff88000e3bbcc0 ffffffff82b3fe61 ffffffff82b3fe61 0000000000000000 0000000000000000 ffffffff82b98910 ffffffff82b98910
>
> [ 5.354451] Call Trace:
> [ 5.354451] Call Trace:
> [ 5.354451] [<ffffffff81d35334>] led_trigger_register+0x63/0x129
> [ 5.354451] [<ffffffff81d35334>] led_trigger_register+0x63/0x129
> [ 5.354451] [<ffffffff81d35648>] led_trigger_register_simple+0x35/0x79
> [ 5.354451] [<ffffffff81d35648>] led_trigger_register_simple+0x35/0x79
> [ 5.354451] [<ffffffff82b3fe61>] ? gs_bind+0xea/0xea
> [ 5.354451] [<ffffffff82b3fe61>] ? gs_bind+0xea/0xea
> [ 5.354451] [<ffffffff82b3fe78>] ledtrig_usb_init+0x17/0x2e
> [ 5.354451] [<ffffffff82b3fe78>] ledtrig_usb_init+0x17/0x2e
> [ 5.354451] [<ffffffff82b00044>] do_one_initcall+0xe6/0x171
> [ 5.354451] [<ffffffff82b00044>] do_one_initcall+0xe6/0x171
> [ 5.354451] [<ffffffff82b001c7>] kernel_init_freeable+0xf8/0x180
> [ 5.354451] [<ffffffff82b001c7>] kernel_init_freeable+0xf8/0x180
> [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> [ 5.354451] [<ffffffff8206079a>] kernel_init+0x9/0xd0
> [ 5.354451] [<ffffffff8206079a>] kernel_init+0x9/0xd0
> [ 5.354451] [<ffffffff8207d2ba>] ret_from_fork+0x7a/0xb0
> [ 5.354451] [<ffffffff8207d2ba>] ret_from_fork+0x7a/0xb0
> [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> [ 5.354451] Code:
> [ 5.354451] Code: c0 c0 eb eb f5 f5 31 31 c9 c9 40 40 8a 8a 3c 3c 0e 0e 4d 4d 8d 8d 0c 0c 08 08 40 40 84 84 ff ff 41 41 88 88 3c 3c 08 08 74 74 0d 0d 48 48 ff ff c1 c1 48 48 39 39 ca ca 75 75 e7 e7 41 41 c6 c6 41 41 01 01 00 00 5d 5d c3 c3 55 55 31 31 c0 c0 48 48 89 89 e5 e5 <8a> <8a> 14 14 07 07 3a 3a 14 14 06 06 74 74 07 07 19 19 c0 c0 83 83 c8 c8 01 01 eb eb 09 09 48 48 ff ff c0 c0 84 84 d2 d2 75 75
>
> [ 5.354451] RIP
> [ 5.354451] RIP [<ffffffff81446a68>] strcmp+0x6/0x20
> [<ffffffff81446a68>] strcmp+0x6/0x20
> [ 5.354451] RSP <ffff88001204fe28>
> [ 5.354451] RSP <ffff88001204fe28>
> [ 5.354451] CR2: ffff88000004e5f0
> [ 5.354451] CR2: ffff88000004e5f0
> [ 5.354451] ---[ end trace 8f9377b34c860a0c ]---
> [ 5.354451] ---[ end trace 8f9377b34c860a0c ]---
>
> git bisect start baa21e834941ee5fbe4bd421c871f7c0c5f9a086 70e71ca0af244f48a5dcf56dc435243792e3a495 --
> git bisect bad 03d6c3b0fa4f5f0379cede079ec828a6c999fe43 # 16:23 0- 1 iwlwifi: pcie: re-ACK all interrupts after device reset
> git bisect good 0a79a0c011cb291675e3b80760a452fcba5c59d9 # 16:28 20+ 0 iwlwifi: mvm: clear IN_HW_RESTART flag on stop()
> # first bad commit: [03d6c3b0fa4f5f0379cede079ec828a6c999fe43] iwlwifi: pcie: re-ACK all interrupts after device reset
> git bisect good 0a79a0c011cb291675e3b80760a452fcba5c59d9 # 16:30 60+ 0 iwlwifi: mvm: clear IN_HW_RESTART flag on stop()
> # extra tests on HEAD of iwlwifi-fixes/master
> git bisect bad baa21e834941ee5fbe4bd421c871f7c0c5f9a086 # 16:30 0- 9 iwlwifi: pcie: limit fw chunk sizes given to fh
> # extra tests on tree/branch iwlwifi-fixes/master
> git bisect bad baa21e834941ee5fbe4bd421c871f7c0c5f9a086 # 16:30 0- 9 iwlwifi: pcie: limit fw chunk sizes given to fh
> # extra tests on tree/branch linus/master
> git bisect good 44e8967d591686463e84a88b46b03beba3ab49fb # 16:32 60+ 0 Ceph: remove left-over reject file
> # extra tests on tree/branch next/master
> git bisect good cfaa3a95dd2b402599b1d8122dc3107478db8717 # 16:35 60+ 1 Add linux-next specific files for 20141218
>
>
> This script may reproduce the error.
>
> ----------------------------------------------------------------------------
> #!/bin/bash
>
> kernel=$1
> initrd=quantal-core-x86_64.cgz
>
> wget --no-clobber https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
>
> kvm=(
> qemu-system-x86_64
> -cpu kvm64
> -enable-kvm
> -kernel $kernel
> -initrd $initrd
> -m 320
> -smp 2
> -net nic,vlan=1,model=e1000
> -net user,vlan=1
> -boot order=nc
> -no-reboot
> -watchdog i6300esb
> -rtc base=localtime
> -serial stdio
> -display none
> -monitor null
> )
>
> append=(
> hung_task_panic=1
> earlyprintk=ttyS0,115200
> debug
> apic=debug
> sysrq_always_enabled
> rcupdate.rcu_cpu_stall_timeout=100
> panic=-1
> softlockup_panic=1
> nmi_watchdog=panic
> oops=panic
> load_ramdisk=2
> prompt_ramdisk=0
> console=ttyS0,115200
> console=tty0
> vga=normal
> root=/dev/ram0
> rw
> drbd.minor_count=8
> )
>
> "${kvm[@]}" --append "${append[*]}"
> ----------------------------------------------------------------------------
>
> Thanks,
> Fengguang
> _______________________________________________
> LKP mailing list
> LKP@linux.intel.com
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Marcelo Ricardo Leitner @ 2014-12-18 20:09 UTC (permalink / raw)
To: Prashant Sreedharan, Bjorn Helgaas
Cc: Michael Chan, Rajat Jain, Nils Holland, David Miller, netdev,
linux-pci@vger.kernel.org, Rafael Wysocki
In-Reply-To: <1418930889.3433.8.camel@prashant>
On 18-12-2014 17:28, Prashant Sreedharan wrote:
> On Thu, 2014-12-18 at 12:15 -0700, Bjorn Helgaas wrote:
>> On Tue, Dec 16, 2014 at 12:54 PM, Michael Chan <mchan@broadcom.com> wrote:
>>> On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote:
>>>> It's a
>>>> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
>>>> Gigabit Ethernet PCI Express
>>>> over here
>>>>
>>>> I put a WARN_ON(1) after those printks, and this is what I got:
>>>>
>>>> [ 1.550640] pci 0000:02:00.0: 1st 1 1
>>>> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0
>>>> [ 1.550645] ------------[ cut here ]------------
>>>> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0()
>>>> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video
>>>> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8
>>>> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013
>>>> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46
>>>> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41
>>>> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000
>>>> [ 1.550669] Call Trace:
>>>> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58
>>>> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0
>>>> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20
>>>> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0
>>>> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50
>>>> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3]
>>>> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3]
>>>> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3]
>>>
>>> So does it work if you use a non-zero crs_timeout? The driver has
>>> called tg3_halt() which may affect configuration read responses. I need
>>> to check with the hardware team to see if the 5722 will return CRS in
>>> this scenario.
>>
>> Any updates from the hardware team?
>>
>> This is a pretty serious regression, but as far as I can tell, it is
>> not a PCI bug. The device should respond to a config read of vendor
>> ID. If the driver does something that make the read return CRS
>> status, I think the driver is responsible for doing whatever delay or
>> other fixup is required.
>>
>> I'm inclined to reassign this bug to the tg3 driver unless you think
>> the PCI core is doing something wrong here.
>>
>> Bjorn
>
> We were not able to reproduce this issue, could you please check what is
> the value of reg 0x70, before the pci_device_is_present call is made ?
> if bit 15 is set config access will be retried.
>
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -9025,6 +9025,7 @@ static int tg3_chip_reset(struct tg3 *tp)
> void (*write_op)(struct tg3 *, u32, u32);
> int i, err;
>
> + printk(KERN_ERR "config state: %x\n", tr32(TG3PCI_PCISTATE));
> if (!pci_device_is_present(tp->pdev))
> return -ENODEV;
>
With that PCI patch applied and my debugs, without the timeout hack (so crs_timeout=0):
[ 1.545554] config state: 12b2
[ 1.548636] pci 0000:02:00.0: 1st 1 1
[ 1.548637] pci 0000:02:00.0: crs_timeout: 0
[ 1.548783] tg3 0000:02:00.0 eth0: Tigon3 [partno(BCM95722) rev a200] (PCI Express) MAC address 00:0a:f7:2b:9b:39
[ 1.548785] tg3 0000:02:00.0 eth0: attached PHY is 5722/5756 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 1.548786] tg3 0000:02:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[ 1.548787] tg3 0000:02:00.0 eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[ 1.554389] tg3 0000:02:00.0 p1p1: renamed from eth0
...
That's the only time your printk got printed.
Marcelo
^ permalink raw reply
* Re: [GIT PULL nf-next] Second round of IPVS Updates for v3.19
From: Pablo Neira Ayuso @ 2014-12-18 20:11 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
In-Reply-To: <1418201201-19257-1-git-send-email-horms@verge.net.au>
On Wed, Dec 10, 2014 at 05:46:40PM +0900, Simon Horman wrote:
> Hi Pablo,
>
> please consider these IPVS updates for v3.19 or alternatively v3.20.
>
> The single patch in this series fixes a long standing bug that
> has not caused any trouble and thus is not being prioritised as a fix.
>
>
> The following changes since commit d6b00fec5dbbe976904b4d77e7d4f9493df5c2ec:
>
> macvlan: play well with ipvlan device (2014-12-09 16:10:06 -0500)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git tags/ipvs2-for-v3.19
Pulled, thanks Simon.
This applies cleanly to:
3.2.x
3.4.x
3.10.x
3.14.x
3.17.x
3.18.x
Please, let me know if this patch has some non obvious dependencies
that needs to be fulfilled before passing it to -stable or it's plain
fine to pass it on.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: changes for wireless
From: Luca Coelho @ 2014-12-18 20:14 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, John W. Linville
In-Reply-To: <1418836025-9035-1-git-send-email-linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Wed, 2014-12-17 at 12:07 -0500, John W. Linville wrote:
> http://marc.info/?l=linux-wireless&m=141883202530292&w=2
>
> This makes it official... :-)
>
> Signed-off-by: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> ---
> MAINTAINERS | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
[...]
> +NETWORKING DRIVERS (WIRELESS)
> +M: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> +L: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Q: http://patchwork.kernel.org/project/linux-wireless/list/
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/
> +S: Maintained
> +F: drivers/net/wireless/
Kalle, welcome to your new role! I'm sure you're the right person for
the job. You've been the person to thank (or to blame? ;) for getting
me into the Linux Wireless community and you've also been a mentor,
guide and friend along the way. I'm very happy for you and for the
community as a whole, which will certainly benefit from your work!
Thanks for taking the position!
--
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Nils Holland @ 2014-12-18 20:26 UTC (permalink / raw)
To: Prashant Sreedharan
Cc: Bjorn Helgaas, Marcelo Ricardo Leitner, Michael Chan, Rajat Jain,
David Miller, netdev, linux-pci@vger.kernel.org, Rafael Wysocki
In-Reply-To: <1418930889.3433.8.camel@prashant>
On Thu, Dec 18, 2014 at 11:28:09AM -0800, Prashant Sreedharan wrote:
> On Thu, 2014-12-18 at 12:15 -0700, Bjorn Helgaas wrote:
> >
> > Any updates from the hardware team?
> >
> > This is a pretty serious regression, but as far as I can tell, it is
> > not a PCI bug. The device should respond to a config read of vendor
> > ID. If the driver does something that make the read return CRS
> > status, I think the driver is responsible for doing whatever delay or
> > other fixup is required.
> >
> > I'm inclined to reassign this bug to the tg3 driver unless you think
> > the PCI core is doing something wrong here.
> >
> > Bjorn
>
> We were not able to reproduce this issue, could you please check what is
> the value of reg 0x70, before the pci_device_is_present call is made ?
> if bit 15 is set config access will be retried.
>
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -9025,6 +9025,7 @@ static int tg3_chip_reset(struct tg3 *tp)
> void (*write_op)(struct tg3 *, u32, u32);
> int i, err;
>
> + printk(KERN_ERR "config state: %x\n", tr32(TG3PCI_PCISTATE));
> if (!pci_device_is_present(tp->pdev))
> return -ENODEV;
No problem, I gave this a try and here is what I get:
[ 2.185190] libphy: tg3 mdio bus: probed
[ 2.229357] tsc: Refined TSC clocksource calibration: 2399.999 MHz
[ 2.244993] config state: 1292
[ 2.247136] tg3 0000:02:00.0 eth0: Tigon3 [partno(BCM57780) rev 57780001]
(PCI Express) MAC address 00:19:99:ce:13:a6
[ 2.249279] tg3 0000:02:00.0 eth0: attached PHY driver [Broadcom BCM57780]
(mii_bus:phy_addr=200:01)
[ 2.251460] tg3 0000:02:00.0 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[0] TSOcap[1]
[ 2.253672] tg3 0000:02:00.0 eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[...]
[ 12.204692] tg3 0000:02:00.0
enp2s0: No firmware running
[ 12.206653] config state: 1292
[ 12.208655] config state: 1292
That's all of the three times the new debugging line gets hit when I
boot my system using the supplied diagnostic patch.
Hope that helps - of course, I'd gladly test any further
(diagnostic) patches if required! Also, if I can provide any
additional information that might be of value, just ask:-)
Greetings,
Nils
^ permalink raw reply
* Re: pull request: bluetooth 2014-12-17
From: David Miller @ 2014-12-18 20:32 UTC (permalink / raw)
To: johan.hedberg; +Cc: netdev, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20141217204614.GA15480@t440s.P-661HNU-F1>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Wed, 17 Dec 2014 22:46:14 +0200
> Here's the first direct (i.e. skipping the wireless tree) bluetooth pull
> request for you, intended for 3.19. It's just one patch: a fix from
> Marcel for for remote service discovery filtering which also fixes a
> 'used uninitialized' compiler warning.
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Marcelo Ricardo Leitner @ 2014-12-18 20:33 UTC (permalink / raw)
To: Prashant Sreedharan, Bjorn Helgaas
Cc: Michael Chan, Rajat Jain, Nils Holland, David Miller, netdev,
linux-pci@vger.kernel.org, Rafael Wysocki
In-Reply-To: <54933491.7020204@gmail.com>
On 18-12-2014 18:09, Marcelo Ricardo Leitner wrote:
> On 18-12-2014 17:28, Prashant Sreedharan wrote:
>> On Thu, 2014-12-18 at 12:15 -0700, Bjorn Helgaas wrote:
>>> On Tue, Dec 16, 2014 at 12:54 PM, Michael Chan <mchan@broadcom.com> wrote:
>>>> On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote:
>>>>> It's a
>>>>> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
>>>>> Gigabit Ethernet PCI Express
>>>>> over here
>>>>>
>>>>> I put a WARN_ON(1) after those printks, and this is what I got:
>>>>>
>>>>> [ 1.550640] pci 0000:02:00.0: 1st 1 1
>>>>> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0
>>>>> [ 1.550645] ------------[ cut here ]------------
>>>>> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0()
>>>>> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video
>>>>> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8
>>>>> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013
>>>>> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46
>>>>> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41
>>>>> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000
>>>>> [ 1.550669] Call Trace:
>>>>> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58
>>>>> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0
>>>>> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20
>>>>> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0
>>>>> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50
>>>>> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3]
>>>>> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3]
>>>>> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3]
>>>>
>>>> So does it work if you use a non-zero crs_timeout? The driver has
>>>> called tg3_halt() which may affect configuration read responses. I need
>>>> to check with the hardware team to see if the 5722 will return CRS in
>>>> this scenario.
>>>
>>> Any updates from the hardware team?
>>>
>>> This is a pretty serious regression, but as far as I can tell, it is
>>> not a PCI bug. The device should respond to a config read of vendor
>>> ID. If the driver does something that make the read return CRS
>>> status, I think the driver is responsible for doing whatever delay or
>>> other fixup is required.
>>>
>>> I'm inclined to reassign this bug to the tg3 driver unless you think
>>> the PCI core is doing something wrong here.
>>>
>>> Bjorn
>>
>> We were not able to reproduce this issue, could you please check what is
>> the value of reg 0x70, before the pci_device_is_present call is made ?
>> if bit 15 is set config access will be retried.
>>
>> --- a/drivers/net/ethernet/broadcom/tg3.c
>> +++ b/drivers/net/ethernet/broadcom/tg3.c
>> @@ -9025,6 +9025,7 @@ static int tg3_chip_reset(struct tg3 *tp)
>> void (*write_op)(struct tg3 *, u32, u32);
>> int i, err;
>>
>> + printk(KERN_ERR "config state: %x\n", tr32(TG3PCI_PCISTATE));
>> if (!pci_device_is_present(tp->pdev))
>> return -ENODEV;
>>
>
> With that PCI patch applied and my debugs, without the timeout hack (so crs_timeout=0):
>
> [ 1.545554] config state: 12b2
> [ 1.548636] pci 0000:02:00.0: 1st 1 1
> [ 1.548637] pci 0000:02:00.0: crs_timeout: 0
> [ 1.548783] tg3 0000:02:00.0 eth0: Tigon3 [partno(BCM95722) rev a200] (PCI Express) MAC address 00:0a:f7:2b:9b:39
> [ 1.548785] tg3 0000:02:00.0 eth0: attached PHY is 5722/5756 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> [ 1.548786] tg3 0000:02:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> [ 1.548787] tg3 0000:02:00.0 eth0: dma_rwctrl[76180000] dma_mask[64-bit]
> [ 1.554389] tg3 0000:02:00.0 p1p1: renamed from eth0
> ...
>
> That's the only time your printk got printed.
My bad, I forgot I had configured the system to not bring that iface up
anymore.. when doing so, just like Nils had too:
[ 1743.678714] tg3 0000:02:00.0: irq 32 for MSI/MSI-X
[ 1745.554039] tg3 0000:02:00.0 p1p1: No firmware running
[ 1745.554724] config state: 12b2
[ 1745.557822] pci 0000:02:00.0: 1st 1 1
[ 1745.557827] pci 0000:02:00.0: crs_timeout: 0
[ 1745.559383] config state: 12b2
[ 1745.562470] pci 0000:02:00.0: 1st 1 1
[ 1745.562471] pci 0000:02:00.0: crs_timeout: 0
Marcelo
^ permalink raw reply
* Re: pull-request: mac80211 2014-12-18
From: David Miller @ 2014-12-18 20:35 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev
In-Reply-To: <1418911822.6134.13.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 18 Dec 2014 15:10:22 +0100
> Also from me a first pull request - we have a number of really old
> issues that happened to crop up now with new work (or just more testing)
> in the right areas as well as some small bugs newly introduced in 3.19.
>
> Let me know if there are any problems.
Pulled, but:
1) Don't put things into a merge commit, I take the text from your
pull request email and that becomes the merge commit contents.
Put it in your pull request email.
2) I want every pull request I get at least CC:'d to netdev.
> The following changes since commit 5fbea33740aeb948422d7b7e8aafbeac362264b2:
>
> r8169:update rtl8168g pcie ephy parameter (2014-12-11 21:38:52 -0500)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2014-12-18
>
> for you to fetch changes up to 28a9bc68124c319b2b3dc861e80828a8865fd1ba:
>
> mac80211: free management frame keys when removing station (2014-12-17 14:00:17 +0100)
^ permalink raw reply
* Re: [PATCH] stmmac: Don't init ptp again when resume from suspend/hibernation
From: David Miller @ 2014-12-18 20:36 UTC (permalink / raw)
To: chenhc; +Cc: peppe.cavallaro, vbridgers2013, netdev, stable
In-Reply-To: <1418884794-15483-1-git-send-email-chenhc@lemote.com>
Two problems:
1) This post did not reach netdev and therefore did not make it into
patchwork for tracking. You need to correct this.
2) Do not CC: stable on networking changes, instead ask me explicitly
to queue them up for -stable submission and to which trees.
^ permalink raw reply
* Re: [PATCH net] net: drop the packet when fails to do software segmentation or header check
From: David Miller @ 2014-12-18 20:39 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, eric.dumazet
In-Reply-To: <1418882239-6720-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Thu, 18 Dec 2014 13:57:19 +0800
> Fixes cecda693a969816bac5e470e1d9c9c0ef5567bca
Please correct this fixes tag, it should be of the form:
Fixes: $(SHA1) ("header text of commit message")
The SHA1 ID should be reduced to 12 digits of significance.
^ permalink raw reply
* Re: pull-request: mac80211 2014-12-18
From: David Miller @ 2014-12-18 21:01 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev
In-Reply-To: <1418936069.10864.1.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 18 Dec 2014 21:54:29 +0100
> On Thu, 2014-12-18 at 15:35 -0500, David Miller wrote:
>
>> 1) Don't put things into a merge commit, I take the text from your
>> pull request email and that becomes the merge commit contents.
>> Put it in your pull request email.
>
> Hmm, ok - not sure I fully understand. I don't think I created a merge
> commit, so did you mean the tag? I thought a (signed) tag with contents
> was now the preferred way to send pull requests, but I can also send a
> signed email without a tag for you to merge a branch? Or would you
> prefer a signed tag but empty (is that even possible?) with the text in
> the email?
Anything you do I guess is fine with me, but I'm going to edit the
content that ends up in the merge commit regardless.
>> 2) I want every pull request I get at least CC:'d to netdev.
>
> Ok, sure.
Thanks.
^ permalink raw reply
* Re: [iwlwifi] BUG: unable to handle kernel
From: Fengguang Wu @ 2014-12-18 21:07 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, lkp@01.org,
linux-leds@vger.kernel.org
In-Reply-To: <1418931737.4679.1.camel@egrumbacBox>
On Fri, Dec 19, 2014 at 03:42:17AM +0800, Grumbach, Emmanuel wrote:
> On Thu, 2014-12-18 at 09:13 -0800, Fengguang Wu wrote:
> > Hi All,
> >
> > I don't see any relationship between the BUG and this bisected commit.
> > Anyway, it's better to report it to the lists than to ignore.
>
> Right - but I have to say that I have no clue how this comment can cause
> the bug you are seeing...
s?comment?commit?
> Do you even have an Intel Wireless device the VM could access?
Nope. It's simple QEMU virtual machine boot test.
Thanks,
Fengguang
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git master
> >
> > commit 03d6c3b0fa4f5f0379cede079ec828a6c999fe43
> > Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > AuthorDate: Wed Dec 3 10:39:07 2014 +0200
> > Commit: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > CommitDate: Sun Dec 14 10:20:29 2014 +0200
> >
> > iwlwifi: pcie: re-ACK all interrupts after device reset
> >
> > When we reset the device, the CSR_INT gets cleared as well
> > as CSR_INT_MASK. Meaning that we shouldn't get any interrupt
> > but, due to a hardware bug, recent devices will keep sending
> > interrupts. This leads to an interrupt storm while stopping
> > the device.
> > The way to fix this is to ACK all the interrupts after the
> > device is reset so that the value of CSR_INT will stay
> > 0xffffffff.
> >
> > Fixes: 522713c81e4e ("iwlwifi: pcie: properly reset the device")
> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> >
> > +------------------------------------------+------------+------------+------------+
> > | | 0a79a0c011 | 03d6c3b0fa | iwlwifi-fi |
> > +------------------------------------------+------------+------------+------------+
> > | boot_successes | 60 | 19 | 3 |
> > | boot_failures | 0 | 1 | 9 |
> > | BUG:unable_to_handle_kernel | 0 | 1 | 9 |
> > | Oops | 0 | 1 | 9 |
> > | RIP:strcmp | 0 | 1 | 9 |
> > | Kernel_panic-not_syncing:Fatal_exception | 0 | 1 | 9 |
> > | backtrace:led_trigger_register_simple | 0 | 1 | 9 |
> > | backtrace:ledtrig_usb_init | 0 | 1 | 9 |
> > | backtrace:kernel_init_freeable | 0 | 1 | 9 |
> > +------------------------------------------+------------+------------+------------+
> >
> > [ 5.345018] g_serial gadget: Gadget Serial v2.4
> > [ 5.345927] g_serial gadget: g_serial ready
> > [ 5.345927] g_serial gadget: g_serial ready
> > [ 5.346777] BUG: unable to handle kernel
> > [ 5.346777] BUG: unable to handle kernel paging requestpaging request at ffff88000004e5f0
> > at ffff88000004e5f0
> > [ 5.348183] IP:
> > [ 5.348183] IP: [<ffffffff81446a68>] strcmp+0x6/0x20
> > [<ffffffff81446a68>] strcmp+0x6/0x20
> > [ 5.349183] PGD 37f1067
> > [ 5.349183] PGD 37f1067 PUD 37f2067 PUD 37f2067 PMD 37f3067 PMD 37f3067 PTE 800000000004e060PTE 800000000004e060
> >
> > [ 5.350498] Oops: 0000 [#1]
> > [ 5.350498] Oops: 0000 [#1] DEBUG_PAGEALLOCDEBUG_PAGEALLOC
> >
> > [ 5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> > [ 5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> > [ 5.352660] task: ffff880012060000 ti: ffff88001204c000 task.ti: ffff88001204c000
> > [ 5.352660] task: ffff880012060000 ti: ffff88001204c000 task.ti: ffff88001204c000
> > [ 5.354143] RIP: 0010:[<ffffffff81446a68>]
> > [ 5.354143] RIP: 0010:[<ffffffff81446a68>] [<ffffffff81446a68>] strcmp+0x6/0x20
> > [<ffffffff81446a68>] strcmp+0x6/0x20
> > [ 5.354451] RSP: 0000:ffff88001204fe28 EFLAGS: 00010246
> > [ 5.354451] RSP: 0000:ffff88001204fe28 EFLAGS: 00010246
> > [ 5.354451] RAX: 0000000000000000 RBX: ffff88000c08fe00 RCX: ffffffff81d35310
> > [ 5.354451] RAX: 0000000000000000 RBX: ffff88000c08fe00 RCX: ffffffff81d35310
> > [ 5.354451] RDX: ffff88000c08fe68 RSI: ffffffff826d05be RDI: ffff88000004e5f0
> > [ 5.354451] RDX: ffff88000c08fe68 RSI: ffffffff826d05be RDI: ffff88000004e5f0
> > [ 5.354451] RBP: ffff88001204fe28 R08: 0000000000000001 R09: 000000000000033a
> > [ 5.354451] RBP: ffff88001204fe28 R08: 0000000000000001 R09: 000000000000033a
> > [ 5.354451] R10: 0000000000000000 R11: ffffffff82531cd1 R12: ffff88000c19fa00
> > [ 5.354451] R10: 0000000000000000 R11: ffffffff82531cd1 R12: ffff88000c19fa00
> > [ 5.354451] R13: 0000000000000000 R14: ffffffff837958b8 R15: 0000000000000000
> > [ 5.354451] R13: 0000000000000000 R14: ffffffff837958b8 R15: 0000000000000000
> > [ 5.354451] FS: 0000000000000000(0000) GS:ffffffff82789000(0000) knlGS:0000000000000000
> > [ 5.354451] FS: 0000000000000000(0000) GS:ffffffff82789000(0000) knlGS:0000000000000000
> > [ 5.354451] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 5.354451] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 5.354451] CR2: ffff88000004e5f0 CR3: 0000000002776000 CR4: 00000000000006b0
> > [ 5.354451] CR2: ffff88000004e5f0 CR3: 0000000002776000 CR4: 00000000000006b0
> > [ 5.354451] Stack:
> > [ 5.354451] Stack:
> > [ 5.354451] ffff88001204fe58
> > [ 5.354451] ffff88001204fe58 ffffffff81d35334 ffffffff81d35334 0000000000000000 0000000000000000 ffff88000c19fa00 ffff88000c19fa00
> >
> > [ 5.354451] ffffffff826d05be
> > [ 5.354451] ffffffff826d05be 0000000000000000 0000000000000000 ffff88001204fe88 ffff88001204fe88 ffffffff81d35648 ffffffff81d35648
> >
> > [ 5.354451] ffff88000e3bbcc0
> > [ 5.354451] ffff88000e3bbcc0 ffffffff82b3fe61 ffffffff82b3fe61 0000000000000000 0000000000000000 ffffffff82b98910 ffffffff82b98910
> >
> > [ 5.354451] Call Trace:
> > [ 5.354451] Call Trace:
> > [ 5.354451] [<ffffffff81d35334>] led_trigger_register+0x63/0x129
> > [ 5.354451] [<ffffffff81d35334>] led_trigger_register+0x63/0x129
> > [ 5.354451] [<ffffffff81d35648>] led_trigger_register_simple+0x35/0x79
> > [ 5.354451] [<ffffffff81d35648>] led_trigger_register_simple+0x35/0x79
> > [ 5.354451] [<ffffffff82b3fe61>] ? gs_bind+0xea/0xea
> > [ 5.354451] [<ffffffff82b3fe61>] ? gs_bind+0xea/0xea
> > [ 5.354451] [<ffffffff82b3fe78>] ledtrig_usb_init+0x17/0x2e
> > [ 5.354451] [<ffffffff82b3fe78>] ledtrig_usb_init+0x17/0x2e
> > [ 5.354451] [<ffffffff82b00044>] do_one_initcall+0xe6/0x171
> > [ 5.354451] [<ffffffff82b00044>] do_one_initcall+0xe6/0x171
> > [ 5.354451] [<ffffffff82b001c7>] kernel_init_freeable+0xf8/0x180
> > [ 5.354451] [<ffffffff82b001c7>] kernel_init_freeable+0xf8/0x180
> > [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> > [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> > [ 5.354451] [<ffffffff8206079a>] kernel_init+0x9/0xd0
> > [ 5.354451] [<ffffffff8206079a>] kernel_init+0x9/0xd0
> > [ 5.354451] [<ffffffff8207d2ba>] ret_from_fork+0x7a/0xb0
> > [ 5.354451] [<ffffffff8207d2ba>] ret_from_fork+0x7a/0xb0
> > [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> > [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> > [ 5.354451] Code:
> > [ 5.354451] Code: c0 c0 eb eb f5 f5 31 31 c9 c9 40 40 8a 8a 3c 3c 0e 0e 4d 4d 8d 8d 0c 0c 08 08 40 40 84 84 ff ff 41 41 88 88 3c 3c 08 08 74 74 0d 0d 48 48 ff ff c1 c1 48 48 39 39 ca ca 75 75 e7 e7 41 41 c6 c6 41 41 01 01 00 00 5d 5d c3 c3 55 55 31 31 c0 c0 48 48 89 89 e5 e5 <8a> <8a> 14 14 07 07 3a 3a 14 14 06 06 74 74 07 07 19 19 c0 c0 83 83 c8 c8 01 01 eb eb 09 09 48 48 ff ff c0 c0 84 84 d2 d2 75 75
> >
> > [ 5.354451] RIP
> > [ 5.354451] RIP [<ffffffff81446a68>] strcmp+0x6/0x20
> > [<ffffffff81446a68>] strcmp+0x6/0x20
> > [ 5.354451] RSP <ffff88001204fe28>
> > [ 5.354451] RSP <ffff88001204fe28>
> > [ 5.354451] CR2: ffff88000004e5f0
> > [ 5.354451] CR2: ffff88000004e5f0
> > [ 5.354451] ---[ end trace 8f9377b34c860a0c ]---
> > [ 5.354451] ---[ end trace 8f9377b34c860a0c ]---
> >
> > git bisect start baa21e834941ee5fbe4bd421c871f7c0c5f9a086 70e71ca0af244f48a5dcf56dc435243792e3a495 --
> > git bisect bad 03d6c3b0fa4f5f0379cede079ec828a6c999fe43 # 16:23 0- 1 iwlwifi: pcie: re-ACK all interrupts after device reset
> > git bisect good 0a79a0c011cb291675e3b80760a452fcba5c59d9 # 16:28 20+ 0 iwlwifi: mvm: clear IN_HW_RESTART flag on stop()
> > # first bad commit: [03d6c3b0fa4f5f0379cede079ec828a6c999fe43] iwlwifi: pcie: re-ACK all interrupts after device reset
> > git bisect good 0a79a0c011cb291675e3b80760a452fcba5c59d9 # 16:30 60+ 0 iwlwifi: mvm: clear IN_HW_RESTART flag on stop()
> > # extra tests on HEAD of iwlwifi-fixes/master
> > git bisect bad baa21e834941ee5fbe4bd421c871f7c0c5f9a086 # 16:30 0- 9 iwlwifi: pcie: limit fw chunk sizes given to fh
> > # extra tests on tree/branch iwlwifi-fixes/master
> > git bisect bad baa21e834941ee5fbe4bd421c871f7c0c5f9a086 # 16:30 0- 9 iwlwifi: pcie: limit fw chunk sizes given to fh
> > # extra tests on tree/branch linus/master
> > git bisect good 44e8967d591686463e84a88b46b03beba3ab49fb # 16:32 60+ 0 Ceph: remove left-over reject file
> > # extra tests on tree/branch next/master
> > git bisect good cfaa3a95dd2b402599b1d8122dc3107478db8717 # 16:35 60+ 1 Add linux-next specific files for 20141218
> >
> >
> > This script may reproduce the error.
> >
> > ----------------------------------------------------------------------------
> > #!/bin/bash
> >
> > kernel=$1
> > initrd=quantal-core-x86_64.cgz
> >
> > wget --no-clobber https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
> >
> > kvm=(
> > qemu-system-x86_64
> > -cpu kvm64
> > -enable-kvm
> > -kernel $kernel
> > -initrd $initrd
> > -m 320
> > -smp 2
> > -net nic,vlan=1,model=e1000
> > -net user,vlan=1
> > -boot order=nc
> > -no-reboot
> > -watchdog i6300esb
> > -rtc base=localtime
> > -serial stdio
> > -display none
> > -monitor null
> > )
> >
> > append=(
> > hung_task_panic=1
> > earlyprintk=ttyS0,115200
> > debug
> > apic=debug
> > sysrq_always_enabled
> > rcupdate.rcu_cpu_stall_timeout=100
> > panic=-1
> > softlockup_panic=1
> > nmi_watchdog=panic
> > oops=panic
> > load_ramdisk=2
> > prompt_ramdisk=0
> > console=ttyS0,115200
> > console=tty0
> > vga=normal
> > root=/dev/ram0
> > rw
> > drbd.minor_count=8
> > )
> >
> > "${kvm[@]}" --append "${append[*]}"
> > ----------------------------------------------------------------------------
> >
> > Thanks,
> > Fengguang
> > _______________________________________________
> > LKP mailing list
> > LKP@linux.intel.com
>
^ permalink raw reply
* Re: pull-request: mac80211 2014-12-18
From: Johannes Berg @ 2014-12-18 20:54 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev
In-Reply-To: <20141218.153520.221364366280641527.davem@davemloft.net>
On Thu, 2014-12-18 at 15:35 -0500, David Miller wrote:
> 1) Don't put things into a merge commit, I take the text from your
> pull request email and that becomes the merge commit contents.
> Put it in your pull request email.
Hmm, ok - not sure I fully understand. I don't think I created a merge
commit, so did you mean the tag? I thought a (signed) tag with contents
was now the preferred way to send pull requests, but I can also send a
signed email without a tag for you to merge a branch? Or would you
prefer a signed tag but empty (is that even possible?) with the text in
the email?
> 2) I want every pull request I get at least CC:'d to netdev.
Ok, sure.
Thanks,
johannes
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2014-12-18 21:39 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix NBMA tunnel mac header handling in GRE, from Timo Teräs.
2) Fix a NAPI race in the fec driver, from Nimrod Andy.
3) The new IFF_VNET_LE bit is outside the size of the flags
member it is stored in (which is 16-bits), store the state
locally in the drivers. From Michael S. Tsirkin.
4) We are kicking the tires with the new wireless maintainership
situation. Bluetooth fixes via Johan Hedberg, and mac80211
fixes from Johannes Berg.
5) Fix locking and leaks in geneve driver, from Jesse Gross.
6) Make netlink TX mmap code always copy, so we don't have to
be potentially exposed to the user changing the underlying
contents from underneath us.
Please pull, thank a lot!
The following changes since commit 67e2c3883828b39548cee2091b36656787775d95:
Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security (2014-12-14 20:36:37 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to 86c8fc4bbe14b8950e62d379bb57722427ad3d67:
Merge tag 'mac80211-for-davem-2014-12-18' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2014-12-18 15:33:49 -0500)
----------------------------------------------------------------
Andreas Müller (1):
mac80211: fix multicast LED blinking and counter
Arik Nemtsov (2):
cfg80211: avoid mem leak on driver hint set
cfg80211: correctly check ad-hoc channels
Asaf Vertz (1):
cirrus: cs89x0: fix time comparison
Brian Norris (1):
brcmsmac: don't leak kernel memory via printk()
Cyrille Pitchen (2):
net/macb: fix misplaced call of free_netdev() in macb_remove()
net/macb: remove useless calls of devm_free_irq()
David Miller (1):
netlink: Always copy on mmap TX.
David S. Miller (8):
Merge branch 'mlx4'
Merge branch 'macb'
Merge branch 'fixed_phy'
Merge branch 'vnet_le'
net: Allow FIXED_PHY to be modular.
Merge tag 'master-2014-12-15' of git://git.kernel.org/.../linville/wireless
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth
Merge tag 'mac80211-for-davem-2014-12-18' of git://git.kernel.org/.../jberg/mac80211
David Vrabel (2):
xen-netfront: use napi_complete() correctly to prevent Rx stalling
xen-netback: support frontends without feature-rx-notify again
Duan Jiong (1):
fib_trie.txt: fix typo
Emmanuel Grumbach (2):
mac80211: update the channel context after channel switch
cfg80211: don't WARN about two consecutive Country IE hint
Fengguang Wu (1):
Bluetooth: fix err_cast.cocci warnings
Florian Fainelli (3):
net: bcmgenet: always select FIXED_PHY
net: systemport: always select FIXED_PHY
net: dsa: bcm_sf2: always select FIXED_PHY
Geert Uytterhoeven (2):
net: stmmac: sti: Fix uninitialized pointer dereference if !OF
rds: Fix min() warning in rds_message_inc_copy_to_user()
Hariprasad Shenai (1):
cxgb4: Fix decoding QSA module for ethtool get settings
Ido Shamay (1):
net/mlx4: Cache line CQE/EQE stride fixes
Jaganath Kanakkassery (2):
Bluetooth: Fix missing hci_dev_lock/unlock in mgmt req_complete()
Bluetooth: Fix missing hci_dev_lock/unlock in hci_event
Janne Heikkinen (1):
Bluetooth: Add USB device 04ca:3010 as Atheros AR3012
Jes Sorensen (1):
mac80211: avoid using uninitialized stack data
Jesse Gross (2):
geneve: Remove socket and offload handlers at destruction.
geneve: Fix races between socket add and release.
Jiri Benc (1):
bnx2x: fix typos in "configure"
Johan Hedberg (5):
Bluetooth: Fix calling hci_conn_put too early
Bluetooth: Fix incorrect pending cmd removal in pairing_complete()
Bluetooth: Fix notifying mgmt power off before flushing connection list
Bluetooth: Fix enabling BR/EDR SC when powering on
Bluetooth: Fix mgmt response status when removing adapter
Johannes Berg (1):
mac80211: free management frame keys when removing station
John W. Linville (2):
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next
MAINTAINERS: changes for wireless
Jouni Malinen (1):
cfg80211: Fix 160 MHz channels with 80+80 and 160 MHz drivers
Julia Lawall (3):
zd1211rw: fix misspelling of current function in string
hostap_cs: fix misspelling of current function in string
rtlwifi: rtl8821ae: fix misspelling of current function in string
Larry Finger (1):
rtlwifi: rtl8192ce: Set fw_ready flag
Luciano Coelho (1):
nl80211: check matches array length before acessing it
Marcel Holtmann (5):
Bluetooth: Check for force_lesc_support when enabling SMP over BR/EDR
Bluetooth: Check for force_lesc_support before rejecting SMP over BR/EDR
Bluetooth: Fix generation of non-resolvable private addresses
Bluetooth: Fix check for support for page scan related commands
Bluetooth: Fix bug with filter in service discovery optimization
Matan Barak (1):
net/mlx4_core: Fixed memory leak and incorrect refcount in mlx4_load_one
Michael S. Tsirkin (5):
macvtap: fix uninitialized access on TUNSETIFF
if_tun: add TUNSETVNETLE/TUNGETVNETLE
tun: drop broken IFF_VNET_LE
macvtap: drop broken IFF_VNET_LE
if_tun: drop broken IFF_VNET_LE
Nimrod Andy (1):
net: fec: Fix NAPI race
Or Gerlitz (2):
net/mlx4_core: Avoid double dumping of the PF device capabilities
net: Disallow providing non zero VLAN ID for NIC drivers FDB add flow
Sriharsha Basavapatna (1):
be2net: Fix incorrect setting of tunnel offload flag in netdev features
Thomas Graf (3):
ip_tunnel: Add sanity checks to ip_tunnel_encap_add_ops()
ip_tunnel: Add missing validation of encap type to ip_tunnel_encap_setup()
netlink: Don't reorder loads/stores before marking mmap netlink frame as available
Timo Teräs (1):
gre: fix the inner mac header in nbma tunnel xmit path
Tobias Klauser (1):
net: smc91x: Fix build without gpiolib
Wei Yongjun (1):
rtlwifi: rtl8192cu: Fix sparse non static symbol warning
Documentation/networking/fib_trie.txt | 4 +--
MAINTAINERS | 19 ++++++--------
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
drivers/net/dsa/Kconfig | 2 +-
drivers/net/ethernet/broadcom/Kconfig | 4 +--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 +--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h | 4 +--
drivers/net/ethernet/cadence/macb.c | 25 +++++++-----------
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 2 +-
drivers/net/ethernet/cirrus/cs89x0.c | 27 ++++++++++----------
drivers/net/ethernet/emulex/benet/be_main.c | 2 ++
drivers/net/ethernet/freescale/fec_main.c | 19 ++++++--------
drivers/net/ethernet/intel/i40e/i40e_main.c | 5 ++++
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 11 ++++++--
drivers/net/ethernet/mellanox/mlx4/fw.c | 30 ++++++++++++----------
drivers/net/ethernet/mellanox/mlx4/fw.h | 1 +
drivers/net/ethernet/mellanox/mlx4/main.c | 62 ++++++++++++++++++++++++---------------------
drivers/net/ethernet/smsc/Kconfig | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 10 ++++----
drivers/net/macvtap.c | 30 +++++++++++++++++-----
drivers/net/phy/Kconfig | 4 +--
drivers/net/phy/Makefile | 2 +-
drivers/net/phy/{fixed.c => fixed_phy.c} | 0
drivers/net/tun.c | 26 ++++++++++++++++---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
drivers/net/wireless/hostap/hostap_cs.c | 15 ++++-------
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 2 ++
drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8821ae/dm.c | 11 ++++----
drivers/net/wireless/zd1211rw/zd_chip.c | 6 ++---
drivers/net/xen-netback/common.h | 4 ++-
drivers/net/xen-netback/interface.c | 4 ++-
drivers/net/xen-netback/netback.c | 27 ++++++++++----------
drivers/net/xen-netback/xenbus.c | 12 ++++++---
drivers/net/xen-netfront.c | 11 +++-----
include/linux/phy_fixed.h | 2 +-
include/uapi/linux/if_tun.h | 3 ++-
net/bluetooth/hci_conn.c | 2 +-
net/bluetooth/hci_core.c | 60 ++++++++++++++++++++++++++------------------
net/bluetooth/hci_event.c | 20 +++++++++++++++
net/bluetooth/l2cap_core.c | 5 ++--
net/bluetooth/mgmt.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++----------------------
net/bluetooth/smp.c | 5 ++--
net/core/rtnetlink.c | 5 ++++
net/ipv4/geneve.c | 30 +++++++++++++++++-----
net/ipv4/ip_gre.c | 9 ++++---
net/ipv4/ip_tunnel.c | 9 +++++++
net/mac80211/chan.c | 4 +++
net/mac80211/key.c | 2 +-
net/mac80211/mlme.c | 1 +
net/mac80211/rx.c | 11 ++++----
net/netlink/af_netlink.c | 54 +++++++++++++--------------------------
net/rds/message.c | 3 ++-
net/wireless/chan.c | 9 ++++---
net/wireless/nl80211.c | 2 +-
net/wireless/reg.c | 20 +++++++++------
58 files changed, 454 insertions(+), 297 deletions(-)
rename drivers/net/phy/{fixed.c => fixed_phy.c} (100%)
^ permalink raw reply
* [PATCH] Fixed TPACKET V3 to signal poll when block is closed rather than for every packet
From: Dan Collins @ 2014-12-18 21:49 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel
Make TPACKET_V3 signal poll when block is closed rather than for every
packet. Side effect is that poll will be signaled when block retire
timer expires which didn't previously happen. Issue was visible when
sending packets at a very low frequency such that all blocks are retired
before packets are received by TPACKET_V3. This caused avoidable packet
loss. The fix ensures that the signal is sent when blocks are closed
which covers the normal path where the block is filled as well as the
path where the timer expires. The case where a block is filled without
moving to the next block (ie. all blocks are full) will still cause poll
to be signaled.
Signed-off-by: Dan Collins <dan@dcollins.co.nz>
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index e52a447..14e883d 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -43,6 +43,8 @@
* Chetan Loke : Implemented TPACKET_V3 block abstraction
* layer.
* Copyright (C) 2011, <lokec@ccs.neu.edu>
+ * Dan Collins : Fixed TPACKET_V3 to wake poll when block is closed
+ * rather than for every packet.
*
*
* This program is free software; you can redistribute it and/or
@@ -785,6 +787,7 @@ static void prb_close_block(struct tpacket_kbdq_core *pkc1,
struct tpacket3_hdr *last_pkt;
struct tpacket_hdr_v1 *h1 = &pbd1->hdr.bh1;
+ struct sock *sk = &po->sk;
if (po->stats.stats3.tp_drops)
status |= TP_STATUS_LOSING;
@@ -809,6 +812,8 @@ static void prb_close_block(struct tpacket_kbdq_core *pkc1,
/* Flush the block */
prb_flush_block(pkc1, pbd1, status);
+ sk->sk_data_ready(sk);
+
pkc1->kactive_blk_num = GET_NEXT_PRB_BLK_NUM(pkc1);
}
@@ -2052,12 +2057,12 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
smp_wmb();
#endif
- if (po->tp_version <= TPACKET_V2)
+ if (po->tp_version <= TPACKET_V2) {
__packet_set_status(po, h.raw, status);
- else
+ sk->sk_data_ready(sk);
+ } else {
prb_clear_blk_fill_status(&po->rx_ring);
-
- sk->sk_data_ready(sk);
+ }
drop_n_restore:
if (skb_head != skb->data && skb_shared(skb)) {
^ permalink raw reply related
* Re: [PATCH] Fixed TPACKET V3 to signal poll when block is closed rather than for every packet
From: David Miller @ 2014-12-18 21:51 UTC (permalink / raw)
To: dan; +Cc: netdev, linux-kernel
In-Reply-To: <1418939356.3016.9.camel@voodoo.cms.waikato.ac.nz>
From: Dan Collins <dan@dcollins.co.nz>
Date: Fri, 19 Dec 2014 10:49:16 +1300
> Make TPACKET_V3 signal poll when block is closed rather than for every
> packet. Side effect is that poll will be signaled when block retire
> timer expires which didn't previously happen. Issue was visible when
> sending packets at a very low frequency such that all blocks are retired
> before packets are received by TPACKET_V3. This caused avoidable packet
> loss. The fix ensures that the signal is sent when blocks are closed
> which covers the normal path where the block is filled as well as the
> path where the timer expires. The case where a block is filled without
> moving to the next block (ie. all blocks are full) will still cause poll
> to be signaled.
>
> Signed-off-by: Dan Collins <dan@dcollins.co.nz>
Your email client has corrupted the patch, turning TAB characters into
sequences of SPACE characters.
Please turn off all formatting in your email client, read:
Documentation/email-clients.txt
for help.
^ 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