* Re: [net-next PATCH 02/12] ixgbe: updates vlan feature flags to enable FCoE offloads on vlan interface
From: David Miller @ 2009-08-14 23:12 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, linux-scsi, gospo, vasu.dev, yi.zou,
peter.p.waskiewicz.jr
In-Reply-To: <20090814224127.1640.84665.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 14 Aug 2009 15:41:28 -0700
> From: Vasu Dev <vasu.dev@intel.com>
>
> Updates netdev->vlan_features for NETIF_F_FCOE_CRC and NETIF_F_FSO, so that
> FCoE CRC and GSO offloads will get used for FCoE over ixgbe based vlan
> interface.
>
> Signed-off-by: Vasu Dev <vasu.dev@intel.com>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 01/12] vlan: adds fcoe offload related net_device_ops and updates fcoe_ddp_xid field
From: David Miller @ 2009-08-14 23:12 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, linux-scsi, gospo, vasu.dev
In-Reply-To: <20090814224106.1640.6910.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 14 Aug 2009 15:41:07 -0700
> From: Vasu Dev <vasu.dev@intel.com>
>
> Adds fcoe offload related net_device_ops functions vlan_dev_fcoe_ddp_setup
> and vlan_dev_fcoe_ddp_done, their implementation simply calls real eth device
> net_device_ops for FCoE DDP setup and done operations.
>
> Updates VLAN netdev field value for fcoe_ddp_xid from real eth device netdev.
>
> Above changes are required for fcoe DDP offload working on a VLAN interface.
>
> Signed-off-by: Vasu Dev <vasu.dev@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 04/12] ixgbe: Add support for NETIF_F_FCOE_MTU to 82599 devices
From: David Miller @ 2009-08-14 23:12 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, linux-scsi, gospo, yi.zou
In-Reply-To: <20090814224217.1640.49274.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 14 Aug 2009 15:42:17 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> Enable netdev feature flag bit NETIF_F_FCOE_MTU for 82599 devices and enable
> jumbo frame correspondingly when NETIF_F_FCOE_MTU is set.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 03/12] net: Add NETIF_F_FCOE_MTU to indicate support for a different MTU for FCoE
From: David Miller @ 2009-08-14 23:12 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, linux-scsi, gospo, yi.zou
In-Reply-To: <20090814224156.1640.59034.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 14 Aug 2009 15:41:57 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> Add NETIF_F_FCOE_MTU to indicate that the NIC can support a secondary MTU for
> converged traffic of LAN and Fiber Channel over Ethernet (FCoE). The MTU for
> FCoE is 2158 = 14 (FCoE header) + 24 (FC header) + 2112 (FC max payload) +
> 4 (FC CRC) + 4 (FCoE trailer).
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 05/12] net: Add ndo_fcoe_control to net_device_ops
From: David Miller @ 2009-08-14 23:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, linux-scsi, gospo, yi.zou
In-Reply-To: <20090814224239.1640.74924.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 14 Aug 2009 15:42:39 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> Add ndo_fcoe_control to net_device_ops so the corresponding HW can initialize
> itself for FCoE traffic or clean up after FCoE traffic is done. This is
> expected to be called by the kernel FCoE stack upon receiving a request for
> creating an FCoE instance on the corresponding netdev interface. When
> implemented by the actual HW, the HW driver check the op code to perform
> corresponding initialization or clean up for FCoE. The initialization normally
> includes allocating extra queues for FCoE, setting corresponding HW registers
> for FCoE, indicating FCoE offload features via netdev, etc. The clean-up would
> include releasing the resources allocated for FCoE.
>
> Currently, there are two defined op codes as NETDEV_FCOE_DISABLE and _ENABLE,
> for initialization and cleanup accordingly.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
And here is where I stop applying patches. This is not the way
to do this.
Having a vague "_control" operation with command codes is almost
as bad as ioctl().
Instead, add explicit ->ndo_fcoe_enable() and ndo_fcoe_disable()
operations.
Any other "control" commands you would add would probably need
parameters, and then this method would be a tangled web of
misc parameter slots and an even more tangled web of semantics.
Please resubmit the rest of this series once this issue is corrected.
Thanks.
^ permalink raw reply
* Re: [PATCH] yellowfin: Fix buffer underrun after dev_alloc_skb() failure
From: David Miller @ 2009-08-14 23:17 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm
In-Reply-To: <4A853572.70209@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 14 Aug 2009 11:59:14 +0200
> /* Reset the chip. */
> iowrite32(0x80000000, ioaddr + DMACtrl);
>
> - i = request_irq(dev->irq, &yellowfin_interrupt, IRQF_SHARED, dev->name, dev);
> - if (i) return i;
> + ret = request_irq(dev->irq, &yellowfin_interrupt, IRQF_SHARED, dev->name, dev);
> + if (ret)
> + return ret;
>
> if (yellowfin_debug > 1)
> printk(KERN_DEBUG "%s: yellowfin_open() irq %d.\n",
> dev->name, dev->irq);
>
> - yellowfin_init_ring(dev);
> + ret = yellowfin_init_ring(dev);
> + if (ret)
> + return ret;
>
> iowrite32(yp->rx_ring_dma, ioaddr + RxPtr);
> iowrite32(yp->tx_ring_dma, ioaddr + TxPtr);
If yellowfin_init_ring() returns an error, you're leaking the IRQ
allocated by request_irq().
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Neil Horman @ 2009-08-14 23:25 UTC (permalink / raw)
To: Bill Fink; +Cc: Linux Network Developers, brice, gallatin
In-Reply-To: <20090814164412.be5daa74.billfink@mindspring.com>
On Fri, Aug 14, 2009 at 04:44:12PM -0400, Bill Fink wrote:
> On Fri, 7 Aug 2009, Neil Horman wrote:
>
> > On Fri, Aug 07, 2009 at 08:54:42PM -0400, Bill Fink wrote:
> > > On Fri, 7 Aug 2009, Neil Horman wrote:
> > >
> > > > You're timing is impeccable! I just posted a patch for an ftrace module to help
> > > > detect just these kind of conditions:
> > > > http://marc.info/?l=linux-netdev&m=124967650218846&w=2
> > > >
> > > > Hope that helps you out
> > > > Neil
> > >
> > > Thanks! It could be helpful. Do you have a pointer to documentation
> > > on how to use it? And does it require the latest GIT kernel or could
> > > it possibly be used with a 2.6.29.6 kernel?
> > >
> > > -Bill
> >
> > It should apply to 2.6.29.6 no problem (might take a little massaging, but not
> > much).
>
> It doesn't look like I can apply your patches to my 2.6.29.6 kernel.
>
> For starters, there's no include/trace/events directory, so there's
> no include/trace/events/skb.h. There is an include/trace/skb.h file,
> but there's no TRACE_EVENT defined anywhere in the kernel.
>
> I don't suppose it's as simple as defining (from include/linux/tracepoint.h
> from Linus's GIT tree):
>
> #define PARAMS(args...) args
>
> #define TRACE_EVENT(name, proto, args, struct, assign, print) \
> DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
>
> So do you still think it's reasonable to try applying your patches
> to my 2.6.29.6 kernel, or should I get a newer kernel like 2.6.30.4
> or 2.6.31-rc6?
>
> -Thanks
>
> -Bill
>
>
>
I thought the trace stuff went it around 2.6.29 but I might be mistaken.
Easiest thing to do likely would be find where in the tree those were introduced
and just apply them prior to my patches, or move to the latest kernel if you
can (at least for the purposes of testing)
Neil
^ permalink raw reply
* RE: [net-next PATCH 05/12] net: Add ndo_fcoe_control to net_device_ops
From: Zou, Yi @ 2009-08-14 23:29 UTC (permalink / raw)
To: David Miller, Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, linux-scsi@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <20090814.161443.18892020.davem@davemloft.net>
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Friday, August 14, 2009 4:15 PM
>To: Kirsher, Jeffrey T
>Cc: netdev@vger.kernel.org; linux-scsi@vger.kernel.org; gospo@redhat.com; Zou,
>Yi
>Subject: Re: [net-next PATCH 05/12] net: Add ndo_fcoe_control to
>net_device_ops
>
>From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>Date: Fri, 14 Aug 2009 15:42:39 -0700
>
>> From: Yi Zou <yi.zou@intel.com>
>>
>> Add ndo_fcoe_control to net_device_ops so the corresponding HW can
>initialize
>> itself for FCoE traffic or clean up after FCoE traffic is done. This is
>> expected to be called by the kernel FCoE stack upon receiving a request for
>> creating an FCoE instance on the corresponding netdev interface. When
>> implemented by the actual HW, the HW driver check the op code to perform
>> corresponding initialization or clean up for FCoE. The initialization
>normally
>> includes allocating extra queues for FCoE, setting corresponding HW
>registers
>> for FCoE, indicating FCoE offload features via netdev, etc. The clean-up
>would
>> include releasing the resources allocated for FCoE.
>>
>> Currently, there are two defined op codes as NETDEV_FCOE_DISABLE and
>_ENABLE,
>> for initialization and cleanup accordingly.
>>
>> Signed-off-by: Yi Zou <yi.zou@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
>And here is where I stop applying patches. This is not the way
>to do this.
>
>Having a vague "_control" operation with command codes is almost
>as bad as ioctl().
>
>Instead, add explicit ->ndo_fcoe_enable() and ndo_fcoe_disable()
>operations.
>
>Any other "control" commands you would add would probably need
>parameters, and then this method would be a tangled web of
>misc parameter slots and an even more tangled web of semantics.
>
>Please resubmit the rest of this series once this issue is corrected.
>
>Thanks.
Thanks, I was kind of worried about the growing of fcoe related function
pointers there. I am thinking that if it may be better to move into a
fcoe_ops structure. If so, I will rework these patch and move them into
the fcoe_ops sturct in the updated set of patches. This will also make sense
as I am currently trying to add support for querying the nic for the Fiber
Channel WWN for the FCoE kernel stack (based on the SAN MAC address plus 2
more bytes as the IEEE extended address format) from the from the same ops
struct.
Thanks,
yi
^ permalink raw reply
* Re: [PATCH] via-velocity: Fix test of mii_status bit VELOCITY_DUPLEX_FULL
From: David Miller @ 2009-08-14 23:31 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm, romieu
In-Reply-To: <4A855414.10007@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 14 Aug 2009 14:09:56 +0200
> Test whether VELOCITY_DUPLEX_FULL bit is set in mii_status.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [Fwd: pegasus usb net driver]
From: David Miller @ 2009-08-14 23:31 UTC (permalink / raw)
To: petkan; +Cc: jenoki, netdev
In-Reply-To: <98be570d7bcf50bef64ffbd1c3479004.squirrel@nucleusys.com>
From: petkan@nucleusys.com
Date: Fri, 14 Aug 2009 19:40:48 +0300 (EEST)
> Attached is a patch against 2.6.30.4 and below is the description. Please
> apply.
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] WAN: bit and/or confusion
From: David Miller @ 2009-08-14 23:32 UTC (permalink / raw)
To: roel.kluin; +Cc: romieu, netdev, akpm
In-Reply-To: <4A855DE2.2000907@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 14 Aug 2009 14:51:46 +0200
> Fix the tests that check whether Frame* bits are not set
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] drivers/net: fixed drivers that support netpoll use ndo_start_xmit()
From: David Miller @ 2009-08-14 23:32 UTC (permalink / raw)
To: mpm; +Cc: Dongdong.deng, netdev, linux-kernel, Bruce.Ashfield, jason.wessel
In-Reply-To: <1250264019.3807.1301.camel@calx>
From: Matt Mackall <mpm@selenic.com>
Date: Fri, 14 Aug 2009 10:33:39 -0500
> On Fri, 2009-08-14 at 13:12 +0800, DDD wrote:
>> The NETPOLL API requires that interrupts remain disabled in
>> netpoll_send_skb(). The use of spin_lock_irq() and spin_unlock_irq()
>> in the NETPOLL API callbacks causes the interrupts to get enabled and
>> can lead to kernel instability.
>>
>> The solution is to use spin_lock_irqsave() and spin_unlock_restore()
>> to prevent the irqs from getting enabled while in netpoll_send_skb().
...
>> Signed-off-by: Dongdong Deng <dongdong.deng@windriver.com>
>> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
>> Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>
> Acked-by: Matt Mackall <mpm@selenic.com>
Applied, thanks everyone.
> Perhaps we should also have a WARN_ONCE if start_xmit returns with
> interrupts enabled?
Probably a good idea.
^ permalink raw reply
* [PATCH] sky2: remove restarting workaround flag
From: Stephen Hemminger @ 2009-08-14 23:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090814.154154.53636130.davem@davemloft.net>
The whole restarting flag was introduced by Mike McCormack
and was a temporary duct tape patch around issues with transmits
inflight during restart. The problems it was covering are now
fixed and the code should have been reverted.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sky2.c 2009-08-14 16:29:56.716322334 -0700
+++ b/drivers/net/sky2.c 2009-08-14 16:30:05.681690475 -0700
@@ -1496,8 +1496,6 @@ static int sky2_up(struct net_device *de
sky2_set_vlan_mode(hw, port, sky2->vlgrp != NULL);
#endif
- sky2->restarting = 0;
-
err = sky2_rx_start(sky2);
if (err)
goto err_out;
@@ -1508,9 +1506,6 @@ static int sky2_up(struct net_device *de
sky2_write32(hw, B0_IMSK, imask);
sky2_read32(hw, B0_IMSK);
- /* wake queue incase we are restarting */
- netif_wake_queue(dev);
-
if (netif_msg_ifup(sky2))
printk(KERN_INFO PFX "%s: enabling interface\n", dev->name);
@@ -1545,8 +1540,6 @@ static inline int tx_dist(unsigned tail,
/* Number of list elements available for next tx */
static inline int tx_avail(const struct sky2_port *sky2)
{
- if (unlikely(sky2->restarting))
- return 0;
return sky2->tx_pending - tx_dist(sky2->tx_cons, sky2->tx_prod);
}
@@ -1850,10 +1843,6 @@ static int sky2_down(struct net_device *
if (netif_msg_ifdown(sky2))
printk(KERN_INFO PFX "%s: disabling interface\n", dev->name);
- /* explicitly shut off tx incase we're restarting */
- sky2->restarting = 1;
- netif_tx_disable(dev);
-
/* Force flow control off */
sky2_write8(hw, SK_REG(port, GMAC_CTRL), GMC_PAUSE_OFF);
@@ -2382,7 +2371,7 @@ static inline void sky2_tx_done(struct n
{
struct sky2_port *sky2 = netdev_priv(dev);
- if (likely(netif_running(dev) && !sky2->restarting))
+ if (netif_running(dev))
sky2_tx_complete(sky2, last);
}
@@ -4327,7 +4316,6 @@ static __devinit struct net_device *sky2
spin_lock_init(&sky2->phy_lock);
sky2->tx_pending = TX_DEF_PENDING;
sky2->rx_pending = RX_DEF_PENDING;
- sky2->restarting = 0;
hw->dev[port] = dev;
--- a/drivers/net/sky2.h 2009-08-14 16:29:56.728439978 -0700
+++ b/drivers/net/sky2.h 2009-08-14 16:30:08.825275706 -0700
@@ -2053,7 +2053,6 @@ struct sky2_port {
#define SKY2_FLAG_AUTO_SPEED 0x0002
#define SKY2_FLAG_AUTO_PAUSE 0x0004
- u8 restarting;
enum flow_control flow_mode;
enum flow_control flow_status;
--
^ permalink raw reply
* Re: [PATCH] gre: Fix MTU calculation for bound GRE tunnels
From: David Miller @ 2009-08-14 23:34 UTC (permalink / raw)
To: thomas.goff; +Cc: netdev
In-Reply-To: <20090814183758.GA21197@boeing.com>
From: Tom Goff <thomas.goff@boeing.com>
Date: Fri, 14 Aug 2009 11:37:58 -0700
> The GRE header length should be subtracted when the tunnel MTU is
> calculated. This just corrects for the associativity change
> introduced by commit 42aa916265d740d66ac1f17290366e9494c884c2.
>
> Signed-off-by: Tom Goff <thomas.goff@boeing.com>
Thanks for finding and fixing this bug, applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] can: Use WARN_ONCE() instead of BUG_ON() for sanity check in receive path
From: David Miller @ 2009-08-14 23:37 UTC (permalink / raw)
To: oliver; +Cc: urs, l.fu, m.olbrich, netdev
In-Reply-To: <4A852641.80305@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Fri, 14 Aug 2009 10:54:25 +0200
> To ensure a proper handling of CAN frames transported in skbuffs some checks
> need to be performed at receive time.
>
> As stated by Michael Olbrich and Luotao Fu BUG_ON() might be to restrictive.
> This is right as we can just drop the non conform skbuff and the Kernel can
> continue working.
>
> This patch replaces the BUG_ON() with a WARN_ONCE() so that the system remains
> healthy but we made the problem visible (once).
>
> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
> Signed-off-by: Urs Thuermann <urs@isnogud.escape.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] WAN: bit and/or confusion
From: Andrew Morton @ 2009-08-14 23:36 UTC (permalink / raw)
To: Roel Kluin; +Cc: romieu, netdev, davem
In-Reply-To: <4A855DE2.2000907@gmail.com>
On Fri, 14 Aug 2009 14:51:46 +0200
Roel Kluin <roel.kluin@gmail.com> wrote:
> Fix the tests that check whether Frame* bits are not set
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> // vi drivers/net/wan/dscc4.c +307
> #define FrameVfr 0x80
> #define FrameRdo 0x40
> #define FrameCrc 0x20
> #define FrameRab 0x10
>
> diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
> index 8face5d..dd3c64a 100644
> --- a/drivers/net/wan/dscc4.c
> +++ b/drivers/net/wan/dscc4.c
> @@ -663,9 +663,9 @@ static inline void dscc4_rx_skb(struct dscc4_dev_priv *dpriv,
> } else {
> if (skb->data[pkt_len] & FrameRdo)
> dev->stats.rx_fifo_errors++;
> - else if (!(skb->data[pkt_len] | ~FrameCrc))
> + else if (!(skb->data[pkt_len] & ~FrameCrc))
> dev->stats.rx_crc_errors++;
that's
if (!(x & 0xffffffdf))
which seems peculiar. Should it have been
else if (skb->data[pkt_len] & FrameCrc)
or
else if (!(skb->data[pkt_len] & FrameCrc))
> - else if (!(skb->data[pkt_len] | ~(FrameVfr | FrameRab)))
> + else if (!(skb->data[pkt_len] & ~(FrameVfr | FrameRab)))
> dev->stats.rx_length_errors++;
> else
> dev->stats.rx_errors++;
^ permalink raw reply
* Re: [PATCH] s2io: Remove unnecessary casts
From: David Miller @ 2009-08-14 23:38 UTC (permalink / raw)
To: dave
Cc: ram.vepa, santosh.rastapur, sivakumar.subramani,
sreenivasa.honnur, anil.murthy, netdev, kernel-janitors
In-Reply-To: <20090814035733.GA29707@fencepost.gnu.org>
From: Davidlohr Bueso <dave@gnu.org>
Date: Thu, 13 Aug 2009 23:57:33 -0400
> Ok, resubmitting and verified by checkpatch.pl
>
> Thanks.
>
> Signed-off-by: Davidlohr Bueso <dave@gnu.org>
Your email client has corrupted the patch, turning tab
characters into spaces and whatnot.
Please correct this and make a fresh, formal, resubmission
(fresh subject, commit message, and all).
Thank you.
^ permalink raw reply
* Re: [PATCH] sky2: remove restarting workaround flag
From: David Miller @ 2009-08-14 23:38 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20090814163317.3c5b5942@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 14 Aug 2009 16:33:17 -0700
> The whole restarting flag was introduced by Mike McCormack
> and was a temporary duct tape patch around issues with transmits
> inflight during restart. The problems it was covering are now
> fixed and the code should have been reverted.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] WAN: bit and/or confusion
From: David Miller @ 2009-08-14 23:41 UTC (permalink / raw)
To: akpm; +Cc: roel.kluin, romieu, netdev
In-Reply-To: <20090814163644.0cc8974f.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Fri, 14 Aug 2009 16:36:44 -0700
> On Fri, 14 Aug 2009 14:51:46 +0200
> Roel Kluin <roel.kluin@gmail.com> wrote:
>
>> @@ -663,9 +663,9 @@ static inline void dscc4_rx_skb(struct dscc4_dev_priv *dpriv,
>> } else {
>> if (skb->data[pkt_len] & FrameRdo)
>> dev->stats.rx_fifo_errors++;
>> - else if (!(skb->data[pkt_len] | ~FrameCrc))
>> + else if (!(skb->data[pkt_len] & ~FrameCrc))
>> dev->stats.rx_crc_errors++;
>
> that's
>
> if (!(x & 0xffffffdf))
>
> which seems peculiar. Should it have been
>
> else if (skb->data[pkt_len] & FrameCrc)
>
> or
>
> else if (!(skb->data[pkt_len] & FrameCrc))
Indeed, I can't tell which variant would be correct.
I'm reverting until someone with a datasheet for this chip speaks up
:-)
^ permalink raw reply
* Re: [PATCH] WAN: bit and/or confusion
From: Andrew Morton @ 2009-08-14 23:58 UTC (permalink / raw)
To: David Miller; +Cc: roel.kluin, romieu, netdev
In-Reply-To: <20090814.164123.36875657.davem@davemloft.net>
On Fri, 14 Aug 2009 16:41:23 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Fri, 14 Aug 2009 16:36:44 -0700
>
> > On Fri, 14 Aug 2009 14:51:46 +0200
> > Roel Kluin <roel.kluin@gmail.com> wrote:
> >
> >> @@ -663,9 +663,9 @@ static inline void dscc4_rx_skb(struct dscc4_dev_priv *dpriv,
> >> } else {
> >> if (skb->data[pkt_len] & FrameRdo)
> >> dev->stats.rx_fifo_errors++;
> >> - else if (!(skb->data[pkt_len] | ~FrameCrc))
> >> + else if (!(skb->data[pkt_len] & ~FrameCrc))
> >> dev->stats.rx_crc_errors++;
> >
> > that's
> >
> > if (!(x & 0xffffffdf))
> >
> > which seems peculiar. Should it have been
> >
> > else if (skb->data[pkt_len] & FrameCrc)
> >
> > or
> >
> > else if (!(skb->data[pkt_len] & FrameCrc))
>
> Indeed, I can't tell which variant would be correct.
>
> I'm reverting until someone with a datasheet for this chip speaks up
> :-)
http://www.datasheet.in/download.php?id=39415
Page 383 and 384 say that bit 5 (CRC) is zero if the rx frame contained
errors.
So we need
else if (!(skb->data[pkt_len] & FrameCrc))
> - else if (!(skb->data[pkt_len] | ~(FrameVfr | FrameRab)))
> + else if (!(skb->data[pkt_len] & ~(FrameVfr | FrameRab)))
vfr is "valid frame". 0 is invalid.
rab is "receive message aborted". The data sheet doesn't actually say
if the bit is active-high or active-low (grr).
^ permalink raw reply
* [net-2.6 PATCH 1/2] e1000e: WoL does not work on 82577/82578 with manageability enabled
From: Jeff Kirsher @ 2009-08-15 0:35 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Bruce Allan, Jeff Kirsher
From: Bruce Allan <bruce.w.allan@intel.com>
With manageability (Intel AMT) enabled via BIOS, PHY wakeup does not get
configured on newer parts which use PHY wakeup vs. MAC wakeup which causes
WoL to not work. The driver should configure PHY wakeup whether or not
manageability is enabled.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 63415bb..58e22fc 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -4538,8 +4538,7 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool *enable_wake)
/* Allow time for pending master requests to run */
e1000e_disable_pcie_master(&adapter->hw);
- if ((adapter->flags2 & FLAG2_HAS_PHY_WAKEUP) &&
- !(hw->mac.ops.check_mng_mode(hw))) {
+ if (adapter->flags2 & FLAG2_HAS_PHY_WAKEUP) {
/* enable wakeup by the PHY */
retval = e1000_init_phy_wakeup(adapter, wufc);
if (retval)
@@ -4557,7 +4556,8 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool *enable_wake)
*enable_wake = !!wufc;
/* make sure adapter isn't asleep if manageability is enabled */
- if (adapter->flags & FLAG_MNG_PT_ENABLED)
+ if ((adapter->flags & FLAG_MNG_PT_ENABLED) ||
+ (hw->mac.ops.check_mng_mode(hw)))
*enable_wake = true;
if (adapter->hw.phy.type == e1000_phy_igp_3)
^ permalink raw reply related
* [net-2.6 PATCH 2/2] e1000e: fix use of pci_enable_pcie_error_reporting
From: Jeff Kirsher @ 2009-08-15 0:35 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Xiaotian Feng, Jeff Kirsher
In-Reply-To: <20090815003524.2335.3107.stgit@localhost.localdomain>
From: Xiaotian Feng <dfeng@redhat.com>
commit 111b9dc5 introduces pcie aer support for e1000e, but it is not
reasonable to disable it in e1000_remove but enable it in e1000_resume.
This patch enables aer support in e1000_probe.
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 58e22fc..fa92a68 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -4670,14 +4670,6 @@ static int e1000_resume(struct pci_dev *pdev)
return err;
}
- /* AER (Advanced Error Reporting) hooks */
- err = pci_enable_pcie_error_reporting(pdev);
- if (err) {
- dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
- "0x%x\n", err);
- /* non-fatal, continue */
- }
-
pci_set_master(pdev);
pci_enable_wake(pdev, PCI_D3hot, 0);
@@ -4990,6 +4982,14 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
if (err)
goto err_pci_reg;
+ /* AER (Advanced Error Reporting) hooks */
+ err = pci_enable_pcie_error_reporting(pdev);
+ if (err) {
+ dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
+ "0x%x\n", err);
+ /* non-fatal, continue */
+ }
+
pci_set_master(pdev);
/* PCI config space info */
err = pci_save_state(pdev);
^ permalink raw reply related
* [PATCH] tcp: fix premature termination of FIN_WAIT2 time-wait sockets
From: Octavian Purdila @ 2009-08-15 0:39 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]
NOTE: this issue has been found, fixed and tested on an ancient 2.6.7 kernel.
This patch is a blind port of that fix, since unfortunately there is no easy
way for me to reproduce the original issue with a newer kernel. But the issue
still seems to be there.
tavi
---
There is a race condition in the time-wait sockets code that can lead
to premature termination of FIN_WAIT2 and, subsequently, to RST
generation when the FIN,ACK from the peer finally arrives:
Time TCP header
0.000000 30755 > http [SYN] Seq=0 Win=2920 Len=0 MSS=1460 TSV=282912 TSER=0
0.000008 http > 30755 aSYN, ACK] Seq=0 Ack=1 Win=2896 Len=0 MSS=1460 TSV=...
0.136899 HEAD /1b.html?n1Lg=v1 HTTP/1.0 [Packet size limited during capture]
0.136934 HTTP/1.0 200 OK [Packet size limited during capture]
0.136945 http > 30755 [FIN, ACK] Seq=187 Ack=207 Win=2690 Len=0 TSV=270521...
0.136974 30755 > http [ACK] Seq=207 Ack=187 Win=2734 Len=0 TSV=283049 TSER=...
0.177983 30755 > http [ACK] Seq=207 Ack=188 Win=2733 Len=0 TSV=283089 TSER=...
0.238618 30755 > http [FIN, ACK] Seq=207 Ack=188 Win=2733 Len=0 TSV=283151...
0.238625 http > 30755 [RST] Seq=188 Win=0 Len=0
Say twdr->slot = 1 and we are running inet_twdr_hangman and in this
instance inet_twdr_do_twkill_work returns 1. At that point we will
mark slot 1 and schedule inet_twdr_twkill_work. We will also make
twdr->slot = 2.
Next, a connection is closed and tcp_time_wait(TCP_FIN_WAIT2, timeo)
is called which will create a new FIN_WAIT2 time-wait socket and will
place it in the last to be reached slot, i.e. twdr->slot = 1.
At this point say inet_twdr_twkill_work will run which will start
destroying the time-wait sockets in slot 1, including the just added
TCP_FIN_WAIT2 one.
To avoid this issue we increment the slot only if all entries in the
slot have been purged.
This change may delay the slots cleanup by a time-wait death row
period but only if the worker thread didn't had the time to run/purge
the current slot in the next period (6 seconds with default sysctl
settings). However, on such a busy system even without this change we
would probably see delays...
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
---
net/ipv4/inet_timewait_sock.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: b36bc8257b528fc8ce5d6e1eb988459f5c2be10d.diff --]
[-- Type: text/x-patch, Size: 551 bytes --]
diff --git a/net/ipv4/inet_timewait_sock.c b/net/ipv4/inet_timewait_sock.c
index 61283f9..13f0781 100644
--- a/net/ipv4/inet_timewait_sock.c
+++ b/net/ipv4/inet_timewait_sock.c
@@ -218,8 +218,8 @@ void inet_twdr_hangman(unsigned long data)
/* We purged the entire slot, anything left? */
if (twdr->tw_count)
need_timer = 1;
+ twdr->slot = ((twdr->slot + 1) & (INET_TWDR_TWKILL_SLOTS - 1));
}
- twdr->slot = ((twdr->slot + 1) & (INET_TWDR_TWKILL_SLOTS - 1));
if (need_timer)
mod_timer(&twdr->tw_timer, jiffies + twdr->period);
out:
^ permalink raw reply related
* [PATCH 5/5] cnic: Fix locking in init/exit calls.
From: Michael Chan @ 2009-08-15 1:49 UTC (permalink / raw)
To: davem, James.Bottomley, michaelc; +Cc: netdev, linux-scsi
In-Reply-To: <1250300987-18407-1-git-send-email-mchan@broadcom.com>
The slow path ulp_init and ulp_exit calls to the bnx2i driver
are sleepable calls and therefore should not be protected using
rcu_read_lock. Fix it by using mutex and refcount during these
calls. cnic_unregister_driver() will now wait for the refcount
to go to zero before completing the call.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Reviewed-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/cnic.c | 48 +++++++++++++++++++++++++++++++++++++++---------
drivers/net/cnic_if.h | 1 +
2 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 4ff618a..74c3429 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -138,6 +138,16 @@ static struct cnic_dev *cnic_from_netdev(struct net_device *netdev)
return NULL;
}
+static inline void ulp_get(struct cnic_ulp_ops *ulp_ops)
+{
+ atomic_inc(&ulp_ops->ref_count);
+}
+
+static inline void ulp_put(struct cnic_ulp_ops *ulp_ops)
+{
+ atomic_dec(&ulp_ops->ref_count);
+}
+
static void cnic_ctx_wr(struct cnic_dev *dev, u32 cid_addr, u32 off, u32 val)
{
struct cnic_local *cp = dev->cnic_priv;
@@ -358,6 +368,7 @@ int cnic_register_driver(int ulp_type, struct cnic_ulp_ops *ulp_ops)
}
read_unlock(&cnic_dev_lock);
+ atomic_set(&ulp_ops->ref_count, 0);
rcu_assign_pointer(cnic_ulp_tbl[ulp_type], ulp_ops);
mutex_unlock(&cnic_lock);
@@ -379,6 +390,8 @@ int cnic_register_driver(int ulp_type, struct cnic_ulp_ops *ulp_ops)
int cnic_unregister_driver(int ulp_type)
{
struct cnic_dev *dev;
+ struct cnic_ulp_ops *ulp_ops;
+ int i = 0;
if (ulp_type >= MAX_CNIC_ULP_TYPE) {
printk(KERN_ERR PFX "cnic_unregister_driver: Bad type %d\n",
@@ -386,7 +399,8 @@ int cnic_unregister_driver(int ulp_type)
return -EINVAL;
}
mutex_lock(&cnic_lock);
- if (!cnic_ulp_tbl[ulp_type]) {
+ ulp_ops = cnic_ulp_tbl[ulp_type];
+ if (!ulp_ops) {
printk(KERN_ERR PFX "cnic_unregister_driver: Type %d has not "
"been registered\n", ulp_type);
goto out_unlock;
@@ -411,6 +425,14 @@ int cnic_unregister_driver(int ulp_type)
mutex_unlock(&cnic_lock);
synchronize_rcu();
+ while ((atomic_read(&ulp_ops->ref_count) != 0) && (i < 20)) {
+ msleep(100);
+ i++;
+ }
+
+ if (atomic_read(&ulp_ops->ref_count) != 0)
+ printk(KERN_WARNING PFX "%s: Failed waiting for ref count to go"
+ " to zero.\n", dev->netdev->name);
return 0;
out_unlock:
@@ -1161,19 +1183,23 @@ static void cnic_ulp_init(struct cnic_dev *dev)
int i;
struct cnic_local *cp = dev->cnic_priv;
- rcu_read_lock();
for (i = 0; i < MAX_CNIC_ULP_TYPE_EXT; i++) {
struct cnic_ulp_ops *ulp_ops;
- ulp_ops = rcu_dereference(cnic_ulp_tbl[i]);
- if (!ulp_ops || !ulp_ops->cnic_init)
+ mutex_lock(&cnic_lock);
+ ulp_ops = cnic_ulp_tbl[i];
+ if (!ulp_ops || !ulp_ops->cnic_init) {
+ mutex_unlock(&cnic_lock);
continue;
+ }
+ ulp_get(ulp_ops);
+ mutex_unlock(&cnic_lock);
if (!test_and_set_bit(ULP_F_INIT, &cp->ulp_flags[i]))
ulp_ops->cnic_init(dev);
+ ulp_put(ulp_ops);
}
- rcu_read_unlock();
}
static void cnic_ulp_exit(struct cnic_dev *dev)
@@ -1181,19 +1207,23 @@ static void cnic_ulp_exit(struct cnic_dev *dev)
int i;
struct cnic_local *cp = dev->cnic_priv;
- rcu_read_lock();
for (i = 0; i < MAX_CNIC_ULP_TYPE_EXT; i++) {
struct cnic_ulp_ops *ulp_ops;
- ulp_ops = rcu_dereference(cnic_ulp_tbl[i]);
- if (!ulp_ops || !ulp_ops->cnic_exit)
+ mutex_lock(&cnic_lock);
+ ulp_ops = cnic_ulp_tbl[i];
+ if (!ulp_ops || !ulp_ops->cnic_exit) {
+ mutex_unlock(&cnic_lock);
continue;
+ }
+ ulp_get(ulp_ops);
+ mutex_unlock(&cnic_lock);
if (test_and_clear_bit(ULP_F_INIT, &cp->ulp_flags[i]))
ulp_ops->cnic_exit(dev);
+ ulp_put(ulp_ops);
}
- rcu_read_unlock();
}
static int cnic_cm_offload_pg(struct cnic_sock *csk)
diff --git a/drivers/net/cnic_if.h b/drivers/net/cnic_if.h
index d1bce27..a492357 100644
--- a/drivers/net/cnic_if.h
+++ b/drivers/net/cnic_if.h
@@ -290,6 +290,7 @@ struct cnic_ulp_ops {
void (*iscsi_nl_send_msg)(struct cnic_dev *dev, u32 msg_type,
char *data, u16 data_size);
struct module *owner;
+ atomic_t ref_count;
};
extern int cnic_register_driver(int ulp_type, struct cnic_ulp_ops *ulp_ops);
--
1.5.6.GIT
^ permalink raw reply related
* [PATCH 0/5] cnic: Bug fixes.
From: Michael Chan @ 2009-08-15 1:49 UTC (permalink / raw)
To: davem, James.Bottomley, michaelc; +Cc: netdev, linux-scsi
This patchset fixes a panic on ia64 and some locking issues.
Please review. 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