* Re: [PATCH] Make sure sockets implement splice_read
From: Andi Kleen @ 2008-02-15 16:30 UTC (permalink / raw)
To: David Miller; +Cc: rdenis, netdev
In-Reply-To: <20080215.023601.219994317.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Rémi_Denis-Courmont <rdenis@simphalempin.com>
> Date: Thu, 14 Feb 2008 18:53:34 +0200
>
>> Fixes a segmentation fault when trying to splice from a non-TCP socket.
>>
>> Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>
>
> Applied, thank you.
That's also a stable candidate, isn't it?
-Andi
^ permalink raw reply
* Re: [PATCH 2.6.25] igb: fix legacy mode irq issue
From: Kok, Auke @ 2008-02-15 16:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andy Gospodarek, netdev, David S. Miller
In-Reply-To: <47B5B5BA.9020807@garzik.org>
Jeff Garzik wrote:
> Andy Gospodarek wrote:
>> I booted an igb kernel with the option pci=nomsi and instantly noticed
>> that interrupts no longer worked on my igb device. I took a look at the
>> interrupt initialization and quickly discovered a comment stating:
>>
>> "DO NOT USE EIAME or IAME in legacy mode"
>>
>> It seemed a bit odd that bits to enable IAM were being set in legacy
>> interrupt mode, so I dropped out the following parts and interrupts
>> began working fine again.
>>
>> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
>> ---
>>
>> igb_main.c | 3 ---
>> 1 files changed, 3 deletions(-)
>>
>> diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
>> index f3c144d..be5da09 100644
>> --- a/drivers/net/igb/igb_main.c
>> +++ b/drivers/net/igb/igb_main.c
>> @@ -472,9 +471,6 @@ static int igb_request_irq(struct igb_adapter
>> *adapter)
>> goto request_done;
>> }
>>
>> - /* enable IAM, auto-mask */
>> - wr32(E1000_IAM, IMS_ENABLE_MASK);
>> -
>
> ACK from Auke? (apologies if I missed it...)
you did not miss it yet :)
So, in principle this patch might leave interrupts enabled way too long.
Unfortunately the code to enable IAM is way too complex for upstream-fixes so I
don't want to push that into 2.6.25. I'm scrambling right now to figure out if
this patch doesn't create endless interrupts from the hardware.
Once I'm happy with that answer I'll push/ack it
Auke
^ permalink raw reply
* [git patches] net driver fixes
From: Jeff Garzik @ 2008-02-15 16:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, LKML
Process note: 'upstream-davem' continues the git history that began
the previous push. This sometimes happens when I continue to commit
locally, working in parallel while waiting for changes to hit Linus
upstream.
As current net-2.6.git appears to have the same commit ids that I
submitted in the previous push, this should be no problem at all,
just wanted you to know.
Please pull from 'upstream-davem' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem
to receive the following updates:
drivers/net/e1000/e1000_ethtool.c | 2 +-
drivers/net/e1000/e1000_main.c | 8 ++++
drivers/net/e1000e/netdev.c | 34 ++---------------
drivers/net/gianfar.c | 4 +-
drivers/net/gianfar_mii.c | 4 +-
drivers/net/hamradio/mkiss.c | 5 +--
drivers/net/igb/igb_ethtool.c | 2 +-
drivers/net/igb/igb_main.c | 28 --------------
drivers/net/ixgb/ixgb_ethtool.c | 2 +-
drivers/net/ixgbe/ixgbe_main.c | 41 +++++++++++++++++----
drivers/net/pcmcia/smc91c92_cs.c | 12 +++++-
drivers/net/tsi108_eth.c | 72 +++++++++++++++++++++++++-----------
12 files changed, 114 insertions(+), 100 deletions(-)
Al Viro (1):
gianfar iomem misannotations
Alex Bounine (5):
Tsi108_eth: add missing linking to driver data
Tsi108_eth: fix detection of 1000Mb mode
Tsi108_eth: remove not needed code
Tsi108_eth: fix link recovery after disconnect
Tsi108_eth: Add ethtool support
Auke Kok (7):
e1000: warn if this driver is used for e1000e devices
e1000e: Fix logic reversal keeping link active
ixgbe: warn when device is in a x4 or lower width slot
ixgbe: Disallow device reset during ethtool test
ixgbe: remove accidentally added #ifdef
e1000e: Fix CRC stripping in hardware context bug
ixgbe: Correctly obtain protocol information on transmit
Chuck Ebbert (1):
Fix station address detection in smc
David Graham (2):
igb: PCIe devices do not need to unset MANC_ARP_ENA
e1000e: PCIe devices do not need to unset MANC_ARP_ENA
Jarek Poplawski (1):
mkiss: ax_bump() locking fix
Julia Lawall (1):
replace code with FIELD_SIZEOF
diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index d876787..85e66f4 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -50,7 +50,7 @@ struct e1000_stats {
int stat_offset;
};
-#define E1000_STAT(m) sizeof(((struct e1000_adapter *)0)->m), \
+#define E1000_STAT(m) FIELD_SIZEOF(struct e1000_adapter, m), \
offsetof(struct e1000_adapter, m)
static const struct e1000_stats e1000_gstrings_stats[] = {
{ "rx_packets", E1000_STAT(stats.gprc) },
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index d4ee8ec..0991648 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1195,6 +1195,14 @@ e1000_probe(struct pci_dev *pdev,
printk("%s\n", print_mac(mac, netdev->dev_addr));
+ if (adapter->hw.bus_type == e1000_bus_type_pci_express) {
+ DPRINTK(PROBE, WARNING, "This device (id %04x:%04x) will no "
+ "longer be supported by this driver in the future.\n",
+ pdev->vendor, pdev->device);
+ DPRINTK(PROBE, WARNING, "please use the \"e1000e\" "
+ "driver instead.\n");
+ }
+
/* reset the hardware with the new settings */
e1000_reset(adapter);
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index f58f017..3031d6d 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1055,23 +1055,6 @@ static void e1000_release_hw_control(struct e1000_adapter *adapter)
}
}
-static void e1000_release_manageability(struct e1000_adapter *adapter)
-{
- if (adapter->flags & FLAG_MNG_PT_ENABLED) {
- struct e1000_hw *hw = &adapter->hw;
-
- u32 manc = er32(MANC);
-
- /* re-enable hardware interception of ARP */
- manc |= E1000_MANC_ARP_EN;
- manc &= ~E1000_MANC_EN_MNG2HOST;
-
- /* don't explicitly have to mess with MANC2H since
- * MANC has an enable disable that gates MANC2H */
- ew32(MANC, manc);
- }
-}
-
/**
* @e1000_alloc_ring - allocate memory for a ring structure
**/
@@ -1561,9 +1544,6 @@ static void e1000_init_manageability(struct e1000_adapter *adapter)
manc = er32(MANC);
- /* disable hardware interception of ARP */
- manc &= ~(E1000_MANC_ARP_EN);
-
/* enable receiving management packets to the host. this will probably
* generate destination unreachable messages from the host OS, but
* the packets will be handled on SMBUS */
@@ -1690,6 +1670,9 @@ static void e1000_setup_rctl(struct e1000_adapter *adapter)
else
rctl |= E1000_RCTL_LPE;
+ /* Enable hardware CRC frame stripping */
+ rctl |= E1000_RCTL_SECRC;
+
/* Setup buffer sizes */
rctl &= ~E1000_RCTL_SZ_4096;
rctl |= E1000_RCTL_BSEX;
@@ -1755,9 +1738,6 @@ static void e1000_setup_rctl(struct e1000_adapter *adapter)
/* Enable Packet split descriptors */
rctl |= E1000_RCTL_DTYP_PS;
-
- /* Enable hardware CRC frame stripping */
- rctl |= E1000_RCTL_SECRC;
psrctl |= adapter->rx_ps_bsize0 >>
E1000_PSRCTL_BSIZE0_SHIFT;
@@ -2008,7 +1988,7 @@ static void e1000_power_down_phy(struct e1000_adapter *adapter)
u16 mii_reg;
/* WoL is enabled */
- if (!adapter->wol)
+ if (adapter->wol)
return;
/* non-copper PHY? */
@@ -2140,8 +2120,6 @@ void e1000e_reset(struct e1000_adapter *adapter)
phy_data &= ~IGP02E1000_PM_SPD;
e1e_wphy(hw, IGP02E1000_PHY_POWER_MGMT, phy_data);
}
-
- e1000_release_manageability(adapter);
}
int e1000e_up(struct e1000_adapter *adapter)
@@ -3487,8 +3465,6 @@ static int e1000_suspend(struct pci_dev *pdev, pm_message_t state)
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- e1000_release_manageability(adapter);
-
/* make sure adapter isn't asleep if manageability is enabled */
if (adapter->flags & FLAG_MNG_PT_ENABLED) {
pci_enable_wake(pdev, PCI_D3hot, 1);
@@ -4054,8 +4030,6 @@ static void __devexit e1000_remove(struct pci_dev *pdev)
flush_scheduled_work();
- e1000_release_manageability(adapter);
-
/* Release control of h/w to f/w. If f/w is AMT enabled, this
* would have already happened in close and is redundant. */
e1000_release_hw_control(adapter);
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 0431e9e..4244fc2 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -130,8 +130,8 @@ static void free_skb_resources(struct gfar_private *priv);
static void gfar_set_multi(struct net_device *dev);
static void gfar_set_hash_for_addr(struct net_device *dev, u8 *addr);
static void gfar_configure_serdes(struct net_device *dev);
-extern int gfar_local_mdio_write(struct gfar_mii *regs, int mii_id, int regnum, u16 value);
-extern int gfar_local_mdio_read(struct gfar_mii *regs, int mii_id, int regnum);
+extern int gfar_local_mdio_write(struct gfar_mii __iomem *regs, int mii_id, int regnum, u16 value);
+extern int gfar_local_mdio_read(struct gfar_mii __iomem *regs, int mii_id, int regnum);
#ifdef CONFIG_GFAR_NAPI
static int gfar_poll(struct napi_struct *napi, int budget);
#endif
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index 6a647d9..2432762 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -51,7 +51,7 @@
* the local mdio pins, which may not be the same as system mdio bus, used for
* controlling the external PHYs, for example.
*/
-int gfar_local_mdio_write(struct gfar_mii *regs, int mii_id,
+int gfar_local_mdio_write(struct gfar_mii __iomem *regs, int mii_id,
int regnum, u16 value)
{
/* Set the PHY address and the register address we want to write */
@@ -77,7 +77,7 @@ int gfar_local_mdio_write(struct gfar_mii *regs, int mii_id,
* and are always tied to the local mdio pins, which may not be the
* same as system mdio bus, used for controlling the external PHYs, for eg.
*/
-int gfar_local_mdio_read(struct gfar_mii *regs, int mii_id, int regnum)
+int gfar_local_mdio_read(struct gfar_mii __iomem *regs, int mii_id, int regnum)
{
u16 value;
diff --git a/drivers/net/hamradio/mkiss.c b/drivers/net/hamradio/mkiss.c
index cfcd15a..30c9b3b 100644
--- a/drivers/net/hamradio/mkiss.c
+++ b/drivers/net/hamradio/mkiss.c
@@ -289,7 +289,6 @@ static void ax_bump(struct mkiss *ax)
*ax->rbuff &= ~0x20;
}
}
- spin_unlock_bh(&ax->buflock);
count = ax->rcount;
@@ -297,17 +296,17 @@ static void ax_bump(struct mkiss *ax)
printk(KERN_ERR "mkiss: %s: memory squeeze, dropping packet.\n",
ax->dev->name);
ax->stats.rx_dropped++;
+ spin_unlock_bh(&ax->buflock);
return;
}
- spin_lock_bh(&ax->buflock);
memcpy(skb_put(skb,count), ax->rbuff, count);
- spin_unlock_bh(&ax->buflock);
skb->protocol = ax25_type_trans(skb, ax->dev);
netif_rx(skb);
ax->dev->last_rx = jiffies;
ax->stats.rx_packets++;
ax->stats.rx_bytes += count;
+ spin_unlock_bh(&ax->buflock);
}
static void kiss_unesc(struct mkiss *ax, unsigned char s)
diff --git a/drivers/net/igb/igb_ethtool.c b/drivers/net/igb/igb_ethtool.c
index f69721e..0447f9b 100644
--- a/drivers/net/igb/igb_ethtool.c
+++ b/drivers/net/igb/igb_ethtool.c
@@ -43,7 +43,7 @@ struct igb_stats {
int stat_offset;
};
-#define IGB_STAT(m) sizeof(((struct igb_adapter *)0)->m), \
+#define IGB_STAT(m) FIELD_SIZEOF(struct igb_adapter, m), \
offsetof(struct igb_adapter, m)
static const struct igb_stats igb_gstrings_stats[] = {
{ "rx_packets", IGB_STAT(stats.gprc) },
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index d4eb8e2..bff280e 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -606,9 +606,6 @@ static void igb_init_manageability(struct igb_adapter *adapter)
u32 manc2h = rd32(E1000_MANC2H);
u32 manc = rd32(E1000_MANC);
- /* disable hardware interception of ARP */
- manc &= ~(E1000_MANC_ARP_EN);
-
/* enable receiving management packets to the host */
/* this will probably generate destination unreachable messages
* from the host OS, but the packets will be handled on SMBUS */
@@ -623,25 +620,6 @@ static void igb_init_manageability(struct igb_adapter *adapter)
}
}
-static void igb_release_manageability(struct igb_adapter *adapter)
-{
- struct e1000_hw *hw = &adapter->hw;
-
- if (adapter->en_mng_pt) {
- u32 manc = rd32(E1000_MANC);
-
- /* re-enable hardware interception of ARP */
- manc |= E1000_MANC_ARP_EN;
- manc &= ~E1000_MANC_EN_MNG2HOST;
-
- /* don't explicitly have to mess with MANC2H since
- * MANC has an enable disable that gates MANC2H */
-
- /* XXX stop the hardware watchdog ? */
- wr32(E1000_MANC, manc);
- }
-}
-
/**
* igb_configure - configure the hardware for RX and TX
* @adapter: private board structure
@@ -844,7 +822,6 @@ void igb_reset(struct igb_adapter *adapter)
igb_reset_adaptive(&adapter->hw);
adapter->hw.phy.ops.get_phy_info(&adapter->hw);
- igb_release_manageability(adapter);
}
/**
@@ -1178,9 +1155,6 @@ static void __devexit igb_remove(struct pci_dev *pdev)
flush_scheduled_work();
-
- igb_release_manageability(adapter);
-
/* Release control of h/w to f/w. If f/w is AMT enabled, this
* would have already happened in close and is redundant. */
igb_release_hw_control(adapter);
@@ -3955,8 +3929,6 @@ static int igb_suspend(struct pci_dev *pdev, pm_message_t state)
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- igb_release_manageability(adapter);
-
/* make sure adapter isn't asleep if manageability is enabled */
if (adapter->en_mng_pt) {
pci_enable_wake(pdev, PCI_D3hot, 1);
diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
index a267dd8..53a9fd0 100644
--- a/drivers/net/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ixgb/ixgb_ethtool.c
@@ -49,7 +49,7 @@ struct ixgb_stats {
int stat_offset;
};
-#define IXGB_STAT(m) sizeof(((struct ixgb_adapter *)0)->m), \
+#define IXGB_STAT(m) FIELD_SIZEOF(struct ixgb_adapter, m), \
offsetof(struct ixgb_adapter, m)
static struct ixgb_stats ixgb_gstrings_stats[] = {
{"rx_packets", IXGB_STAT(net_stats.rx_packets)},
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index ead49e5..23d0a4a 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -220,7 +220,6 @@ static bool ixgbe_clean_tx_irq(struct ixgbe_adapter *adapter,
tx_ring->stats.bytes += tx_buffer_info->length;
if (cleaned) {
struct sk_buff *skb = tx_buffer_info->skb;
-#ifdef NETIF_F_TSO
unsigned int segs, bytecount;
segs = skb_shinfo(skb)->gso_segs ?: 1;
/* multiply data chunks by size of headers */
@@ -228,10 +227,6 @@ static bool ixgbe_clean_tx_irq(struct ixgbe_adapter *adapter,
skb->len;
total_tx_packets += segs;
total_tx_bytes += bytecount;
-#else
- total_tx_packets++;
- total_tx_bytes += skb->len;
-#endif
}
ixgbe_unmap_and_free_tx_resource(adapter,
tx_buffer_info);
@@ -1942,6 +1937,10 @@ static int ixgbe_open(struct net_device *netdev)
int err;
u32 num_rx_queues = adapter->num_rx_queues;
+ /* disallow open during test */
+ if (test_bit(__IXGBE_TESTING, &adapter->state))
+ return -EBUSY;
+
try_intr_reinit:
/* allocate transmit descriptors */
err = ixgbe_setup_all_tx_resources(adapter);
@@ -2278,11 +2277,29 @@ static bool ixgbe_tx_csum(struct ixgbe_adapter *adapter,
IXGBE_ADVTXD_DTYP_CTXT);
if (skb->ip_summed == CHECKSUM_PARTIAL) {
- if (skb->protocol == htons(ETH_P_IP))
+ switch (skb->protocol) {
+ case __constant_htons(ETH_P_IP):
type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV4;
+ if (ip_hdr(skb)->protocol == IPPROTO_TCP)
+ type_tucmd_mlhl |=
+ IXGBE_ADVTXD_TUCMD_L4T_TCP;
+ break;
+
+ case __constant_htons(ETH_P_IPV6):
+ /* XXX what about other V6 headers?? */
+ if (ipv6_hdr(skb)->nexthdr == IPPROTO_TCP)
+ type_tucmd_mlhl |=
+ IXGBE_ADVTXD_TUCMD_L4T_TCP;
+ break;
- if (skb->sk->sk_protocol == IPPROTO_TCP)
- type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_TCP;
+ default:
+ if (unlikely(net_ratelimit())) {
+ DPRINTK(PROBE, WARNING,
+ "partial checksum but proto=%x!\n",
+ skb->protocol);
+ }
+ break;
+ }
}
context_desc->type_tucmd_mlhl = cpu_to_le32(type_tucmd_mlhl);
@@ -2778,6 +2795,14 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
hw->mac.type, hw->phy.type,
(part_num >> 8), (part_num & 0xff));
+ if (link_width <= IXGBE_PCI_LINK_WIDTH_4) {
+ dev_warn(&pdev->dev, "PCI-Express bandwidth available for "
+ "this card is not sufficient for optimal "
+ "performance.\n");
+ dev_warn(&pdev->dev, "For optimal performance a x8 "
+ "PCI-Express slot is required.\n");
+ }
+
/* reset the hardware with the new settings */
ixgbe_start_hw(hw);
diff --git a/drivers/net/pcmcia/smc91c92_cs.c b/drivers/net/pcmcia/smc91c92_cs.c
index f18eca9..250eb19 100644
--- a/drivers/net/pcmcia/smc91c92_cs.c
+++ b/drivers/net/pcmcia/smc91c92_cs.c
@@ -559,8 +559,16 @@ static int mhz_setup(struct pcmcia_device *link)
/* Read the station address from the CIS. It is stored as the last
(fourth) string in the Version 1 Version/ID tuple. */
- if (link->prod_id[3]) {
- station_addr = link->prod_id[3];
+ tuple->DesiredTuple = CISTPL_VERS_1;
+ if (first_tuple(link, tuple, parse) != CS_SUCCESS) {
+ rc = -1;
+ goto free_cfg_mem;
+ }
+ /* Ugh -- the EM1144 card has two VERS_1 tuples!?! */
+ if (next_tuple(link, tuple, parse) != CS_SUCCESS)
+ first_tuple(link, tuple, parse);
+ if (parse->version_1.ns > 3) {
+ station_addr = parse->version_1.str + parse->version_1.ofs[3];
if (cvt_ascii_address(dev, station_addr) == 0) {
rc = 0;
goto free_cfg_mem;
diff --git a/drivers/net/tsi108_eth.c b/drivers/net/tsi108_eth.c
index 35d15e8..6f33f84 100644
--- a/drivers/net/tsi108_eth.c
+++ b/drivers/net/tsi108_eth.c
@@ -36,6 +36,7 @@
#include <linux/net.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -297,18 +298,11 @@ static void tsi108_check_phy(struct net_device *dev)
u32 speed;
unsigned long flags;
- /* Do a dummy read, as for some reason the first read
- * after a link becomes up returns link down, even if
- * it's been a while since the link came up.
- */
-
spin_lock_irqsave(&phy_lock, flags);
if (!data->phy_ok)
goto out;
- tsi108_read_mii(data, MII_BMSR);
-
duplex = mii_check_media(&data->mii_if, netif_msg_link(data), data->init_media);
data->init_media = 0;
@@ -345,22 +339,21 @@ static void tsi108_check_phy(struct net_device *dev)
TSI_WRITE(TSI108_MAC_CFG2, mac_cfg2_reg);
TSI_WRITE(TSI108_EC_PORTCTRL, portctrl_reg);
+ }
- if (data->link_up == 0) {
- /* The manual says it can take 3-4 usecs for the speed change
- * to take effect.
- */
- udelay(5);
+ if (data->link_up == 0) {
+ /* The manual says it can take 3-4 usecs for the speed change
+ * to take effect.
+ */
+ udelay(5);
- spin_lock(&data->txlock);
- if (is_valid_ether_addr(dev->dev_addr) && data->txfree)
- netif_wake_queue(dev);
+ spin_lock(&data->txlock);
+ if (is_valid_ether_addr(dev->dev_addr) && data->txfree)
+ netif_wake_queue(dev);
- data->link_up = 1;
- spin_unlock(&data->txlock);
- }
+ data->link_up = 1;
+ spin_unlock(&data->txlock);
}
-
} else {
if (data->link_up == 1) {
netif_stop_queue(dev);
@@ -1274,12 +1267,11 @@ static void tsi108_init_phy(struct net_device *dev)
* PHY_STAT register before the link up status bit is set.
*/
- data->link_up = 1;
+ data->link_up = 0;
while (!((phyval = tsi108_read_mii(data, MII_BMSR)) &
BMSR_LSTATUS)) {
if (i++ > (MII_READ_DELAY / 10)) {
- data->link_up = 0;
break;
}
spin_unlock_irqrestore(&phy_lock, flags);
@@ -1287,6 +1279,7 @@ static void tsi108_init_phy(struct net_device *dev)
spin_lock_irqsave(&phy_lock, flags);
}
+ data->mii_if.supports_gmii = mii_check_gmii_support(&data->mii_if);
printk(KERN_DEBUG "PHY_STAT reg contains %08x\n", phyval);
data->phy_ok = 1;
data->init_media = 1;
@@ -1527,12 +1520,46 @@ static void tsi108_init_mac(struct net_device *dev)
TSI_WRITE(TSI108_EC_INTMASK, ~0);
}
+static int tsi108_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct tsi108_prv_data *data = netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ spin_lock_irqsave(&data->txlock, flags);
+ rc = mii_ethtool_gset(&data->mii_if, cmd);
+ spin_unlock_irqrestore(&data->txlock, flags);
+
+ return rc;
+}
+
+static int tsi108_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct tsi108_prv_data *data = netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ spin_lock_irqsave(&data->txlock, flags);
+ rc = mii_ethtool_sset(&data->mii_if, cmd);
+ spin_unlock_irqrestore(&data->txlock, flags);
+
+ return rc;
+}
+
static int tsi108_do_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct tsi108_prv_data *data = netdev_priv(dev);
+ if (!netif_running(dev))
+ return -EINVAL;
return generic_mii_ioctl(&data->mii_if, if_mii(rq), cmd, NULL);
}
+static const struct ethtool_ops tsi108_ethtool_ops = {
+ .get_link = ethtool_op_get_link,
+ .get_settings = tsi108_get_settings,
+ .set_settings = tsi108_set_settings,
+};
+
static int
tsi108_init_one(struct platform_device *pdev)
{
@@ -1584,7 +1611,6 @@ tsi108_init_one(struct platform_device *pdev)
data->mii_if.phy_id = einfo->phy;
data->mii_if.phy_id_mask = 0x1f;
data->mii_if.reg_num_mask = 0x1f;
- data->mii_if.supports_gmii = mii_check_gmii_support(&data->mii_if);
data->phy = einfo->phy;
data->phy_type = einfo->phy_type;
@@ -1598,6 +1624,7 @@ tsi108_init_one(struct platform_device *pdev)
dev->get_stats = tsi108_get_stats;
netif_napi_add(dev, &data->napi, tsi108_poll, 64);
dev->do_ioctl = tsi108_do_ioctl;
+ dev->ethtool_ops = &tsi108_ethtool_ops;
/* Apparently, the Linux networking code won't use scatter-gather
* if the hardware doesn't do checksums. However, it's faster
@@ -1629,6 +1656,7 @@ tsi108_init_one(struct platform_device *pdev)
goto register_fail;
}
+ platform_set_drvdata(pdev, dev);
printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
dev->name, print_mac(mac, dev->dev_addr));
#ifdef DEBUG
^ permalink raw reply related
* Re: Is netif_tx_lock() SMP PREEMPT safe?
From: Eric Dumazet @ 2008-02-15 16:01 UTC (permalink / raw)
To: Marin Mitov; +Cc: linux-kernel, netdev
In-Reply-To: <200802151725.05424.mitov@issp.bas.bg>
Marin Mitov a écrit :
> Hi all,
>
> As in: include/linux/netdevice.h (kernel-2.6.24.2) one finds:
>
> static inline void __netif_tx_lock(struct net_device *dev, int cpu)
> {
> spin_lock(&dev->_xmit_lock);
> dev->xmit_lock_owner = cpu;
> }
>
> static inline void netif_tx_lock(struct net_device *dev)
> {
> __netif_tx_lock(dev, smp_processor_id());
> }
>
> Does netif_tx_lock(struct net_device *dev) expands into:
>
> cpu = smp_processor_id();
> <preempt & shift to another cpu (bogus)>
> spin_lock(&dev->_xmit_lock);
> dev->xmit_lock_owner = cpu; /* cpu is not the lock owner */
>
> Or to:
>
> spin_lock(&dev->_xmit_lock);
> dev->xmit_lock_owner = smp_processor_id();
>
> which is correct?
>
>
Hi Marin
This expands to the first version, but netif_tx_lock() is allways called
with preemption disabled.
(Or checks in smp_processor_id() would just trigger)
Eric
(Cced netdev for network related stuff)
^ permalink raw reply
* Re: [PATCH 2.6.25] igb: fix legacy mode irq issue
From: Jeff Garzik @ 2008-02-15 15:54 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, Auke Kok, David S. Miller
In-Reply-To: <20080214031920.GI856@gospo.usersys.redhat.com>
Andy Gospodarek wrote:
> I booted an igb kernel with the option pci=nomsi and instantly noticed
> that interrupts no longer worked on my igb device. I took a look at the
> interrupt initialization and quickly discovered a comment stating:
>
> "DO NOT USE EIAME or IAME in legacy mode"
>
> It seemed a bit odd that bits to enable IAM were being set in legacy
> interrupt mode, so I dropped out the following parts and interrupts
> began working fine again.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> ---
>
> igb_main.c | 3 ---
> 1 files changed, 3 deletions(-)
>
> diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
> index f3c144d..be5da09 100644
> --- a/drivers/net/igb/igb_main.c
> +++ b/drivers/net/igb/igb_main.c
> @@ -472,9 +471,6 @@ static int igb_request_irq(struct igb_adapter *adapter)
> goto request_done;
> }
>
> - /* enable IAM, auto-mask */
> - wr32(E1000_IAM, IMS_ENABLE_MASK);
> -
ACK from Auke? (apologies if I missed it...)
^ permalink raw reply
* Re: [PATCH 2/2] e1000e: PCIe devices do not need to unset MANC_ARP_ENA
From: Jeff Garzik @ 2008-02-15 15:53 UTC (permalink / raw)
To: Auke Kok; +Cc: e1000-devel, netdev
In-Reply-To: <20080214181720.11070.43867.stgit@localhost.localdomain>
Auke Kok wrote:
> From: David Graham <david.graham@intel.com>
>
> Users reported that ARP's were lost with e1000e. The problem
> is fixed by not enabling this manageability configuration
> bit.
>
> None of the release_manageability code is actually needed as the
> normal device reset during a shutdown returns everthing to
> the right condition automatically.
>
> Signed-off-by: David Graham <david.graham@intel.com>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000e/netdev.c | 26 --------------------------
> 1 files changed, 0 insertions(+), 26 deletions(-)
applied 1-2
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [PATCH] ixgbe: Correctly obtain protocol information on transmit
From: Jeff Garzik @ 2008-02-15 15:53 UTC (permalink / raw)
To: Auke Kok; +Cc: e1000-devel, netdev, andy
In-Reply-To: <20080212232033.13861.17859.stgit@localhost.localdomain>
Auke Kok wrote:
> In reply to "RE: [Fwd: [PATCH 2.6.25] ixgbe/igb: correctly obtain protocol
> information on transmit]" from Andy Gospodarek:
>
> The driver was incorrectly looking at socket headers for
> protocol information, needed for checksumming offload. Fix
> this by not looking at the socket but frame headers instead.
>
> This disregards extension headers but it's unclear that linux
> generates those anyway.
>
> Tested by Andy Gospodarek.
>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
applied
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [PATCH] e1000e: Fix CRC stripping in hardware context bug
From: Jeff Garzik @ 2008-02-15 15:53 UTC (permalink / raw)
To: Auke Kok; +Cc: netdev, johan.andersson, andy, e1000-devel
In-Reply-To: <20080212232024.13842.10804.stgit@localhost.localdomain>
Auke Kok wrote:
> CRC stripping was only correctly enabled for packet split recieves
> which is used when receiving jumbo frames. Correctly enable SECRC
> also for normal buffer packet receives.
>
> Tested by Andy Gospodarek and Johan Andersson, see bugzilla #9940.
>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000e/netdev.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
applied
^ permalink raw reply
* Re: [patch] Fix station address detection in smc
From: Jeff Garzik @ 2008-02-15 15:53 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: Dominik Brodowski, linux-pcmcia, Netdev
In-Reply-To: <47B38F8F.6060408@redhat.com>
Chuck Ebbert wrote:
> Megahertz EM1144 PCMCIA ethernet adapter needs special handling
> because it has two VERS_1 tuples and the station address is in
> the second one. Conversion to generic handling of these fields
> broke it. Reverting that fixes the device.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=233255
>
> Thanks go to Jon Stanley for not giving up on this one until the
> problem was found.
>
> Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
>
> ---
>
> This was broken for over a year before the problem was found...
applied
^ permalink raw reply
* Re: [PATCH][AX25] mkiss: ax_bump() locking fix
From: Jeff Garzik @ 2008-02-15 15:53 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David Miller, Jann Traschewski, Ralf Baechle, netdev
In-Reply-To: <20080213111758.GA2867@ff.dom.local>
Jarek Poplawski wrote:
> Hi,
>
> This is unchanged patch previously sent here for testing.
> I think it should be applied.
>
> Thanks,
> Jarek P.
>
> ---------------->
>
> Subject: [PATCH][AX25] mkiss: ax_bump() locking fix
>
> According to one of OOPSes reported by Jann softirq can break
> while skb is prepared for netif_rx. The report isn't complete,
> so the real reason of the later bug could be different, but
> IMHO this locking break in ax_bump is unsafe and unnecessary.
>
> Reported-and-tested-by: Jann Traschewski <jann@gmx.de>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>
> ---
>
> drivers/net/hamradio/mkiss.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
applied
^ permalink raw reply
* Network namespace status
From: Daniel Lezcano @ 2008-02-15 15:31 UTC (permalink / raw)
To: Linux Netdev List
Cc: Stephen Hemminger, mathieu.lacage,
YOSHIFUJI Hideaki / 吉藤英明,
Linux Containers
I receive some emails about the current status of the network namespace.
I tried to synthesize this information and I uploaded it at:
http://lxc.sourceforge.net/network_status.php
I hope that can help.
-- Daniel
^ permalink raw reply
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Sergej Stepanov @ 2008-02-15 15:38 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, netdev, jgarzik
In-Reply-To: <200802151350.20627.laurentp@cse-semaphore.com>
Am Freitag, den 15.02.2008, 13:50 +0100 schrieb Laurent Pinchart:
> We're loosing the possibility of having MDC and MDIO on different ports. This
> is quite easy to fix for the non-CONFIG_PPC_CPM_NEW_BINDING case but I'm not
> familiar with OF bindings (yet) to fix the CONFIG_PPC_CPM_NEW_BINDING case.
>
for OF issue i had this for a paar month:
http://www.spinics.net/lists/netdev/msg45778.html
http://www.spinics.net/lists/netdev/msg47159.html
i'll be glad if it helps...
Regards
Sergej.
^ permalink raw reply
* Re: BUG/ spinlock lockup, 2.6.24
From: Bart Van Assche @ 2008-02-15 15:24 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev, linux-kernel
In-Reply-To: <20080215150044.M24489@visp.net.lb>
2008/2/15 Denys Fedoryshchenko <denys@visp.net.lb>:
> I have random crashes, at least once per week. It is very difficult to catch
> error message, and only recently i setup netconsole. Now i got crash, but
> there is no traceback and only single line came over netconsole, mentioned
> before.
Did you already run memtest ? You can run memtest by booting from the
Knoppix CD-ROM or DVD. Most Linux distributions also have included
memtest on their bootable distribution CD's/DVD's.
Bart Van Assche.
^ permalink raw reply
* BUG/ spinlock lockup, 2.6.24
From: Denys Fedoryshchenko @ 2008-02-15 15:19 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Server crashed(not responding over network), last line over netconsole was
Feb 15 15:50:17 217.151.X.X [1521315.068984] BUG: spinlock lockup on CPU#1,
ksoftirqd/1/7, f0551180
I have random crashes, at least once per week. It is very difficult to catch
error message, and only recently i setup netconsole. Now i got crash, but
there is no traceback and only single line came over netconsole, mentioned
before.
.config file
http://www.nuclearcat.com/files/config_qos
Kernel is 2.6.24 with epoll patch(it is from mainline) applied.
cat /proc/version
Linux version 2.6.24-devel (root@visp-1) (gcc version 4.1.1 (Gentoo 4.1.1-
r3)) #1 SMP Sat Jan 26 17:26:54 EET 2008
visp-1 ~ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 18361 17785 17471 17748 IO-APIC-edge timer
1: 2 0 0 0 IO-APIC-edge i8042
8: 5 4 3 4 IO-APIC-edge rtc
9: 0 0 0 0 IO-APIC-fasteoi acpi
12: 1 0 1 2 IO-APIC-edge i8042
14: 14 17 17 15 IO-APIC-edge libata
15: 0 0 0 0 IO-APIC-edge libata
17: 269 259 256 259 IO-APIC-fasteoi ioc0
18: 5 5 6 7 IO-APIC-fasteoi
ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4
19: 0 0 0 0 IO-APIC-fasteoi
uhci_hcd:usb3
66: 1 0 0 0 none-<NULL>
212: 27 32 35 32 PCI-MSI-edge eth1
213: 36818 36995 37307 37029 PCI-MSI-edge eth0
214: 0 1 1 1 PCI-MSI-edge
NMI: 71107 70983 70962 70962 Non-maskable interrupts
LOC: 53005 53178 53490 53214 Local timer interrupts
RES: 414 434 363 378 Rescheduling interrupts
CAL: 52 46 56 47 function call interrupts
TLB: 398 288 403 264 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
SPU: 0 0 0 0 Spurious interrupts
ERR: 0
MIS: 0
visp-1 ~ # cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.20GHz
stepping : 4
cpu MHz : 3192.163
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl vmx cid cx16 xtpr lahf_lm
bogomips : 6390.17
clflush size : 64
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.20GHz
stepping : 4
cpu MHz : 3192.163
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl vmx cid cx16 xtpr lahf_lm
bogomips : 6383.72
clflush size : 64
processor : 2
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.20GHz
stepping : 4
cpu MHz : 3192.163
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl vmx cid cx16 xtpr lahf_lm
bogomips : 6383.75
clflush size : 64
processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Xeon(TM) CPU 3.20GHz
stepping : 4
cpu MHz : 3192.163
cache size : 2048 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl vmx cid cx16 xtpr lahf_lm
bogomips : 6383.76
clflush size : 64
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Christoph Raisch @ 2008-02-15 13:22 UTC (permalink / raw)
To: Dave Hansen
Cc: apw, Greg KH, Jan-Bernd Themann, linux-kernel, linuxppc-dev,
netdev, ossthema, Badari Pulavarty, Thomas Q Klein, tklein
In-Reply-To: <1203009163.19205.42.camel@nimitz.home.sr71.net>
Dave Hansen <haveblue@us.ibm.com> wrote on 14.02.2008 18:12:43:
> On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
> > Dave Hansen <haveblue@us.ibm.com> wrote on 13.02.2008 18:05:00:
> > > On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> > > > Constraints imposed by HW / FW:
> > > > - eHEA has own MMU
> > > > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate
> > virtual
> > > > addresses to absolute addresses (like DMA mapped memory on a PCI
bus)
> > > > - The number of MRs is limited (not enough to have one MR per
packet)
> > >
> > > Are there enough to have one per 16MB section?
> >
> > Unfortunately this won't work. This was one of our first ideas we
tossed
> > out,
> > but the number of MRs will not be sufficient.
>
> Can you give a ballpark of how many there are to work with? 10? 100?
> 1000?
>
It depends on HMC configuration, but in worst case the upper limit is in
the 2 digits range.
> > > But, I'm really not convinced that you can actually keep this map
> > > yourselves. It's not as simple as you think. What happens if you
get
> > > on an LPAR with two sections, one 256MB@0x0 and another
> > > 16MB@0x1000000000000000. That's quite possible. I think your
vmalloc'd
> > > array will eat all of memory.
> > I'm glad you mention this part. There are many algorithms out there to
> > handle this problem,
> > hashes/trees/... all of these trade speed for smaller memory footprint.
> > We based the table decission on the existing implementations of the
> > architecture.
> > Do you see such a case coming along for the next generation POWER
systems?
>
> Dude. It exists *TODAY*. Go take a machine, add tens of gigabytes of
> memory to it. Then, remove all of the sections of memory in the middle.
> You'll be left with a very sparse memory configuration that we *DO*
> handle today in the core VM. We handle it quite well, actually.
>
> The hypervisor does not shrink memory from the top down. It pulls
> things out of the middle and shuffles things around. In fact, a NUMA
> node's memory isn't even contiguous.
>
> Your code will OOM the machine in this case. I consider the ehea driver
> buggy in this regard.
Your comment indicates that the upper limit for memory to be set on HMC
does not influence
the upper limit of the partition physical address space.
So our base assumption we discussed internally is wrong here.
(conclusion see below)
>
> > I would guess these drastic changes would also require changes in base
> > kernel.
>
> No, we actually solved those a couple years ago.
>
> > Will you provide a generic mapping system with a contiguous virtual
address
> > space
> > like the ehea_bmap we can query? This would need to be a "stable" part
of
> > the implementation,
> > including translation functions from kernel to
nextgen_ehea_generic_bmap
> > like virt_to_abs.
>
> Yes, that's a real possibility, especially if some other users for it
> come forward. We could definitely add something like that to the
> generic code. But, you'll have to be convincing that what we have now
> is insufficient.
>
> Does this requirement:
> "- MRs cover a contiguous virtual memory block (no holes)"
> come from the hardware?
>
yes
> Is that *EACH* MR? OR all MRs?
>
each
> Where does EHEA_BUSMAP_START come from? Is that defined in the
> hardware? Have you checked to ensure that no other users might want a
> chunk of memory in that area?
>
EHEA_BUSMAP_START is a value which has to match between the wqe
virtual addresses and the MR used in them.
Fortunately there's a simple answer on that one. Each MR has a own address
space,
so there's no need to check.
A HEA MR actually has exactly the same attributes as a Infiniband MR with
this hardware.
send/receive processing is pretty much comparable to a Infiniband UD queue.
> Can you query the existing MRs?
no
> Not change them in place, but can you
> query their contents?
no
>
> > > That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP
implemented
> > > in the core, so that we can deal with these kinds of problems, once
and
> > > *NOT* in every single little driver out there.
> > >
> > > > Functions to use while building ehea_bmap + MRs:
> > > > - Use either the functions that are used by the memory hotplug
system
> > as
> > > > well, that means using the section defines + functions
> > (section_nr_to_pfn,
> > > > pfn_valid)
> > >
> > > Basically, you can't use anything related to sections outside of the
> > > core code. You can use things like pfn_valid(), or you can create
new
> > > interfaces that are properly abstracted.
> >
> > We picked sections instead of PFNs because this keeps the ehea_bmap in
a
> > reasonable range
> > on the existing systems.
> > But if you provide a abstract method handling exactly the problem we
> > mention
> > we'll be happy to use that and dump our private implementation.
>
> One thing you can guarantee today is that things are contiguous up to
> MAX_ORDER_NR_PAGES. That's a symbol that is unlikely to change and is
> much more appropriate than using sparsemem. We could also give you a
> nice new #define like MINIMUM_CONTIGUOUS_PAGES or something. I think
> that's what you really want.
That's definitely the right direction.
>From this mail thread I would conclude....
memory space can have holes, and drivers shouldn't make any assumption when
where and how.
A translation from kernel to ehea_bmap space should be fast and predictable
(ruling out hashes).
If a driver doesn't know anything else about the mapping structure,
the normal solution in kernel for this type of problem is a multi level
look up table
like pgd->pud->pmd->pte
This doesn't sound right to be implemented in a device driver.
We didn't see from the existing code that such a mapping to a contiguous
space already exists.
Maybe we've missed it.
If the mapping is less random, the translation gets much simpler.
MAX_ORDER_NR_PAGES helps here, is there more like that?
Gruss / Regards
Christoph Raisch + Jan-Bernd Themann
^ permalink raw reply
* [PATCH] [XFRM] Add CONFIG_INET dependency to CONFIG_XFRM_STATISTICS
From: Johann Felix Soden @ 2008-02-15 15:08 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
From: Johann Felix Soden <johfel@users.sourceforge.net>
With INET=n and XFRM_STATISTICS=y I get the following build failure:
net/built-in.o: In function `xfrm_init':
(.init.text+0xcd7): undefined reference to `snmp_mib_init'
Signed-off-by: Johann Felix Soden <johfel@users.sourceforge.net>
CC: Masahide NAKAMURA <nakam@linux-ipv6.org>
---
net/xfrm/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index 8f9dbec..3bf2338 100644
--- a/net/xfrm/Kconfig
+++ b/net/xfrm/Kconfig
@@ -38,7 +38,7 @@ config XFRM_MIGRATE
config XFRM_STATISTICS
bool "Transformation statistics (EXPERIMENTAL)"
- depends on XFRM && PROC_FS && EXPERIMENTAL
+ depends on XFRM && PROC_FS && INET && EXPERIMENTAL
---help---
This statistics is not a SNMP/MIB specification but shows
statistics about transformation error (or almost error) factor
--
1.5.4.1
^ permalink raw reply related
* Re: tbench regression in 2.6.25-rc1
From: Eric Dumazet @ 2008-02-15 14:21 UTC (permalink / raw)
To: Zhang, Yanmin; +Cc: herbert, LKML, netdev
In-Reply-To: <1203057044.3027.134.camel@ymzhang>
Zhang, Yanmin a écrit :
> On Fri, 2008-02-15 at 07:05 +0100, Eric Dumazet wrote:
>
>> Zhang, Yanmin a �crit :
>>
>>> Comparing with kernel 2.6.24, tbench result has regression with
>>> 2.6.25-rc1.
>>>
>>> 1) On 2 quad-core processor stoakley: 4%.
>>> 2) On 4 quad-core processor tigerton: more than 30%.
>>>
>>> bisect located below patch.
>>>
>>> b4ce92775c2e7ff9cf79cca4e0a19c8c5fd6287b is first bad commit
>>> commit b4ce92775c2e7ff9cf79cca4e0a19c8c5fd6287b
>>> Author: Herbert Xu <herbert@gondor.apana.org.au>
>>> Date: Tue Nov 13 21:33:32 2007 -0800
>>>
>>> [IPV6]: Move nfheader_len into rt6_info
>>>
>>> The dst member nfheader_len is only used by IPv6. It's also currently
>>> creating a rather ugly alignment hole in struct dst. Therefore this patch
>>> moves it from there into struct rt6_info.
>>>
>>>
>>> As tbench uses ipv4, so the patch's real impact on ipv4 is it deletes
>>> nfheader_len in dst_entry. It might change cache line alignment.
>>>
>>> To verify my finding, I just added nfheader_len back to dst_entry in 2.6.25-rc1
>>> and reran tbench on the 2 machines. Performance could be recovered completely.
>>>
>>> I started cpu_number*2 tbench processes. On my 16-core tigerton:
>>> #./tbench_srv &
>>> #./tbench 32 127.0.0.1
>>>
>>> -yanmin
>>>
>> Yup. struct dst is sensitive to alignements, especially for benches.
>>
>> In the real world, we need to make sure that next pointer start at a cache
>> line bondary (or a litle bit after), so that RT cache lookups use one cache
>> line per entry instead of two. This permits better behavior in DDOS attacks.
>>
>> (check commit 1e19e02ca0c5e33ea73a25127dbe6c3b8fcaac4b for reference)
>>
>> Are you using a 64 or a 32 bit kernel ?
>>
> 64bit x86-64 machine. On another 4-way Madison Itanium machine, tbench has the
> similiar regression.
>
>
On linux-2.6.25-rc1 x86_64 :
offsetof(struct dst_entry, lastuse)=0xb0
offsetof(struct dst_entry, __refcnt)=0xb8
offsetof(struct dst_entry, __use)=0xbc
offsetof(struct dst_entry, next)=0xc0
So it should be optimal... I dont know why tbench prefers __refcnt being
on 0xc0, since in this case lastuse will be on a different cache line...
Each incoming IP packet will need to change lastuse, __refcnt and __use,
so keeping them in the same cache line is a win.
I suspect then that even this patch could help tbench, since it avoids
writing lastuse...
diff --git a/include/net/dst.h b/include/net/dst.h
index e3ac7d0..24d3c4e 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -147,7 +147,8 @@ static inline void dst_use(struct dst_entry *dst,
unsigned long time)
{
dst_hold(dst);
dst->__use++;
- dst->lastuse = time;
+ if (time != dst->lastuse)
+ dst->lastuse = time;
}
^ permalink raw reply related
* Re: [PATCH] add macro for printing mac addresses
From: Johannes Berg @ 2008-02-15 12:54 UTC (permalink / raw)
To: Bruno Randolf
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, jgarzik-e+AXbWqSrlAAvxtiuMwx3w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <20080215104804.9870.15722.stgit@one>
[-- Attachment #1: Type: text/plain, Size: 344 bytes --]
On Fri, 2008-02-15 at 19:48 +0900, Bruno Randolf wrote:
> is there any chance to include a macro like this for printing mac addresses?
>
> its advantage is that it can be used without the need to declare buffers for
> print_mac(), for example:
>
> printk("mac address: " MAC_FMT, MAC_ADDR(addr));
you want print_mac()
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 6/9] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Laurent Pinchart @ 2008-02-15 12:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, jgarzik, netdev
In-Reply-To: <20070920220121.GF28784@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
Hi Scott,
I apologize for bringing this after so much time. Hope the "better late than
never" motto applies.
On Friday 21 September 2007 00:01, Scott Wood wrote:
> The existing OF glue code was crufty and broken. Rather than fix it, it
> will be removed, and the ethernet driver now talks to the device tree
> directly.
>
> The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
> platforms are dropped from arch/ppc (which will hopefully be soon), and
> existing arch/powerpc boards that I wasn't able to test on for this
> patchset get converted (which should be even sooner).
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
[snip]
> diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
> index f8c7ee8..14ebba8 100644
> --- a/drivers/net/fs_enet/fs_enet.h
> +++ b/drivers/net/fs_enet/fs_enet.h
> @@ -24,19 +24,6 @@ struct fec_info {
> #include <asm/cpm2.h>
> #endif
>
> -/* This is used to operate with pins.
> - Note that the actual port size may
> - be different; cpm(s) handle it OK */
> -struct bb_info {
> - u8 mdio_dat_msk;
> - u8 mdio_dir_msk;
> - u8 *mdio_dir;
> - u8 *mdio_dat;
> - u8 mdc_msk;
> - u8 *mdc_dat;
> - int delay;
> -};
> -
[snip]
> diff --git a/drivers/net/fs_enet/mii-bitbang.c
> b/drivers/net/fs_enet/mii-bitbang.c index 8f766a5..2b9c44c 100644
> --- a/drivers/net/fs_enet/mii-bitbang.c
> +++ b/drivers/net/fs_enet/mii-bitbang.c
[snip]
> +struct bb_info {
> + __be32 __iomem *dir;
> + __be32 __iomem *dat;
> + u32 mdio_msk;
> + u32 mdc_msk;
> + int delay;
> +};
We're loosing the possibility of having MDC and MDIO on different ports. This
is quite easy to fix for the non-CONFIG_PPC_CPM_NEW_BINDING case but I'm not
familiar with OF bindings (yet) to fix the CONFIG_PPC_CPM_NEW_BINDING case.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] add macro for printing mac addresses
From: David Miller @ 2008-02-15 10:58 UTC (permalink / raw)
To: bruno; +Cc: netdev, jgarzik, linux-wireless, linville
In-Reply-To: <20080215104804.9870.15722.stgit@one>
From: Bruno Randolf <bruno@thinktube.com>
Date: Fri, 15 Feb 2008 19:48:05 +0900
> is there any chance to include a macro like this for printing mac addresses?
>
> its advantage is that it can be used without the need to declare buffers for
> print_mac(), for example:
>
> printk("mac address: " MAC_FMT, MAC_ADDR(addr));
>
> Signed-off-by: Bruno Randolf <bruno@thinktube.com>
We specifically removed this sort of thing, please don't
add it back.
Thank you.
^ permalink raw reply
* [PATCH] add macro for printing mac addresses
From: Bruno Randolf @ 2008-02-15 10:48 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: jgarzik-e+AXbWqSrlAAvxtiuMwx3w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
is there any chance to include a macro like this for printing mac addresses?
its advantage is that it can be used without the need to declare buffers for
print_mac(), for example:
printk("mac address: " MAC_FMT, MAC_ADDR(addr));
Signed-off-by: Bruno Randolf <bruno-L9ZBdB2wSWtl57MIdRCFDg@public.gmane.org>
---
include/linux/if_ether.h | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
index 5f92977..b9a6fb2 100644
--- a/include/linux/if_ether.h
+++ b/include/linux/if_ether.h
@@ -127,6 +127,15 @@ extern struct ctl_table ether_table[];
* Display a 6 byte device address (MAC) in a readable format.
*/
#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x"
+
+#define MAC_ADDR(addr) \
+ ((unsigned char *)(addr))[0], \
+ ((unsigned char *)(addr))[1], \
+ ((unsigned char *)(addr))[2], \
+ ((unsigned char *)(addr))[3], \
+ ((unsigned char *)(addr))[4], \
+ ((unsigned char *)(addr))[5]
+
extern char *print_mac(char *buf, const u8 *addr);
#define DECLARE_MAC_BUF(var) char var[18] __maybe_unused
^ permalink raw reply related
* Re: [IPV6]: Fix IPsec datagram fragmentation
From: Herbert Xu @ 2008-02-15 10:38 UTC (permalink / raw)
To: David Stevens; +Cc: Bill Fink, David Miller, kazunori, netdev, yoshfuji
In-Reply-To: <OF3737A582.CBFC60B5-ON882573F0.002BE602-882573F0.002C7307@us.ibm.com>
On Fri, Feb 15, 2008 at 12:05:32AM -0800, David Stevens wrote:
>
> For the future, maybe we should rename that, or reverse
> the sense of it (in v4 as well). :-)
Yeah it really should be called local_mayfrag.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Make sure sockets implement splice_read
From: David Miller @ 2008-02-15 10:36 UTC (permalink / raw)
To: rdenis; +Cc: netdev
In-Reply-To: <200802141853.35016.rdenis@simphalempin.com>
From: Rémi_Denis-Courmont <rdenis@simphalempin.com>
Date: Thu, 14 Feb 2008 18:53:34 +0200
> Fixes a segmentation fault when trying to splice from a non-TCP socket.
>
> Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>
Applied, thank you.
^ permalink raw reply
* [PATCH] plusb.c patched to support Belkin F5U258 USB host-to-host cable
From: tony_gibbs @ 2008-02-14 20:56 UTC (permalink / raw)
To: David Brownell; +Cc: NETDEV mailing list, Linux USB mailing list
Dear Dave,
I have tried to make the changes I have been working on and testing with
your help into a patch as attached.
Please let me know what you think of it.
Kind Regards,
Tony
---
Description: To make usbnet work with the Belkin F5U258 USB Host to Host
cable,
which contains Prolific PL-25A1 chip, the file plusb.c has been edited to
add the
VID and PID values for that cable.
The changes have been checked using the checkpatch.pl script.
The patch was tested on kernel 2.6.23.14 on Fedora Core 8, and on kernel
2.6.17.14 on Ubuntu Dapper Drake.
Signed-off-by: Tony Gibbs <tony_gibbs@compuserve.com>
--- /home/tony/drivers/net/usb/plusb.c 2008-02-12 23:02:01.000000000 +0000
+++
/usr/src/redhat/BUILD/kernel-2.6.23/linux-2.6.23.i386/drivers/net/usb/plusb
.c 2008-02-12 23:17:16.000000000 +0000
@@ -1,6 +1,7 @@
/*
* PL-2301/2302 USB host-to-host link cables
* Copyright (C) 2000-2005 by David Brownell
+ * PL-25A1 hack added by Tony Gibbs 07/02/2008.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -17,8 +18,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA
*/
-//#define DEBUG // error path messages, extra info
-//#define VERBOSE // more; success messages
+#define DEBUG // error path messages, extra info
+#define VERBOSE // more; success messages
#include <linux/module.h>
#include <linux/init.h>
@@ -46,6 +47,8 @@
* seems to get wedged under load. Prolific docs are weak, and
* don't identify differences between PL2301 and PL2302, much less
* anything to explain the different PL2302 versions observed.
+ *
+ * PL25A1 chip in Belkin F5U258 added.
*/
/*
@@ -96,7 +99,7 @@ static int pl_reset(struct usbnet *dev)
}
static const struct driver_info prolific_info = {
- .description = "Prolific PL-2301/PL-2302",
+ .description = "Prolific PL-2301/PL-2302_PL-25A1hack",
.flags = FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface()
*/
.reset = pl_reset,
@@ -118,7 +121,12 @@ static const struct usb_device_id produc
}, {
USB_DEVICE(0x067b, 0x0001), // PL-2302
.driver_info = (unsigned long) &prolific_info,
-},
+}, {
+ USB_DEVICE(0x050d, 0x258a), /*Belkin F5U258 cable containing
PL-25A1 chip.*/
+ /* TG hack 07/02/2008 */
+ .driver_info = (unsigned long) &prolific_info
+},
+
{ }, // END
};
MODULE_DEVICE_TABLE(usb, products);
@@ -145,5 +153,5 @@ static void __exit plusb_exit(void)
module_exit(plusb_exit);
MODULE_AUTHOR("David Brownell");
-MODULE_DESCRIPTION("Prolific PL-2301/2302 USB Host to Host Link Driver");
+MODULE_DESCRIPTION("Prolific PL-2301/2302 USB Host to Host Link Driver
with PL-25A1 TG hack");
MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH] netconsole: avoid null pointer dereference at show_local_mac()
From: David Miller @ 2008-02-15 10:02 UTC (permalink / raw)
To: k-keiichi; +Cc: mpm, satyam.sharma, linux-kernel, netdev, shemminger
In-Reply-To: <47B55F4C.5080703@bx.jp.nec.com>
From: Keiichi KII <k-keiichi@bx.jp.nec.com>
Date: Fri, 15 Feb 2008 18:45:48 +0900
> This patch avoids a null pointer dereference when we read local_mac
> for netconsole in configfs and shows default local mac address
> value.
>
> A null pointer dereference occurs when we call show_local_mac() via
> local_mac entry in configfs before we setup the content of netpoll
> using netpoll_setup().
>
> This patch is for 2.6.25-rc1.
> Your comments are very welcome.
>
> Signed-off-by: Keiichi KII <k-keiichi@bx.jp.nec.com>
Patch applied, thank you.
^ 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