Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

[Ray Lee]

Larry Finger wrote:
> Ray Lee wrote:
>> Michael Buesch wrote:
>>> On Wednesday 15 November 2006 20:01, Ray Lee wrote:
 Suggestions? Requests for  even more info?
>>> Yeah, enable bcm43xx debugging.
>>
>> Sigh, didn't even think to look for that. Okay, enabled and compiling
>> a new kernel. This will take a few days to trigger, if the pattern holds, so
>> in the meantime, any *other* thoughts?
> 
> Which chip and revision do you have? Send me your equivalent of the line
> "bcm43xx: Chip ID 0x4306, rev 0x2".

bcm43xx: Chip ID 0x4306, rev 0x3

Also, another thing I wasn't clear about in my first email was that the netdev
watchdog timeouts are new with rc5:

$ zgrep 'NETDEV WATCH' /var/log/messages{,.0,.1.gz} | cut -d: -f2| cut -c 1-6
| uniq -c
   1249 Nov 13
  6 Nov  6
  1 Nov  7
  3 Nov  8
  2 Nov  9
   5717 Nov 10
   5652 Nov 11
  5 Oct 29
  3 Oct 30
  3 Oct 31
  4 Nov  1
  1 Nov  2
  1 Nov  3

I booted into 2.6.19-rc5 on November 10th. Previous to that was 2.6.19-rc3.
There really does seem to be something suspicious with that patch, yes?

Thanks,

Ray
-
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.19-rc5-mm2 -- bcm43xx busted (backing out the bcm43xx patches fixes it)

[Miles Lane]

On 11/15/06, Larry Finger <[EMAIL PROTECTED]> wrote:

Rafael J. Wysocki wrote:
> On Wednesday, 15 November 2006 00:21, Miles Lane wrote:
>> Hello,
>>
>> The last three MM kernels have fail to give me a working bcm43xx driver.
>> The odd thing is that dmesg output seems to indicate that the driver
>> is working okay.  NetworkManager doesn't see the driver, though.
>> "iwlist scan" fails to find any access points, too.  iwconfig shows
>> "Access Point: invalid".
>
> I can confirm the symptoms, I see them too on my test boxes.
>
>> I tried backing out the following patches, and it fixes the problem:
>>
>> drivers/net/wireless/bcm43xx/bcm43xx.h
>> drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> drivers/net/wireless/bcm43xx/bcm43xx_power.c
>> drivers/net/wireless/bcm43xx/bcm43xx_wx.c
>>> drivers/net/wireless/bcm43xx/bcm43xx_xmit.c

The missing patch is shown below. This patch was entitled "[PATCH] bcm43xx: 
Readd dropped
assignment" and submitted to wireless-2.6 by Daniel Drake on 10/17/06, but it 
seems to have fallen
through the cracks. It is a fix to a patch entitled "[PATCH] ieee80211: Move 
IV/ICV stripping into
ieee80211_rx" also submitted by Daniel Drake on 9/26/2006.

NOTE to maintainers: This problem affects BOTH wireless-2.6 and 2.6.19-rcX-mmY. 
At present, the
"Move IV/ICV" patch has not been incorporated into 2.6.19-rcX and it is OK.

Larry


In the patch sent by Daniel Drake under the title "[PATCH] ieee80211: Move
IV/ICV stripping into ieee80211_rx", a needed line was accidentally removed.
As my current copy of wireless-2.6.git does not contain this line, I am
(re)submitting a patch to restore that line.

Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---

Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -543,6 +543,7 @@ int bcm43xx_rx(struct bcm43xx_private *b
break;
}

+   frame_ctl = le16_to_cpu(wlhdr->frame_ctl);
switch (WLAN_FC_GET_TYPE(frame_ctl)) {
case IEEE80211_FTYPE_MGMT:
ieee80211_rx_mgt(bcm->ieee, wlhdr, &stats);




Thanks!  I have verified that this patch solves the problem for me.

 Miles
-
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: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)

[Michael Renzmann]

Hi.

Michael Buesch wrote:

Well, it never worked for me. But I gave up trying about
half a year ago. But maybe it's just stupid me. ;)


Well, we have various support channels (an IRC channel besides two 
mailing lists, for example) that you are welcome to make use of in case 
of problems :)


Bye, Mike


-
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] cxgb3: Chelsio T3 1G/10G ethernet device driver

[Stephen Hemminger]

My stuff really should have been in response to a differnt  mail thread.
   driver support for Chelsio T210 10Gb ethernet in 2.6.x
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2.6.19][TG3]: Disable TSO on 5906 if CLKREQ is enabled.

[Michael Chan]

[TG3]: Disable TSO on 5906 if CLKREQ is enabled.

Due to hardware errata, TSO must be disabled if the PCI Express clock
request is enabled on 5906.  The chip may hang when transmitting TSO
frames if CLKREQ is enabled.

Update version to 3.69.

Signed-off-by: Michael Chan <[EMAIL PROTECTED]>

diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 6e86866..1dbdd6b 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -68,8 +68,8 @@ #include "tg3.h"
 
 #define DRV_MODULE_NAME"tg3"
 #define PFX DRV_MODULE_NAME": "
-#define DRV_MODULE_VERSION "3.68"
-#define DRV_MODULE_RELDATE "November 02, 2006"
+#define DRV_MODULE_VERSION "3.69"
+#define DRV_MODULE_RELDATE "November 15, 2006"
 
 #define TG3_DEF_MAC_MODE   0
 #define TG3_DEF_RX_MODE0
@@ -10366,7 +10366,7 @@ static int __devinit tg3_get_invariants(
u32 pci_state_reg, grc_misc_cfg;
u32 val;
u16 pci_cmd;
-   int err;
+   int err, pcie_cap;
 
/* Force memory write invalidate off.  If we leave it on,
 * then on 5700_BX chips we have to enable a workaround.
@@ -10541,8 +10541,19 @@ static int __devinit tg3_get_invariants(
GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5906)
tp->tg3_flags2 |= TG3_FLG2_JUMBO_CAPABLE;
 
-   if (pci_find_capability(tp->pdev, PCI_CAP_ID_EXP) != 0)
+   pcie_cap = pci_find_capability(tp->pdev, PCI_CAP_ID_EXP);
+   if (pcie_cap != 0) {
tp->tg3_flags2 |= TG3_FLG2_PCI_EXPRESS;
+   if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
+   u16 lnkctl;
+
+   pci_read_config_word(tp->pdev,
+pcie_cap + PCI_EXP_LNKCTL,
+&lnkctl);
+   if (lnkctl & PCI_EXP_LNKCTL_CLKREQ_EN)
+   tp->tg3_flags2 &= ~TG3_FLG2_HW_TSO_2;
+   }
+   }
 
/* If we have an AMD 762 or VIA K8T800 chipset, write
 * reordering to the mailbox registers done by the host
@@ -11809,6 +11820,7 @@ #if TG3_TSO_SUPPORT != 0
else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 ||
tp->pci_chip_rev_id == CHIPREV_ID_5705_A0 ||
+   GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906 ||
(tp->tg3_flags & TG3_FLAG_ENABLE_ASF) != 0) {
tp->tg3_flags2 &= ~TG3_FLG2_TSO_CAPABLE;
} else {
diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
index c312a12..c321316 100644
--- a/include/linux/pci_regs.h
+++ b/include/linux/pci_regs.h
@@ -371,6 +371,7 @@ #define  PCI_EXP_DEVSTA_AUXPD   0x10/* AU
 #define  PCI_EXP_DEVSTA_TRPND  0x20/* Transactions Pending */
 #define PCI_EXP_LNKCAP 12  /* Link Capabilities */
 #define PCI_EXP_LNKCTL 16  /* Link Control */
+#define  PCI_EXP_LNKCTL_CLKREQ_EN 0x100/* Enable clkreq */
 #define PCI_EXP_LNKSTA 18  /* Link Status */
 #define PCI_EXP_SLTCAP 20  /* Slot Capabilities */
 #define PCI_EXP_SLTCTL 24  /* Slot Control */


-
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] cxgb3: Chelsio T3 1G/10G ethernet device driver

[Steve WIse]

On Wed, 2006-11-15 at 16:33 -0800, Stephen Hemminger wrote:
> On Wed, 15 Nov 2006 16:11:36 -0800
> divy <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> > 
> > This patch adds support for the latest Chelsio adapter, T3.
> > 
> > Since some files are bigger than the 40kB advertized in the submit
> > guidelines, a monolithic patch against 2.6.19-rc5 is posted at the
> > following URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2
> > 
> > Please advise on any other form you would like to see the code.
> > 
> > We wish this patch to be considered for inclusion in 2.6.20. This driver
> > will be required by the Chelsio T3 RDMA driver which will be posted for
> > review asap.
> > 
> > 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
> 
> 
> This took me an afternoon, so I don't see why Chelsio didn't do it.
> 
> Port of Chelsio's 2.2.0 version driver from:
> http://service.chelsio.com/drivers/linux/t210/cxgb2toe-2.2.0.tar.gz
> 
> De-vendorized:
> - removed all TCP Offload Engine support because those changes
>   will not be accepted in mainline kernel.
> - new files run through Lindent
> - removed code that was '#ifdef' for older kernel versions
> - fix for 2.6.19 irq
> - replace usage of TSC with ktime
> - remove /proc trace debug stuff
> - remove dead code
> - incorporate GSO, etc.
> - get rid of FILE_IDENT() macro
> - fix sparse warnings by adding __iomem and __user
> 
> Also, I kept as many of the filenames and device names the same since
> it is really just an extension of existing driver.
> 
> I'm testing it now.
> 

Stephen,

Divy posted a new driver to support the new Chelsio T3 hardware, not the
210 hardware.

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

[PATCH 10/13] Core HAL

[Steve Wise]

The RDMA Core interfaces with the T3 HW and ULLD providing a low level
RDMA interface.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/core/cxio_hal.c | 1306 +++
 drivers/infiniband/hw/cxgb3/core/cxio_hal.h |  201 
 2 files changed, 1507 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_hal.c 
