[PATCH] ipw2200: add channels sysfs entry

2007-02-14 Thread Zhu Yi

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

2007-02-14 Thread Jarek Poplawski
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

2007-02-14 Thread Ishizaki Kou
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:
+ *
+ *
+ *
+ * ...
+ *<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);
 alloc_tx_failed:
del_timer_sync(&card->aneg_tim

[PATCH 3/4] spidernet: spidernet: add support for Celleb

2007-02-14 Thread Ishizaki Kou
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

2007-02-14 Thread Ishizaki Kou
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

2007-02-14 Thread Ishizaki Kou
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

2007-02-14 Thread Ishizaki Kou
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_

Re: [Netem] [Fwd: [PATCH 2.6.18 0/2] LARTC: trace control for netem]

2007-02-14 Thread Rainer Baumann


Stephen Hemminger wrote:
> On Wed, 07 Feb 2007 19:36:22 +0100
> Rainer Baumann <[EMAIL PROTECTED]> wrote:
>
>   
>> Hi Stephen
>>
>> I just wanted to ask you, if you already had time to test our trace
>> extension for netem as discussed on the 13th of December.
>>
>> Cheers
>> Rainer
>>
>> Rainer Baumann wrote:
>> 
>>> Hi Stephen
>>>
>>> As discussed yesterday, here our patches to integrate trace control into 
>>> netem
>>>
>>>
>>>
>>> Trace Control for Netem: Emulate network properties such as long range 
>>> dependency and self-similarity of cross-traffic.
>>>
>>> A new option (trace) has been added to the netem command. If the trace 
>>> option is used, the values for packet delay etc. are read from a 
>>> pregenerated trace file, afterwards the packets are processed by the normal 
>>> netem functions. The packet action values are readout from the trace file 
>>> in user space and sent to kernel space via configfs.
>>>
>>>
>>>   
>
> I looked at it some more, and want to go in and clean the configuration and 
> buffer interface
> slightly before inclusion. Once it is in I get stuck with the ABI so don't 
> want to do something
> wrong.
>   
Just let me know, if we can 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 0/2] natsemi: Support Aculab E1/T1 cPCI carrier cards

2007-02-14 Thread Mark Brown
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

2007-02-14 Thread Mark Brown
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


[patch 1/2] natsemi: Add support for using MII port with no PHY

2007-02-14 Thread Mark Brown
This patch provides code paths which allow the natsemi driver to use the
external MII port on the chip but ignore any PHYs that may be attached to it.
The link state will be left as it was when the driver started and can be
configured via ethtool.  Any PHYs that are present can be accessed via the MII
ioctl()s.

This is useful for systems where the device is connected without a PHY
or where either information or actions outside the scope of the driver
are required in order to use the PHYs.

Signed-Off-By: Mark Brown <[EMAIL PROTECTED]>

---

Previous versions of this patch exposed the new functionality as a module
option.  This has been removed.  Any hardware that needs this should be
identifiable by a quirk since it unlikely to behave correctly with an
unmodified driver.

Index: linux/drivers/net/natsemi.c
===
--- linux.orig/drivers/net/natsemi.c2007-02-12 17:44:33.0 +
+++ linux/drivers/net/natsemi.c 2007-02-12 18:09:44.0 +
@@ -568,6 +568,8 @@
u32 intr_status;
/* Do not touch the nic registers */
int hands_off;
+   /* Don't pay attention to the reported link state. */
+   int ignore_phy;
/* external phy that is used: only valid if dev->if_port != PORT_TP */
int mii;
int phy_addr_external;
@@ -696,7 +698,10 @@
struct netdev_private *np = netdev_priv(dev);
u32 tmp;
 
-   netif_carrier_off(dev);
+   if (np->ignore_phy)
+   netif_carrier_on(dev);
+   else
+   netif_carrier_off(dev);
 
/* get the initial settings from hardware */
tmp= mdio_read(dev, MII_BMCR);
@@ -806,8 +811,10 @@
np->hands_off = 0;
np->intr_status = 0;
np->eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
+   np->ignore_phy = 0;
 
/* Initial port:
+* - If configured to ignore the PHY set up for external.
 * - If the nic was configured to use an external phy and if find_mii
 *   finds a phy: use external port, first phy that replies.
 * - Otherwise: internal port.
@@ -815,7 +822,7 @@
 * The address would be used to access a phy over the mii bus, but
 * the internal phy is accessed through mapped registers.
 */
