[PATCH] ipw2200: add channels sysfs entry
Add 'channels' sysfs entry for ipw2200. The entry exports channels
information for the user space.
Signed-off-by: Zhu Yi [EMAIL PROTECTED]
--
diff -urp a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
--- a/drivers/net/wireless/ipw2200.c2007-02-05 17:40:23.0 +0800
+++ b/drivers/net/wireless/ipw2200.c2007-02-14 15:44:56.0 +0800
@@ -1847,6 +1847,52 @@ static ssize_t store_net_stats(struct de
static DEVICE_ATTR(net_stats, S_IWUSR | S_IRUGO,
show_net_stats, store_net_stats);
+static ssize_t show_channels(struct device *d,
+struct device_attribute *attr,
+char *buf)
+{
+ struct ipw_priv *priv = dev_get_drvdata(d);
+ const struct ieee80211_geo *geo = ipw_get_geo(priv-ieee);
+ int len = 0, i;
+
+ len = sprintf(buf[len],
+ Displaying %d channels in 2.4Ghz band
+ (802.11bg):\n, geo-bg_channels);
+
+ for (i = 0; i geo-bg_channels; i++) {
+ len += sprintf(buf[len], %d: BSS%s%s, %s, Band %s.\n,
+ geo-bg[i].channel,
+ geo-bg[i].flags IEEE80211_CH_RADAR_DETECT ?
+ (radar spectrum) : ,
+ ((geo-bg[i].flags IEEE80211_CH_NO_IBSS) ||
+ (geo-bg[i].flags IEEE80211_CH_RADAR_DETECT))
+ ? : , IBSS,
+ geo-bg[i].flags IEEE80211_CH_PASSIVE_ONLY ?
+ passive only : active/passive,
+ geo-bg[i].flags IEEE80211_CH_B_ONLY ?
+ B : B/G);
+ }
+
+ len += sprintf(buf[len],
+ Displaying %d channels in 5.2Ghz band
+ (802.11a):\n, geo-a_channels);
+ for (i = 0; i geo-a_channels; i++) {
+ len += sprintf(buf[len], %d: BSS%s%s, %s.\n,
+ geo-a[i].channel,
+ geo-a[i].flags IEEE80211_CH_RADAR_DETECT ?
+ (radar spectrum) : ,
+ ((geo-a[i].flags IEEE80211_CH_NO_IBSS) ||
+ (geo-a[i].flags IEEE80211_CH_RADAR_DETECT))
+ ? : , IBSS,
+ geo-a[i].flags IEEE80211_CH_PASSIVE_ONLY ?
+ passive only : active/passive);
+ }
+
+ return len;
+}
+
+static DEVICE_ATTR(channels, S_IRUSR, show_channels, NULL);
+
static void notify_wx_assoc_event(struct ipw_priv *priv)
{
union iwreq_data wrqu;
@@ -11383,6 +11383,7 @@ static struct attribute *ipw_sysfs_entri
dev_attr_led.attr,
dev_attr_speed_scan.attr,
dev_attr_net_stats.attr,
+ dev_attr_channels.attr,
#ifdef CONFIG_IPW2200_PROMISCUOUS
dev_attr_rtap_iface.attr,
dev_attr_rtap_filter.attr,
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][NET][BRIDGE] br_if: oops in port_carrier_check
On Tue, Feb 13, 2007 at 12:35:53PM -0800, David Miller wrote: ... I've applied this patch, thanks everyone. Stephen, do we want this in -stable? I got this info it went trough -mm too: ... From: [EMAIL PROTECTED] Subject: - br_if-oops-in-port_carrier_check.patch removed from -mm tree To: [EMAIL PROTECTED], mm-commits@vger.kernel.org ... The patch titled br_if: oops in port_carrier_check has been removed from the -mm tree. Its filename was br_if-oops-in-port_carrier_check.patch This patch was dropped because it was merged into mainline or a subsystem tree Regards, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] spidernet: load firmware when open
This moves calling init_firmware() from spider_net_probe() to
spider_net_open() so as to use the driver by built-in.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Linas Vepstas [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
--- org-linux-powerpc-git/drivers/net/spider_net.c 2007-02-14
12:13:38.0 +0900
+++ linux-powerpc-git/drivers/net/spider_net.c 2007-02-14 12:17:28.0
+0900
@@ -1727,6 +1727,124 @@
}
/**
+ * spider_net_download_firmware - loads firmware into the adapter
+ * @card: card structure
+ * @firmware_ptr: pointer to firmware data
+ *
+ * spider_net_download_firmware loads the firmware data into the
+ * adapter. It assumes the length etc. to be allright.
+ */
+static int
+spider_net_download_firmware(struct spider_net_card *card,
+const void *firmware_ptr)
+{
+ int sequencer, i;
+ const u32 *fw_ptr = firmware_ptr;
+
+ /* stop sequencers */
+ spider_net_write_reg(card, SPIDER_NET_GSINIT,
+SPIDER_NET_STOP_SEQ_VALUE);
+
+ for (sequencer = 0; sequencer SPIDER_NET_FIRMWARE_SEQS;
+sequencer++) {
+ spider_net_write_reg(card,
+SPIDER_NET_GSnPRGADR + sequencer * 8, 0);
+ for (i = 0; i SPIDER_NET_FIRMWARE_SEQWORDS; i++) {
+ spider_net_write_reg(card, SPIDER_NET_GSnPRGDAT +
+sequencer * 8, *fw_ptr);
+ fw_ptr++;
+ }
+ }
+
+ if (spider_net_read_reg(card, SPIDER_NET_GSINIT))
+ return -EIO;
+
+ spider_net_write_reg(card, SPIDER_NET_GSINIT,
+SPIDER_NET_RUN_SEQ_VALUE);
+
+ return 0;
+}
+
+/**
+ * spider_net_init_firmware - reads in firmware parts
+ * @card: card structure
+ *
+ * Returns 0 on success, 0 on failure
+ *
+ * spider_net_init_firmware opens the sequencer firmware and does some basic
+ * checks. This function opens and releases the firmware structure. A call
+ * to download the firmware is performed before the release.
+ *
+ * Firmware format
+ * ===
+ * spider_fw.bin is expected to be a file containing 6*1024*4 bytes, 4k being
+ * the program for each sequencer. Use the command
+ *tail -q -n +2 Seq_code1_0x088.txt Seq_code2_0x090.txt \
+ * Seq_code3_0x098.txt Seq_code4_0x0A0.txt Seq_code5_0x0A8.txt \
+ * Seq_code6_0x0B0.txt | xxd -r -p -c4 spider_fw.bin
+ *
+ * to generate spider_fw.bin, if you have sequencer programs with something
+ * like the following contents for each sequencer:
+ *ONE LINE COMMENT
+ *FIRST 4-BYTES-WORD FOR SEQUENCER
+ *SECOND 4-BYTES-WORD FOR SEQUENCER
+ * ...
+ *1024th 4-BYTES-WORD FOR SEQUENCER
+ */
+static int
+spider_net_init_firmware(struct spider_net_card *card)
+{
+ struct firmware *firmware = NULL;
+ struct device_node *dn;
+ const u8 *fw_prop = NULL;
+ int err = -ENOENT;
+ int fw_size;
+
+ if (request_firmware((const struct firmware **)firmware,
+SPIDER_NET_FIRMWARE_NAME, card-pdev-dev) == 0) {
+ if ( (firmware-size != SPIDER_NET_FIRMWARE_LEN)
+netif_msg_probe(card) ) {
+ pr_err(Incorrect size of spidernet firmware in \
+ filesystem. Looking in host firmware...\n);
+ goto try_host_fw;
+ }
+ err = spider_net_download_firmware(card, firmware-data);
+
+ release_firmware(firmware);
+ if (err)
+ goto try_host_fw;
+
+ goto done;
+ }
+
+try_host_fw:
+ dn = pci_device_to_OF_node(card-pdev);
+ if (!dn)
+ goto out_err;
+
+ fw_prop = get_property(dn, firmware, fw_size);
+ if (!fw_prop)
+ goto out_err;
+
+ if ( (fw_size != SPIDER_NET_FIRMWARE_LEN)
+netif_msg_probe(card) ) {
+ pr_err(Incorrect size of spidernet firmware in \
+ host firmware\n);
+ goto done;
+ }
+
+ err = spider_net_download_firmware(card, fw_prop);
+
+done:
+ return err;
+out_err:
+ if (netif_msg_probe(card))
+ pr_err(Couldn't find spidernet firmware in filesystem \
+ or host firmware\n);
+ return err;
+}
+
+/**
* spider_net_open - called upon ifonfig up
* @netdev: interface device structure
*
@@ -1741,6 +1859,10 @@
struct spider_net_card *card = netdev_priv(netdev);
int result;
+ result = spider_net_init_firmware(card);
+ if (result)
+ goto init_firmware_failed;
+
/* start probing with copper */
spider_net_setup_aneg(card);
if (card-phy.def-phy_id)
@@ -1784,6 +1906,7 @@
spider_net_free_chain(card, card-tx_chain);
[PATCH 3/4] spidernet: spidernet: add support for Celleb
This adds or changes some HW specific settings for spider_net on Celleb. Signed-off-by: Kou Ishizaki [EMAIL PROTECTED] Acked-by: Linas Vepstas [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- --- org-linux-powerpc-git/drivers/net/Kconfig 2007-02-14 13:33:09.0 +0900 +++ linux-powerpc-git/drivers/net/Kconfig 2007-02-14 13:33:17.0 +0900 @@ -2243,7 +2243,7 @@ config SPIDER_NET tristate Spider Gigabit Ethernet driver - depends on PCI PPC_IBM_CELL_BLADE + depends on PCI (PPC_IBM_CELL_BLADE || PPC_CELLEB) select FW_LOADER help This driver supports the Gigabit Ethernet chips present on the --- org-linux-powerpc-git/drivers/net/spider_net.h 2007-02-14 12:13:44.0 +0900 +++ linux-powerpc-git/drivers/net/spider_net.h 2007-02-14 13:31:22.0 +0900 @@ -1,7 +1,8 @@ /* - * Network device driver for Cell Processor-Based Blade + * Network device driver for Cell Processor-Based Blade and Celleb platform * * (C) Copyright IBM Corp. 2005 + * (C) Copyright 2006 TOSHIBA CORPORATION * * Authors : Utz Bacher [EMAIL PROTECTED] * Jens Osterkamp [EMAIL PROTECTED] @@ -184,7 +185,8 @@ /* pause frames: automatic, no upper retransmission count */ /* outside loopback mode: ETOMOD signal dont matter, not connected */ -#define SPIDER_NET_OPMODE_VALUE0x0063 +/* ETOMOD signal is brought to PHY reset. bit 2 must be 1 in Celleb */ +#define SPIDER_NET_OPMODE_VALUE0x0067 /*#define SPIDER_NET_OPMODE_VALUE 0x001b0062*/ #define SPIDER_NET_LENLMT_VALUE0x0908 --- org-linux-powerpc-git/drivers/net/spider_net.c 2007-02-14 12:19:28.0 +0900 +++ linux-powerpc-git/drivers/net/spider_net.c 2007-02-14 13:31:22.0 +0900 @@ -1,7 +1,8 @@ /* - * Network device driver for Cell Processor-Based Blade + * Network device driver for Cell Processor-Based Blade and Celleb platform * * (C) Copyright IBM Corp. 2005 + * (C) Copyright 2006 TOSHIBA CORPORATION * * Authors : Utz Bacher [EMAIL PROTECTED] * Jens Osterkamp [EMAIL PROTECTED] @@ -1627,6 +1628,11 @@ spider_net_write_reg(card, SPIDER_NET_CKRCTRL, SPIDER_NET_CKRCTRL_RUN_VALUE); + + /* trigger ETOMOD signal */ + spider_net_write_reg(card, SPIDER_NET_GMACOPEMD, + spider_net_read_reg(card, SPIDER_NET_GMACOPEMD) | 0x4); + } /** - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] spidernet: remove txram full logging
This removes logging for SPIDER_NET_GTMFLLINT interrupts.
Since the interrupts are not irregular, and they happen frequently
when using 100Mbps network switches.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Linas Vepstas [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
--- org-linux-powerpc-git/drivers/net/spider_net.c 2007-02-14
13:35:20.0 +0900
+++ linux-powerpc-git/drivers/net/spider_net.c 2007-02-14 13:36:01.0
+0900
@@ -1444,8 +1444,8 @@
switch (i)
{
case SPIDER_NET_GTMFLLINT:
- if (netif_msg_intr(card) net_ratelimit())
- pr_err(Spider TX RAM full\n);
+ /* TX RAM full may happen on a usual case.
+* Logging is not needed. */
show_error = 0;
break;
case SPIDER_NET_GRFDFLLINT: /* fallthrough */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] spidernet: support for Celleb
Jeff-san, This is a revised patch set for spider_net to work on Celleb. This patch set is based on Jens-san's v3 phy patch and Linas-san's spider_net patch. Please apply our patch set with them. Note: You need not apply Jens-san's spidernet patch because our patch set includes it. Best regards, Kou Ishizaki - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] spidernet: autoneg support for Celleb
Add auto negotiation support for Celleb.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Acked-by: Linas Vepstas [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
--- org-linux-powerpc-git/drivers/net/spider_net.h 2007-02-14
11:56:03.0 +0900
+++ linux-powerpc-git/drivers/net/spider_net.h 2007-02-14 12:05:11.0
+0900
@@ -50,6 +50,8 @@
#define SPIDER_NET_TX_DESCRIPTORS_MAX 512
#define SPIDER_NET_TX_TIMER(HZ/5)
+#define SPIDER_NET_ANEG_TIMER (HZ)
+#define SPIDER_NET_ANEG_TIMEOUT2
#define SPIDER_NET_RX_CSUM_DEFAULT 1
@@ -104,6 +106,7 @@
#define SPIDER_NET_GMACOPEMD 0x0100
#define SPIDER_NET_GMACLENLMT 0x0108
+#define SPIDER_NET_GMACST 0x0110
#define SPIDER_NET_GMACINTEN 0x0118
#define SPIDER_NET_GMACPHYCTRL 0x0120
@@ -333,9 +336,12 @@
/* We rely on flagged descriptor interrupts */
#define SPIDER_NET_RXINT ( (1 SPIDER_NET_GDAFDCINT) )
+#define SPIDER_NET_LINKINT ( 1 SPIDER_NET_GMAC2INT )
+
#define SPIDER_NET_ERRINT ( 0x \
(~SPIDER_NET_TXINT) \
- (~SPIDER_NET_RXINT) )
+ (~SPIDER_NET_RXINT) \
+ (~SPIDER_NET_LINKINT) )
#define SPIDER_NET_GPREXEC 0x8000
#define SPIDER_NET_GPRDAT_MASK 0x
@@ -439,12 +445,16 @@
struct pci_dev *pdev;
struct mii_phy phy;
+ int medium;
+
void __iomem *regs;
struct spider_net_descr_chain tx_chain;
struct spider_net_descr_chain rx_chain;
struct spider_net_descr *low_watermark;
+ int aneg_count;
+ struct timer_list aneg_timer;
struct timer_list tx_timer;
struct work_struct tx_timeout_task;
atomic_t tx_timeout_task_counter;
--- org-linux-powerpc-git/drivers/net/spider_net.c 2007-02-14
11:55:57.0 +0900
+++ linux-powerpc-git/drivers/net/spider_net.c 2007-02-14 12:09:06.0
+0900
@@ -165,6 +165,38 @@
return readvalue;
}
+/** spider_net_setup_aneg - initial auto-negotiation setup
+ * @card: device structure
+ **/
+static void
+spider_net_setup_aneg(struct spider_net_card *card)
+{
+ struct mii_phy *phy = card-phy;
+ u32 advertise = 0;
+ u16 bmsr, estat;
+
+ bmsr = spider_net_read_phy(card-netdev, phy-mii_id, MII_BMSR);
+ estat= spider_net_read_phy(card-netdev, phy-mii_id, MII_ESTATUS);
+
+ if (bmsr BMSR_10HALF)
+ advertise |= ADVERTISED_10baseT_Half;
+ if (bmsr BMSR_10FULL)
+ advertise |= ADVERTISED_10baseT_Full;
+ if (bmsr BMSR_100HALF)
+ advertise |= ADVERTISED_100baseT_Half;
+ if (bmsr BMSR_100FULL)
+ advertise |= ADVERTISED_100baseT_Full;
+
+ if ((bmsr BMSR_ESTATEN) (estat ESTATUS_1000_TFULL))
+ advertise |= SUPPORTED_1000baseT_Full;
+ if ((bmsr BMSR_ESTATEN) (estat ESTATUS_1000_THALF))
+ advertise |= SUPPORTED_1000baseT_Half;
+
+ mii_phy_probe(phy, phy-mii_id);
+ phy-def-ops-setup_aneg(phy, advertise);
+
+}
+
/**
* spider_net_rx_irq_off - switch off rx irq on this spider card
* @card: device structure
@@ -1273,6 +1305,33 @@
}
/**
+ * spider_net_link_reset
+ * @netdev: net device structure
+ *
+ * This is called when the PHY_LINK signal is asserted. For the blade this is
+ * not connected so we should never get here.
+ *
+ */
+static void
+spider_net_link_reset(struct net_device *netdev)
+{
+
+ struct spider_net_card *card = netdev_priv(netdev);
+
+ del_timer_sync(card-aneg_timer);
+
+ /* clear interrupt, block further interrupts */
+ spider_net_write_reg(card, SPIDER_NET_GMACST,
+spider_net_read_reg(card, SPIDER_NET_GMACST));
+ spider_net_write_reg(card, SPIDER_NET_GMACINTEN, 0);
+
+ /* reset phy and setup aneg */
+ spider_net_setup_aneg(card);
+ mod_timer(card-aneg_timer, jiffies + SPIDER_NET_ANEG_TIMER);
+
+}
+
+/**
* spider_net_handle_error_irq - handles errors raised by an interrupt
* @card: card structure
* @status_reg: interrupt status register 0 (GHIINT0STS)
@@ -1525,6 +1584,9 @@
if (status_reg SPIDER_NET_TXINT)
netif_rx_schedule(netdev);
+ if (status_reg SPIDER_NET_LINKINT)
+ spider_net_link_reset(netdev);
+
if (status_reg SPIDER_NET_ERRINT )
spider_net_handle_error_irq(card, status_reg);
@@ -1649,8 +1711,6 @@
spider_net_write_reg(card, SPIDER_NET_GMACLENLMT,
SPIDER_NET_LENLMT_VALUE);
- spider_net_write_reg(card, SPIDER_NET_GMACMODE,
-SPIDER_NET_MACMODE_VALUE);
spider_net_write_reg(card, SPIDER_NET_GMACOPEMD,
[patch 0/2] natsemi: Support Aculab E1/T1 cPCI carrier cards
These patches add support for the Aculab E1/T1 cPCI carrier card to the natsemi driver. The first patch provides support for using the MII port with no PHY and the second adds the quirk required to configure the card. -- You grabbed my hand and we fell into it, like a daydream - or a fever. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/2] natsemi: Support Aculab E1/T1 PMXc cPCI carrier cards
Aculab E1/T1 PMXc cPCI carrier card cards present a natsemi on the cPCI
bus with an oversized EEPROM using a direct MII-MII connection with no
PHY. This patch adds a new device table entry supporting these cards.
Signed-Off-By: Mark Brown [EMAIL PROTECTED]
Index: linux/drivers/net/natsemi.c
===
--- linux.orig/drivers/net/natsemi.c2007-02-12 18:09:44.0 +
+++ linux/drivers/net/natsemi.c 2007-02-12 18:09:59.0 +
@@ -244,6 +244,9 @@
MII_EN_SCRM = 0x0004, /* enable scrambler (tp) */
};
+enum {
+ NATSEMI_FLAG_IGNORE_PHY = 0x1,
+};
/* array of board data directly indexed by pci_tbl[x].driver_data */
static const struct {
@@ -251,10 +254,12 @@
unsigned long flags;
unsigned int eeprom_size;
} natsemi_pci_info[] __devinitdata = {
+ { Aculab E1/T1 PMXc cPCI carrier card, NATSEMI_FLAG_IGNORE_PHY, 128 },
{ NatSemi DP8381[56], 0, 24 },
};
static const struct pci_device_id natsemi_pci_tbl[] __devinitdata = {
+ { PCI_VENDOR_ID_NS, 0x0020, 0x12d9, 0x000c, 0, 0, 0 },
{ PCI_VENDOR_ID_NS, 0x0020, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ } /* terminate list */
};
@@ -811,7 +816,11 @@
np-hands_off = 0;
np-intr_status = 0;
np-eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
- np-ignore_phy = 0;
+ if (natsemi_pci_info[chip_idx].flags NATSEMI_FLAG_IGNORE_PHY) {
+ np-ignore_phy = 1;
+ } else {
+ np-ignore_phy = 0;
+ }
/* Initial port:
* - If configured to ignore the PHY set up for external.
--
You grabbed my hand and we fell into it, like a daydream - or a fever.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20 crash in tcp_tso_segment()
Herbert Xu writes:
[NETFILTER]: Clear GSO bits for TCP reset packet
The TCP reset packet is copied from the original. This
includes all the GSO bits which do not apply to the new
packet. So we should clear those bits.
Spotted by Patrick McHardy.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Something like this is needed for all trees with GSO.
Actually it applies to TSO too although the effect there
is a bit harder to notice.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.
c
index a9eb363..80f739e 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -80,6 +80,10 @@ static void send_reset(struct sk_buff *oldskb, int hook)
nskb-mark = 0;
skb_init_secmark(nskb);
+ skb_shinfo(nskb)-gso_size = 0;
+ skb_shinfo(nskb)-gso_segs = 0;
+ skb_shinfo(nskb)-gso_type = 0;
+
tcph = (struct tcphdr *)((u_int32_t*)nskb-nh.iph + nskb-nh.iph-ihl);
/* Swap source and dest */
I picked up this patch and we ran the overnight stress tests that had been
experiencing this problem against it. No problems so far, which based on
past results probably means the problem has indeed been fixed. Thank you!
--
Mike Accetta
ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] IPv6 Updates
Dave,
Please consider pulling the following changesets available on the
2.6.20-net-2.6-20070214-FOR_DAVEM
branch at
git://git.linux-ipv6.org/gitroot/yoshfuji/linux-2.6-dev.git
(on top of commit 928ba4169dc1d82c83105831f5ddb5472379b440).
Thank you.
HEADLINES
-
[IPV6] ADDRCONF: Manage prefix route corresponding to address manually
added.
[IPV6] IP6TUNNEL: Use update_pmtu() of dst on xmit.
[IPV6] IP6TUNNEL: Split out generic rutine in ip6ip6_err().
[IPV6] IP6TUNNEL: Split out generic rutine in ip6ip6_rcv().
[IPV6] IP6TUNNEL: Split out generic rutine in ip6ip6_xmit().
[IPV6] IP6TUNNEL: Add support to IPv4 over IPv6 tunnel.
[IPV6] IP6TUNNEL: Rename functions ip6ip6_* to ip6_tnl_*.
[IPV6] IP6TUNNEL: Enable to control the handled inner protocol.
[IPV6] ADDRCONF: Register inet6_dev earlier.
DIFFSTAT
net/ipv6/addrconf.c | 30 ++
net/ipv6/ip6_tunnel.c | 630 +++--
2 files changed, 478 insertions(+), 182 deletions(-)
CHANGESETS
--
commit bda786c68d05984f5d4a1812d3ebd2290d5bea57
Author: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Thu Feb 15 01:09:10 2007 +0900
[IPV6] ADDRCONF: Manage prefix route corresponding to address manually
added.
It is more natural to manage prefix routes corresponding to address which is
being added manually.
With help from Masafumi Aramoto [EMAIL PROTECTED].
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index ea0755b..c6683ea 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1911,6 +1911,7 @@ static int inet6_addr_add(int ifindex, struct in6_addr
*pfx, int plen,
struct inet6_dev *idev;
struct net_device *dev;
int scope;
+ u32 flags = RTF_EXPIRES;
ASSERT_RTNL();
@@ -1926,9 +1927,10 @@ static int inet6_addr_add(int ifindex, struct in6_addr
*pfx, int plen,
scope = ipv6_addr_scope(pfx);
- if (valid_lft == INFINITY_LIFE_TIME)
+ if (valid_lft == INFINITY_LIFE_TIME) {
ifa_flags |= IFA_F_PERMANENT;
- else if (valid_lft = 0x7FFF/HZ)
+ flags = 0;
+ } else if (valid_lft = 0x7FFF/HZ)
valid_lft = 0x7FFF/HZ;
if (prefered_lft == 0)
@@ -1946,6 +1948,8 @@ static int inet6_addr_add(int ifindex, struct in6_addr
*pfx, int plen,
ifp-tstamp = jiffies;
spin_unlock_bh(ifp-lock);
+ addrconf_prefix_route(ifp-addr, ifp-prefix_len, dev,
+ jiffies_to_clock_t(valid_lft * HZ),
flags);
addrconf_dad_start(ifp, 0);
in6_ifa_put(ifp);
addrconf_verify(0);
@@ -2125,6 +2129,7 @@ static void addrconf_add_linklocal(struct inet6_dev
*idev, struct in6_addr *addr
ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, IFA_F_PERMANENT);
if (!IS_ERR(ifp)) {
+ addrconf_prefix_route(ifp-addr, ifp-prefix_len, idev-dev,
0, 0);
addrconf_dad_start(ifp, 0);
in6_ifa_put(ifp);
}
@@ -2539,10 +2544,6 @@ static void addrconf_dad_start(struct inet6_ifaddr *ifp,
u32 flags)
addrconf_join_solict(dev, ifp-addr);
- if (ifp-prefix_len != 128 (ifp-flagsIFA_F_PERMANENT))
- addrconf_prefix_route(ifp-addr, ifp-prefix_len, dev, 0,
- flags);
-
net_srandom(ifp-addr.s6_addr32[3]);
read_lock_bh(idev-lock);
@@ -2973,12 +2974,15 @@ inet6_rtm_deladdr(struct sk_buff *skb, struct nlmsghdr
*nlh, void *arg)
static int inet6_addr_modify(struct inet6_ifaddr *ifp, u8 ifa_flags,
u32 prefered_lft, u32 valid_lft)
{
+ u32 flags = RTF_EXPIRES;
+
if (!valid_lft || (prefered_lft valid_lft))
return -EINVAL;
- if (valid_lft == INFINITY_LIFE_TIME)
+ if (valid_lft == INFINITY_LIFE_TIME) {
ifa_flags |= IFA_F_PERMANENT;
- else if (valid_lft = 0x7FFF/HZ)
+ flags = 0;
+ } else if (valid_lft = 0x7FFF/HZ)
valid_lft = 0x7FFF/HZ;
if (prefered_lft == 0)
@@ -2997,6 +3001,8 @@ static int inet6_addr_modify(struct inet6_ifaddr *ifp, u8
ifa_flags,
if (!(ifp-flagsIFA_F_TENTATIVE))
ipv6_ifa_notify(0, ifp);
+ addrconf_prefix_route(ifp-addr, ifp-prefix_len, ifp-idev-dev,
+ jiffies_to_clock_t(valid_lft * HZ), flags);
addrconf_verify(0);
return 0;
---
commit b5ea2d4352fab08edd0cbceb280c15c764063f0d
Author: Yasuyuki Kozakai [EMAIL PROTECTED]
Date: Thu Feb 15 01:09:11 2007 +0900
[IPV6] IP6TUNNEL: Use update_pmtu() of dst on xmit.
Signed-off-by: Yasuyuki Kozakai [EMAIL PROTECTED]
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6
Fw: [Bugme-new] [Bug 8009] New: PPPoE+mppe Server fail with Win Client
Begin forwarded message: Date: Wed, 14 Feb 2007 02:30:59 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 8009] New: PPPoE+mppe Server fail with Win Client http://bugzilla.kernel.org/show_bug.cgi?id=8009 Summary: PPPoE+mppe Server fail with Win Client Kernel Version: linux-2.6.18 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: - Distribution: Gentoo Hardware Environment: i386 Software Environment: ppp-2.4.4 + rp-pppoe-3.8 /etc/ppp/options: name PPPoE-R noipdefault ipcp-accept-local ipcp-accept-remote debug lock auth local crtscts asyncmap 0 mru 1480 mtu 1480 nobsdcomp nodetach lcp-echo-interval 30 lcp-echo-failure 4 lcp-max-configure 60 lcp-restart 2 idle 600 noipx ms-dns 212.216.112.112 ms-dns 192.168.3.39 logfile /var/log/ppp/pppoe.log refuse-pap refuse-chap refuse-mschap require-mschap-v2 lcp-echo-interval 10 lcp-echo-failure 2 require-mppe mppe-stateful plugin rp-pppoe.so plugin radius.so Problem Description: When i try to connect with linux i have no problem (but it use mppe stateless). When i try to connect with WindowsXP Client i need mppe-stateful or it fail at set up time, then when i use this settings i get this log: Connect time 0.0 minutes. Sent 84 bytes, received 120 bytes. Modem hangup Plugin rp-pppoe.so loaded. RP-PPPoE plugin version 3.3 compiled against pppd 2.4.4 Plugin radius.so loaded. RADIUS plugin initialized. Plugin /etc/ppp/plugins/rp-pppoe.so loaded. RP-PPPoE plugin version 3.3 compiled against pppd 2.4.4 using channel 93 Using interface ppp0 Connect: ppp0 -- eth0 sent [LCP ConfReq id=0x1 mru 1480 auth chap MS-v2 magic 0xf80e0eee] rcvd [LCP ConfReq id=0x0 mru 1480 magic 0x44c81073 callback CBCP] sent [LCP ConfRej id=0x0 callback CBCP] rcvd [LCP ConfAck id=0x1 mru 1480 auth chap MS-v2 magic 0xf80e0eee] rcvd [LCP ConfReq id=0x1 mru 1480 magic 0x44c81073] sent [LCP ConfAck id=0x1 mru 1480 magic 0x44c81073] sent [LCP EchoReq id=0x0 magic=0xf80e0eee] sent [CHAP Challenge id=0xaf 9834fec3e3953b0dd6437afa94d5c64f, name = PPPoE-R] rcvd [LCP Ident id=0x2 magic=0x44c81073 MSRASV5.10] rcvd [LCP Ident id=0x3 magic=0x44c81073 MSRAS-0-HTS91-PORTMS] rcvd [LCP EchoRep id=0x0 magic=0x44c81073] rcvd [CHAP Response id=0xaf 439bafda9a64ee5abc796eb04697e399b5f6b8a8559ef7aec1498c543cf8559bc65598f91ed96aa100, name = t2OyoEA9] sent [CHAP Success id=0xaf S=5A7D3E7B78F49C15F25B3D54570E2B67AAB7704F] peer from calling number 00:17:08:32:F5:0A authorized sent [CCP ConfReq id=0x1 mppe +H -M +S +L -D -C] rcvd [CCP ConfReq id=0x4 mppe -H -M +S -L -D +C] sent [CCP ConfNak id=0x4 mppe -H -M +S -L -D -C] rcvd [IPCP ConfReq id=0x5 compress VJ 0f 01 addr 0.0.0.0 ms-dns1 0.0.0.0 ms-wins 0.0.0.0 ms-dns3 0.0.0.0 ms-wins 0.0.0.0] sent [IPCP TermAck id=0x5] rcvd [CCP ConfNak id=0x1 mppe -H -M +S -L -D -C] sent [CCP ConfReq id=0x2 mppe -H -M +S -L -D -C] rcvd [CCP ConfReq id=0x6 mppe -H -M +S -L -D -C] sent [CCP ConfAck id=0x6 mppe -H -M +S -L -D -C] rcvd [CCP ConfAck id=0x2 mppe -H -M +S -L -D -C] MPPE 128-bit stateful compression enabled sent [IPCP ConfReq id=0x1 addr 10.0.0.1] rcvd [IPCP ConfAck id=0x1 addr 10.0.0.1] rcvd [IPCP ConfReq id=0x7 compress VJ 0f 01 addr 0.0.0.0 ms-dns1 0.0.0.0 ms-wins 0.0.0.0 ms-dns3 0.0.0.0 ms-wins 0.0.0.0] sent [IPCP ConfRej id=0x7 compress VJ 0f 01 ms-wins 0.0.0.0 ms-wins 0.0.0.0] rcvd [IPCP ConfReq id=0x8 addr 0.0.0.0 ms-dns1 0.0.0.0 ms-dns3 0.0.0.0] sent [IPCP ConfNak id=0x8 addr 10.67.7.5 ms-dns1 212.216.112.112 ms-dns3 192.168.3.39] rcvd [IPCP ConfReq id=0x9 addr 10.67.7.5 ms-dns1 212.216.112.112 ms-dns3 192.168.3.39] sent [IPCP ConfAck id=0x9 addr 10.67.7.5 ms-dns1 212.216.112.112 ms-dns3 192.168.3.39] local IP address 10.0.0.1 remote IP address 10.67.7.5 Script /etc/ppp/ip-up started (pid 5510) Script /etc/ppp/ip-up finished (pid 5510), status = 0x1 rcvd [proto=0xe17] 45 10 ae 8b 70 45 f3 45 76 21 78 23 79 1e 6a d8 eb e7 6d 2a 5b 1a cc 9c b4 6a 41 11 4b 06 9a 4b ... Unsupported protocol 0xe17 received sent [LCP ProtRej id=0x2 0e 17 45 10 ae 8b 70 45 f3 45 76 21 78 23 79 1e 6a d8 eb e7 6d 2a 5b 1a cc 9c b4 6a 41 11 4b 06 ...] rcvd [proto=0x89] 7e d8 50 1f 9f 65 e3 95 f1 39 de 49 dc 30 3c fd 70 7a 46 88 d5 3f 62 03 88 90 76 ec c9 d9 88 bd ... Unsupported protocol 0x89 received sent [LCP ProtRej id=0x3 00 89 7e d8 50 1f 9f 65 e3 95 f1 39 de 49 dc 30 3c fd 70 7a 46 88 d5 3f 62 03 88 90 76 ec c9 d9 ...] rcvd [proto=0x4f] bb 69 33 41 2f 71 c8 09 f2 14 fe f6 29 45 66 8b dc df 6a b2 79 6d d8 66 49 d7 c6 82 07 ec 9a 99 ... Unsupported protocol 'IP6 Header Compression' (0x4f) received sent [LCP ProtRej id=0x4 00 4f bb 69 33 41 2f 71 c8 09 f2 14 fe f6 29 45 66 8b dc df 6a b2 79 6d d8 66 49 d7 c6 82 07 ec ...] rcvd [proto=0x5045] c0 e5 fb 71 5b fc 71 c4 42 63 12 43 10 93 23 48 7a da fc 52 a2 53 c2 71 2d a8 ba 67 13 72 32 27 ... Unsupported protocol 0x5045 received sent [LCP ProtRej id=0x5 50 45
Fw: Problem with 2.6.20 and hostap_cs (Netgear MA401)
Begin forwarded message: Date: Wed, 14 Feb 2007 11:59:00 -0500 From: David G Hamblen [EMAIL PROTECTED] To: Kernel mailing list linux-kernel@vger.kernel.org Subject: Problem with 2.6.20 and hostap_cs (Netgear MA401) I've got the ieee80211 and hostap code compiled as modules for my MA401 card, and the system locks up when I insert the card. No keyboard, no sysrq, no logs after reboot, no nothing. The same configuration works fine under 2.6.19. If I first insert my old 3com 3c589 card, then eject it and rmmod the 3c589_cs module, the insertion of the MA401 works completely. Preloading the modules with insmod or modprobe doesn't help. Was there a change in the pcmcia or networking initialization code between 2.6.19 and 2.6.20? Here are the relevant modules. #/sbin/lsmod Module Size Used by ieee80211_crypt_wep 5248 0 hostap_cs 59220 3 hostap110852 1 hostap_cs ieee80211_crypt 5632 2 ieee80211_crypt_wep,hostap ... pcmcia 29280 1 hostap_cs firmware_class 9664 1 pcmcia yenta_socket 26892 4 ... rsrc_nonstatic 13248 1 yenta_socket pcmcia_core39056 4 \ hostap_cs,pcmcia,yenta_socket,rsrc_nonstatic - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] IPv6 Updates
Hi Yoshifuji-san
I have a question:
YOSHIFUJI Hideaki / 吉藤英明 wrote:
commit bd292ad1ccbf15c72351f79d4a130dd50da81613
Author: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Thu Feb 15 02:07:27 2007 +0900
[IPV6] ADDRCONF: Register inet6_dev earlier.
Allocate inet6_dev earlier to allow users to set up per-interface variables.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index c6683ea..42b5cc5 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2246,6 +2246,14 @@ static int addrconf_notify(struct notifier_block *this,
unsigned long event,
int run_pending = 0;
switch(event) {
+ case NETDEV_REGISTER:
+ if (!idev) {
+ idev = ipv6_add_dev(dev);
+ if (!idev)
+ printk(KERN_WARNING IPv6: add_dev failed for
%s\n,
+ dev-name);
+ }
+ break;
case NETDEV_UP:
case NETDEV_CHANGE:
if (event == NETDEV_UP) {
In this case, ipv6_add_dev will join the all-nodes multicast group on
the interface that may be still down. Is that an issue at all?
It seems that this operation would be better performed when the
interface is marked up?
Thanks
-vlad
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] IPv6 Updates
YOSHIFUJI Hideaki / 吉藤英明 wrote:
commit bd292ad1ccbf15c72351f79d4a130dd50da81613
Author: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Date: Thu Feb 15 02:07:27 2007 +0900
[IPV6] ADDRCONF: Register inet6_dev earlier.
Allocate inet6_dev earlier to allow users to set up per-interface
variables.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index c6683ea..42b5cc5 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2246,6 +2246,14 @@ static int addrconf_notify(struct notifier_block
*this, unsigned long event,
int run_pending = 0;
switch(event) {
+ case NETDEV_REGISTER:
+ if (!idev) {
+ idev = ipv6_add_dev(dev);
+ if (!idev)
+ printk(KERN_WARNING IPv6: add_dev failed for
%s\n,
+ dev-name);
+ }
+ break;
case NETDEV_UP:
case NETDEV_CHANGE:
if (event == NETDEV_UP) {
---
Many thanks. Now if only IPv4 would be fixed in similar fashion as well.
Also, this reminds me related issue - ADDRCONF(NETDEV_UP): ifname: link
is not ready and ADDRCONF(NETDEV_CHANGE): ifname: link becomes ready
messages. While it may look informational, it's extremely annoying in
systems with hundreds and even thousands vlan interfaces.
regards,
--
Hasso Tepper
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Convert network devices to use struct device instead of class_device
On Wed, Feb 14, 2007 at 12:40:00AM -0600, Kumar Gala wrote: Convert network devices to use struct device instead of class_device. Greg missed this one in his cleanup path. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Jeff, Sorry my mailer was completely screwed. I thought I had fixed the settings to turn of flowed text. I think this was why the patches I've been sending haven't been applying. You can also get this fix from the following git tree: master.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git gfar I will probably pull it, but I've away at a fs/storage conference so things are backed up this week. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] spidernet: support for Celleb
Jeff, I think we are all in agreement about this patch set, please commit. --linas On Wed, Feb 14, 2007 at 04:51:07PM +0900, Ishizaki Kou wrote: We also need Linas-san's patch set which includes bug-fix and makes the code compilable etc. But our previous patch set conflicts with Linas-san's patch set. ! Sorry. I thought I tried it both ways, and although the line numbers would be off, I don't remember any outright patch conflicts. I thought I'd gottoen lucky, guess not. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007
On Fri, 2007-02-09 at 14:55 -0500, Joseph Jezak wrote: Well, here's the problem. There are a few places where a value is changed (different value written to a register). Does this mean that the value is different due to the uCode changes (can't tell, no documentation)? From what I've seen in the ucode that question isn't really too hard to answer: as long as it's not in the shared memory or ucode register space the ucode can't really have an influence. Is it applicable to all revisions (can't tell, some revisions are not supported in this version)? Best bet would be to make it conditional right now and have someone test for these cases with older hw. If the revision number range in a check changes is that because of a difference in supported cards or a bug fix? Hmm. Same I guess, use the new check for new hw and the old check for old hw, i.e. assume it's the former and not a bug fix (until tested otherwise.) I think our best bet is to treat the older hw the same as the older driver does. A bigger problem, IMO, is that we'd have to support all the older microcode things which is a bit tricky since things in shm have moved a lot... Maybe we should find a third maintainer who has access to a couple of old cards :) johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007
On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote: It's likely that old cards still work with v4 firmware, No, it's absolutely impossible. Rev 2/4 cores have a totally different instruction set in the microcode. johannes signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] IPv6 Updates
Hasso Tepper [EMAIL PROTECTED] wrote:
Many thanks. Now if only IPv4 would be fixed in similar fashion as well.
Here you go.
[IPV4] devinet: Register inetdev earlier.
This patch allocates inetdev at registration for all devices
in line with IPv6. This allows sysctl configuration on the
devices to occur before they're brought up or addresses are
added.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index ba5e7f4..3a4497c 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1055,12 +1055,14 @@ static int inetdev_event(struct notifier_block *this,
unsigned long event,
ASSERT_RTNL();
if (!in_dev) {
- if (event == NETDEV_REGISTER dev == loopback_dev) {
+ if (event == NETDEV_REGISTER) {
in_dev = inetdev_init(dev);
if (!in_dev)
panic(devinet: Failed to create loopback\n);
- in_dev-cnf.no_xfrm = 1;
- in_dev-cnf.no_policy = 1;
+ if (dev == loopback_dev) {
+ in_dev-cnf.no_xfrm = 1;
+ in_dev-cnf.no_policy = 1;
+ }
}
goto out;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: deadlock in 2.6.18.2 related to bridging?
On Tue, 13 Feb 2007 17:23:05 -0800 Ben Greear [EMAIL PROTECTED] wrote: I think I may have found a deadlock bug in 2.6.18.2. This is with my hacked kernel, but my binary module has not been loaded. I have several bridges configured, including some containing my redirect-device virtual devices and ethernet devices. I believe the deadlock is this: The work-queue process is calling this, and is blocked on rtnl: [c0337ede] __mutex_lock_slowpath+0xbe/0x2a0 [c03380dc] mutex_lock+0x1c/0x20 [c02dd1db] __rtnl_lock+0x1b/0x40 [df909dc2] port_carrier_check+0x22/0xa0 [bridge] [c012d21b] run_workqueue+0x7b/0x100 [c012d9cf] worker_thread+0x10f/0x130 [c01304b5] kthread+0xd5/0xe0 [c0101005] kernel_thread_helper+0x5/0x10 It is waiting for the other function to finish (in this case the ioctl). But, the 'ip' program already has rtnl (acquired in devinet_ioctl), and is trying to flush the work-queue: ipD D9C34000 6600 2780 2775 (NOTLB) d9c35e1c 0046 deeebae8 d9c34000 c010327f 0001 d9c34000 0260 deeeba80 0001 d9c542b0 e548f009 001a 00020224 d9c543c0 007b 007b 00335517 deeeba80 deeebae8 0053 d9c35e44 c012d30b Call Trace: [c012d30b] flush_cpu_workqueue+0x6b/0xb0 [c012d388] flush_workqueue+0x38/0x50 [c012d3fd] flush_scheduled_work+0xd/0x10 [df819665] rtl8139_close+0x165/0x1a0 [8139too] [c02d4bd4] dev_close+0x54/0x70 [c02d3e31] dev_change_flags+0x51/0x110 [c0314e90] devinet_ioctl+0x4b0/0x6a0 [c031579b] inet_ioctl+0x6b/0x80 [c02c9627] sock_ioctl+0x77/0x250 [c017e1f8] do_ioctl+0x28/0x80 [c017e2a7] vfs_ioctl+0x57/0x2b0 [c017e539] sys_ioctl+0x39/0x60 [c01031ad] sysenter_past_esp+0x56/0x99 [b7fd5410] 0xb7fd5410 The bug is in r8139too.c driver. It calls flush_scheduled_work with RTNL mutex held, so any other work using it will get stuck. Has this been fixed in later releases? No but a different race (with device removal) has been fixed. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: deadlock in 2.6.18.2 related to bridging?
Stephen Hemminger wrote:
The bug is in r8139too.c driver. It calls flush_scheduled_work
with RTNL mutex held, so any other work using it will get stuck.
It looks like a fairly common problem, as tg3 has the same issue
(though it seems someone tried to hack around one particular case):
static int tg3_close(struct net_device *dev)
{
struct tg3 *tp = netdev_priv(dev);
/* Calling flush_scheduled_work() may deadlock because
* linkwatch_event() may be on the workqueue and it will try to get
* the rtnl_lock which we are holding.
*/
while (tp-tg3_flags TG3_FLAG_IN_RESET_TASK)
msleep(1);
netif_stop_queue(dev);
e1000 appears clean, at least, but there are a lot of other
drivers that are calling that method (I didn't check to see
if they might be holding rtnl when called.)
Thanks,
Ben
Has this been fixed in later releases?
No but a different race (with device removal) has been fixed.
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] RTNL and flush_scheduled_work deadlocks
Ben found this but the problem seems pretty widespread. The following places are subject to deadlock between flush_scheduled_work and the RTNL mutex. What can happen is that a work queue routine (like bridge port_carrier_check) is waiting forever for RTNL, and the driver routine has called flush_scheduled_work with RTNL held and is waiting for the work queue to clear. Several other places have comments like: can't call flush_scheduled_work here or it will deadlock. Most of the problem places are in device close routine. My recommendation would be to add a check for device netif_running in what ever work routine is used, and move the flush_scheduled_work to the remove routine. 8139too.c: rtl8139_close -- rtl8139_stop_thread r8169.c: rtl8169_down cassini.c: cas_change_mtu iseries_veth.c: veth_stop_connection s2io.c: s2io_close sis190.c: sis190_down - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] RTNL and flush_scheduled_work deadlocks
Stephen Hemminger wrote: Ben found this but the problem seems pretty widespread. The following places are subject to deadlock between flush_scheduled_work and the RTNL mutex. What can happen is that a work queue routine (like bridge port_carrier_check) is waiting forever for RTNL, and the driver routine has called flush_scheduled_work with RTNL held and is waiting for the work queue to clear. Several other places have comments like: can't call flush_scheduled_work here or it will deadlock. Most of the problem places are in device close routine. My recommendation would be to add a check for device netif_running in what ever work routine is used, and move the flush_scheduled_work to the remove routine. I seem to be able to trigger this within about 1 minute on a particular 2.6.18.2 system with some 8139too devices, so if someone has a patch that could be tested, I'll gladly test it. For whatever reason, I haven't hit this problem on 2.6.20 yet, but that could easily be dumb luck, and I haven't been running .20 very much. To add to the list below, tg3 has this problem as well, as far as I can tell by looking at the code. Thanks, Ben 8139too.c: rtl8139_close -- rtl8139_stop_thread r8169.c: rtl8169_down cassini.c: cas_change_mtu iseries_veth.c: veth_stop_connection s2io.c: s2io_close sis190.c: sis190_down -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] IPv6 Updates
Thank you all for these changes.
Hugo
On 2/14/07, Herbert Xu [EMAIL PROTECTED] wrote:
Herbert Xu [EMAIL PROTECTED] wrote:
[IPV4] devinet: Register inetdev earlier.
I needed to move the panic call as well.
[IPV4] devinet: Register inetdev earlier.
This patch allocates inetdev at registration for all devices
in line with IPv6. This allows sysctl configuration on the
devices to occur before they're brought up or addresses are
added.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index ba5e7f4..2224f8e 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1055,12 +1055,14 @@ static int inetdev_event(struct notifier_block *this,
unsigned long event,
ASSERT_RTNL();
if (!in_dev) {
- if (event == NETDEV_REGISTER dev == loopback_dev) {
+ if (event == NETDEV_REGISTER) {
in_dev = inetdev_init(dev);
- if (!in_dev)
- panic(devinet: Failed to create loopback\n);
- in_dev-cnf.no_xfrm = 1;
- in_dev-cnf.no_policy = 1;
+ if (dev == loopback_dev) {
+ if (!in_dev)
+ panic(devinet: Failed to create
loopback\n);
+ in_dev-cnf.no_xfrm = 1;
+ in_dev-cnf.no_policy = 1;
+ }
}
goto out;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: deadlock in 2.6.18.2 related to bridging?
Ben Greear [EMAIL PROTECTED] : [...] e1000 appears clean, at least, but there are a lot of other drivers that are calling that method (I didn't check to see if they might be holding rtnl when called.) Not that lot: only r8169, sis190, s2io and cassini (through change_mtu). Bad week. -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] RTNL and flush_scheduled_work deadlocks
Ben Greear [EMAIL PROTECTED] :
[...]
I seem to be able to trigger this within about 1 minute on a
particular 2.6.18.2 system with some 8139too devices, so if someone
has a patch that could be tested, I'll gladly test it. For
whatever reason, I haven't hit this problem on 2.6.20 yet, but
that could easily be dumb luck, and I haven't been running .20
very much.
Bandaid below. It is not complete if your device hits the tx_watchdog
hard but it should help.
I'll return in 24h.
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 35ad5cf..cbee350 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -1603,18 +1603,20 @@ static void rtl8139_thread (struct work_struct *work)
struct net_device *dev = tp-mii.dev;
unsigned long thr_delay = next_tick;
+ rtnl_lock();
+
+ if (!netif_running(dev))
+ goto unlock;
+
if (tp-watchdog_fired) {
tp-watchdog_fired = 0;
rtl8139_tx_timeout_task(work);
- } else if (rtnl_trylock()) {
- rtl8139_thread_iter (dev, tp, tp-mmio_addr);
- rtnl_unlock ();
- } else {
- /* unlikely race. mitigate with fast poll. */
- thr_delay = HZ / 2;
- }
+ } else
+ rtl8139_thread_iter(dev, tp, tp-mmio_addr);
schedule_delayed_work(tp-thread, thr_delay);
+unlock:
+ rtnl_unlock ();
}
static void rtl8139_start_thread(struct rtl8139_private *tp)
@@ -1626,19 +1628,11 @@ static void rtl8139_start_thread(struct rtl8139_private
*tp)
return;
tp-have_thread = 1;
+ tp-watchdog_fired = 0;
schedule_delayed_work(tp-thread, next_tick);
}
-static void rtl8139_stop_thread(struct rtl8139_private *tp)
-{
- if (tp-have_thread) {
- cancel_rearming_delayed_work(tp-thread);
- tp-have_thread = 0;
- } else
- flush_scheduled_work();
-}
-
static inline void rtl8139_tx_clear (struct rtl8139_private *tp)
{
tp-cur_tx = 0;
@@ -2233,8 +2227,6 @@ static int rtl8139_close (struct net_device *dev)
netif_stop_queue (dev);
- rtl8139_stop_thread(tp);
-
if (netif_msg_ifdown(tp))
printk(KERN_DEBUG %s: Shutting down ethercard, status was
0x%4.4x.\n,
dev-name, RTL_R16 (IntrStatus));
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/2] natsemi: Add support for using MII port with no PHY
On Wed, Feb 14, 2007 at 10:02:04AM +, Mark Brown wrote:
Signed-Off-By: Mark Brown [EMAIL PROTECTED]
[...]
- if (np-phy_addr_external == PHY_ADDR_NONE) {
+ /* If we're ignoring the PHY it doesn't matter if we can't
+ * find one. */
+ if (!np-ignore_phy np-phy_addr_external == PHY_ADDR_NONE) {
[...]
+ if (!np-ignore_phy) {
+ /* The link status field is latched: it remains low
+ * after a temporary link failure until it's read. We
+ * need the current link status, thus read twice.
+ */
+ mdio_read(dev, MII_BMSR);
+ bmsr = mdio_read(dev, MII_BMSR);
[...]
/*
+ * If we're ignoring the PHY then autoneg and the internal
+ * transciever are really not going to work so don't let the
+ * user select them.
+ */
+ if (np-ignore_phy (ecmd-autoneg == AUTONEG_ENABLE ||
A trivial comment actually, Is there a point to write multi-line comments
in two different formats ?
Thanks,
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/2] natsemi: Add support for using MII port with no PHY
On Wed, Feb 14, 2007 at 03:28:34PM +0200, Ahmed S. Darwish wrote: A trivial comment actually, Is there a point to write multi-line comments in two different formats ? No goal in doing that, no - it wasn't a conscious decision. -- You grabbed my hand and we fell into it, like a daydream - or a fever. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.21-rc1] ehea: dynamic add / remove port
This patch enables dynamic adding / removing of ehea ports
by DLPAR tool.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
diff -Nurp -X dontdiff linux-2.6.20/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.20/drivers/net/ehea/ehea.h2007-02-12 14:44:35.0
+0100
+++ patched_kernel/drivers/net/ehea/ehea.h 2007-02-12 14:47:24.0
+0100
@@ -39,7 +39,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0046
+#define DRV_VERSIONEHEA_0047
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -380,10 +380,11 @@ struct ehea_port_res {
};
+#define EHEA_MAX_PORTS 16
struct ehea_adapter {
u64 handle;
- u8 num_ports;
- struct ehea_port *port[16];
+ struct ibmebus_dev *ebus_dev;
+ struct ehea_port *port[EHEA_MAX_PORTS];
struct ehea_eq *neq; /* notification event queue */
struct workqueue_struct *ehea_wq;
struct tasklet_struct neq_tasklet;
diff -Nurp -X dontdiff linux-2.6.20/drivers/net/ehea/ehea_main.c
patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.20/drivers/net/ehea/ehea_main.c 2007-02-12 14:44:35.0
+0100
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2007-02-12 14:47:24.0
+0100
@@ -580,7 +580,7 @@ static struct ehea_port *ehea_get_port(s
{
int i;
- for (i = 0; i adapter-num_ports; i++)
+ for (i = 0; i EHEA_MAX_PORTS; i++)
if (adapter-port[i])
if (adapter-port[i]-logical_port_id == logical_port)
return adapter-port[i];
@@ -2274,8 +2274,6 @@ static void ehea_tx_watchdog(struct net_
int ehea_sense_adapter_attr(struct ehea_adapter *adapter)
{
struct hcp_query_ehea *cb;
- struct device_node *lhea_dn = NULL;
- struct device_node *eth_dn = NULL;
u64 hret;
int ret;
@@ -2292,18 +2290,6 @@ int ehea_sense_adapter_attr(struct ehea_
goto out_herr;
}
- /* Determine the number of available logical ports
-* by counting the child nodes of the lhea OFDT entry
-*/
- adapter-num_ports = 0;
- lhea_dn = of_find_node_by_name(lhea_dn, lhea);
- do {
- eth_dn = of_get_next_child(lhea_dn, eth_dn);
- if (eth_dn)
- adapter-num_ports++;
- } while ( eth_dn );
- of_node_put(lhea_dn);
-
adapter-max_mc_mac = cb-max_mc_mac - 1;
ret = 0;
@@ -2313,79 +2299,89 @@ out:
return ret;
}
-static int ehea_setup_single_port(struct ehea_port *port,
- struct device_node *dn)
+int ehea_get_jumboframe_status(struct ehea_port *port, int *jumbo)
{
- int ret;
- u64 hret;
- struct net_device *dev = port-netdev;
- struct ehea_adapter *adapter = port-adapter;
struct hcp_ehea_port_cb4 *cb4;
- u32 *dn_log_port_id;
- int jumbo = 0;
-
- sema_init(port-port_lock, 1);
- port-state = EHEA_PORT_DOWN;
- port-sig_comp_iv = sq_entries / 10;
-
- if (!dn) {
- ehea_error(bad device node: dn=%p, dn);
- ret = -EINVAL;
- goto out;
- }
-
- port-of_dev_node = dn;
-
- /* Determine logical port id */
- dn_log_port_id = (u32*)get_property(dn, ibm,hea-port-no, NULL);
-
- if (!dn_log_port_id) {
- ehea_error(bad device node: dn_log_port_id=%p,
- dn_log_port_id);
- ret = -EINVAL;
- goto out;
- }
- port-logical_port_id = *dn_log_port_id;
-
- port-mc_list = kzalloc(sizeof(struct ehea_mc_list), GFP_KERNEL);
- if (!port-mc_list) {
- ret = -ENOMEM;
- goto out;
- }
-
- INIT_LIST_HEAD(port-mc_list-list);
+ u64 hret;
+ int ret = 0;
- ret = ehea_sense_port_attr(port);
- if (ret)
- goto out;
+ *jumbo = 0;
- /* Enable Jumbo frames */
+ /* (Try to) enable *jumbo frames */
cb4 = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!cb4) {
ehea_error(no mem for cb4);
+ ret = -ENOMEM;
+ goto out;
} else {
- hret = ehea_h_query_ehea_port(adapter-handle,
+ hret = ehea_h_query_ehea_port(port-adapter-handle,
port-logical_port_id,
H_PORT_CB4,
H_PORT_CB4_JUMBO, cb4);
-
if (hret == H_SUCCESS) {
if (cb4-jumbo_frame)
- jumbo = 1;
+ *jumbo = 1;
else {
cb4-jumbo_frame = 1;
- hret = ehea_h_modify_ehea_port(adapter-handle,
+
Re: [PATCH 2.6.21-rc1] ehea: dynamic add / remove port
Hi-
A few high level comments, then some really insignificant ones.
First, is there a reason why we shouldn't have a sysfs entry/kobject for
each logical port? How is it possible to determine, from the adapter
sysfs directory, the current number of ports for that adapter? A port
sysfs directory could include attributes like the OF path to the port,
the state of the port, etc etc.
Second, the probe and remove functions do not communicate whether an add
or remove was successful. Combine this with the lack of port
information in the adapter sysfs directory, and the userspace tool has
no way of verifying a dynamic add/remove.
+ dn_log_port_id = (u32*)get_property(eth_dn, ibm,hea-port-no,
+ NULL);
+ if (!dn_log_port_id) {
+ ehea_error(bad device node: dn_log_port_id=%p,
+ dn_log_port_id);
Wouldn't this print NULL every time for dn_log_port_id? Would the OF
path for eth_dn make for a more useful error msg?
+ ehea_info(%s - logial port id #%d,
Spelling :)
if (port_setup_ok)
- ret = 0;/* At least some ports are setup correctly */
+ return 0; /* At least some ports are setup correctly */
else
- ret = -EINVAL;
+ return -EINVAL;
The else is unnecessary.
static int __devexit ehea_remove(struct ibmebus_dev *dev)
{
struct ehea_adapter *adapter = dev-ofdev.dev.driver_data;
u64 hret;
int i;
- for (i = 0; i adapter-num_ports; i++)
+ for (i = 0; i EHEA_MAX_PORTS; i++)
if (adapter-port[i]) {
ehea_shutdown_single_port(adapter-port[i]);
adapter-port[i] = NULL;
}
Else break?
Thanks-
John
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 21/21] Xen-paravirt: Add the Xen virtual network device driver.
Jeremy Fitzhardinge [EMAIL PROTECTED] writes: +++ b/drivers/xen/Kconfig.net @@ -0,0 +1,14 @@ +menu Xen network device drivers +depends on NETDEVICES XEN + +config XEN_NETDEV_FRONTEND + tristate Network-device frontend driver + depends on XEN + default y + help + The network-device frontend driver allows the kernel to access + network interfaces within another guest OS. Unless you are building a + dedicated device-driver domain, or your master control domain + (domain 0), then you almost certainly want to say Y here. Am I reading this correctly I can directly use the network interface of another guest OS (no protection)? I think this description is misleading, and probably say something about virtual hardware. Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: Fix code for spec changes of 2/7/2007
On Wednesday 14 February 2007 14:18, Johannes Berg wrote: On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote: It's likely that old cards still work with v4 firmware, No, it's absolutely impossible. Rev 2/4 cores have a totally different instruction set in the microcode. Ok, I was not talking about _that_ old cards. ;) -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix bugs in Whether sock accept queue is full checking
Hi, All
when I use linux TCP socket, and find there is a bug in function
sk_acceptq_is_full().
When a new SYN comes, TCP module first checks its validation. If valid,
send SYN,ACK to the client and add the sock to the syn hash table. Next
time if received the valid ACK for SYN,ACK from the client. server will
accept this connection and increase the sk-sk_ack_backlog -- which is
done in function tcp_check_req().We check wether acceptq is full in
function tcp_v4_syn_recv_sock().
Consider an example:
After listen(sockfd, 1) system call, sk-sk_max_ack_backlog is set to
1. As we know, sk-sk_ack_backlog is initialized to 0. Assuming accept()
system call is not invoked now.
1. 1st connection comes. invoke sk_acceptq_is_full(). sk-
sk_ack_backlog=0 sk-sk_max_ack_backlog=1, function return 0 accept
this connection. Increase the sk-sk_ack_backlog
2. 2nd connection comes. invoke sk_acceptq_is_full(). sk-
sk_ack_backlog=1 sk-sk_max_ack_backlog=1, function return 0 accept
this connection. Increase the sk-sk_ack_backlog
3. 3rd connection comes. invoke sk_acceptq_is_full(). sk-
sk_ack_backlog=2 sk-sk_max_ack_backlog=1, function return 1. Refuse
this connection.
I think it has bugs. after listen system call. sk-sk_max_ack_backlog=1
but now it can accept 2 connections. The following patch can fix this
problem.
signed-off-by: Wei Dong [EMAIL PROTECTED]
diff -ruN old/include/net/sock.h new/include/net/sock.h
--- old/include/net/sock.h 2007-02-03 08:38:21.0 -0500
+++ new/include/net/sock.h 2007-02-03 08:38:30.0 -0500
@@ -426,7 +426,7 @@
static inline int sk_acceptq_is_full(struct sock *sk)
{
- return sk-sk_ack_backlog sk-sk_max_ack_backlog;
+ return sk-sk_ack_backlog = sk-sk_max_ack_backlog;
}
/*
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] atl1: bugfix, cleanup, enhancement
Jeff, Please accept the following patchset for the atl1 network device driver. * Drop unnecessary NET_PCI config * Fix incorrect hash table address * Read MAC address from register * Remove unused define * Add Attansic L1 device id to pci_ids * Bump version number This patchset contains changes to the following files. drivers/net/Kconfig |2 +- drivers/net/atl1/atl1_hw.c | 37 + drivers/net/atl1/atl1_main.c |5 ++--- include/linux/pci_ids.h |1 + 4 files changed, 25 insertions(+), 20 deletions(-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] atl1: drop NET_PCI from Kconfig
From: Jay Cliburn [EMAIL PROTECTED] The atl1 driver doesn't need NET_PCI. Remove it from Kconfig. Noticed by Chad Sprouse. Signed-off-by: Jay Cliburn [EMAIL PROTECTED] Signed-off-by: Chris Snook [EMAIL PROTECTED] --- drivers/net/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 0bb3c1e..1b624b4 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2350,7 +2350,7 @@ config QLA3XXX config ATL1 tristate Attansic L1 Gigabit Ethernet support (EXPERIMENTAL) - depends on NET_PCI PCI EXPERIMENTAL + depends on PCI EXPERIMENTAL select CRC32 select MII help - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] atl1: fix bad ioread address
From: Al Viro [EMAIL PROTECTED] An ioread32 statement reads the wrong address. Fix it. Signed-off-by: Al Viro [EMAIL PROTECTED] Signed-off-by: Jay Cliburn [EMAIL PROTECTED] Signed-off-by: Chris Snook [EMAIL PROTECTED] --- drivers/net/atl1/atl1_hw.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c index 08b2d78..e28707a 100644 --- a/drivers/net/atl1/atl1_hw.c +++ b/drivers/net/atl1/atl1_hw.c @@ -357,7 +357,7 @@ void atl1_hash_set(struct atl1_hw *hw, u32 hash_value) */ hash_reg = (hash_value 31) 0x1; hash_bit = (hash_value 26) 0x1F; - mta = ioread32((hw + REG_RX_HASH_TABLE) + (hash_reg 2)); + mta = ioread32((hw-hw_addr + REG_RX_HASH_TABLE) + (hash_reg 2)); mta |= (1 hash_bit); iowrite32(mta, (hw-hw_addr + REG_RX_HASH_TABLE) + (hash_reg 2)); } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] atl1: read MAC address from register
From: Jay Cliburn [EMAIL PROTECTED]
On some Asus motherboards containing the L1 NIC, the MAC address is
written by the BIOS directly to the MAC register during POST, and is
not stored in eeprom. If we don't succeed in fetching the MAC address
from eeprom or spi, try reading it directly from the MAC register.
Suggested by Xiong Huang.
And do some cleanup while we've got the hood up...
Signed-off-by: Jay Cliburn [EMAIL PROTECTED]
Signed-off-by: Chris Snook [EMAIL PROTECTED]
---
drivers/net/atl1/atl1_hw.c | 35 ---
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c
index e28707a..314dbaa 100644
--- a/drivers/net/atl1/atl1_hw.c
+++ b/drivers/net/atl1/atl1_hw.c
@@ -243,14 +243,8 @@ static int atl1_get_permanent_address(struct atl1_hw *hw)
i += 4;
}
-/*
- * The following 2 lines are the Attansic originals. Saving for posterity.
- * *(u32 *) eth_addr[2] = LONGSWAP(addr[0]);
- * *(u16 *) eth_addr[0] = SHORTSWAP(*(u16 *) addr[1]);
- */
- *(u32 *) eth_addr[2] = swab32(addr[0]);
- *(u16 *) eth_addr[0] = swab16(*(u16 *) addr[1]);
-
+ *(u32 *) eth_addr[2] = swab32(addr[0]);
+ *(u16 *) eth_addr[0] = swab16(*(u16 *) addr[1]);
if (is_valid_ether_addr(eth_addr)) {
memcpy(hw-perm_mac_addr, eth_addr, ETH_ALEN);
return 0;
@@ -281,17 +275,28 @@ static int atl1_get_permanent_address(struct atl1_hw *hw)
i += 4;
}
-/*
- * The following 2 lines are the Attansic originals. Saving for posterity.
- * *(u32 *) eth_addr[2] = LONGSWAP(addr[0]);
- * *(u16 *) eth_addr[0] = SHORTSWAP(*(u16 *) addr[1]);
- */
- *(u32 *) eth_addr[2] = swab32(addr[0]);
- *(u16 *) eth_addr[0] = swab16(*(u16 *) addr[1]);
+ *(u32 *) eth_addr[2] = swab32(addr[0]);
+ *(u16 *) eth_addr[0] = swab16(*(u16 *) addr[1]);
if (is_valid_ether_addr(eth_addr)) {
memcpy(hw-perm_mac_addr, eth_addr, ETH_ALEN);
return 0;
}
+
+ /*
+* On some motherboards, the MAC address is written by the
+* BIOS directly to the MAC register during POST, and is
+* not stored in eeprom. If all else thus far has failed
+* to fetch the permanent MAC address, try reading it directly.
+*/
+ addr[0] = ioread32(hw-hw_addr + REG_MAC_STA_ADDR);
+ addr[1] = ioread16(hw-hw_addr + (REG_MAC_STA_ADDR + 4));
+ *(u32 *) eth_addr[2] = swab32(addr[0]);
+ *(u16 *) eth_addr[0] = swab16(*(u16 *) addr[1]);
+ if (is_valid_ether_addr(eth_addr)) {
+ memcpy(hw-perm_mac_addr, eth_addr, ETH_ALEN);
+ return 0;
+ }
+
return 1;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] atl1: remove unused define
From: Chris Snook [EMAIL PROTECTED] Remove unused define from atl1_main.c. Signed-off-by: Chris Snook [EMAIL PROTECTED] Signed-off-by: Jay Cliburn [EMAIL PROTECTED] --- drivers/net/atl1/atl1_main.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c index 6655640..abce97e 100644 --- a/drivers/net/atl1/atl1_main.c +++ b/drivers/net/atl1/atl1_main.c @@ -82,7 +82,6 @@ #include atl1.h -#define RUN_REALTIME 0 #define DRIVER_VERSION 2.0.6 char atl1_driver_name[] = atl1; - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] atl1: add L1 device id to pci_ids, then use it
From: Chris Snook [EMAIL PROTECTED]
Add device id for the Attansic L1 chip to pci_ids.h, then use it.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Signed-off-by: Jay Cliburn [EMAIL PROTECTED]
---
drivers/net/atl1/atl1_main.c |2 +-
include/linux/pci_ids.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index abce97e..09f3375 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -99,7 +99,7 @@ MODULE_VERSION(DRIVER_VERSION);
* atl1_pci_tbl - PCI Device ID Table
*/
static const struct pci_device_id atl1_pci_tbl[] = {
- {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, 0x1048)},
+ {PCI_DEVICE(PCI_VENDOR_ID_ATTANSIC, PCI_DEVICE_ID_ATTANSIC_L1)},
/* required last entry */
{0,}
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 68a7be9..bd21933 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2067,6 +2067,7 @@
#define PCI_DEVICE_ID_TDI_EHCI 0x0101
#define PCI_VENDOR_ID_ATTANSIC 0x1969
+#define PCI_DEVICE_ID_ATTANSIC_L1 0x1048
#define PCI_VENDOR_ID_JMICRON 0x197B
#define PCI_DEVICE_ID_JMICRON_JMB360 0x2360
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] atl1: bump version number
From: Jay Cliburn [EMAIL PROTECTED] Bump the version number. Signed-off-by: Jay Cliburn [EMAIL PROTECTED] --- drivers/net/atl1/atl1_main.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c index 09f3375..6567348 100644 --- a/drivers/net/atl1/atl1_main.c +++ b/drivers/net/atl1/atl1_main.c @@ -82,7 +82,7 @@ #include atl1.h -#define DRIVER_VERSION 2.0.6 +#define DRIVER_VERSION 2.0.7 char atl1_driver_name[] = atl1; static const char atl1_driver_string[] = Attansic L1 Ethernet Network Driver; - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Fabric7 VIOC driver source code
On Wed, 07 Feb 2007 13:07:40 -0800 Sriram Chidambaram [EMAIL PROTECTED] wrote: This patch provides the Fabric7 VIOC driver source code. This git mbox patch is built against git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git The patch can be pulled from ftp://ftp.fabric7.com/VIOC/Fabric7-VIOC-driver-patch.FEB-07-2007 For people wondering what this is, the documentation file is below. I'll pull this driver into my queue so that it doesn't get lost and to give people an opportunity to review it more easily. From a quick peek, I'd expect some changes to be needed: stylistic things, plus some suspicious looking PCI-poking in vioc_irq.c. But I didn't look at it at all closely. The driver needed a bit of help to make it compile on ia64 (I haven't tried any other architectures). If it's simply not possible that this device will ever be present on any non-x86 machines then perhaps we should restrict it to those architectures at kernel configuration time. But then, all the changes I made were good ones.. Overview A Virtual Input-Output Controller (VIOC) is a PCI device that provides 10Gbps of I/O bandwidth that can be shared by up to 16 virtual network interfaces (VNICs). VIOC hardware supports several features such as large frames, checksum offload, gathered send, MSI/MSI-X, bandwidth control, interrupt mitigation, etc. VNICs are provisioned to a host partition via an out-of-band interface from the System Controller -- typically before the partition boots, although they can be dynamically added or removed from a running partition as well. Each provisioned VNIC appears as an Ethernet netdevice to the host OS, and maintains its own transmit ring in DMA memory. VNICs are configured to share up to 4 of total 16 receive rings and 1 of total 16 receive-completion rings in DMA memory. VIOC hardware classifies packets into receive rings based on size, allowing more efficient use of DMA buffer memory. The default, and recommended, configuration uses groups of 'receive sets' (rxsets), each with 3 receive rings, a receive completion ring, and a VIOC Rx interrupt. The driver gives each rxset a NAPI poll handler associated with a phantom (invisible) netdevice, for concurrency. VNICs are assigned to rxsets using a simple modulus. VIOC provides 4 interrupts in INTx mode: 2 for Rx, 1 for Tx, and 1 for out-of-band messages from the System Controller and errors. VIOC also provides 19 MSI-X interrupts: 16 for Rx, 1 for Tx, 1 for out-of-band messages from the System Controller, and 1 for error signalling from the hardware. The VIOC driver makes a determination whether MSI-X functionality is supported and initializes interrupts accordingly. [Note: The Linux kernel disables MSI-X for VIOCs on modules with AMD 8131, even if the device is on the HT link.] Module loadable parameters == - poll_weight (default 8) - the number of received packets will be processed during one call into the NAPI poll handler. - rx_intr_timeout (default 1) - hardware rx interrupt mitigation timer, in units of 5us. - rx_intr_pkt_cnt (default 64) - hardware rx interrupt mitigation counter, in units of packets. - tx_pkts_per_irq (default 64) - hardware tx interrupt mitigation counter, in units of packets. - tx_pkts_per_bell (default 1) - the number of packets to enqueue on a transmit ring before issuing a doorbell to hardware. Performance Tuning == You may want to use the following sysctl settings to improve performance. [NOTE: To be re-checked] # set in /etc/sysctl.conf net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_sack = 0 net.ipv4.tcp_rmem = 1000 1000 1000 net.ipv4.tcp_wmem = 1000 1000 1000 net.ipv4.tcp_mem = 1000 1000 1000 net.core.rmem_max = 5242879 net.core.wmem_max = 5242879 net.core.rmem_default = 5242879 net.core.wmem_default = 5242879 net.core.optmem_max = 5242879 net.core.netdev_max_backlog = 10 Out-of-band Communications with System Controller = System operators can use the out-of-band facility to allow for remote shutdown or reboot of the host partition. Upon receiving such a command, the VIOC driver executes /sbin/reboot or /sbin/shutdown via the usermodehelper() call. This same communications facility is used for dynamic VNIC provisioning (plug in and out). The VIOC driver also registers a callback with register_reboot_notifier(). When the callback is executed, the driver records the shutdown event and reason in a VIOC register to notify the System Controller. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