b/drivers/infiniband/hw/cxgb3/core/cxio_hal.c
new file mode 100644
index 000..9821a72
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_hal.c
@@ -0,0 +1,1306 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "cxio_resource.h"
+#include "cxio_hal.h"
+#include "cxgb3_offload.h"
+#include "sge_defs.h"
+
+static struct cxio_rdev *rdev_tbl[T3_MAX_NUM_RNIC];
+static cxio_hal_ev_callback_func_t cxio_ev_cb = NULL;
+
+static inline struct cxio_rdev *cxio_hal_find_rdev_by_name(char *dev_name)
+{
+   int i;
+   for (i = 0; i < T3_MAX_NUM_RNIC; i++)
+   if (rdev_tbl[i])
+   if (!strcmp(rdev_tbl[i]->dev_name, dev_name))
+   return rdev_tbl[i];
+   return NULL;
+}
+
+static inline struct cxio_rdev *cxio_hal_find_rdev_by_t3cdev(struct t3cdev
+*tdev)
+{
+   int i;
+   for (i = 0; i < T3_MAX_NUM_RNIC; i++)
+   if (rdev_tbl[i])
+   if (rdev_tbl[i]->t3cdev_p == tdev)
+   return rdev_tbl[i];
+   return NULL;
+}
+
+static inline int cxio_hal_add_rdev(struct cxio_rdev *rdev_p)
+{
+   int i;
+   for (i = 0; i < T3_MAX_NUM_RNIC; i++) {
+   if (!rdev_tbl[i]) {
+   rdev_tbl[i] = rdev_p;
+   break;
+   }
+   }
+   return (i == T3_MAX_NUM_RNIC);
+}
+
+static inline void cxio_hal_delete_rdev(struct cxio_rdev *rdev_p)
+{
+   int i;
+   for (i = 0; i < T3_MAX_NUM_RNIC; i++)
+   if (rdev_tbl[i] == rdev_p) {
+   rdev_tbl[i] = NULL;
+   break;
+   }
+}
+
+int cxio_hal_cq_op(struct cxio_rdev *rdev_p, struct t3_cq *cq, 
+  enum t3_cq_opcode op, u32 credit)
+{
+   int ret;
+   struct t3_cqe *cqe;
+   u32 rptr;
+
+   struct rdma_cq_op setup;
+   setup.id = cq->cqid;
+   setup.credits = (op == CQ_CREDIT_UPDATE) ? credit : 0;
+   setup.op = op;
+   ret = rdev_p->t3cdev_p->ctl(rdev_p->t3cdev_p, RDMA_CQ_OP, &setup);
+
+   if ((ret < 0) || (op == CQ_CREDIT_UPDATE)) 
+   return ret;
+
+   /*
+* If the rearm returned an index other than our current index,
+* then there might be CQE's in flight (being DMA'd).  We must wait
+* here for them to complete or the consumer can miss a notification.
+*/
+   if (Q_PTR2IDX((cq->rptr), cq->size_log2) != ret) {
+   int i=0;
+
+   rptr = cq->rptr;
+
+   /* 
+* Keep the generation correct by bumping rptr until it
+* matches the index returned by the rearm - 1.
+*/
+   while (Q_PTR2IDX((rptr+1), cq->size_log2) != ret)
+   rptr++;
+
+   /* 
+* Now rptr is the index for the (last) cqe that was 
+* in-flight at the time the HW rearmed the CQ.  We 
+* spin until that CQE is v

[PATCH 07/13] Async Event Handler

[Steve Wise]

Code to handle async events coming from the T3 RDMA Core.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch_ev.c |  228 +
 1 files changed, 228 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch_ev.c 
b/drivers/infiniband/hw/cxgb3/iwch_ev.c
new file mode 100644
index 000..0726fa6
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_ev.c
@@ -0,0 +1,228 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include 
+#include 
+#include 
+#include "iwch_provider.h"
+#include "iwch.h"
+#include "iwch_cm.h"
+#include "cxio_hal.h"
+#include "cxio_wr.h"
+
+static void post_qp_event(struct iwch_dev *rnicp, struct iwch_cq *chp,
+ struct respQ_msg_t *rsp_msg,
+ enum ib_event_type ib_event, 
+ int send_term)
+{
+   struct ib_event event;
+   struct iwch_qp_attributes attrs;
+   struct iwch_qp *qhp;
+
+   printk(KERN_ERR "%s - AE qpid 0x%x opcode %d status 0x%x "
+  "type %d wrid.hi 0x%x wrid.lo 0x%x \n", __FUNCTION__, 
+  CQE_QPID(rsp_msg->cqe), CQE_OPCODE(rsp_msg->cqe), 
+  CQE_STATUS(rsp_msg->cqe), CQE_TYPE(rsp_msg->cqe),
+  CQE_WRID_HI(rsp_msg->cqe), CQE_WRID_LOW(rsp_msg->cqe));
+
+   spin_lock(&rnicp->lock);
+   qhp = rnicp->qpid2ptr[CQE_QPID(rsp_msg->cqe)];
+
+   if (!qhp) {
+   printk(KERN_ERR "%s unaffiliated error 0x%x qpid 0x%x\n", 
+  __FUNCTION__, CQE_STATUS(rsp_msg->cqe), 
+  CQE_QPID(rsp_msg->cqe));
+   spin_unlock(&rnicp->lock);
+   return;
+   }
+
+   if ((qhp->attr.state == IWCH_QP_STATE_ERROR) ||
+   (qhp->attr.state == IWCH_QP_STATE_TERMINATE)) {
+   PDBG("%s AE received after RTS - "
+"qp state %d qpid 0x%x status 0x%x\n", __FUNCTION__, 
+qhp->attr.state, qhp->wq.qpid, CQE_STATUS(rsp_msg->cqe));
+   spin_unlock(&rnicp->lock);
+   return;
+   }
+
+   atomic_inc(&qhp->refcnt);
+   spin_unlock(&rnicp->lock);
+
+   event.event = ib_event;
+   event.device = chp->ibcq.device;
+   if (ib_event == IB_EVENT_CQ_ERR)
+   event.element.cq = &chp->ibcq;
+   else 
+   event.element.qp = &qhp->ibqp;
+
+   if (qhp->ibqp.event_handler)
+   (*qhp->ibqp.event_handler)(&event, qhp->ibqp.qp_context);
+
+   attrs.next_state = IWCH_QP_STATE_TERMINATE;
+   if (send_term && (qhp->attr.state == IWCH_QP_STATE_RTS) && 
+   !iwch_modify_qp(qhp->rhp, qhp, IWCH_QP_ATTR_NEXT_STATE, &attrs, 1))
+   iwch_post_terminate(qhp, rsp_msg);
+
+   if (atomic_dec_and_test(&qhp->refcnt))
+   wake_up(&qhp->wait);
+}
+
+void iwch_ev_dispatch(struct cxio_rdev *rdev_p, struct sk_buff *skb)
+{
+   struct iwch_dev *rnicp;
+   struct respQ_msg_t *rsp_msg = (struct respQ_msg_t *) skb->data;
+   struct iwch_cq *chp;
+   struct iwch_qp *qhp;
+   u32 cqid = RSPQ_CQID(rsp_msg);
+
+   rnicp = (struct iwch_dev *) rdev_p->ulp;
+   spin_lock(&rnicp->lock);
+   chp = rnicp->cqid2ptr[cqid];
+   qhp = rnicp->qpid2ptr[CQE_QPID(rsp_msg->cqe)];
+   if (!chp || !qhp) {
+   printk(KERN_ERR MOD "BAD AE cqid 0x%x qpid 0x%x opcode %d "
+  "status 0x%x type %d wrid.hi 0x%x wrid.lo 0x%x \n", 
+  cqid, CQE_QPID(rsp_

[PATCH 13/13] Kconfig/Makefile

[Steve Wise]

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/Kconfig  |1 +
 drivers/infiniband/Makefile |1 +
 drivers/infiniband/hw/cxgb3/Kconfig |   27 +++
 drivers/infiniband/hw/cxgb3/Makefile|   12 
 drivers/infiniband/hw/cxgb3/locking.txt |   25 +
 5 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
index 59b3932..06453ab 100644
--- a/drivers/infiniband/Kconfig
+++ b/drivers/infiniband/Kconfig
@@ -38,6 +38,7 @@ source "drivers/infiniband/hw/mthca/Kcon
 source "drivers/infiniband/hw/ipath/Kconfig"
 source "drivers/infiniband/hw/ehca/Kconfig"
 source "drivers/infiniband/hw/amso1100/Kconfig"
+source "drivers/infiniband/hw/cxgb3/Kconfig"
 
 source "drivers/infiniband/ulp/ipoib/Kconfig"
 
diff --git a/drivers/infiniband/Makefile b/drivers/infiniband/Makefile
index 570b30a..69bdd55 100644
--- a/drivers/infiniband/Makefile
+++ b/drivers/infiniband/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_INFINIBAND_MTHCA)  += hw/mt
 obj-$(CONFIG_INFINIBAND_IPATH) += hw/ipath/
 obj-$(CONFIG_INFINIBAND_EHCA)  += hw/ehca/
 obj-$(CONFIG_INFINIBAND_AMSO1100)  += hw/amso1100/
+obj-$(CONFIG_INFINIBAND_CXGB3) += hw/cxgb3/
 obj-$(CONFIG_INFINIBAND_IPOIB) += ulp/ipoib/
 obj-$(CONFIG_INFINIBAND_SRP)   += ulp/srp/
 obj-$(CONFIG_INFINIBAND_ISER)  += ulp/iser/
diff --git a/drivers/infiniband/hw/cxgb3/Kconfig 
b/drivers/infiniband/hw/cxgb3/Kconfig
new file mode 100644
index 000..84f0f6e
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/Kconfig
@@ -0,0 +1,27 @@
+config INFINIBAND_CXGB3
+   tristate "Chelsio RDMA Driver"
+   depends on CHELSIO_T3 && INFINIBAND
+   select GENERIC_ALLOCATOR
+   ---help---
+ This is an iWARP/RDMA driver for the Chelsio T3 1GbE and
+ 10GbE adapters.
+
+  For general information about Chelsio and our products, visit
+  our website at .
+
+  For customer support, please visit our customer support page at
+  .
+
+  Please send feedback to <[EMAIL PROTECTED]>.
+
+  To compile this driver as a module, choose M here: the module
+  will be called iw_cxgb3.
+
+config INFINIBAND_CXGB3_DEBUG
+   bool "Verbose debugging output"
+   depends on INFINIBAND_CXGB3
+   default n
+   ---help---
+ This option causes the Chelsio RDMA driver to produce copious
+ amounts of debug messages.  Select this if you are developing
+ the driver or trying to diagnose a problem.
diff --git a/drivers/infiniband/hw/cxgb3/Makefile 
b/drivers/infiniband/hw/cxgb3/Makefile
new file mode 100644
index 000..0df2b3d
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/Makefile
@@ -0,0 +1,12 @@
+EXTRA_CFLAGS += -I$(TOPDIR)/drivers/net/cxgb3 \
+   -I$(TOPDIR)/drivers/infiniband/hw/cxgb3/core 
+
+obj-$(CONFIG_INFINIBAND_CXGB3) += iw_cxgb3.o
+
+iw_cxgb3-y :=  iwch_cm.o iwch_ev.o iwch_cq.o iwch_qp.o iwch_mem.o \
+  iwch_provider.o iwch.o core/cxio_hal.o core/cxio_resource.o
+
+ifdef CONFIG_INFINIBAND_CXGB3_DEBUG
+EXTRA_CFLAGS += -DDEBUG -O1 -g 
+iw_cxgb3-y += core/cxio_dbg.o
+endif
diff --git a/drivers/infiniband/hw/cxgb3/locking.txt 
b/drivers/infiniband/hw/cxgb3/locking.txt
new file mode 100644
index 000..e5e9991
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/locking.txt
@@ -0,0 +1,25 @@
+cq lock:
+   - spin lock
+   - used to synchronize the t3_cq
+
+qp lock:
+   - spin lock
+   - used to synchronize updates to the qp state, attrs, and the t3_wq.
+   - touched on interrupt and process context
+   
+rnicp lock:
+   - spin lock
+   - touched on interrupt and process context
+   - used around lookup tables mapping CQID and QPID to a structure.
+   - used also to bump the refcnt atomically with the lookup.
+
+poll:
+   lock+disable on cq lock
+   lock qp lock for each cqe that is polled around the call
+   to cxio_poll_cq().
+   
+post: 
+   lock+disable qp lock
+
+global mutex iwch_mutex:
+   used to maintain global device list.
-
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 09/13] Core WQE/CQE Types

[Steve Wise]

T3 WQE and CQE structures, defines, etc...

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/core/cxio_wr.h |  658 
 1 files changed, 658 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_wr.h 
b/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
new file mode 100644
index 000..ad84708
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
@@ -0,0 +1,658 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#ifndef __CXIO_WR_H__
+#define __CXIO_WR_H__
+
+#include 
+#include 
+#include 
+#include "firmware_exports.h"
+
+#define T3_MAX_SGE  4
+
+#define Q_EMPTY(rptr,wptr) ((rptr)==(wptr))
+#define Q_FULL(rptr,wptr,size_log2)  ( (((wptr)-(rptr))>>(size_log2)) && \
+  ((rptr)!=(wptr)) )
+#define Q_GENBIT(ptr,size_log2) (!(((ptr)>>size_log2)&0x1))
+#define Q_FREECNT(rptr,wptr,size_log2) ((1UL<> S_FW_RIWR_OP)) & M_FW_RIWR_OP)
+
+#define S_FW_RIWR_SOPEOP   22
+#define M_FW_RIWR_SOPEOP   0x3
+#define V_FW_RIWR_SOPEOP(x)((x) << S_FW_RIWR_SOPEOP)
+
+#define S_FW_RIWR_FLAGS8
+#define M_FW_RIWR_FLAGS0x3f
+#define V_FW_RIWR_FLAGS(x) ((x) << S_FW_RIWR_FLAGS)
+#define G_FW_RIWR_FLAGS(x) x) >> S_FW_RIWR_FLAGS)) & M_FW_RIWR_FLAGS)
+
+#define S_FW_RIWR_TID  8
+#define V_FW_RIWR_TID(x)   ((x) << S_FW_RIWR_TID)
+
+#define S_FW_RIWR_LEN  0
+#define V_FW_RIWR_LEN(x)   ((x) << S_FW_RIWR_LEN)
+
+#define S_FW_RIWR_GEN   31
+#define V_FW_RIWR_GEN(x)((x)  << S_FW_RIWR_GEN)
+
+struct t3_sge {
+   u32 stag;
+   u32 len;
+   u64 to;
+};
+
+/* If num_sgle is zero, flit 5+ contains immediate data.*/
+struct t3_send_wr {
+   struct fw_riwrh wrh;/* 0 */
+   union t3_wrid wrid; /* 1 */
+
+   enum t3_rdma_opcode rdmaop:8;
+   u32 reserved:24;/* 2 */
+   u32 rem_stag;   /* 2 */
+   u32 plen;   /* 3 */
+   u32 num_sgle;
+   struct t3_sge sgl[T3_MAX_SGE];  /* 4+ */
+};
+
+struct t3_local_inv_wr {
+   struct fw_riwrh wrh;/* 0 */
+   union t3_wrid wrid; /* 1 */
+   u32 stag;   /* 2 */
+   u32 reserved3;
+};
+
+struct t3_rdma_write_wr {
+   struct fw_riwrh wrh;/* 0 */
+   union t3_wrid wrid; /* 1 */
+   enum t3_rdma_opcode rdmaop:8;   /* 2 */
+   u32 reserved:24;/* 2 */
+   u32 stag_sink;
+   u64 to_sink;/* 3 */
+   u32 plen;   /* 4 */
+   u32 num_sgle;
+   struct t3_sge sgl[T3_MAX_SGE];  /* 5+ */
+};
+
+struct t3_rdma_read_wr {
+   struct fw_riwrh wrh;/* 0 */
+   union t3_wrid wrid; /* 1 */
+   enum t3_rdma_opcode rdmaop:8;   /* 2 */
+   u32 reserved:24;
+   u32 rem_stag;
+   u64 rem_to; /* 3 */
+   u32 local_stag; /* 4 */
+   u32 local_len;
+   u64 local_to;   /* 5 */
+};
+
+enum t3_addr_type {
+   T3_VA_BASED_TO = 0x0,
+   T3_ZERO_BASED_TO = 0x1
+} __attribute__ ((packed));
+
+enum t3_mem_perms {
+   T3_MEM_ACCESS_LOCAL_READ = 0x1,
+   T3_MEM_ACCESS_LOCAL_WRITE = 0x2,
+   T3_MEM_ACCESS_REM_READ = 0x4,
+   T3_MEM_ACCESS_REM_WRITE = 0x8
+} __attribute__ ((packed));
+
+struct t3_bind_mw_wr {
+   struct fw_riwrh wrh;/* 0 */
+   union t3_wrid wrid; /* 1 */
+   u32 reserved:16;
+   enum t3_addr_type type:8;
+   enum t3_mem_perms perms:8;  /* 2 */
+   u32 

[PATCH 08/13] Memory Registration

[Steve Wise]

Functions to register memory regions.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch_mem.c |  175 
 1 files changed, 175 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch_mem.c 
b/drivers/infiniband/hw/cxgb3/iwch_mem.c
new file mode 100644
index 000..9aad3a0
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_mem.c
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include 
+
+#include 
+#include 
+
+#include "cxio_hal.h"
+#include "iwch.h"
+#include "iwch_provider.h"
+
+int iwch_register_mem(struct iwch_dev *rhp, struct iwch_pd *php,
+   struct iwch_mr *mhp,
+   int shift,
+   u64 *page_list)
+{
+   u32 stag;
+   u32 mmid;
+
+
+   if (cxio_register_phys_mem(&rhp->rdev,
+  &stag, mhp->attr.pdid,
+  mhp->attr.perms,
+  mhp->attr.zbva,
+  mhp->attr.va_fbo,
+  mhp->attr.len,
+  shift-12,
+  page_list,
+  &mhp->attr.pbl_size, &mhp->attr.pbl_addr)) {
+   return -ENOMEM;
+   }
+   mhp->attr.state = 1;
+   mhp->attr.stag = stag;
+   mmid = stag >> 8;
+   mhp->ibmr.rkey = mhp->ibmr.lkey = stag;
+   rhp->mmid2ptr[mmid] = mhp;
+   PDBG("%s mmid 0x%x mhp %p\n", __FUNCTION__, mmid, mhp);
+   return 0;
+}
+
+int iwch_reregister_mem(struct iwch_dev *rhp, struct iwch_pd *php,
+   struct iwch_mr *mhp,
+   int shift,
+   u64 *page_list,
+   int npages)
+{
+   u32 stag;
+   u32 mmid;
+
+
+   /* We could support this... */
+   if (npages > mhp->attr.pbl_size)
+   return -ENOMEM;
+
+   stag = mhp->attr.stag;
+   if (cxio_reregister_phys_mem(&rhp->rdev,
+  &stag, mhp->attr.pdid,
+  mhp->attr.perms,
+  mhp->attr.zbva,
+  mhp->attr.va_fbo,
+  mhp->attr.len,
+  shift-12,
+  page_list,
+  &mhp->attr.pbl_size, &mhp->attr.pbl_addr)) {
+   return -ENOMEM;
+   }
+   mhp->attr.state = 1;
+   mhp->attr.stag = stag;
+   mmid = stag >> 8;
+   mhp->ibmr.rkey = mhp->ibmr.lkey = stag;
+   rhp->mmid2ptr[mmid] = mhp;
+   PDBG("%s mmid 0x%x mhp %p\n", __FUNCTION__, mmid, mhp);
+   return 0;
+}
+
+int build_phys_page_list(struct ib_phys_buf *buffer_list,
+   int num_phys_buf,
+   u64 *iova_start,
+   u64 *total_size,
+   int *npages,
+   int *shift,
+   u64 **page_list)
+{
+   u64 mask;
+   int i, j, n;
+
+   mask = 0;
+   *total_size = 0;
+   for (i = 0; i < num_phys_buf; ++i) {
+   if (i != 0 && buffer_list[i].addr & ~PAGE_MASK)
+ 

[PATCH 02/13] Device Discovery and ULLD Linkage

[Steve Wise]

Code to discover all the T3 devices and register them 
with the T3 RDMA Core and the Linux RDMA Core.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch.c |  222 
 drivers/infiniband/hw/cxgb3/iwch.h |  134 ++
 2 files changed, 356 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch.c 
b/drivers/infiniband/hw/cxgb3/iwch.c
new file mode 100644
index 000..f45f005
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch.c
@@ -0,0 +1,222 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include 
+#include 
+
+#include 
+
+#include "cxgb3_offload.h"
+#include "iwch_provider.h"
+#include "iwch_user.h"
+#include "iwch.h"
+#include "iwch_cm.h"
+
+#define DRV_VERSION "1.1"
+
+MODULE_AUTHOR("Boyd Faulkner, Steve Wise");
+MODULE_DESCRIPTION("Chelsio T3 RDMA Driver");
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_VERSION(DRV_VERSION);
+
+cxgb3_cpl_handler_func t3c_handlers[NUM_CPL_CMDS];
+
+static void open_rnic_dev(struct t3cdev *);
+static void close_rnic_dev(struct t3cdev *);
+
+struct cxgb3_client t3c_client = {
+   .name = "iw_cxgb3",
+   .add = open_rnic_dev,
+   .remove = close_rnic_dev,
+   .handlers = t3c_handlers,
+   .redirect = iwch_ep_redirect
+};
+
+static LIST_HEAD(dev_list);
+static DEFINE_MUTEX(dev_mutex);
+
+static inline void *vzmalloc(int size)
+{
+   void *p = vmalloc(size);
+   memset(p, 0, size);
+   return p;
+}
+
+static int open_rnic_init(struct iwch_dev *rnicp)
+{
+   PDBG("%s iwch_dev %p\n", __FUNCTION__,  rnicp);
+   rnicp->pdid2ptr = vzmalloc(sizeof(void*) * T3_MAX_NUM_PD);
+   if (!rnicp->pdid2ptr)
+   goto pdid_err;
+   rnicp->cqid2ptr = vzmalloc(sizeof(void*) * T3_MAX_NUM_CQ);
+   if (!rnicp->cqid2ptr)
+   goto cqid_err;
+   rnicp->qpid2ptr = vzmalloc(sizeof(void*) * T3_MAX_NUM_QP);
+   if (!rnicp->qpid2ptr)
+   goto qpid_err;
+   rnicp->mmid2ptr = vzmalloc(sizeof(void*) * 
+  cxio_num_stags(&rnicp->rdev));
+   if (!rnicp->mmid2ptr)
+   goto stag_err;
+
+   spin_lock_init(&rnicp->lock);
+
+   rnicp->attr.vendor_id = 0x168;
+   rnicp->attr.vendor_part_id = 7;
+   rnicp->attr.max_qps = T3_MAX_NUM_QP - 32;
+   rnicp->attr.max_wrs = (1UL << 24) - 1;
+   rnicp->attr.max_sge_per_wr = T3_MAX_SGE;
+   rnicp->attr.max_sge_per_rdma_write_wr = T3_MAX_SGE;
+   rnicp->attr.max_cqs = T3_MAX_NUM_CQ - 1;
+   rnicp->attr.max_cqes_per_cq = (1UL << 24) - 1;
+   rnicp->attr.max_mem_regs = cxio_num_stags(&rnicp->rdev);
+   rnicp->attr.max_phys_buf_entries = T3_MAX_PBL_SIZE;
+   rnicp->attr.max_pds = T3_MAX_NUM_PD - 1;
+   rnicp->attr.mem_pgsizes_bitmask = 0x7FFF;   /* 4KB-128MB */
+   rnicp->attr.can_resize_wq = 0;
+   rnicp->attr.max_rdma_reads_per_qp = 8;
+   rnicp->attr.max_rdma_read_resources =
+   rnicp->attr.max_rdma_reads_per_qp * rnicp->attr.max_qps;
+   rnicp->attr.max_rdma_read_qp_depth = 8; /* IRD */
+   rnicp->attr.max_rdma_read_depth =
+   rnicp->attr.max_rdma_read_qp_depth * rnicp->attr.max_qps;
+   rnicp->attr.rq_overflow_handled = 0;
+   rnicp->attr.can_modify_ird = 0;
+   rnicp->attr.can_modify_ord = 0;
+   rnicp->attr.max_mem_windows = rnicp->attr.max_mem_regs - 1;
+   rnicp->attr.stag0_value = 1;
+   rnicp->attr.zbva_support = 1;
+   rnicp->attr.local_invalidate_fe

[PATCH 03/13] Provider Methods and Data Structures

[Steve Wise]

Provider methods to support the Linux RDMA verbs.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch_provider.c | 1186 +++
 drivers/infiniband/hw/cxgb3/iwch_provider.h |  390 +
 drivers/infiniband/hw/cxgb3/iwch_user.h |   68 ++
 3 files changed, 1644 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c 
b/drivers/infiniband/hw/cxgb3/iwch_provider.c
new file mode 100644
index 000..11afe0c
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -0,0 +1,1186 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "iwch.h"
+#include "iwch_provider.h"
+#include "iwch_cm.h"
+#include "iwch_user.h"
+
+static int iwch_modify_port(struct ib_device *ibdev,
+   u8 port, int port_modify_mask,
+   struct ib_port_modify *props)
+{
+   return -ENOSYS;
+}
+
+static struct ib_ah *iwch_ah_create(struct ib_pd *pd,
+   struct ib_ah_attr *ah_attr)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
+static int iwch_ah_destroy(struct ib_ah *ah)
+{
+   return -ENOSYS;
+}
+
+static int iwch_multicast_attach(struct ib_qp *ibqp, union ib_gid *gid, u16 
lid)
+{
+   return -ENOSYS;
+}
+
+static int iwch_multicast_detach(struct ib_qp *ibqp, union ib_gid *gid, u16 
lid)
+{
+   return -ENOSYS;
+}
+
+static int iwch_process_mad(struct ib_device *ibdev,
+   int mad_flags,
+   u8 port_num,
+   struct ib_wc *in_wc,
+   struct ib_grh *in_grh,
+   struct ib_mad *in_mad, struct ib_mad *out_mad)
+{
+   return -ENOSYS;
+}
+
+static int iwch_dealloc_ucontext(struct ib_ucontext *context)
+{
+   struct iwch_dev *rhp = to_iwch_dev(context->device);
+   struct iwch_ucontext *ucontext = to_iwch_ucontext(context);
+   PDBG("%s context %p\n", __FUNCTION__, context);
+   cxio_release_ucontext(&rhp->rdev, &ucontext->uctx);
+   kfree(ucontext);
+   return 0;
+}
+
+static struct ib_ucontext *iwch_alloc_ucontext(struct ib_device *ibdev,
+   struct ib_udata *udata)
+{
+   struct iwch_ucontext *context;
+   struct iwch_dev *rhp = to_iwch_dev(ibdev);
+
+   PDBG("%s ibdev %p\n", __FUNCTION__, ibdev);
+   context = kmalloc(sizeof(*context), GFP_KERNEL);
+   if (!context)
+   return ERR_PTR(-ENOMEM);
+   cxio_init_ucontext(&rhp->rdev, &context->uctx);
+   INIT_LIST_HEAD(&context->mmaps);
+   return &context->ibucontext;
+}
+
+static int iwch_destroy_cq(struct ib_cq *ib_cq)
+{
+   struct iwch_cq *chp;
+
+   PDBG("%s ib_cq %p\n", __FUNCTION__, ib_cq);
+   chp = to_iwch_cq(ib_cq);
+
+   spin_lock_irq(&chp->rhp->lock);
+   chp->rhp->cqid2ptr[chp->cq.cqid] = NULL;
+   spin_unlock_irq(&chp->rhp->lock);
+
+   atomic_dec(&chp->refcnt);
+   wait_event(chp->wait, !atomic_read(&chp->refcnt));
+
+   cxio_destroy_cq(&chp->rhp->rdev, &chp->cq);
+   kfree(chp);
+   return 0;
+}
+
+static struct ib_cq *iwch_create_cq(struct ib_device *ibdev, int entries,
+struct ib_ucontext *context,
+struct ib_udata *

[PATCH 11/13] Core Resource Allocation

[Steve Wise]

Core functions to carve up adapter memory, stag, qp, and cq IDs.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/core/cxio_resource.c |  357 ++
 drivers/infiniband/hw/cxgb3/core/cxio_resource.h |   70 
 2 files changed, 427 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_resource.c 
b/drivers/infiniband/hw/cxgb3/core/cxio_resource.c
new file mode 100644
index 000..ada44b9
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_resource.c
@@ -0,0 +1,357 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+/* Crude resource management */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cxio_resource.h"
+#include "cxio_hal.h"
+
+static struct kfifo *rhdl_fifo;
+static spinlock_t rhdl_fifo_lock;
+
+#define RANDOM_SIZE 16
+
+
+/* Loosely based on the Mersenne twister algorithm */
+static u32 next_random(u32 rand)
+{
+   u32 y, ylast;
+
+   y = rand;   
+   ylast = y;
+   y = (y * 69069) & 0x;
+   y = (y & 0x8000) + (ylast & 0x7fff);
+   if ((y & 1))
+   y = ylast ^ (y > 1) ^ (2567483615UL);
+   else
+   y = ylast ^ (y > 1);
+   y = y ^ (y >> 11);
+   y = y ^ ((y >> 7) & 2636928640UL);
+   y = y ^ ((y >> 15) & 4022730752UL);
+   y = y ^ (y << 18);
+   return y;
+}
+static int __cxio_init_resource_fifo(struct kfifo **fifo,
+  spinlock_t *fifo_lock,
+  u32 nr, u32 skip_low,
+  u32 skip_high,
+  int random)
+{
+   u32 i, j, entry = 0, idx;
+   u32 random_bytes;
+   u32 rarray[16];
+   spin_lock_init(fifo_lock);
+
+   *fifo = kfifo_alloc(nr * sizeof(u32), GFP_KERNEL, fifo_lock);
+   if (IS_ERR(*fifo))
+   return -ENOMEM;
+
+   for (i = 0; i < skip_low + skip_high; i++)
+   __kfifo_put(*fifo, (unsigned char *) &entry, sizeof(u32));
+   if (random) {
+   j = 0;
+   get_random_bytes(&random_bytes,sizeof(random_bytes));
+   for (i = 0; i < RANDOM_SIZE; i++)
+   rarray[i] = i + skip_low;
+   for (i = skip_low + RANDOM_SIZE; i < nr - skip_high; i++) {
+   if (j >= RANDOM_SIZE) {
+   j = 0;
+   random_bytes = next_random(random_bytes);
+   }
+   idx = (random_bytes >> (j * 2)) & 0xF;
+   __kfifo_put(*fifo, 
+   (unsigned char *) &rarray[idx],
+   sizeof(u32));
+   rarray[idx] = i;
+   j++;
+   }
+   for (i = 0; i < RANDOM_SIZE; i++)
+   __kfifo_put(*fifo, 
+   (unsigned char *) &rarray[i],
+   sizeof(u32));
+   } else
+   for (i = skip_low; i < nr - skip_high; i++)
+   __kfifo_put(*fifo, (unsigned char *) &i, sizeof(u32));
+
+   for (i = 0; i < skip_low + skip_high; i++)
+   kfifo_get(*fifo, (unsigned char *) &entry, sizeof(u32));
+   return 0;
+}
+
+static int cxio_init_resource_fifo(struct kfifo **fifo, spinlock_t * fifo_lock,
+  u32 nr, u32 skip_low, u32 skip_high)
+{
+   return (__cxio_init_

[PATCH 12/13] Core Debug functions

[Steve Wise]

Debug code to dump various data structs, some of which are in 
adapter memory.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/core/cxio_dbg.c |  205 +++
 1 files changed, 205 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_dbg.c 
b/drivers/infiniband/hw/cxgb3/core/cxio_dbg.c
new file mode 100644
index 000..ffe5261
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_dbg.c
@@ -0,0 +1,205 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#ifdef DEBUG
+#include 
+#include "common.h"
+#include "cxgb3_ioctl.h"
+#include "cxio_hal.h"
+#include "cxio_wr.h"
+
+void cxio_dump_tpt(struct cxio_rdev *rdev, u32 stag) 
+{
+   struct ch_mem_range *m;
+   u64 *data;
+   int rc;
+   int size = 32;
+
+   m = kmalloc(sizeof(*m) + size, GFP_ATOMIC);
+   if (!m) {
+   PDBG("%s couldn't allocate memory.\n", __FUNCTION__);
+   return;
+   }
+   m->mem_id = MEM_PMRX;
+   m->addr = (stag>>8) * 32 + rdev->rnic_info.tpt_base;
+   m->len = size;
+   PDBG("%s TPT addr 0x%x len %d\n", __FUNCTION__, m->addr, m->len);
+   rc = rdev->t3cdev_p->ctl(rdev->t3cdev_p, RDMA_GET_MEM, m);
+   if (rc) {
+   PDBG("%s toectl returned error %d\n", __FUNCTION__, rc);
+   kfree(m);
+   return;
+   }
+
+   data = (u64 *)m->buf;
+   while (size > 0) {
+   PDBG("TPT %08x: %016llx\n", m->addr, (u64)*data);
+   size -= 8;
+   data++;
+   m->addr += 8;
+   }
+   kfree(m);
+}
+
+void cxio_dump_pbl(struct cxio_rdev *rdev, u32 pbl_addr, uint len, u8 shift)
+{
+   struct ch_mem_range *m;
+   u64 *data;
+   int rc;
+   int size, npages;
+
+   shift += 12;
+   npages = (len + (1ULL << shift) - 1) >> shift;
+   size = npages * sizeof(u64);
+
+   m = kmalloc(sizeof(*m) + size, GFP_ATOMIC);
+   if (!m) {
+   PDBG("%s couldn't allocate memory.\n", __FUNCTION__);
+   return;
+   }
+   m->mem_id = MEM_PMRX;
+   m->addr = pbl_addr;
+   m->len = size;
+   PDBG("%s PBL addr 0x%x len %d depth %d\n", 
+   __FUNCTION__, m->addr, m->len, npages);
+   rc = rdev->t3cdev_p->ctl(rdev->t3cdev_p, RDMA_GET_MEM, m);
+   if (rc) {
+   PDBG("%s toectl returned error %d\n", __FUNCTION__, rc);
+   kfree(m);
+   return;
+   }
+
+   data = (u64 *)m->buf;
+   while (size > 0) {
+   PDBG("PBL %08x: %016llx\n", m->addr, (u64)*data);
+   size -= 8;
+   data++;
+   m->addr += 8;
+   }
+   kfree(m);
+}
+
+void cxio_dump_wqe(union t3_wr *wqe)
+{
+   u64 *data = (u64 *)wqe;
+   uint size = (uint)(be64_to_cpu(*data) & 0xff);
+
+   if (size == 0) 
+   size = 8;
+   while (size > 0) {
+   PDBG("WQE %p: %016llx\n", data, be64_to_cpu(*data));
+   size--;
+   data++;
+   }
+}
+
+void cxio_dump_wce(struct t3_cqe *wce)
+{
+   u64 *data = (u64 *)wce;
+   int size = sizeof(*wce);
+
+   while (size > 0) {
+   PDBG("WCE %p: %016llx\n", data, be64_to_cpu(*data));
+   size -= 8;
+   data++;
+   }
+}
+
+void cxio_dump_rqt(struct cxio_rdev *rdev, u32 hwtid, int nents)
+{
+   struct ch_mem_range *m;
+   int size = nents * 64;
+   u64 *data;
+   int rc;
+

[PATCH 06/13] Completion Queues

[Steve Wise]

Functions to manipulate CQs.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch_cq.c |  231 +
 1 files changed, 231 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch_cq.c 
b/drivers/infiniband/hw/cxgb3/iwch_cq.c
new file mode 100644
index 000..aa5c0f6
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_cq.c
@@ -0,0 +1,231 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include "iwch_provider.h"
+#include "iwch.h"
+
+/*
+ * Get one cq entry from cxio and map it to openib.
+ *
+ * Returns:
+ * 0   EMPTY;
+ * 1   cqe returned
+ * -EAGAIN caller must try again
+ * any other -errnofatal error
+ */
+int iwch_poll_cq_one(struct iwch_dev *rhp, struct iwch_cq *chp,
+struct ib_wc *wc)
+{
+   struct iwch_qp *qhp = NULL;
+   struct t3_cqe cqe, *rd_cqe;
+   struct t3_wq *wq;
+   u32 credit = 0;
+   u8 cqe_flushed;
+   u64 cookie;
+   int ret = 1;
+
+   rd_cqe = cxio_next_cqe(&chp->cq);
+
+   if (!rd_cqe)
+   return 0;
+
+   qhp = get_qhp(rhp, CQE_QPID(*rd_cqe));
+   if (!qhp)
+   wq = NULL;
+   else {
+   spin_lock(&qhp->lock);
+   wq = &(qhp->wq);
+   }
+   ret = cxio_poll_cq(wq, &(chp->cq), &cqe, &cqe_flushed, &cookie,
+  &credit);
+   if (t3a_device(chp->rhp) && credit) {
+   PDBG("%s updating %d cq credits on id %d\n", __FUNCTION__, 
+credit, chp->cq.cqid);
+   cxio_hal_cq_op(&rhp->rdev, &chp->cq, CQ_CREDIT_UPDATE, credit);
+   }
+
+   if (ret) {
+   ret = -EAGAIN;
+   goto out;
+   }
+   ret = 1;
+
+   wc->wr_id = cookie;
+   wc->qp_num = qhp->wq.qpid;
+   wc->vendor_err = CQE_STATUS(cqe);
+
+   PDBG("%s qpid 0x%x type %d opcode %d status 0x%x wrid hi 0x%x "
+"lo 0x%x cookie 0x%llx\n", __FUNCTION__, 
+CQE_QPID(cqe), CQE_TYPE(cqe),
+CQE_OPCODE(cqe), CQE_STATUS(cqe), CQE_WRID_HI(cqe),
+CQE_WRID_LOW(cqe), cookie);
+
+   if (CQE_TYPE(cqe) == 0) {
+   if (!CQE_STATUS(cqe))
+   wc->byte_len = CQE_LEN(cqe);
+   else
+   wc->byte_len = 0;
+   wc->opcode = IB_WC_RECV;
+   } else {
+   switch (CQE_OPCODE(cqe)) {
+   case T3_RDMA_WRITE:
+   wc->opcode = IB_WC_RDMA_WRITE;
+   break;
+   case T3_READ_REQ:
+   wc->opcode = IB_WC_RDMA_READ;
+   wc->byte_len = CQE_LEN(cqe);
+   break;
+   case T3_SEND:
+   case T3_SEND_WITH_SE:
+   wc->opcode = IB_WC_SEND;
+   break;
+   case T3_BIND_MW:
+   wc->opcode = IB_WC_BIND_MW;
+   break;
+
+   /* these aren't supported yet */
+   case T3_SEND_WITH_INV:
+   case T3_SEND_WITH_SE_INV:
+   case T3_LOCAL_INV:
+   case T3_FAST_REGISTER:
+   default:
+   printk(KERN_ERR MOD "Unexpected opcode %d "
+  "in the CQE received for QPID=0x%0x\n", 
+  CQE_OPCODE(cqe), CQE_QPID(cqe));
+   

[PATCH 05/13] Queue Pairs

[Steve Wise]

Code to manipulate the QP.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/hw/cxgb3/iwch_qp.c |  996 +
 1 files changed, 996 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb3/iwch_qp.c 
b/drivers/infiniband/hw/cxgb3/iwch_qp.c
new file mode 100644
index 000..dc1c55e
--- /dev/null
+++ b/drivers/infiniband/hw/cxgb3/iwch_qp.c
@@ -0,0 +1,996 @@
+/*
+ * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
+ * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include "iwch_provider.h"
+#include "iwch.h"
+#include "iwch_cm.h"
+#include "cxio_hal.h"
+
+#define NO_SUPPORT -1
+
+static inline int iwch_build_rdma_send(union t3_wr *wqe,
+   struct ib_send_wr *wr,
+   u8 * flit_cnt)
+{
+   int i;
+   switch (wr->opcode) {
+   case IB_WR_SEND:
+   case IB_WR_SEND_WITH_IMM:
+   if (wr->send_flags & IB_SEND_SOLICITED)
+   wqe->send.rdmaop = T3_SEND_WITH_SE;
+   else
+   wqe->send.rdmaop = T3_SEND;
+   wqe->send.rem_stag = 0;
+   break;
+#if 0  /* Not currently supported */
+   case TYPE_SEND_INVALIDATE:
+   case TYPE_SEND_INVALIDATE_IMMEDIATE:
+   wqe->send.rdmaop = T3_SEND_WITH_INV;
+   wqe->send.rem_stag = cpu_to_be32(wr->wr.rdma.rkey);
+   break;
+   case TYPE_SEND_SE_INVALIDATE:
+   wqe->send.rdmaop = T3_SEND_WITH_SE_INV;
+   wqe->send.rem_stag = cpu_to_be32(wr->wr.rdma.rkey);
+   break;
+#endif
+   default:
+   break;
+   }
+   if (wr->num_sge > T3_MAX_SGE)
+   return -EINVAL;
+   wqe->send.reserved = 0;
+   if (wr->opcode == IB_WR_SEND_WITH_IMM) {
+   wqe->send.plen = 4;
+   wqe->send.sgl[0].stag = wr->imm_data;
+   wqe->send.sgl[0].len = 0;
+   wqe->send.num_sgle = 0;
+   *flit_cnt = 5;
+   } else {
+   wqe->send.plen = 0;
+   for (i = 0; i < wr->num_sge; i++) {
+   if ((wqe->send.plen + wr->sg_list[i].length) < 
+   wqe->send.plen) {
+   return -EMSGSIZE;
+   }
+   wqe->send.plen += wr->sg_list[i].length;
+   wqe->send.sgl[i].stag =
+   cpu_to_be32(wr->sg_list[i].lkey);
+   wqe->send.sgl[i].len =
+   cpu_to_be32(wr->sg_list[i].length);
+   wqe->send.sgl[i].to = cpu_to_be64(wr->sg_list[i].addr);
+   }
+   wqe->send.plen = cpu_to_be32(wqe->send.plen);
+   wqe->send.num_sgle = cpu_to_be32(wr->num_sge);
+   *flit_cnt = 4 + ((wr->num_sge) << 1);
+   }
+   return 0;
+}
+
+static inline int iwch_build_rdma_write(union t3_wr *wqe,
+   struct ib_send_wr *wr,
+   u8 *flit_cnt)
+{
+   int i;
+   if (wr->num_sge > T3_MAX_SGE)
+   return -EINVAL;
+   wqe->write.rdmaop = T3_RDMA_WRITE;
+   wqe->write.reserved = 0;
+   wqe->write.stag_sink = cpu_to_be32(wr->wr.rdma.rkey);
+   wqe->write.to_sink = cpu_to_be64(wr->wr.rdma.remote_addr);
+
+   wqe->write.num_sgle = wr->num_sge;
+
+   if (wr->opcode == IB_WR_RDMA_WRITE_WI

[PATCH 01/13] Linux RDMA Core Changes

[Steve Wise]

Support provider-specific data in ib_uverbs_cmd_req_notify_cq().
The Chelsio iwarp provider library needs to pass information to the
kernel verb for re-arming the CQ.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/core/uverbs_cmd.c  |9 +++--
 drivers/infiniband/hw/amso1100/c2.h   |2 +-
 drivers/infiniband/hw/amso1100/c2_cq.c|3 ++-
 drivers/infiniband/hw/ehca/ehca_iverbs.h  |3 ++-
 drivers/infiniband/hw/ehca/ehca_reqs.c|3 ++-
 drivers/infiniband/hw/ipath/ipath_cq.c|4 +++-
 drivers/infiniband/hw/ipath/ipath_verbs.h |3 ++-
 drivers/infiniband/hw/mthca/mthca_cq.c|6 --
 drivers/infiniband/hw/mthca/mthca_dev.h   |4 ++--
 include/rdma/ib_verbs.h   |5 +++--
 10 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/infiniband/core/uverbs_cmd.c 
b/drivers/infiniband/core/uverbs_cmd.c
index 743247e..5dd1de9 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -959,6 +959,7 @@ ssize_t ib_uverbs_req_notify_cq(struct i
int out_len)
 {
struct ib_uverbs_req_notify_cq cmd;
+   struct ib_udata   udata;
struct ib_cq  *cq;
 
if (copy_from_user(&cmd, buf, sizeof cmd))
@@ -968,8 +969,12 @@ ssize_t ib_uverbs_req_notify_cq(struct i
if (!cq)
return -EINVAL;
 
-   ib_req_notify_cq(cq, cmd.solicited_only ?
-IB_CQ_SOLICITED : IB_CQ_NEXT_COMP);
+   INIT_UDATA(&udata, buf + sizeof cmd, 0,
+  in_len - sizeof cmd, 0); 
+
+   cq->device->req_notify_cq(cq, cmd.solicited_only ?
+ IB_CQ_SOLICITED : IB_CQ_NEXT_COMP,
+ &udata);
 
put_cq_read(cq);
 
diff --git a/drivers/infiniband/hw/amso1100/c2.h 
b/drivers/infiniband/hw/amso1100/c2.h
index 1b17dcd..716f9dc 100644
--- a/drivers/infiniband/hw/amso1100/c2.h
+++ b/drivers/infiniband/hw/amso1100/c2.h
@@ -519,7 +519,7 @@ extern void c2_free_cq(struct c2_dev *c2
 extern void c2_cq_event(struct c2_dev *c2dev, u32 mq_index);
 extern void c2_cq_clean(struct c2_dev *c2dev, struct c2_qp *qp, u32 mq_index);
 extern int c2_poll_cq(struct ib_cq *ibcq, int num_entries, struct ib_wc 
*entry);
-extern int c2_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify);
+extern int c2_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify, struct 
ib_udata *udata);
 
 /* CM */
 extern int c2_llp_connect(struct iw_cm_id *cm_id,
diff --git a/drivers/infiniband/hw/amso1100/c2_cq.c 
b/drivers/infiniband/hw/amso1100/c2_cq.c
index 05c9154..7ce8bca 100644
--- a/drivers/infiniband/hw/amso1100/c2_cq.c
+++ b/drivers/infiniband/hw/amso1100/c2_cq.c
@@ -217,7 +217,8 @@ int c2_poll_cq(struct ib_cq *ibcq, int n
return npolled;
 }
 
-int c2_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify)
+int c2_arm_cq(struct ib_cq *ibcq, enum ib_cq_notify notify,
+ struct ib_udata *udata)
 {
struct c2_mq_shared __iomem *shared;
struct c2_cq *cq;
diff --git a/drivers/infiniband/hw/ehca/ehca_iverbs.h 
b/drivers/infiniband/hw/ehca/ehca_iverbs.h
index 3720e30..566b30c 100644
--- a/drivers/infiniband/hw/ehca/ehca_iverbs.h
+++ b/drivers/infiniband/hw/ehca/ehca_iverbs.h
@@ -135,7 +135,8 @@ int ehca_poll_cq(struct ib_cq *cq, int n
 
 int ehca_peek_cq(struct ib_cq *cq, int wc_cnt);
 
-int ehca_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify cq_notify);
+int ehca_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify cq_notify,
+  struct ib_udata *udata);
 
 struct ib_qp *ehca_create_qp(struct ib_pd *pd,
 struct ib_qp_init_attr *init_attr,
diff --git a/drivers/infiniband/hw/ehca/ehca_reqs.c 
b/drivers/infiniband/hw/ehca/ehca_reqs.c
index b46bda1..3ed6992 100644
--- a/drivers/infiniband/hw/ehca/ehca_reqs.c
+++ b/drivers/infiniband/hw/ehca/ehca_reqs.c
@@ -634,7 +634,8 @@ poll_cq_exit0:
return ret;
 }
 
-int ehca_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify cq_notify)
+int ehca_req_notify_cq(struct ib_cq *cq, enum ib_cq_notify cq_notify,
+  struct ib_udata *udata)
 {
struct ehca_cq *my_cq = container_of(cq, struct ehca_cq, ib_cq);
 
diff --git a/drivers/infiniband/hw/ipath/ipath_cq.c 
b/drivers/infiniband/hw/ipath/ipath_cq.c
index 87462e0..27ba4db 100644
--- a/drivers/infiniband/hw/ipath/ipath_cq.c
+++ b/drivers/infiniband/hw/ipath/ipath_cq.c
@@ -307,13 +307,15 @@ int ipath_destroy_cq(struct ib_cq *ibcq)
  * ipath_req_notify_cq - change the notification type for a completion queue
  * @ibcq: the completion queue
  * @notify: the type of notification to request
+ * @udata: user data 
  *
  * Returns 0 for success.
  *
  * This may be called from interrupt context.  Also called by
  * ib_req_notify_cq() in the generic verbs code.
  */
-int ipath_req_notify_cq(struct ib_cq *ibcq, enum ib_cq_notify notify)
+int ipath_req_notify_cq(struct ib_cq

[PATCH 00/13] Chelsio T3 RDMA Driver

[Steve Wise]

Roland / All:

The following series implements the Chelsio T3 iWARP/RDMA Driver to
be considered for inclusion in 2.6.20.  It depends on the Chelsio
T3 Ethernet Driver which is also under review now for 2.6.20
(http://marc.theaimsgroup.com/?l=linux-netdev&m=116363600816597&w=2).

The patches are against 2.6.19-rc5.

This patch series can also be pulled from:

http://www.opengridcomputing.com/downloads/iw_cxgb3_patches.tar.bz2

The Chelsio T3 Ethernet Driver patch can be pulled from:

http://service.chelsio.com/kernel.org/cxgb3.patch.bz2


Thanks,

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

Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

[Larry Finger]

Ray Lee wrote:

Michael Buesch wrote:

On Wednesday 15 November 2006 20:01, Ray Lee wrote:

Suggestions? Requests for  even more info?

Yeah, enable bcm43xx debugging.


Sigh, didn't even think to look for that. Okay, enabled and compiling a new
kernel. This will take a few days to trigger, if the pattern holds, so in the
meantime, any *other* thoughts?



Which chip and revision do you have? Send me your equivalent of the line "bcm43xx: Chip ID 0x4306, 
rev 0x2".


Thanks,

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 07/30] bcm43xx: Drain TX status before starting IRQs

[Chris Wright]

-stable review patch.  If anyone has any objections, please let us know.
--

From: Michael Buesch <[EMAIL PROTECTED]>

Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run. Those would immediately fire after enabling
IRQs and would lead to an oops in the DMA TXstatus handling code.

Cc: "John W. Linville" <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
 drivers/net/wireless/bcm43xx/bcm43xx_main.c |   18 ++
 1 file changed, 18 insertions(+)

--- linux-2.6.18.2.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.18.2/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1463,6 +1463,23 @@ static void handle_irq_transmit_status(s
}
 }
 
+static void drain_txstatus_queue(struct bcm43xx_private *bcm)
+{
+   u32 dummy;
+
+   if (bcm->current_core->rev < 5)
+   return;
+   /* Read all entries from the microcode TXstatus FIFO
+* and throw them away.
+*/
+   while (1) {
+   dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_0);
+   if (!dummy)
+   break;
+   dummy = bcm43xx_read32(bcm, BCM43xx_MMIO_XMITSTAT_1);
+   }
+}
+
 static void bcm43xx_generate_noise_sample(struct bcm43xx_private *bcm)
 {
bcm43xx_shm_write16(bcm, BCM43xx_SHM_SHARED, 0x408, 0x7F7F);
@@ -3517,6 +3534,7 @@ int bcm43xx_select_wireless_core(struct 
bcm43xx_macfilter_clear(bcm, BCM43xx_MACFILTER_ASSOC);
bcm43xx_macfilter_set(bcm, BCM43xx_MACFILTER_SELF, (u8 
*)(bcm->net_dev->dev_addr));
bcm43xx_security_init(bcm);
+   drain_txstatus_queue(bcm);
ieee80211softmac_start(bcm->net_dev);
 
/* Let's go! Be careful after enabling the IRQs.

--
-
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.19-rc5-mm2 -- bcm43xx busted (backing out the bcm43xx patches fixes it)

[John W. Linville]

On Wed, Nov 15, 2006 at 08:16:37PM -0600, Larry Finger wrote:

> NOTE to maintainers: This problem affects BOTH wireless-2.6 and 
> 2.6.19-rcX-mmY. At present, the
> "Move IV/ICV" patch has not been incorporated into 2.6.19-rcX and it is OK.

This patch is available in the 'upstream' branch pull request I posted
yesterday evening:

http://marc.theaimsgroup.com/?l=linux-netdev&m=116355611923558&w=2

Hth!

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: 2.6.19-rc5-mm2 -- bcm43xx busted (backing out the bcm43xx patches fixes it)

[Larry Finger]

Rafael J. Wysocki wrote:

On Wednesday, 15 November 2006 00:21, Miles Lane wrote:

Hello,

The last three MM kernels have fail to give me a working bcm43xx driver.
The odd thing is that dmesg output seems to indicate that the driver
is working okay.  NetworkManager doesn't see the driver, though.
"iwlist scan" fails to find any access points, too.  iwconfig shows
"Access Point: invalid".


I can confirm the symptoms, I see them too on my test boxes.


I tried backing out the following patches, and it fixes the problem:

drivers/net/wireless/bcm43xx/bcm43xx.h
drivers/net/wireless/bcm43xx/bcm43xx_main.c
drivers/net/wireless/bcm43xx/bcm43xx_power.c
drivers/net/wireless/bcm43xx/bcm43xx_wx.c
drivers/net/wireless/bcm43xx/bcm43xx_xmit.c 


The missing patch is shown below. This patch was entitled "[PATCH] bcm43xx: 
Readd dropped
assignment" and submitted to wireless-2.6 by Daniel Drake on 10/17/06, but it 
seems to have fallen
through the cracks. It is a fix to a patch entitled "[PATCH] ieee80211: Move 
IV/ICV stripping into
ieee80211_rx" also submitted by Daniel Drake on 9/26/2006.

NOTE to maintainers: This problem affects BOTH wireless-2.6 and 2.6.19-rcX-mmY. 
At present, the
"Move IV/ICV" patch has not been incorporated into 2.6.19-rcX and it is OK.

Larry


In the patch sent by Daniel Drake under the title "[PATCH] ieee80211: Move
IV/ICV stripping into ieee80211_rx", a needed line was accidentally removed.
As my current copy of wireless-2.6.git does not contain this line, I am
(re)submitting a patch to restore that line.

Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---

Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -543,6 +543,7 @@ int bcm43xx_rx(struct bcm43xx_private *b
break;
}

+   frame_ctl = le16_to_cpu(wlhdr->frame_ctl);
switch (WLAN_FC_GET_TYPE(frame_ctl)) {
case IEEE80211_FTYPE_MGMT:
ieee80211_rx_mgt(bcm->ieee, wlhdr, &stats);

-
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] cxgb3: Chelsio T3 1G/10G ethernet device driver

[Arnd Bergmann]

On Thursday 16 November 2006 01:11, divy wrote:
> This patch adds support for the latest Chelsio adapter, T3.
>
> Since some files are bigger than the 40kB advertized in the submit
> guidelines, a monolithic patch against 2.6.19-rc5 is posted at the
> following URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2
>
> Please advise on any other form you would like to see the code.

You should still attempt to post it as inline email for better review.
The hard limit on mails is 100kb right now, IIRC, so it should be
possible to split it up into smaller chunks for review.

> We wish this patch to be considered for inclusion in 2.6.20. This driver
> will be required by the Chelsio T3 RDMA driver which will be posted for
> review asap.

Two things I noticed on a very brief review:

- The driver is _huge_. Even if your hardware is terribly complicated,
  the fact that you need 600kb to drive it is a hint that you do
  something wrong. In particular, the header files contain hundreds
  of macros that are completely unused. You should get rid of them.

- You define a driver specific multiplexing ioctl method. This is
  something you really shouldn't do in a network driver, since the
  ioctl number will conflict with other drivers. In order to get
  the rest of your code merged, I'd suggest you split out the
  private ioctl handling into a separate patch that you don't submit
  for now, and then we can think of how to replace the interfaces
  with something better, e.g. new driver-independent calls like ioctl
  or ethtool or sysfs, or get rid of them if they turn out to be
  not required.

Arnd <><
-
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] cxgb3: Chelsio T3 1G/10G ethernet device driver

[Stephen Hemminger]

On Wed, 15 Nov 2006 16:11:36 -0800
divy <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> This patch adds support for the latest Chelsio adapter, T3.
> 
> Since some files are bigger than the 40kB advertized in the submit
> guidelines, a monolithic patch against 2.6.19-rc5 is posted at the
> following URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2
> 
> Please advise on any other form you would like to see the code.
> 
> We wish this patch to be considered for inclusion in 2.6.20. This driver
> will be required by the Chelsio T3 RDMA driver which will be posted for
> review asap.
> 
> 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


This took me an afternoon, so I don't see why Chelsio didn't do it.

Port of Chelsio's 2.2.0 version driver from:
http://service.chelsio.com/drivers/linux/t210/cxgb2toe-2.2.0.tar.gz

De-vendorized:
- removed all TCP Offload Engine support because those changes
  will not be accepted in mainline kernel.
- new files run through Lindent
- removed code that was '#ifdef' for older kernel versions
- fix for 2.6.19 irq
- replace usage of TSC with ktime
- remove /proc trace debug stuff
- remove dead code
- incorporate GSO, etc.
- get rid of FILE_IDENT() macro
- fix sparse warnings by adding __iomem and __user

Also, I kept as many of the filenames and device names the same since
it is really just an extension of existing driver.

I'm testing it now.

-- 
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] netdev do down on suspend and up on resume

[Stephen Hemminger]

This is a demo only. IMHO the network device code should take care of bringing
down network devices and restoring them on resume. Some distro's do this with 
scripts
and many devices do it themselves in the suspend code. But doing it in the main
netdevice code is best, and means that many network devices would need no 
special
suspend/resume code, since the default suspend for pci devices does a 
save/restore
state and power control.

It is compatiable with older devices (and distro's like Ubuntu) that do the same
thing already, because luckily calling dev_close on a down device does nothing, 
and
calling dev_open on an up device does nothing.

It is not possible to use the class interface (net_class) for a couple of 
reasons,
first the classes are called in registration order so the interesting ones like 
pci
have already suspended the device. Second, the class interface is based off 
hardware
not pseudo-devices like netdevice objects.



--- linux-2.6.19-rc5.orig/include/linux/netdevice.h 2006-11-15 
11:27:54.0 -0800
+++ linux-2.6.19-rc5/include/linux/netdevice.h  2006-11-15 11:40:50.0 
-0800
@@ -351,6 +351,7 @@
 
 
unsigned intflags;  /* interface flags (a la BSD)   */
+   unsigned intsave_flags; /* during suspend/resume */
unsigned short  gflags;
 unsigned short  priv_flags; /* Like 'flags' but invisible to 
userspace. */
unsigned short  padded; /* How much padding added by 
alloc_netdev() */
@@ -988,6 +989,14 @@
 extern voidnet_enable_timestamp(void);
 extern voidnet_disable_timestamp(void);
 
+#ifdef CONFIG_NET
+extern voidnetdev_suspend(void);
+extern voidnetdev_resume(void);
+#else
+#define netdev_suspend()   do { } while(0)
+#define netdev_resume()do { } while(0)
+#endif
+
 #ifdef CONFIG_PROC_FS
 extern void *dev_seq_start(struct seq_file *seq, loff_t *pos);
 extern void *dev_seq_next(struct seq_file *seq, void *v, loff_t *pos);
--- sky2.orig/kernel/power/main.c   2006-11-15 11:35:42.0 -0800
+++ sky2/kernel/power/main.c2006-11-15 11:37:24.0 -0800
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "power.h"
 
@@ -61,6 +62,8 @@
 
pm_prepare_console();
 
+   netdev_suspend();
+
error = disable_nonboot_cpus();
if (error)
goto Enable_cpu;
@@ -98,6 +101,7 @@
thaw_processes();
  Enable_cpu:
enable_nonboot_cpus();
+   netdev_resume();
pm_restore_console();
return error;
 }
@@ -139,6 +143,7 @@
if (pm_ops && pm_ops->finish)
pm_ops->finish(state);
pm_restore_console();
+   netdev_resume();
 }
 
 
--- sky2.orig/net/core/dev.c2006-11-15 11:28:00.0 -0800
+++ sky2/net/core/dev.c 2006-11-15 11:33:53.0 -0800
@@ -949,6 +949,45 @@
return 0;
 }
 
+#ifdef CONFIG_PM
+/*
+ * netdev_suspend - close all network devices
+ * During suspend, bring down all network interfaces and save state.
+ */
+void netdev_suspend(void)
+{
+   struct net_device *d;
+
+   rtnl_lock();
+   for (d = dev_base; d; d = d->next) {
+   d->save_flags = d->flags;
+   dev_close(d);
+   }
+   rtnl_unlock();
+}
+
+
+/*
+ * netdev_resume - restore all network devices
+ * During resume, bring up all network interfaces that were up before 
suspend.
+ */
+void netdev_resume(void)
+{
+   struct net_device *d;
+
+   rtnl_lock();
+   for (d = dev_base; d; d = d->next)
+   if (d->save_flags & IFF_UP) {
+   err = dev_open(d);
+   if (err) {
+   printk(KERN_INFO "%s: failed to come back up 
(%d)\n",
+  d->name, err);
+   }
+   }
+
+   rtnl_unlock();
+}
+#endif
 
 /*
  * Device change register/unregister. These are not inline or static
-
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] cxgb3: Chelsio T3 1G/10G ethernet device driver

[divy]

Hi,

This patch adds support for the latest Chelsio adapter, T3.

Since some files are bigger than the 40kB advertized in the submit
guidelines, a monolithic patch against 2.6.19-rc5 is posted at the
following URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2

Please advise on any other form you would like to see the code.

We wish this patch to be considered for inclusion in 2.6.20. This driver
will be required by the Chelsio T3 RDMA driver which will be posted for
review asap.

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

Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assessar5k (enabling free Atheros HAL)

[David Kimdon]

On Wed, Nov 15, 2006 at 02:39:01PM -0500, Pavel Roskin wrote:
> On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote:
> > On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
> 
> I said it before, and it's worth repeating.  Dissolving HAL in the
> sources is easy.  It's just a matter of moving functions around without
> serious chances of breaking anything as long as the source compiles.
> The whole "HAL-based architecture" can be reshuffled and eliminated by
> one person in a few days.
> 
> Making things work properly takes years.  That's what MadWifi has been
> working on for a long time, using contributions and bug reports from
> scores of users and developers.
> 
> Rejecting MadWifi because it's HAL based is like throwing away a diamond
> ring because it's too narrow.

I completely agree.  The approach we are taking with dadwifi[1] is to
use much of the existing code from madwifi and port it to the d80211
stack.  Today dadwifi works in monitor, sta and ap mode.

-David


[1] http://madwifi.org/wiki/DadWifi

> 
> -- 
> Regards,
> Pavel Roskin
> 
> 
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Madwifi-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/madwifi-devel
-
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/3] add numa node information to struct device

[Andrew Morton]

On Wed, 15 Nov 2006 18:37:01 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:

> +#ifdef CONFIG_NUMA
> +#define dev_to_node(dev) ((dev)->numa_node)
> +#define set_dev_node(dev, node)  ((dev)->numa_node = node)
> +#else
> +#define dev_to_node(dev) (-1)
> +#define set_dev_node(dev, node)  do { } while (0)
> +#endif

minor point: using inlines here would give typechecking, prevent possible
unused-var warnings, etc.

Maybe there was a reason for not doing that.



No doubt I'll find out ;)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] node-aware skb allocations

[Andrew Morton]

On Wed, 15 Nov 2006 18:36:43 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:

> This is the final version of the node-aware skb allocations,
> implementing davem's suggestion of storing the numa node in
> struct device.  I'd love to get this into 2.6.20 now that I
> don't hear negative comments about it anymre, but I wonder
> how.  The first patch toches mm/slab.c, the second struct device
> and assorted files and only the last one is actually in the networking
> code.  Should Dave push all this through net-2.6.20 or should we
> get it in purely through -mm?

If Dave wants to nod at it then I can merge all of it, else I can hand
patch 3/3 over to Dave once its prerequisites are in mainline.

-
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] myri10ge: use physical pages for skb allocation

[Brice Goglin]

Hi Jeff,

It looks like you didn't apply this patch to #upstream for 2.6.20 so far. We 
would really like to get ith in 2.6.20 (we already missed 2.6.19 by a couple 
days :)). But, I guess we need some testing in -mm first, so...

thanks,
Brice





Brice Goglin wrote:
> Physical pages are used instead of 16kB contiguous buffers for the
> skb frags. And we also put as much fragments as possible in any page
> so that we do not have to allocate a page for every fragments.
>
> Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
> Signed-off-by: Andrew J. Gallatin <[EMAIL PROTECTED]>
> ---
>  drivers/net/myri10ge/myri10ge.c |  499 
> 
>  1 file changed, 254 insertions(+), 245 deletions(-)
>   

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sysctl syscall

[Jan Engelhardt]

On Nov 16 2006 00:03, Hasso Tepper wrote:
>
>Compiling the program which uses a lot "sysctl" syscalls, gives me this 
>warning on Debian unstable:
>
>"warning: the `sysctl' syscall has been removed from 2.6.18+ kernels, 
>direct access to `/proc/sys' should be used instead."
>
>Is it true?

Well it was unobsoleted in 2.6.19 if I followed the list correctly.

>And what can be used as alternative which would work with both 
>2.4 and 2.6 kernels
>and would work with capabilities (sys/capability.h)?
>Accessing `/proc/sys' directly isn't such alternative as it doesn't work 
>with capabilities.



-`J'
-- 
-
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

Sysctl syscall

[Hasso Tepper]

Compiling the program which uses a lot "sysctl" syscalls, gives me this 
warning on Debian unstable:

"warning: the `sysctl' syscall has been removed from 2.6.18+ kernels, 
direct access to `/proc/sys' should be used instead."

Is it true? And what can be used as alternative which would work with both 
2.4 and 2.6 kernels and would work with capabilities (sys/capability.h)?
Accessing `/proc/sys' directly isn't such alternative as it doesn't work 
with capabilities.


regards,

-- 
Hasso Tepper
Elion Enterprises Ltd. [AS3249]
Data Communication Network Administrator
-
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

Sysctl syscall

[Hasso Tepper]

Compiling the program which uses a lot "sysctl" syscalls, gives me this 
warning on Debian unstable:

"warning: the `sysctl' syscall has been removed from 2.6.18+ kernels, 
direct access to `/proc/sys' should be used instead."

Is it true? And what can be used as alternative which would work with both 
2.4 and 2.6 kernels and would work with capabilities (sys/capability.h)?
Accessing `/proc/sys' directly isn't such alternative as it doesn't work 
with capabilities.


regards,

-- 
Hasso Tepper
Elion Enterprises Ltd. [AS3249]
Data Communication Network Administrator
-
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: Setup of testing lab and work on development

[Johannes Berg]

On Thu, 2006-11-16 at 02:34 +0530, Udayan Singh wrote:

> ok. you are referring to bcm43xx , etc

right, all of those drivers use d80211.

> lets say we have development happening in d80211 driver. now if i want
> to participate in the development of the (d80211), i can do it in a
> much better manner if i am trying out modificaitons on my own on the
> drivers that are using d80211 (my feeling) 

I doubt you'll get far without ever testing your code changes. :)

> e.g. bcm43xx, etc. Hence i
> would like to setup a test environment where i can make modifications
> in code (of d80211 or related driver) and test it

You'll need one of the cards that is supported by a d80211 driver. I've
used bcm43xx and rt2500usb so far.

> same - "participate in development on d80211"

Well, check http://wireless.sipsolutions.net for things we still have to
do... and then send patches :)

Or do something else you're interested in and send patches.

johannes


signature.asc
Description: This is a digitally signed message part

Re: Setup of testing lab and work on development

[Udayan Singh]

On 11/15/06, Johannes Berg <[EMAIL PROTECTED]> wrote:

On Wed, 2006-11-15 at 22:27 +0530, Udayan Singh wrote:

> 1. if i understood correctly.. The discussion thread : "wireless notes
> / pre d80211 merge" discussion applies to the directory "net/d80211/"
> from git:..

Right. I CCed you because you seemed interested in d80211.



Thanks.. Johannes.. :)


> 2. Test environment to setup for d80211 would be like this :
>
> Laptop (Centrino - with ipw2200 or would it be some other) <> PC
> acting as Access Point (with Wireless modem)

no, ipw2200 doesn't do d80211. check drivers/net/wireless/d80211/



ok. you are referring to bcm43xx , etc


> Any other that you would suggest that would be a more reasonable test
> environment setup ?
>
> Also if you have suggestions which company of appliances i should go for..

What do you want a test environment for? That's the key issue. I have a
bunch of wireless hardware and an access point...



lets say we have development happening in d80211 driver. now if i want
to participate in the development of the (d80211), i can do it in a
much better manner if i am trying out modificaitons on my own on the
drivers that are using d80211 (my feeling) e.g. bcm43xx, etc. Hence i
would like to setup a test environment where i can make modifications
in code (of d80211 or related driver) and test it


> Few points that for clarification.
> 1. I intend to do the same so that I can also check if I make any
> changes how are they reflected. I hope my purpose would be solved with
> above setup.

Not sure what you mean? Do "the same" what?


same - "participate in development on d80211"


> 2. How frequently would there be changes required in h/w here ?

Umm, never?

You fail to state what you actually want to do...



sorry for that, will surely try to give a complete picture in future
(tried that today again - hope its ok..).



johannes





thanks..

Udayan
Tata Consultancy Services
-
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: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)

[Michael Buesch]

On Wednesday 15 November 2006 20:39, Pavel Roskin wrote:
> Hello!
> 
> On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote:
> > On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
> > 
> > > Now that it seems to be ok to use these openbsd sources, should I port
> > > them to my driver framework?
> > > I looked over the ar5k code and, well, I don't like it. ;)
> > > I don't really like having a HAL. I'd rather prefer a "real" driver
> > > without that HAL obfuscation.
> > 
> > I don't think anyone likes the HAL-based architecture.  I don't think
> > we will accept a HAL-based driver into the upstream kernel.
> 
> I said it before, and it's worth repeating.  Dissolving HAL in the
> sources is easy.  It's just a matter of moving functions around without
> serious chances of breaking anything as long as the source compiles.
> The whole "HAL-based architecture" can be reshuffled and eliminated by
> one person in a few days.

I'll look at it tomorrow.
Probably best to merge this stuff into the tree somehow to get it
working and clean it up afterwards. Shouldn't be too hard to merge.

> Making things work properly takes years.  That's what MadWifi has been
> working on for a long time, using contributions and bug reports from
> scores of users and developers.
> 
> Rejecting MadWifi because it's HAL based is like throwing away a diamond
> ring because it's too narrow.

Well, it never worked for me. But I gave up trying about
half a year ago. But maybe it's just stupid me. ;)

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)

[Michael Buesch]

On Wednesday 15 November 2006 20:21, John W. Linville wrote:
> On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
> 
> > Now that it seems to be ok to use these openbsd sources, should I port
> > them to my driver framework?
> > I looked over the ar5k code and, well, I don't like it. ;)
> > I don't really like having a HAL. I'd rather prefer a "real" driver
> > without that HAL obfuscation.
> 
> I don't think anyone likes the HAL-based architecture.  I don't think
> we will accept a HAL-based driver into the upstream kernel.

Yeah, wanted to hear that. ;)

> The point is that the ar5k is now safe to be used as a reference and
> source of information (and code, as appropriate) without copyright FUD.
> Distilling that information into a proper Linux driver is work that
> remains to be done.

Yeah, ok. I'll look what I can do. First I'll have to read the code.
and understand it. DMA stuff seems to be really obfuscated though
dozens of callbacks, heh. :)

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)

[Pavel Roskin]

Hello!

On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote:
> On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
> 
> > Now that it seems to be ok to use these openbsd sources, should I port
> > them to my driver framework?
> > I looked over the ar5k code and, well, I don't like it. ;)
> > I don't really like having a HAL. I'd rather prefer a "real" driver
> > without that HAL obfuscation.
> 
> I don't think anyone likes the HAL-based architecture.  I don't think
> we will accept a HAL-based driver into the upstream kernel.

I said it before, and it's worth repeating.  Dissolving HAL in the
sources is easy.  It's just a matter of moving functions around without
serious chances of breaking anything as long as the source compiles.
The whole "HAL-based architecture" can be reshuffled and eliminated by
one person in a few days.

Making things work properly takes years.  That's what MadWifi has been
working on for a long time, using contributions and bug reports from
scores of users and developers.

Rejecting MadWifi because it's HAL based is like throwing away a diamond
ring because it's too narrow.

-- 
Regards,
Pavel Roskin


-
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: ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)

[Arjan van de Ven]

On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote:
> On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
> 
> > Now that it seems to be ok to use these openbsd sources, should I port
> > them to my driver framework?
> > I looked over the ar5k code and, well, I don't like it. ;)
> > I don't really like having a HAL. I'd rather prefer a "real" driver
> > without that HAL obfuscation.
> 
> I don't think anyone likes the HAL-based architecture.  I don't think
> we will accept a HAL-based driver into the upstream kernel.
> 
> The point is that the ar5k is now safe to be used as a reference and
> source of information (and code, as appropriate) without copyright FUD.
> Distilling that information into a proper Linux driver is work that
> remains to be done.

there have been several efforts on this before; is it worth revitalizing
one of them?

Also I suspect that if you merge a provisional driver early, lots of
folks will switch to it and start beating on it and fixing the style etc
issues...


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
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: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)

[Ben Greear]

Michael Buesch wrote:


Yeah, ok. I'll look what I can do. First I'll have to read the code.
and understand it. DMA stuff seems to be really obfuscated though
dozens of callbacks, heh. :)


I'd certainly like to see solid Atheros chipset support in mainline.
If you need any hardware or other resources to help with this effort,
let me know.

Thanks,
Ben

--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc  http://www.candelatech.com

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

[Ray Lee]

Michael Buesch wrote:
> On Wednesday 15 November 2006 20:01, Ray Lee wrote:
>> Suggestions? Requests for  even more info?
> 
> Yeah, enable bcm43xx debugging.

Sigh, didn't even think to look for that. Okay, enabled and compiling a new
kernel. This will take a few days to trigger, if the pattern holds, so in the
meantime, any *other* thoughts?
-
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: ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)

[John W. Linville]

On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:

> Now that it seems to be ok to use these openbsd sources, should I port
> them to my driver framework?
> I looked over the ar5k code and, well, I don't like it. ;)
> I don't really like having a HAL. I'd rather prefer a "real" driver
> without that HAL obfuscation.

I don't think anyone likes the HAL-based architecture.  I don't think
we will accept a HAL-based driver into the upstream kernel.

The point is that the ar5k is now safe to be used as a reference and
source of information (and code, as appropriate) without copyright FUD.
Distilling that information into a proper Linux driver is work that
remains to be done.

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: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

[Michael Buesch]

On Wednesday 15 November 2006 20:01, Ray Lee wrote:
> Suggestions? Requests for  even more info?

Yeah, enable bcm43xx debugging.

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

[Ray Lee]

Hey all,

I ran 2.6.19-rc3 for almost two weeks or so with no difficulties (none related
to the bcm43xx driver, at least). However, Andrew asked me to double check the
latest release to see if my problem report against 2.6.18 (hard locks) was
fixed. Good news is that it still is fixed. Bad news is that 2.6.19-rc5 is
worse than rc3 in other ways.

I've come back to my laptop being mostly dead after hours of it being off on
its own (twice now). Mostly dead meaning the keyboard is nearly
non-responsive, but the mouse works great (I'm in X, of course). I say 'nearly
dead' as sysrq-t,b works, so I'm sorta stumped there. (x-session seems to use
netlink, so perhaps that's the connection? ctrl-alt-f[1-7] don't do anything,
however.)

It seems to be a locking problem, though lockdep isn't catching it. I'll let
you guys decide though.

Regardless, here's what's I can see. My logs start filling with:

$ grep 'NETDEV WATCHDOG:' /var/log/messages |  cut -d '[' -f 2- | head
50025.388173] NETDEV WATCHDOG: eth1: transmit timed out
50029.019574] NETDEV WATCHDOG: eth1: transmit timed out
50030.835313] NETDEV WATCHDOG: eth1: transmit timed out
50032.651049] NETDEV WATCHDOG: eth1: transmit timed out
50034.466785] NETDEV WATCHDOG: eth1: transmit timed out
50036.282523] NETDEV WATCHDOG: eth1: transmit timed out
50038.098237] NETDEV WATCHDOG: eth1: transmit timed out
50039.913974] NETDEV WATCHDOG: eth1: transmit timed out
50041.729709] NETDEV WATCHDOG: eth1: transmit timed out
50043.545447] NETDEV WATCHDOG: eth1: transmit timed out
(...1249 of these, so it doesn't fix itself.)

and then the system becomes pretty worthless. (Full /var/log/messages with
sysrq-t at: http://madrabbit.org/~ray/messages.gz ).

Interesting bits of that:

$ grep -B5 -A10 'Nov 13 01:5.*mutex' /var/log/messages | cut -d ']' -f2-
 DWARF2 unwinder stuck at child_rip+0xa/0x12

 Leftover inexact backtrace:

  [restore_args+0/48] restore_args+0x0/0x30
  [mutex_lock+9/16] mutex_lock+0x9/0x10
  [kthread+0/272] kthread+0x0/0x110
  [child_rip+0/18] child_rip+0x0/0x12

 khelper   S 810037fbe318 0 5  1 6 4 (L-TLB)
  810037907e60 0046 810037907e70 810037fbe140
  81001095f140 3b5d 810001e3e668 0286
  810037907e40 8026bbb2 810037907e70 810001e3e600
 Call Trace:
  [worker_thread+236/352] worker_thread+0xec/0x160
  [kthread+211/272] kthread+0xd3/0x110
--
 DWARF2 unwinder stuck at child_rip+0xa/0x12

 Leftover inexact backtrace:

  [restore_args+0/48] restore_args+0x0/0x30
  [mutex_lock+9/16] mutex_lock+0x9/0x10
  [kthread+0/272] kthread+0x0/0x110
  [child_rip+0/18] child_rip+0x0/0x12

 kthread   S 810037fad218 0 6  1252129 5 (L-TLB)
  810037f01e60 0046 810037f01e70 810037fad040
  81002b3df140 062b 810001e3e468 0286
  810037f01e40 8026bbb2 810037f01e70 810001e3e400
 Call Trace:
  [worker_thread+236/352] worker_thread+0xec/0x160
  [kthread+211/272] kthread+0xd3/0x110
--
 DWARF2 unwinder stuck at child_rip+0xa/0x12

 Leftover inexact backtrace:

  [restore_args+0/48] restore_args+0x0/0x30
  [mutex_lock+9/16] mutex_lock+0x9/0x10
  [kthread+0/272] kthread+0x0/0x110
  [child_rip+0/18] child_rip+0x0/0x12

 kblockd/0 S 810037989318 025  626   (L-TLB)
  81003798fe60 0046 81003798fe70 810037989140
  8100379a5100 078b 810037fa2468 0286
  81003798fe40 8026bbb2 81003798fe70 810037fa2400
 Call Trace:
  [worker_thread+236/352] worker_thread+0xec/0x160
  [kthread+211/272] kthread+0xd3/0x110
--
 NetworkManage D 810037943258 0  4833  1  4853  4809 (NOTLB)
  81002bfefbe8 0046 81002bfefb98 810037943080
  81002e6d2100 000122a6 8062ce80 0046
  0246 810037943080 81002e47b3f0 81002e47b3a0
 Call Trace:
  [__mutex_lock_slowpath+344/624] __mutex_lock_slowpath+0x158/0x270
  [mutex_lock+9/16] mutex_lock+0x9/0x10
  [_end+126343345/2126632680] :bcm43xx:bcm43xx_wx_get_mode+0x29/0x60
  [ioctl_standard_call+139/944] ioctl_standard_call+0x8b/0x3b0
  [wireless_process_ioctl+260/976] wireless_process_ioctl+0x104/0x3d0
  [dev_ioctl+854/944] dev_ioctl+0x356/0x3b0
  [sock_ioctl+576/624] sock_ioctl+0x240/0x270
  [do_ioctl+49/160] do_ioctl+0x31/0xa0
  [vfs_ioctl+683/720] vfs_ioctl+0x2ab/0x2d0
  [sys_ioctl+106/160] sys_ioctl+0x6a/0xa0
  [system_call+126/131] system_call+0x7e/0x83
 DWARF2 unwinder stuck at system_call+0x7e/0x83
--
 x-session-man D 81002ef02298 0  5625   4565  5672  4586 (NOTLB)
  810028a1fad8 0046 8062c500 81002ef020c0
  8100249a6040 8c5d  0046
  0246 81002ef020c0 805505b0 80550560
 Call Trace:
  [__mutex_lock_slowpath+344/624] __mutex_lock_slowpath+0x158/

Re: wireless notes / pre d80211 merge

[Jeff Garzik]

Simon Barber wrote:

I disagree that the master device is a hack - I also disagree that we
should use 802.11 format frames anywhere but internally inside the
802.11 stack. The 802.11 specification does not use 802.11 format frames
to communicate with the upper layers - it uses almost exactly the same
interface as 802.3 ethernet does. This is a 2 address interface. I


The 802.11 specification doesn't communicate with any layer :)  The 
Linux kernel code in question does that.


In Linux it is generally bad form to emulate something (802.3 ethernet, 
in this case).  Overhead increases, performance decreases, and there are 
inevitably emulation bugs.


802.11 /is not ethernet/, and you are already breaking assumptions by 
pretending that it is.




It is normal to have a single interface to represent the physical
hardware network interface. This is exactly the pattern that many other
physical network devices use. Things like sniffing should go on on this
physical interface - and the changes that johannes proposes are exactly
the right things to enable this.


Sure... when it behaves like a normal interface.  Stuff like "TX goes 
through the interface, but not RX" is definitely /not/ normal.


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: ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)

[Michael Buesch]

On Wednesday 15 November 2006 04:10, John W. Linville wrote:
> It is my pleasure to announce that the SFLC [1] has assisted the ar5k
> developers in evaluating the development history of Reyk Floeter's
> OpenBSD reverse-engineered Atheros HAL, ar5k [2].  SFLC's assessment
> leads to the conclusion that free software developers should not be
> worried about using/extending ar5k or porting ar5k to other platforms.
> 
> In the past there were serious questions raised and even dire warnings
> made about ar5k's copyright status.  The purpose of this statement
> is to refute those claims and to publicly clarify ar5k's status
> to developers.
> 
> SFLC has made independent inquiries with the OpenBSD team regarding the
> development history of ar5k source.  The responses received provide
> a reasonable basis for SFLC to believe that the OpenBSD developers
> who worked on ar5k did not misappropriate code, and that the ar5k
> implementation is OpenBSD's original copyrighted work.
> 
> This announcement should serve to remove the cloud which has prevented
> progress towards an in-kernel driver for Atheros hardware.  This should
> be of particular interest to those involved with the DadWifi project [3].
> 
> I'd like to take this opportunity to thank the folks at the SFLC for
> their hard work, and I'd also like to personally thank Luis Rodriguez
> for the role he played in coordinating contact between the SFLC and
> the community at large.
> 
> Thanks!
> 
> John
> 
> [1] http://www.softwarefreedom.org/
> [2] http://team.vantronix.net/ar5k/
> [3] http://marc.theaimsgroup.com/?l=linux-netdev&m=116113064513921&w=2

So, who is finally going to _DO_ the work?
Some of you know that I started an atheros driver at
http://bu3sch.de/ath/atheros.git/
It's not really a driver, yet, as nobody got to continue on the specification,
so I was stuck.

Now that it seems to be ok to use these openbsd sources, should I port
them to my driver framework?
I looked over the ar5k code and, well, I don't like it. ;)
I don't really like having a HAL. I'd rather prefer a "real" driver
without that HAL obfuscation.

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless notes / pre d80211 merge

[Jeff Garzik]

Jiri Benc wrote:

On Tue, 14 Nov 2006 18:10:50 -0800, Simon Barber wrote:

I disagree that the master device is a hack


It's a clever hack but still a hack. The Linux network interfaces
wasn't designed for the sort of things we do with master interface.
Actually, the networking core doesn't support the concept of "wiphys"
at all. Yes, Jouni found a really clever way around this. But the most
correct solution is different.


Agreed.

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

[PATCH, RFT]: Fix bcm43xx-d80211 hwcrypto (was Re: bcm43xx-d80211 broadcast reception with WPA)

[Michael Buesch]

Please test if this fixes hwcrypto.
Note that we will require v4 firmware with this patch.
I will remove v3 firmware support, because it's _really_
a huge pain to support both firmware versions.
If someone wants to have v3 support, please fork my tree.
Or alternatively simply install v4 firmware, which is a lot
easier. ;)

Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h 
2006-11-14 16:03:00.0 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h  2006-11-14 
18:34:14.0 +0100
@@ -620,7 +620,6 @@ struct bcm43xx_stats {
 
 struct bcm43xx_key {
u8 enabled;
-   u8 used;
u8 algorithm;
u8 address[6];
 };
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-11-14 16:03:00.0 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 
2006-11-15 18:58:51.0 +0100
@@ -874,11 +874,12 @@ static void keymac_write(struct bcm43xx_
 {
u32 addrtmp[2];
 
+   assert(index >= 4 + 4);
+   memcpy(bcm->key[index].address, addr, 6);
/* We have two default TX keys and two default RX keys.
 * Physical mac 0 is mapped to physical key 8.
 * So we must adjust the index here.
 */
-   assert(index >= 4 + 4);
index -= 8;
 
addrtmp[0] = addr[0];
@@ -912,97 +913,88 @@ static void keymac_write(struct bcm43xx_
}
 }
 
-static int key_write_common(struct bcm43xx_private *bcm,
-   u8 index, u8 algorithm,
-   struct ieee80211_key_conf *keyconf,
-   const u8 *mac_addr)
+static void do_key_write(struct bcm43xx_private *bcm,
+u8 index, u8 algorithm,
+const u8 *key, size_t key_len,
+const u8 *mac_addr)
 {
u8 buf[BCM43xx_SEC_KEYSIZE];
 
-   /* The "index" passed to this function is the
-* absolute key table index.
-*/
-
-   if ((index >= bcm->max_nr_keys) ||
-   (keyconf && (keyconf->keylen > BCM43xx_SEC_KEYSIZE)))
-   return -EINVAL;
+   assert(index < bcm->max_nr_keys);
+   assert(key_len <= BCM43xx_SEC_KEYSIZE);
 
memset(buf, 0, sizeof(buf));
-   if (mac_addr)
+   if (index >= 8)
keymac_write(bcm, index, buf); /* First zero out mac. */
-   if (keyconf)
-   memcpy(buf, keyconf->key, keyconf->keylen);
+   memcpy(buf, key, key_len);
key_write(bcm, index, algorithm, buf);
-   if (mac_addr)
+   if (index >= 8)
keymac_write(bcm, index, mac_addr);
-   bcm->key[index].algorithm = algorithm;
-   bcm->key[index].used = 1;
-   bcm->key[index].enabled = 1;
-   if (mac_addr)
-   memcpy(bcm->key[index].address, mac_addr, 6);
-   else
-   memset(bcm->key[index].address, 0, 6);
 
-   return 0;
+   bcm->key[index].algorithm = algorithm;
 }
 
-static int bcm43xx_default_key_write(struct bcm43xx_private *bcm,
-u8 index, u8 algorithm,
-struct ieee80211_key_conf *key)
+static int bcm43xx_key_write(struct bcm43xx_private *bcm,
+int index, u8 algorithm,
+const u8 *key, size_t key_len,
+const u8 *mac_addr,
+struct ieee80211_key_conf *keyconf)
 {
-   int err;
+   int i;
 
-   if (index > 3)
+   if (key_len > BCM43xx_SEC_KEYSIZE)
return -EINVAL;
+   if (index < 0) {
+   /* Per station key with associated MAC address.
+* Look if it already exists, if yes update, otherwise
+* allocate a new key.
+*/
+   for (i = 8; i < bcm->max_nr_keys; i++) {
+   if (compare_ether_addr(bcm->key[i].address, mac_addr) 
== 0) {
+   /* found existing */
+   index = i;
+   break;
+   }
+   }
+   if (index < 0) {
+   for (i = 8; i < bcm->max_nr_keys; i++) {
+   if (!bcm->key[i].enabled) {
+   /* found empty */
+   index = i;
+   break;
+   }
+   }
+   }
+   if (index < 0) {
+   dprintk(KERN_ERR PFX "Out of hw key memory\n");
+   return -ENOBUFS;
+   }
+   } else
+ 

[PATCH] Adapt ucc_geth driver to use new of_platform_device support

[Kim Phillips]

Include of_platform header, and use
new of_[un]register_platform_driver() fns.

Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---

please consider for 2.6.20

 drivers/net/ucc_geth.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index b378880..1f05511 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -30,7 +30,7 @@ #include 
 #include 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -4301,12 +4301,12 @@ static int __init ucc_geth_init(void)
memcpy(&(ugeth_info[i]), &ugeth_primary_info,
   sizeof(ugeth_primary_info));
 
-   return of_register_driver(&ucc_geth_driver);
+   return of_register_platform_driver(&ucc_geth_driver);
 }
 
 static void __exit ucc_geth_exit(void)
 {
-   of_unregister_driver(&ucc_geth_driver);
+   of_unregister_platform_driver(&ucc_geth_driver);
 }
 
 module_init(ucc_geth_init);
-- 
1.4.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

Re: Setup of testing lab and work on development

[Johannes Berg]

On Wed, 2006-11-15 at 22:27 +0530, Udayan Singh wrote:

> 1. if i understood correctly.. The discussion thread : "wireless notes
> / pre d80211 merge" discussion applies to the directory "net/d80211/"
> from git:..

Right. I CCed you because you seemed interested in d80211.

> 2. Test environment to setup for d80211 would be like this :
> 
> Laptop (Centrino - with ipw2200 or would it be some other) <> PC
> acting as Access Point (with Wireless modem)

no, ipw2200 doesn't do d80211. check drivers/net/wireless/d80211/

> Any other that you would suggest that would be a more reasonable test
> environment setup ?
> 
> Also if you have suggestions which company of appliances i should go for..

What do you want a test environment for? That's the key issue. I have a
bunch of wireless hardware and an access point...

> Few points that for clarification.
> 1. I intend to do the same so that I can also check if I make any
> changes how are they reflected. I hope my purpose would be solved with
> above setup.

Not sure what you mean? Do "the same" what?

> 2. How frequently would there be changes required in h/w here ?

Umm, never?

You fail to state what you actually want to do...

johannes


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] fix up sysctl_tcp_mem initialization

[John Heffner]

David Miller wrote:
However, I wonder if we want to set this differently than the way this 
patch does it.  Depending on how far off the memory size is from a power 
of two (exactly equal to a power of two is the worst case), and if total 
memory <128M, it can be substantially less than 3/4.


Longer term, yes, probably a better way exists.

So you concern is that when we round to a power of 2 like we do
now, we often mis-shoot?


I'm not that concerned about it, but basically yes, there are big (x2) 
jumps on power-of-two memory size boundaries.  There's also a bigger 
(x8) discontinuity at 128k pages.  It could be smoother.


  -John
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] qla3xxx: Add support for Qlogic ISP4032 chip.

[Ron Mercer]

borked again.  Patch applied cleanly when I mailed it to myself, but not from 
list.  Third
try all will be corrected.

> >  oops, that patch is borked (line-wrapped). will resend ASAP.
> > 
> > Ron Mercer.
> 
-
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/3] node-aware skb allocation

[Christoph Hellwig]

Node-aware allocation of skbs for the receive path.

Details:

  - __alloc_skb gets a new node argument and cals the node-aware
slab functions with it.
  - netdev_alloc_skb passed the node number it gets from dev_to_node
to it, everyone else passes -1 (any node)


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/include/linux/skbuff.h
===
--- linux-2.6.orig/include/linux/skbuff.h   2006-11-02 12:47:50.0 
+0100
+++ linux-2.6/include/linux/skbuff.h2006-11-02 12:48:22.0 +0100
@@ -331,17 +331,17 @@
 extern void kfree_skb(struct sk_buff *skb);
 extern void   __kfree_skb(struct sk_buff *skb);
 extern struct sk_buff *__alloc_skb(unsigned int size,
-  gfp_t priority, int fclone);
+  gfp_t priority, int fclone, int node);
 static inline struct sk_buff *alloc_skb(unsigned int size,
gfp_t priority)
 {
-   return __alloc_skb(size, priority, 0);
+   return __alloc_skb(size, priority, 0, -1);
 }
 
 static inline struct sk_buff *alloc_skb_fclone(unsigned int size,
   gfp_t priority)
 {
-   return __alloc_skb(size, priority, 1);
+   return __alloc_skb(size, priority, 1, -1);
 }
 
 extern struct sk_buff *alloc_skb_from_cache(kmem_cache_t *cp,
Index: linux-2.6/net/core/skbuff.c
===
--- linux-2.6.orig/net/core/skbuff.c2006-11-02 12:47:50.0 +0100
+++ linux-2.6/net/core/skbuff.c 2006-11-02 12:48:22.0 +0100
@@ -131,6 +131,7 @@
  * @gfp_mask: allocation mask
  * @fclone: allocate from fclone cache instead of head cache
  * and allocate a cloned (child) skb
+ * @node: numa node to allocate memory on
  *
  * Allocate a new &sk_buff. The returned buffer has no headroom and a
  * tail room of size bytes. The object has a reference count of one.
@@ -140,7 +141,7 @@
  * %GFP_ATOMIC.
  */
 struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
-   int fclone)
+   int fclone, int node)
 {
kmem_cache_t *cache;
struct skb_shared_info *shinfo;
@@ -150,14 +151,14 @@
cache = fclone ? skbuff_fclone_cache : skbuff_head_cache;
 
/* Get the HEAD */
-   skb = kmem_cache_alloc(cache, gfp_mask & ~__GFP_DMA);
+   skb = kmem_cache_alloc_node(cache, gfp_mask & ~__GFP_DMA, node);
if (!skb)
goto out;
 
/* Get the DATA. Size must match skb_add_mtu(). */
size = SKB_DATA_ALIGN(size);
-   data = kmalloc_track_caller(size + sizeof(struct skb_shared_info),
-   gfp_mask);
+   data = kmalloc_node_track_caller(size + sizeof(struct skb_shared_info),
+   gfp_mask, node);
if (!data)
goto nodata;
 
@@ -266,9 +267,10 @@
 struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int length, gfp_t gfp_mask)
 {
+   int node = dev->class_dev.dev ? dev_to_node(dev->class_dev.dev) : -1;
struct sk_buff *skb;
 
-   skb = alloc_skb(length + NET_SKB_PAD, gfp_mask);
+   skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask, 0, node);
if (likely(skb)) {
skb_reserve(skb, NET_SKB_PAD);
skb->dev = 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/3] node-aware skb allocations

[Christoph Hellwig]

This is the final version of the node-aware skb allocations,
implementing davem's suggestion of storing the numa node in
struct device.  I'd love to get this into 2.6.20 now that I
don't hear negative comments about it anymre, but I wonder
how.  The first patch toches mm/slab.c, the second struct device
and assorted files and only the last one is actually in the networking
code.  Should Dave push all this through net-2.6.20 or should we
get it in purely through -mm?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] add numa node information to struct device

[Christoph Hellwig]

For node-aware skb allocations we need information about the node
in struct net_device or struct device.  Davem suggested to put
it into struct device which this patch does.

In particular:

 - struct device gets a new int numa_node member if CONFIG_NUMA is set
 - there are two new helpers, dev_to_node and set_dev_node to
   transparently deal with the non-numa case
 - for pci devices the node-info is set to the value we get from
   pcibus_to_node.

Note that for some architectures pcibus_to_node doesn't work yet at the
time we call it currently.  This is harmless and will just mean skb
allocations aren't node-local on this architectures until the
implementation of pcibus_to_node on these architectures have been
updated (There are patches for x86 and x86_64 floating around)


Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
 
Index: linux-2.6/include/linux/device.h
===
--- linux-2.6.orig/include/linux/device.h   2006-11-05 00:16:09.0 
+0100
+++ linux-2.6/include/linux/device.h2006-11-05 00:39:22.0 +0100
@@ -347,6 +347,9 @@
   BIOS data),reserved for device core*/
struct dev_pm_info  power;
 
+#ifdef CONFIG_NUMA
+   int numa_node;  /* NUMA node this device is close to */
+#endif
u64 *dma_mask;  /* dma mask (if dma'able device) */
u64 coherent_dma_mask;/* Like dma_mask, but for
 alloc_coherent mappings as
@@ -368,6 +371,14 @@
void(*release)(struct device * dev);
 };
 
+#ifdef CONFIG_NUMA
+#define dev_to_node(dev)   ((dev)->numa_node)
+#define set_dev_node(dev, node)((dev)->numa_node = node)
+#else
+#define dev_to_node(dev)   (-1)
+#define set_dev_node(dev, node)do { } while (0)
+#endif
+
 static inline void *
 dev_get_drvdata (struct device *dev)
 {
Index: linux-2.6/drivers/base/core.c
===
--- linux-2.6.orig/drivers/base/core.c  2006-11-05 00:16:09.0 +0100
+++ linux-2.6/drivers/base/core.c   2006-11-05 00:40:01.0 +0100
@@ -381,6 +381,7 @@
INIT_LIST_HEAD(&dev->node);
init_MUTEX(&dev->sem);
device_init_wakeup(dev, 0);
+   set_dev_node(dev, -1);
 }
 
 /**
Index: linux-2.6/drivers/pci/probe.c
===
--- linux-2.6.orig/drivers/pci/probe.c  2006-11-05 00:16:09.0 +0100
+++ linux-2.6/drivers/pci/probe.c   2006-11-05 00:39:55.0 +0100
@@ -846,6 +846,7 @@
dev->dev.release = pci_release_dev;
pci_dev_get(dev);
 
+   set_dev_node(&dev->dev, pcibus_to_node(bus));
dev->dev.dma_mask = &dev->dma_mask;
dev->dev.coherent_dma_mask = 0xull;
 
-
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/3] leak tracking for kmalloc_node

[Christoph Hellwig]

We have variants of kmalloc and kmem_cache_alloc that leave leak
tracking to the caller.  This is used for subsystem-specific allocators
like skb_alloc.

To make skb_alloc node-aware we need similar routines for the node-aware
slab allocator, which this patch adds.

Note that the code is rather ugly, but it mirrors the non-node-aware
code 1:1:

Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>

Index: linux-2.6/include/linux/slab.h
===
--- linux-2.6.orig/include/linux/slab.h 2006-10-23 17:20:14.0 +0200
+++ linux-2.6/include/linux/slab.h  2006-10-30 13:13:52.0 +0100
@@ -236,7 +236,25 @@
}
return __kmalloc_node(size, flags, node);
 }
+
+/*
+ * kmalloc_node_track_caller is a special version of kmalloc_node that
+ * records the calling function of the routine calling it for slab leak
+ * tracking instead of just the calling function (confusing, eh?).
+ * It's useful when the call to kmalloc_node comes from a widely-used
+ * standard allocator where we care about the real place the memory
+ * allocation request comes from.
+ */
+#ifndef CONFIG_DEBUG_SLAB
+#define kmalloc_node_track_caller(size, flags, node) \
+   __kmalloc_node(size, flags, node)
 #else
+extern void *__kmalloc_node_track_caller(size_t, gfp_t, int, void *);
+#define kmalloc_node_track_caller(size, flags, node) \
+   __kmalloc_node_track_caller(size, flags, node, \
+   __builtin_return_address(0))
+#endif
+#else /* CONFIG_NUMA */
 static inline void *kmem_cache_alloc_node(kmem_cache_t *cachep, gfp_t flags, 
int node)
 {
return kmem_cache_alloc(cachep, flags);
@@ -245,6 +263,9 @@
 {
return kmalloc(size, flags);
 }
+
+#define kmalloc_node_track_caller(size, flags, node) \
+   kmalloc_track_caller(size, flags)
 #endif
 
 extern int FASTCALL(kmem_cache_reap(int));
@@ -283,6 +304,8 @@
 #define kzalloc(s, f) __kzalloc(s, f)
 #define kmalloc_track_caller kmalloc
 
+#define kmalloc_node_track_caller kmalloc_node
+
 #endif /* CONFIG_SLOB */
 
 /* System wide caches */
Index: linux-2.6/mm/slab.c
===
--- linux-2.6.orig/mm/slab.c2006-10-23 17:21:47.0 +0200
+++ linux-2.6/mm/slab.c 2006-10-30 13:14:20.0 +0100
@@ -996,7 +996,7 @@
return NULL;
 }
 
-static inline void *__cache_alloc_node(struct kmem_cache *cachep,
+static inline void *cache_alloc_node(struct kmem_cache *cachep,
 gfp_t flags, int nodeid)
 {
return NULL;
@@ -1004,7 +1004,7 @@
 
 #else  /* CONFIG_NUMA */
 
-static void *__cache_alloc_node(struct kmem_cache *, gfp_t, int);
+static void *cache_alloc_node(struct kmem_cache *, gfp_t, int);
 static void *alternate_node_alloc(struct kmem_cache *, gfp_t);
 
 static struct array_cache **alloc_alien_cache(int node, int limit)
@@ -3105,10 +3105,10 @@
objp = cache_alloc(cachep, flags);
/*
 * We may just have run out of memory on the local node.
-* __cache_alloc_node() knows how to locate memory on other nodes
+* cache_alloc_node() knows how to locate memory on other nodes
 */
if (NUMA_BUILD && !objp)
-   objp = __cache_alloc_node(cachep, flags, numa_node_id());
+   objp = cache_alloc_node(cachep, flags, numa_node_id());
local_irq_restore(save_flags);
objp = cache_alloc_debugcheck_after(cachep, flags, objp,
caller);
@@ -3135,7 +3135,7 @@
else if (current->mempolicy)
nid_alloc = slab_node(current->mempolicy);
if (nid_alloc != nid_here)
-   return __cache_alloc_node(cachep, flags, nid_alloc);
+   return cache_alloc_node(cachep, flags, nid_alloc);
return NULL;
 }
 
@@ -3158,7 +3158,7 @@
if (zone_idx(*z) <= ZONE_NORMAL &&
cpuset_zone_allowed(*z, flags) &&
cache->nodelists[nid])
-   obj = __cache_alloc_node(cache,
+   obj = cache_alloc_node(cache,
flags | __GFP_THISNODE, nid);
}
return obj;
@@ -3167,7 +3167,7 @@
 /*
  * A interface to enable slab creation on nodeid
  */
-static void *__cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
+static void *cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
int nodeid)
 {
struct list_head *entry;
@@ -3440,7 +3440,9 @@
  * New and improved: it will now make sure that the object gets
  * put on the correct node list so that there is no false sharing.
  */
-void *kmem_cache_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid)
+static __always_inline void *
+__cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
+   int nodeid, void *caller)
 {
unsigned long save_flags

[Patch] qla3xxx: Add support for Qlogic ISP4032 chipset.

[Ron Mercer]

Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>

diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index ec640f6..b23ab70 100644
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -22,6 +22,7 @@ #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -38,7 +39,7 @@ #include "qla3xxx.h"
 
 #define DRV_NAME   "qla3xxx"
 #define DRV_STRING "QLogic ISP3XXX Network Driver"
-#define DRV_VERSION"v2.02.00-k36"
+#define DRV_VERSION"v2.03.00-k2"
 #define PFXDRV_NAME " "
 
 static const char ql3xxx_driver_name[] = DRV_NAME;
@@ -61,8 +62,9 @@ static int msi;
 module_param(msi, int, 0);
 MODULE_PARM_DESC(msi, "Turn on Message Signaled Interrupts.");
 
-static struct pci_device_id ql3xxx_pci_tbl[] __devinitdata = {
+static const struct pci_device_id ql3xxx_pci_tbl[] __devinitdata = {
{PCI_DEVICE(PCI_VENDOR_ID_QLOGIC, QL3022_DEVICE_ID)},
+   {PCI_DEVICE(PCI_VENDOR_ID_QLOGIC, QL3032_DEVICE_ID)},
/* required last entry */
{0,}
 };
@@ -1466,6 +1468,9 @@ static int ql_mii_setup(struct ql3_adapt
 2) << 7))
return -1;
 
+   if (qdev->device_id == QL3032_DEVICE_ID)
+   ql_write_page0_reg(qdev, &port_regs->macMIIMgmtControlReg, 
0x0f0);  /* clear bits 4-7 */
+
/* Divide 125MHz clock by 28 to meet PHY timing requirements */
reg = MAC_MII_CONTROL_CLK_SEL_DIV28;
 
@@ -1697,18 +1702,43 @@ static void ql_process_mac_tx_intr(struc
   struct ob_mac_iocb_rsp *mac_rsp)
 {
struct ql_tx_buf_cb *tx_cb;
+   int i;
 
tx_cb = &qdev->tx_buf[mac_rsp->transaction_id];
+
pci_unmap_single(qdev->pdev,
-pci_unmap_addr(tx_cb, mapaddr),
-pci_unmap_len(tx_cb, maplen), PCI_DMA_TODEVICE);
-   dev_kfree_skb_irq(tx_cb->skb);
+pci_unmap_addr(&tx_cb->map[0], mapaddr),
+pci_unmap_len(&tx_cb->map[0], maplen),
+PCI_DMA_TODEVICE);
+   tx_cb->seg_count--;
+   if (tx_cb->seg_count) {
+   for (i = 1; i < tx_cb->seg_count; i++) {
+   pci_unmap_page(qdev->pdev,
+  pci_unmap_addr(&tx_cb->map[i],
+ mapaddr),
+  pci_unmap_len(&tx_cb->map[i], maplen),
+  PCI_DMA_TODEVICE);
+   }
+   }
qdev->stats.tx_packets++;
qdev->stats.tx_bytes += tx_cb->skb->len;
+   dev_kfree_skb_irq(tx_cb->skb);
tx_cb->skb = NULL;
atomic_inc(&qdev->tx_count);
 }
 
+/*
+ * The difference between 3022 and 3032 for inbound completions:
+ * 3022 uses two buffers per completion.  The first buffer contains 
+ * (some) header info, the second the remainder of the headers plus 
+ * the data.  For this chip we reserve some space at the top of the 
+ * receive buffer so that the header info in buffer one can be 
+ * prepended to the buffer two.  Buffer two is the sent up while 
+ * buffer one is returned to the hardware to be reused.
+ * 3032 receives all of it's data and headers in one buffer for a 
+ * simpler process.  3032 also supports checksum verification as
+ * can be seen in ql_process_macip_rx_intr().
+ */
 static void ql_process_mac_rx_intr(struct ql3_adapter *qdev,
   struct ib_mac_iocb_rsp *ib_mac_rsp_ptr)
 {
@@ -1731,14 +1761,17 @@ static void ql_process_mac_rx_intr(struc
qdev->last_rsp_offset = qdev->small_buf_phy_addr_low + offset;
qdev->small_buf_release_cnt++;
 
-   /* start of first buffer */
-   lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
-   lrg_buf_cb1 = &qdev->lrg_buf[qdev->lrg_buf_index];
-   qdev->lrg_buf_release_cnt++;
-   if (++qdev->lrg_buf_index == NUM_LARGE_BUFFERS)
-   qdev->lrg_buf_index = 0;
-   curr_ial_ptr++; /* 64-bit pointers require two incs. */
-   curr_ial_ptr++;
+   if (qdev->device_id == QL3022_DEVICE_ID) {
+   /* start of first buffer (3022 only) */
+   lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
+   lrg_buf_cb1 = &qdev->lrg_buf[qdev->lrg_buf_index];
+   qdev->lrg_buf_release_cnt++;
+   if (++qdev->lrg_buf_index == NUM_LARGE_BUFFERS) {
+   qdev->lrg_buf_index = 0;
+   }
+   curr_ial_ptr++; /* 64-bit pointers require two incs. */
+   curr_ial_ptr++;
+   }
 
/* start of second buffer */
lrg_buf_phy_addr_low = le32_to_cpu(*curr_ial_ptr);
@@ -1769,7 +1802,8 @@ static void ql_process_mac_rx_intr(struc
qdev->ndev->last_rx = jiffies;
lrg_buf_cb2->skb = NULL;
 
-   ql_release_to_lrg_buf_free_list(qdev, lrg_buf_cb1);
+   if (qdev->device_id == QL3022_DEVICE_ID)
+   ql_release_to_lrg_buf_fre

Setup of testing lab and work on development

[Udayan Singh]

Hello,


From the previous response that i received, now i have the code and

now m browsing thru it.


1. if i understood correctly.. The discussion thread : "wireless notes
/ pre d80211 merge" discussion applies to the directory "net/d80211/"
from git:..

2. Test environment to setup for d80211 would be like this :

Laptop (Centrino - with ipw2200 or would it be some other) <> PC
acting as Access Point (with Wireless modem)

Any other that you would suggest that would be a more reasonable test
environment setup ?

Also if you have suggestions which company of appliances i should go for..

I can have 2 PCs i386 (Fedora Linux) easily available. So if some add
ons can be used would be pretty good also.

Few points that for clarification.
1. I intend to do the same so that I can also check if I make any
changes how are they reflected. I hope my purpose would be solved with
above setup.

2. How frequently would there be changes required in h/w here ?

tia..

Regards,
Udayan
Tata Consultancy Services
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/2]d80211: hardware TKIP support for ipw3945

[Johannes Berg]

On Tue, 2006-11-14 at 10:22 +0800, Hong Liu wrote:
> Resend the patch according to Johannes's comments.

Thanks :)

> Still put he tkip_key in tx_control structure.

Having the tkip_key in there is actually pretty bad for when/if we want
to push the tx_control into skb->cb (possibly combined with some header
or whatever). I don't think that has been decided on yet, will be a
large change anyway and this helps a lot so :)

Instead of putting all this into the stack, however, I think we could
make those drivers that require it do the bookkeeping and export
ieee80211_tkip_gen_phase1key and ieee80211_tkip_gen_rc4key for their
use. Maybe that's too much against Jiri's doctrine of "be easy on
drivers" though :)

This might actually also go some way towards unification with ipw2x00's
ieee80211 because those drivers require such functions as well as far as
I know. Haven't looked too deeply though.

johannes
-
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: watchdog timeout panic in e1000 driver

[Auke Kok]

Kenzo Iwami wrote:

Hi,


Even if the total lock time can be reduced, it's possible that interrupt
handler is executed while the interrupted code is still holding the 
semaphore.

I think your method only decrease the frequency of this problem.
Why does reducing the lock time solve this problem?
there are several problems here that need addressing. It's not acceptable 
for our driver to wait up to 15 seconds, and we can (presumably) reduce it 
to milliseconds, so that would help a lot. We should in no case at all hold 
it for any period longer than (give or take) half a second, so working 
towards that is a very good step in the right direction.


Adding the timer task back may also help, as we are no longer trying to 
aqcuire the sw_fw_semaphore in interrupt context, but we removed it for a 
reason, and I need to dig up what reason this exactly was before we can 
revert it. Jesse might know, so I'll talk to him. But this will not fix the 
fact that the semaphore is held for a long time :)

[...]

I think this problem occurs because interrupt handler is executed in same
CPU as process that acquires semaphore.
How about disabling interrupt while the process is holding the semaphore?
I think this is possible, if the total lock time has been reduced.


I created the attached patch based on the method described above.
This patch disables interrupt while the process is holding the semaphore.

I measured how long interrupts are being disabled 10,000 times using the
following method. TSC was read by rdtscll when interrupt was disabled
and interrupt was enabled again, then I subtract these two value.

The longest period interrupt was disabled is under 10usec, which seems
acceptable. The evaluation environment is;
  CPU: Intel Xeon CPU 3.73GHz
  kernel : 2.6.19-rc5

I also ran the reproduction TP I sent previously and confirmed that the
system didn't panic.
  http://marc.theaimsgroup.com/?l=linux-netdev&m=116125332319850&w=2

How about this method?


I'm not sure why you would have to disable interrupts when freeing the semaphore, but 
more importantly I don't want to introduce irq code in the swfw handling functions.


Since the major (only) user running this piece of code in intterupt context is the 
watchdog, we might as well see if we can only disable interrupts for that code path, 
which would only be once per 2 seconds. We don't need to protect the ethtool path into 
this code as it doesn't run in irq context.


Would you mind giving attached patch a try and let me know if it works for you? It will 
disable irqs for a bit longer time than your patch, and it begs for a special 
check-link-in-watchdog function that doesn't take so damn long :(


Thanks,

Auke


Signed-off-by: Auke Kok <[EMAIL PROTECTED]>

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index a2f1464..0b52ded 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2430,8 +2430,12 @@ e1000_watchdog(unsigned long data)
 	struct e1000_tx_ring *txdr = adapter->tx_ring;
 	uint32_t link, tctl;
 	int32_t ret_val;
+	unsigned long flags;
 
+	local_irq_save(flags);
 	ret_val = e1000_check_for_link(&adapter->hw);
+	local_irq_restore(flags);
+
 	if ((ret_val == E1000_ERR_PHY) &&
 	(adapter->hw.phy_type == e1000_phy_igp_3) &&
 	(E1000_READ_REG(&adapter->hw, CTRL) & E1000_PHY_CTRL_GBE_DISABLE)) {

Re: watchdog timeout panic in e1000 driver

[Kenzo Iwami]

Hi,

 Even if the total lock time can be reduced, it's possible that interrupt
 handler is executed while the interrupted code is still holding the 
 semaphore.
 I think your method only decrease the frequency of this problem.
 Why does reducing the lock time solve this problem?
>>> there are several problems here that need addressing. It's not acceptable 
>>> for our driver to wait up to 15 seconds, and we can (presumably) reduce it 
>>> to milliseconds, so that would help a lot. We should in no case at all hold 
>>> it for any period longer than (give or take) half a second, so working 
>>> towards that is a very good step in the right direction.
>>>
>>> Adding the timer task back may also help, as we are no longer trying to 
>>> aqcuire the sw_fw_semaphore in interrupt context, but we removed it for a 
>>> reason, and I need to dig up what reason this exactly was before we can 
>>> revert it. Jesse might know, so I'll talk to him. But this will not fix the 
>>> fact that the semaphore is held for a long time :)
[...]
> I think this problem occurs because interrupt handler is executed in same
> CPU as process that acquires semaphore.
> How about disabling interrupt while the process is holding the semaphore?
> I think this is possible, if the total lock time has been reduced.

I created the attached patch based on the method described above.
This patch disables interrupt while the process is holding the semaphore.

I measured how long interrupts are being disabled 10,000 times using the
following method. TSC was read by rdtscll when interrupt was disabled
and interrupt was enabled again, then I subtract these two value.

The longest period interrupt was disabled is under 10usec, which seems
acceptable. The evaluation environment is;
  CPU: Intel Xeon CPU 3.73GHz
  kernel : 2.6.19-rc5

I also ran the reproduction TP I sent previously and confirmed that the
system didn't panic.
  http://marc.theaimsgroup.com/?l=linux-netdev&m=116125332319850&w=2

How about this method?

I welcome any comments.
-- 
  Kenzo Iwami ([EMAIL PROTECTED])

Signed-off-by: Kenzo Iwami <[EMAIL PROTECTED]>

diff -urpN linux-2.6.19-rc5_org/drivers/net/e1000/e1000_hw.c
linux-2.6.19-rc5/drivers/net/e1000/e1000_hw.c
--- linux-2.6.19-rc5_org/drivers/net/e1000/e1000_hw.c   2006-11-14
17:47:28.0 +0900
+++ linux-2.6.19-rc5/drivers/net/e1000/e1000_hw.c   2006-11-15 
17:49:39.0
+0900
@@ -3379,6 +3379,7 @@ e1000_swfw_sync_acquire(struct e1000_hw
 uint32_t swmask = mask;
 uint32_t fwmask = mask << 16;
 int32_t timeout = 200;
+unsigned long flags;

 DEBUGFUNC("e1000_swfw_sync_acquire");

@@ -3389,8 +3390,11 @@ e1000_swfw_sync_acquire(struct e1000_hw
 return e1000_get_hw_eeprom_semaphore(hw);

 while (timeout) {
-if (e1000_get_hw_eeprom_semaphore(hw))
+local_irq_save(flags);
+if (e1000_get_hw_eeprom_semaphore(hw)) {
+local_irq_restore(flags);
 return -E1000_ERR_SWFW_SYNC;
+}

 swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC);
 if (!(swfw_sync & (fwmask | swmask))) {
@@ -3400,6 +3404,7 @@ e1000_swfw_sync_acquire(struct e1000_hw
 /* firmware currently using resource (fwmask) */
 /* or other software thread currently using resource (swmask) */
 e1000_put_hw_eeprom_semaphore(hw);
+local_irq_restore(flags);
 mdelay(5);
 timeout--;
 }
@@ -3413,6 +3418,7 @@ e1000_swfw_sync_acquire(struct e1000_hw
 E1000_WRITE_REG(hw, SW_FW_SYNC, swfw_sync);

 e1000_put_hw_eeprom_semaphore(hw);
+local_irq_restore(flags);
 return E1000_SUCCESS;
 }

@@ -3421,6 +3427,7 @@ e1000_swfw_sync_release(struct e1000_hw
 {
 uint32_t swfw_sync;
 uint32_t swmask = mask;
+unsigned long flags;

 DEBUGFUNC("e1000_swfw_sync_release");

@@ -3434,6 +3441,7 @@ e1000_swfw_sync_release(struct e1000_hw
 return;
 }

+local_irq_save(flags);
 /* if (e1000_get_hw_eeprom_semaphore(hw))
  *return -E1000_ERR_SWFW_SYNC; */
 while (e1000_get_hw_eeprom_semaphore(hw) != E1000_SUCCESS);
@@ -3444,6 +3452,7 @@ e1000_swfw_sync_release(struct e1000_hw
 E1000_WRITE_REG(hw, SW_FW_SYNC, swfw_sync);

 e1000_put_hw_eeprom_semaphore(hw);
+local_irq_restore(flags);
 }

 /*
-
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: wireless notes / pre d80211 merge

[Johannes Berg]

On Wed, 2006-11-15 at 11:05 +0100, Jiri Benc wrote:

> I wasn't in times when there was no cfg80211. But now... yes, you're
> right. The sysfs ieee80211 class exports just some interesting
> informations (we already agreed that add_interface and remove_interface
> would go away). Feel free to move it wherever you think is appropriate.

Even with cfg80211 we have the wiphy concept embedded in there. Not much
difference because we still have to do tc on wmasterN and "wiconf" on
wiphyN. So that doesn't really change anything. Now, we could of course
drop the wiphy concept from cfg80211 easily and require doing all these
things on wmasterN. That's the option I considered in section (8). I
don't like it too much, but I think I could live with it.

johannes
-
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: wireless notes / pre d80211 merge

[Johannes Berg]

On Wed, 2006-11-15 at 10:43 +0100, Jiri Benc wrote:

> In particular:
> - The operations that make sense for user to perform on wiphy/master
>   interface are different than the ones on virtual interfaces. It isn't
>   this way now.

Which particular operations do you have in mind? Granted, you won't ever
be able to specify the master device as the default route for IP, but
hey. I'd almost bet there are other devices that you can't do this with.

> - Why should master interface appear in ifconfig and similar tools the
>   same way as "virtual" interfaces? If you want to know how users are
>   confused by this, just search some forums.

Because it manages the qdiscs and frames actually show up there. Even
now, you can there see what you're transmitting :)

> - Does attaching of qdiscs to virtual interfaces make sense?

Yes, I do think so. Why not?

> This is a different thing. See the difference between SOCK_RAW and
> SOCK_DGRAM. The interface you are talking about is SOCK_DGRAM. Except
> it supports only one address. The correct solution would be extending
> sockaddr_ll (that's not possible, I know) or introduce a new
> SOCK_SOMETHING type (not possible either, at least in a short term).

I still haven't quite understood this argument. Could you elaborate?

> Except that all other hardware doesn't need things that we need. They
> need just one virtual interface - so their master and virtual interface
> is merged. This is net_device. We need to split it into two things.

That's not really true, if you have a 802.1q network then the raw netdev
is useless without vlan virtuals above unless you unpack the vlan on the
switch giving you a non-802.1q network again.

johannes
-
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: wireless notes / pre d80211 merge

[Jiri Benc]

On Wed, 15 Nov 2006 10:16:18 +0100, Johannes Berg wrote:
> > During the "tx handlers" phase that "copy of skb->cb" is extended quite a
> > lot with other information determined in the tx handlers. The result is a
> > structure that doesn't fit into cb anymore. This is a reason for not using
> > cb to pass tx information to drivers.
> 
> Actually, no, it isn't :) The part that is passed to drivers does fit,
> only the internal stuff doesn't.

Sorry, I was wrong here. I rechecked it now and starting from the last
diet (made by me long time ago, grr) it fits.

> > Please note that master interface has been always considered as a hack. Of
> > course, this perception can be changed if it's desirable.
> 
> Has it? Simon seems to disagree ;)

And I disagree with Simon :-)

> > > The master netdev and wiphy create two orthogonal interfaces to
> > > userspace that nonetheless pretty much represent the same thing---the
> > > underlying hardware.
> > 
> > Yup.
> 
> You just say it like that. Aren't you unhappy about that at all?

I wasn't in times when there was no cfg80211. But now... yes, you're
right. The sysfs ieee80211 class exports just some interesting
informations (we already agreed that add_interface and remove_interface
would go away). Feel free to move it wherever you think is appropriate.

> I don't think the master interface matters here at all. It's just an
> additional netdev that users previously didn't have, but so what?

As I said, my pre-cfg80211 arguments are not valid now.

> Let me qualify to externally visible problems :)

Okay :-)

> I've never wanted to change the top part (so far anyway :) ). It's
> orthogonal. And whether d80211 behaves as an 802.11 protocol is
> something that's visible only in the RX path really, struct packet_type
> and associated things.

I just said it's a confusing term, nothing against the idea.

> > >it becomes too small, we could put a pointer into skb->cb instead and
> > >do lifetime management with an skb desctructor.
> > 
> > Not very effective but will work.
> 
> Not really less effective than copying it around all the time as we do
> now and then kmalloc()ing it in some circumstances.

That's true.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs
-
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: wireless notes / pre d80211 merge

[Johannes Berg]

> I would go further - and perhaps move some of the meta-data that is in
> the skb->cb into a d80211 specific hardware header. This would allow
> sniffers to directly attach to the master device and both send and
> receive frames complete with the meta data. It would also reduce the
> amount of cb space we need. Virtual devices could be created in order to
> use sniffers that use a different hardware header format (with a small
> performance penalty when using those).

I'm not sure this is a good idea, it locks us in to some format because
user-space uses it and we'd need to serialise to that format to be
extensible.

On the other hand, we could fix some part of the structure to be
user-space visible, make it a real struct that just lives before the
802.11 header and don't serialise like it would be necessary with
something that is extensible. On RX, we could do the same.

For TX, this would allow applications to control whatever we put into
that struct (I would not, for example, allow tx status notifications to
ever go over a netdev as we do now), while for RX it would allow apps to
see almost everything.

It might complicate code a bit because different things would come from
different places (some things from a special header and some from
skb->cb), but I don't think it would be bad.

Other than this, I agree with you.

johannes
-
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: wireless notes / pre d80211 merge

[Jiri Benc]

On Tue, 14 Nov 2006 18:10:50 -0800, Simon Barber wrote:
> I disagree that the master device is a hack

It's a clever hack but still a hack. The Linux network interfaces
wasn't designed for the sort of things we do with master interface.
Actually, the networking core doesn't support the concept of "wiphys"
at all. Yes, Jouni found a really clever way around this. But the most
correct solution is different.

In particular:
- The operations that make sense for user to perform on wiphy/master
  interface are different than the ones on virtual interfaces. It isn't
  this way now.
- Why should master interface appear in ifconfig and similar tools the
  same way as "virtual" interfaces? If you want to know how users are
  confused by this, just search some forums.
- Does attaching of qdiscs to virtual interfaces make sense?
- Etc.

To me, the master interface in its current shape is a nice workaround
of kernel limitations, but still not a clean solution.

> I also disagree that we
> should use 802.11 format frames anywhere but internally inside the
> 802.11 stack. The 802.11 specification does not use 802.11 format frames
> to communicate with the upper layers - it uses almost exactly the same
> interface as 802.3 ethernet does. This is a 2 address interface. I
> believe that using the standard 2 address format to talk with upper
> layers matches well with the spec and is the right way to do things.

This is a different thing. See the difference between SOCK_RAW and
SOCK_DGRAM. The interface you are talking about is SOCK_DGRAM. Except
it supports only one address. The correct solution would be extending
sockaddr_ll (that's not possible, I know) or introduce a new
SOCK_SOMETHING type (not possible either, at least in a short term).

> If
> you put 802.11 frame format directly into the L3 protocols then you make
> all these protocols depend on the MAC - since they will now implement
> part of the MAC inside the L3 protocol. I don't think this is the right
> thing to do. I believe that the mapping of 3 and 4 address frames to a
> particular virtual 2 address port is the right way to do this mapping.

For some kind of applications SOCK_RAW on 802.11 interfaces makes
sense. (Actually, that's not so simple as they need to specify other
things like tx rate but that's an another story.)

> It is normal to have a single interface to represent the physical
> hardware network interface.

Except that all other hardware doesn't need things that we need. They
need just one virtual interface - so their master and virtual interface
is merged. This is net_device. We need to split it into two things.

> This is exactly the pattern that many other
> physical network devices use. Things like sniffing should go on on this
> physical interface - and the changes that johannes proposes are exactly
> the right things to enable this.
> 
> I would go further - and perhaps move some of the meta-data that is in
> the skb->cb into a d80211 specific hardware header. This would allow
> sniffers to directly attach to the master device and both send and
> receive frames complete with the meta data. It would also reduce the
> amount of cb space we need. Virtual devices could be created in order to
> use sniffers that use a different hardware header format (with a small
> performance penalty when using those).

This seems as a really bad solution to me. I fully agree with Johannes
regarding this.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs
-
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: wireless notes / pre d80211 merge

[Johannes Berg]

On Wed, 2006-11-15 at 01:11 +0100, Jiri Benc wrote:

> I wouldn't say "useless". It's actually a hack (and you yourself described
> in (7) why it is currently necessary). We'll need to live with it or
> cripple the stack to support only very basic features or rewrite the Linux
> networking core. Choose your own favorite solution :-)

I'd be fine with living with what you think of as a "hack" for a while
if the medium- to long-term plan is to rewrite the networking core to
get rid of it. I'm just not sure it makes sense.

> During the "tx handlers" phase that "copy of skb->cb" is extended quite a
> lot with other information determined in the tx handlers. The result is a
> structure that doesn't fit into cb anymore. This is a reason for not using
> cb to pass tx information to drivers.

Actually, no, it isn't :) The part that is passed to drivers does fit,
only the internal stuff doesn't.

> > Straying a bit from the discussion of frames and similar, let me
> > describe the "wiphy" concept we currently have. Currently, in sysfs we
> > have class/ieee80211/phy%d/ and below that a wealth of information not
> > only about various hardware related things but also, for example, a list
> > of all stations associated to any virtual access points intermixed with
> > those 'stations' that we are associated to on any virtual interface.
> > Also, we here find 'add_iface' and 'remove_iface', knobs to create and
> > destroy virtual interfaces.
> > 
> > The second wiphy concept is currently present in cfg80211 which
> > currently requires this concept in the userspace interface and should
> > effectively replace the 'add_iface' and 'remove_iface' hooks and make
> > them more generically available for non-d80211 drivers. I was thinking
> > of ipw2200 when I wrote it which allows adding a monitor device
> > (currently through some config option I think).
> 
> Not a big problem to combine these two "wiphys" into just one.

Right, that's no biggie. I was just trying to describe what we currently
have an forgot to mention it.

> Please note that master interface has been always considered as a hack. Of
> course, this perception can be changed if it's desirable.

Has it? Simon seems to disagree ;)

> > The master netdev and wiphy create two orthogonal interfaces to
> > userspace that nonetheless pretty much represent the same thing---the
> > underlying hardware.
> 
> Yup.

You just say it like that. Aren't you unhappy about that at all?

> There is one thing you haven't mentioned and which was probably the key
> reason for not believing this concept was wrong: we want to make the
> transition to the new stack as smooth to the users as possible. Users are
> not used to use the master interface. But since we're going to have a new
> set of userspace tools anyway, this point is no longer valid.

No, wait! We're transitioning from something that only supports one
interface to something that supports many virtual ones. As long as we
can represent the semantics of the previous single one as the default
virtual one, we're fine. Which is actually very possible and cfg80211's
WE compat code tries to show that.

I don't think the master interface matters here at all. It's just an
additional netdev that users previously didn't have, but so what?

> If this is your biggest problem with d80211 you're really happy :-) Try to
> fix some locking issue ;-)

Let me qualify to externally visible problems :)
I'm not too concerned about the internal stuff. That can be cleaned up
with some effort, but the externally visible stuff can't actually just
be cleaned up without thought and a plan.

> A full conversion to 802.11 protocol should do much more things and is not
> possible until we rewrite bridging. You converted the master interface
> only. That's not what I would call converting d80211 to a 802.11 protocol.

I've said this before but let me repeat.

There are two ends to d80211

top:virtual interfaces, most likely 802.3 for at least a while if
not forever
bottom: communication with hardware, qdiscs, etc.

I've never wanted to change the top part (so far anyway :) ). It's
orthogonal. And whether d80211 behaves as an 802.11 protocol is
something that's visible only in the RX path really, struct packet_type
and associated things.

> > This seems quite elegant, but there are a couple of problems with it:
> >  - skb->cb is sort of abused, and might be too small in the future. If
> 
> This is a blocker issue for me.
> 
> >it becomes too small, we could put a pointer into skb->cb instead and
> >do lifetime management with an skb desctructor.
> 
> Not very effective but will work.

Not really less effective than copying it around all the time as we do
now and then kmalloc()ing it in some circumstances.

johannes
-
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: [PATCHv2 1/2]: [NET]: Supporting UDP-Lite (RFC 3828) in Linux

[David Miller]

From: Gerrit Renker <[EMAIL PROTECTED]>
Date: Wed, 15 Nov 2006 07:58:17 +

> [NET/IPv4]: Make udp_push_pending_frames static
> udp_push_pending_frames is only referenced within
> net/ipv4/udp.c and hence can remain static.
> 
> Signed-off-by: Gerrit Renker  <[EMAIL PROTECTED]>

Applied, thanks Gerrit.
-
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: status of route matching work?

[Thomas Graf]

* Kumar Gala <[EMAIL PROTECTED]> 2006-11-14 15:08
> And was wondering what the status of this work was.  I'm interested  
> in being able to force packets for a local address out a real  
> ethernet device.

I'm working on it. For now, use SO_BINDTODEVICE.
-
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: Intel 82559 NIC corrupted EEPROM

[John]

John wrote:


-0009 : System RAM
000a-000b : Video RAM area
000f-000f : System ROM
0010-0ffe : System RAM
  0010-00296a1a : Kernel code
  00296a1b-0031bbe7 : Kernel data
0fff-0fff2fff : ACPI Non-volatile Storage
0fff3000-0fff : ACPI Tables
2000-200f : :00:08.0
2010-201f : :00:09.0
2020-202f : :00:0a.0
e000-e3ff : :00:00.0
e500-e50f : :00:08.0
e510-e51f : :00:09.0
e520-e52f : :00:0a.0
e530-e5300fff : :00:08.0
e5301000-e5301fff : :00:0a.0
e5302000-e5302fff : :00:09.0
- : reserved

I've also attached:

o config-2.6.18.1-adlink used to compile this kernel
o dmesg output after the machine boots


I suppose the information I've sent is not enough to locate the
root of the problem. Is there more I can provide?
-
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: [PATCHv2 1/2]: [NET]: Supporting UDP-Lite (RFC 3828) in Linux

[Gerrit Renker]

|  > [NET]:  Supporting UDP-Lite (RFC 3828) in Linux
| applied to net-2.6.20, thanks Gerrit.
Many thanks indeed. During these changes I accidentally
forgot to restore udp_push_pending_frames to its static state.

Can you please consider the attached patch --


[NET/IPv4]: Make udp_push_pending_frames static
udp_push_pending_frames is only referenced within
net/ipv4/udp.c and hence can remain static.

Signed-off-by: Gerrit Renker  <[EMAIL PROTECTED]>
---

diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 227655c..ac613ed 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -447,7 +447,7 @@ static void udp4_hwcsum_outgoing(struct 
 /*
  * Push out all pending data as one UDP datagram. Socket is locked.
  */
-int udp_push_pending_frames(struct sock *sk, struct udp_sock *up)
+static int udp_push_pending_frames(struct sock *sk, struct udp_sock *up)
 {
struct inet_sock *inet = inet_sk(sk);
struct flowi *fl = &inet->cork.fl;
-
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