* Re: [net-next 12/12] ixgbe: update ntuple filter configuration
From: Alexander Duyck @ 2011-01-07 4:12 UTC (permalink / raw)
To: Ben Hutchings
Cc: jeffrey.t.kirsher, davem, Alexander Duyck, netdev, gosp, bphilips
In-Reply-To: <1294362158.11825.78.camel@bwh-desktop>
On Thu, Jan 6, 2011 at 5:02 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Thu, 2011-01-06 at 16:29 -0800, jeffrey.t.kirsher@intel.com wrote:
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> This change fixes several issues found in ntuple filtering while I was
>> doing the ATR refactor.
>>
>> Specifically I updated the masks to work correctly with the latest version
>> of ethtool,
> [...]
>
> Did the previous code not correctly handle a zero value with a non-zero
> mask for some fields? If so, I can revert that change to ethtool.
>
> Ben.
Actually I think the ethtool mention doesn't really apply to the
in-kernel driver. I think I just carried that over from the check-in
for our out of tree driver which hadn't been updated when you added
the code to cleanup the rx ntuple filters. Also for the driver I'm
not too worried about what the status of it was before since there are
blatant errors in bit/byte ordering and mask bit values in the code
that from what I can tell would have significantly diminished the
usability of the filters.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
From: Jesse Gross @ 2011-01-07 4:36 UTC (permalink / raw)
To: Matt Carlson
Cc: Michael Leun, Michael Chan, Eric Dumazet, David Miller,
Ben Greear, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20110107032459.GA17959@mcarlson.broadcom.com>
On Thu, Jan 6, 2011 at 10:24 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
> On Sat, Dec 18, 2010 at 07:38:00PM -0800, Jesse Gross wrote:
>> On Tue, Dec 14, 2010 at 11:16 PM, Michael Leun
>> <lkml20101129@newton.leun.net> wrote:
>> > OK - all tests done on that DL320G5:
>> >
>> > For completeness, 2.6.37-rc5 unpatched:
>> >
>> > eth0, no vlan configured: totally broken - see double tagged vlans
>> > without tag, single or untagged packets missing at all
>>
>> Random behavior? This one is somewhat hard to explain - maybe there
>> are some other factors. eth0 has ASF on, so it always strips tags. I
>> would expect it to behave like the vlan configured case.
>>
>> >
>> > eth0, vlan configured: see packets without vlan tag (see double tagged
>> > packets with one vlan tag)
>>
>> Both ASF and vlan group configured cause tag stripping to be enabled.
>> Missing tag.
>>
>> >
>> > eth1 same as originally reported:
>> > without vlan configured see vlan tags (single and double tagged as
>> > expected)
>>
>> No ASF and no vlan group means tag stripping is disabled. Have tag.
>>
>> > with vlan configured: see packets without vlan tag (see double tagged
>> > packets with one vlan tag)
>>
>> Configuring vlan group causes stripping to be enabled. Missing tag.
>>
>> >
>> >
>> > 2.6.37-rc5, your tg3 use new vlan-code patch:
>> >
>> > eth0, no vlan configured: ?see packets without vlan tag (see double
>> > tagged packets with one vlan tag)
>>
>> ASF enables tag stripping. Missing tag.
>>
>> > eth1, no vlan configured: see vlan tags (single and double tagged as
>> > expected)
>>
>> No ASF, no vlan group means no stripping. Have tag.
>>
>> >
>> >
>> > eth0, vlan configured: as without vlan
>>
>> ASF enables stripping. Missing tag.
>>
>> > eth1, vlan configured: as without vlan
>>
>> With this patch vlan stripping is only enabled when ASF is on, so no
>> stripping. Have tag.
>>
>> >
>> > 2.6.37-rc5, your tg3 use new vlan-code patch with test patch ontop
>> >
>> > eth1 no vlan configured: see packets without vlan tag (see double tagged
>> > packets with one vlan tag)
>>
>> With the second patch, vlan stripping is always enabled. Missing tag.
>>
>> > eth1 with vlan: the same
>>
>> Stripping still always enabled. Missing tag.
>>
>> The bottom line is whenever vlan stripping is enabled we're missing
>> the outer tag. It might be worth adding some debugging in the area
>> before napi_gro_receive/vlan_gro_receive (depending on version). My
>> guess is that (desc->type_flags & RXD_FLAG_VLAN) is false even for
>> vlan packets on this NIC.
>>
>> You said that everything works on the 5752? Matt, is it possible that
>> the 5714 either has a problem with vlan stripping or a different way
>> of reporting it?
>
> I don't think this is a 5714 specific issue. I think the problem is
> rooted in the fact that the VLAN tag stripping is enabled.
It's definitely related to vlan stripping being enabled. Other cards
using tg3 seem to work fine with stripping though, which is why I
thought it might be specific to the 5714.
>
> Your RXD_FLAG_VLAN idea sounds unlikely to me, but it's worth a check.
>
> The patch here is using __vlan_hwaccel_put_tag(), which informs the
> stack a VLAN tag is present. If this is indeed a reporting problem, I'm
> not sure what else the driver should be doing.
The code to hand off the tag to the stack looks OK to me. Michael was
seeing this on older versions of the kernel as well with this NIC,
which predates both this patch and the larger vlan changes so it
doesn't seem like a problem with passing the tag to the network stack.
It's hard to know exactly what is going on though without seeing what
the hardware is reporting.
^ permalink raw reply
* Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
From: Jesse Gross @ 2011-01-07 4:38 UTC (permalink / raw)
To: Matt Carlson
Cc: Eric Dumazet, Michael Leun, Michael Chan, David Miller,
Ben Greear, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20110107034130.GA18028@mcarlson.broadcom.com>
On Thu, Jan 6, 2011 at 10:41 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
> On Thu, Jan 06, 2011 at 07:04:46PM -0800, Eric Dumazet wrote:
>> Le jeudi 06 janvier 2011 ?? 18:59 -0800, Matt Carlson a ??crit :
>> > On Thu, Jan 06, 2011 at 06:43:22PM -0800, Eric Dumazet wrote:
>> > > Le vendredi 07 janvier 2011 ?? 03:41 +0100, Eric Dumazet a ??crit :
>> > > > Le jeudi 06 janvier 2011 ?? 18:29 -0800, Matt Carlson a ??crit :
>> > > >
>> > > > > Hi Eric. Sorry for the delay. I was under the impression that your
>> > > > > problems were software related and that you just needed a revised
>> > > > > version of these VLAN patches I was sending to Michael. Is this not
>> > > > > true?
>> > > > >
>> > > > > Having a hardware stat increment suggests this is a new problem.
>> > > > > Maybe I missed it, but I didn't see what hardware you are working
>> > > > > with and whether or not management firmware was enabled. Could you tell
>> > > > > me that info?
>> > > > >
>> > > >
>> > > > Hi Matt
>> > > >
>> > > > I started a bisection, because I couldnt sleep tonight anyway :(
>> > > >
>> > > > 14:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5715S
>> > > > Gigabit Ethernet (rev a3)
>> > > > Subsystem: Hewlett-Packard Company NC326m PCIe Dual Port Adapter
>> > > > Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 43
>> > > > Memory at fdff0000 (64-bit, non-prefetchable) [size=64K]
>> > > > Memory at fdfe0000 (64-bit, non-prefetchable) [size=64K]
>> > > > [virtual] Expansion ROM at fdbe0000 [disabled] [size=128K]
>> > > > Capabilities: [40] PCI-X non-bridge device
>> > > > Capabilities: [48] Power Management version 2
>> > > > Capabilities: [50] Vital Product Data
>> > > > Capabilities: [58] MSI: Enable+ Count=1/8 Maskable- 64bit+
>> > > > Kernel driver in use: tg3
>> > > > Kernel modules: tg3
>> > > >
>> > > >
>> > >
>> > > $ ethtool -i eth2
>> > > driver: tg3
>> > > version: 3.115
>> > > firmware-version: 5715s-v3.28
>> > > bus-info: 0000:14:04.0
>> > > $ dmesg | grep ASF
>> > > [ 6.220577] tg3 0000:14:04.0: eth2: RXcsums[1] LinkChgREG[0] MIirq[0]
>> > > ASF[0] TSOcap[1]
>> > > [ 6.228586] tg3 0000:14:04.1: eth3: RXcsums[1] LinkChgREG[0] MIirq[0]
>> > > ASF[0] TSOcap[1]
>> >
>> > Thanks. So management firmware is disabled. This should be
>> > straightforward case.
>> >
>> > I'm wondering if I'm misunderstanding something though. You said earlier
>> > that VLAN tagging doesn't work unless you applied my patch. Is this no
>> > longer true?
>> >
>>
>> I dont apply your patch because Jesse said it was not a good patch ;)
>
> Oh.
>
>> Maybe I missed something and it must be applied ? Problem is : current
>> Linus tree now includes net-next-2.6 and vlan doesnt work. You should
>> resubmit it perhaps ?
>
> Yes, something needs to be submitted. I want to make sure we aren't
> chasing the same problem though. If the patch(es) fix your problem,
> then I can concentrate on finalizing the patch.
>
> I can combine my last patch (the one that always enabled VLAN tag
> stripping) and the previous patch (that implements all your comments so
> far) into one patch, but that still leaves the behavior Michael noted
> unaddressed.
Just to clarify, I think there are three separate things going on here:
* The patch, which independent of the separately reported issues, is
good because it moves tg3 to the new vlan model. However, I don't
think we should always disable vlan stripping as is done because it is
probably useful in the majority of cases. Maybe in some situations it
needs to be disabled but those are independent and should affect both
the patched and unpatched versions.
* Eric's issue. It sounds like the commit that bisect turned up has
some interaction with stripping. The patch fixes this because it
always disables stripping but that doesn't seem like the right
solution because previous versions worked with stripping enabled.
* Michael's issue. Not clear what the cause is but disabling
stripping fixes it. It has different symptoms from Eric's though
(missing tags vs missing packets). The patch changes behavior a
little bit because it changes when stripping is enabled but doesn't
fix the underlying cause.
So each needs to be tracked down separately. Unfortunately, the fixed
patch will no longer solve Eric's issue...
^ permalink raw reply
* [PATCH 1/2] sky2: fix limited auto negotiation
From: Stephen Hemminger @ 2011-01-07 4:40 UTC (permalink / raw)
To: Mohsen Hariri, David Miller; +Cc: netdev
In-Reply-To: <AANLkTimGZbDNeRccp4SkgOsJsLXjyKNq+ma4UvW=-5GG@mail.gmail.com>
The sky2 driver would always try all possible supported speeds even
if the user only asked for a limited set of speed/duplex combinations.
Reported-by: Mohsen Hariri <m.hariri@gmail.com>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sky2.c 2011-01-04 08:46:31.796080594 -0800
+++ b/drivers/net/sky2.c 2011-01-06 20:09:25.660684849 -0800
@@ -3411,18 +3411,15 @@ static u32 sky2_supported_modes(const st
u32 modes = SUPPORTED_10baseT_Half
| SUPPORTED_10baseT_Full
| SUPPORTED_100baseT_Half
- | SUPPORTED_100baseT_Full
- | SUPPORTED_Autoneg | SUPPORTED_TP;
+ | SUPPORTED_100baseT_Full;
if (hw->flags & SKY2_HW_GIGABIT)
modes |= SUPPORTED_1000baseT_Half
| SUPPORTED_1000baseT_Full;
return modes;
} else
- return SUPPORTED_1000baseT_Half
- | SUPPORTED_1000baseT_Full
- | SUPPORTED_Autoneg
- | SUPPORTED_FIBRE;
+ return SUPPORTED_1000baseT_Half
+ | SUPPORTED_1000baseT_Full;
}
static int sky2_get_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
@@ -3436,9 +3433,11 @@ static int sky2_get_settings(struct net_
if (sky2_is_copper(hw)) {
ecmd->port = PORT_TP;
ecmd->speed = sky2->speed;
+ ecmd->supported |= SUPPORTED_Autoneg | SUPPORTED_TP;
} else {
ecmd->speed = SPEED_1000;
ecmd->port = PORT_FIBRE;
+ ecmd->supported |= SUPPORTED_Autoneg | SUPPORTED_FIBRE;
}
ecmd->advertising = sky2->advertising;
@@ -3455,8 +3454,19 @@ static int sky2_set_settings(struct net_
u32 supported = sky2_supported_modes(hw);
if (ecmd->autoneg == AUTONEG_ENABLE) {
+ if (ecmd->advertising & ~supported)
+ return -EINVAL;
+
+ if (sky2_is_copper(hw))
+ sky2->advertising = ecmd->advertising |
+ ADVERTISED_TP |
+ ADVERTISED_Autoneg;
+ else
+ sky2->advertising = ecmd->advertising |
+ ADVERTISED_FIBRE |
+ ADVERTISED_Autoneg;
+
sky2->flags |= SKY2_FLAG_AUTO_SPEED;
- ecmd->advertising = supported;
sky2->duplex = -1;
sky2->speed = -1;
} else {
@@ -3500,8 +3510,6 @@ static int sky2_set_settings(struct net_
sky2->flags &= ~SKY2_FLAG_AUTO_SPEED;
}
- sky2->advertising = ecmd->advertising;
-
if (netif_running(dev)) {
sky2_phy_reinit(sky2);
sky2_set_multicast(dev);
^ permalink raw reply
* [PATCH 2/2] sky2: convert to new VLAN model
From: Stephen Hemminger @ 2011-01-07 4:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev
This converts sky2 to new VLAN offload flags control via ethtool.
It also allows for transmit offload of vlan tagged frames which
was not possible before.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/sky2.c 2011-01-06 17:44:00.643524039 -0800
+++ b/drivers/net/sky2.c 2011-01-06 19:05:06.100968234 -0800
@@ -46,10 +46,6 @@
#include <asm/irq.h>
-#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
-#define SKY2_VLAN_TAG_USED 1
-#endif
-
#include "sky2.h"
#define DRV_NAME "sky2"
@@ -1326,40 +1322,33 @@ static int sky2_ioctl(struct net_device
return err;
}
-#ifdef SKY2_VLAN_TAG_USED
-static void sky2_set_vlan_mode(struct sky2_hw *hw, u16 port, bool onoff)
+/* Features available on VLAN with transmit tag stripped */
+#define VLAN_FEAT (NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO)
+
+static void sky2_vlan_mode(struct net_device *dev)
{
- if (onoff) {
+ struct sky2_port *sky2 = netdev_priv(dev);
+ struct sky2_hw *hw = sky2->hw;
+ u16 port = sky2->port;
+
+ if (dev->features & NETIF_F_HW_VLAN_RX)
sky2_write32(hw, SK_REG(port, RX_GMF_CTRL_T),
RX_VLAN_STRIP_ON);
+ else
+ sky2_write32(hw, SK_REG(port, RX_GMF_CTRL_T),
+ RX_VLAN_STRIP_OFF);
+
+ if (dev->features & NETIF_F_HW_VLAN_TX) {
sky2_write32(hw, SK_REG(port, TX_GMF_CTRL_T),
TX_VLAN_TAG_ON);
+ dev->vlan_features = dev->features & VLAN_FEAT;
} else {
- sky2_write32(hw, SK_REG(port, RX_GMF_CTRL_T),
- RX_VLAN_STRIP_OFF);
sky2_write32(hw, SK_REG(port, TX_GMF_CTRL_T),
TX_VLAN_TAG_OFF);
+ dev->vlan_features = dev->features & NETIF_F_HIGHDMA;
}
}
-static void sky2_vlan_rx_register(struct net_device *dev, struct vlan_group *grp)
-{
- struct sky2_port *sky2 = netdev_priv(dev);
- struct sky2_hw *hw = sky2->hw;
- u16 port = sky2->port;
-
- netif_tx_lock_bh(dev);
- napi_disable(&hw->napi);
-
- sky2->vlgrp = grp;
- sky2_set_vlan_mode(hw, port, grp != NULL);
-
- sky2_read32(hw, B0_Y2_SP_LISR);
- napi_enable(&hw->napi);
- netif_tx_unlock_bh(dev);
-}
-#endif
-
/* Amount of required worst case padding in rx buffer */
static inline unsigned sky2_rx_pad(const struct sky2_hw *hw)
{
@@ -1635,9 +1624,7 @@ static void sky2_hw_up(struct sky2_port
sky2_prefetch_init(hw, txqaddr[port], sky2->tx_le_map,
sky2->tx_ring_size - 1);
-#ifdef SKY2_VLAN_TAG_USED
- sky2_set_vlan_mode(hw, port, sky2->vlgrp != NULL);
-#endif
+ sky2_vlan_mode(sky2->netdev);
sky2_rx_start(sky2);
}
@@ -1780,7 +1767,7 @@ static netdev_tx_t sky2_xmit_frame(struc
}
ctrl = 0;
-#ifdef SKY2_VLAN_TAG_USED
+
/* Add VLAN tag, can piggyback on LRGLEN or ADDR64 */
if (vlan_tx_tag_present(skb)) {
if (!le) {
@@ -1792,7 +1779,6 @@ static netdev_tx_t sky2_xmit_frame(struc
le->length = cpu_to_be16(vlan_tx_tag_get(skb));
ctrl |= INS_VLAN;
}
-#endif
/* Handle TCP checksum offload */
if (skb->ip_summed == CHECKSUM_PARTIAL) {
@@ -2432,11 +2418,8 @@ static struct sk_buff *sky2_receive(stru
struct sk_buff *skb = NULL;
u16 count = (status & GMR_FS_LEN) >> 16;
-#ifdef SKY2_VLAN_TAG_USED
- /* Account for vlan tag */
- if (sky2->vlgrp && (status & GMR_FS_VLAN))
- count -= VLAN_HLEN;
-#endif
+ if (status & GMR_FS_VLAN)
+ count -= VLAN_HLEN; /* Account for vlan tag */
netif_printk(sky2, rx_status, KERN_DEBUG, dev,
"rx slot %u status 0x%x len %d\n",
@@ -2504,17 +2487,9 @@ static inline void sky2_tx_done(struct n
static inline void sky2_skb_rx(const struct sky2_port *sky2,
u32 status, struct sk_buff *skb)
{
-#ifdef SKY2_VLAN_TAG_USED
- u16 vlan_tag = be16_to_cpu(sky2->rx_tag);
- if (sky2->vlgrp && (status & GMR_FS_VLAN)) {
- if (skb->ip_summed == CHECKSUM_NONE)
- vlan_hwaccel_receive_skb(skb, sky2->vlgrp, vlan_tag);
- else
- vlan_gro_receive(&sky2->hw->napi, sky2->vlgrp,
- vlan_tag, skb);
- return;
- }
-#endif
+ if (status & GMR_FS_VLAN)
+ __vlan_hwaccel_put_tag(skb, be16_to_cpu(sky2->rx_tag));
+
if (skb->ip_summed == CHECKSUM_NONE)
netif_receive_skb(skb);
else
@@ -2631,7 +2606,6 @@ static int sky2_status_intr(struct sky2_
goto exit_loop;
break;
-#ifdef SKY2_VLAN_TAG_USED
case OP_RXVLAN:
sky2->rx_tag = length;
break;
@@ -2639,7 +2613,6 @@ static int sky2_status_intr(struct sky2_
case OP_RXCHKSVLAN:
sky2->rx_tag = length;
/* fall through */
-#endif
case OP_RXCHKS:
if (likely(sky2->flags & SKY2_FLAG_RX_CHECKSUM))
sky2_rx_checksum(sky2, status);
@@ -3042,6 +3015,10 @@ static int __devinit sky2_init(struct sk
| SKY2_HW_NEW_LE
| SKY2_HW_AUTO_TX_SUM
| SKY2_HW_ADV_POWER_CTL;
+
+ /* The workaround for status conflicts VLAN tag detection. */
+ if (hw->chip_rev == CHIP_REV_YU_FE2_A0)
+ hw->flags |= SKY2_HW_VLAN_BROKEN;
break;
case CHIP_ID_YUKON_SUPR:
@@ -4237,15 +4214,28 @@ static int sky2_set_eeprom(struct net_de
static int sky2_set_flags(struct net_device *dev, u32 data)
{
struct sky2_port *sky2 = netdev_priv(dev);
- u32 supported =
- (sky2->hw->flags & SKY2_HW_RSS_BROKEN) ? 0 : ETH_FLAG_RXHASH;
+ unsigned long old_feat = dev->features;
+ u32 supported = 0;
int rc;
+ if (!(sky2->hw->flags & SKY2_HW_RSS_BROKEN))
+ supported |= ETH_FLAG_RXHASH;
+
+ if (!(sky2->hw->flags & SKY2_HW_VLAN_BROKEN))
+ supported |= ETH_FLAG_RXVLAN | ETH_FLAG_TXVLAN;
+
+ printk(KERN_DEBUG "sky2 set_flags: supported %x data %x\n",
+ supported, data);
+
rc = ethtool_op_set_flags(dev, data, supported);
if (rc)
return rc;
- rx_set_rss(dev);
+ if ((old_feat ^ dev->features) & NETIF_F_RXHASH)
+ rx_set_rss(dev);
+
+ if ((old_feat ^ dev->features) & (NETIF_F_HW_VLAN_RX|NETIF_F_HW_VLAN_TX))
+ sky2_vlan_mode(dev);
return 0;
}
@@ -4281,6 +4271,7 @@ static const struct ethtool_ops sky2_eth
.get_sset_count = sky2_get_sset_count,
.get_ethtool_stats = sky2_get_ethtool_stats,
.set_flags = sky2_set_flags,
+ .get_flags = ethtool_op_get_flags,
};
#ifdef CONFIG_SKY2_DEBUG
@@ -4562,9 +4553,6 @@ static const struct net_device_ops sky2_
.ndo_change_mtu = sky2_change_mtu,
.ndo_tx_timeout = sky2_tx_timeout,
.ndo_get_stats64 = sky2_get_stats,
-#ifdef SKY2_VLAN_TAG_USED
- .ndo_vlan_rx_register = sky2_vlan_rx_register,
-#endif
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = sky2_netpoll,
#endif
@@ -4580,9 +4568,6 @@ static const struct net_device_ops sky2_
.ndo_change_mtu = sky2_change_mtu,
.ndo_tx_timeout = sky2_tx_timeout,
.ndo_get_stats64 = sky2_get_stats,
-#ifdef SKY2_VLAN_TAG_USED
- .ndo_vlan_rx_register = sky2_vlan_rx_register,
-#endif
},
};
@@ -4633,7 +4618,8 @@ static __devinit struct net_device *sky2
sky2->port = port;
dev->features |= NETIF_F_IP_CSUM | NETIF_F_SG
- | NETIF_F_TSO | NETIF_F_GRO;
+ | NETIF_F_TSO | NETIF_F_GRO;
+
if (highmem)
dev->features |= NETIF_F_HIGHDMA;
@@ -4641,13 +4627,8 @@ static __devinit struct net_device *sky2
if (!(hw->flags & SKY2_HW_RSS_BROKEN))
dev->features |= NETIF_F_RXHASH;
-#ifdef SKY2_VLAN_TAG_USED
- /* The workaround for FE+ status conflicts with VLAN tag detection. */
- if (!(sky2->hw->chip_id == CHIP_ID_YUKON_FE_P &&
- sky2->hw->chip_rev == CHIP_REV_YU_FE2_A0)) {
+ if (!(hw->flags & SKY2_HW_VLAN_BROKEN))
dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
- }
-#endif
/* read the mac address */
memcpy_fromio(dev->dev_addr, hw->regs + B2_MAC_1 + port * 8, ETH_ALEN);
--- a/drivers/net/sky2.h 2011-01-06 17:44:01.939546184 -0800
+++ b/drivers/net/sky2.h 2011-01-06 17:59:12.430966390 -0800
@@ -2236,11 +2236,8 @@ struct sky2_port {
u16 rx_pending;
u16 rx_data_size;
u16 rx_nfrags;
-
-#ifdef SKY2_VLAN_TAG_USED
u16 rx_tag;
- struct vlan_group *vlgrp;
-#endif
+
struct {
unsigned long last;
u32 mac_rp;
@@ -2284,6 +2281,7 @@ struct sky2_hw {
#define SKY2_HW_AUTO_TX_SUM 0x00000040 /* new IP decode for Tx */
#define SKY2_HW_ADV_POWER_CTL 0x00000080 /* additional PHY power regs */
#define SKY2_HW_RSS_BROKEN 0x00000100
+#define SKY2_HW_VLAN_BROKEN 0x00000200
u8 chip_id;
u8 chip_rev;
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Stephen Hemminger @ 2011-01-07 4:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1294286850.2723.65.camel@edumazet-laptop>
On Thu, 06 Jan 2011 05:07:30 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 05 janvier 2011 à 11:21 -0800, Stephen Hemminger a écrit :
> > This implements the CHOKe packet scheduler based on the existing
> > Linux RED scheduler based on the algorithm described in the paper.
> >
> > The core idea is:
> > For every packet arrival:
> > Calculate Qave
> > if (Qave < minth)
> > Queue the new packet
> > else
> > Select randomly a packet from the queue
> > if (both packets from same flow)
> > then Drop both the packets
> > else if (Qave > maxth)
> > Drop packet
> > else
> > Admit packet with probability p (same as RED)
> >
> > See also:
> > Rong Pan, Balaji Prabhakar, Konstantinos Psounis, "CHOKe: a stateless active
> > queue management scheme for approximating fair bandwidth allocation",
> > Proceeding of INFOCOM'2000, March 2000.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
>
> To be really useful in a wide range of environments, I believe that :
>
> - CHOKe should be able to use an external flow classifier (like say...
> SFQ) to compute a token and compare two skbs by this token instead of
> custom rxhash or whatever. (rxhash can be the default in absence of flow
> classifier). Probably you need to store the token in skb->cb[] to avoid
> calling tc_classify() several times for a given packet.
>
> http://lwn.net/Articles/236200/
> http://kerneltrap.org/mailarchive/linux-netdev/2008/1/31/667679
Probably should split SFQ flow hash stuff into core code for reuse.
> - Must use a FIFO with O(1) access to Nth skb in queue.
>
> A linked list makes this implementation too expensive for big queues.
>
> For small queues (less than 128 skbs at this moment for SFQ), existing
> schedulers are good enough.
>
> CHOKe authors dont mention this in their paper, but their experiments
> were done in 1999 with 1Mbs links. minth=100 and maxth=200, limit=300
>
> We want to try CHOKe with modern links, probably with minth=2000 and
> maxth=4000 or more.
>
> They said "It is arguably more difficult to drop a randomy chosen packet
> since this means removing from a linked-list. Instead of doing this, we
> propose to add one extra bit to the packet header. The bit is set to one
> if the drop candidate is to be dropped. When a packet advance to the
> head of the FIFO buffer, the status of the bit determines whether it is
> to be immediately discarded or transmitted on the outgoind line"
>
> If they thought removing a buffer from a linked list was expensive
> (!!!), they certainly assumed the previous access to the randomly chosen
> buffer was faster than the skb unlink !
>
> Using a circular buffer should be enough, using a similar trick than
> suggested : when droping an skb from the ring, stick a NULL pointer and
> dont memmove() the window to shrink it.
>
> struct skb_ring {
> unsigned int head;
> unsigned int tail;
> unsigned int size; /* a power of two */
> struct sk_buff **table;
> };
>
> Doing so avoids the cache misses to adjacent skbs prev/next when
> queue/dequeue is done.
The problem is that large tables of pointers in kernel require either
contiguous allocation or some indirect table algorithm.
--
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Changli Gao @ 2011-01-07 5:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <20110106205549.0de56de1@nehalam>
On Fri, Jan 7, 2011 at 12:55 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Thu, 06 Jan 2011 05:07:30 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> Le mercredi 05 janvier 2011 à 11:21 -0800, Stephen Hemminger a écrit :
>> > This implements the CHOKe packet scheduler based on the existing
>> > Linux RED scheduler based on the algorithm described in the paper.
>> >
>> > The core idea is:
>> > For every packet arrival:
>> > Calculate Qave
>> > if (Qave < minth)
>> > Queue the new packet
>> > else
>> > Select randomly a packet from the queue
>> > if (both packets from same flow)
>> > then Drop both the packets
>> > else if (Qave > maxth)
>> > Drop packet
>> > else
>> > Admit packet with probability p (same as RED)
>> >
>> > See also:
>> > Rong Pan, Balaji Prabhakar, Konstantinos Psounis, "CHOKe: a stateless active
>> > queue management scheme for approximating fair bandwidth allocation",
>> > Proceeding of INFOCOM'2000, March 2000.
>> >
>> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>> >
>>
>> To be really useful in a wide range of environments, I believe that :
>>
>> - CHOKe should be able to use an external flow classifier (like say...
>> SFQ) to compute a token and compare two skbs by this token instead of
>> custom rxhash or whatever. (rxhash can be the default in absence of flow
>> classifier). Probably you need to store the token in skb->cb[] to avoid
>> calling tc_classify() several times for a given packet.
>>
>> http://lwn.net/Articles/236200/
>> http://kerneltrap.org/mailarchive/linux-netdev/2008/1/31/667679
>
> Probably should split SFQ flow hash stuff into core code for reuse.
>
>
We need not do that, since we have sch_drr and cls_flow. :)
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: Use ioctl() to list all network interfaces.
From: Chin Shi Hong @ 2011-01-07 5:40 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: netdev
In-Reply-To: <201101061811.06847.remi@remlab.net>
2011/1/7 Rémi Denis-Courmont <remi@remlab.net>:
> Le jeudi 6 janvier 2011 17:33:39 Chin Shi Hong, vous avez écrit :
>> My application's role is to display all network interfaces, including
>> the network interface which are down.
>
> You should use if_nameindex() then.
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
> http://fi.linkedin.com/in/remidenis
>
Thank you. if_nameindex() really help me.
Regards,
^ permalink raw reply
* Re: Use ioctl() to list all network interfaces.
From: Chin Shi Hong @ 2011-01-07 5:41 UTC (permalink / raw)
To: Alexander Clouter; +Cc: netdev
In-Reply-To: <4f9hv7-kev.ln1@chipmunk.wormnet.eu>
On Fri, Jan 7, 2011 at 1:07 AM, Alexander Clouter <alex@digriz.org.uk> wrote:
> Chin Shi Hong <cshong87@gmail.com> wrote:
>>
>> The following codes are just part of my application's source codes:
>>
>> --begin of some codes--
>> ifconf ifc;
>> ret = ioctl(n, SIOCGIFCONF,&ifc);
>> --End of some codes--
>>
>> My application's role is to display all network interfaces, including
>> the network interface which are down.
>>
>> However, with the above codes, my application only display the network
>> interface which are already up. The network interface which are down
>> will not be displayed.
>>
>> So, what can I do to make my application display all network
>> interfaces, including the network interface which are down?
>>
> getifaddrs(), you get the IPv6 ones too this way.
>
> Cheers
>
> --
> Alexander Clouter
> .sigmonster says: I've only got 12 cards.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
getifaddrs() helpful also. Thank you!
Regards,
^ permalink raw reply
* Re: Bad TCP timestamps on non-PC platforms
From: Alex Dubov @ 2011-01-07 6:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David Miller
In-Reply-To: <1294366281.2704.36.camel@edumazet-laptop>
>
>
> You dont give new informations ;)
>
> I asked if you could give information on the other side :
> The bug is to
> drop this legal packet.
>
> uname -a
> sysctl -a | grep tcp
>
One of the other machines:
Linux sunapp 2.6.31.3 #2 SMP Mon Oct 12 21:32:20 EST 2009 x86_64 Dual-Core AMD Opteron(tm) Processor 8220 AuthenticAMD GNU/Linux
error: permission denied on key 'net.ipv4.route.flush'
fs.nfs.nlm_tcpport = 0
fs.nfs.nfs_callback_tcpport = 0
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_max_orphans = 65536
net.ipv4.tcp_max_tw_buckets = 180000
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_fack = 1
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_mem = 3095040 4126720 6190080
net.ipv4.tcp_wmem = 4096 16384 4194304
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_congestion_control = reno
net.ipv4.tcp_abc = 0
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_dma_copybreak = 4096
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_available_congestion_control = reno
net.ipv4.tcp_allowed_congestion_control = reno
net.ipv4.tcp_max_ssthresh = 0
error: permission denied on key 'net.ipv6.route.flush'
sunrpc.transports = tcp 1048576
sunrpc.tcp_slot_table_entries = 16
sunrpc.tcp_fin_timeout = 15
^ permalink raw reply
* Re: [PATCH v3 05/10] net/fec: add dual fec support for mx28
From: Shawn Guo @ 2011-01-07 7:00 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw, w.sang,
s.hauer, netdev, linux-arm-kernel
In-Reply-To: <20110106071047.GW25121@pengutronix.de>
Hi Uwe,
On Thu, Jan 06, 2011 at 08:10:47AM +0100, Uwe Kleine-König wrote:
> Hello Shawn,
>
[...]
> > > > + /*
> > > > + * enet-mac reset will reset mac address registers too,
> > > > + * so need to reconfigure it.
> > > > + */
> > > > + if (fec_is_enetmac) {
> > > > + memcpy(&temp_mac, dev->dev_addr, ETH_ALEN);
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > + writel(cpu_to_be32(temp_mac[0]), fep->hwp + FEC_ADDR_LOW);
> > > > + writel(cpu_to_be32(temp_mac[1]), fep->hwp + FEC_ADDR_HIGH);
> > > where is the value saved to temp_mac[]? For me it looks you write
> > > uninitialized data into the mac registers.
> >
> > memcpy above.
> oops. right. I looked for something like
>
> temp_mac[0] = dev->dev_addr[0] << $shiftfor0 | ...
>
> which AFAIK is what you want here. memcpy is sensible to (at least)
> endian issues. If you ask me factor out the setting of the mac address
> in probe to a function and use that here, too.
>
The memcpy of mac address is being widely used in fec and other
network drivers, and I do not prefer to change something so common
in this patch set.
--
Regards,
Shawn
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Stephen Hemminger @ 2011-01-07 7:10 UTC (permalink / raw)
To: Changli Gao; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <AANLkTi=C6c2md1_MB6dqvVHx2OL0Vj5Lgosi2C=kK9YG@mail.gmail.com>
On Fri, 7 Jan 2011 13:39:26 +0800
Changli Gao <xiaosuo@gmail.com> wrote:
> On Fri, Jan 7, 2011 at 12:55 PM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> > On Thu, 06 Jan 2011 05:07:30 +0100
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> >> Le mercredi 05 janvier 2011 à 11:21 -0800, Stephen Hemminger a écrit :
> >> > This implements the CHOKe packet scheduler based on the existing
> >> > Linux RED scheduler based on the algorithm described in the paper.
> >> >
> >> > The core idea is:
> >> > For every packet arrival:
> >> > Calculate Qave
> >> > if (Qave < minth)
> >> > Queue the new packet
> >> > else
> >> > Select randomly a packet from the queue
> >> > if (both packets from same flow)
> >> > then Drop both the packets
> >> > else if (Qave > maxth)
> >> > Drop packet
> >> > else
> >> > Admit packet with probability p (same as RED)
> >> >
> >> > See also:
> >> > Rong Pan, Balaji Prabhakar, Konstantinos Psounis, "CHOKe: a stateless active
> >> > queue management scheme for approximating fair bandwidth allocation",
> >> > Proceeding of INFOCOM'2000, March 2000.
> >> >
> >> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >> >
> >>
> >> To be really useful in a wide range of environments, I believe that :
> >>
> >> - CHOKe should be able to use an external flow classifier (like say...
> >> SFQ) to compute a token and compare two skbs by this token instead of
> >> custom rxhash or whatever. (rxhash can be the default in absence of flow
> >> classifier). Probably you need to store the token in skb->cb[] to avoid
> >> calling tc_classify() several times for a given packet.
> >>
> >> http://lwn.net/Articles/236200/
> >> http://kerneltrap.org/mailarchive/linux-netdev/2008/1/31/667679
> >
> > Probably should split SFQ flow hash stuff into core code for reuse.
> >
> >
>
> We need not do that, since we have sch_drr and cls_flow. :)
I prefer that the qdisc be useable without any explicit flow classification.
I.e like SFQ it should fall back to a sensible flow matching. DRR and others
put everything in one flow, if no filters are used.
^ permalink raw reply
* [PATCH] sh: sh_eth: Add support ethtool
From: Nobuhiro Iwamatsu @ 2011-01-07 7:25 UTC (permalink / raw)
To: netdev; +Cc: linux-sh, Nobuhiro Iwamatsu, Yoshihiro Shimoda
This commit supports following functions.
- get_drvinfo
- get_settings
- set_settings
- nway_reset
- get_msglevel
- set_msglevel
- get_link
- get_strings
- get_ethtool_stats
- get_sset_count
About other function, the device does not support.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
drivers/net/sh_eth.c | 190 ++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 176 insertions(+), 14 deletions(-)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index 819c175..10493e8 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -32,6 +32,7 @@
#include <linux/io.h>
#include <linux/pm_runtime.h>
#include <linux/slab.h>
+#include <linux/ethtool.h>
#include <asm/cacheflush.h>
#include "sh_eth.h"
@@ -573,7 +574,7 @@ static int sh_eth_ring_init(struct net_device *ndev)
}
/* Allocate all Rx descriptors. */
- rx_ringsize = sizeof(struct sh_eth_rxdesc) * RX_RING_SIZE;
+ rx_ringsize = sizeof(struct sh_eth_rxdesc) *RX_RING_SIZE;
mdp->rx_ring = dma_alloc_coherent(NULL, rx_ringsize, &mdp->rx_desc_dma,
GFP_KERNEL);
@@ -587,7 +588,7 @@ static int sh_eth_ring_init(struct net_device *ndev)
mdp->dirty_rx = 0;
/* Allocate all Tx descriptors. */
- tx_ringsize = sizeof(struct sh_eth_txdesc) * TX_RING_SIZE;
+ tx_ringsize = sizeof(struct sh_eth_txdesc) *TX_RING_SIZE;
mdp->tx_ring = dma_alloc_coherent(NULL, tx_ringsize, &mdp->tx_desc_dma,
GFP_KERNEL);
if (!mdp->tx_ring) {
@@ -817,6 +818,19 @@ static int sh_eth_rx(struct net_device *ndev)
return 0;
}
+static void sh_eth_linkdown(u32 ioaddr)
+{
+ /* Link Down : disable tx and rx */
+ ctrl_outl(ctrl_inl(ioaddr + ECMR) &
+ ~(ECMR_RE | ECMR_TE), ioaddr + ECMR);
+}
+
+static void sh_eth_linkup(u32 ioaddr)
+{
+ ctrl_outl(ctrl_inl(ioaddr + ECMR) |
+ (ECMR_RE | ECMR_TE), ioaddr + ECMR);
+}
+
/* error control function */
static void sh_eth_error(struct net_device *ndev, int intr_status)
{
@@ -843,11 +857,9 @@ static void sh_eth_error(struct net_device *ndev, int intr_status)
if (mdp->ether_link_active_low)
link_stat = ~link_stat;
}
- if (!(link_stat & PHY_ST_LINK)) {
- /* Link Down : disable tx and rx */
- writel(readl(ioaddr + ECMR) &
- ~(ECMR_RE | ECMR_TE), ioaddr + ECMR);
- } else {
+ if (!(link_stat & PHY_ST_LINK))
+ sh_eth_linkdown(ioaddr);
+ else {
/* Link Up */
writel(readl(ioaddr + EESIPR) &
~DMAC_M_ECI, ioaddr + EESIPR);
@@ -857,8 +869,7 @@ static void sh_eth_error(struct net_device *ndev, int intr_status)
writel(readl(ioaddr + EESIPR) |
DMAC_M_ECI, ioaddr + EESIPR);
/* enable tx and rx */
- writel(readl(ioaddr + ECMR) |
- (ECMR_RE | ECMR_TE), ioaddr + ECMR);
+ sh_eth_linkup(ioaddr);
}
}
}
@@ -1063,6 +1074,154 @@ static int sh_eth_phy_start(struct net_device *ndev)
return 0;
}
+static void sh_eth_get_drvinfo(struct net_device *ndev,
+ struct ethtool_drvinfo *info)
+{
+ strncpy(info->driver, "sh_eth", sizeof(info->driver) - 1);
+ strcpy(info->version, "N/A");
+ strcpy(info->fw_version, "N/A");
+ strlcpy(info->bus_info, dev_name(ndev->dev.parent),
+ sizeof(info->bus_info));
+}
+
+static int sh_eth_get_settings(struct net_device *ndev,
+ struct ethtool_cmd *ecmd)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(&mdp->lock, flags);
+ ret = phy_ethtool_gset(mdp->phydev, ecmd);
+ spin_unlock_irqrestore(&mdp->lock, flags);
+
+ return ret;
+}
+
+static int sh_eth_set_settings(struct net_device *ndev,
+ struct ethtool_cmd *ecmd)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ unsigned long flags;
+ int ret;
+ u32 ioaddr = ndev->base_addr;
+
+ spin_lock_irqsave(&mdp->lock, flags);
+
+ /* disable tx and rx */
+ sh_eth_linkdown(ioaddr);
+
+ ret = phy_ethtool_sset(mdp->phydev, ecmd);
+ if (ret)
+ goto error_exit;
+
+ if (ecmd->duplex == DUPLEX_FULL)
+ mdp->duplex = 1;
+ else
+ mdp->duplex = 0;
+
+ if (mdp->cd->set_duplex)
+ mdp->cd->set_duplex(ndev);
+
+error_exit:
+ mdelay(100);
+
+ /* enable tx and rx */
+ sh_eth_linkup(ioaddr);
+
+ spin_unlock_irqrestore(&mdp->lock, flags);
+
+ return ret;
+}
+
+static int sh_eth_nway_reset(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(&mdp->lock, flags);
+ ret = phy_start_aneg(mdp->phydev);
+ spin_unlock_irqrestore(&mdp->lock, flags);
+
+ return ret;
+}
+
+static u32 sh_eth_get_msglevel(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ return mdp->msg_enable;
+}
+
+static void sh_eth_set_msglevel(struct net_device *ndev, u32 value)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ mdp->msg_enable = value;
+}
+
+static const char sh_eth_gstrings_stats[][ETH_GSTRING_LEN] = {
+ "rx_packets", "tx_packets", "rx_bytes", "tx_bytes", "rx_errors",
+ "tx_errors", "rx_dropped", "tx_dropped", "multicast", "collisions",
+ "rx_length_errors", "rx_over_errors", "rx_crc_errors",
+ "rx_frame_errors", "rx_fifo_errors", "rx_missed_errors",
+ "tx_aborted_errors", "tx_carrier_errors", "tx_fifo_errors",
+ "tx_heartbeat_errors", "tx_window_errors",
+ /* device-specific stats */
+ "rx_current", "tx_current",
+ "rx_dirty", "tx_dirty",
+};
+#define SH_ETH_NET_STATS_LEN 21
+#define SH_ETH_STATS_LEN ARRAY_SIZE(sh_eth_gstrings_stats)
+
+static int sh_eth_get_sset_count(struct net_device *netdev, int sset)
+{
+ switch (sset) {
+ case ETH_SS_STATS:
+ return SH_ETH_STATS_LEN;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static void sh_eth_get_ethtool_stats(struct net_device *ndev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ int i;
+
+ for (i = 0; i < SH_ETH_NET_STATS_LEN; i++)
+ data[i] = ((unsigned long *)&ndev->stats)[i];
+
+ /* device-specific stats */
+ data[i++] = mdp->cur_rx;
+ data[i++] = mdp->cur_tx;
+ data[i++] = mdp->dirty_rx;
+ data[i++] = mdp->dirty_tx;
+}
+
+static void sh_eth_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
+{
+ switch (stringset) {
+ case ETH_SS_STATS:
+ memcpy(data, *sh_eth_gstrings_stats,
+ sizeof(sh_eth_gstrings_stats));
+ break;
+ }
+}
+
+static struct ethtool_ops sh_eth_ethtool_ops = {
+ .get_drvinfo = sh_eth_get_drvinfo,
+ .get_settings = sh_eth_get_settings,
+ .set_settings = sh_eth_set_settings,
+ .nway_reset = sh_eth_nway_reset,
+ .get_msglevel = sh_eth_get_msglevel,
+ .set_msglevel = sh_eth_set_msglevel,
+ .get_link = ethtool_op_get_link,
+ .get_strings = sh_eth_get_strings,
+ .get_ethtool_stats = sh_eth_get_ethtool_stats,
+ .get_sset_count = sh_eth_get_sset_count,
+};
+
/* network device open function */
static int sh_eth_open(struct net_device *ndev)
{
@@ -1073,8 +1232,8 @@ static int sh_eth_open(struct net_device *ndev)
ret = request_irq(ndev->irq, sh_eth_interrupt,
#if defined(CONFIG_CPU_SUBTYPE_SH7763) || \
- defined(CONFIG_CPU_SUBTYPE_SH7764) || \
- defined(CONFIG_CPU_SUBTYPE_SH7757)
+ defined(CONFIG_CPU_SUBTYPE_SH7764) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7757)
IRQF_SHARED,
#else
0,
@@ -1232,11 +1391,11 @@ static int sh_eth_close(struct net_device *ndev)
sh_eth_ring_free(ndev);
/* free DMA buffer */
- ringsize = sizeof(struct sh_eth_rxdesc) * RX_RING_SIZE;
+ ringsize = sizeof(struct sh_eth_rxdesc) *RX_RING_SIZE;
dma_free_coherent(NULL, ringsize, mdp->rx_ring, mdp->rx_desc_dma);
/* free DMA buffer */
- ringsize = sizeof(struct sh_eth_txdesc) * TX_RING_SIZE;
+ ringsize = sizeof(struct sh_eth_txdesc) *TX_RING_SIZE;
dma_free_coherent(NULL, ringsize, mdp->tx_ring, mdp->tx_desc_dma);
pm_runtime_put_sync(&mdp->pdev->dev);
@@ -1497,8 +1656,11 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
/* set function */
ndev->netdev_ops = &sh_eth_netdev_ops;
+ SET_ETHTOOL_OPS(ndev, &sh_eth_ethtool_ops);
ndev->watchdog_timeo = TX_TIMEOUT;
+ /* debug message level */
+ mdp->msg_enable = (1 << 3) - 1;
mdp->post_rx = POST_RX >> (devno << 1);
mdp->post_fw = POST_FW >> (devno << 1);
@@ -1572,7 +1734,7 @@ static int sh_eth_runtime_nop(struct device *dev)
return 0;
}
-static struct dev_pm_ops sh_eth_dev_pm_ops = {
+static const struct dev_pm_ops sh_eth_dev_pm_ops = {
.runtime_suspend = sh_eth_runtime_nop,
.runtime_resume = sh_eth_runtime_nop,
};
--
1.7.2.3
^ permalink raw reply related
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Eric Dumazet @ 2011-01-07 8:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110106205549.0de56de1@nehalam>
Le jeudi 06 janvier 2011 à 20:55 -0800, Stephen Hemminger a écrit :
> The problem is that large tables of pointers in kernel require either
> contiguous allocation or some indirect table algorithm.
>
By large table, how many slots do you envision ?
1024 ?
8192 ?
65536 ?
Even insane value like 65536 is OK most of the time.
if kmalloc(GFP_KERNEL) fails, try vmalloc().
We are in process context and are allowed to sleep when qdisc is
created.
Anyway, accessing a random skb in a list of 65536 skbs is just crazy.
^ permalink raw reply
* Re: 2.6.37 vlans on bnx2 not functional, panic with tcpdump
From: selsinork @ 2011-01-07 9:03 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1294361206.21580.7.camel@HP1>
On Fri, Jan 7, 2011 at 12:46 AM, Michael Chan <mchan@broadcom.com> wrote:
> May be you have management firmware running on your devices that can
> change the behavior. Can you provide ethtool -i eth0 on both bnx2
> devices on your system?
This particular system has four onboard ports, a two port add-in card
and a single port fiber card all using bnx2, so I have some options to
try different devices if there's something different about them.
Details of all of them below.
Booting the same system back to 2.6.36 with the patch I mentioned
previously leaves me with a functioning network, so given it could be
management firmware related, why does it work on .36 but not .37 ?
The install is very stripped down, there's no udev or /sbin/hotplug
loading firmware behind my back as neither are installed. So firmware
is whatever comes with the kernel. Just having had a look, I see the
firmware provided with the kernel has changed in .37, but the output
of ethtool -i shows the same firmware being used with .36 and .37
Iain
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6
controllers (rev 01)
07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
07:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
0a:00.0 PCI bridge: Broadcom EPB PCI-Express to PCI-X Bridge (rev c3)
0b:00.0 Ethernet controller: Broadcom Corporation NetXtreme II
BCM5708S Gigabit Ethernet (rev 12)
from 2.6.37:
root@64bit:~# ethtool -i eth0
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2 NCSI 2.0.6
bus-info: 0000:02:00.0
root@64bit:~# ethtool -i eth1
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2 NCSI 2.0.6
bus-info: 0000:02:00.1
root@64bit:~# ethtool -i eth2
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:03:00.0
root@64bit:~# ethtool -i eth3
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:03:00.1
root@64bit:~# ethtool -i eth4
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:07:00.0
root@64bit:~# ethtool -i eth5
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:07:00.1
root@64bit:~# ethtool -i eth6
driver: bnx2
version: 2.0.17
firmware-version: bc 1.9.6
bus-info: 0000:0b:00.0
from 2.6.36:
ethtool -i eth1
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2 NCSI 2.0.6
bus-info: 0000:02:00.1
^ permalink raw reply
* Re: rndis gadget: Inconsistent locking
From: Neil Jones @ 2011-01-07 9:30 UTC (permalink / raw)
To: David Brownell
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1293407341.2255.1038.camel@helium>
>Has this shown up with other USB device controller drivers, or just the
>DWC (DesignWare)? UDC driver?
Yes Michal Nazarewicz has seen this on a S3C UDC, heres his stack trace:
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x44/0xc0()
[...]
[<c0049024>] (local_bh_enable_ip+0x44/0xc0) from [<c025ef18>]
(dev_txq_stats_fold+0xac/0x108)
[<c025ef18>] (dev_txq_stats_fold+0xac/0x108) from [<c025f018>]
(dev_get_stats+0xa4/0xac)
[<c025f018>] (dev_get_stats+0xa4/0xac) from [<c01f72bc>]
(gen_ndis_query_resp+0x4c/0x43c)
[<c01f72bc>] (gen_ndis_query_resp+0x4c/0x43c) from [<c01f784c>]
(rndis_msg_parser+0x1a0/0x32c)
[<c01f784c>] (rndis_msg_parser+0x1a0/0x32c) from [<c01f79f8>]
(rndis_command_complete+0x20/0x4c)
[<c01f79f8>] (rndis_command_complete+0x20/0x4c) from [<c01f3278>]
(done+0x5c/0x70)
[<c01f3278>] (done+0x5c/0x70) from [<c01f3c60>] (complete_tx+0xf0/0x1a8)
[<c01f3c60>] (complete_tx+0xf0/0x1a8) from [<c01f3d8c>]
(process_ep_in_intr+0x74/0x14c)
[<c01f3d8c>] (process_ep_in_intr+0x74/0x14c) from [<c01f470c>]
(s3c_udc_irq+0x2c8/0x3f4)
[<c01f470c>] (s3c_udc_irq+0x2c8/0x3f4) from [<c006dfd0>]
(handle_IRQ_event+0x24/0xe4)
[<c006dfd0>] (handle_IRQ_event+0x24/0xe4) from [<c006fe40>]
(handle_level_irq+0xb0/0x12c)
[<c006fe40>] (handle_level_irq+0xb0/0x12c) from [<c0027074>]
(asm_do_IRQ+0x74/0x98)
[<c0027074>] (asm_do_IRQ+0x74/0x98) from [<c0027ca4>] (__irq_usr+0x44/0xc0)
(taken from Michal's original patch here:
<https://patchwork.kernel.org/patch/195562/>)
Neil
On Sun, Dec 26, 2010 at 11:49 PM, David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> wrote:
> On Wed, 2010-12-08 at 15:11 +0000, Neil Jones wrote:
>>
>> Im getting another lockdep warning when using the RNDIS gadget:
>
>
>
> Probably this is either
>
>
> (a) a recent regression, maybe caused by a change ISTR in the network
> layer stats handling ... which broke another USB + NET driver in much
> the same way, wish I remembered details of which driver, the fix
> there was simple and maybe a good model for fixing this one.
>
> or (b) ... maybe a
> DWC-specific USB device controller driver oddity. (Seemed less likely
> to me when I glanced at the stackdumps below.
>
> Has this shown up with other USB device controller drivers, or just the
> DWC (DesignWare)? UDC driver?
>
> I'll say I'm not keen on adding a thread to the driver. It's worked
> fine without one for many years, even running lockdep. Whatever change
> (network stack or using DWC) caused the locking issue can be fixed
> without a new thread.
>
> - Dave
>
>
>
> The first thing I noticed was that very little of the dumped stack
> context was part of the RNDIS gadget ... often a sign that the issue
> is in the call down to the code dumping its stack (or its context).
>
> (Or if my recollection is right ... that there was an incompatible
> change in a network statistics call, and whoever changed that didn't
> update all affected callers. (ergo breakage here and in another driver.
>>
>> WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
>> Modules linked in: g_ether
>>
>> Call trace:
>> [<40003bf8>] _show_stack+0x68/0x7c
>> [<40003c20>] _dump_stack+0x14/0x28
>> [<40013c3c>] _warn_slowpath_common+0x5c/0x7c
>> [<40013c74>] _warn_slowpath_null+0x18/0x2c
>> [<4001b17c>] ___local_bh_disable+0xc0/0xd0
>> [<4001b1a0>] _local_bh_disable+0x14/0x28
>> [<402e57f8>] __raw_spin_lock_bh+0x18/0x54
>> [<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
>> [<402580c4>] _dev_get_stats+0xb8/0xc0
>> [<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
>> [<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
>> [<401d66fc>] _dwc_otg_request_done+0xd8/0x220
>> [<401d928c>] _ep0_complete_request+0x3f4/0x578
>> [<401d95bc>] _handle_ep0+0x1ac/0x146c
>> [<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
>> [<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
>> [<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
>> [<40054cf4>] _handle_IRQ_event+0x4c/0x184
>> [<40057b4c>] _handle_level_irq+0xac/0x15c
>> [<4000b204>] _metag_soc_irq_demux+0xac/0xb4
>> [<40002dd4>] _do_IRQ+0x4c/0x78
>> [<40004000>] _trigger_handler+0x38/0xac
>> [<40000b18>] ___TBIBoingVec+0xc/0x10
>> [<40003588>] _cpu_idle+0x54/0x78
>>
>> no locks held by swapper/0.
>> ---[ end trace 77ac3cfee0ae5b25 ]---
>>
>> It looks like we are calling spin_lock_bh in the completion function
>> which is running in hard_irq, I think the driver should defer handling
>> this msg (and maybe all requests) to a workqueue?
>>
>> Cheers
>>
>> Neil
>>
>>
>>
>> On Wed, Dec 8, 2010 at 3:03 PM, Neil Jones <neiljay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Hi,
>> >
>> > Im getting another lockdep warning when using the RNDIS gadget:
>> >
>> > WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
>> > Modules linked in: g_ether
>> >
>> > Call trace:
>> > [<40003bf8>] _show_stack+0x68/0x7c
>> > [<40003c20>] _dump_stack+0x14/0x28
>> > [<40013c3c>] _warn_slowpath_common+0x5c/0x7c
>> > [<40013c74>] _warn_slowpath_null+0x18/0x2c
>> > [<4001b17c>] ___local_bh_disable+0xc0/0xd0
>> > [<4001b1a0>] _local_bh_disable+0x14/0x28
>> > [<402e57f8>] __raw_spin_lock_bh+0x18/0x54
>> > [<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
>> > [<402580c4>] _dev_get_stats+0xb8/0xc0
>> > [<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
>> > [<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
>> > [<401d66fc>] _dwc_otg_request_done+0xd8/0x220
>> > [<401d928c>] _ep0_complete_request+0x3f4/0x578
>> > [<401d95bc>] _handle_ep0+0x1ac/0x146c
>> > [<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
>> > [<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
>> > [<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
>> > [<40054cf4>] _handle_IRQ_event+0x4c/0x184
>> > [<40057b4c>] _handle_level_irq+0xac/0x15c
>> > [<4000b204>] _metag_soc_irq_demux+0xac/0xb4
>> > [<40002dd4>] _do_IRQ+0x4c/0x78
>> > [<40004000>] _trigger_handler+0x38/0xac
>> > [<40000b18>] ___TBIBoingVec+0xc/0x10
>> > [<40003588>] _cpu_idle+0x54/0x78
>> >
>> > no locks held by swapper/0.
>> > ---[ end trace 77ac3cfee0ae5b25 ]---
>> >
>> > It
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: genetlink misinterprets NEW as GET
From: Jan Engelhardt @ 2011-01-07 9:38 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Ben Pfaff, Netfilter Developer Mailing List,
Linux Networking Developer Mailing List
In-Reply-To: <4D266CE5.4000309@netfilter.org>
On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote:
>>>> /* Modifiers to GET request */
>>>> #define NLM_F_ROOT 0x100
>>>> #define NLM_F_MATCH 0x200
>>>> #define NLM_F_ATOMIC 0x400
>>>> #define NLM_F_DUMP (NLM_F_ROOT|NLM_F_MATCH)
>> [...]
>>>> [N.B.: I am also wondering whether
>>>> (nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
>>>> may have been desired, because NLM_F_DUMP is composed of two bits.]
>>>
>>> Someone may include NLM_F_ATOMIC to a dump operation, in that case the
>>> checking that you propose is not valid.
>>
>> Are you saying that NLM_F_MATCH and NLM_F_ATOMIC are mutually
>> exclusive, and that NLM_F_ROOT|NLM_F_ATOMIC would also signal a
>> dump operation? Otherwise the test that Jan proposes looks valid
>> to me.
>
>Indeed, Jan's test is fine to fix this. Please, send a patch to Davem asap.
But that would still mean that a user sending a
NLM_F_REQUEST|NLM_F_REPLACE|NLM_F_EXCL message would be misinterpreted
as NLM_F_DUMP.
There just is no way for genl to figure out from an arbitrary nlmsghdr
whether it's a dump request or something else without breaking
something.
The overlapping of NLM_F_ is quite unfortunate.
^ permalink raw reply
* [PATCH] net/r8169: Update the function of parsing firmware
From: Hayes Wang @ 2011-01-07 9:45 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
Update rtl_phy_write_fw function. The new function could
parse the complex firmware which is used by RTL8111E and later.
The new firmware may read data and do some operations, not just
do writing only.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 112 ++++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 97 insertions(+), 15 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 27a7c20..2115424 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1632,39 +1632,121 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
{
__le32 *phytable = (__le32 *)fw->data;
struct net_device *dev = tp->dev;
- size_t i;
+ size_t index;
+ u32 predata, count;
if (fw->size % sizeof(*phytable)) {
- netif_err(tp, probe, dev, "odd sized firmware %zd\n", fw->size);
+ netif_err(tp, probe, dev, "odd sized firmware %zd\n",
+ fw->size);
return;
}
- for (i = 0; i < fw->size / sizeof(*phytable); i++) {
- u32 action = le32_to_cpu(phytable[i]);
+ for (index = 0; index < fw->size / sizeof(*phytable); index++) {
+ u32 action = le32_to_cpu(phytable[index]);
- if (!action)
+ switch(action & 0xF0000000) {
+ case PHY_READ:
+ case PHY_DATA_OR:
+ case PHY_DATA_AND:
+ case PHY_BJMPN:
+ case PHY_READ_EFUSE:
+ case PHY_CLEAR_READCOUNT:
+ case PHY_WRITE:
+ case PHY_READCOUNT_EQ_SKIP:
+ case PHY_COMP_EQ_SKIPN:
+ case PHY_COMP_NEQ_SKIPN:
+ case PHY_WRITE_PREVIOUS:
+ case PHY_SKIPN:
+ case PHY_DELAY_MS:
break;
- if ((action & 0xf0000000) != PHY_WRITE) {
- netif_err(tp, probe, dev,
- "unknown action 0x%08x\n", action);
+ case PHY_READ_MAC_BYTE:
+ case PHY_WRITE_MAC_BYTE:
+ case PHY_WRITE_ERI_WORD:
+ default:
+ netif_err(tp, probe, tp->dev,
+ "Invalid action 0x%08x\n", action);
return;
}
}
- while (i-- != 0) {
- u32 action = le32_to_cpu(*phytable);
- u32 data = action & 0x0000ffff;
- u32 reg = (action & 0x0fff0000) >> 16;
+ predata = 0;
+ count = 0;
+
+ for (index = 0; index < fw->size / sizeof(*phytable); ) {
+ u32 action = le32_to_cpu(phytable[index]);
+ u32 data = action & 0x0000FFFF;
+ u32 regno = (action & 0x0FFF0000) >> 16;
+
+ if (!action)
+ break;
- switch(action & 0xf0000000) {
+ switch(action & 0xF0000000) {
+ case PHY_READ:
+ predata = rtl_readphy(tp, regno);
+ count++;
+ index++;
+ break;
+ case PHY_DATA_OR:
+ predata |= data;
+ index++;
+ break;
+ case PHY_DATA_AND:
+ predata &= data;
+ index++;
+ break;
+ case PHY_BJMPN:
+ index -= regno;
+ break;
+ case PHY_READ_EFUSE:
+ predata = rtl8168d_efuse_read(tp->mmio_addr, regno);
+ index++;
+ break;
+ case PHY_CLEAR_READCOUNT:
+ count = 0;
+ index++;
+ break;
case PHY_WRITE:
- rtl_writephy(tp, reg, data);
- phytable++;
+ rtl_writephy(tp, regno, data);
+ index++;
+ break;
+ case PHY_READCOUNT_EQ_SKIP:
+ if (count == data)
+ index += 2;
+ else
+ index += 1;
+ break;
+ case PHY_COMP_EQ_SKIPN:
+ if (predata == data)
+ index += regno;
+ index++;
+ break;
+ case PHY_COMP_NEQ_SKIPN:
+ if (predata != data)
+ index += regno;
+ index++;
+ break;
+ case PHY_WRITE_PREVIOUS:
+ rtl_writephy(tp, regno, predata);
+ index++;
break;
+ case PHY_SKIPN:
+ index += regno + 1;
+ break;
+ case PHY_DELAY_MS:
+ mdelay(data);
+ index++;
+ break;
+
+ case PHY_READ_MAC_BYTE:
+ case PHY_WRITE_MAC_BYTE:
+ case PHY_WRITE_ERI_WORD:
default:
BUG();
}
+
+ if (index < 0)
+ BUG();
}
}
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH v3 05/10] net/fec: add dual fec support for mx28
From: Uwe Kleine-König @ 2011-01-07 9:44 UTC (permalink / raw)
To: Shawn Guo
Cc: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw, w.sang,
s.hauer, netdev, linux-arm-kernel
In-Reply-To: <20110107070056.GA28358@freescale.com>
Hello,
On Fri, Jan 07, 2011 at 03:00:57PM +0800, Shawn Guo wrote:
> On Thu, Jan 06, 2011 at 08:10:47AM +0100, Uwe Kleine-König wrote:
> > Hello Shawn,
> >
> [...]
> > > > > + /*
> > > > > + * enet-mac reset will reset mac address registers too,
> > > > > + * so need to reconfigure it.
> > > > > + */
> > > > > + if (fec_is_enetmac) {
> > > > > + memcpy(&temp_mac, dev->dev_addr, ETH_ALEN);
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > + writel(cpu_to_be32(temp_mac[0]), fep->hwp + FEC_ADDR_LOW);
> > > > > + writel(cpu_to_be32(temp_mac[1]), fep->hwp + FEC_ADDR_HIGH);
> > > > where is the value saved to temp_mac[]? For me it looks you write
> > > > uninitialized data into the mac registers.
> > >
> > > memcpy above.
> > oops. right. I looked for something like
> >
> > temp_mac[0] = dev->dev_addr[0] << $shiftfor0 | ...
> >
> > which AFAIK is what you want here. memcpy is sensible to (at least)
> > endian issues. If you ask me factor out the setting of the mac address
> > in probe to a function and use that here, too.
> >
> The memcpy of mac address is being widely used in fec and other
> network drivers, and I do not prefer to change something so common
> in this patch set.
Hmm, fec_get_mac uses memcpy as does fec_set_mac_address.
fec_enet_init uses mask and shift. When writing my comment I only saw
the latter. Having that uniform and only in two places (one for setting
and for reading) would be great.
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: About disabling congestion control
From: Syed Obaid Amin @ 2011-01-07 10:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110106173758.37bfef4d@nehalam>
Thanks for the reply. Yes I also thought to create a sort of NULL
congestion control type that does nothing. But this way the changes
would be system wide. BTW, would some one share the insight that why
linux uses sysctl to select a congestion control algorithm instead of
socket options.
Thanks again,
Obaid
On Thu, Jan 6, 2011 at 8:37 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Thu, 6 Jan 2011 20:25:18 -0500
> Syed Obaid Amin <obaidasyed@gmail.com> wrote:
>
>> Hey all,
>>
>> I am currently working on a socket option to disable the tcp
>> congestion control. I think the simplest approach to do this is to
>> ignore cwnd before sending out a packet.
>>
>> After going through tcp output engine it seems that tcp_cwnd_test is
>> the method that decides that how many segments can be sent out on a
>> wire. For testing it out, I changed this method so that if no-cc
>> option is ON, just return a big constant value. But, it didn't work
>> and I am unable to see a burst of pkts. It looks like that I am
>> missing something here.
>>
>> Any suggestions that what is the right place to look for disabling the
>> congestion control ?
>>
>> Thanks much!
>>
>> Obaid
>
> I assume this is just a local hack experiment; not something you
> want to actually submit for other users to use...
>
> The easiest/safest way to do this would be to build/define a new TCP congestion
> control type that does nothing.
>
>
^ permalink raw reply
* Re: About disabling congestion control
From: Eric Dumazet @ 2011-01-07 10:33 UTC (permalink / raw)
To: Syed Obaid Amin; +Cc: Stephen Hemminger, netdev, Michael Kerrisk
In-Reply-To: <AANLkTi=FLGM1z0VLH+WZXvF=7TZHtMhxLe+KRF3ojWR1@mail.gmail.com>
Le vendredi 07 janvier 2011 à 05:04 -0500, Syed Obaid Amin a écrit :
> Thanks for the reply. Yes I also thought to create a sort of NULL
> congestion control type that does nothing. But this way the changes
> would be system wide. BTW, would some one share the insight that why
> linux uses sysctl to select a congestion control algorithm instead of
> socket options.
Hmm, maybe "man 7 tcp" is not up2date.
It mentions TCP_CONGESTION once but doesnt describe it.
CC Michael Kerrisk <mtk.manpages@gmail.com> ;)
http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html
Lets say you have a kernel with support for two congestion controls :
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
cubic reno
# cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
Therefore, default is cubic, but you can change to reno if you want.
setsockopt(sock, SOL_TCP, TCP_CONGESTION, "reno", strlen("reno"));
^ permalink raw reply
* Re: possible issue between bridge igmp/multicast handling & bnx2x on kernel 2.6.34 and >
From: Yann Dupont @ 2011-01-07 10:40 UTC (permalink / raw)
To: netdev
In-Reply-To: <4D23234E.30709@univ-nantes.fr>
Le 04/01/2011 14:40, Yann Dupont a écrit :
...
> We just added BCM57711 10G cards (bnx2x driver) on our blade servers
> (connected to 10G Power Connect M8024).
> Since then, we are experiencing random lost of packets.
>
> Symptom : packets are lost on some vlans for a few seconds, then
> things go back to normal (and stops again a few minutes later)
>
As I didn't had answer so far , I digged a little more and captured more
packets.
I just noticed that an event trigger that problem : IPv6 neighbor
discovery packet .
This is , of course, a multicast packet.
Just saw that 2.6.36.3 should include this fix :
> From: David Stevens<dlstevens@us.ibm.com>
>
> [ Upstream commit 04bdf0c9a451863e50fff627713a900a2cabb998 ]
>
> This patch fixes a missing ntohs() for bridge IPv6 multicast snooping.
But in fact , I just tested, and this doesn't cure the problem :(
This bug
- only occurs with bnx2x with tagged vlans, attached to bridges. Other
interfaces (bnx2 , for exemple) works fine. bnx2x without bridges works
fine.
- only happens when bridge is compiled with CONFIG_BRIDGE_IGMP_SNOOPING
(default setting)
- is triggered by IPv6 neighbor discovery packet. Just after that
packet, others packets are discarded for some time.
- packets originating from same vlans are not affected, only packets
previously routed are discarded. Examinating those packets, I don't
undersand why, apart TTL (and mac address), they seems similar .
- has origin circa 2.6.33 :
fe2d7c70b747d5d968f4e8fa210676d49d40059 is the first bad commit
commit 3fe2d7c70b747d5d968f4e8fa210676d49d40059
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun Feb 28 00:49:38 2010 -0800
bridge: Add multicast start/stop hooks
This patch hooks up the bridge start/stop and add/delete/disable
port functions to the new multicast module.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
What can I do to help fixing this bug ?
regards,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr
^ permalink raw reply
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Kirill A. Shutemov @ 2011-01-07 11:12 UTC (permalink / raw)
To: Al Viro
Cc: Kirill A. Shutemov, Trond Myklebust, J. Bruce Fields, Neil Brown,
Pavel Emelyanov, linux-nfs, David S. Miller, netdev, linux-kernel
In-Reply-To: <20110105114155.GN19804@ZenIV.linux.org.uk>
On Wed, Jan 05, 2011 at 11:41:55AM +0000, Al Viro wrote:
> On Wed, Dec 29, 2010 at 03:14:18PM +0200, Kirill A. Shutemov wrote:
> > Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
>
> Won't that make sunrpc impossible to rmmod once you've got it in?
> Note that having a reference to vfsmount pins it down, which pins
> the superblock down, which pins the file_system_type down, which
> pins the damn module down. So cleanup_sunrpc() won't be ever called,
> AFAICS...
Hm.. rpc_pipe_fs_type.owner = NULL seems fix the problem.
Is it valid solution in this case?
--
Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Kirill A. Shutemov @ 2011-01-07 11:19 UTC (permalink / raw)
To: Al Viro
Cc: Trond Myklebust, J. Bruce Fields, Neil Brown, Pavel Emelyanov,
linux-nfs, David S. Miller, netdev, linux-kernel
In-Reply-To: <20110107111222.GA19395@shutemov.name>
On Fri, Jan 07, 2011 at 01:12:22PM +0200, Kirill A. Shutemov wrote:
> On Wed, Jan 05, 2011 at 11:41:55AM +0000, Al Viro wrote:
> > On Wed, Dec 29, 2010 at 03:14:18PM +0200, Kirill A. Shutemov wrote:
> > > Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
> >
> > Won't that make sunrpc impossible to rmmod once you've got it in?
> > Note that having a reference to vfsmount pins it down, which pins
> > the superblock down, which pins the file_system_type down, which
> > pins the damn module down. So cleanup_sunrpc() won't be ever called,
> > AFAICS...
>
> Hm.. rpc_pipe_fs_type.owner = NULL seems fix the problem.
> Is it valid solution in this case?
Please, ignore it. :)
--
Kirill A. Shutemov
^ permalink raw reply
* Re: rndis gadget: Inconsistent locking
From: David Brownell @ 2011-01-07 11:20 UTC (permalink / raw)
To: Neil Jones; +Cc: linux-usb, netdev
In-Reply-To: <AANLkTi=OS+jernOe8y1fbMbx5Rf+JRcvzqGY4Z2LKqsH@mail.gmail.com>
> Yes Michal Nazarewicz has seen this on a S3C UDC,
Good to confirm that. As I mentioned, other folk have seen much the same bug on other hardware; we
know it's neither a new nor a HW-specific issue.
Correction to an earlier comment of mine:
https://patchwork.kernel.org/patch/195562/
does correctly identify the commit which
caused this bug in multiple drivers.
However, that patch won't apply to the latest
tree from Linus.
Michal, can you update and resubmit, so I can
at least ack your fix and xpedite its merge?
It'd be good to have RNDIS work again, a fair
number of folk rely on it, and this seems to be
the main obstacle to continuing to do that.
- Dave
^ 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