* Re: [PATCH net-next 1/2] net: introduce NAPI_POLL_WEIGHT
From: David Miller @ 2013-03-06 4:59 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, eilong
In-Reply-To: <1362535042.15793.144.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 05 Mar 2013 17:57:22 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Some drivers use a too big NAPI poll weight.
>
> This patch adds a NAPI_POLL_WEIGHT default value
> and issues an error message if a driver attempts
> to use a bigger weight.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] net: cs89x0: use module_platform_driver_probe()
From: David Miller @ 2013-03-06 4:59 UTC (permalink / raw)
To: jg1.han; +Cc: netdev
In-Reply-To: <005301ce194b$44ca8e10$ce5faa30$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Tue, 05 Mar 2013 11:43:50 +0900
> This patch uses module_platform_driver_probe() macro which makes
> the code smaller and simpler.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] net: macb: use module_platform_driver_probe()
From: David Miller @ 2013-03-06 4:59 UTC (permalink / raw)
To: jg1.han; +Cc: netdev
In-Reply-To: <005201ce194b$318a6c80$949f4580$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Tue, 05 Mar 2013 11:43:18 +0900
> This patch uses module_platform_driver_probe() macro which makes
> the code smaller and simpler.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] net: at91_ether: use module_platform_driver_probe()
From: David Miller @ 2013-03-06 4:58 UTC (permalink / raw)
To: jg1.han; +Cc: netdev
In-Reply-To: <005101ce194b$04f4d980$0ede8c80$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Tue, 05 Mar 2013 11:42:03 +0900
> This patch uses module_platform_driver_probe() macro which makes
> the code smaller and simpler.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] benet: Wait f/w POST until timeout
From: David Miller @ 2013-03-06 4:58 UTC (permalink / raw)
To: Sathya.Perla; +Cc: shangw, netdev, subbu.seetharaman, Ajit.Khaparde
In-Reply-To: <dd3bebd7-d92d-4485-b4a6-413df763b985@CMEXHTCAS1.ad.emulex.com>
From: "Perla, Sathya" <Sathya.Perla@Emulex.Com>
Date: Wed, 6 Mar 2013 04:45:03 +0000
>> -----Original Message-----
>> From: David Miller [mailto:davem@davemloft.net]
>>
>> From: Gavin Shan <shangw@linux.vnet.ibm.com>
>> Date: Mon, 4 Mar 2013 15:48:46 +0800
>>
>> > While PCI card faces EEH errors, reset (usually hot reset) is expected
>> > to recover from the EEH errors. After EEH core finishes the reset, the
>> > driver callback (be_eeh_reset) is called and wait the firmware to
>> > complete POST successfully. The original code would return with error
>> > once detecting failure during POST stage. That seems not enough.
>> >
>> > The patch forces the driver (be_eeh_reset) to wait the firmware
>> > completes POST until timeout, instead of returning error upon
>> > detection POST failure immediately. Also, it would improve the
>> > reliability of the EEH funtionality of the driver.
>> >
>> > Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>>
>> I know that patch #2 of this series needs to be implemented differently, but this
>> patch seems fine.
>>
>> So can I get an ACK from one of the benet driver folks?
>
> Acked-by: Sathya Perla <sathya.perla@emulex.com>
Applied, thanks for reviewing.
^ permalink raw reply
* Re: [PATCH 1/1] reset nf before xmit vxlan encapsulated packet
From: David Miller @ 2013-03-06 4:56 UTC (permalink / raw)
To: zealot0630; +Cc: netdev
In-Reply-To: <1362413254-10520-1-git-send-email-zealot0630@gmail.com>
From: Zang MingJie <zealot0630@gmail.com>
Date: Tue, 5 Mar 2013 00:07:34 +0800
>
> We should reset nf settings bond to the skb as ipip/ipgre do.
>
> If not, the conntrack/nat info bond to the origin packet may continually
> redirect the packet to vxlan interface causing a routing loop.
>
> this is the scenario:
>
> VETP VXLAN Gateway
> /----\ /---------------\
> | | | |
> | vx+--+vx --NAT-> eth0+--> Internet
> | | | |
> \----/ \---------------/
>
> when there are any packet coming from internet to the vetp, there will be lots
> of garbage packets coming out the gateway's vxlan interface, but none actually
> sent to the physical interface, because they are redirected back to the vxlan
> interface in the postrouting chain of NAT rule, and dmesg complains:
>
> Mar 1 21:52:53 debian kernel: [ 8802.997699] Dead loop on virtual device vxlan0, fix it urgently!
> Mar 1 21:52:54 debian kernel: [ 8804.004907] Dead loop on virtual device vxlan0, fix it urgently!
> Mar 1 21:52:55 debian kernel: [ 8805.012189] Dead loop on virtual device vxlan0, fix it urgently!
> Mar 1 21:52:56 debian kernel: [ 8806.020593] Dead loop on virtual device vxlan0, fix it urgently!
>
> the patch should fix the problem
>
> Signed-off-by: Zang MingJie <zealot0630@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: fix new kernel-doc warnings in net core
From: David Miller @ 2013-03-06 4:56 UTC (permalink / raw)
To: rdunlap; +Cc: netdev, torvalds
In-Reply-To: <5135210B.6090207@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Mon, 04 Mar 2013 14:32:43 -0800
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix new kernel-doc warnings in net/core/dev.c:
>
> Warning(net/core/dev.c:4788): No description found for parameter 'new_carrier'
> Warning(net/core/dev.c:4788): Excess function parameter 'new_carries' description in 'dev_change_carrier'
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH net-next] tcp: ipv6: bind() use stronger condition for bind_conflict
From: David Miller @ 2013-03-06 4:54 UTC (permalink / raw)
To: fbl; +Cc: netdev, yoshfuji
In-Reply-To: <1362507061-22475-1-git-send-email-fbl@redhat.com>
From: Flavio Leitner <fbl@redhat.com>
Date: Tue, 5 Mar 2013 15:11:01 -0300
> We must try harder to get unique (addr, port) pairs when
> doing port autoselection for sockets with SO_REUSEADDR
> option set.
>
> This is a continuation of commit aacd9289af8b82f5fb01bcdd53d0e3406d1333c7
> for IPv6.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
I think this is 'net' material, therefore that's will I will apply
this, thanks Flavio.
^ permalink raw reply
* Re: [PATCH] net/ipv4: Timestamp option cannot overflow with prespecified addresses
From: David Miller @ 2013-03-06 4:54 UTC (permalink / raw)
To: david.ward; +Cc: netdev
In-Reply-To: <1362539192-9343-1-git-send-email-david.ward@ll.mit.edu>
From: David Ward <david.ward@ll.mit.edu>
Date: Tue, 5 Mar 2013 22:06:32 -0500
> When a router forwards a packet that contains the IPv4 timestamp option,
> if there is no space left in the option for the router to add its own
> timestamp, then the router increments the Overflow value in the option.
>
> However, if the addresses of the routers are prespecified in the option,
> then the overflow condition cannot happen: the option is structured so
> that each prespecified router has a place to write its timestamp. Other
> routers do not add a timestamp, so there will never be a lack of space.
>
> This fix ensures that the Overflow value in the IPv4 timestamp option is
> not incremented when the addresses of the routers are prespecified, even
> if the Pointer value is greater than the Length value.
>
> Signed-off-by: David Ward <david.ward@ll.mit.edu>
Applied, thanks for fixing this.
^ permalink raw reply
* Re: [PATCH] net: docs: document multiqueue tuntap API
From: David Miller @ 2013-03-06 4:54 UTC (permalink / raw)
To: jasowang; +Cc: maxk, rob, linux-doc, linux-kernel, netdev, mst, hkchu
In-Reply-To: <1362539123-24863-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 6 Mar 2013 11:05:23 +0800
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Please fix these warnings emitted by GIT:
Applying: net: docs: document multiqueue tuntap API
/home/davem/src/GIT/net/.git/rebase-apply/patch:31: space before tab in indent.
struct ifreq ifr;
/home/davem/src/GIT/net/.git/rebase-apply/patch:32: space before tab in indent.
int fd, err, i;
/home/davem/src/GIT/net/.git/rebase-apply/patch:34: space before tab in indent.
if (!dev)
/home/davem/src/GIT/net/.git/rebase-apply/patch:35: space before tab in indent.
return -1;
/home/davem/src/GIT/net/.git/rebase-apply/patch:37: space before tab in indent.
memset(&ifr, 0, sizeof(ifr));
warning: squelched 29 whitespace errors
warning: 34 lines add whitespace errors.
^ permalink raw reply
* Re: [PATCH BUGFIX 0/6] pkt_sched: fix little service anomalies and possible crashes of qfq+
From: David Miller @ 2013-03-06 4:50 UTC (permalink / raw)
To: paolo.valente; +Cc: jhs, shemminger, netdev, linux-kernel, fchecconi, rizzo
In-Reply-To: <1362506702-4985-1-git-send-email-paolo.valente@unimore.it>
From: Paolo valente <paolo.valente@unimore.it>
Date: Tue, 5 Mar 2013 19:04:56 +0100
> Split, and inserted a detailed description of both the problem and the fix
> in each patch.
Series applied, thanks.
Although two topics for possibly resolving later:
1) That 1ULL bit mask fix is quite expensive on 32-bit, it would
probably be cheaper to test for that case using a helper function
that nops out on 64-bit. Although this is not so important.
2) That static inline forward declaration is ugly, better to remove
the inline tag (let the compiler handle it) or move the function
above all the call sites.
^ permalink raw reply
* RE: [PATCH 1/2] benet: Wait f/w POST until timeout
From: Perla, Sathya @ 2013-03-06 4:45 UTC (permalink / raw)
To: David Miller, shangw@linux.vnet.ibm.com
Cc: netdev@vger.kernel.org, Seetharaman, Subramanian, Khaparde, Ajit
In-Reply-To: <20130305.163431.2055740152739079020.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
>
> From: Gavin Shan <shangw@linux.vnet.ibm.com>
> Date: Mon, 4 Mar 2013 15:48:46 +0800
>
> > While PCI card faces EEH errors, reset (usually hot reset) is expected
> > to recover from the EEH errors. After EEH core finishes the reset, the
> > driver callback (be_eeh_reset) is called and wait the firmware to
> > complete POST successfully. The original code would return with error
> > once detecting failure during POST stage. That seems not enough.
> >
> > The patch forces the driver (be_eeh_reset) to wait the firmware
> > completes POST until timeout, instead of returning error upon
> > detection POST failure immediately. Also, it would improve the
> > reliability of the EEH funtionality of the driver.
> >
> > Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>
> I know that patch #2 of this series needs to be implemented differently, but this
> patch seems fine.
>
> So can I get an ACK from one of the benet driver folks?
Acked-by: Sathya Perla <sathya.perla@emulex.com>
thanks!
^ permalink raw reply
* Re: [PATCH 0/4] other ircomm_tty fixes
From: David Miller @ 2013-03-06 4:44 UTC (permalink / raw)
To: peter; +Cc: samuel, sasha.levin, gregkh, netdev, jslaby, linux-kernel
In-Reply-To: <1362499747-4262-1-git-send-email-peter@hurleysoftware.com>
From: Peter Hurley <peter@hurleysoftware.com>
Date: Tue, 5 Mar 2013 11:09:03 -0500
> On Sun, 2013-03-03 at 23:24 -0500, Peter Hurley wrote:
>> In the meantime, while reviewing that code, I noticed there's a handful
>> of serious bugs in that one function that I'll send a patchset for.
>
> As promised.
>
>
> Peter Hurley (4):
> net/irda: Fix port open counts
> net/irda: Hold port lock while bumping blocked_open
> net/irda: Use barrier to set task state
> net/irda: Raise dtr in non-blocking open
Series looks good, all applied, thanks Peter!
^ permalink raw reply
* Re: [net 0/4][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2013-03-06 4:42 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1362476917-5189-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 5 Mar 2013 01:48:33 -0800
> This series contains fixes to e1000e and igb.
>
> The e1000e fix resolves an issue at 1000Mbps link speed, where one of the
> MAC's internal clocks can be stopped for up to 4us when entering K1 (a
> power mode of the MAC-PHY interconnect). If the MAC is waiting for
> completion indications for 2 DMA write requests into Host memory
> (e.g. descriptor writeback or Rx packet writing) and the
> indications occur while the clock is stopped, both indications will be
> missed by the MAC causing the MAC to wait for the completion indications
> and be unable to generate further DMA write requests. This results in an
> apparent hardware hang. The patch works-around the issue by disabling
> the de-assertion of the clock request when 1000Mbps link is acquired (K1
> must be disabled while doing this).
>
> The igb fix to drop BUILD_BUG_ON check from igb_build_rx_buffer resolves
> a build error on s390 devices. The igb driver was throwing a build error
> due to the fact that a frame built using build_skb would be larger than 2K.
> Since this is not likely to change at any point in the future we are better
> off just dropping the check since we already had a check in
> igb_set_rx_buffer_len that will just disable the usage of build_skb anyway.
>
> The igb fix for i210 link setup changes the setup copper link function
> to use a switch statement, so that the appropriate setup link function
> is called for the given PHY types.
>
> Lastly, the igb fix for a lockdep issue in igb_get_i2c_client resolves
> the issue by re-factoring the initialization and usage of the i2c_client.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnx2x: use the default NAPI weight
From: David Miller @ 2013-03-06 4:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, eilong
In-Reply-To: <1362540509.15793.158.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 05 Mar 2013 19:28:29 -0800
> We are facing a fanout/fanin problem for a given application.
>
> What happens is that link is mostly idle, and every couple of minutes,
> we receive a burst of messages, needing a burst of transmits.
>
> BQL starts with a limit of 0, meaning it needs some TX completion runs
> to be able to detect the sudden increase of TX need and reach line rate.
>
> bnx2x is really unfair in this scenario, because the NAPI poll budget is
> very high, and aggregated packets (by LRO) count for a single packet in
> the budget. (or even 0, see the "goto next_cqe;" that avoids the rx_pkt
> ++; in drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c line 1007)
>
> We probably have other issues in the stack, I am patiently finding all
> of them. In the mean time we had to disable BQL :(
Thanks for the explanation.
Since you haven't completely resolved the issues you were running into
I'll target this to net-next for now.
Thanks!
^ permalink raw reply
* RE: [PATCH net-next 1/3] net: stmmac: add gmac autoneg set for SGMII, TBI, and RTBI
From: Byungho An @ 2013-03-06 4:13 UTC (permalink / raw)
To: 'Giuseppe CAVALLARO'
Cc: netdev, linux-kernel, davem, jeffrey.t.kirsher, kgene.kim, cpgs
In-Reply-To: <51277004.20702@st.com>
Hello Peppe,
> Hello Byungho
>
> sorry for my late reply. I'm attaching two patches built for net-next
> as we had clarified. I had written the first patch long time ago
> and on top of it I have added some part of your code below with some
> fixes (see also the comments inline below).
>
> This work is not yet completed but I do hope these two patches will
> help you to complete all. Unfortunately, I cannot do any tests
> because I have no HW that supports PCS. :-(
>
> In the second patch, take a look at the comment that reports
> the missing parts. For example, ethtool, SGMII etc.
>
> I wonder if you could review/test the two patches on your side.
Looks good to me and it works fine on my hardware platform. Just note, I
tested them with some additional stuff which is in stmmac_init_phy() and
stmmac_mdio_register() for SGMII.
> Also I hope you can improve all adding the missing features (that is
> what you were already doing).
>
> If you agree, you could also re-send *all* to the mailing list to
> be finally reviewed.
>
Anyway, in my opinion, you can take them in your tree for now with my
tested-by if you want. Of course, I'll implement additional patches as you
requested on top of them for remained stuff such as SGMII, TBI, ethtool and
so on.
I think those should be separated for each purpose and we can add and modify
after those two patches.
On 2/22/2013 10:418 PM, Giuseppe CAVALLARO wrote:
> On 1/25/2013 11:01 PM, Byungho An wrote:
> >
> > On 1/23/2013 1:43 PM, Giuseppe CAVALLARO write:
>
> [snip]
>
> >>
> > I modified this part like below
> >
> > @@ -1044,12 +1046,8 @@ static int stmmac_open(struct net_device *dev)
> > priv->hw->mac->core_init(priv->ioaddr);
> >
> > /* Enable auto-negotiation for SGMII, TBI or RTBI */
> > - if (interface == PHY_INTERFACE_MODE_SGMII ||
> > - interface == PHY_INTERFACE_MODE_TBI ||
> > - interface == PHY_INTERFACE_MODE_RTBI) {
> > - if (priv->phydev->autoneg)
> > - priv->hw->mac->set_autoneg(priv->ioaddr);
> > - }
> > + if (priv->dma_cap.pcs)
> > + priv->hw->mac->ctrl_ane(priv->ioaddr, 0);
> >
> > /* Request the IRQ lines */
> > ret = request_irq(dev->irq, stmmac_interrupt,
> >
> > As you may know, auto-negotiation is essential for SGMII, TBI, or RTBI
> > interface.
> >
>
> good, add it on top of the second patch.
this part is already in the second patch. I think restart flag should be 0
because auto-negotiation does not restarted in the stmmac_open function.
>
> > And ctrl_ane funciont is like that
> >
> > @@ -311,6 +317,18 @@ static void dwmac1000_set_autoneg(void __iomem
> *ioaddr)
> > writel(value, ioaddr + GMAC_AN_CTRL);
> > }
> >
> > +static void dwmac1000_ctrl_ane(void __iomem *ioaddr, bool restart)
> > +{
> > + u32 value;
> > +
> > + value = readl(ioaddr + GMAC_AN_CTRL);
> > + /* auto negotiation enable and External Loopback enable */
> > + value = GMAC_AN_CTRL__ANE | GMAC_AN_CTRL__ELE;
> > +
> > + if (restart)
> > + value |= GMAC_AN_CTRL_RAN;
> > +
> > + writel(value, ioaddr + GMAC_AN_CTRL);
> > +}
> >
> > static const struct stmmac_ops dwmac1000_ops = {
> > .core_init = dwmac1000_core_init,
>
> well done and added in the second patch.
>
> [snip]
> > I've changed restart AN like below.
> >
> > @@ -610,6 +607,27 @@ static int stmmac_set_coalesce(struct net_device
> *dev,
> > return 0;
> > }
> >
> > +static int
> > +stmmac_nway_reset(struct net_device *netdev)
> > +{
> > + struct stmmac_priv *priv = netdev_priv(netdev);
> > + struct phy_device *phy = priv->phydev;
> > + int ret = 0;
> > +
> > + spin_lock(&priv->lock);
> > +
> > + if (netif_running(netdev)) {
> > + phy_stop(phy);
> > + phy_start(phy);
> > + ret = phy_start_aneg(phy);
> > + if (priv->dma_cap.pcs)
> > + priv->hw->mac->ctrl_ane(priv->ioaddr, true);
> > + }
> > +
> > + spin_unlock(&priv->lock);
> > + return ret;
> > +}
> > +
> > static const struct ethtool_ops stmmac_ethtool_ops = {
> > .begin = stmmac_check_if_running,
> > .get_drvinfo = stmmac_ethtool_getdrvinfo,
> >
> >
>
> we have to review this. I expect to have a new patch that includes the
> ethtool support but, at first glance, the stmmac_nway_reset should only
> call the ctrl_ane.
>
> pay attention that also some other ethtool functions have to be fixed
> for this support.
>
I agree with you, I need more time to test ethtool support including
advertisement support.
> [snip]
>
> > I think whenever link is changed, phy->state is changed and call
> > stmmac_adjust_link. It would update gmac's link.
> > I can get autonegotiation complete and link change irqs if we need
> something
> > we can add code in the handler but I'm not sure which one is need yet.
> > As of now I just added phy_state = PHY_CHANGELINK as a test code in the
> link
> > change irq handler.
> >
> > @@ -1624,8 +1629,43 @@ static irqreturn_t stmmac_interrupt(int irq, void
> > *dev_id)
> >
priv->xstats.mmc_rx_csum_offload_irq_n++;
> > if (status & core_irq_receive_pmt_irq)
> > priv->xstats.irq_receive_pmt_irq_n++;
> > + if (status & core_irq_pcs_autoneg_complete)
> > + priv->core_pcs_an = true;
> > + if (status & core_irq_pcs_link_status_change) {
> > + priv->core_pcs_link_change = true;
> > + status = readl(priv->ioaddr +
> > GMAC_AN_STATUS);
> > + if (status & GMAC_AN_STATUS_LS)
> > + if ((priv->speed != phy->speed)
||
> > (priv->oldduplex != phy->duplex))
> > + phy->state = PHY_CHANGELINK; /*
for
> > test */
> > + }
> >
> > /* For LPI we need to save the tx status */
> > if (status & core_irq_tx_path_in_lpi_mode) {
> >
> > I have a question, how to hand over phy's irq number, as I analyzed
> > phydev->irq is irqlist and irqlist is like below but I can not find a
> way to
> > set phy's irq number.
> > How to register or set priv->mii_irq or mdio_bus_data->irqs.
> >
> > if (mdio_bus_data->irqs)
> > irqlist = mdio_bus_data->irqs;
> > else
> > irqlist = priv->mii_irq;
>
> I had added something in my first patch that should be ok.
>
> > I added some defines for AN like below
> > @@ -97,6 +97,20 @@ enum power_event {
> > #define GMAC_TBI 0x000000d4 /* TBI extend status */
> > #define GMAC_GMII_STATUS 0x000000d8 /* S/R-GMII status */
> >
> > +/* AN Configuration defines */
> > +#define GMAC_AN_CTRL_RAN 0x00000200 /* Restart
Auto-Negotiation
> > */
> > +#define GMAC_AN_CTRL_ANE 0x00001000 /* Auto-Negotiation
Enable
> > */
> > +#define GMAC_AN_CTRL_ELE 0x00004000 /* External Loopback
Enable
> > */
> > +#define GMAC_AN_CTRL_ECD 0x00010000 /* Enable Comma Detect
*/
> > +#define GMAC_AN_CTRL_LR 0x00020000 /* Lock to Reference */
> > +#define GMAC_AN_CTRL_SGMRAL 0x00040000 /* SGMII RAL Control */
> > +
> > +/* AN Status defines */
> > +#define GMAC_AN_STATUS_LS 0x00000004 /* Link Status 0:down
1:up
> > */
> > +#define GMAC_AN_STATUS_ANA 0x00000008 /* Auto-Negotiation
> Ability
> > */
> > +#define GMAC_AN_STATUS_ANC 0x00000020 /* Auto-Negotiation
> Complete
> > */
> > +#define GMAC_AN_STATUS_ES 0x00000100 /* Extended Status */
> > +
> > /* GMAC Configuration defines */
> > #define GMAC_CONTROL_TC 0x01000000 /* Transmit Conf. in
> > RGMII/SGMII */
> > #define GMAC_CONTROL_WD 0x00800000 /* Disable Watchdog on
> > receive */
>
> ok, these are in the second patch
^ permalink raw reply
* igb_down from bottom half context
From: ratheesh kannoth @ 2013-03-06 4:08 UTC (permalink / raw)
To: e1000-devel, netdev, linux-newbie; +Cc: Alexander Duyck
I have kernel timer which check for flag.
if(flag ) {
igb_down(adapter);
} else {
igb_up(adapter);
}
I could see a kernel crash; because there are a lot of msleep() in
igb_down function.
#define msleep(x) do { set_current_state(TASK_UNINTERRUPTIBLE); \
schedule_timeout((x * HZ)/1000 + 2); \
} while (0)
sleep() is called from bottom half context; this is the cause of kernel crash.
1) Since timer call back dont have process context associated with it;
i think , "current" points to the last preempted task ?
2) How can i introduce delays in interrupt context to avoid the kernel
crash. mdelay() will work ?
3) is there any better mechanism to do this job ?
Thanks,
Ratheesh
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnx2x: use the default NAPI weight
From: Eric Dumazet @ 2013-03-06 3:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eilong
In-Reply-To: <20130305.210909.1826827522208936437.davem@davemloft.net>
On Tue, 2013-03-05 at 21:09 -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 05 Mar 2013 17:57:47 -0800
>
> > BQL (Byte Queue Limits) proper operation needs TX completion
> > being serviced in a timely fashion.
> >
> > bnx2x uses a non standard NAPI poll weight, and thats not fair to other
> > napi poll handlers, and even not reasonable.
>
> Can you give some details about the situation in which you noticed
> this?
>
> It may be reason enough to target this for 'net' and -stable instead.
Sure :
We are facing a fanout/fanin problem for a given application.
What happens is that link is mostly idle, and every couple of minutes,
we receive a burst of messages, needing a burst of transmits.
BQL starts with a limit of 0, meaning it needs some TX completion runs
to be able to detect the sudden increase of TX need and reach line rate.
bnx2x is really unfair in this scenario, because the NAPI poll budget is
very high, and aggregated packets (by LRO) count for a single packet in
the budget. (or even 0, see the "goto next_cqe;" that avoids the rx_pkt
++; in drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c line 1007)
We probably have other issues in the stack, I am patiently finding all
of them. In the mean time we had to disable BQL :(
^ permalink raw reply
* Re: [PATCH 1/1] net: ipv4: Remove redundant NULL check
From: Sachin Kamat @ 2013-03-06 3:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130305.144052.577951922981506984.davem@davemloft.net>
On 6 March 2013 01:10, David Miller <davem@davemloft.net> wrote:
> From: Sachin Kamat <sachin.kamat@linaro.org>
> Date: Tue, 5 Mar 2013 16:57:09 +0530
>
>> kfree on a null pointer is a NO-OP. Hence null check is not necessary.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>
> Unnecessary writes to the socket struct should be avoided, as it
> generates unnecessary write traffic to the L2 cache.
Sounds reasonable.
>
> I'm not applying this.
Ok. No problem.
^ permalink raw reply
* [PATCH] net: docs: document multiqueue tuntap API
From: Jason Wang @ 2013-03-06 3:05 UTC (permalink / raw)
To: maxk, rob, linux-doc, linux-kernel, davem, netdev; +Cc: mst, hkchu, Jason Wang
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Documentation/networking/tuntap.txt | 77 +++++++++++++++++++++++++++++++++++
1 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/tuntap.txt b/Documentation/networking/tuntap.txt
index c0aab98..97423f5 100644
--- a/Documentation/networking/tuntap.txt
+++ b/Documentation/networking/tuntap.txt
@@ -105,6 +105,83 @@ Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
Proto [2 bytes]
Raw protocol(IP, IPv6, etc) frame.
+ 3.3 Multiqueue tuntap interface:
+
+ From version 3.8, Linux supports multiqueue tuntap which can uses multiple
+ file descriptors (queues) to parallelize packets sending or receiving. The
+ device allocation is the same as before, and if user wants to create multiple
+ queues, TUNSETIFF with the same device name must be called many times with
+ IFF_MULTI_QUEUE flag.
+
+ char *dev should be the name of the device, queues is the number of queues to
+ be created, fds is used to store and return the file descriptors (queues)
+ created to the caller. Each file descriptor were served as the interface of a
+ queue which could be accessed by userspace.
+
+ #include <linux/if.h>
+ #include <linux/if_tun.h>
+
+ int tun_alloc_mq(char *dev, int queues, int *fds)
+ {
+ struct ifreq ifr;
+ int fd, err, i;
+
+ if (!dev)
+ return -1;
+
+ memset(&ifr, 0, sizeof(ifr));
+ /* Flags: IFF_TUN - TUN device (no Ethernet headers)
+ * IFF_TAP - TAP device
+ *
+ * IFF_NO_PI - Do not provide packet information
+ * IFF_MULTI_QUEUE - Create a multiqueue devices
+ */
+ ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_MULTI_QUEUE;
+ strcpy(ifr.ifr_name, dev);
+
+ for (i = 0; i < queues; i++) {
+ if ((fd = open("/dev/net/tun", O_RDWR)) < 0)
+ goto err;
+ err = ioctl(fd, TUNSETIFF, (void *)&ifr);
+ if (err) {
+ close(fd);
+ goto err;
+ }
+ fds[i] = fd;
+ }
+
+ return 0;
+ err:
+ for (--i; i >= 0; i--)
+ close(fds[i]);
+ return err;
+ }
+
+ A new ioctl(TUNSETQUEUE) were introduced to enable or disable a queue. When
+ calling it with IFF_DETACH_QUEUE flag, the queue were disabled. And when
+ calling it with IFF_ATTACH_QUEUE flag, the queue were enabled. The queue were
+ enabled by default after it was created through TUNSETIFF.
+
+ fd is the file descriptor (queue) that we want to enable or disable, when
+ enable is true we enable it, otherwise we disable it
+
+ #include <linux/if.h>
+ #include <linux/if_tun.h>
+
+ int tun_set_queue(int fd, int enable)
+ {
+ struct ifreq ifr;
+
+ memset(&ifr, 0, sizeof(ifr));
+
+ if (enable)
+ ifr.ifr_flags = IFF_ATTACH_QUEUE;
+ else
+ ifr.ifr_flags = IFF_DETACH_QUEUE;
+
+ return ioctl(fd, TUNSETQUEUE, (void *)&ifr);
+ }
+
Universal TUN/TAP device driver Frequently Asked Question.
1. What platforms are supported by TUN/TAP driver ?
--
1.7.1
^ permalink raw reply related
* [PATCH] net/ipv4: Timestamp option cannot overflow with prespecified addresses
From: David Ward @ 2013-03-06 3:06 UTC (permalink / raw)
To: netdev; +Cc: David Ward
When a router forwards a packet that contains the IPv4 timestamp option,
if there is no space left in the option for the router to add its own
timestamp, then the router increments the Overflow value in the option.
However, if the addresses of the routers are prespecified in the option,
then the overflow condition cannot happen: the option is structured so
that each prespecified router has a place to write its timestamp. Other
routers do not add a timestamp, so there will never be a lack of space.
This fix ensures that the Overflow value in the IPv4 timestamp option is
not incremented when the addresses of the routers are prespecified, even
if the Pointer value is greater than the Length value.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
net/ipv4/ip_options.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index f6289bf..310a364 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -423,7 +423,7 @@ int ip_options_compile(struct net *net,
put_unaligned_be32(midtime, timeptr);
opt->is_changed = 1;
}
- } else {
+ } else if ((optptr[3]&0xF) != IPOPT_TS_PRESPEC) {
unsigned int overflow = optptr[3]>>4;
if (overflow == 15) {
pp_ptr = optptr + 3;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 4/7] usbnet: cdc_mbim: don't recover device if suspend fails in system sleep
From: Ming Lei @ 2013-03-06 3:03 UTC (permalink / raw)
To: Bjørn Mork
Cc: David S. Miller, Greg Kroah-Hartman, Jiri Kosina, Alan Stern,
Oliver Neukum, netdev, linux-usb, linux-input
In-Reply-To: <CACVXFVMMtjfea2N7ZMp1j0q_kcg95_RVx6COQ3hGSaxxwftEaw@mail.gmail.com>
On Wed, Mar 6, 2013 at 10:51 AM, Ming Lei <ming.lei@canonical.com> wrote:
> On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork <bjorn@mork.no> wrote:
>> Ming Lei <ming.lei@canonical.com> writes:
>>
>> I am starting to wonder why the USB core has combined system suspend and
>> runtime suspend if we are going to end up with every driver testing
>> PMSG_IS_AUTO(message) and selecting a completely different code path.
>>
>> You are right that we will end up with problems if usbnet_resume is
>> called for a device usbnet hasn't suspended. But I'd still claim that
>> is a bug in the USB core, which is the one that decided to ignore the
>> suspend error and still call resume.
>>
>> I guess proper error handling here require the USB core to see the
>> interface driver as dead if it fails to suspend on system suspend, and
>> do forced rebinding on resume.
>
> The idea should be fine, but may cause regression of user space, suppose
> one device with suspend failure can be across suspend-resume cycle and
> work well before, but it is no longer with your forced rebinding.
Give the potential cost(user space regression) of doing rebind, I think it
is better to try to recover the device in resume() first, then
consider rebinding
as the last straw. In fact, I am also wondering if resume() can't recover one
device but probe() can, maybe we can always let resume() recover the
device which experienced suspend failure.
I remember that some guys went against rebinding during system sleep before
in the firmware loading discussion.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH 4/7] usbnet: cdc_mbim: don't recover device if suspend fails in system sleep
From: Ming Lei @ 2013-03-06 2:51 UTC (permalink / raw)
To: Bjørn Mork
Cc: David S. Miller, Greg Kroah-Hartman, Jiri Kosina, Alan Stern,
Oliver Neukum, netdev, linux-usb, linux-input
In-Reply-To: <87wqtlommw.fsf@nemi.mork.no>
On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork <bjorn@mork.no> wrote:
> Ming Lei <ming.lei@canonical.com> writes:
>
> I am starting to wonder why the USB core has combined system suspend and
> runtime suspend if we are going to end up with every driver testing
> PMSG_IS_AUTO(message) and selecting a completely different code path.
>
> You are right that we will end up with problems if usbnet_resume is
> called for a device usbnet hasn't suspended. But I'd still claim that
> is a bug in the USB core, which is the one that decided to ignore the
> suspend error and still call resume.
>
> I guess proper error handling here require the USB core to see the
> interface driver as dead if it fails to suspend on system suspend, and
> do forced rebinding on resume.
The idea should be fine, but may cause regression of user space, suppose
one device with suspend failure can be across suspend-resume cycle and
work well before, but it is no longer with your forced rebinding.
>
> I am not going to fight this any longer. The per-driver
> PMSG_IS_AUTO(message) testing is an ugly workround for a core problem,
> but they are already all over the place... Still, please make sure the
> drivers all return 0 if they are pretending to suspend. No error code
> return if the driver ignores the error.
I agree, resume() of driver has to handle the suspend failure if there is
the failure returned from suspend().
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: hitting lockdep warning as of too early VF probe with 3.9-rc1
From: Ming Lei @ 2013-03-06 2:43 UTC (permalink / raw)
To: Or Gerlitz
Cc: Greg Kroah-Hartman, David Miller, Roland Dreier, netdev,
Yan Burman, Jack Morgenstein
In-Reply-To: <51360D7C.3060209@mellanox.com>
On Tue, Mar 5, 2013 at 11:21 PM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> Hi Ming, Greg, Roland, Dave, all..
>
> With 3.9-rc1, we are hitting the below lockdep with probing of virtual
> functions over the mlx4 driver, where it seems that the probing of the VF
> starts before the PF initialization is done.
>
> Yan Burman from our team bisected that to be introduced by commit
> 190888ac01d059e38ffe77a2291d44cafa9016fb
> "driver core: fix possible missing of device probe".
I guess that the lockdep warning still can be triggered without the commit.
> Basically what happens is that the VF probe fails, and once the PF
> probing/initialization is done, the VF
> is probed again and this time it succeeds.
>
> Anything here which people see to be possibly wrong with the mlx4_core
> (drivers/net/ethernet/mellanox/mlx4) driver interaction with the PCI
> subsystem?
>
> Or.
>
>
> mlx4_core: Initializing 0000:04:00.0
> mlx4_core 0000:04:00.0: Enabling SR-IOV with 1 VFs
> pci 0000:04:00.1: [15b3:1004] type 00 class 0x028000
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 3.9.0-rc1 #96 Not tainted
> ---------------------------------------------
> kworker/0:1/734 is trying to acquire lock:
> ((&wfc.work)){+.+.+.}, at: [<ffffffff81066cb0>] flush_work+0x0/0x250
>
> but task is already holding lock:
> ((&wfc.work)){+.+.+.}, at: [<ffffffff81064352>]
> process_one_work+0x162/0x4c0
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
> ----
> lock((&wfc.work));
> lock((&wfc.work));
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 3 locks held by kworker/0:1/734:
> #0: (events){.+.+.+}, at: [<ffffffff81064352>]
> process_one_work+0x162/0x4c0
> #1: ((&wfc.work)){+.+.+.}, at: [<ffffffff81064352>]
> process_one_work+0x162/0x4c0
> #2: (&__lockdep_no_validate__){......}, at: [<ffffffff812db225>]
> device_attach+0x25/0xb0
>
> stack backtrace:
> Pid: 734, comm: kworker/0:1 Not tainted 3.9.0-rc1 #96
> Call Trace:
> [<ffffffff810948ec>] validate_chain+0xdcc/0x11f0
> [<ffffffff81095150>] __lock_acquire+0x440/0xc70
> [<ffffffff81095150>] ? __lock_acquire+0x440/0xc70
> [<ffffffff810959da>] lock_acquire+0x5a/0x70
> [<ffffffff81066cb0>] ? wq_worker_waking_up+0x60/0x60
> [<ffffffff81066cf5>] flush_work+0x45/0x250
> [<ffffffff81066cb0>] ? wq_worker_waking_up+0x60/0x60
> [<ffffffff810922be>] ? mark_held_locks+0x9e/0x130
> [<ffffffff81066a96>] ? queue_work_on+0x46/0x90
> [<ffffffff810925dd>] ? trace_hardirqs_on_caller+0xfd/0x190
> [<ffffffff8109267d>] ? trace_hardirqs_on+0xd/0x10
> [<ffffffff81066f74>] work_on_cpu+0x74/0x90
> [<ffffffff81063820>] ? keventd_up+0x20/0x20
> [<ffffffff8121fd30>] ? pci_pm_prepare+0x60/0x60
> [<ffffffff811f9293>] ? cpumask_next_and+0x23/0x40
> [<ffffffff81220a1a>] pci_device_probe+0xba/0x110
> [<ffffffff812dadca>] ? driver_sysfs_add+0x7a/0xb0
> [<ffffffff812daf1f>] driver_probe_device+0x8f/0x230
> [<ffffffff812db170>] ? __driver_attach+0xb0/0xb0
> [<ffffffff812db1bb>] __device_attach+0x4b/0x60
> [<ffffffff812d9314>] bus_for_each_drv+0x64/0x90
> [<ffffffff812db298>] device_attach+0x98/0xb0
> [<ffffffff81218474>] pci_bus_add_device+0x24/0x50
> [<ffffffff81232e80>] virtfn_add+0x240/0x3e0
You are adding one new PCI device inside another PCI device's probe(),
so the new device will be probed, since PCI probe() is scheduled by
work_on_cpu, then cause flush_work() called inside worker function,
which might be a real deadlock.
I am wondering why this commit can cause the problem, since the PCI
device will be probed with its driver if there is one driver for it. There is no
any limit on when the driver should be loaded into system, either before
device is added or after.
>From driver core view, looks no wrong things are found.
> [<ffffffff8146ce3d>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
> [<ffffffff812333be>] pci_enable_sriov+0x23e/0x500
> [<ffffffffa011fa1a>] __mlx4_init_one+0x5da/0xce0 [mlx4_core]
> [<ffffffffa012016d>] mlx4_init_one+0x2d/0x60 [mlx4_core]
> [<ffffffff8121fd79>] local_pci_probe+0x49/0x80
> [<ffffffff81063833>] work_for_cpu_fn+0x13/0x20
> [<ffffffff810643b8>] process_one_work+0x1c8/0x4c0
> [<ffffffff81064352>] ? process_one_work+0x162/0x4c0
> [<ffffffff81064cfb>] worker_thread+0x30b/0x430
> [<ffffffff810649f0>] ? manage_workers+0x340/0x340
> [<ffffffff8106cea6>] kthread+0xd6/0xe0
> [<ffffffff8106cdd0>] ? __init_kthread_worker+0x70/0x70
> [<ffffffff8146daac>] ret_from_fork+0x7c/0xb0
> [<ffffffff8106cdd0>] ? __init_kthread_worker+0x70/0x70
> mlx4_core: Initializing 0000:04:00.1
> mlx4_core 0000:04:00.1: enabling device (0000 -> 0002)
> mlx4_core 0000:04:00.1: Detected virtual function - running in slave mode
> mlx4_core 0000:04:00.1: Sending reset
> mlx4_core 0000:04:00.1: Got slave FLRed from Communication channel (ret:0x1)
> mlx4_core 0000:04:00.1: slave is currently in themiddle of FLR.
> retrying...(try num:1)
> mlx4_core 0000:04:00.1: Communication channel is not idle.my toggle is 1
> (cmd:0x0)
> mlx4_core 0000:04:00.1: slave is currently in themiddle of FLR.
> retrying...(try num:2)
> [... repeated the same ...]
> mlx4_core 0000:04:00.1: slave is currently in themiddle of FLR.
> retrying...(try num:10)
> mlx4_core 0000:04:00.1: Communication channel is not idle.my toggle is 1
> (cmd:0x0)
> mlx4_core 0000:04:00.1: slave driver version is not supported by the master
> mlx4_core 0000:04:00.1: Communication channel is not idle.my toggle is 1
> (cmd:0x0)
> mlx4_core 0000:04:00.1: Failed to initialize slave
> mlx4_core: probe of 0000:04:00.1 failed with error -5
> mlx4_core 0000:04:00.0: Running in master mode
> mlx4_core 0000:04:00.0: FW version 2.11.500 (cmd intf rev 3), max commands
> 16
> mlx4_core 0000:04:00.0: Catastrophic error buffer at 0x1f020, size 0x10, BAR
> 0
> mlx4_core 0000:04:00.0: Communication vector bar:2 offset:0x800
> [... probing of PF continues ...]
> mlx4_core 0000:04:00.0: Started init_resource_tracker: 80 slaves
> mlx4_core 0000:04:00.0: irq 83 for MSI/MSI-X
> mlx4_core 0000:04:00.0: irq 84 for MSI/MSI-X
> mlx4_core 0000:04:00.0: irq 85 for MSI/MSI-X
> mlx4_core 0000:04:00.0: irq 86 for MSI/MSI-X
> mlx4_core 0000:04:00.0: NOP command IRQ test passed
> [... probing of PF ends ...]
> [... probing of VF done again ...]
> mlx4_core: Initializing 0000:04:00.1
> mlx4_core 0000:04:00.1: enabling device (0000 -> 0002)
> mlx4_core 0000:04:00.1: Detected virtual function - running in slave mode
> mlx4_core 0000:04:00.1: Sending reset
> mlx4_core 0000:04:00.0: Received reset from slave:1
> mlx4_core 0000:04:00.1: Sending vhcr0
> [... probing of VF succeeds ...]
> mlx4_core 0000:04:00.1: NOP command IRQ test passed
>
>
>
>
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH net-next 2/2] bnx2x: use the default NAPI weight
From: David Miller @ 2013-03-06 2:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, eilong
In-Reply-To: <1362535067.15793.146.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 05 Mar 2013 17:57:47 -0800
> BQL (Byte Queue Limits) proper operation needs TX completion
> being serviced in a timely fashion.
>
> bnx2x uses a non standard NAPI poll weight, and thats not fair to other
> napi poll handlers, and even not reasonable.
Can you give some details about the situation in which you noticed
this?
It may be reason enough to target this for 'net' and -stable instead.
Thanks!
^ 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