-   if (readl(ioaddr + ChipConfig) & CfgExtPhy)
+   if (np->ignore_phy || readl(ioaddr + ChipConfig) & CfgExtPhy)
dev->if_port = PORT_MII;
else
dev->if_port = PORT_TP;
@@ -825,7 +832,9 @@
 
if (dev->if_port != PORT_TP) {
np->phy_addr_external = find_mii(dev);
-   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) {
dev->if_port = PORT_TP;
np->phy_addr_external = PHY_ADDR_INTERNAL;
}
@@ -891,6 +900,8 @@
printk("%02x, IRQ %d", dev->dev_addr[i], irq);
if (dev->if_port == PORT_TP)
printk(", port TP.\n");
+   else if (np->ignore_phy)
+   printk(", port MII, ignoring PHY\n");
else
printk(", port MII, phy ad %d.\n", 
np->phy_addr_external);
}
@@ -1571,42 +1582,45 @@
 {
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr = ns_ioaddr(dev);
-   int duplex;
+   int duplex = np->duplex;
u16 bmsr;
 
-   /* 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 are ignoring the PHY then don't try reading it. */
+   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 (!(bmsr & BMSR_LSTATUS)) {
-   if (netif_carrier_ok(dev)) {
+   if (!(bmsr & BMSR_LSTATUS)) {
+   if (netif_carrier_ok(dev)) {
+   if (netif_msg_link(np))
+   printk(KERN_NOTICE "%s: link down.\n",
+  dev->name);
+   netif_carrier_off(dev);
+   undo_cable_magic(dev);
+   }
+   return;
+   }
+   if (!netif_carrier_ok(dev)) {
if (netif_msg_link(np))
-   

Re: 2.6.20 crash in tcp_tso_segment()

2007-02-14 Thread Mike Accetta
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 ~{PmV>HI~} <[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

2007-02-14 Thread YOSHIFUJI Hideaki / 吉藤英明
Dave,

Please consider pulling the following changesets available on the
2.6.20-net-2.6-20070214-FOR_DAVEM
branch at

(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->flags&IFA_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->flags&IFA_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 &l

Fw: [Bugme-new] [Bug 8009] New: PPPoE+mppe Server fail with Win Client

2007-02-14 Thread Andrew Morton


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   ]
rcvd [LCP ConfReq id=0x0   ]
sent [LCP ConfRej id=0x0 ]
rcvd [LCP ConfAck id=0x1   ]
rcvd [LCP ConfReq id=0x1  ]
sent [LCP ConfAck id=0x1  ]
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 ]
rcvd [CCP ConfReq id=0x4 ]
sent [CCP ConfNak id=0x4 ]
rcvd [IPCP ConfReq id=0x5   
  ]
sent [IPCP TermAck id=0x5]
rcvd [CCP ConfNak id=0x1 ]
sent [CCP ConfReq id=0x2 ]
rcvd [CCP ConfReq id=0x6 ]
sent [CCP ConfAck id=0x6 ]
rcvd [CCP ConfAck id=0x2 ]
MPPE 128-bit stateful compression enabled
sent [IPCP ConfReq id=0x1 ]
rcvd [IPCP ConfAck id=0x1 ]
rcvd [IPCP ConfReq id=0x7   
  ]
sent [IPCP ConfRej id=0x7   ]
rcvd [IPCP ConfReq id=0x8   ]
sent [IPCP ConfNak id=0x8   ]
rcvd [IPCP ConfReq id=0x9   ]
sent [IPCP ConfAck id=0x9   ]
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 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 ...]
rcvd [proto=0x4ea] 60 37 28 14 f5 86 09 24 b2 b5 4d df 2a b8 1d 7d bc 71 66 72
5f fc 73 e6 bf e5 ee 82 ad 04 b4 75 ...
Unsupported protocol 0x4ea received
sent [LCP ProtRej id=0x6 04 ea 60 37 28 14 f5 86 09 24 b2 b5 4d df 2a b8 1d 7d
bc 71 66 72 5f fc 73 e6 bf e5 ee 82 ad 04 ...]
rcvd [proto=0xc204] 10 92 44 80 8c ad a5 ba 3d cb 5a e3 a4 4b a7 07 ad 9b 67 b4
5b 96 04 da 3a c1 04 6e 92 c5 09 36 ...
Unsupported protocol 0xc204 received
sent [LCP ProtRej id=0x7 c2 04 10 92 44 80 8c ad a5 ba 3d cb 5a e3 a4 4b a7 07
ad 9b 67 b4 5b 96 04 da 3a c1 04 6e 92 c5 ...]
rcvd [proto=0x148d] 90 3c 99 0f 84 ba 9d bc 63 86 11 a3 ed 87 c4 05 8c ac 47 d7
d0 7b 58 6e d9 9f b6 22 f6 34 20 b2 ...
Unsupported protocol 0

Fw: Problem with 2.6.20 and hostap_cs (Netgear MA401)

2007-02-14 Thread Andrew Morton


Begin forwarded message:

Date: Wed, 14 Feb 2007 11:59:00 -0500
From: David G Hamblen <[EMAIL PROTECTED]>
To: Kernel mailing list 
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

2007-02-14 Thread Vlad Yasevich

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

2007-02-14 Thread Hasso Tepper
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): : link
is not ready" and "ADDRCONF(NETDEV_CHANGE): : 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

2007-02-14 Thread Jeff Garzik
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

2007-02-14 Thread Linas Vepstas

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

2007-02-14 Thread Johannes Berg
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

2007-02-14 Thread Johannes Berg
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

2007-02-14 Thread Herbert Xu
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 ~{PmV>HI~} <[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?

2007-02-14 Thread Stephen Hemminger
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:
> 
>   [] __mutex_lock_slowpath+0xbe/0x2a0
>   [] mutex_lock+0x1c/0x20
>   [] __rtnl_lock+0x1b/0x40
>   [] port_carrier_check+0x22/0xa0 [bridge]
>   [] run_workqueue+0x7b/0x100
>   [] worker_thread+0x10f/0x130
>   [] kthread+0xd5/0xe0
>   [] 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:
>   [] flush_cpu_workqueue+0x6b/0xb0
>   [] flush_workqueue+0x38/0x50
>   [] flush_scheduled_work+0xd/0x10
>   [] rtl8139_close+0x165/0x1a0 [8139too]
>   [] dev_close+0x54/0x70
>   [] dev_change_flags+0x51/0x110
>   [] devinet_ioctl+0x4b0/0x6a0
>   [] inet_ioctl+0x6b/0x80
>   [] sock_ioctl+0x77/0x250
>   [] do_ioctl+0x28/0x80
>   [] vfs_ioctl+0x57/0x2b0
>   [] sys_ioctl+0x39/0x60
>   [] sysenter_past_esp+0x56/0x99
>   [] 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?

2007-02-14 Thread Ben Greear

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

2007-02-14 Thread Stephen Hemminger
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: [GIT PULL] IPv6 Updates

2007-02-14 Thread Herbert Xu
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 ~{PmV>HI~} <[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


Re: [BUG] RTNL and flush_scheduled_work deadlocks

2007-02-14 Thread Ben Greear

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

2007-02-14 Thread Hugo Santos

 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 ~{PmV>HI~} <[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?

2007-02-14 Thread Francois Romieu
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

2007-02-14 Thread Francois Romieu
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

2007-02-14 Thread Ahmed S. Darwish
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

2007-02-14 Thread Mark Brown
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

2007-02-14 Thread Jan-Bernd Themann
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 
 
 #define DRV_NAME   "ehea"
-#define DRV_VERSION"EHEA_0046"
+#define DRV_VERSION"EHEA_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 = ehe

Re: [PATCH 2.6.21-rc1] ehea: dynamic add / remove port

2007-02-14 Thread John Rose
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.

2007-02-14 Thread Eric W. Biederman
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

2007-02-14 Thread Michael Buesch
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

2007-02-14 Thread weidong
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

2007-02-14 Thread Jay Cliburn
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

2007-02-14 Thread Jay Cliburn
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

2007-02-14 Thread Jay Cliburn
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

2007-02-14 Thread Jay Cliburn
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 *) ð_addr[2] = swab32(addr[0]);
+   *(u16 *) ð_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 *) ð_addr[2] = swab32(addr[0]);
+   *(u16 *) ð_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 *) ð_addr[2] = swab32(addr[0]);
+   *(u16 *) ð_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

2007-02-14 Thread Jay Cliburn
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

2007-02-14 Thread Jay Cliburn
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

2007-02-14 Thread Jay Cliburn
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

2007-02-14 Thread Andrew Morton
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