* Re: [PATCH] net: sh_eth: fix build failure
From: Nobuhiro Iwamatsu @ 2011-09-30 19:36 UTC (permalink / raw)
To: David Miller; +Cc: yoshihiro.shimoda.uh, sfr, netdev, linux-sh
In-Reply-To: <20110930.035449.1012299223616580574.davem@davemloft.net>
I see.
Thanks you.
Nobuhiro
2011/9/30 David Miller <davem@davemloft.net>:
> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Date: Fri, 30 Sep 2011 16:51:34 +0900
>
>> 2011/09/30 15:55, Nobuhiro Iwamatsu wrote:
>>> 2011/9/30 Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>:
>> < snip >
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/spinlock.h>
>>> These are not required.
>>
>> The Documentation/SubmitChecklist says the following:
>>
>> ========================================================
>> 1: If you use a facility then #include the file that defines/declares
>> that facility. Don't depend on other header files pulling in ones
>> that you use.
>> ========================================================
>>
>> The sh_eth driver uses spinlock functions and some macros of kernel.h.
>> So, I think that I have to write their "#include" in the driver.
>
> Agreed.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Nobuhiro Iwamatsu
^ permalink raw reply
* [patch] make PACKET_STATISTICS getsockopt report consistently between ring and non-ring
From: Willem de Bruijn @ 2011-09-30 20:38 UTC (permalink / raw)
To: davem, netdev
This is a minor change.
Up until kernel 2.6.32, getsockopt(fd, SOL_PACKET, PACKET_STATISTICS,
...) would return total and dropped packets since its last invocation. The
introduction of socket queue overflow reporting [1] changed drop
rate calculation in the normal packet socket path, but not when using a
packet ring. As a result, the getsockopt now returns different statistics
depending on the reception method used. With a ring, it still returns the
count since the last call, as counts are incremented in tpacket_rcv and
reset in getsockopt. Without a ring, it returns 0 if no drops occurred
since the last getsockopt and the total drops over the lifespan of
the socket otherwise. The culprit is this line in packet_rcv, executed
on a drop:
drop_n_acct:
po->stats.tp_drops = atomic_inc_return(&sk->sk_drops);
As it shows, the new drop number it taken from the socket drop counter,
which is not reset at getsockopt. I put together a small example
that demonstrates the issue [2]. It runs for 10 seconds and overflows
the queue/ring on every odd second. The reported drop rates are:
ring: 16, 0, 16, 0, 16, ...
non-ring: 0, 15, 0, 30, 0, 46, 0, 60, 0 , 74.
Note how the even ring counts monotonically increase. Because the
getsockopt adds tp_drops to tp_packets, total counts are similarly
reported cumulatively. Long story short, reinstating the original code, as
the below patch does, fixes the issue at the cost of additional per-packet
cycles. Another solution that does not introduce per-packet overhead
is be to keep the current data path, record the value of sk_drops at
getsockopt() at call N in a new field in struct packetsock and subtract
that when reporting at call N+1. I'll be happy to code that, instead,
it's just more messy.
[1] http://patchwork.ozlabs.org/patch/35665/
[2] http://kernel.googlecode.com/files/test-packetsock-getstatistics.c
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/packet/af_packet.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index c698cec..fabb4fa 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -961,7 +961,10 @@ static int packet_rcv(struct sk_buff *skb, struct net_device *dev,
return 0;
drop_n_acct:
- po->stats.tp_drops = atomic_inc_return(&sk->sk_drops);
+ spin_lock(&sk->sk_receive_queue.lock);
+ po->stats.tp_drops++;
+ atomic_inc(&sk->sk_drops);
+ spin_unlock(&sk->sk_receive_queue.lock);
drop_n_restore:
if (skb_head != skb->data && skb_shared(skb)) {
--
1.7.3.1
^ permalink raw reply related
* [PATCH] netdev/phy: Use mdiobus_read() so that proper locks are taken.
From: David Daney @ 2011-09-30 21:51 UTC (permalink / raw)
To: netdev, davem; +Cc: linux-mips, David Daney
Accesses to the mdio busses must be done with the mdio_lock to ensure
proper operation. Conveniently we have the helper function
mdiobus_read() to do that for us. Lets use it in get_phy_id() instead
of accessing the bus without the lock held.
Signed-off-by: David Daney <david.daney@cavium.com>
---
drivers/net/phy/phy_device.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index ff109fe..83a5a5a 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -213,7 +213,7 @@ int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id)
/* Grab the bits from PHYIR1, and put them
* in the upper half */
- phy_reg = bus->read(bus, addr, MII_PHYSID1);
+ phy_reg = mdiobus_read(bus, addr, MII_PHYSID1);
if (phy_reg < 0)
return -EIO;
@@ -221,7 +221,7 @@ int get_phy_id(struct mii_bus *bus, int addr, u32 *phy_id)
*phy_id = (phy_reg & 0xffff) << 16;
/* Grab the bits from PHYIR2, and put them in the lower half */
- phy_reg = bus->read(bus, addr, MII_PHYSID2);
+ phy_reg = mdiobus_read(bus, addr, MII_PHYSID2);
if (phy_reg < 0)
return -EIO;
--
1.7.2.3
^ permalink raw reply related
* [PATCH] netdev/phy/icplus: Use mdiobus_write() and mdiobus_read() for proper locking.
From: David Daney @ 2011-09-30 22:17 UTC (permalink / raw)
To: netdev, davem
Cc: linux-mips, David Daney, Greg Dietsche, Uwe Kleine-Konig,
Giuseppe Cavallaro
Usually you have to take the bus lock. Why not here too?
I saw this when working on something else. Not even compile tested.
Signed-off-by: David Daney <david.daney@cavium.com>
Cc: Greg Dietsche <Gregory.Dietsche@cuw.edu>
Cc: "Uwe Kleine-Konig" <u.kleine-koenig@pengutronix.de>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/phy/icplus.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/icplus.c b/drivers/net/phy/icplus.c
index d4cbc29..bd4c740 100644
--- a/drivers/net/phy/icplus.c
+++ b/drivers/net/phy/icplus.c
@@ -42,36 +42,36 @@ static int ip175c_config_init(struct phy_device *phydev)
if (full_reset_performed == 0) {
/* master reset */
- err = phydev->bus->write(phydev->bus, 30, 0, 0x175c);
+ err = mdiobus_write(phydev->bus, 30, 0, 0x175c);
if (err < 0)
return err;
/* ensure no bus delays overlap reset period */
- err = phydev->bus->read(phydev->bus, 30, 0);
+ err = mdiobus_read(phydev->bus, 30, 0);
/* data sheet specifies reset period is 2 msec */
mdelay(2);
/* enable IP175C mode */
- err = phydev->bus->write(phydev->bus, 29, 31, 0x175c);
+ err = mdiobus_write(phydev->bus, 29, 31, 0x175c);
if (err < 0)
return err;
/* Set MII0 speed and duplex (in PHY mode) */
- err = phydev->bus->write(phydev->bus, 29, 22, 0x420);
+ err = mdiobus_write(phydev->bus, 29, 22, 0x420);
if (err < 0)
return err;
/* reset switch ports */
for (i = 0; i < 5; i++) {
- err = phydev->bus->write(phydev->bus, i,
- MII_BMCR, BMCR_RESET);
+ err = mdiobus_write(phydev->bus, i,
+ MII_BMCR, BMCR_RESET);
if (err < 0)
return err;
}
for (i = 0; i < 5; i++)
- err = phydev->bus->read(phydev->bus, i, MII_BMCR);
+ err = mdiobus_read(phydev->bus, i, MII_BMCR);
mdelay(2);
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] netdev/phy: Use mdiobus_read() so that proper locks are taken.
From: David Miller @ 2011-09-30 22:54 UTC (permalink / raw)
To: david.daney; +Cc: netdev, linux-mips
In-Reply-To: <1317419482-25655-1-git-send-email-david.daney@cavium.com>
From: David Daney <david.daney@cavium.com>
Date: Fri, 30 Sep 2011 14:51:22 -0700
> Accesses to the mdio busses must be done with the mdio_lock to ensure
> proper operation. Conveniently we have the helper function
> mdiobus_read() to do that for us. Lets use it in get_phy_id() instead
> of accessing the bus without the lock held.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] netdev/phy/icplus: Use mdiobus_write() and mdiobus_read() for proper locking.
From: David Miller @ 2011-09-30 22:54 UTC (permalink / raw)
To: david.daney
Cc: netdev, linux-mips, Gregory.Dietsche, u.kleine-koenig,
peppe.cavallaro
In-Reply-To: <1317421068-27278-1-git-send-email-david.daney@cavium.com>
From: David Daney <david.daney@cavium.com>
Date: Fri, 30 Sep 2011 15:17:48 -0700
> Usually you have to take the bus lock. Why not here too?
>
> I saw this when working on something else. Not even compile tested.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
> Cc: Greg Dietsche <Gregory.Dietsche@cuw.edu>
> Cc: "Uwe Kleine-Konig" <u.kleine-koenig@pengutronix.de>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied to net-next.
^ permalink raw reply
* [PATCH net-next] drivers/net: Add module.h to wireless/ath/ath6kl/sdio.c
From: Paul Gortmaker @ 2011-09-30 23:07 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linville-2XuSBdqkA4R54TAoqtyWWQ,
kvalo-A+ZNKFmMK5xy9aJCnZT0Uw,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Paul Gortmaker
This file uses various MODULE_* macros, and so needs the full
module.h header called out explicitly.
Signed-off-by: Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
---
[Dave: I can't carry this in the module.h tree with all the other one
line patches, as it only exists in trees based off wireless/net-next.
It fixes a compile failure that shows up in linux-next. Thanks.]
diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
index 3417160..ca4a93e 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -14,6 +14,7 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include <linux/module.h>
#include <linux/mmc/card.h>
#include <linux/mmc/mmc.h>
#include <linux/mmc/host.h>
--
1.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFD PATCH] netdev/phy/of: Augment device tree bindings for PHYs to specify IEEE802.3-2005 Section 45 addressing.
From: David Daney @ 2011-09-30 23:09 UTC (permalink / raw)
To: devicetree-discuss, grant.likely, linux-kernel, netdev, davem; +Cc: David Daney
Many 10 gigabit Ethernet PHY devices are interfaced to the MDIO bus
using a protocol called IEEE802.3-2005 Section 45. Where as PHYS for
1G, 100M and 10M usually use IEEE802.3-2005 Section 22. These two
protocols can be present on the same MDIO bus.
If we look at the Linux PHY probing code in drivers/of/of_mdio.c and
drivers/net/phy/phy_device.c, we have the situation where we need to
read the PHY registers to get the PHY ID out so that we can use this
to bind to a compatible driver. However we can only read these
registers if we know the proper MDIO bus protocol to use.
My idea is as follows:
o Add an optional property "mdio-clause-45" to the PHY's device tree
node to indicate that clause 45 addressing is used.
o When calling get_phy_id() we will set MII_ADDR_C45 in the address
if we know that clause 45 addressing is required for the PHY.
get_phy_id() will then use the proper bus protocol and register
numbers to read PHY ID based on MII_ADDR_C45.
o of_mdiobus_register() will signal MII_ADDR_C45 for PHYs tagged with
"mdio-clause-45"
o Existing PHYs without "mdio-clause-45" are unaffected.
o If no specific driver for the probed PHY ID is present, we can still
communicate with the PHY and perhaps use a generic 10G phy driver.
If the MDIO bus protocol were just to depend on the "compatible"
property, then we could not use generic drivers for unknown PHY IDs
Comments/other ideas welcome.
Thanks,
Signed-off-by: David Daney <david.daney@cavium.com>
---
Documentation/devicetree/bindings/net/phy.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index bb8c742..69fd948 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -14,6 +14,11 @@ Required properties:
- linux,phandle : phandle for this node; likely referenced by an
ethernet controller node.
+Optional properties:
+
+ - mdio-clause-45 : Optional. If present, IEEE802.3-2005 Section 45
+ protocol is used for register access (usually for 10G PHYs).
+
Example:
ethernet-phy@0 {
--
1.7.2.3
^ permalink raw reply related
* Re: tg3: BMC stops responding in 3.0
From: Matt Carlson @ 2011-09-30 23:53 UTC (permalink / raw)
To: Arkadiusz Mi??kiewicz
Cc: Matthew Carlson, Michael Chan, netdev@vger.kernel.org
In-Reply-To: <201109301006.25590.a.miskiewicz@gmail.com>
On Fri, Sep 30, 2011 at 01:06:25AM -0700, Arkadiusz Mi??kiewicz wrote:
> On Friday 30 of September 2011, Matt Carlson wrote:
> > On Mon, Sep 26, 2011 at 11:31:33AM -0700, Arkadiusz Mi??kiewicz wrote:
> > > On Monday 26 of September 2011, Matt Carlson wrote:
> > > > On Fri, Sep 23, 2011 at 12:45:50PM -0700, Arkadiusz Mi??kiewicz wrote:
> > > > > Hi,
> > > > >
> > > > > I was using 2.6.38.8 and recently tried to switch to 3.0.4 on Tyan
> > > > > S2891 platform.
> > > > >
> > > > > This platform uses tg3:
> > > > > tg3 0000:0a:09.1: eth1: Tigon3 [partno(BCM95704) rev 2003]
> > > > > (PCIX:133MHz:64- bit) MAC address 00:e0:81:33:5e:af
> > > > > tg3 0000:0a:09.1: eth1: attached PHY is 5704 (10/100/1000Base-T
> > > > > Ethernet) (WireSpeed[1], EEE[0])
> > > > > tg3 0000:0a:09.1: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0]
> > > > > TSOcap[1] tg3 0000:0a:09.1: eth1: dma_rwctrl[769f4000]
> > > > > dma_mask[64-bit]
> > > > >
> > > > > With 2.6.38.8 everything was working fine. With 3.0.4 there is a
> > > > > problem. As soon as tg3 module is loaded or eth0 configured (can't
> > > > > tell which one since the machine is 400km away from me and I have no
> > > > > way to play with it other than ipmi or ssh) BMC stops responding (so
> > > > > all ipmitool commands over LAN stop working). Normal tg3 activity is
> > > > > not affected - I can ssh-in without a problem etc but ipmi over lan
> > > > > doesn't work.
> > > > >
> > > > > From ssh console "ipmitool lan print" works, shows data but for
> > > > > example after "ipmitool mc reset cold" it doesn't recover - ipmitool
> > > > > returns "Invalid channel: 255". I have to reboot to 2.6.38.8 and
> > > > > then issue "ipmitool mc reset cold" to recover.
> > > > >
> > > > > Any idea which tg3 change could break this? Can't bisect this due
> > > > > remote access only.
> > > > >
> > > > > I was hoping that maybe 9e975cc291d80d5e4562d6bed15ec171e896d69b
> > > > > "tg3: Fix io failures after chip reset" will fix things for me but no
> > > > > - this doesn't help.
> > > >
> > > > What version of the tg3 driver are you working with?
> > >
> > > The one in 3.0.4 kernel. I think it's 3.119 (at least modinfo says so).
> >
> > Unfortunately there were a lot of changes between 3.117 and 3.119(+).
> > Is there any way you can narrow down the gap?
>
> The machines are 400km away from me and it's hard to debug that way then
> ipmi/network conectivity is in stake :-/ I could try some form of bisecting
> but need to know if all git versions between 3.117 and 3.119 were known to be
> safe and working? I don't want to loose any conectivity to this machine.
>
> I was going to try 2.6.39 but it looks like it also uses 3.117 driver.
O.K. Can you give me the details of your machine? Maybe we have the
exact machine or a machine similar enough to reproduce the problem with.
^ permalink raw reply
* Re: Network problem with bridge and virtualbox
From: Stephen Hemminger @ 2011-10-01 0:18 UTC (permalink / raw)
To: William Thompson; +Cc: netdev
In-Reply-To: <20110929124941.GA16567@electro-mechanical.com>
On Thu, 29 Sep 2011 08:49:41 -0400
William Thompson <wt@electro-mechanical.com> wrote:
> Please keep me in the CC as I am not subscribed.
>
> I'm using a 64-bit kernel 3.0.0 and virtualbox 4.1.2.
>
> My problem is that I cannot ping the host from a virtual machine.
>
> My bridge is configured as follows:
> # brctl addbr br0
> # brctl setfd br0 0
> # brctl stp br0 off
> # ifconfig br0 10.2.3.1 netmask 255.255.255.0
>
> In the virtual machine, it is set to use br0 as it's interface (bridge mode)
> and it's IP is 10.2.3.10.
>
> The host gets packets from the vm, but the vm does not receive packets back.
>
> I have this same setup working on a 32-bit kernel 2.6.38.6 on another
> machine with virtualbox 4.0.4.
>
> I had a thought that the bridge on the host wasn't responding due to having
> no ports configured so I added one of my spare ethernet cards to it as
> follows:
> # brctl addif br0 eth1
> # ifconfig eth1 up
>
> The card was plugged into a switch. After doing this, the vm still could not
> talk to the host. I added a physical machine to the switch that eth1 was
> connected to and configured it to 10.2.3.2. I was able to ping 10.2.3.2 but
> not 10.2.3.1
Did you add any interface to the bridge?
I think you were bit by the change in carrier behavior. No carrier on the
bridge interface tracks the union of the devices in the bridge.
Several people have been using bridge in strange way (as a dummy device)
with no physical interfaces and some applications are checking for carrier.
^ permalink raw reply
* [PATCH 2/2] bridge: allow updating existing fdb entries
From: Stephen Hemminger @ 2011-10-01 0:37 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20111001003725.449204345@vyatta.com>
[-- Attachment #1: bridge-allow-replace-fdb.patch --]
[-- Type: text/plain, Size: 1580 bytes --]
Need to allow application to update existing fdb entries that already
exist. This makes bridge netlink neighbor API have same flags and
semantics as ip neighbor table.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
net/bridge/br_fdb.c | 23 ++++++++++++++++-------
1 files changed, 16 insertions(+), 7 deletions(-)
--- a/net/bridge/br_fdb.c 2011-09-16 13:12:58.061369744 -0700
+++ b/net/bridge/br_fdb.c 2011-09-30 10:31:57.478241405 -0700
@@ -558,19 +558,28 @@ skip:
/* Create new static fdb entry */
static int fdb_add_entry(struct net_bridge_port *source, const __u8 *addr,
- __u16 state)
+ __u16 state, __u16 flags)
{
struct net_bridge *br = source->br;
struct hlist_head *head = &br->hash[br_mac_hash(addr)];
struct net_bridge_fdb_entry *fdb;
fdb = fdb_find(head, addr);
- if (fdb)
- return -EEXIST;
-
- fdb = fdb_create(head, source, addr);
- if (!fdb)
- return -ENOMEM;
+ if (fdb == NULL) {
+ if (!(flags & NLM_F_CREATE))
+ return -ENOENT;
+
+ fdb = fdb_create(head, source, addr);
+ if (!fdb)
+ return -ENOMEM;
+ } else {
+ if (flags & NLM_F_EXCL)
+ return -EEXIST;
+
+ if (flags & NLM_F_REPLACE)
+ fdb->updated = fdb->used = jiffies;
+ fdb->is_local = fdb->is_static = 0;
+ }
if (state & NUD_PERMANENT)
fdb->is_local = fdb->is_static = 1;
@@ -626,7 +635,7 @@ int br_fdb_add(struct sk_buff *skb, stru
}
spin_lock_bh(&p->br->hash_lock);
- err = fdb_add_entry(p, addr, ndm->ndm_state);
+ err = fdb_add_entry(p, addr, ndm->ndm_state, nlh->nlmsg_flags);
spin_unlock_bh(&p->br->hash_lock);
return err;
^ permalink raw reply
* [PATCH 1/2] bridge: fix ordering of NEWLINK and NEWNEIGH events
From: Stephen Hemminger @ 2011-10-01 0:37 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20111001003725.449204345@vyatta.com>
[-- Attachment #1: bridge-fix-event-order.patch --]
[-- Type: text/plain, Size: 2076 bytes --]
When port is added to a bridge, the old code would send the new neighbor
netlink message before the subsequent new link message. This bug makes
it difficult to use the monitoring API in an application.
This code changes the ordering to add the forwarding entry
after the port is setup. One of the error checks (for invalid address)
is moved earlier in the process to avoid having to do unwind.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
net/bridge/br_if.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/net/bridge/br_if.c 2011-09-22 21:59:11.515091624 -0700
+++ b/net/bridge/br_if.c 2011-09-30 10:31:32.877957572 -0700
@@ -13,6 +13,7 @@
#include <linux/kernel.h>
#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
#include <linux/netpoll.h>
#include <linux/ethtool.h>
#include <linux/if_arp.h>
@@ -322,7 +323,8 @@ int br_add_if(struct net_bridge *br, str
/* Don't allow bridging non-ethernet like devices */
if ((dev->flags & IFF_LOOPBACK) ||
- dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN)
+ dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
+ !is_valid_ether_addr(dev->dev_addr))
return -EINVAL;
/* No bridging of bridges */
@@ -350,10 +352,6 @@ int br_add_if(struct net_bridge *br, str
err = kobject_init_and_add(&p->kobj, &brport_ktype, &(dev->dev.kobj),
SYSFS_BRIDGE_PORT_ATTR);
if (err)
- goto err0;
-
- err = br_fdb_insert(br, p, dev->dev_addr);
- if (err)
goto err1;
err = br_sysfs_addif(p);
@@ -394,6 +392,9 @@ int br_add_if(struct net_bridge *br, str
dev_set_mtu(br->dev, br_min_mtu(br));
+ if (br_fdb_insert(br, p, dev->dev_addr))
+ netdev_err(dev, "failed insert local address bridge forwarding table\n");
+
kobject_uevent(&p->kobj, KOBJ_ADD);
return 0;
@@ -403,11 +404,9 @@ err4:
err3:
sysfs_remove_link(br->ifobj, p->dev->name);
err2:
- br_fdb_delete_by_port(br, p, 1);
-err1:
kobject_put(&p->kobj);
p = NULL; /* kobject_put frees */
-err0:
+err1:
dev_set_promiscuity(dev, -1);
put_back:
dev_put(dev);
^ permalink raw reply
* [PATCH] bluetooth: macroize two small inlines to avoid module.h
From: Paul Gortmaker @ 2011-10-01 2:12 UTC (permalink / raw)
To: marcel-kz+m5ild9QBg9hUCZPvPmw, padovan-Y3ZbgMPKUGA34EUeqzHoZw
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Paul Gortmaker
These two small inlines make calls to try_module_get() and
module_put() which would force us to keep module.h present
within yet another common include header. We can avoid this
by turning them into macros. The hci_dev_hold construct
is patterned off of raw_spin_trylock_irqsave() in spinlock.h
Signed-off-by: Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
---
[This is something I've added to the module.h cleanup tree since
the original module.h cleanup RFC patchset; sending here just for
transparency and for any review comments.]
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 8f441b8..9a77e8a 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -498,11 +498,15 @@ static inline void __hci_dev_put(struct hci_dev *d)
d->destruct(d);
}
-static inline void hci_dev_put(struct hci_dev *d)
-{
- __hci_dev_put(d);
- module_put(d->owner);
-}
+/*
+ * hci_dev_put and hci_dev_hold are macros to avoid dragging all the
+ * overhead of all the modular infrastructure into this header.
+ */
+#define hci_dev_put(d) \
+do { \
+ __hci_dev_put(d); \
+ module_put(d->owner); \
+} while (0)
static inline struct hci_dev *__hci_dev_hold(struct hci_dev *d)
{
@@ -510,12 +514,10 @@ static inline struct hci_dev *__hci_dev_hold(struct hci_dev *d)
return d;
}
-static inline struct hci_dev *hci_dev_hold(struct hci_dev *d)
-{
- if (try_module_get(d->owner))
- return __hci_dev_hold(d);
- return NULL;
-}
+#define hci_dev_hold(d) \
+({ \
+ try_module_get(d->owner) ? __hci_dev_hold(d) : NULL; \
+})
#define hci_dev_lock(d) spin_lock(&d->lock)
#define hci_dev_unlock(d) spin_unlock(&d->lock)
--
1.7.6
^ permalink raw reply related
* (unknown),
From: FEDEX OFFICE @ 2011-10-01 2:08 UTC (permalink / raw)
Attn: Beneficiary,
This is to inform you that your package worth the sum of $800,000.00 (Eight
Hundred Thousand United State Dollars) in a certified bank draft is in our
office ready for delivery,We are sending you this email because your package
has been registered on a Special Order.You are advise to contact our Delivery
Department for immediate dispatch of your package to your designated address.
Regards
Mr.Umar Tony {Head Dispatch Officer}
FedEx Express ®Courier Company West-Africa
E-mail:fedexdelivery1952@msn.com
Telephone Number:+234-70-65749930
---------------------------------------------------------------------------------
www.galiciaaberta.com
Información mantida pola Secretaría Xeral de Emigración da Xunta de Galicia
^ permalink raw reply
* Re: ICMP redirect issue
From: Simon Horman @ 2011-10-01 3:22 UTC (permalink / raw)
To: David Miller; +Cc: fbl, netdev
In-Reply-To: <20110928.191255.1803703769504267178.davem@davemloft.net>
On Wed, Sep 28, 2011 at 07:12:55PM -0400, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 28 Sep 2011 18:56:54 -0400 (EDT)
>
> > From: Flavio Leitner <fbl@redhat.com>
> > Date: Wed, 28 Sep 2011 17:19:52 -0300
> >
> >> What about something like below? It will change a bit the
> >> secure_redirects documentation.
> >
> > The previous check was stronger, and served other purposes.
> >
> > Firstly, it required that the spoofer know the exact gateway
> > IP address we used previously, whereas your test requires only
> > knowing the subnet which is easier to figure out.
> >
> > But more importantly, the old test allowed us to ignore outdated
> > or erroneous redirects.
> >
> > We really have to restore the original behavior before my inetpeer
> > changes (enforce that the old gateway matches), and find another way
> > to accomodate IPVS.
>
> BTW, I just double-checked RFC1122 and it explicitly specifies the
> old_gw check:
>
> [ RFC1122, section 3.2.2.2 ]
>
> ...
>
> A Redirect message SHOULD be silently discarded if the new
> gateway address it specifies is not on the same connected
> (sub-) net through which the Redirect arrived [INTRO:2,
> Appendix A], or if the source of the Redirect is not the
> current first-hop gateway for the specified destination (see
> Section 3.3.1).
>
> In fact, it's saying that we should also validate that saddr == old_gw
> too.
>
> So really, we need to put the check back and find a way to accomodate IPVS.
Hi Dave,
I'm have to admit that this issues is new to me.
But doesn't it affect any setup where a secondary
address is being used as the gateway and the gateway
send an ICMP redirect?
Perhaps an option to weaken the check for these cases
would provide a work-around for those who need it.
Or does that break your inetpeer changes horribly?
^ permalink raw reply
* [GIT PULL nf-next] IPVS
From: Simon Horman @ 2011-10-01 3:34 UTC (permalink / raw)
To: Patrick McHardy, Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
Hi Pablo,
please consider pulling the following to get some
documentation changes from myself.
The following changes since commit 6fa4dec85e199f31774faf29be26a53329d02e9e:
ipvs: Removed unused variables (2011-09-28 21:09:24 +0200)
are available in the git repository at:
git@github.com:horms/ipvs-next.git master
Simon Horman (2):
IPVS: secure_tcp does provide alternate state timeouts
IPVS: Enhance grammar used to refer to Kconfig options
Documentation/networking/ipvs-sysctl.txt | 14 ++++++--------
1 files changed, 6 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH 1/2] IPVS: secure_tcp does provide alternate state timeouts
From: Simon Horman @ 2011-10-01 3:34 UTC (permalink / raw)
To: Patrick McHardy, Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Simon Horman
In-Reply-To: <1317440059-31112-1-git-send-email-horms@verge.net.au>
* Also reword the test to make it read more easily (to me)
Signed-off-by: Simon Horman <horms@verge.net.au>
---
Julian, I don't see that IPVS currently implements alternate
timeouts for secure_tcp. Am I missing something?
---
Documentation/networking/ipvs-sysctl.txt | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index 1dcdd49..13610e3 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -140,13 +140,11 @@ nat_icmp_send - BOOLEAN
secure_tcp - INTEGER
0 - disabled (default)
- The secure_tcp defense is to use a more complicated state
- transition table and some possible short timeouts of each
- state. In the VS/NAT, it delays the entering the ESTABLISHED
- until the real server starts to send data and ACK packet
- (after 3-way handshake).
+ The secure_tcp defense is to use a more complicated TCP state
+ transition table. For VS/NAT, it also delays entering the
+ TCP ESTABLISHED state until the three way handshake is completed.
- The value definition is the same as that of drop_entry or
+ The value definition is the same as that of drop_entry and
drop_packet.
sync_threshold - INTEGER
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] IPVS: Enhance grammar used to refer to Kconfig options
From: Simon Horman @ 2011-10-01 3:34 UTC (permalink / raw)
To: Patrick McHardy, Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Simon Horman
In-Reply-To: <1317440059-31112-1-git-send-email-horms@verge.net.au>
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
Documentation/networking/ipvs-sysctl.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index 13610e3..f2a2488 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -30,7 +30,7 @@ conntrack - BOOLEAN
Connections handled by the IPVS FTP application module
will have connection tracking entries regardless of this setting.
- Only available when IPVS is compiled with the CONFIG_IP_VS_NFCT
+ Only available when IPVS is compiled with CONFIG_IP_VS_NFCT enabled.
cache_bypass - BOOLEAN
0 - disabled (default)
@@ -56,7 +56,7 @@ debug_level - INTEGER
11 - IPVS packet handling (ip_vs_in/ip_vs_out)
12 or more - packet traversal
- Only available when IPVS is compiled with the CONFIG_IP_VS_DEBUG
+ Only available when IPVS is compiled with CONFIG_IP_VS_DEBUG enabled.
Higher debugging levels include the messages for lower debugging
levels, so setting debug level 2, includes level 0, 1 and 2
--
1.7.5.4
^ permalink raw reply related
* [net-next 00/11 v2][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-01 4:52 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo
The following series contains updates to e1000e and ixgbe. The one
patch for e1000e makes function tables const, thanks to Stephen
Hemminger for reporting this. The remaining patches are for ixgbe,
and the contain the following:
- minor cleanups
- add support for 82599 device and ethtool -E support
- removal of a PHY which is not used in production silicon
v2- Updated patch 11 with the suggested changes from Ben Hutchings
The following are changes since commit 56fd49e399ce1d82200fad5b8924d4e35a587809:
bna: Driver Version changed to 3.0.2.2
and are available in the git repository at
git://github.com/Jkirsher/net-next.git
Emil Tantilov (8):
ixgbe: prevent link checks while resetting
ixgbe: clear the data field in ixgbe_read_i2c_byte_generic
ixgbe: remove return code for functions that always return 0
ixgbe: add support for new 82599 device
ixgbe: send MFLCN to ethtool
ixgbe: do not disable flow control in ixgbe_check_mac_link
ixgbe: remove instances of ixgbe_phy_aq for 82598 and 82599
ixgbe: allow eeprom writes via ethtool
Jacob Keller (1):
ixgbe: fix driver version initialization in firmware
Jeff Kirsher (1):
e1000e: make function tables const
Mika Lansirinne (1):
ixgbe: get pauseparam autoneg
drivers/net/ethernet/intel/e1000e/80003es2lan.c | 8 +-
drivers/net/ethernet/intel/e1000e/82571.c | 20 +++---
drivers/net/ethernet/intel/e1000e/e1000.h | 28 ++++----
drivers/net/ethernet/intel/e1000e/ich8lan.c | 16 +++---
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 8 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 7 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 6 --
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 74 +++++++++++++++++++---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 12 +++-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 33 +++-------
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 1 +
12 files changed, 125 insertions(+), 89 deletions(-)
--
1.7.6.2
^ permalink raw reply
* [net-next 11/11 v2] ixgbe: allow eeprom writes via ethtool
From: Jeff Kirsher @ 2011-10-01 4:52 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, Jeff Kirsher
In-Reply-To: <1317444771-13962-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Implement support for ethtool -E
v2- change 2 return values to EINVAL based on feedback
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 61 ++++++++++++++++++++++
2 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
index e02e911..fff57a0 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
@@ -1305,6 +1305,7 @@ static struct ixgbe_mac_operations mac_ops_82598 = {
static struct ixgbe_eeprom_operations eeprom_ops_82598 = {
.init_params = &ixgbe_init_eeprom_params_generic,
.read = &ixgbe_read_eerd_generic,
+ .write = &ixgbe_write_eeprom_generic,
.read_buffer = &ixgbe_read_eerd_buffer_generic,
.calc_checksum = &ixgbe_calc_eeprom_checksum_generic,
.validate_checksum = &ixgbe_validate_eeprom_checksum_generic,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 10ea29f..fb47abb 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -812,6 +812,66 @@ static int ixgbe_get_eeprom(struct net_device *netdev,
return ret_val;
}
+static int ixgbe_set_eeprom(struct net_device *netdev,
+ struct ethtool_eeprom *eeprom, u8 *bytes)
+{
+ struct ixgbe_adapter *adapter = netdev_priv(netdev);
+ struct ixgbe_hw *hw = &adapter->hw;
+ u16 *eeprom_buff;
+ void *ptr;
+ int max_len, first_word, last_word, ret_val = 0;
+ u16 i;
+
+ if (eeprom->len == 0)
+ return -EINVAL;
+
+ if (eeprom->magic != (hw->vendor_id | (hw->device_id << 16)))
+ return -EINVAL;
+
+ max_len = hw->eeprom.word_size * 2;
+
+ first_word = eeprom->offset >> 1;
+ last_word = (eeprom->offset + eeprom->len - 1) >> 1;
+ eeprom_buff = kmalloc(max_len, GFP_KERNEL);
+ if (!eeprom_buff)
+ return -ENOMEM;
+
+ ptr = (void *)eeprom_buff;
+
+ if (eeprom->offset & 1) {
+ /*
+ * need read/modify/write of first changed EEPROM word
+ * only the second byte of the word is being modified
+ */
+ ret_val = hw->eeprom.ops.read(hw, first_word, &eeprom_buff[0]);
+ ptr++;
+ }
+ if (((eeprom->offset + eeprom->len) & 1) && (ret_val == 0)) {
+ /*
+ * need read/modify/write of last changed EEPROM word
+ * only the first byte of the word is being modified
+ */
+ ret_val = hw->eeprom.ops.read(hw, last_word,
+ &eeprom_buff[last_word - first_word]);
+ }
+
+ /* Device's eeprom is always little-endian, word addressable */
+ for (i = 0; i < last_word - first_word + 1; i++)
+ le16_to_cpus(&eeprom_buff[i]);
+
+ memcpy(ptr, bytes, eeprom->len);
+
+ for (i = 0; i <= (last_word - first_word); i++)
+ ret_val |= hw->eeprom.ops.write(hw, first_word + i,
+ eeprom_buff[i]);
+
+ /* Update the checksum */
+ hw->eeprom.ops.update_checksum(hw);
+
+ kfree(eeprom_buff);
+ return ret_val;
+}
+
static void ixgbe_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
@@ -2526,6 +2586,7 @@ static const struct ethtool_ops ixgbe_ethtool_ops = {
.get_link = ethtool_op_get_link,
.get_eeprom_len = ixgbe_get_eeprom_len,
.get_eeprom = ixgbe_get_eeprom,
+ .set_eeprom = ixgbe_set_eeprom,
.get_ringparam = ixgbe_get_ringparam,
.set_ringparam = ixgbe_set_ringparam,
.get_pauseparam = ixgbe_get_pauseparam,
--
1.7.6.2
^ permalink raw reply related
* Re: [net-next 00/11 v2][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-01 4:56 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1317444771-13962-1-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]
On Fri, 2011-09-30 at 21:52 -0700, Kirsher, Jeffrey T wrote:
> The following series contains updates to e1000e and ixgbe. The one
> patch for e1000e makes function tables const, thanks to Stephen
> Hemminger for reporting this. The remaining patches are for ixgbe,
> and the contain the following:
>
> - minor cleanups
> - add support for 82599 device and ethtool -E support
> - removal of a PHY which is not used in production silicon
>
> v2- Updated patch 11 with the suggested changes from Ben Hutchings
>
> The following are changes since commit 56fd49e399ce1d82200fad5b8924d4e35a587809:
> bna: Driver Version changed to 3.0.2.2
> and are available in the git repository at
> git://github.com/Jkirsher/net-next.git
>
> Emil Tantilov (8):
> ixgbe: prevent link checks while resetting
> ixgbe: clear the data field in ixgbe_read_i2c_byte_generic
> ixgbe: remove return code for functions that always return 0
> ixgbe: add support for new 82599 device
> ixgbe: send MFLCN to ethtool
> ixgbe: do not disable flow control in ixgbe_check_mac_link
> ixgbe: remove instances of ixgbe_phy_aq for 82598 and 82599
> ixgbe: allow eeprom writes via ethtool
>
> Jacob Keller (1):
> ixgbe: fix driver version initialization in firmware
>
> Jeff Kirsher (1):
> e1000e: make function tables const
>
> Mika Lansirinne (1):
> ixgbe: get pauseparam autoneg
>
> drivers/net/ethernet/intel/e1000e/80003es2lan.c | 8 +-
> drivers/net/ethernet/intel/e1000e/82571.c | 20 +++---
> drivers/net/ethernet/intel/e1000e/e1000.h | 28 ++++----
> drivers/net/ethernet/intel/e1000e/ich8lan.c | 16 +++---
> drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 8 +--
> drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 7 +--
> drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 6 --
> drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 74 +++++++++++++++++++---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 12 +++-
> drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 33 +++-------
> drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 1 +
> 12 files changed, 125 insertions(+), 89 deletions(-)
>
I did not re-send patches 1-10 of the series since there was no change.
I can re-send if necessary...
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: tg3: BMC stops responding in 3.0
From: Arkadiusz Miśkiewicz @ 2011-10-01 5:37 UTC (permalink / raw)
To: Matt Carlson; +Cc: Michael Chan, netdev@vger.kernel.org
In-Reply-To: <20110930235353.GB16743@mcarlson.broadcom.com>
On Saturday 01 of October 2011, Matt Carlson wrote:
> On Fri, Sep 30, 2011 at 01:06:25AM -0700, Arkadiusz Mi??kiewicz wrote:
> > On Friday 30 of September 2011, Matt Carlson wrote:
> > > On Mon, Sep 26, 2011 at 11:31:33AM -0700, Arkadiusz Mi??kiewicz wrote:
> > > > On Monday 26 of September 2011, Matt Carlson wrote:
> > > > > On Fri, Sep 23, 2011 at 12:45:50PM -0700, Arkadiusz Mi??kiewicz
wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I was using 2.6.38.8 and recently tried to switch to 3.0.4 on
> > > > > > Tyan S2891 platform.
> > > > > >
> > > > > > This platform uses tg3:
> > > > > > tg3 0000:0a:09.1: eth1: Tigon3 [partno(BCM95704) rev 2003]
> > > > > > (PCIX:133MHz:64- bit) MAC address 00:e0:81:33:5e:af
> > > > > > tg3 0000:0a:09.1: eth1: attached PHY is 5704 (10/100/1000Base-T
> > > > > > Ethernet) (WireSpeed[1], EEE[0])
> > > > > > tg3 0000:0a:09.1: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0]
> > > > > > TSOcap[1] tg3 0000:0a:09.1: eth1: dma_rwctrl[769f4000]
> > > > > > dma_mask[64-bit]
> > > > > >
> > > > > > With 2.6.38.8 everything was working fine. With 3.0.4 there is a
> > > > > > problem. As soon as tg3 module is loaded or eth0 configured
> > > > > > (can't tell which one since the machine is 400km away from me
> > > > > > and I have no way to play with it other than ipmi or ssh) BMC
> > > > > > stops responding (so all ipmitool commands over LAN stop
> > > > > > working). Normal tg3 activity is not affected - I can ssh-in
> > > > > > without a problem etc but ipmi over lan doesn't work.
> > > > > >
> > > > > > From ssh console "ipmitool lan print" works, shows data but for
> > > > > > example after "ipmitool mc reset cold" it doesn't recover -
> > > > > > ipmitool returns "Invalid channel: 255". I have to reboot to
> > > > > > 2.6.38.8 and then issue "ipmitool mc reset cold" to recover.
> > > > > >
> > > > > > Any idea which tg3 change could break this? Can't bisect this due
> > > > > > remote access only.
> > > > > >
> > > > > > I was hoping that maybe 9e975cc291d80d5e4562d6bed15ec171e896d69b
> > > > > > "tg3: Fix io failures after chip reset" will fix things for me
> > > > > > but no - this doesn't help.
> > > > >
> > > > > What version of the tg3 driver are you working with?
> > > >
> > > > The one in 3.0.4 kernel. I think it's 3.119 (at least modinfo says
> > > > so).
> > >
> > > Unfortunately there were a lot of changes between 3.117 and 3.119(+).
> > > Is there any way you can narrow down the gap?
> >
> > The machines are 400km away from me and it's hard to debug that way then
> > ipmi/network conectivity is in stake :-/ I could try some form of
> > bisecting but need to know if all git versions between 3.117 and 3.119
> > were known to be safe and working? I don't want to loose any conectivity
> > to this machine.
> >
> > I was going to try 2.6.39 but it looks like it also uses 3.117 driver.
>
> O.K. Can you give me the details of your machine? Maybe we have the
> exact machine or a machine similar enough to reproduce the problem with.
It's 1U server, with Tyan S2891 mainboard and some chenbro chassis. ipmi and
eth0 share physical rj45 port in the server.
lspci & dmidecode below:
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
Subsystem: Tyan Computer Thunder K8SRE Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [e0] HyperTransport: MSI Mapping Enable+ Fixed-
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0
I/O ports at 8c00 [size=1K]
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
Subsystem: Tyan Computer Device 2891
Flags: 66MHz, fast devsel
I/O ports at 1000 [size=32]
I/O ports at 5000 [size=64]
I/O ports at 5040 [size=64]
Capabilities: [44] Power Management version 2
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
(prog-if 10 [OHCI])
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10
Memory at dd000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
(prog-if 20 [EHCI])
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 7
Memory at dd001000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port: BAR=1 offset=0098
Capabilities: [80] Power Management version 2
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a
[Master SecP PriP])
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0
[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1]
I/O ports at 1400 [size=16]
Capabilities: [44] Power Management version 2
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
(prog-if 85 [Master SecO PriO])
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 11
I/O ports at 1440 [size=8]
I/O ports at 1434 [size=4]
I/O ports at 1438 [size=8]
I/O ports at 1430 [size=4]
I/O ports at 1410 [size=16]
Memory at dd002000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
(prog-if 85 [Master SecO PriO])
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10
I/O ports at 1458 [size=8]
I/O ports at 144c [size=4]
I/O ports at 1450 [size=8]
I/O ports at 1448 [size=4]
I/O ports at 1420 [size=16]
Memory at dd003000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 00
[Normal decode])
Flags: bus master, 66MHz, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 00002000-00002fff
Memory behind bridge: dd100000-deffffff
Prefetchable memory behind bridge: d0000000-d00fffff
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00
[Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
Capabilities: [40] Power Management version 2
Capabilities: [48] MSI: Enable- Count=1/2 Maskable- 64bit+
Capabilities: [58] HyperTransport: MSI Mapping Enable- Fixed-
Capabilities: [80] Express Root Port (Slot+), MSI 00
Kernel driver in use: pcieport
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
Flags: fast devsel
Capabilities: [80] HyperTransport: Host or Secondary Interface
Capabilities: [a0] HyperTransport: Host or Secondary Interface
Capabilities: [c0] HyperTransport: Host or Secondary Interface
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
Flags: fast devsel
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
Flags: fast devsel
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
Flags: fast devsel
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
Flags: fast devsel
Capabilities: [80] HyperTransport: Host or Secondary Interface
Capabilities: [a0] HyperTransport: Host or Secondary Interface
Capabilities: [c0] HyperTransport: Host or Secondary Interface
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
Flags: fast devsel
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
Flags: fast devsel
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
Flags: fast devsel
01:07.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
(prog-if 00 [VGA controller])
Subsystem: ATI Technologies Inc Rage XL
Flags: bus master, stepping, medium devsel, latency 66, IRQ 11
Memory at de000000 (32-bit, non-prefetchable) [size=16M]
I/O ports at 2000 [size=256]
Memory at dd100000 (32-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at d0000000 [disabled] [size=128K]
Capabilities: [5c] Power Management version 2
08:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev
12) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 64
Bus: primary=08, secondary=09, subordinate=09, sec-latency=64
I/O behind bridge: 00003000-00003fff
Memory behind bridge: df300000-df3fffff
Prefetchable memory behind bridge: 00000000df500000-00000000df5fffff
Capabilities: [a0] PCI-X bridge device
Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration
Capabilities: [c0] HyperTransport: Slave or Primary Interface
08:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
(prog-if 10 [IO-APIC])
Subsystem: Tyan Computer Device 2891
Flags: bus master, medium devsel, latency 0
Memory at df200000 (64-bit, non-prefetchable) [size=4K]
08:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev
12) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 64
Bus: primary=08, secondary=0a, subordinate=0a, sec-latency=64
Memory behind bridge: df400000-df4fffff
Capabilities: [a0] PCI-X bridge device
Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration
08:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
(prog-if 10 [IO-APIC])
Subsystem: Tyan Computer Device 2891
Flags: bus master, medium devsel, latency 0
Memory at df201000 (64-bit, non-prefetchable) [size=4K]
09:08.0 Fibre Channel: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X
HBA (rev 02)
Subsystem: Compaq Computer Corporation Device 0100
Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 24
I/O ports at 3000 [size=256]
Memory at df300000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at df500000 [disabled] [size=128K]
Capabilities: [44] Power Management version 2
Capabilities: [4c] PCI-X non-bridge device
Capabilities: [54] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [64] CompactPCI hot-swap <?>
Kernel driver in use: qla2xxx
0a:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
Ethernet (rev 03)
Subsystem: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 28
Memory at df410000 (64-bit, non-prefetchable) [size=64K]
Memory at df400000 (64-bit, non-prefetchable) [size=64K]
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
0a:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
Ethernet (rev 03)
Subsystem: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 29
Memory at df430000 (64-bit, non-prefetchable) [size=64K]
Memory at df420000 (64-bit, non-prefetchable) [size=64K]
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
# dmidecode 2.11
SMBIOS version fixup (2.33 -> 2.3).
SMBIOS 2.3 present.
34 structures occupying 1202 bytes.
Table at 0x7FFEF000.
Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
Vendor: Phoenix Technologies Ltd.
Version: 2003Q2
Release Date: 03/27/2006
Address: 0xE65B0
Runtime Size: 105040 bytes
ROM Size: 1024 kB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
EDD is supported
5.25"/360 kB floppy services are supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
Handle 0x0001, DMI type 1, 25 bytes
System Information
Manufacturer: TYAN Computer Corp
Product Name: S2891
Version: REFERENCE
Serial Number: 0123456789
UUID: Not Settable
Wake-up Type: Power Switch
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: TYAN Computer Corp
Product Name: GT24-B2891
Version: REFERENCE
Serial Number: 0123456789
Handle 0x0003, DMI type 3, 17 bytes
Chassis Information
Manufacturer: TYAN Computer Corp
Type: Main Server Chassis
Lock: Not Present
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Boot-up State: Unknown
Power Supply State: Unknown
Thermal State: Unknown
Security Status: Unknown
OEM Information: 0x00000000
Handle 0x0004, DMI type 4, 35 bytes
Processor Information
Socket Designation: CPU0-Socket 940
Type: Central Processor
Family: Opteron
Manufacturer: AMD
ID: 12 0F 02 00 FF FB 8B 17
Signature: Family 15, Model 33, Stepping 2
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
HTT (Multi-threading)
Version: AMD
Voltage: 1.2 V
External Clock: 200 MHz
Max Speed: 3000 MHz
Current Speed: 2000 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0006
L2 Cache Handle: 0x0007
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0005, DMI type 4, 35 bytes
Processor Information
Socket Designation: CPU1-Socket 940
Type: Central Processor
Family: Opteron
Manufacturer: AMD
ID: 12 0F 02 00 FF FB 8B 17
Signature: Family 15, Model 33, Stepping 2
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
HTT (Multi-threading)
Version: AMD
Voltage: 1.2 V
External Clock: 200 MHz
Max Speed: 3000 MHz
Current Speed: 2000 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0008
L2 Cache Handle: 0x0009
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0006, DMI type 7, 19 bytes
Cache Information
Socket Designation: H0 L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 64 kB
Maximum Size: 64 kB
Supported SRAM Types:
Burst
Pipeline Burst
Asynchronous
Installed SRAM Type: Asynchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unknown
Associativity: Unknown
Handle 0x0007, DMI type 7, 19 bytes
Cache Information
Socket Designation: H0 L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Through
Location: Internal
Installed Size: 2048 kB
Maximum Size: 1024 kB
Supported SRAM Types:
Burst
Pipeline Burst
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unified
Associativity: Unknown
Handle 0x0008, DMI type 7, 19 bytes
Cache Information
Socket Designation: H1 L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 64 kB
Maximum Size: 64 kB
Supported SRAM Types:
Burst
Pipeline Burst
Asynchronous
Installed SRAM Type: Asynchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unknown
Associativity: Unknown
Handle 0x0009, DMI type 7, 19 bytes
Cache Information
Socket Designation: H1 L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Through
Location: Internal
Installed Size: 2048 kB
Maximum Size: 1024 kB
Supported SRAM Types:
Burst
Pipeline Burst
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unified
Associativity: Unknown
Handle 0x000A, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2
Internal Connector Type: PS/2
External Reference Designator: PS/2 Mouse
External Connector Type: PS/2
Port Type: Mouse Port
Handle 0x000B, DMI type 9, 13 bytes
System Slot Information
Designation: PCI Slot 1
Type: 32-bit PCI
Current Usage: Unknown
Length: Long
ID: 0
Characteristics:
3.3 V is provided
PME signal is supported
Handle 0x000C, DMI type 11, 5 bytes
OEM Strings
String 1: 0
String 2: 0
String 3: .........................
Handle 0x000D, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 32 GB
Error Information Handle: Not Provided
Number Of Devices: 8
Handle 0x000E, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 1
Locator: C0_DIMM0
Bank Locator: Bank 0
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x000F, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 2
Locator: C0_DIMM1
Bank Locator: Bank 1
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0010, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 3
Locator: C0_DIMM2
Bank Locator: Bank 2
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0011, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 3
Locator: C0_DIMM3
Bank Locator: Bank 3
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0012, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 3
Locator: C0_DIMM0
Bank Locator: Bank 0
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0013, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 3
Locator: C1_DIMM1
Bank Locator: Bank 1
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0014, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: DIMM
Set: 3
Locator: C1_DIMM2
Bank Locator: Bank 2
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0015, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: DIMM
Set: 3
Locator: C1_DIMM3
Bank Locator: Bank 3
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0016, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x00BFFFFFFFF
Range Size: 48 GB
Physical Array Handle: 0x000D
Partition Width: 2
Handle 0x0017, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x001FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x000E
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x0018, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00200000000
Ending Address: 0x003FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x000F
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x0019, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00400000000
Ending Address: 0x005FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x0010
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001A, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00600000000
Ending Address: 0x007FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x0011
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001B, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00800000000
Ending Address: 0x009FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x0012
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001C, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00A00000000
Ending Address: 0x00BFFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x0013
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001D, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00BFFFFFC00
Ending Address: 0x00BFFFFFFFF
Range Size: 1 kB
Physical Device Handle: 0x0014
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001E, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00BFFFFFC00
Ending Address: 0x00BFFFFFFFF
Range Size: 1 kB
Physical Device Handle: 0x0015
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001F, DMI type 32, 20 bytes
System Boot Information
Status: <OUT OF SPEC>
Handle 0x0020, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA8 (I/O)
Register Spacing: 32-bit Boundaries
Interrupt Polarity: Active Low
Interrupt Trigger Mode: Edge
Handle 0x0021, DMI type 127, 4 bytes
End Of Table
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: Eric Dumazet @ 2011-10-01 6:44 UTC (permalink / raw)
To: starlight; +Cc: linux-kernel, netdev, Peter Zijlstra
In-Reply-To: <6.2.5.6.2.20111001012019.05c05b80@flumedata.com>
Le samedi 01 octobre 2011 à 01:30 -0400, starlight@binnacle.cx a écrit :
> Hello,
>
> I'm hoping someone can provide a brief big-picture
> perspective on the dramatic UDP/IP multicast
> receive performance reduction from 2.6.18 to
> 2.6.32 that I just benchmarked.
>
> Have helped out in the past, mainly by identifying
> a bug in hugepage handling and providing a solid
> testcase that helped in quickly identifying and
> correcting the problem.
>
> Have a very-high-volume UDP multicast receiver
> application. Just finished benchmarking latest RH
> variant of 2.6.18 against latest RH 2.6.32 and
> vanilla 2.6.32.27 on the same 12 core Opteron
> 6174 processor system, one CPU.
>
> Application reads on 250 sockets with large socket
> buffer maximums. Zero data loss. Four Intel
> 'e1000e' 82571 gigabit NICs, or two Intel 'igb'
> 82571 gigabit NICs or two Intel 82599 10 gigabit
> NICs. Results similar on all.
>
> With 2.6.18, system CPU is reported in
> /proc/<pid>/stat as 25% of total. With 2.6.32,
> system consumption is 45% with the same exact data
> playback test. Jiffy count for user CPU is same
> for both kernels, but .32 system CPU is double
> .18 system CPU.
>
> Overall maximum performance capacity is reduced in
> proportion to the increased system overhead.
>
> ------
>
> My question is why is the performance significantly
> worse in the more recent kernels? Apparently
> network performance is worse for TCP by about the
> same amount--double the system overhead for the
> same amount of work.
>
> http://www.phoronix.com/scan.php?page=article&item=linux_2612_2637&num=6
>
> Is there any chance that network performance will
> improve in future kernels? Or is the situation
> a permanent trade-off for security, reliability
> or scalability reasons?
>
CC netdev
Since you have 2.6.32, you could use perf tool and provide us a
performance report.
In my experience, I have the exact opposite : performance greatly
improved in recent kernels. Unless you compile your kernel to include
new features that might reduce performance (namespaces, cgroup, ...)
It can vary a lot depending on many parameters, like cpu affinities,
device parameters (coalescing, interrupt mitigation...).
You cant expect switching from 2.6.18 to 2.6.32 and have exactly same
system behavior.
If your app is performance sensitive, you'll have to make some analysis
to find out what needs to be tuned.
One known problem of old kernels and UDP is that they was no memory
accouting, so an application could easily consume all kernel memory and
crash the machine.
So in 2.6.25, Hideo Aoki added memory limiting to UDP, slowing down a
lot of UDP operations because of added socket locking, both on transmit
and receive path.
If your application is multithreaded and use a single socket, you can
hit lock contention since 2.6.25.
Step by step, we tried to remove part of the scalability problems
introduced in 2.6.25
In 2.6.35, we speedup receive path a bit (avoiding backlog processing)
In 2.6.39, transmit path became lockless again, thanks to Herbert Xu.
I advise you to try a recent kernel if you need UDP performance, 2.6.32
is quite old
Multicast is quite a stress for process scheduler, so we experimented a
way to group all wakeups at the end of softirq handler.
Work is in progress in this area : Peter Zijlstra named this "delayed
wakeup". A further idea would be to be able to delegate the wakeups to
another cpu, since I suspect you have one CPU busy in softirq
processing, and other cpus are ile.
^ permalink raw reply
* (unknown),
From: FEDEX OFFICE @ 2011-10-01 4:56 UTC (permalink / raw)
Attn: Beneficiary,
This is to inform you that your package worth the sum of $800,000.00 (Eight
Hundred Thousand United State Dollars) in a certified bank draft is in our
office ready for delivery,We are sending you this email because your package
has been registered on a Special Order.You are advise to contact our Delivery
Department for immediate dispatch of your package to your designated address.
Regards
Mr.Umar Tony {Head Dispatch Officer}
FedEx Express ®Courier Company West-Africa
E-mail:fedexdelivery1952@msn.com
Telephone Number:+234-70-65749930
---------------------------------------------------------------------------------
www.galiciaaberta.com
Información mantida pola Secretaría Xeral de Emigración da Xunta de Galicia
^ permalink raw reply
* Re: [RFC patch net-next-2.6] net: introduce ethernet teaming device
From: Jiri Pirko @ 2011-10-01 8:15 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, davem, eric.dumazet, bhutchings, fubar, andy, tgraf,
ebiederm, mirqus, kaber, greearb
In-Reply-To: <20110930092619.6b45087d@nehalam.linuxnetplumber.net>
Fri, Sep 30, 2011 at 06:26:19PM CEST, shemminger@vyatta.com wrote:
>On Fri, 30 Sep 2011 14:44:03 +0200
>Jiri Pirko <jpirko@redhat.com> wrote:
>
>> +static struct rtnl_link_stats64 *team_get_stats(struct net_device *dev,
>> + struct rtnl_link_stats64 *stats)
>> +{
>> + struct team *team = netdev_priv(dev);
>> + struct rtnl_link_stats64 temp;
>> + struct team_port *port;
>> +
>> + memset(stats, 0, sizeof(*stats));
>> +
>> + rcu_read_lock();
>> + list_for_each_entry_rcu(port, &team->port_list, list) {
>> + const struct rtnl_link_stats64 *pstats;
>
>You need to use u64_stats_sync macros to make this safe on 32 bit
>mode.
Well I'm doing this the same way it's done on several other place, as
for example bonding.
>
>Also, I am not sure about the handling of speed and duplex.
>There are people who do active backup with links of different speeds.
Yes, team can handle multiple ifaces with different speeds and duplexes.
Why would you think it cannot?
>
>The team device doesn't seem to handle hardware offload features
>as completely as it should. The TSO and transmit checksumming should
>be the union of the teamed ports.
>
Yeah, you are right here. I probably need something like
bond_compute_features() for team. Will add that.
Thank you Stephen.
Jirka
^ 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