Re: [NET_SCHED]: act_ipt: fix regression in ipt action
Applied, thanks Patrick. - 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: [BNX2]: PHY workaround for 5709 A0.
From: Michael Chan [EMAIL PROTECTED] Date: Thu, 01 Feb 2007 10:47:58 -0800 [BNX2]: PHY workaround for 5709 A0. 5709 A0 copper devices will not link up with some link partners without this workaround. Update driver to 1.5.5. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, thanks 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
[PATCH] d80211: Fix WMM ACI to UP mapping
Fix WMM ACI to UP mapping according to IEEE 802.1d spec. Table 7-2.
Signed-off-by: Zhu Yi [EMAIL PROTECTED]
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 393a294..fabdef5 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -289,7 +289,7 @@ static void ieee80211_sta_wmm_params(struct
net_device *dev,
case 1:
queue = IEEE80211_TX_QUEUE_DATA3;
if (acm) {
- local-wmm_acm |= BIT(1) | BIT(2);
+ local-wmm_acm |= BIT(0) | BIT(3);
}
break;
case 2:
@@ -308,7 +308,7 @@ static void ieee80211_sta_wmm_params(struct
net_device *dev,
default:
queue = IEEE80211_TX_QUEUE_DATA2;
if (acm) {
- local-wmm_acm |= BIT(0) | BIT(3);
+ local-wmm_acm |= BIT(1) | BIT(2);
}
break;
}
-
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: spidernet: dynamic phy setup code
Jens-san,
Thanks for your comments.
Ishizaki-san,
This patch partially works on celleb but remains
following several problems.
1. It doesn't recover once an ethernet cable which is
connected to a spider_net card is unpluged.
My understanding is that you are using the LINK interrupt to detect this.
Yes. We use the LINK interrupt for this purpose.
For the blade this is not connected but reenabling it wont hurt, I hope.
2. It doesn't work when the spider_net card is connected to
a 100Mbps ethernet switch.
To solve these problems, we need to restore some codes
you removed from your patch.
(1)
- if (card-aneg_count 10) {
- /* timeout */
- card-aneg_count = 0;
- is1000 = !is1000;
- goto re_setup;
- if (phy-speed == 1000 !is1000) {
- is1000 = 1;
- goto re_setup;
- } else if(phy-speed != 1000 is1000) {
- is1000 = 0;
- goto re_setup;
- }
We need to use different auto-neg initial settings between
for 10/100Mbps ethernet switches and for Gbps ethernet switches.
Driver don't know which type of network switch is connected to
network card, so we try both settings alternately in auto negtiation
sequences by using a variable is1000.
I still dont see why you need different settings for different speed switches.
This is getting to a point where access to some hardware would be handy.
What exact phy are using anyway ?
We use bcm5461. There is a possibility that we don't know the appropriate
setting which is applicable for both type of switches.
Furthermore, we have a problem that poll_link() may succeed even when
the auto-neg initial setting is for different network switch type,
and the network card does not work on this case. We retry auto-neg
with the another initial setting on this case.
See above, could you give some more details why this is the case. Or maybe Ben
knows more about this ?
We didn't investigate for the detail, but we met the following phenomena.
1. When auto-neg starts with Gbps setting and ethernet card is connected to
a 100Mbps switch, LINK is not detected.
2. When auto-neg starts with 100/10Mbps setting and ethernet card is
connected to Gbps switch, LINK is detected (poll_link() succeeds), but
the network is not available.
#We are commented that is1000 should be in spider_net_card.
#We fixed it in another patch. Please refer the following.
#http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030203.html
But we don't think this is the best solution, and we are still
developing
our spidernet driver. If you have a good alternative idea, please
tell
us.
(2)
- spider_net_write_reg(card, SPIDER_NET_GMACST,
-spider_net_read_reg(card, SPIDER_NET_GMACST));
- spider_net_write_reg(card, SPIDER_NET_GMACINTEN, 0x4);
These codes are enabling LINK status interrupt which is disabled
at the beginning of auto-neg.
Without this operation, auto negotiation works only when a connection
detected for the first time, and auto negotiation will not work
when an ethernet cable is unpluged or pluged.
I will reenable it and see wether it affects us. The pin is not
connected so
we should never enter this part of the code.
(3)
- mii_phy_probe(phy, phy-mii_id);
It seems that PHY reset is necessary before auto negotiation,
after a link once went down.
We can't call directly reset routine from driver, so we call
mii_phy_probe().
We are still developping the patch as we noted, and we are considering
to call mii_phy_probe() from spider_net_setup_aneg(), or to call
reset_one_mii_phy() from bcm54xx_setup_aneg().
IMHO using mii_phy_probe is the right way to do this.
OK. We will do so.
We think these (1)-(3) are necessary, but we are afraid that you removed
them
by a reason that they causes some trouble in Cell Blade. If so please
tell us.
I'll do some investigations and let you know of the results.
Thanks for your cooperation to us.
By the way, we have a suggestion. Would you please make your spidernet
patch based main-line code(not based on our patch)?
Our patch are still changing, so we think it's more convenient
for you and us to maintain the code.
We will not mind whether it includes our code or not.
We will post our recent spidernet patch set based on 2.6.20-rc6.
This patch set is merged Jens-san's spidernet patch and works on celleb.
We hope this patch set will work on Cell blade.
We intend this patch set is just for a test so far(not intended to be
taken for main-line immediately). Please try this, if you can.
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
[RFC/PATCH 2.6.20-rc6 1/4] spidernet: autoneg support for Celleb
Add auto negotiation support for Celleb.
This patch is just for a test. Please try this, if you can.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
---
--- org-linux-powerpc-git/drivers/net/spider_net.h 2007-02-02
14:24:26.0 +0900
+++ linux-powerpc-git/drivers/net/spider_net.h 2007-02-02 14:24:45.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
@@ -447,6 +453,10 @@
spinlock_t intmask_lock;
struct tasklet_struct rxram_full_tl;
+
+ int aneg_count;
+ int is1000;
+ struct timer_list aneg_timer;
struct timer_list tx_timer;
struct work_struct tx_timeout_task;
--- org-linux-powerpc-git/drivers/net/spider_net.c 2007-02-02
14:24:22.0 +0900
+++ linux-powerpc-git/drivers/net/spider_net.c 2007-02-02 14:26:17.0
+0900
@@ -165,6 +165,57 @@
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 bmcr, bmsr, ctrl1000, stat1000, estat;
+
+ bmcr = spider_net_read_phy(card-netdev, phy-mii_id, MII_BMCR);
+ bmsr = spider_net_read_phy(card-netdev, phy-mii_id, MII_BMSR);
+ ctrl1000 = spider_net_read_phy(card-netdev, phy-mii_id, MII_CTRL1000);
+ stat1000 = spider_net_read_phy(card-netdev, phy-mii_id, MII_STAT1000);
+ estat= spider_net_read_phy(card-netdev, phy-mii_id, MII_ESTATUS);
+
+ if (bmsr BMSR_10HALF)
+ advertise |= ADVERTISE_10HALF;
+ if (bmsr BMSR_10FULL)
+ advertise |= ADVERTISE_10FULL;
+ if (bmsr BMSR_100HALF)
+ advertise |= ADVERTISE_100HALF;
+ if (bmsr BMSR_100FULL)
+ advertise |= ADVERTISE_100FULL;
+ if (bmsr BMSR_100BASE4)
+ advertise |= ADVERTISE_100BASE4;
+
+ mii_phy_probe(phy, phy-mii_id);
+
+ if (card-is1000) {
+ if ((bmsr BMSR_ESTATEN) (estat ESTATUS_1000_TFULL)) {
+ advertise |= ADVERTISE_1000XFULL;
+ ctrl1000 |= ADVERTISE_1000FULL;
+ }
+ if ((bmsr BMSR_ESTATEN) (estat ESTATUS_1000_THALF)) {
+ advertise |= ADVERTISE_1000XHALF;
+ ctrl1000 |= ADVERTISE_1000HALF;
+ }
+
+ spider_net_write_phy(card-netdev, phy-mii_id,
+MII_CTRL1000, ctrl1000);
+
+
+ phy-def-ops-setup_aneg(phy, advertise);
+ } else {
+ bmcr |= (BMCR_ANRESTART | BMCR_ANENABLE);
+ spider_net_write_phy(card-netdev, phy-mii_id,
+MII_BMCR, bmcr);
+ }
+}
+
/**
* spider_net_rx_irq_off - switch off rx irq on this spider card
* @card: device structure
@@ -1245,6 +1296,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
[RFC/PATCH 2.6.20-rc6 2/4] spidernet: load firmaware when open
This patch moves calling init_firmware() from spider_net_probe() to
spider_net_open() so as to use the driver by built-in.
This patch is just for a test. Please try this, if you can.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
---
--- org-linux-powerpc-git/drivers/net/spider_net.c 2007-02-02
14:29:17.0 +0900
+++ linux-powerpc-git/drivers/net/spider_net.c 2007-02-02 14:29:39.0
+0900
@@ -1718,6 +1718,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
*
@@ -1735,6 +1853,10 @@
result = -ENOMEM;
+ 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)
@@ -1785,6 +1907,7 @@
spider_net_free_chain(card, card-tx_chain);
alloc_tx_failed:
del_timer_sync(card-aneg_timer);
+init_firmware_failed:
[RFC/PATCH 2.6.20-rc6 3/4] spidernet: add support for Celleb
This patch adds or changes some HW specific settings for spider_net on Celleb. This patch is just for a test. Please try this, if you can. Signed-off-by: Kou Ishizaki [EMAIL PROTECTED] --- --- org-linux-powerpc-git/drivers/net/Kconfig 2007-02-02 14:34:19.0 +0900 +++ linux-powerpc-git/drivers/net/Kconfig 2007-02-02 14:32:18.0 +0900 @@ -2256,7 +2256,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-02 14:29:13.0 +0900 +++ linux-powerpc-git/drivers/net/spider_net.h 2007-02-02 14:32:18.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-02 14:31:39.0 +0900 +++ linux-powerpc-git/drivers/net/spider_net.c 2007-02-02 14:32:18.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] @@ -1618,6 +1619,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
[RFC/PATCH 2.6.20-rc6 4/4] spidernet: remove txram full logging
This patches removes logging for SPIDER_NET_GTMFLLINT interrupts.
Since the interrupts are not irregular, and they happen frequently
when using 100Mbps network switches.
This patch is just for a test. Please try this if you can.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
---
--- org-linux-powerpc-git/drivers/net/spider_net.c 2007-02-02
14:35:14.0 +0900
+++ linux-powerpc-git/drivers/net/spider_net.c 2007-02-02 14:35:49.0
+0900
@@ -1435,8 +1435,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
Re: [RFC][PATCH][XFRM][0/5] extension for XFRM databases
Hello, On Thu, 01 Feb 2007 08:24:33 -0500 jamal [EMAIL PROTECTED] wrote: Hello, I think i may have understood your approach before but i am a little lost right now, so bear with me. No problem. Could we not achieve your goals by using (on XFRM at least) XFRM_MSG_UPDPOLICY and XFRM_MSG_UPDSA ? At the beginning, we consider whether the existing messages (XFRM_MSG_UPDPOLICY and XFRM_MSG_UPDSA) can do the job. But after careful analysis, we reached to the conclusion that we need something else. Let me expand: In the design phase, we sorted out the requirements as below: (1) Overhead of userland - kernel interaction message exchange should be kept minimum. (2) There should not be too much requirement for user application to leverage the feature (dynamic update of endpoint). More specifically, we don't want to expect the user application to have detailed information of IPsec security association (i.e. SPI). (3) There should not be negative impact on the existing software which is based on PF_KEYv2 (RFC2367). Firstly, if we use the existing messages for updating SPD and SAD, we simply need 2 pairs of request/response exchange between the userland and kernel for updating a single endpoint. This is not ideal from the perspective of (1). Secondly, we need to be careful about updating the endpoint address because it may invoke unexpected signaling (ACQUIRE) to the user application. Imagine you update SPD and SAD sequentially while there is an outbound flow going on. The kernel may end up with triggering the userland application by unexpected ACQUIRE message due to the absence of SAD entry. In order to avoid this problem, we need a sort of atomic update of SPD and SAD entries. XFRM_MSG_MIGRATE is designed and implemented in a way that unexpected ACQUIRE would never occur. Thirdly, we also need to pay attention to the PF_KEYv2 spec. XFRM_MSG_UPDSA is derived from SADB_UPDATE message in PF_KEYv2. According to the spec, the semantics of SADB_UPDATE is to add a new security association with the information provided by previous SADB_GETSPI message. We think it's not a good idea to overload the semantics of SADB_UPDATE message because it may confuse legacy software from the perspective of (3). Moreover, caller of SADB_UPDATE should specify SPI, source address, and destination address, which is a bit problematic from the perspective of (2). From the above reasons, we decided to extend XFRM/PF_KEYv2 for dynamic update of the endpoint. Please note that the mechanism is useful not only for Mobile IPv6 but also for Mobile VPN scenario. Does this make sense? Regards, Shinta cheers, jamal On Thu, 2007-01-02 at 13:09 +0900, Shinta Sugimoto wrote: Hello, Let me issue a request for comments for the patch set developed by the USAGI project. The patch set aims to extend the XFRM framework so that endpoint addresses in the XFRM databases, namely Could XFRM policy and XFRM state can be dynamically updated according to a request from user application. This feature is required for Mobile IPv6 to follow the security requirements specified in RFC3776. More specifically, the Mobile Node and Home Agent need to update the endpoint addresses of the IPsec tunnel when the Mobile Node changes its attachment point (Care-of Address) to the Internet. The kernel also notifies userland application via both Netlink and PF_KEY sockets so that user application (e.g. IKE Daemon) could be informed of the updates appropriately. More detailed information of motivation/rationale for this feature can be found in the internet draft[1]. The patch set consists of following patches: [1/5] [XFRM]: Extension to the XFRM framework for dynamic update of endpoint address(es) [2/5] [XFRM]: User interface for handling XFRM_MSG_MIGRATE [3/5] [XFRM]: CONFIG_XFRM_MIGRATE option [4/5] [PFKEYV2]: Extension to the PF_KEYv2 framework for dynamic update of endpoint address(es) [5/5] [PFKEYV2]: CONFIG_NET_KEY_MIGRATE option Any comments/suggestions are appreciated. Thank you very much. [1]: http://www.ietf.org/internet-drafts/draft-sugimoto-mip6-pfkey-migrate-03.txt Regards, Shinta - 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: [RFC][PATCH][XFRM][1/5] extension to XFRM for dynamic endpoint update (MIGRATE)
Dear James,
Thank you for your comments. Please find my comments inline.
On Thu, 1 Feb 2007 09:45:18 -0500 (EST)
James Morris [EMAIL PROTECTED] wrote:
On Thu, 1 Feb 2007, Shinta Sugimoto wrote:
+int xfrm_migrate(struct xfrm_selector *sel, u8 dir, u8 type,
+struct xfrm_migrate *m, int num_migrate)
+{
+ int i, err, nx_cur = 0, nx_new = 0;
+ struct xfrm_policy *pol = NULL;
[...]
+donothing:
+ if (pol)
+ xfrm_pol_put(pol);
If you reach 'donothing', pol must be NULL, so you don't need to check for
it before xfrm_pol_put().
Yes, you are right. I will delete unnecessary null-check and xfrm_pol_put().
+#ifdef CONFIG_XFRM_MIGRATE
+static struct xfrm_algo *xfrm_algo_solidclone(struct xfrm_algo *orig)
+{
+ struct xfrm_algo *a;
+ a = kmalloc(sizeof(*orig) + orig-alg_key_len, GFP_KERNEL);
+ if (a)
+ memcpy(a, orig, sizeof(*orig) + orig-alg_key_len);
Use kmemdup() ?
I see. I will replace sets of kmalloc and memcpy with kmemdup().
+if (orig-encap) {
+ x-encap = kmalloc(sizeof(*x-encap), GFP_KERNEL);
+ if (!x-encap)
+ goto error;
+ memcpy(x-encap, orig-encap, sizeof(*x-encap));
+ }
+
+ if (orig-coaddr) {
+ x-coaddr = kmalloc(sizeof(*x-coaddr), GFP_KERNEL);
+ if (!x-coaddr)
+ goto error;
+ memcpy(x-coaddr, orig-coaddr, sizeof(*x-coaddr));
+ }
Ditto.
+EXPORT_SYMBOL(xfrm_state_clone);
Why not EXPORT_SYMBOL_GPL ?
(for all of your exports).
Actually I don't have specific preference on either EXPORT_SYMBOL or
EXPORT_SYMBOL_GPL. It seemed to me that other functions defined in
files under net/xfrm/ are using EXPORT_SYMBOL, so I followed that.
Do you think EXPORT_SYMBOL_GPL is more appropriate in this case?
Regards,
Shinta
-
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/7] [S390]: Introduction of AF_IUCV sockets support
Hello, The Inter-User Communication Vehicle (IUCV) is a z/VM communication facility that enables a program running in one virtual machine to communicate with another virtual machine, or with a control program, or even with itself. The communication takes place over a predefined linkage called a path. AF_IUCV provides a complete socket interface for socket communication from Linux to Linux (running on z/VM) or Linux on VM to CMS. The AF_IUCV Protocol Support will use IUCV to provide AF_IUCV protocol support for communication with z/VM back-end services. It also can connect socket applications operating in Linux kernels running on different VM user IDs, or to connect a Linux application to another socket application running in a VM guest. AF_IUCV is using a different addressing scheme and therefore there is no chance to use existing drivers like netiucv for such functionality. The patch set consists of following patches: [1/7] [S390]: Rewrite of the IUCV base code, part 1 [2/7] [S390]: Rewrite of the IUCV base code, part 2 [3/7] [S390]: Adapt monreader driver to new IUCV API [4/7] [S390]: Adapt vmlogrdr driver to new IUCV API [5/7] [S390]: Adapt netiucv driver to new IUCV API [6/7] [S390]: Adapt special message interface to new IUCV API [7/7] [S390]: Add AF_IUCV socket support Basically it will remove the old IUCV base code from drivers/s390/net, adds the new rewritten one to net/iucv. Then all iucv based device drivers like monreader, vmlogrdr, netiucv and special message interface will be adapted to the new IUCV API. The last patch then adds the AF_IUCV socket support residing in net/iucv either. I am asking for integration now and of course code review comments and suggestions are very appreciated . Thank you very much Frank - 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/7] [S390]: Adapt special message interface to new IUCV API
From: Martin Schwidefsky [EMAIL PROTECTED]
Adapt special message interface to new IUCV API
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
drivers/s390/net/smsgiucv.c | 147 ++-
1 files changed, 74 insertions(+), 73 deletions(-)
diff --git a/drivers/s390/net/smsgiucv.c b/drivers/s390/net/smsgiucv.c
index b8179c2..3ccca58 100644
--- a/drivers/s390/net/smsgiucv.c
+++ b/drivers/s390/net/smsgiucv.c
@@ -1,7 +1,7 @@
/*
* IUCV special message driver
*
- * Copyright (C) 2003 IBM Deutschland Entwicklung GmbH, IBM Corporation
+ * Copyright 2003 IBM Deutschland Entwicklung GmbH, IBM Corporation
* Author(s): Martin Schwidefsky ([EMAIL PROTECTED])
*
* This program is free software; you can redistribute it and/or modify
@@ -23,10 +23,10 @@ #include linux/module.h
#include linux/init.h
#include linux/errno.h
#include linux/device.h
+#include net/iucv/iucv.h
#include asm/cpcmd.h
#include asm/ebcdic.h
-
-#include iucv.h
+#include smsgiucv.h
struct smsg_callback {
struct list_head list;
@@ -39,38 +39,46 @@ MODULE_AUTHOR
((C) 2003 IBM Corporation by Martin Schwidefsky ([EMAIL PROTECTED]));
MODULE_DESCRIPTION (Linux for S/390 IUCV special message driver);
-static iucv_handle_t smsg_handle;
-static unsigned short smsg_pathid;
+static struct iucv_path *smsg_path;
+
static DEFINE_SPINLOCK(smsg_list_lock);
static struct list_head smsg_list = LIST_HEAD_INIT(smsg_list);
-static void
-smsg_connection_complete(iucv_ConnectionComplete *eib, void *pgm_data)
+static int smsg_path_pending(struct iucv_path *, u8 ipvmid[8], u8 ipuser[16]);
+static void smsg_message_pending(struct iucv_path *, struct iucv_message *);
+
+static struct iucv_handler smsg_handler = {
+ .path_pending= smsg_path_pending,
+ .message_pending = smsg_message_pending,
+};
+
+static int smsg_path_pending(struct iucv_path *path, u8 ipvmid[8],
+u8 ipuser[16])
{
+ if (strncmp(ipvmid, *MSG, sizeof(ipvmid)) != 0)
+ return -EINVAL;
+ /* Path pending from *MSG. */
+ return iucv_path_accept(path, smsg_handler, SMSGIUCV, NULL);
}
-
-static void
-smsg_message_pending(iucv_MessagePending *eib, void *pgm_data)
+static void smsg_message_pending(struct iucv_path *path,
+struct iucv_message *msg)
{
struct smsg_callback *cb;
- unsigned char *msg;
+ unsigned char *buffer;
unsigned char sender[9];
- unsigned short len;
int rc, i;
- len = eib-ln1msg2.ipbfln1f;
- msg = kmalloc(len + 1, GFP_ATOMIC|GFP_DMA);
- if (!msg) {
- iucv_reject(eib-ippathid, eib-ipmsgid, eib-iptrgcls);
+ buffer = kmalloc(msg-length + 1, GFP_ATOMIC | GFP_DMA);
+ if (!buffer) {
+ iucv_message_reject(path, msg);
return;
}
- rc = iucv_receive(eib-ippathid, eib-ipmsgid, eib-iptrgcls,
- msg, len, NULL, NULL, NULL);
+ rc = iucv_message_receive(path, msg, 0, buffer, msg-length, NULL);
if (rc == 0) {
- msg[len] = 0;
- EBCASC(msg, len);
- memcpy(sender, msg, 8);
+ buffer[msg-length] = 0;
+ EBCASC(buffer, msg-length);
+ memcpy(sender, buffer, 8);
sender[8] = 0;
/* Remove trailing whitespace from the sender name. */
for (i = 7; i = 0; i--) {
@@ -80,27 +88,17 @@ smsg_message_pending(iucv_MessagePending
}
spin_lock(smsg_list_lock);
list_for_each_entry(cb, smsg_list, list)
- if (strncmp(msg + 8, cb-prefix, cb-len) == 0) {
- cb-callback(sender, msg + 8);
+ if (strncmp(buffer + 8, cb-prefix, cb-len) == 0) {
+ cb-callback(sender, buffer + 8);
break;
}
spin_unlock(smsg_list_lock);
}
- kfree(msg);
+ kfree(buffer);
}
-static iucv_interrupt_ops_t smsg_ops = {
- .ConnectionComplete = smsg_connection_complete,
- .MessagePending = smsg_message_pending,
-};
-
-static struct device_driver smsg_driver = {
- .name = SMSGIUCV,
- .bus = iucv_bus,
-};
-
-int
-smsg_register_callback(char *prefix, void (*callback)(char *from, char *str))
+int smsg_register_callback(char *prefix,
+ void (*callback)(char *from, char *str))
{
struct smsg_callback *cb;
@@ -110,18 +108,18 @@ smsg_register_callback(char *prefix, voi
cb-prefix = prefix;
cb-len = strlen(prefix);
cb-callback = callback;
- spin_lock(smsg_list_lock);
+ spin_lock_bh(smsg_list_lock);
list_add_tail(cb-list, smsg_list);
- spin_unlock(smsg_list_lock);
+
[PATCH 3/7] [S390]: Adapt monreader driver to new IUCV API
From: Martin Schwidefsky [EMAIL PROTECTED]
Adapt monreader character device driver to new IUCV API
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
drivers/s390/char/monreader.c | 218 +++--
1 files changed, 101 insertions(+), 117 deletions(-)
diff --git a/drivers/s390/char/monreader.c b/drivers/s390/char/monreader.c
index a138b15..3a1a958 100644
--- a/drivers/s390/char/monreader.c
+++ b/drivers/s390/char/monreader.c
@@ -3,7 +3,7 @@
*
* Character device driver for reading z/VM *MONITOR service records.
*
- * Copyright (C) 2004 IBM Corporation, IBM Deutschland Entwicklung GmbH.
+ * Copyright 2004 IBM Corporation, IBM Deutschland Entwicklung GmbH.
*
* Author: Gerald Schaefer [EMAIL PROTECTED]
*/
@@ -22,7 +22,7 @@ #include asm/uaccess.h
#include asm/ebcdic.h
#include asm/extmem.h
#include linux/poll.h
-#include ../net/iucv.h
+#include net/iucv/iucv.h
//#define MON_DEBUG/* Debug messages on/off */
@@ -50,14 +50,13 @@ static char mon_dcss_name[9] = MONDCSS\
struct mon_msg {
u32 pos;
u32 mca_offset;
- iucv_MessagePending local_eib;
+ struct iucv_message msg;
char msglim_reached;
char replied_msglim;
};
struct mon_private {
- u16 pathid;
- iucv_handle_t iucv_handle;
+ struct iucv_path *path;
struct mon_msg *msg_array[MON_MSGLIM];
unsigned int write_index;
unsigned int read_index;
@@ -75,8 +74,6 @@ static unsigned long mon_dcss_end;
static DECLARE_WAIT_QUEUE_HEAD(mon_read_wait_queue);
static DECLARE_WAIT_QUEUE_HEAD(mon_conn_wait_queue);
-static u8 iucv_host[8] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
-
static u8 user_data_connect[16] = {
/* Version code, must be 0x01 for shared mode */
0x01,
@@ -100,8 +97,7 @@ static u8 user_data_sever[16] = {
* Create the 8 bytes EBCDIC DCSS segment name from
* an ASCII name, incl. padding
*/
-static inline void
-dcss_mkname(char *ascii_name, char *ebcdic_name)
+static inline void dcss_mkname(char *ascii_name, char *ebcdic_name)
{
int i;
@@ -119,8 +115,7 @@ dcss_mkname(char *ascii_name, char *ebcd
* print appropriate error message for segment_load()/segment_type()
* return code
*/
-static void
-mon_segment_warn(int rc, char* seg_name)
+static void mon_segment_warn(int rc, char* seg_name)
{
switch (rc) {
case -ENOENT:
@@ -166,44 +161,37 @@ mon_segment_warn(int rc, char* seg_name)
}
}
-static inline unsigned long
-mon_mca_start(struct mon_msg *monmsg)
+static inline unsigned long mon_mca_start(struct mon_msg *monmsg)
{
- return monmsg-local_eib.ln1msg1.iprmmsg1_u32;
+ return *(u32 *) monmsg-msg.rmmsg;
}
-static inline unsigned long
-mon_mca_end(struct mon_msg *monmsg)
+static inline unsigned long mon_mca_end(struct mon_msg *monmsg)
{
- return monmsg-local_eib.ln1msg2.ipbfln1f;
+ return *(u32 *) monmsg-msg.rmmsg[4];
}
-static inline u8
-mon_mca_type(struct mon_msg *monmsg, u8 index)
+static inline u8 mon_mca_type(struct mon_msg *monmsg, u8 index)
{
return *((u8 *) mon_mca_start(monmsg) + monmsg-mca_offset + index);
}
-static inline u32
-mon_mca_size(struct mon_msg *monmsg)
+static inline u32 mon_mca_size(struct mon_msg *monmsg)
{
return mon_mca_end(monmsg) - mon_mca_start(monmsg) + 1;
}
-static inline u32
-mon_rec_start(struct mon_msg *monmsg)
+static inline u32 mon_rec_start(struct mon_msg *monmsg)
{
return *((u32 *) (mon_mca_start(monmsg) + monmsg-mca_offset + 4));
}
-static inline u32
-mon_rec_end(struct mon_msg *monmsg)
+static inline u32 mon_rec_end(struct mon_msg *monmsg)
{
return *((u32 *) (mon_mca_start(monmsg) + monmsg-mca_offset + 8));
}
-static inline int
-mon_check_mca(struct mon_msg *monmsg)
+static inline int mon_check_mca(struct mon_msg *monmsg)
{
if ((mon_rec_end(monmsg) = mon_rec_start(monmsg)) ||
(mon_rec_start(monmsg) mon_dcss_start) ||
@@ -221,20 +209,17 @@ mon_check_mca(struct mon_msg *monmsg)
return 0;
}
-static inline int
-mon_send_reply(struct mon_msg *monmsg, struct mon_private *monpriv)
+static inline int mon_send_reply(struct mon_msg *monmsg,
+struct mon_private *monpriv)
{
- u8 prmmsg[8];
int rc;
P_DEBUG(read, REPLY: pathid = 0x%04X, msgid = 0x%08X, trgcls =
0x%08X\n\n,
- monmsg-local_eib.ippathid, monmsg-local_eib.ipmsgid,
- monmsg-local_eib.iptrgcls);
- rc = iucv_reply_prmmsg(monmsg-local_eib.ippathid,
- monmsg-local_eib.ipmsgid,
- monmsg-local_eib.iptrgcls,
- 0, prmmsg);
+ monpriv-path-pathid, monmsg-msg.id, monmsg-msg.class);
+
+ rc = iucv_message_reply(monpriv-path, monmsg-msg,
+
[PATCH 4/7] [S390]: Adapt vmlogrdr driver to new IUCV API
From: Martin Schwidefsky [EMAIL PROTECTED]
Adapt vmlogrdr character device driver to new IUCV API
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
drivers/s390/char/vmlogrdr.c | 284 +++---
1 files changed, 129 insertions(+), 155 deletions(-)
diff --git a/drivers/s390/char/vmlogrdr.c b/drivers/s390/char/vmlogrdr.c
index 6cb2304..8432a76 100644
--- a/drivers/s390/char/vmlogrdr.c
+++ b/drivers/s390/char/vmlogrdr.c
@@ -3,7 +3,7 @@
* character device driver for reading z/VM system service records
*
*
- * Copyright (C) 2004 IBM Corporation
+ * Copyright 2004 IBM Corporation
* character device driver for reading z/VM system service records,
* Version 1.0
* Author(s): Xenia Tkatschow [EMAIL PROTECTED]
@@ -21,7 +21,7 @@ #include asm/uaccess.h
#include asm/cpcmd.h
#include asm/debug.h
#include asm/ebcdic.h
-#include ../net/iucv.h
+#include net/iucv/iucv.h
#include linux/kmod.h
#include linux/cdev.h
#include linux/device.h
@@ -60,12 +60,11 @@ struct vmlogrdr_priv_t {
char system_service[8];
char internal_name[8];
char recording_name[8];
- u16 pathid;
+ struct iucv_path *path;
int connection_established;
int iucv_path_severed;
- iucv_MessagePending local_interrupt_buffer;
+ struct iucv_message local_interrupt_buffer;
atomic_t receive_ready;
- iucv_handle_t iucv_handle;
int minor_num;
char * buffer;
char * current_position;
@@ -97,40 +96,21 @@ static struct file_operations vmlogrdr_f
};
-static u8 iucvMagic[16] = {
- 0xF0, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40,
- 0xF0, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40
-};
+static void vmlogrdr_iucv_path_complete(struct iucv_path *, u8 ipuser[16]);
+static void vmlogrdr_iucv_path_severed(struct iucv_path *, u8 ipuser[16]);
+static void vmlogrdr_iucv_message_pending(struct iucv_path *,
+ struct iucv_message *);
-static u8 mask[] = {
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+static struct iucv_handler vmlogrdr_iucv_handler = {
+ .path_complete = vmlogrdr_iucv_path_complete,
+ .path_severed= vmlogrdr_iucv_path_severed,
+ .message_pending = vmlogrdr_iucv_message_pending,
};
-static u8 iucv_host[8] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
-
-
-static void
-vmlogrdr_iucv_ConnectionComplete(iucv_ConnectionComplete *eib, void *pgm_data);
-static void
-vmlogrdr_iucv_ConnectionSevered(iucv_ConnectionSevered *eib, void *pgm_data);
-static void
-vmlogrdr_iucv_MessagePending(iucv_MessagePending *eib, void *pgm_data);
-
-
-static iucv_interrupt_ops_t vmlogrdr_iucvops = {
- .ConnectionComplete = vmlogrdr_iucv_ConnectionComplete,
- .ConnectionSevered = vmlogrdr_iucv_ConnectionSevered,
- .MessagePending = vmlogrdr_iucv_MessagePending,
-};
-
-
-DECLARE_WAIT_QUEUE_HEAD(conn_wait_queue);
-DECLARE_WAIT_QUEUE_HEAD(read_wait_queue);
+static DECLARE_WAIT_QUEUE_HEAD(conn_wait_queue);
+static DECLARE_WAIT_QUEUE_HEAD(read_wait_queue);
/*
* pointer to system service private structure
@@ -177,28 +157,29 @@ static struct cdev *vmlogrdr_cdev = NUL
static int recording_class_AB;
-static void
-vmlogrdr_iucv_ConnectionComplete (iucv_ConnectionComplete * eib,
- void * pgm_data)
+static void vmlogrdr_iucv_path_complete(struct iucv_path *path, u8 ipuser[16])
{
- struct vmlogrdr_priv_t * logptr = pgm_data;
+ struct vmlogrdr_priv_t * logptr = path-private;
+
spin_lock(logptr-priv_lock);
logptr-connection_established = 1;
spin_unlock(logptr-priv_lock);
wake_up(conn_wait_queue);
- return;
}
-static void
-vmlogrdr_iucv_ConnectionSevered (iucv_ConnectionSevered * eib, void * pgm_data)
+static void vmlogrdr_iucv_path_severed(struct iucv_path *path, u8 ipuser[16])
{
- u8 reason = (u8) eib-ipuser[8];
- struct vmlogrdr_priv_t * logptr = pgm_data;
+ struct vmlogrdr_priv_t * logptr = path-private;
+ u8 reason = (u8) ipuser[8];
printk (KERN_ERR vmlogrdr: connection severed with
reason %i\n, reason);
+ iucv_path_sever(path, NULL);
+ kfree(path);
+ logptr-path = NULL;
+
spin_lock(logptr-priv_lock);
logptr-connection_established = 0;
logptr-iucv_path_severed = 1;
@@ -210,10 +191,10 @@ vmlogrdr_iucv_ConnectionSevered (iucv_Co
}
-static void
-vmlogrdr_iucv_MessagePending (iucv_MessagePending * eib, void * pgm_data)
+static void vmlogrdr_iucv_message_pending(struct iucv_path *path,
+ struct iucv_message *msg)
{
- struct vmlogrdr_priv_t * logptr =
[PATCH 7/7] [S390]: Add AF_IUCV socket support
From: Jennifer Hunt[EMAIL PROTECTED]
This patch adds AF_IUCV socket support.
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
arch/s390/defconfig|1
include/linux/net.h|2
include/linux/socket.h |4
include/net/iucv/af_iucv.h | 106
net/iucv/Kconfig |8
net/iucv/Makefile |1
net/iucv/af_iucv.c | 1077
7 files changed, 1197 insertions(+), 2 deletions(-)
diff --git a/arch/s390/defconfig b/arch/s390/defconfig
index 56fe005..11a8049 100644
--- a/arch/s390/defconfig
+++ b/arch/s390/defconfig
@@ -178,6 +178,7 @@ # CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_NET_KEY=y
CONFIG_IUCV=m
+CONFIG_AFIUCV=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
diff --git a/include/linux/net.h b/include/linux/net.h
index f28d8a2..4db21e6 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -24,7 +24,7 @@ #include asm/socket.h
struct poll_table_struct;
struct inode;
-#define NPROTO 32 /* should be enough for now.. */
+#define NPROTO 33 /* should be enough for now.. */
#define SYS_SOCKET 1 /* sys_socket(2)*/
#define SYS_BIND 2 /* sys_bind(2) */
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 92cd38e..fcd35a2 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -187,7 +187,8 @@ #define AF_WANPIPE 25 /* Wanpipe API Soc
#define AF_LLC 26 /* Linux LLC*/
#define AF_TIPC30 /* TIPC sockets */
#define AF_BLUETOOTH 31 /* Bluetooth sockets*/
-#define AF_MAX 32 /* For now.. */
+#define AF_IUCV32 /* IUCV sockets */
+#define AF_MAX 33 /* For now.. */
/* Protocol families, same as address families. */
#define PF_UNSPEC AF_UNSPEC
@@ -220,6 +221,7 @@ #define PF_WANPIPE AF_WANPIPE
#define PF_LLC AF_LLC
#define PF_TIPCAF_TIPC
#define PF_BLUETOOTH AF_BLUETOOTH
+#define PF_IUCVAF_IUCV
#define PF_MAX AF_MAX
/* Maximum queue length specifiable by listen. */
diff --git a/include/net/iucv/af_iucv.h b/include/net/iucv/af_iucv.h
new file mode 100644
index 000..04d1abb
--- /dev/null
+++ b/include/net/iucv/af_iucv.h
@@ -0,0 +1,106 @@
+/*
+ * Copyright 2006 IBM Corporation
+ * IUCV protocol stack for Linux on zSeries
+ * Version 1.0
+ * Author(s): Jennifer Hunt [EMAIL PROTECTED]
+ *
+ */
+
+#ifndef __AFIUCV_H
+#define __AFIUCV_H
+
+#include asm/types.h
+#include asm/byteorder.h
+#include linux/list.h
+#include linux/poll.h
+#include linux/socket.h
+
+#ifndef AF_IUCV
+#define AF_IUCV32
+#define PF_IUCVAF_IUCV
+#endif
+
+/* Connection and socket states */
+enum {
+ IUCV_CONNECTED = 1,
+ IUCV_OPEN,
+ IUCV_BOUND,
+ IUCV_LISTEN,
+ IUCV_SEVERED,
+ IUCV_DISCONN,
+ IUCV_CLOSED
+};
+
+#define IUCV_QUEUELEN_DEFAULT 65535
+#define IUCV_CONN_TIMEOUT (HZ * 40)
+#define IUCV_DISCONN_TIMEOUT (HZ * 2)
+#define IUCV_CONN_IDLE_TIMEOUT (HZ * 60)
+#define IUCV_BUFSIZE_DEFAULT 32768
+
+/* IUCV socket address */
+struct sockaddr_iucv {
+ sa_family_t siucv_family;
+ unsigned short siucv_port; /* Reserved */
+ unsigned intsiucv_addr; /* Reserved */
+ charsiucv_nodeid[8];/* Reserved */
+ charsiucv_user_id[8]; /* Guest User Id */
+ charsiucv_name[8]; /* Application Name */
+};
+
+
+/* Common socket structures and functions */
+
+#define iucv_sk(__sk) ((struct iucv_sock *) __sk)
+
+struct iucv_sock {
+ struct sock sk;
+ charsrc_user_id[8];
+ charsrc_name[8];
+ chardst_user_id[8];
+ chardst_name[8];
+ struct list_headaccept_q;
+ struct sock *parent;
+ struct iucv_path*path;
+ struct sk_buff_head send_skb_q;
+ unsigned intsend_tag;
+};
+
+struct iucv_sock_list {
+ struct hlist_head head;
+ rwlock_t lock;
+ atomic_t autobind_name;
+};
+
+static void iucv_sock_destruct(struct sock *sk);
+static void iucv_sock_cleanup_listen(struct sock *parent);
+static void iucv_sock_kill(struct sock *sk);
+static void iucv_sock_close(struct sock *sk);
+static int iucv_sock_create(struct socket *sock, int proto);
+static int iucv_sock_bind(struct socket *sock, struct sockaddr *addr,
+ int addr_len);
+static int iucv_sock_connect(struct socket *sock, struct sockaddr *addr,
+ int alen, int
Re: (usagi-core 32165) Re: [RFC][PATCH][XFRM][4/5] extension to XFRM for dynamic endpoint update (MIGRATE)
On Thu, 1 Feb 2007 09:50:00 -0500 (EST) James Morris [EMAIL PROTECTED] wrote: On Thu, 1 Feb 2007, Shinta Sugimoto wrote: + /* allow IPSEC_PROTO_ANY to match all protocols */ + //sel.proto = pfkey_proto_to_xfrm(sa-sadb_address_proto); + sel.proto = sa-sadb_address_proto; Which one is correct ? :-) Thank you for point this out. The following should be correct. sel.proto = pfkey_proto_to_xfrm(sa-sadb_address_proto); + /* allow IPSEC_PROTO_ANY to match all protocols */ + //sel.proto = pfkey_proto_to_xfrm(sa-sadb_address_proto); + sel.proto = sa-sadb_address_proto; ... Same for this one. I will fix them. Regards, Shinta - 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: [RFC][PATCH][XFRM][1/5] extension to XFRM for dynamic endpoint update (MIGRATE)
On Fri, 2 Feb 2007, Shinta Sugimoto wrote: +EXPORT_SYMBOL(xfrm_state_clone); Why not EXPORT_SYMBOL_GPL ? (for all of your exports). Actually I don't have specific preference on either EXPORT_SYMBOL or EXPORT_SYMBOL_GPL. It seemed to me that other functions defined in files under net/xfrm/ are using EXPORT_SYMBOL, so I followed that. Hmm, you're right, most of them are not _GPL. Do you think EXPORT_SYMBOL_GPL is more appropriate in this case? Well, I would have thought that users of xfrm were generally derivative of the kernel, but it doesn't make much sense to have only a couple of symbols exported as GPL, so probably keep it the way you already have it. - James -- James Morris [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: [PATCH 2.6.20 1/5] s2io: Making LRO and UFO as module loadable parameter.
Sivakumar Subramani wrote: This patch adds two load parameters napi and ufo. Previously NAPI was compilation option with these changes wan enable disable NAPI using load parameter. Also we are introducing ufo load parameter to enable/disable ufo feature Signed-off-by: Sivakumar Subramani [EMAIL PROTECTED] applied patches 1-5, yay :) - 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] [v4] PA Semi PWRficient Ethernet driver
Olof Johansson wrote: Driver for the PA Semi PWRficient on-chip Ethernet (1/10G) Basic enablement, will be complemented with performance enhancements over time. PHY support will be added as well. Signed-off-by: Olof Johansson [EMAIL PROTECTED] patch applied. You may now send diffs for all future changes 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 1/1] NetXen: Fixes for ppc architecture.
Amit S. Kale wrote: NetXen: Fixes for ppc architecture. Signed-off-by: Amit S. Kale [EMAIL PROTECTED] --- Sorry, I wanted to send only one patch so please ignore [PATCH 0/2] in the subject of my last mail. It should be [PATCH 0/1]. netxen_nic.h | 98 -- netxen_nic_hw.c | 31 - netxen_nic_init.c | 19 +- netxen_nic_main.c |7 ++- netxen_nic_niu.c |2 - 5 files changed, 91 insertions(+), 66 deletions(-) Patch does not apply to latest vanilla linux-2.6.git: [EMAIL PROTECTED] netdev-2.6]$ git-am --signoff --utf8 /g/tmp/mbox Applying 'NetXen: Fixes for ppc architecture.' error: patch failed: drivers/net/netxen/netxen_nic.h:246 error: drivers/net/netxen/netxen_nic.h: patch does not apply error: patch failed: drivers/net/netxen/netxen_nic_hw.c:236 error: drivers/net/netxen/netxen_nic_hw.c: patch does not apply error: patch failed: drivers/net/netxen/netxen_nic_init.c:690 error: drivers/net/netxen/netxen_nic_init.c: patch does not apply error: patch failed: drivers/net/netxen/netxen_nic_main.c:818 error: drivers/net/netxen/netxen_nic_main.c: patch does not apply Patch failed at 0001. When you have resolved this problem run git-am --resolved. If you would prefer to skip this patch, instead run git-am --skip. - 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 -FIX] e100: fix napi ifdefs removing needed code
Auke Kok wrote: e100: fix napi ifdefs removing needed code From: Auke Kok [EMAIL PROTECTED] The e100 driver is NAPI mode only. We need to netif_poll_disable during suspend and shutdown. The non-NAPI driver code was removed and is only avaiable in the out-of-tree e100 kernel driver. Signed-off-by: Auke Kok [EMAIL PROTECTED] applied - 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] spidernet : fix memory leak in spider_net_stop
Jens Osterkamp wrote: We forget to call spider_net_free_rx_chain_contents which does the actual dev_kfree_skb. New skbs are allocated from skbuff_head_cache on each ifconfig up letting the cache grow infinitely. This patch fixes it. Signed-off-by: Jens Osterkamp [EMAIL PROTECTED] applied - 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: [RFC][PATCH][XFRM][0/5] extension for XFRM databases
Hello, On Fri, 2007-02-02 at 20:25 +0900, Shinta Sugimoto wrote: In the design phase, we sorted out the requirements as below: (1) Overhead of userland - kernel interaction message exchange should be kept minimum. (2) There should not be too much requirement for user application to leverage the feature (dynamic update of endpoint). More specifically, we don't want to expect the user application to have detailed information of IPsec security association (i.e. SPI). (3) There should not be negative impact on the existing software which is based on PF_KEYv2 (RFC2367). Firstly, if we use the existing messages for updating SPD and SAD, we simply need 2 pairs of request/response exchange between the userland and kernel for updating a single endpoint. This is not ideal from the perspective of (1). Ok, if i understand you correctly: Instead of having from userland one message for updating SAD and another for updating SPD, you have a single message which updates both? Secondly, we need to be careful about updating the endpoint address because it may invoke unexpected signaling (ACQUIRE) to the user application. Imagine you update SPD and SAD sequentially while there is an outbound flow going on. The kernel may end up with triggering the userland application by unexpected ACQUIRE message due to the absence of SAD entry. In order to avoid this problem, we need a sort of atomic update of SPD and SAD entries. XFRM_MSG_MIGRATE is designed and implemented in a way that unexpected ACQUIRE would never occur. Ok, this is sensible - it could be achieved with two multipart messages in netlink; but a single message is better. Thirdly, we also need to pay attention to the PF_KEYv2 spec. XFRM_MSG_UPDSA is derived from SADB_UPDATE message in PF_KEYv2. According to the spec, the semantics of SADB_UPDATE is to add a new security association with the information provided by previous SADB_GETSPI message. We think it's not a good idea to overload the semantics of SADB_UPDATE message because it may confuse legacy software from the perspective of (3). Moreover, caller of SADB_UPDATE should specify SPI, source address, and destination address, which is a bit problematic from the perspective of (2). We really dont have this issue with xfrm side. I think that PF_KEYv2 is just a dinosaur that needs to be extinct. Continuing to bandaid around it is converting into a mammoth. I found your first two explanation more reasonable, but not this one. From the above reasons, we decided to extend XFRM/PF_KEYv2 for dynamic update of the endpoint. Please note that the mechanism is useful not only for Mobile IPv6 but also for Mobile VPN scenario. Can you explain what you mean by this last part? There are many ways to achieve mobile VPN - is the end client aware? Does this make sense? Yes, I think I see the logic behind your design. To be 100% convinced, depends if your answer to the first question i asked is yes. cheers, jamal - 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] mm: fix page_mkclean_one
Mark Groves wrote: Hi, I have been been seeing a problem when using sendfile repeatedly on an SMP server, which I believe is related to the problem that was discovered recently with marking dirty pages. The bug, as well as a test script, is listed at http://bugzilla.kernel.org/show_bug.cgi?id=7650. Currently, we're experiencing errors where part of a previous packet is being sent out rather than the current packet. I have applied the patch Linus posted to a 2.6.19 kernel but am still getting the problem. So I am wondering if there are any other places in the kernel which mark pages as dirty which might require a similar patch? Your issue is not related, firstly because the page_mkclean bug did not exist before 2.6.19 kernels. Anyway, I had a look at your bugzilla test-case and managed to slim it down to something that easily shows what the problem is (available on request) -- the problem is that recipient of the sendfile is seeing modifications that occur to the source file _after_ the sender has completed the sendfile, because the file pages are not copied but queued. I think the usual approach to what you are trying to do is to set TCP_CORK, then write(2) the header into the socket, then sendfile directly from the file you want. Another approach I guess is to implement an ack in your userland protocol so you do not modify the sendfile source file until the client acks that it has all the data. I'm not sure if there are any other usual ways to do this (ie. a barrier for sendfile, to ensure it will not pick up future modifications to the file). netdev cc'ed, someone there might have additional comments. Please close this bug if/when you are satisfied it is not a kernel problem. Thanks, Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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: sky2 hangs
Hello, Next time sky2 hangs on me I'll try to reset the PHY and see if that helps. I can usually trigger the hang by doing a couple of ifconfig up/down on the interface, though I'm not getting any error message from the driver when that happens. same for me. In dmesg is absolut nothing. I change my fix script, too. To see if that is enough to resolv the problem. Thomas - 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: sky2 hangs
Thomas Glanzmann [EMAIL PROTECTED] wrote: Hi, I can reproduce the problem now (on mac mini). Interestingly it seems to whack the whole ethernet switch when it happens. I've observed that too, on a cheap DLink switch. Next time sky2 hangs on me I'll try to reset the PHY and see if that helps. I can usually trigger the hang by doing a couple of ifconfig up/down on the interface, though I'm not getting any error message from the driver when that happens. JB. -- Julien BLACHE http://www.jblache.org [EMAIL PROTECTED] GPG KeyID 0xF5D65169 - 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: sky2 hangs
Thomas Glanzmann wrote: Hello, Next time sky2 hangs on me I'll try to reset the PHY and see if that helps. I can usually trigger the hang by doing a couple of ifconfig up/down on the interface, though I'm not getting any error message from the driver when that happens. same for me. In dmesg is absolut nothing. I change my fix script, too. To see if that is enough to resolv the problem. Well, ethtool -r eth0 did not work for me. :( This time I got nothing in the log. When I say ethtool -r eth0, I have this: sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control both But the interface stays down. (Maybe the other end got confused?) - Cs. - 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
/async open+send/ Re: [take35 10/10] kevent: Kevent based AIO (aio_sendfile()/aio_sendfile_path()).
On Thu, Feb 01, 2007 at 01:12:34PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
Kevent based AIO (aio_sendfile()/aio_sendfile_path()).
aio_sendfile()/aio_sendfile_path() contains of two major parts: AIO
state machine and page processing code.
The former is just a small subsystem, which allows to queue callback
for theirs invocation in process' context on behalf of pool of kernel
threads. It allows to queue caches of callbacks to the local thread
or to any other specified. Each cache of callbacks is processed until
there are callbacks in it, callbacks can requeue themselfs into the
same cache.
Below patch, casted by discussion in lkml@ about micro-thread AIO.
Async sending and file closing are implemented already, I added
kaio_open() into state machine as example of what it can do, it was sync
before. It is an example only - kevent was asked to have feature-freeze
time.
Btw, could you please Cc: linux-fsdevel@ on AIO patchsets too.
Thanks.
diff --git a/kernel/kevent/kevent_aio.c b/kernel/kevent/kevent_aio.c
index 9bb5e99..803e9ff 100644
--- a/kernel/kevent/kevent_aio.c
+++ b/kernel/kevent/kevent_aio.c
@@ -759,16 +759,15 @@ err_out_exit:
return err;
}
-asmlinkage long sys_aio_sendfile_path(int kevent_fd, int sock_fd,
- void __user *header, size_t header_size,
- char __user *filename, off_t offset, size_t count)
+static int kaio_open(struct kaio_req *req, int direct)
{
+ struct kaio_private *priv = req-priv;
+ char *filename = priv-sptr;
char *tmp = getname(filename);
int fd = PTR_ERR(tmp);
int flags = O_RDONLY, err;
struct nameidata nd;
struct file *file;
- struct kaio_req *req;
if (force_o_largefile())
flags = O_LARGEFILE;
@@ -795,25 +794,12 @@ asmlinkage long sys_aio_sendfile_path(int kevent_fd, int
sock_fd,
if (!file)
goto err_out_fdput;
- /* One reference will be released in sys_close(),
-* second one through req-destructor()
-*/
- atomic_inc(file-f_count);
-
- req = kaio_sendfile(kevent_fd, sock_fd, header, header_size,
- file, offset, count);
- if (!req) {
- err = -EINVAL;
- goto err_out_fput;
- }
-
fd_install(fd, file);
- return fd;
+ priv-sptr = file;
+
+ return 0;
-err_out_fput:
- fput(file);
- fput(file);
err_out_fdput:
put_unused_fd(fd);
err_out_put_name:
@@ -822,6 +808,67 @@ err_out_exit:
return err;
}
+asmlinkage long sys_aio_sendfile_path(int kevent_fd, int sock_fd,
+ void __user *header, size_t header_size,
+ char __user *filename, off_t offset, size_t count)
+{
+ struct kaio_req *req;
+ struct socket *sock;
+ struct kaio_private *priv;
+ int err;
+
+ sock = sockfd_lookup(sock_fd, err);
+ if (!sock)
+ goto err_out_exit;
+
+ priv = kmem_cache_alloc(kaio_priv_cache, GFP_KERNEL);
+ if (!priv)
+ goto err_out_sput;
+
+ priv-sptr = filename;
+ priv-dptr = sock;
+ priv-offset = offset;
+ priv-count = count;
+ priv-processed = offset;
+ priv-limit = 128;
+ priv-header = header;
+ priv-header_size = header_size;
+
+ req = kaio_add_call(NULL, kaio_open, -1, GFP_KERNEL);
+ if (!req)
+ goto err_out_free;
+
+ kaio_append_call(req, kaio_read_send_pages);
+
+ req-destructor = kaio_destructor;
+ req-priv = priv;
+
+ err = kaio_add_kevent(kevent_fd, req);
+
+ dprintk(%s: req: %p, priv: %p, call: %p [%p], offset: %Lu, processed:
%Lu, count: %Lu, err: %d.\n,
+ __func__, req, priv, kaio_read_send_pages,
+ kaio_read_send_pages, priv-offset, priv-processed,
priv-count, err);
+
+ if (err)
+ goto err_out_remove;
+
+ kaio_schedule_req(req);
+
+ return (long)req;
+
+err_out_remove:
+ /* It is safe to just free the object since it is guaranteed that it
was not
+* queued for processing.
+*/
+ kmem_cache_free(kaio_req_cache, req);
+err_out_free:
+ kmem_cache_free(kaio_priv_cache, priv);
+err_out_sput:
+ sockfd_put(sock);
+err_out_exit:
+ return -1;
+}
+
static int kevent_aio_callback(struct kevent *k)
{
struct kaio_req *req = k-event.ptr;
--
Evgeniy Polyakov
-
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]ip_auto_config bug in 2.6.20-rc6
On Thu, 2007-02-01 at 12:26 +0100, Joakim Tjernlund wrote:
The following commandline:
root=/dev/mtdblock6 rw rootfstype=jffs2
ip=192.168.1.10:::255.255.255.0:localhost.localdomain:eth1:off
console=ttyS0,115200
makes ip_auto_config fall back to DHCP and complain IP-Config: Incomplete
network configuration information.
depending on if CONFIG_IP_PNP_DHCP is set or not.
The only way I can make ip_auto_config accept my IP config is to add an entry
for the server IP:
ip=192.168.1.10:192.168.1.15::255.255.255.0:localhost.localdomain:eth1:off
I think this is a bug since I am not using a NFS root FS.
Jocke
The following patch fixes the above problem. This change was present in
2.4 but has been removed from 2.6, dunno why.
Signed-off-by: Joakim Tjernlund [EMAIL PROTECTED]
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 9f245de..b90479c 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1282,7 +1282,8 @@ static int __init ip_auto_config(void)
#ifdef CONFIG_ROOT_NFS
(MAJOR(ROOT_DEV) == UNNAMED_MAJOR
root_server_addr == NONE
- ic_servaddr == NONE) ||
+ ic_servaddr == NONE
+ ROOT_DEV == Root_NFS) ||
#endif
ic_first_dev-next) {
#ifdef IPCONFIG_DYNAMIC
-
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] mm: fix page_mkclean_one
On Fri, Feb 02, 2007 at 07:42:52PM +1100, Nick Piggin ([EMAIL PROTECTED]) wrote: Anyway, I had a look at your bugzilla test-case and managed to slim it down to something that easily shows what the problem is (available on request) -- the problem is that recipient of the sendfile is seeing modifications that occur to the source file _after_ the sender has completed the sendfile, because the file pages are not copied but queued. I think the usual approach to what you are trying to do is to set TCP_CORK, then write(2) the header into the socket, then sendfile directly from the file you want. Another approach I guess is to implement an ack in your userland protocol so you do not modify the sendfile source file until the client acks that it has all the data. Mark, don't you use e1000 or other scatter-gather capable nic with checksum offload? Likely yes. Actual data sucking in that case happens when packet is supposed to be transmitted by the NIC, not when sendfile() is returned. The same applies to the case, when you have fancy egress filtering. It is not allowed to modify pages until they are really transmitted, if you want data integrity. There are _no_ bugs in network or VFS cache in this test case. I'm not sure if there are any other usual ways to do this (ie. a barrier for sendfile, to ensure it will not pick up future modifications to the file). netdev cc'ed, someone there might have additional comments. Please close this bug if/when you are satisfied it is not a kernel problem. Thanks, Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -- Evgeniy Polyakov - 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 2.6.20-rc7 1/2] atl1: get rid of pci_module_init
Jay Cliburn wrote: From: Jay Cliburn [EMAIL PROTECTED] pci_module_init is deprecated. Use pci_register_driver instead. Discovered by and modification suggested by Alan Cox. Signed-off-by: Jay Cliburn [EMAIL PROTECTED] applied 1-2 to #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
Re: [PATCH]ip_auto_config bug in 2.6.20-rc6
On Feb 2 2007 14:09, Joakim Tjernlund wrote: On Thu, 2007-02-01 at 12:26 +0100, Joakim Tjernlund wrote: The following commandline: root=/dev/mtdblock6 rw rootfstype=jffs2 ip=192.168.1.10:::255.255.255.0:localhost.localdomain:eth1:off console=ttyS0,115200 makes ip_auto_config fall back to DHCP and complain IP-Config: Incomplete network configuration information. depending on if CONFIG_IP_PNP_DHCP is set or not. The only way I can make ip_auto_config accept my IP config is to add an entry for the server IP: ip=192.168.1.10:192.168.1.15::255.255.255.0:localhost.localdomain:eth1:off I think this is a bug since I am not using a NFS root FS. I just wonder why IP_PNP has not been obsoleted and removed from the tree yet, given that initramfs is the advertised way to do so such things. Jan -- - 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: sky2 hangs
On 02-02-2007 12:53, Fagyal Csongor wrote: Thomas Glanzmann wrote: ... Next time sky2 hangs on me I'll try to reset the PHY and see if that helps. I can usually trigger the hang by doing a couple of ifconfig up/down on the interface, though I'm not getting any error message from the driver when that happens. same for me. In dmesg is absolut nothing. I change my fix script, too. To see if that is enough to resolv the problem. Well, ethtool -r eth0 did not work for me. :( This time I got nothing in the log. When I say ethtool -r eth0, I have this: sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control both But the interface stays down. (Maybe the other end got confused?) Hi, Is this with this yesterday sky2-tx-recover.patch applied? 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
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/e100.c |7 +--
drivers/net/netxen/netxen_nic.h | 136 +++
drivers/net/netxen/netxen_nic_ethtool.c | 22 +++---
drivers/net/netxen/netxen_nic_hw.c | 43 --
drivers/net/netxen/netxen_nic_hw.h | 74 +-
drivers/net/netxen/netxen_nic_init.c| 15 ++--
drivers/net/netxen/netxen_nic_isr.c |4 +-
drivers/net/netxen/netxen_nic_main.c|8 +-
drivers/net/netxen/netxen_nic_niu.c | 106
drivers/net/spider_net.c|2 +
10 files changed, 199 insertions(+), 218 deletions(-)
Al Viro (1):
netxen patches (trivial sparse annotations)
Auke Kok (1):
e100: fix napi ifdefs removing needed code
Jens Osterkamp (1):
spidernet : fix memory leak in spider_net_stop
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 3208dac..0cefef5 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2718,14 +2718,12 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
-#ifdef CONFIG_E100_NAPI
if (netif_running(netdev))
netif_poll_disable(nic-netdev);
-#endif
del_timer_sync(nic-watchdog);
netif_carrier_off(nic-netdev);
-
netif_device_detach(netdev);
+
pci_save_state(pdev);
if ((nic-flags wol_magic) | e100_asf(nic)) {
@@ -2761,16 +2759,13 @@ static int e100_resume(struct pci_dev *pdev)
}
#endif /* CONFIG_PM */
-
static void e100_shutdown(struct pci_dev *pdev)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
-#ifdef CONFIG_E100_NAPI
if (netif_running(netdev))
netif_poll_disable(nic-netdev);
-#endif
del_timer_sync(nic-watchdog);
netif_carrier_off(nic-netdev);
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 59324b1..e8598b8 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -239,49 +239,39 @@ extern unsigned long long netxen_dma_mask;
typedef u32 netxen_ctx_msg;
-#define _netxen_set_bits(config_word, start, bits, val){\
- unsigned long long mask = (((1ULL (bits)) - 1) (start)); \
- unsigned long long value = (val); \
- (config_word) = ~mask; \
- (config_word) |= (((value) (start)) mask); \
-}
-
#define netxen_set_msg_peg_id(config_word, val)\
- _netxen_set_bits(config_word, 0, 2, val)
+ ((config_word) = ~3, (config_word) |= val 3)
#define netxen_set_msg_privid(config_word) \
- set_bit(2, (unsigned long*)config_word)
+ ((config_word) |= 1 2)
#define netxen_set_msg_count(config_word, val) \
- _netxen_set_bits(config_word, 3, 15, val)
+ ((config_word) = ~(0x7fff3), (config_word) |= (val 0x7fff) 3)
#define netxen_set_msg_ctxid(config_word, val) \
- _netxen_set_bits(config_word, 18, 10, val)
+ ((config_word) = ~(0x3ff18), (config_word) |= (val 0x3ff) 18)
#define netxen_set_msg_opcode(config_word, val)\
- _netxen_set_bits(config_word, 28, 4, val)
+ ((config_word) = ~(0xf24), (config_word) |= (val 0xf) 24)
struct netxen_rcv_context {
- u32 rcv_ring_addr_lo;
- u32 rcv_ring_addr_hi;
- u32 rcv_ring_size;
- u32 rsrvd;
+ __le64 rcv_ring_addr;
+ __le32 rcv_ring_size;
+ __le32 rsrvd;
};
struct netxen_ring_ctx {
/* one command ring */
- u64 cmd_consumer_offset;
- u32 cmd_ring_addr_lo;
- u32 cmd_ring_addr_hi;
- u32 cmd_ring_size;
- u32 rsrvd;
+ __le64 cmd_consumer_offset;
+ __le64 cmd_ring_addr;
+ __le32 cmd_ring_size;
+ __le32 rsrvd;
/* three receive rings */
struct netxen_rcv_context rcv_ctx[3];
/* one status ring */
- u32 sts_ring_addr_lo;
- u32 sts_ring_addr_hi;
- u32 sts_ring_size;
+ __le64 sts_ring_addr;
+ __le32 sts_ring_size;
- u32 ctx_id;
+ __le32 ctx_id;
} __attribute__ ((aligned(64)));
/*
@@ -305,81 +295,85 @@ struct netxen_ring_ctx {
((cmd_desc)-port_ctxid |= ((var) 0x0F))
#define netxen_set_cmd_desc_flags(cmd_desc, val) \
- _netxen_set_bits((cmd_desc)-flags_opcode, 0, 7, val)
+ ((cmd_desc)-flags_opcode = ~cpu_to_le16(0x7f), \
+ (cmd_desc)-flags_opcode |= cpu_to_le16((val) 0x7f))
#define netxen_set_cmd_desc_opcode(cmd_desc, val) \
- _netxen_set_bits((cmd_desc)-flags_opcode, 7, 6, val)
+ ((cmd_desc)-flags_opcode = ~cpu_to_le16(0x3f7), \
+ (cmd_desc)-flags_opcode |= cpu_to_le16((val) (0x3f7)))
#define
Re: sky2 hangs
On Fri, Feb 02, 2007 at 02:43:11PM +0100, Jarek Poplawski wrote: On 02-02-2007 12:53, Fagyal Csongor wrote: Thomas Glanzmann wrote: ... Is this with this yesterday sky2-tx-recover.patch applied? I mean hung-ups - not ethtool. 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
Re: when having to acquire an SA, ipsec drops the packet
On Thursday, February 1 2007 6:44 pm, James Morris wrote: On Thu, 1 Feb 2007, Joy Latten wrote: When using labeled xfrms (xfrms that contain a security context), there is potential for a greater amount of SAs to be created than when using regular xfrms. An SA may be created every time a different security context is encountered in a particular traffic stream. This could be many if each networking app has its own security context, making current behavior problematic. Do you have any examples of how many SAs would need to be created on a typical system? It may not be the end of the world if an MLS box has to negotiate a whole bunch of SAs when it boots up. I agree that having an MLS box spend some extra time when starting the IKE daemon is probably not the end of the world. However, I'm a little concerned that it may not be possible to determine a good set of SAs to negotiate with only the SPD as a reference. For example, the current SELinux MLS policy has 16 sensitivity levels and 1024 categories. Ignoring the TE portion of the SELinux context for the sake of clarity you can easily see the large number of unique combinations, with each combination requiring a new SA. Granted, in the majority of these cases only a quick mode IKE negotiation would be required, which is much less expensive then having to do a full phase-1 negotiation, but due to the large numbers of SAs involved I believe it would still be quite a task. It also should be said that this procedure would need to be done for each SPD rule. I haven't thought about this too much yet, but I suspect proactively creating SAs is not going to be a practical solution. -- paul moore linux security @ hp - 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] skge: handle zero address at open
Some motherboards are broken and have no address set. Failing at probe time
prevents the device from ever being used (like to download a fixed BIOS).
Instead
warn on probe and check again when device is brought up. That way the address
can be set.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge.orig/drivers/net/skge.c
+++ skge/drivers/net/skge.c
@@ -2373,6 +2373,9 @@ static int skge_up(struct net_device *de
size_t rx_size, tx_size;
int err;
+ if (!is_valid_ether_addr(dev-dev_addr))
+ return -EINVAL;
+
if (netif_msg_ifup(skge))
printk(KERN_INFO PFX %s: enabling interface\n, dev-name);
@@ -3567,11 +3570,10 @@ static int __devinit skge_probe(struct p
if (!dev)
goto err_out_led_off;
+ /* Some motherboards are broken and has zero in ROM. */
if (!is_valid_ether_addr(dev-dev_addr)) {
- printk(KERN_ERR PFX %s: bad (zero?) ethernet address in rom\n,
+ printk(KERN_WARNING PFX %s: bad (zero?) ethernet address in
rom\n,
pci_name(pdev));
- err = -EIO;
- goto err_out_free_netdev;
}
err = register_netdev(dev);
--
-
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] skge: update
Several enhancements: WOL now works, use dev_printk macros and allow handling broken hardware better. -- - 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] skge: version 1.10
Mark this as 1.10 because WOL now works Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- skge.orig/drivers/net/skge.c +++ skge/drivers/net/skge.c @@ -42,7 +42,7 @@ #include skge.h #define DRV_NAME skge -#define DRV_VERSION1.9 +#define DRV_VERSION1.10 #define PFXDRV_NAME #define DEFAULT_TX_RING_SIZE 128 -- - 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/4] skge: WOL support
Add WOL support for Yukon chipsets in skge device.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/skge.c | 158 +
drivers/net/skge.h |2
2 files changed, 125 insertions(+), 35 deletions(-)
--- skge.orig/drivers/net/skge.c
+++ skge/drivers/net/skge.c
@@ -132,18 +132,93 @@ static void skge_get_regs(struct net_dev
}
/* Wake on Lan only supported on Yukon chips with rev 1 or above */
-static int wol_supported(const struct skge_hw *hw)
+static u32 wol_supported(const struct skge_hw *hw)
{
- return !((hw-chip_id == CHIP_ID_GENESIS ||
- (hw-chip_id == CHIP_ID_YUKON hw-chip_rev == 0)));
+ if (hw-chip_id == CHIP_ID_YUKON hw-chip_rev != 0)
+ return WAKE_MAGIC | WAKE_PHY;
+ else
+ return 0;
+}
+
+static u32 pci_wake_enabled(struct pci_dev *dev)
+{
+ int pm = pci_find_capability(dev, PCI_CAP_ID_PM);
+ u16 value;
+
+ /* If device doesn't support PM Capabilities, but request is to disable
+* wake events, it's a nop; otherwise fail */
+ if (!pm)
+ return 0;
+
+ pci_read_config_word(dev, pm + PCI_PM_PMC, value);
+
+ value = PCI_PM_CAP_PME_MASK;
+ value = ffs(PCI_PM_CAP_PME_MASK) - 1; /* First bit of mask */
+
+ return value != 0;
+}
+
+static void skge_wol_init(struct skge_port *skge)
+{
+ struct skge_hw *hw = skge-hw;
+ int port = skge-port;
+ enum pause_control save_mode;
+ u32 ctrl;
+
+ /* Bring hardware out of reset */
+ skge_write16(hw, B0_CTST, CS_RST_CLR);
+ skge_write16(hw, SK_REG(port, GMAC_LINK_CTRL), GMLC_RST_CLR);
+
+ skge_write8(hw, SK_REG(port, GPHY_CTRL), GPC_RST_CLR);
+ skge_write8(hw, SK_REG(port, GMAC_CTRL), GMC_RST_CLR);
+
+ /* Force to 10/100 skge_reset will re-enable on resume */
+ save_mode = skge-flow_control;
+ skge-flow_control = FLOW_MODE_SYMMETRIC;
+
+ ctrl = skge-advertising;
+ skge-advertising =
~(ADVERTISED_1000baseT_Half|ADVERTISED_1000baseT_Full);
+
+ skge_phy_reset(skge);
+
+ skge-flow_control = save_mode;
+ skge-advertising = ctrl;
+
+ /* Set GMAC to no flow control and auto update for speed/duplex */
+ gma_write16(hw, port, GM_GP_CTRL,
+ GM_GPCR_FC_TX_DIS|GM_GPCR_TX_ENA|GM_GPCR_RX_ENA|
+ GM_GPCR_DUP_FULL|GM_GPCR_FC_RX_DIS|GM_GPCR_AU_FCT_DIS);
+
+ /* Set WOL address */
+ memcpy_toio(hw-regs + WOL_REGS(port, WOL_MAC_ADDR),
+ skge-netdev-dev_addr, ETH_ALEN);
+
+ /* Turn on appropriate WOL control bits */
+ skge_write16(hw, WOL_REGS(port, WOL_CTRL_STAT), WOL_CTL_CLEAR_RESULT);
+ ctrl = 0;
+ if (skge-wol WAKE_PHY)
+ ctrl |= WOL_CTL_ENA_PME_ON_LINK_CHG|WOL_CTL_ENA_LINK_CHG_UNIT;
+ else
+ ctrl |= WOL_CTL_DIS_PME_ON_LINK_CHG|WOL_CTL_DIS_LINK_CHG_UNIT;
+
+ if (skge-wol WAKE_MAGIC)
+ ctrl |= WOL_CTL_ENA_PME_ON_MAGIC_PKT|WOL_CTL_ENA_MAGIC_PKT_UNIT;
+ else
+ ctrl |=
WOL_CTL_DIS_PME_ON_MAGIC_PKT|WOL_CTL_DIS_MAGIC_PKT_UNIT;;
+
+ ctrl |= WOL_CTL_DIS_PME_ON_PATTERN|WOL_CTL_DIS_PATTERN_UNIT;
+ skge_write16(hw, WOL_REGS(port, WOL_CTRL_STAT), ctrl);
+
+ /* block receiver */
+ skge_write8(hw, SK_REG(port, RX_GMF_CTRL_T), GMF_RST_SET);
}
static void skge_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
{
struct skge_port *skge = netdev_priv(dev);
- wol-supported = wol_supported(skge-hw) ? WAKE_MAGIC : 0;
- wol-wolopts = skge-wol ? WAKE_MAGIC : 0;
+ wol-supported = wol_supported(skge-hw);
+ wol-wolopts = skge-wol;
}
static int skge_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
@@ -151,23 +226,12 @@ static int skge_set_wol(struct net_devic
struct skge_port *skge = netdev_priv(dev);
struct skge_hw *hw = skge-hw;
- if (wol-wolopts != WAKE_MAGIC wol-wolopts != 0)
- return -EOPNOTSUPP;
-
- if (wol-wolopts == WAKE_MAGIC !wol_supported(hw))
+ if (wol-wolopts wol_supported(hw))
return -EOPNOTSUPP;
- skge-wol = wol-wolopts == WAKE_MAGIC;
-
- if (skge-wol) {
- memcpy_toio(hw-regs + WOL_MAC_ADDR, dev-dev_addr, ETH_ALEN);
-
- skge_write16(hw, WOL_CTRL_STAT,
-WOL_CTL_ENA_PME_ON_MAGIC_PKT |
-WOL_CTL_ENA_MAGIC_PKT_UNIT);
- } else
- skge_write16(hw, WOL_CTRL_STAT, WOL_CTL_DEFAULT);
-
+ skge-wol = wol-wolopts;
+ if (!netif_running(dev))
+ skge_wol_init(skge);
return 0;
}
@@ -3456,6 +3520,7 @@ static struct net_device *skge_devinit(s
skge-duplex = -1;
skge-speed = -1;
skge-advertising = skge_supported_modes(hw);
+ skge-wol = pci_wake_enabled(hw-pdev) ? wol_supported(hw) : 0;
[PATCH 2/4] skge: use dev_printk
Use dev_printk related macros for PCI related errors and warnings
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge.orig/drivers/net/skge.c
+++ skge/drivers/net/skge.c
@@ -2395,7 +2395,7 @@ static int skge_up(struct net_device *de
BUG_ON(skge-dma 7);
if ((u64)skge-dma 32 != ((u64) skge-dma + skge-mem_size) 32) {
- printk(KERN_ERR PFX pci_alloc_consistent region crosses 4G
boundary\n);
+ dev_err(hw-pdev-dev, pci_alloc_consistent region crosses 4G
boundary\n);
err = -EINVAL;
goto free_pci_mem;
}
@@ -3004,6 +3004,7 @@ static void skge_mac_intr(struct skge_hw
/* Handle device specific framing and timeout interrupts */
static void skge_error_irq(struct skge_hw *hw)
{
+ struct pci_dev *pdev = hw-pdev;
u32 hwstatus = skge_read32(hw, B0_HWE_ISRC);
if (hw-chip_id == CHIP_ID_GENESIS) {
@@ -3019,12 +3020,12 @@ static void skge_error_irq(struct skge_h
}
if (hwstatus IS_RAM_RD_PAR) {
- printk(KERN_ERR PFX Ram read data parity error\n);
+ dev_err(pdev-dev, Ram read data parity error\n);
skge_write16(hw, B3_RI_CTRL, RI_CLR_RD_PERR);
}
if (hwstatus IS_RAM_WR_PAR) {
- printk(KERN_ERR PFX Ram write data parity error\n);
+ dev_err(pdev-dev, Ram write data parity error\n);
skge_write16(hw, B3_RI_CTRL, RI_CLR_WR_PERR);
}
@@ -3035,38 +3036,38 @@ static void skge_error_irq(struct skge_h
skge_mac_parity(hw, 1);
if (hwstatus IS_R1_PAR_ERR) {
- printk(KERN_ERR PFX %s: receive queue parity error\n,
- hw-dev[0]-name);
+ dev_err(pdev-dev, %s: receive queue parity error\n,
+ hw-dev[0]-name);
skge_write32(hw, B0_R1_CSR, CSR_IRQ_CL_P);
}
if (hwstatus IS_R2_PAR_ERR) {
- printk(KERN_ERR PFX %s: receive queue parity error\n,
- hw-dev[1]-name);
+ dev_err(pdev-dev, %s: receive queue parity error\n,
+ hw-dev[1]-name);
skge_write32(hw, B0_R2_CSR, CSR_IRQ_CL_P);
}
if (hwstatus (IS_IRQ_MST_ERR|IS_IRQ_STAT)) {
u16 pci_status, pci_cmd;
- pci_read_config_word(hw-pdev, PCI_COMMAND, pci_cmd);
- pci_read_config_word(hw-pdev, PCI_STATUS, pci_status);
+ pci_read_config_word(pdev, PCI_COMMAND, pci_cmd);
+ pci_read_config_word(pdev, PCI_STATUS, pci_status);
- printk(KERN_ERR PFX %s: PCI error cmd=%#x status=%#x\n,
- pci_name(hw-pdev), pci_cmd, pci_status);
+ dev_err(pdev-dev, PCI error cmd=%#x status=%#x\n,
+ pci_cmd, pci_status);
/* Write the error bits back to clear them. */
pci_status = PCI_STATUS_ERROR_BITS;
skge_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
- pci_write_config_word(hw-pdev, PCI_COMMAND,
+ pci_write_config_word(pdev, PCI_COMMAND,
pci_cmd | PCI_COMMAND_SERR |
PCI_COMMAND_PARITY);
- pci_write_config_word(hw-pdev, PCI_STATUS, pci_status);
+ pci_write_config_word(pdev, PCI_STATUS, pci_status);
skge_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
/* if error still set then just ignore it */
hwstatus = skge_read32(hw, B0_HWE_ISRC);
if (hwstatus IS_IRQ_STAT) {
- printk(KERN_INFO PFX unable to clear error (so
ignoring them)\n);
+ dev_warn(hw-pdev-dev, unable to clear error (so
ignoring them)\n);
hw-intr_mask = ~IS_HW_ERR;
}
}
@@ -3280,8 +3281,8 @@ static int skge_reset(struct skge_hw *hw
hw-phy_addr = PHY_ADDR_BCOM;
break;
default:
- printk(KERN_ERR PFX %s: unsupported phy type 0x%x\n,
- pci_name(hw-pdev), hw-phy_type);
+ dev_err(hw-pdev-dev, unsupported phy type 0x%x\n,
+ hw-phy_type);
return -EOPNOTSUPP;
}
break;
@@ -3296,8 +3297,8 @@ static int skge_reset(struct skge_hw *hw
break;
default:
- printk(KERN_ERR PFX %s: unsupported chip type 0x%x\n,
- pci_name(hw-pdev), hw-chip_id);
+ dev_err(hw-pdev-dev, unsupported chip type 0x%x\n,
+ hw-chip_id);
return -EOPNOTSUPP;
}
@@ -3337,7 +3338,7 @@ static int skge_reset(struct skge_hw *hw
/* avoid boards with stuck Hardware error bits */
if ((skge_read32(hw, B0_ISRC) IS_HW_ERR)
Re: meaningful spinlock contention when bound to non-intr CPU?
On 2/1/07, Rick Jones [EMAIL PROTECTED] wrote: snip With some help from Lee Schermerhorn and Alan Brunelle I got a lockmeter kernel going, and it is suggesting that the greatest spinlock contention comes from the routines: SPINLOCKS HOLDWAIT UTIL CONMEAN( MAX ) MEAN( MAX )(% CPU) TOTAL NOWAIT SPIN RJECT NAME 7.4% 2.8% 0.1us( 143us) 3.3us( 147us)( 1.4%) 75262432 97.2% 2.8% 0% lock_sock_nested+0x30 29.5% 6.6% 0.5us( 148us) 0.9us( 143us)(0.49%) 37622512 93.4% 6.6% 0% tcp_v4_rcv+0xb30 3.0% 5.6% 0.1us( 142us) 0.9us( 143us)(0.14%) 13911325 94.4% 5.6% 0% release_sock+0x120 9.6% 0.75% 0.1us( 144us) 0.7us( 139us)(0.08%) 75262432 99.2% 0.75% 0% release_sock+0x30 I suppose it stands to some reason that there would be contention associated with the socket since there will be two things going for the socket (a netperf/netserver and an interrupt/upthestack) each running on separate CPUs. Some of it looks like it _may_ be inevitable? - waking-up the user who will now be racing to grab the socket before the stack releases it? (I may have been mis-interpreting some of the code I was checking) Still, does this look like something worth persuing? In a past life/OS when one was able to eliminate one percentage point of spinlock contention, two percentage points of improvement ensued. Rick, this looks like good stuff, we're seeing more and more issues like this as systems become more multi-core and have more interrupts per NIC (think MSI-X) Let me know if there is something I can do to 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
Re: meaningful spinlock contention when bound to non-intr CPU?
SPINLOCKS HOLDWAIT UTIL CONMEAN( MAX ) MEAN( MAX )(% CPU) TOTAL NOWAIT SPIN RJECT NAME 7.4% 2.8% 0.1us( 143us) 3.3us( 147us)( 1.4%) 75262432 97.2% 2.8% 0% lock_sock_nested+0x30 29.5% 6.6% 0.5us( 148us) 0.9us( 143us)(0.49%) 37622512 93.4% 6.6% 0% tcp_v4_rcv+0xb30 3.0% 5.6% 0.1us( 142us) 0.9us( 143us)(0.14%) 13911325 94.4% 5.6% 0% release_sock+0x120 9.6% 0.75% 0.1us( 144us) 0.7us( 139us)(0.08%) 75262432 99.2% 0.75% 0% release_sock+0x30 ... Still, does this look like something worth persuing? In a past life/OS when one was able to eliminate one percentage point of spinlock contention, two percentage points of improvement ensued. Rick, this looks like good stuff, we're seeing more and more issues like this as systems become more multi-core and have more interrupts per NIC (think MSI-X) MSI-X - haven't even gotten to that - discussion of that probably overlaps with some pci mailing list right? Let me know if there is something I can do to help. I suppose one good step would be to reproduce the results on some other platform. After that, I need to understand what those routines are doing much better than I currently do, particularly from an architecture perspective - I think that it may involve all the prequeue/try to get the TCP processing on the user's stack stuff but I'm _far_ from certain. rick jones - 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: meaningful spinlock contention when bound to non-intr CPU?
Rick Jones [EMAIL PROTECTED] writes: Still, does this look like something worth persuing? In a past life/OS when one was able to eliminate one percentage point of spinlock contention, two percentage points of improvement ensued. The stack is really designed to go fast with per CPU local RX processing of packets. This normally works because waking on up a task the scheduler tries to move it to that CPU. Since the wakeups are on the CPU that process the incoming packets it should usually end up correctly. The trouble is when your NICs are so fast that a single CPU can't keep up, or when you have programs that process many different sockets from a single thread. The fast NIC case will be eventually fixed by adding proper support for MSI-X and connection hashing. Then the NIC can fan out to multiple interrupts and use multiple CPUs to process the incoming packets. Then there is the case of a single process having many sockets from different NICs This will be of course somewhat slower because there will be cross CPU traffic. However there should be not much socket lock contention because a process handling many sockets will be hopefully unlikely to bang on each of its many sockets at the exactly same time as the stack receives RX packets. This should also eliminate the spinlock contenion. From that theory your test sounds somewhat unrealistic to me. Do you have any evidence you're modelling a real world scenario here? I somehow doubt it. -Andi - 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: meaningful spinlock contention when bound to non-intr CPU?
Andi Kleen wrote: Rick Jones [EMAIL PROTECTED] writes: Still, does this look like something worth persuing? In a past life/OS when one was able to eliminate one percentage point of spinlock contention, two percentage points of improvement ensued. The stack is really designed to go fast with per CPU local RX processing of packets. This normally works because waking on up a task the scheduler tries to move it to that CPU. Since the wakeups are on the CPU that process the incoming packets it should usually end up correctly. The trouble is when your NICs are so fast that a single CPU can't keep up, or when you have programs that process many different sockets from a single thread. The fast NIC case will be eventually fixed by adding proper support for MSI-X and connection hashing. Then the NIC can fan out to multiple interrupts and use multiple CPUs to process the incoming packets. If that is implemented well (for some definition of well) then it might address the many sockets from a thread issue too, but if not... If it is simple hash on the headers then you still have issues with a process/thread servicing mutiple connections - the hash of the different headers will take things up different CPUs and you induce the scheduler to flip the process back and forth between them. The meta question behind all that would seem to be whether the scheduler should be telling us where to perform the network processing, or should the network processing be telling the scheduler what to do? (eg all my old blathering about IPS vs TOPS in HP-UX...) Then there is the case of a single process having many sockets from different NICs This will be of course somewhat slower because there will be cross CPU traffic. The extreme case I see with the netperf test suggests it will be a pretty big hit. Dragging cachelines from CPU to CPU is evil. Sometimes a necessary evil of course, but still evil. However there should be not much socket lock contention because a process handling many sockets will be hopefully unlikely to bang on each of its many sockets at the exactly same time as the stack receives RX packets. This should also eliminate the spinlock contenion. From that theory your test sounds somewhat unrealistic to me. Do you have any evidence you're modelling a real world scenario here? I somehow doubt it. Well, yes and no. If I drop the burst and instead have N times more netperf's going, I see the same lock contention situation. I wasn't expecting to - thinking that if there were then N different processes on each CPU the likelihood of there being a contention on any one socket was low, but it was there just the same. That is part of what makes me wonder if there is a race between wakeup and release of a lock. rick - 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: meaningful spinlock contention when bound to non-intr CPU?
The meta question behind all that would seem to be whether the scheduler should be telling us where to perform the network processing, or should the network processing be telling the scheduler what to do? (eg all my old blathering about IPS vs TOPS in HP-UX...) That's an unsolved problem. But past experiments suggest that giving the scheduler more imperatives than just use CPUs well are often net-losses. I suspect it cannot be completely solved in the general case. Well, yes and no. If I drop the burst and instead have N times more netperf's going, I see the same lock contention situation. I wasn't expecting to - thinking that if there were then N different processes on each CPU the likelihood of there being a contention on any one socket was low, but it was there just the same. That is part of what makes me wonder if there is a race between wakeup A race? and release of a lock. You could try with echo 1 /proc/sys/net/ipv4/tcp_low_latency. That should change RX locking behaviour significantly. -Andi - 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] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Ok, I'm still testing it, but heres a new patch for review. Significant changes
include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent on
the inclusion of both IPPV6 and EXPERIMENTAL options, as well as a new method
for redirecting packets from optimistic sources to incomplete neighbors by
instead looking up a default router in ip6_dst_lookup_tail, as I described in my
previous note.
Thoughts and comments appreciated
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
include/linux/if_addr.h |1
include/linux/ipv6.h|4 ++
include/linux/sysctl.h |1
include/net/addrconf.h |4 +-
net/ipv6/Kconfig| 10 ++
net/ipv6/addrconf.c | 79 ++--
net/ipv6/ip6_output.c | 32 ++-
net/ipv6/mcast.c|4 +-
net/ipv6/ndisc.c| 79 +---
9 files changed, 171 insertions(+), 43 deletions(-)
diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index d557e4c..43f3bed 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -39,6 +39,7 @@ enum
#define IFA_F_TEMPORARYIFA_F_SECONDARY
#defineIFA_F_NODAD 0x02
+#define IFA_F_OPTIMISTIC 0x04
#defineIFA_F_HOMEADDRESS 0x10
#define IFA_F_DEPRECATED 0x20
#define IFA_F_TENTATIVE0x40
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index f824113..bf93c1b 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -177,6 +177,9 @@ struct ipv6_devconf {
#endif
#endif
__s32 proxy_ndp;
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+ __s32 optimistic_dad;
+#endif
void*sysctl;
};
@@ -205,6 +208,7 @@ enum {
DEVCONF_RTR_PROBE_INTERVAL,
DEVCONF_ACCEPT_RA_RT_INFO_MAX_PLEN,
DEVCONF_PROXY_NDP,
+ DEVCONF_OPTIMISTIC_DAD,
DEVCONF_MAX
};
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 81480e6..972a33a 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -570,6 +570,7 @@ enum {
NET_IPV6_RTR_PROBE_INTERVAL=21,
NET_IPV6_ACCEPT_RA_RT_INFO_MAX_PLEN=22,
NET_IPV6_PROXY_NDP=23,
+ NET_IPV6_OPTIMISTIC_DAD=24,
__NET_IPV6_MAX
};
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 88df8fc..d248a19 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -73,7 +73,9 @@ extern intipv6_get_saddr(struct dst_entry
*dst,
extern int ipv6_dev_get_saddr(struct net_device *dev,
struct in6_addr *daddr,
struct in6_addr *saddr);
-extern int ipv6_get_lladdr(struct net_device *dev, struct
in6_addr *);
+extern int ipv6_get_lladdr(struct net_device *dev,
+ struct in6_addr *,
+ unsigned char banned_flags);
extern int ipv6_rcv_saddr_equal(const struct sock *sk,
const struct sock *sk2);
extern voidaddrconf_join_solict(struct net_device *dev,
diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index deb4101..822d3eb 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -57,6 +57,16 @@ config IPV6_ROUTE_INFO
If unsure, say N.
+config IPV6_OPTIMISTIC_DAD
+ bool IPv6: Enable RFC 4429 Optimistic DAD (EXPERIMENTAL)
+ depends on IPV6 EXPERIMENTAL
+ ---help---
+ This is experimental support for optimistic Duplicate
+ Address Detection. It allows for autoconfigured addresses
+ to be used more quickly.
+
+ If unsure, say N.
+
config INET6_AH
tristate IPv6: AH transformation
depends on IPV6
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2a7e461..d00e3f6 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -593,7 +593,13 @@ ipv6_add_addr(struct inet6_dev *idev, const struct
in6_addr *addr, int pfxlen,
ifa-cstamp = ifa-tstamp = jiffies;
ifa-rt = rt;
-
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+ if (!idev-cnf.optimistic_dad || ipv6_devconf.forwarding ||
+ (ifa-rt-rt6i_nexthop == NULL))
+ ifa-flags = ~IFA_F_OPTIMISTIC;
+#else
+ ifa-flags = ~IFA_F_OPTIMISTIC;
+#endif
ifa-idev = idev;
in6_dev_hold(idev);
/* For caller */
@@ -830,7 +836,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) max_addresses ?
ipv6_add_addr(idev, addr, tmp_plen,
- ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK,
IFA_F_TEMPORARY) : NULL;
+ ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK,
+
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
From: Neil Horman [EMAIL PROTECTED] Date: Fri, 2 Feb 2007 14:06:34 -0500 Ok, I'm still testing it, but heres a new patch for review. Significant changes include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent on the inclusion of both IPPV6 and EXPERIMENTAL options, as well as a new method for redirecting packets from optimistic sources to incomplete neighbors by instead looking up a default router in ip6_dst_lookup_tail, as I described in my previous note. This looks largely fine to me, but I wonder about one bit: + + /* +* Optimistic nodes need to join the anycast address +* right away +*/ + if (ifp-flags IFA_F_OPTIMISTIC) + addrconf_join_anycast(ifp); + If something can clear that bit during the DAD, we won't call addrconf_leave_anycast() later. Can that happen? - 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: meaningful spinlock contention when bound to non-intr CPU?
Andi Kleen wrote: The meta question behind all that would seem to be whether the scheduler should be telling us where to perform the network processing, or should the network processing be telling the scheduler what to do? (eg all my old blathering about IPS vs TOPS in HP-UX...) That's an unsolved problem. But past experiments suggest that giving the scheduler more imperatives than just use CPUs well are often net-losses. I wasn't thinking about giving the scheduler more imperitives really (?), just letting networking know more about where threads executed accessing given connections. (eg TOPS) I suspect it cannot be completely solved in the general case. Not unless the NIC can peer into the connection table and see where each connection was last accessed by user-space. Well, yes and no. If I drop the burst and instead have N times more netperf's going, I see the same lock contention situation. I wasn't expecting to - thinking that if there were then N different processes on each CPU the likelihood of there being a contention on any one socket was low, but it was there just the same. That is part of what makes me wonder if there is a race between wakeup A race? Perhaps a poor choice of words on my part - something along the lines of: hold_lock(); wake_up_someone(); release_lock(); where the someone being awoken can try to grab the lock before the path doing the waking manages to release it. and release of a lock. You could try with echo 1 /proc/sys/net/ipv4/tcp_low_latency. That should change RX locking behaviour significantly. Running the same 8 netperf's with TCP_RR and burst bound to different CPU than the NIC interrupt, the lockmeter output looks virtually unchanged. Still release_sock, tcp_v4_rcv, lock_sock_nested at their same offsets. However, if I run the multiple-connection-per-thread code, and have each service 32 concurrent connections, and bind to a CPU other than the interrupt CPU, the lock contention in this case does appear to go away. rick jones - 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] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
On Fri, Feb 02, 2007 at 11:46:08AM -0800, David Miller wrote: From: Neil Horman [EMAIL PROTECTED] Date: Fri, 2 Feb 2007 14:06:34 -0500 Ok, I'm still testing it, but heres a new patch for review. Significant changes include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent on the inclusion of both IPPV6 and EXPERIMENTAL options, as well as a new method for redirecting packets from optimistic sources to incomplete neighbors by instead looking up a default router in ip6_dst_lookup_tail, as I described in my previous note. This looks largely fine to me, but I wonder about one bit: + + /* + * Optimistic nodes need to join the anycast address + * right away + */ + if (ifp-flags IFA_F_OPTIMISTIC) + addrconf_join_anycast(ifp); + If something can clear that bit during the DAD, we won't call addrconf_leave_anycast() later. Can that happen? The only way the flag should get cleared once we've started DAD is when it completes or fails. In the failure case, we destroy the ifaddr structure, which I think should force a leave_anycast, while the completed condition calls addrconf_leave_anycast as part of the completion process before it clears the flags, so I think we should be ok. If anyone sees anything to the contrary, please let me know and I'll be sure to plug the hole. Thanks Regards Neil - 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: meaningful spinlock contention when bound to non-intr CPU?
Perhaps a poor choice of words on my part - something along the lines of: hold_lock(); wake_up_someone(); release_lock(); where the someone being awoken can try to grab the lock before the path doing the waking manages to release it. Yes the wakeup happens deep inside the critical section and if the process is running on another CPU it could race to the lock. Hmm, i suppose the wakeup could be moved out, but it would need some restructuring of the code. Also to be safe the code would still need to at least hold a reference count of the sock during the wakeup, and when that is released then you have another cache line to bounce, which might not be any better than the lock. So it might not be actually worth it. I suppose the socket release could be at least partially protected with RCU against this case so that could be done without a reference count, but it might be tricky to get this right. Again still not sure it's worth handling this. -Andi - 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: meaningful spinlock contention when bound to non-intr CPU?
Yes the wakeup happens deep inside the critical section and if the process is running on another CPU it could race to the lock. Hmm, i suppose the wakeup could be moved out, but it would need some restructuring of the code. Also to be safe the code would still need to at least hold a reference count of the sock during the wakeup, and when that is released then you have another cache line to bounce, which might not be any better than the lock. So it might not be actually worth it. I suppose the socket release could be at least partially protected with RCU against this case so that could be done without a reference count, but it might be tricky to get this right. Again still not sure it's worth handling this. Based on my experiments thusfar I'd have to agree/accept (I wasn't certain to begin with - hence the post in the first place :) but I do need/want to see what happens with a single-stream through a 10G NIC - on the receive side at least with a 1500 byte MTU. I was using the burst-mode aggregate RR over the 1G NICs to get the CPU util up without need for considerable bandwidth, since the system handled 8 TCP_STREAM tests across the 8 NICs without working-up a sweat. I suppose I could instead chop the MTU on the 1G NICs and use that to increase the CPU util on the receive side. rick - 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] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Hi Neil,
@@ -830,7 +836,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) max_addresses ?
ipv6_add_addr(idev, addr, tmp_plen,
- ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK,
IFA_F_TEMPORARY) : NULL;
+ ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK,
+ IFA_F_TEMPORARY|IFA_F_OPTIMISTIC) : NULL;
So why are you always adding these as optimistic now? Shouldn't this be
triggering off idev-cnf.optimistic_dad? I know you're clearing it in
ipv6_add_addr(), but I liked Vlad's suggestion of not setting it
initially since this way seems backwards.
@@ -2123,7 +2142,8 @@ static void addrconf_add_linklocal(struct inet6_dev
*idev, struct in6_addr *addr
{
struct inet6_ifaddr * ifp;
- ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, IFA_F_PERMANENT);
+ ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK,
+ IFA_F_PERMANENT|IFA_F_OPTIMISTIC);
Here too.
-Brian
-
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
Please pull upstream-fixes branch of wireless-2.6
This is a fix for 2.6.20 (time permitting).
---
The following changes since commit f56df2f4db6e4af87fb8e941cff69f4501a111df:
Linus Torvalds (1):
Linux 2.6.20-rc7
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-fixes
Maxime Austruy (1):
zd1211rw: fix potential leak in usb_init
drivers/net/wireless/zd1211rw/zd_usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c
b/drivers/net/wireless/zd1211rw/zd_usb.c
index 605e96e..2468ad6 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -1128,6 +1128,7 @@ static int __init usb_init(void)
r = usb_register(driver);
if (r) {
+ destroy_workqueue(zd_workqueue);
printk(KERN_ERR %s usb_register() failed. Error number %d\n,
driver.name, r);
return r;
--
John W. Linville
[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
Please pull upstream branch of wireless-2.6
This patches are intended for 2.6.21.
---
The following changes since commit 541c654cfdeb5cc6d2e945988985570384ee2a43:
John W. Linville (1):
Merge branch 'upstream-fixes' into upstream
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
Daniel Drake (1):
zd1211rw: Remove noisy debug message
Larry Finger (3):
bcm43xx: Fix problem with 1 GB RAM
bcm43xx: Fix scaling error for 'iwlist rate' information
bcm43xx: Fix scaling error for 'iwlist freq' information
Michael Buesch (1):
bcm43xx: Enable fwpostfix in nondebug bcm43xx
Robert P. J. Day (1):
Rename IPW2100 debugging macros to not look like config options.
Ulrich Kunitz (3):
zd1211rw: Reset device in the probe call
zd1211rw: Fixed array size issue in reset_mode
zd1211rw: Added error stats update
drivers/net/wireless/bcm43xx/bcm43xx.h |1 +
drivers/net/wireless/bcm43xx/bcm43xx_dma.c | 171 +++
drivers/net/wireless/bcm43xx/bcm43xx_main.c |6 +-
drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 28 ++--
drivers/net/wireless/ipw2100.c | 16 ++--
drivers/net/wireless/zd1211rw/zd_mac.c | 44 ++--
drivers/net/wireless/zd1211rw/zd_usb.c | 11 ++
7 files changed, 193 insertions(+), 84 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx.h
b/drivers/net/wireless/bcm43xx/bcm43xx.h
index 3a064de..0e790ef 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -771,6 +771,7 @@ struct bcm43xx_private {
* This is currently always BCM43xx_BUSTYPE_PCI
*/
u8 bustype;
+ u64 dma_mask;
u16 board_vendor;
u16 board_type;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
index 978ed09..6e0dc76 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -145,16 +145,14 @@ dma_addr_t map_descbuffer(struct bcm43xx_dmaring *ring,
int tx)
{
dma_addr_t dmaaddr;
+ int direction = PCI_DMA_FROMDEVICE;
- if (tx) {
- dmaaddr = dma_map_single(ring-bcm-pci_dev-dev,
-buf, len,
-DMA_TO_DEVICE);
- } else {
- dmaaddr = dma_map_single(ring-bcm-pci_dev-dev,
+ if (tx)
+ direction = PCI_DMA_TODEVICE;
+
+ dmaaddr = pci_map_single(ring-bcm-pci_dev,
buf, len,
-DMA_FROM_DEVICE);
- }
+direction);
return dmaaddr;
}
@@ -166,13 +164,13 @@ void unmap_descbuffer(struct bcm43xx_dmaring *ring,
int tx)
{
if (tx) {
- dma_unmap_single(ring-bcm-pci_dev-dev,
+ pci_unmap_single(ring-bcm-pci_dev,
addr, len,
-DMA_TO_DEVICE);
+PCI_DMA_TODEVICE);
} else {
- dma_unmap_single(ring-bcm-pci_dev-dev,
+ pci_unmap_single(ring-bcm-pci_dev,
addr, len,
-DMA_FROM_DEVICE);
+PCI_DMA_FROMDEVICE);
}
}
@@ -183,8 +181,8 @@ void sync_descbuffer_for_cpu(struct bcm43xx_dmaring *ring,
{
assert(!ring-tx);
- dma_sync_single_for_cpu(ring-bcm-pci_dev-dev,
- addr, len, DMA_FROM_DEVICE);
+ pci_dma_sync_single_for_cpu(ring-bcm-pci_dev,
+ addr, len, PCI_DMA_FROMDEVICE);
}
static inline
@@ -194,8 +192,8 @@ void sync_descbuffer_for_device(struct bcm43xx_dmaring
*ring,
{
assert(!ring-tx);
- dma_sync_single_for_device(ring-bcm-pci_dev-dev,
- addr, len, DMA_FROM_DEVICE);
+ pci_dma_sync_single_for_cpu(ring-bcm-pci_dev,
+ addr, len, PCI_DMA_TODEVICE);
}
/* Unmap and free a descriptor buffer. */
@@ -214,17 +212,53 @@ void free_descriptor_buffer(struct bcm43xx_dmaring *ring,
static int alloc_ringmemory(struct bcm43xx_dmaring *ring)
{
- struct device *dev = (ring-bcm-pci_dev-dev);
-
- ring-descbase = dma_alloc_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
- (ring-dmabase), GFP_KERNEL);
+ ring-descbase = pci_alloc_consistent(ring-bcm-pci_dev,
BCM43xx_DMA_RINGMEMSIZE,
+ (ring-dmabase));
if (!ring-descbase) {
- printk(KERN_ERR PFX DMA ringmemory allocation failed\n);
- return -ENOMEM;
+ /* Allocation may have failed due to pci_alloc_consistent
+ insisting on use of GFP_DMA, which is more
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Neil Horman wrote: Ok, I'm still testing it, but heres a new patch for review. Significant changes include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent on the inclusion of both IPPV6 and EXPERIMENTAL options, as well as a new method for redirecting packets from optimistic sources to incomplete neighbors by instead looking up a default router in ip6_dst_lookup_tail, as I described in my previous note. Hi Neil Still digesting the routing changes, but I think you missed addrconf_prefix_rcv()... ;) -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: [PATCH] ieee80211: Fix sparse warning
On Wed, Jan 31, 2007 at 06:50:19PM -0600, Larry Finger wrote:
Sparse issues the warning warning: symbol 'crypt' shadows an earlier one
in net/ieee80211/ieee80211_tx.c.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/net/ieee80211/ieee80211_tx.c
===
--- wireless-2.6.orig/net/ieee80211/ieee80211_tx.c
+++ wireless-2.6/net/ieee80211/ieee80211_tx.c
@@ -502,8 +502,6 @@ int ieee80211_xmit(struct sk_buff *skb,
if (host_encrypt)
ieee80211_encrypt_fragment(ieee, skb_frag, hdr_len);
else if (host_build_iv) {
- struct ieee80211_crypt_data *crypt;
-
crypt = ieee-crypt[ieee-tx_keyidx];
atomic_inc(crypt-refcnt);
if (crypt-ops-build_iv)
Couldn't you remove the crypt = ieee-crypt[ieee-tx_keyidx];
as well?
John
--
John W. Linville
[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: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Brian Haley wrote: Hi Neil, @@ -830,7 +836,8 @@ retry: ift = !max_addresses || ipv6_count_addresses(idev) max_addresses ? ipv6_add_addr(idev, addr, tmp_plen, - ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK, IFA_F_TEMPORARY) : NULL; + ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK, + IFA_F_TEMPORARY|IFA_F_OPTIMISTIC) : NULL; Hi Brian So why are you always adding these as optimistic now? Shouldn't this be triggering off idev-cnf.optimistic_dad? I know you're clearing it in ipv6_add_addr(), but I liked Vlad's suggestion of not setting it initially since this way seems backwards. The troubling case seems to manually configured addresses (inet6_addr_add()). If we can clearly and easily distinguish between this case of address and all the other ones, then we can simply set the flag in ipv6_add_addr, like we set the tentative flag. So, we can introduce another parameter to ipv6_add_addr() or another flag that can distinguish manual config. Otherwise, we can keep the code as is, passing the optimistic flag from needed callers, and clearing it inside ipv6_add_addr(). My thought was to clear it from the 'flags' parameter before ifa-flags was set, but that doesn't really matter. -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: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Neil Horman wrote: On Fri, Feb 02, 2007 at 11:46:08AM -0800, David Miller wrote: From: Neil Horman [EMAIL PROTECTED] Date: Fri, 2 Feb 2007 14:06:34 -0500 Ok, I'm still testing it, but heres a new patch for review. Significant changes include the addition of a CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent on the inclusion of both IPPV6 and EXPERIMENTAL options, as well as a new method for redirecting packets from optimistic sources to incomplete neighbors by instead looking up a default router in ip6_dst_lookup_tail, as I described in my previous note. This looks largely fine to me, but I wonder about one bit: + +/* + * Optimistic nodes need to join the anycast address + * right away + */ +if (ifp-flags IFA_F_OPTIMISTIC) +addrconf_join_anycast(ifp); + If something can clear that bit during the DAD, we won't call addrconf_leave_anycast() later. Can that happen? The only way the flag should get cleared once we've started DAD is when it completes or fails. In the failure case, we destroy the ifaddr structure, which I think should force a leave_anycast, while the completed condition calls addrconf_leave_anycast as part of the completion process before it clears the flags, so I think we should be ok. If anyone sees anything to the contrary, please let me know and I'll be sure to plug the hole. I think there is a hole: Looking for addrconf_leave_anycast() shows: dev_forward_change(): 475 addrconf_leave_anycast(ifa); __ipv6_ifa_notify():3613 addrconf_leave_anycast(ifp); Problem: __ipv6_ifa_notify only performs the 'leave' if forwarding is enabled. However, OPTIMISTIC, is set when forwarding is _disabled_. -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: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Hi Vlad, Vlad Yasevich wrote: Brian Haley wrote: Hi Neil, @@ -830,7 +836,8 @@ retry: ift = !max_addresses || ipv6_count_addresses(idev) max_addresses ? ipv6_add_addr(idev, addr, tmp_plen, - ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK, IFA_F_TEMPORARY) : NULL; + ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK, + IFA_F_TEMPORARY|IFA_F_OPTIMISTIC) : NULL; Hi Brian So why are you always adding these as optimistic now? Shouldn't this be triggering off idev-cnf.optimistic_dad? I know you're clearing it in ipv6_add_addr(), but I liked Vlad's suggestion of not setting it initially since this way seems backwards. The troubling case seems to manually configured addresses (inet6_addr_add()). If we can clearly and easily distinguish between this case of address and all the other ones, then we can simply set the flag in ipv6_add_addr, like we set the tentative flag. Right, I guess maybe I'm trying to figure out what idev-cnf.optimistic_dad means: 1. Interface supports OPTIMISTIC addresses 2. All auto-configured addresses on interface are OPTIMISTIC 3. ??? All other addresses are created w/out OPTIMISTIC set. I think manually-configured addresses can be tagged as OPTIMISTIC just like MIPv6 Home Addresses are if we just change this line in inet6_rtm_newaddr(): ifa_flags = ifm-ifa_flags (IFA_F_NODAD | IFA_F_HOMEADDRESS); -- ifa_flags = ifm-ifa_flags (IFA_F_NODAD | IFA_F_HOMEADDRESS | IFA_F_OPTIMISTIC); and tweak the rest of the code, but that doesn't cover the addrconf_add_ifaddr() codepath via ioctl(SIOCSIFADDR). I can generate a patch based-on Neil's, but it will take me until Monday to get it out. -Brian - 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: [RFC][PATCH][XFRM][0/5] extension for XFRM databases
Hello Jamal, Thank you for your feedback. Please find my comments inline. On Fri, 02 Feb 2007 08:35:51 -0500 jamal [EMAIL PROTECTED] wrote: Hello, On Fri, 2007-02-02 at 20:25 +0900, Shinta Sugimoto wrote: In the design phase, we sorted out the requirements as below: (1) Overhead of userland - kernel interaction message exchange should be kept minimum. (2) There should not be too much requirement for user application to leverage the feature (dynamic update of endpoint). More specifically, we don't want to expect the user application to have detailed information of IPsec security association (i.e. SPI). (3) There should not be negative impact on the existing software which is based on PF_KEYv2 (RFC2367). Firstly, if we use the existing messages for updating SPD and SAD, we simply need 2 pairs of request/response exchange between the userland and kernel for updating a single endpoint. This is not ideal from the perspective of (1). Ok, if i understand you correctly: Instead of having from userland one message for updating SAD and another for updating SPD, you have a single message which updates both? Yes. A XFRM_MSG_MIGRATE message can update an SPD entry and associated SAD entries (if any) at a time. Secondly, we need to be careful about updating the endpoint address because it may invoke unexpected signaling (ACQUIRE) to the user application. Imagine you update SPD and SAD sequentially while there is an outbound flow going on. The kernel may end up with triggering the userland application by unexpected ACQUIRE message due to the absence of SAD entry. In order to avoid this problem, we need a sort of atomic update of SPD and SAD entries. XFRM_MSG_MIGRATE is designed and implemented in a way that unexpected ACQUIRE would never occur. Ok, this is sensible - it could be achieved with two multipart messages in netlink; but a single message is better. Thirdly, we also need to pay attention to the PF_KEYv2 spec. XFRM_MSG_UPDSA is derived from SADB_UPDATE message in PF_KEYv2. According to the spec, the semantics of SADB_UPDATE is to add a new security association with the information provided by previous SADB_GETSPI message. We think it's not a good idea to overload the semantics of SADB_UPDATE message because it may confuse legacy software from the perspective of (3). Moreover, caller of SADB_UPDATE should specify SPI, source address, and destination address, which is a bit problematic from the perspective of (2). We really dont have this issue with xfrm side. I think that PF_KEYv2 is just a dinosaur that needs to be extinct. Continuing to bandaid around it is converting into a mammoth. I found your first two explanation more reasonable, but not this one. From the above reasons, we decided to extend XFRM/PF_KEYv2 for dynamic update of the endpoint. Please note that the mechanism is useful not only for Mobile IPv6 but also for Mobile VPN scenario. Can you explain what you mean by this last part? There are many ways to achieve mobile VPN - is the end client aware? By Mobile VPN, I meant a VPN scenario where clients roam around subnets and continue changing its attachment point to the Internet (aka roadwarrior). In such case, both client and SGW need to update endpoint address of the security association. When the endpoint address of client side is updated, instead of re-establishing the security association from scratch, the client may inform the SGW of its new endpoint address. This is what MOBIKE (RFC4555) does. So, just like in the case of Mobile IPv6, endpoint address management of IPsec databases is necessary and XFRM_MSG_MIGRATE message can be used. Does this make sense? Yes, I think I see the logic behind your design. To be 100% convinced, depends if your answer to the first question i asked is yes. Ok, thanks. Regards, Shinta - 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] ieee80211: Fix sparse warning
John W. Linville wrote:
On Wed, Jan 31, 2007 at 06:50:19PM -0600, Larry Finger wrote:
Sparse issues the warning warning: symbol 'crypt' shadows an earlier one
in net/ieee80211/ieee80211_tx.c.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/net/ieee80211/ieee80211_tx.c
===
--- wireless-2.6.orig/net/ieee80211/ieee80211_tx.c
+++ wireless-2.6/net/ieee80211/ieee80211_tx.c
@@ -502,8 +502,6 @@ int ieee80211_xmit(struct sk_buff *skb,
if (host_encrypt)
ieee80211_encrypt_fragment(ieee, skb_frag, hdr_len);
else if (host_build_iv) {
-struct ieee80211_crypt_data *crypt;
-
crypt = ieee-crypt[ieee-tx_keyidx];
atomic_inc(crypt-refcnt);
if (crypt-ops-build_iv)
Couldn't you remove the crypt = ieee-crypt[ieee-tx_keyidx];
as well?
Yes it can. I'll send a revised patch along shortly.
Larry
-
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 V2] ieee80211: Fix sparse warning
Sparse issues the warning warning: symbol 'crypt' shadows an earlier one
in net/ieee80211/ieee80211_tx.c.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/net/ieee80211/ieee80211_tx.c
===
--- wireless-2.6.orig/net/ieee80211/ieee80211_tx.c
+++ wireless-2.6/net/ieee80211/ieee80211_tx.c
@@ -502,9 +502,6 @@ int ieee80211_xmit(struct sk_buff *skb,
if (host_encrypt)
ieee80211_encrypt_fragment(ieee, skb_frag, hdr_len);
else if (host_build_iv) {
- struct ieee80211_crypt_data *crypt;
-
- crypt = ieee-crypt[ieee-tx_keyidx];
atomic_inc(crypt-refcnt);
if (crypt-ops-build_iv)
crypt-ops-build_iv(skb_frag, hdr_len,
-
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]ip_auto_config bug in 2.6.20-rc6
-Original Message- From: Thomas Bogendoerfer [mailto:[EMAIL PROTECTED] Sent: 02 February 2007 16:18 To: Jan Engelhardt Cc: Joakim Tjernlund; Netdev; Linux-Kernel Subject: Re: [PATCH]ip_auto_config bug in 2.6.20-rc6 On Fri, Feb 02, 2007 at 02:27:29PM +0100, Jan Engelhardt wrote: I think this is a bug since I am not using a NFS root FS. I just wonder why IP_PNP has not been obsoleted and removed from the tree yet, given that initramfs is the advertised way to do so such things. I hope this will not happen. Using BOOTP/NFS makes kernel hacking much easier on not yet supported machines, which offer tftp in their firmware. Thomas. Just want to add a me too :) Jocke PS. This is the first mail I have received in response to my postings, please CC me on any replies. - 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]ip_auto_config bug in 2.6.20-rc6
On Fri, Feb 02, 2007 at 02:27:29PM +0100, Jan Engelhardt wrote: I think this is a bug since I am not using a NFS root FS. I just wonder why IP_PNP has not been obsoleted and removed from the tree yet, given that initramfs is the advertised way to do so such things. I hope this will not happen. Using BOOTP/NFS makes kernel hacking much easier on not yet supported machines, which offer tftp in their firmware. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea.[ RFC1925, 2.3 ] - 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
dynticks + iptables almost stops the boot process [was: Re: 2.6.20-rc6-mm3]
Cc-ing netdev and netfilter-devel, the beginning of the thread is here http://lkml.org/lkml/2007/1/31/306 On Thu, Feb 01, 2007 at 11:33:22PM +0100, Thomas Gleixner wrote: Mattia, ... May I ask you for another test ? Please turn on high resolution timers and check, if the same strange behaviour is happening. Yep, here we go again. Still seeing long stalls but no negative expires offset. Actually one more test I did is disabling my iptables script and the boot process went fine. The script is just: #!/bin/sh iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -P INPUT DROP iptables -P FORWARD ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport ssh -j ACCEPT # LAN iptables -I INPUT -s 10.0.0.0/8 -j ACCEPT # LAN UML iptables -I INPUT -s 172.20.0.0/16 -j ACCEPT echo iptables: MASQUERADING for virtual machines iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE sysctl -w net.ipv4.ip_forward=1 and executing it from a shell once the boot process is done doesn't generate all that strangeness/slowness... Dmesg with iptables script enabled: [0.00] Linux version 2.6.20-rc6-mm3-1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #8 SMP Fri Feb 2 10:26:07 CET 2007 [0.00] BIOS-provided physical RAM map: [0.00] sanitize start [0.00] sanitize end [0.00] copy_e820_map() start: size: 0009f800 end: 0009f800 type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 [0.00] copy_e820_map() start: 000dc000 size: 00024000 end: 0010 type: 2 [0.00] copy_e820_map() start: 0010 size: 3fd7 end: 3fe7 type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 3fe7 size: 0009 end: 3ff0 type: 4 [0.00] copy_e820_map() start: 3ff0 size: 0010 end: 4000 type: 2 [0.00] copy_e820_map() start: e000 size: 1000 end: f000 type: 2 [0.00] copy_e820_map() start: fec0 size: 0001 end: fec1 type: 2 [0.00] copy_e820_map() start: fed14000 size: 6000 end: fed1a000 type: 2 [0.00] copy_e820_map() start: fed1c000 size: 00074000 end: fed9 type: 2 [0.00] copy_e820_map() start: fee0 size: 1000 end: fee01000 type: 2 [0.00] copy_e820_map() start: ff00 size: 0100 end: 0001 type: 2 [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000dc000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3fe7 (usable) [0.00] BIOS-e820: 3fe7 - 3ff0 (ACPI NVS) [0.00] BIOS-e820: 3ff0 - 4000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fed14000 - fed1a000 (reserved) [0.00] BIOS-e820: fed1c000 - fed9 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: ff00 - 0001 (reserved) [0.00] 126MB HIGHMEM available. [0.00] 896MB LOWMEM available. [0.00] found SMP MP-table at 000f6480 [0.00] Entering add_active_range(0, 0, 261744) 0 entries of 256 used [0.00] sizeof(struct page) = 32 [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] Normal 4096 - 229376 [0.00] HighMem229376 - 261744 [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 - 261744 [0.00] On node 0 totalpages: 261744 [0.00] Node 0 memmap at 0xc100 size 8388608 first pfn 0xc100 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 1760 pages used for memmap [0.00] Normal zone: 223520 pages, LIFO batch:31 [0.00] HighMem zone: 252 pages used for memmap [0.00] HighMem zone: 32116 pages, LIFO batch:7 [0.00] DMI present. [0.00] ACPI: RSDP @ 0x000f63b0/0x0014 (v000 PTLTD ) [0.00] ACPI: RSDT @ 0x3fe764ef/0x0048 (v001 Sony N0 0x20060710 PTL 0x) [
[RFT] sky2 auto negotiation PHY errata
This patch does the Marvell errata before auto negotiation
(from drivers/phy/marvell.c). The Yukon II chips have an internal
version of the same PHY, so perhaps this errata is necessary for them
as well.
For test only, but it may fix some of the hangs. It seems to fix
the PHY lockups I saw yesterday on Mac Mini.
---
drivers/net/sky2.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 822dd0b..4f04ffa 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -387,6 +387,14 @@ static void sky2_phy_init(struct sky2_hw
if (sky2-autoneg == AUTONEG_ENABLE) {
if (sky2_is_copper(hw)) {
+ /* Errata setup */
+ gm_phy_write(hw, port, PHY_MARV_PAGE_ADDR, 0x1f);
+ gm_phy_write(hw, port, PHY_MARV_PAGE_DATA, 0x200c);
+ gm_phy_write(hw, port, PHY_MARV_PAGE_ADDR, 5);
+ gm_phy_write(hw, port, PHY_MARV_PAGE_DATA, 0);
+ gm_phy_write(hw, port, PHY_MARV_PAGE_DATA, 0x100);
+
+
if (sky2-advertising ADVERTISED_1000baseT_Full)
ct1000 |= PHY_M_1000C_AFD;
if (sky2-advertising ADVERTISED_1000baseT_Half)
--
1.4.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
Re: dynticks + iptables almost stops the boot process [was: Re: 2.6.20-rc6-mm3]
On Fri, 2007-02-02 at 20:18 +0100, Mattia Dongili wrote: May I ask you for another test ? Please turn on high resolution timers and check, if the same strange behaviour is happening. Yep, here we go again. Still seeing long stalls but no negative expires offset. Actually one more test I did is disabling my iptables script and the boot process went fine. The script is just: Mattia, I have it halfways reproducible now and I'm working to find the root cause. Thanks for providing the info. tglx - 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: dynticks + iptables almost stops the boot process [was: Re: 2.6.20-rc6-mm3]
On Fri, Feb 02, 2007 at 09:27:14PM +0100, Thomas Gleixner wrote: On Fri, 2007-02-02 at 20:18 +0100, Mattia Dongili wrote: May I ask you for another test ? Please turn on high resolution timers and check, if the same strange behaviour is happening. Yep, here we go again. Still seeing long stalls but no negative expires offset. Actually one more test I did is disabling my iptables script and the boot process went fine. The script is just: Mattia, I have it halfways reproducible now and I'm working to find the root cause. Thanks for providing the info. Great, I'm obviously available to test any patch :) -- mattia :wq! - 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 10/10] cxgb3 - Add dual licensing
Arjan van de Ven wrote: On Tue, 2007-01-30 at 19:44 -0800, Divy Le Ray wrote: Dual licensing, needed for OFED 1.2 Hi, did you get permission from all the people who contributed code to your driver ? Hi Arjan, The NIC driver was developed in Chelsio, the RDMA support was developed in cooperation with Opengridcomputing. The need for dual licensing actually comes from Opengridcomputing. Cheers, Divy - 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] sky2: flow control off
Turn flow control off for sky2. When flow control is on, the transmitter may get randomly stuck. Perhaps there is hardware problem, but until Marvell provides errata information for workaround, it should default to off. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- drivers/net/sky2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c index 822dd0b..a31dea5 100644 --- a/drivers/net/sky2.c +++ b/drivers/net/sky2.c @@ -3263,7 +3263,7 @@ #endif /* Auto speed and flow control */ sky2-autoneg = AUTONEG_ENABLE; - sky2-flow_mode = FC_BOTH; + sky2-flow_mode = FC_NONE; sky2-duplex = -1; sky2-speed = -1; -- 1.4.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
Re: [Fwd: Re: [PATCH 1/10] cxgb3 - main header files]
On Thu, 2007-02-01 at 20:48 -0800, Roland Dreier wrote: Have you had a chance to review this? Still on my list. Can we trade? Can you look at the IPoIB connected mode stuff in the ipoib-cm branch in git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git and let me know if you see anything you don't like? - R. Ok. I'll review the IPoIB connected mode code. Steve. - 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
2.6.20-rc7: known regressions (v2) (part 1)
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: NULL pointer dereference at as_move_to_dispatch() References : http://lkml.org/lkml/2007/1/22/141 Submitter : Andrew Vasquez [EMAIL PROTECTED] Status : unknown Subject: pktcdvd doesn't work with libata pata drivers (caused by scsi_lib and pktcdvd patches) References : http://bugzilla.kernel.org/show_bug.cgi?id=7810 http://lkml.org/lkml/2007/1/25/128 http://bugzilla.kernel.org/show_bug.cgi?id=7910 http://lkml.org/lkml/2007/1/30/289 Submitter : Gerhard Dirschl [EMAIL PROTECTED] Luca Tettamanti [EMAIL PROTECTED] Caused-By : Christoph Hellwig [EMAIL PROTECTED] commit 3b00315799d78f76531b71435fbc2643cd71ae4c commit 406c9b605cbc45151c03ac9a3f95e9acf050808c Status : unknown Subject: e1000: 82571EB/82572EI PCI-E cards: link is always down (MSI related) References : http://lkml.org/lkml/2007/1/16/27 http://lkml.org/lkml/2007/1/17/182 Submitter : Allen Parker [EMAIL PROTECTED] Adam Kropelin [EMAIL PROTECTED] Handled-By : Auke Kok [EMAIL PROTECTED] Status : problem is being debugged Subject: powerpc64: performance monitor exception References : http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030045.html Submitter : Livio Soares [EMAIL PROTECTED] Caused-By : Paul Mackerras [EMAIL PROTECTED] commit d04c56f73c30a5e593202ecfcf25ed43d42363a2 Status : unknown - 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-rc7: known regressions (v2) (part 1)
Adrian Bunk wrote: This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Subject: e1000: 82571EB/82572EI PCI-E cards: link is always down (MSI related) References : http://lkml.org/lkml/2007/1/16/27 http://lkml.org/lkml/2007/1/17/182 Submitter : Allen Parker [EMAIL PROTECTED] Adam Kropelin [EMAIL PROTECTED] Handled-By : Auke Kok [EMAIL PROTECTED] Status : problem is being debugged I probably can't fix this bug. Not only do I doubt that the e1000 driver is at fault here, I don't have a system with this particular chipset. Most likely the regression comes from a combination of MSI layer rewrites and possibly platform issues. We've seen many reports that are similar and all are on the platform type mentioned here. I really don't want to point fingers here either. None of the MSI code in e1000 has changed significantly either. as far as I can see, the msi code in e1000 has not changed since 2.6.18. Nonetheless there's no way I can debug any of this without a system. I will address the fact that we are lacking any of these systems to test on, but that is not going to get this issue handled (not to mention soon) in the way it needs to be. I strongly encourage the people on the linux-pci list to help out, I'll trace the e1000 driver for suspicious activity (again), but I run countless tests on the latest trees and nothing has shown up recently, other than Eric Biederman's msi irq reclaim leak fix. Perhaps Adam can git-bisect this issue? Adam? Cheers, Auke - 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-rc7: known regressions (v2) (part 1)
Auke Kok [EMAIL PROTECTED] writes: Adrian Bunk wrote: This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Subject: e1000: 82571EB/82572EI PCI-E cards: link is always down (MSI related) References : http://lkml.org/lkml/2007/1/16/27 http://lkml.org/lkml/2007/1/17/182 Submitter : Allen Parker [EMAIL PROTECTED] Adam Kropelin [EMAIL PROTECTED] Handled-By : Auke Kok [EMAIL PROTECTED] Status : problem is being debugged I probably can't fix this bug. Not only do I doubt that the e1000 driver is at fault here, I don't have a system with this particular chipset. Most likely the regression comes from a combination of MSI layer rewrites and possibly platform issues. We've seen many reports that are similar and all are on the platform type mentioned here. I really don't want to point fingers here either. None of the MSI code in e1000 has changed significantly either. as far as I can see, the msi code in e1000 has not changed since 2.6.18. Nonetheless there's no way I can debug any of this without a system. I will address the fact that we are lacking any of these systems to test on, but that is not going to get this issue handled (not to mention soon) in the way it needs to be. I strongly encourage the people on the linux-pci list to help out, I'll trace the e1000 driver for suspicious activity (again), but I run countless tests on the latest trees and nothing has shown up recently, other than Eric Biederman's msi irq reclaim leak fix. Perhaps Adam can git-bisect this issue? Adam? Do we have any explanation about the weird /proc/interrupts output? i.e. Multiple MSI irqs being assigned to the same card? Does /sbin/ifconfig ethN down ; /sbin/ifconfig ethN up have anything to do with the duplication in /proc/interrupts? I can't see any way for a pci device that doesn't support msi-x to be assigned multiple interrupts simultaneously. I just skimmed through the code and there hasn't been any significant generic MSI work since 2.6.19. Did this device really work with MSI enabled in 2.6.19? 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
