Re: [PATCH v2] bridge: fix locking and memory leak in br_add_bridge
From: Jiri Benc <[EMAIL PROTECTED]> Date: Fri, 26 May 2006 11:08:06 +0200 > On Thu, 25 May 2006 09:23:31 -0700, Stephen Hemminger wrote: > > + unregister_netdevice(dev); > > + err: > > rtnl_unlock(); > > + if (ret) > > + free_netdev(dev); > > return ret; > > I don't think this is correct. netdev_run_todo calls dev->destructor > which is set to free_netdev by br_dev_setup. So you're calling > free_netdev on already freed device. Right, we need a more correct version of this bug fix. :) - 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] via-velocity: allow MTU size less than 1500 bytes
Jay Cliburn wrote: Change the minimum allowable MTU size from 1500 bytes to 64 bytes. Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]> --- linux-2.6.16.x86_64/drivers/net/via-velocity.h.orig 2006-05-23 07:42:24.0 -0500 +++ linux-2.6.16.x86_64/drivers/net/via-velocity.h 2006-05-23 08:31:17.0 -0500 @@ -307,7 +307,7 @@ #define TX_QUEUE_NO 4 #define MAX_HW_MIB_COUNTER 32 -#define VELOCITY_MIN_MTU(1514-14) +#define VELOCITY_MIN_MTU(64) #define VELOCITY_MAX_MTU(9000) ACK, but patch won't apply: [EMAIL PROTECTED] netdev-2.6]$ git-applymbox /g/tmp/mbox ~/info/signoff.txt 1 patch(es) to process. Applying 'via-velocity: allow MTU size less than 1500 bytes' fatal: corrupt patch at line 5 - 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 4/5] s390: lcs driver bug fixes and improvements [1/2]
Frank Pavlic wrote: From: Klaus Wacker <[EMAIL PROTECTED]> Several problems occured with lcs device driver: - device not operational anymore after cable pull/plug-in. - unpredictable results occured, e.g. kernel panic using cards of type QD8F. - STOPLAN and delete multicast address command were not proper recognized by OSA card under heavy network workload. - channel/device error checks missing in interrupt handler. To fix all problems at once recovery of lcs devices has been improved. missing error checks in lcs interrupt handler has been added. Once a hardware problem occurs lcs will recover the device now properly. Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]> applied 4-5 - 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/5] s390: minor fix in cu3088
Frank Pavlic wrote: Hi Jeff, please apply following 5 patches. Thanks ... Frank From: Cornelia Huck <[EMAIL PROTECTED]> In case of a parse error for the cu3088 group attribute, return -EINVAL instead of count. Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]> applied patches 1-3 of 5 - 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] r8169: add new PCI ID
Yoichi Yuasa wrote: Hi, This patch add new PCI ID for r8169 driver. RTL8110SBL has this PCI ID. applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pci_ids: add new device ids
Ayaz Abdulla wrote: This patch adds new device ids for MCP61 and MCP65 chips. Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]> applied. For the future, make subject line more descriptive. "Add new NVIDIA device IDs" would have been better. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] forcedeth: add support for new device ids
Ayaz Abdulla wrote: This patch adds support for the new chips MCP61 and MCP65. Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]> ACK, but did not apply due to rejection of configuration patch - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: spidernet: replace whitespaces by tabs
Jens Osterkamp wrote: From: Jens Osterkamp <[EMAIL PROTECTED]> The original patch was using whitespaces instead of tabs. Signed-off-by: Jens Osterkamp <[EMAIL PROTECTED]> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.17-rc5] pcnet32: remove incorrect pcnet32_free_ring
Don Fry wrote: During a code scan for another change I discovered that this call to pcnet32_free_ring must be removed. If the open fails due to a lack of memory all the ring structures are removed via the call to free_ring and a subsequent call to open will dereference a null pointer in pcnet32_init_ring. Please apply to 2.6.17. Signed-off-by: Don Fry <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000: add WoL fix for 2.6.17rc
Auke Kok wrote: Jeff, Please queue the 'e1000: add shutdown handler back for WoL' for 2.6.17rc's. Since this fix is already committed to jgarzik/netdev-2.6#upstream, you can cherrypick it into #upstream-fixes: $ git-cherry-pick c653e6351e371b33b29871e5eedf610ffb3be037 perfect, done, thanks. 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: Please pull 'upstream-fixes' branch of wireless-2.6
John W. Linville wrote: The following changes since commit 705af309505681f197f81618440954d10f120dc0: Martin Schwidefsky: s390: fix typo in stop_hz_timer. are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-fixes pulled - 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/9] ixgb: driver update to 1.0.109-k2
Kok, Auke wrote: Hi, Here are the ixgb driver updates for 1.0.109-k2. This corresponds with the release of 1.0.109 on e1000.sf.net, and fixes several issues. e1000 update will come soon... Summary: [1] fix smp polling race condition [2] fix interface losing macaddr on ifdn/up [3] revert an unwanted fix regarding tso/descriptors [4] allocate only buffersize needed [5] remove lock access in the fast path [6] remove inlines, allow compiler to choose [7] replace netdev->priv with netdev_priv() [8] remove changelog [9] update version, dates These changes are available through git. git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 ixgb-1.0.109-k2 pulled - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.18 3/3] tg3: update version and reldate
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Fri, 26 May 2006 16:03:16 -0700 > Update version to 3.59. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Also applied, thanks a lot 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: [PATCH 2.6.18 2/3] tg3: Add recovery logic when MMIOs are re-ordered
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Fri, 26 May 2006 16:03:07 -0700 > Add recovery logic when we suspect that the system is re-ordering > MMIOs. Re-ordered MMIOs to the send mailbox can cause bogus tx > completions and hit BUG_ON() in the tx completion path. ... > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Looks good, applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.18 1/3] tg3: Add 5786 PCI ID
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Fri, 26 May 2006 15:55:23 -0700 > Add PCI ID for BCM5786 which is a variant of 5787. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Simple enough, applied to net-2.6.18 Thanks. - 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.18 1/3] tg3: Add 5786 PCI ID
Add PCI ID for BCM5786 which is a variant of 5787.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 49ad60b..3de5a62 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -229,6 +229,8 @@ static struct pci_device_id tg3_pci_tbl[
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5755M,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
+ { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5786,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5787,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5787M,
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index d6fe048..bef7ea1 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1886,6 +1886,7 @@
#define PCI_DEVICE_ID_TIGON3_5751F 0x167e
#define PCI_DEVICE_ID_TIGON3_5787M 0x1693
#define PCI_DEVICE_ID_TIGON3_5782 0x1696
+#define PCI_DEVICE_ID_TIGON3_5786 0x169a
#define PCI_DEVICE_ID_TIGON3_5787 0x169b
#define PCI_DEVICE_ID_TIGON3_5788 0x169c
#define PCI_DEVICE_ID_TIGON3_5789 0x169d
-
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.18 3/3] tg3: update version and reldate
Update version to 3.59. Signed-off-by: Michael Chan <[EMAIL PROTECTED]> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c index b01499c..db3f769 100644 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -69,8 +69,8 @@ #define DRV_MODULE_NAME"tg3" #define PFX DRV_MODULE_NAME": " -#define DRV_MODULE_VERSION "3.58" -#define DRV_MODULE_RELDATE "May 22, 2006" +#define DRV_MODULE_VERSION "3.59" +#define DRV_MODULE_RELDATE "May 26, 2006" #define TG3_DEF_MAC_MODE 0 #define TG3_DEF_RX_MODE0 - 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.18 2/3] tg3: Add recovery logic when MMIOs are re-ordered
Add recovery logic when we suspect that the system is re-ordering
MMIOs. Re-ordered MMIOs to the send mailbox can cause bogus tx
completions and hit BUG_ON() in the tx completion path.
tg3 already has logic to handle re-ordered MMIOs by flushing the
MMIOs that must be strictly ordered (such as the send mailbox).
Determining when to enable the flush is currently a manual process
of adding known chipsets to a list.
The new code replaces the BUG_ON() in the tx completion path with the
call to tg3_tx_recover(). It will set the TG3_FLAG_MBOX_WRITE_REORDER
flag and reset the chip later in the workqueue to recover and start
flushing MMIOs to the mailbox.
A message to report the problem will be printed. We will then decide
whether or not to add the host bridge to the list of chipsets that do
re-ordering.
We may add some additional code later to print the host bridge's ID
so that the user can report it more easily.
The assumption that re-ordering can only happen on x86 systems is also
removed.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 3de5a62..bc3f884 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -2967,6 +2967,29 @@ static int tg3_setup_phy(struct tg3 *tp,
return err;
}
+/* This is called whenever we suspect that the system chipset is re-
+ * ordering the sequence of MMIO to the tx send mailbox. The symptom
+ * is bogus tx completions. We try to recover by setting the
+ * TG3_FLAG_MBOX_WRITE_REORDER flag and resetting the chip later
+ * in the workqueue.
+ */
+static void tg3_tx_recover(struct tg3 *tp)
+{
+ BUG_ON((tp->tg3_flags & TG3_FLAG_MBOX_WRITE_REORDER) ||
+ tp->write32_tx_mbox == tg3_write_indirect_mbox);
+
+ printk(KERN_WARNING PFX "%s: The system may be re-ordering memory-"
+ "mapped I/O cycles to the network device, attempting to "
+ "recover. Please report the problem to the driver maintainer "
+ "and include system chipset information.\n", tp->dev->name);
+
+ spin_lock(&tp->lock);
+ spin_lock(&tp->tx_lock);
+ tp->tg3_flags |= TG3_FLAG_TX_RECOVERY_PENDING;
+ spin_unlock(&tp->tx_lock);
+ spin_unlock(&tp->lock);
+}
+
/* Tigon3 never reports partial packet sends. So we do not
* need special logic to handle SKBs that have not had all
* of their frags sent yet, like SunGEM does.
@@ -2979,9 +3002,13 @@ static void tg3_tx(struct tg3 *tp)
while (sw_idx != hw_idx) {
struct tx_ring_info *ri = &tp->tx_buffers[sw_idx];
struct sk_buff *skb = ri->skb;
- int i;
+ int i, tx_bug = 0;
+
+ if (unlikely(skb == NULL)) {
+ tg3_tx_recover(tp);
+ return;
+ }
- BUG_ON(skb == NULL);
pci_unmap_single(tp->pdev,
pci_unmap_addr(ri, mapping),
skb_headlen(skb),
@@ -2992,10 +3019,9 @@ static void tg3_tx(struct tg3 *tp)
sw_idx = NEXT_TX(sw_idx);
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
- BUG_ON(sw_idx == hw_idx);
-
ri = &tp->tx_buffers[sw_idx];
- BUG_ON(ri->skb != NULL);
+ if (unlikely(ri->skb != NULL || sw_idx == hw_idx))
+ tx_bug = 1;
pci_unmap_page(tp->pdev,
pci_unmap_addr(ri, mapping),
@@ -3006,6 +3032,11 @@ static void tg3_tx(struct tg3 *tp)
}
dev_kfree_skb(skb);
+
+ if (unlikely(tx_bug)) {
+ tg3_tx_recover(tp);
+ return;
+ }
}
tp->tx_cons = sw_idx;
@@ -,6 +3364,11 @@ static int tg3_poll(struct net_device *n
/* run TX completion thread */
if (sblk->idx[0].tx_consumer != tp->tx_cons) {
tg3_tx(tp);
+ if (unlikely(tp->tg3_flags & TG3_FLAG_TX_RECOVERY_PENDING)) {
+ netif_rx_complete(netdev);
+ schedule_work(&tp->reset_task);
+ return 0;
+ }
}
/* run RX thread, within the bounds set by NAPI.
@@ -3581,6 +3617,13 @@ static void tg3_reset_task(void *_data)
restart_timer = tp->tg3_flags2 & TG3_FLG2_RESTART_TIMER;
tp->tg3_flags2 &= ~TG3_FLG2_RESTART_TIMER;
+ if (tp->tg3_flags & TG3_FLAG_TX_RECOVERY_PENDING) {
+ tp->write32_tx_mbox = tg3_write32_tx_mbox;
+ tp->write32_rx_mbox = tg3_write_flush_reg32;
+ tp->tg3_flags |= TG3_FLAG_MBOX_WRITE_REORDER;
+ tp->tg3_flags &= ~TG3_FLAG_TX_RECOVERY_PENDING;
+ }
+
tg3_halt(tp, RESET_KIND_SHUTDOWN, 0);
tg3_init_hw(tp, 1);
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 0e29b88..7f2
Re: Refactor Netlink connector?
James Morris wrote: > I've been looking through the kernel for new subsytems which might need > LSM hooks, and we've got a proliferation of Netlink abstractions: generic > Netlink, nfnetlink, connector and kobject_uevent. > > I think we should look at consolidating some of these schemes, and if > possible, into a unififed Netlink API. > > As a first step, what would it take to adapt the single user of > connector (the w1 driver) to use generic Netlink? > > I suspect that some of the nfnetlink infrastructure can be used more > generically, and that a simple API for the common case of kernel->user > event notifications could be also be provided. > > Thoughts? No great thoughts at this point, but I agree 100%. In my opinion netlink subsystems should be usable in a uniform way (at least netlink specific parts like dump/query/set, ACKs, attribute encoding and similar low-level stuff) without implementation specific details. I guess from a SELinux point of view having a single spot to place hooks with well defined semantics is what counts, but it comes down to the same, there is too much diversion among netlink users. I'll look into the nfnetlink bits for a start, but I fear because of use of network byteorder in lots of places it will not be able to fully convert to generic netlink. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] new qla3xxx NIC Driver v2.02.00k29 (repost)
Fixes:
1. Remove code has to unregister net device before doing any hardware
tear down. This ensures that packets won't get queued etc..
2. Need to unmap PCI request before reference in eth_type_trans
3. call free_netdev not kfree to free net_device
see Documentation/networking/netdevices.txt
Improvements:
4. indentation. Lots of funny line breaks in your source.
5. use const if you can
6. ethtool get_link reports carrier state
7. don't need to do multicast list comparisons?
kernel already have to deal with multicast hash collision from drivers,
so if your hardware can't do it. walking the list of addresses seems like
unnecessary work.
(if you want to keep this code, consider using compare_ether_addr)
7. prefetching the data before passing up is almost always a cache win
since the first thing that happens is looking at the data.
My changes might have broken stuff, not tested (no hardware).
Next time please post in standard kernel patch format.
(ie Documentation/SubmittingPatches)
I.e as part of a kernel build tree:
drivers/net/ql3_xxx.c
drivers/net/ql3_def.h
and delta's for drivers/net/Kconfig and drivers/net/Makefile
--- ql3_xxx.c.orig 2006-05-24 15:41:42.0 -0700
+++ ql3_xxx.c 2006-05-26 15:32:39.0 -0700
@@ -9,10 +9,10 @@
#define DRV_NAME "qla3xxx"
#define DRV_STRING "QLogic ISP3XXX Network Driver"
#define DRV_VERSION"v2.02.00-k29"
-#define PFXDRV_NAME " "
+#define PFXDRV_NAME " "
-static char ql3xxx_driver_name[] = DRV_NAME;
-static char ql3xxx_driver_version[] = DRV_VERSION;
+static const char ql3xxx_driver_name[] = DRV_NAME;
+static const char ql3xxx_driver_version[] = DRV_VERSION;
MODULE_AUTHOR("QLogic Corporation");
MODULE_DESCRIPTION("QLogic ISP3XXX Network Driver " DRV_VERSION " ");
@@ -485,7 +485,7 @@ static int ql_get_nvram_params(struct ql
return checksum;
}
-static u32 PHYAddr[2] = {
+static const u32 PHYAddr[2] = {
PORT0_PHY_ADDRESS, PORT1_PHY_ADDRESS
};
@@ -1504,9 +1504,12 @@ static void ql_set_msglevel(struct net_d
}
static struct ethtool_ops ql3xxx_ethtool_ops = {
- .get_settings = ql_get_settings,.get_drvinfo = ql_get_drvinfo,
+ .get_settings = ql_get_settings,
+ .get_drvinfo = ql_get_drvinfo,
.get_perm_addr = ethtool_op_get_perm_addr,
- .get_msglevel = ql_get_msglevel,.set_msglevel = ql_set_msglevel,
+ .get_link = ethtool_op_get_link,
+ .get_msglevel = ql_get_msglevel,
+ .set_msglevel = ql_set_msglevel,
};
static struct ql_tx_buf_cb *ql_alloc_txbuf(struct ql3_adapter *qdev)
@@ -1760,9 +1763,6 @@ static void ql_process_mac_rx_intr(struc
u32 *curr_ial_ptr;
struct sk_buff *skb;
struct net_device *ndev = qdev->ndev;
- int send_packet = 1;
- struct dev_mc_list *mc_list = ndev->mc_list;
- struct ethhdr *eth_hdr;
u16 length = le16_to_cpu(ib_mac_rsp_ptr->length);
/*
@@ -1799,59 +1799,27 @@ static void ql_process_mac_rx_intr(struc
qdev->lrg_buf_index = 0;
}
skb = lrg_buf_cb2->skb;
- eth_hdr = (struct ethhdr *)skb->data;
-
- if (ib_mac_rsp_ptr->flags & IB_MAC_IOCB_RSP_B) {
- if (!(ndev->flags & (IFF_BROADCAST | IFF_PROMISC))) {
- send_packet = 0;
- }
- } else if (ib_mac_rsp_ptr->flags & IB_MAC_IOCB_RSP_M) {
- /* We received a multicast packet. Scan the list of multicast
addresses
-* and see if there is a match otherwise discard packet */
- send_packet = 0;
- if (ndev->flags & (IFF_ALLMULTI | IFF_PROMISC)) {
- send_packet = 1;
- } else if ((ndev->flags & IFF_MULTICAST)) {
- while (mc_list) {
- if ((mc_list->dmi_addr[0] == eth_hdr->h_dest[0])
- && (mc_list->dmi_addr[1] ==
- eth_hdr->h_dest[1])
- && (mc_list->dmi_addr[2] ==
- eth_hdr->h_dest[2])
- && (mc_list->dmi_addr[3] ==
- eth_hdr->h_dest[3])
- && (mc_list->dmi_addr[4] ==
- eth_hdr->h_dest[4])
- && (mc_list->dmi_addr[5] ==
- eth_hdr->h_dest[5])) {
- send_packet = 1;
- break;
- }
- mc_list = mc_list->next;
- }
- }
- }
qdev->stats.rx_packets++;
qdev->stats.rx_bytes += length;
- if (send_packet) {
- skb_put(skb, length);
- skb->dev = qdev->ndev;
-
Re: Wireless patches to push for 2.6.18?
On Friday 26 May 2006 21:59, John W. Linville wrote: > As David M. so recently reminded us, 2.6.17 is likely to be blessed soon. > That will open a short merge window for non-"fixes" to go into 2.6.18. > > Along w/ the patches currently on the 'upstream' branch, I'd like to > see some of the the drivers hanging-out only on the 'master' branch > of wireless-2.6 to get polished-up and pushed-out. What do you think > are the best candidates? > > > http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/master/ > > Anyone have anything else they are holding-back for 2.6.18? Yes, we would like to merge the big tx-power-rewrite (aka get 4318 working) into the bcm43xx driver, but it is only 90% completed atm. I guess we still have 1 to 1.5 weeks left, before the window closes? - 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: reminder, 2.6.18 window...
Can you ask internally on how openview would handle this? It carriers the major chunk of management tools market so it may provide good insight. I've asked the question in an internal, informal communications channel. No guarantees it will reach any OpenView types, but if it does I'll try to provide the gist of the replies. While the question of the patch itself appears to be laid to rest for the time being, since I took an "action item" I figured it would be good to complete it. Here was one response: If the stats are being gathered via SNMP, most management systems do one of two things: - treat it as a discontinuity: in this case, the handling is similar to that for a device reboot; that is, delta calculation starts anew. - treat it as a wrap-around (especially for 32-bit counters): the smarter ones have logic to detect whether this is a "feasible" wrap-around (e.g., old measurement was "near" overflow, etc.) and appropriately adjust the delta. In your case, it looks like you want to treat this as a discontinuity. The interface table in IF-MIB has an attribute called ifLastChange; if you reset the counter, you may want to set it to the sysUpTime value. This way, a "proper" implementation could determine that a discontinuity has occurred. And then a more detailed response with an associated, and very long URL: http://openview.hp.com/ecare/getsupportdoc?docid=OV-EN012963&urlN=http%3A%2F%2Fsupport.openview.hp.com%2Fselfsolve%2Fdo%2Fadvanced-search&fromOV =false&urlB=http%3A%2F%2Fsupport.openview.hp.com%2Fselfsolve%2Fdo%2Fadvanced-search%3Faction%3Dresults&f=ss&hl=true QUOTE: This problem can be caused by the SNMP MIB counter wrap. NNM 6.01 or later has logic to detect collected MIB counter wrap. If NNM detects that a MIB counter is wrapped, then it is considered as one of the following two cases: The counter reached its maximum value and wrapped. The counter reset occurred due to the SNMP agent restart. In the case of (1), snmpCollect takes the counter wrap into account and adjusts the value taking the maximum value of the counter into consideration. However, in the case of (2), NNM cancels the measurement of this period because it considers that the previous value that was used for calculation is no longer valid. If the value of the counter increases too fast, NNM may consider that the detected counter wrap is due to the agent restart even though the counter just wrapped. In this case, the data of the measurement period gets dropped. There are two approaches available to avoid this situation: Use counters that have a larger maximum size. For example, use IfHCInOctets/IfHCOutOctets(64bit - counter64) in IF_MIB instead of IfInOctets/IfOutOctets(32bit - counter). Shorten the period of measurement, so that the amount of the counter increase is potentially short enough to let NNM detect the counter wrap correctly. Note: It may be necessary to upgrade the operating system of some network devices to gain access to 64-bit counters. Note also, that counter64 is a SNMPv2 data type, the agent must support SNMPv2. If trying to access the values using snmpwalk use the parameter-v2c to ensure that the variables can be accessed. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Please pull 'upstream-fixes' branch of wireless-2.6
The following changes since commit 705af309505681f197f81618440954d10f120dc0:
Martin Schwidefsky:
s390: fix typo in stop_hz_timer.
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-fixes
Randy Dunlap:
wavelan: fix section mismatch
arlan: fix section mismatch warnings
drivers/net/wireless/arlan-main.c |4 ++--
drivers/net/wireless/wavelan.c|2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/arlan-main.c
b/drivers/net/wireless/arlan-main.c
index 0e1ac33..bed6823 100644
--- a/drivers/net/wireless/arlan-main.c
+++ b/drivers/net/wireless/arlan-main.c
@@ -1838,7 +1838,7 @@ struct net_device * __init arlan_probe(i
}
#ifdef MODULE
-int init_module(void)
+int __init init_module(void)
{
int i = 0;
@@ -1860,7 +1860,7 @@ int init_module(void)
}
-void cleanup_module(void)
+void __exit cleanup_module(void)
{
int i = 0;
struct net_device *dev;
diff --git a/drivers/net/wireless/wavelan.c b/drivers/net/wireless/wavelan.c
index ff192e9..dade4b9 100644
--- a/drivers/net/wireless/wavelan.c
+++ b/drivers/net/wireless/wavelan.c
@@ -4306,7 +4306,7 @@ #ifdefMODULE
* Insertion of the module
* I'm now quite proud of the multi-device support.
*/
-int init_module(void)
+int __init init_module(void)
{
int ret = -EIO; /* Return error if no cards found */
int i;
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] network dev.c comment cleanups
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Fri, 26 May 2006 10:42:48 -0700 > Noticed that dev_alloc_name() comment was incorrect, and more spellung errors. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Applied, thanks Stephen. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [IPV6] ROUTE: Don't try less preferred routes for on-link routes.
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Fri, 26 May 2006 20:01:56 +0900 (JST) > In article <[EMAIL PROTECTED]> (at Fri, 26 May 2006 13:44:59 +0300 (EEST)), > Meelis Roos <[EMAIL PROTECTED]> says: > > > >> The unreachable route works now but LAN routing still does not work. > > >> Locally generated ICMPv6 packets that should go to LAN interface still > > >> go to tun6to4. > > > > > > Please try this. > > > > This works for both unreachable and LAN routes, thanks! > > Please push this to 2.6.17-final. Applied, thank you very much. - 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
usb wifi: zd1201 cleanups
Hi!
I am trying to get zd1201 to work on ARM. It works okay on i386, but
not on ARM -- I get no results from iwlist wlan0 scan. Anyway, here
are some cleanups.
Line of ~280 characters, full of whitespace really got me. Please
apply,
---
Cleanup coding style and other small stuff in zd1201. No real code
changes.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/usb/net/zd1201.c b/drivers/usb/net/zd1201.c
index 9b1e4ed..aef02c4 100644
--- a/drivers/usb/net/zd1201.c
+++ b/drivers/usb/net/zd1201.c
@@ -33,7 +33,7 @@ static struct usb_device_id zd1201_table
{}
};
-static int ap = 0; /* Are we an AP or a normal station? */
+static int ap; /* Are we an AP or a normal station? */
#define ZD1201_VERSION "0.15"
@@ -49,7 +49,7 @@ MODULE_DEVICE_TABLE(usb, zd1201_table);
static int zd1201_fw_upload(struct usb_device *dev, int apfw)
{
const struct firmware *fw_entry;
- char* data;
+ char *data;
unsigned long len;
int err;
unsigned char ret;
@@ -65,7 +65,7 @@ static int zd1201_fw_upload(struct usb_d
if (err) {
dev_err(&dev->dev, "Failed to load %s firmware file!\n",
fwfile);
dev_err(&dev->dev, "Make sure the hotplug firmware loader is
installed.\n");
- dev_err(&dev->dev, "Goto http://linux-lc100020.sourceforge.net
for more info\n");
+ dev_err(&dev->dev, "Goto http://linux-lc100020.sourceforge.net
for more info.\n");
return err;
}
@@ -94,12 +94,12 @@ static int zd1201_fw_upload(struct usb_d
USB_DIR_OUT | 0x40, 0, 0, NULL, 0, ZD1201_FW_TIMEOUT);
if (err < 0)
goto exit;
-
+
err = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), 0x4,
USB_DIR_IN | 0x40, 0,0, &ret, sizeof(ret), ZD1201_FW_TIMEOUT);
if (err < 0)
goto exit;
-
+
if (ret & 0x80) {
err = -EIO;
goto exit;
@@ -166,13 +166,13 @@ static int zd1201_docmd(struct zd1201 *z
return -ENOMEM;
}
usb_fill_bulk_urb(urb, zd->usb, usb_sndbulkpipe(zd->usb, zd->endp_out2),
-command, 16, zd1201_usbfree, zd);
+ command, 16, zd1201_usbfree, zd);
ret = usb_submit_urb(urb, GFP_ATOMIC);
if (ret) {
kfree(command);
usb_free_urb(urb);
}
-
+
return ret;
}
@@ -316,7 +316,7 @@ static void zd1201_usbrx(struct urb *urb
fc = le16_to_cpu(*(__le16 *)&data[datalen-16]);
seq = le16_to_cpu(*(__le16 *)&data[datalen-24]);
- if(zd->monitor) {
+ if (zd->monitor) {
if (datalen < 24)
goto resubmit;
if (!(skb = dev_alloc_skb(datalen+24)))
@@ -364,7 +364,7 @@ static void zd1201_usbrx(struct urb *urb
goto resubmit;
}
hlist_for_each_entry(frag, node, &zd->fraglist, fnode)
- if(frag->seq == (seq&IEEE80211_SCTL_SEQ))
+ if (frag->seq == (seq&IEEE80211_SCTL_SEQ))
break;
if (!frag)
goto resubmit;
@@ -376,7 +376,6 @@ static void zd1201_usbrx(struct urb *urb
goto resubmit;
hlist_del_init(&frag->fnode);
kfree(frag);
- /* Fallthrough */
} else {
if (datalen<14)
goto resubmit;
@@ -422,7 +421,7 @@ static int zd1201_getconfig(struct zd120
int rid_fid;
int length;
unsigned char *pdata;
-
+
zd->rxdatas = 0;
err = zd1201_docmd(zd, ZD1201_CMDCODE_ACCESS, rid, 0, 0);
if (err)
@@ -471,11 +470,11 @@ static int zd1201_getconfig(struct zd120
length = zd->rxlen;
do {
- int actual_length;
+ int actual_length;
actual_length = (length > 64) ? 64 : length;
- if(pdata[0] != 0x3) {
+ if (pdata[0] != 0x3) {
dev_dbg(&zd->usb->dev, "Rx Resource packet type error:
%02X\n",
pdata[0]);
return -EINVAL;
@@ -487,11 +486,10 @@ static int zd1201_getconfig(struct zd120
}
/* Skip t
Refactor Netlink connector?
I've been looking through the kernel for new subsytems which might need LSM hooks, and we've got a proliferation of Netlink abstractions: generic Netlink, nfnetlink, connector and kobject_uevent. I think we should look at consolidating some of these schemes, and if possible, into a unififed Netlink API. As a first step, what would it take to adapt the single user of connector (the w1 driver) to use generic Netlink? I suspect that some of the nfnetlink infrastructure can be used more generically, and that a simple API for the common case of kernel->user event notifications could be also be provided. Thoughts? - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] Resending NetXen 1G/10G NIC driver patch
Amit> We'll implement the minor changes rightaway and post an Amit> update. We are also thinking about what's the best way to Amit> incorporate the data structure changes you have Amit> suggested. Will post a reply on that too soon. By the way, my suggestion to the original posting still stands: use a descriptive subject line and include a changelog entry for each patch that you expect to be merged. - R. - 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
Wireless patches to push for 2.6.18?
As David M. so recently reminded us, 2.6.17 is likely to be blessed soon. That will open a short merge window for non-"fixes" to go into 2.6.18. Along w/ the patches currently on the 'upstream' branch, I'd like to see some of the the drivers hanging-out only on the 'master' branch of wireless-2.6 to get polished-up and pushed-out. What do you think are the best candidates? http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/master/ Anyone have anything else they are holding-back for 2.6.18? What about the wireless button infrastructure Ivo posted yesterday? Is that useful for any of the drivers currently in wireless-2.6? I was caught a bit 'flat-footed' for the 2.6.17 merge window. I'd like to be prepared for this one... :-) Thanks! 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
[RFC] new qla3xxx NIC Driver v2.02.00k29 (repost)
Reposted with corrected URL. All, Third submission for the upstream inclusion of the qla3xxx Ethernet driver. This is a complementary network driver for our ISP4XXX parts. There is a concurrent effort underway to get the iSCSI driver (qla4xxx) integrated upstream as well. The following files are included and have been posted to the link below: qla3xxxsrc-v2.02.00k29.tgz ftp://ftp.qlogic.com/outgoing/linux/network/upstream/20.02.00k29/ Second submission: http://marc.theaimsgroup.com/?l=linux-netdev&m=114780280407707&w=2 Comments from second submission: http://marc.theaimsgroup.com/?l=linux-netdev&m=114782208808695&w=2 Changes in this release: - Reordered code to remove forward declarations. - Removed typedefs. - Changed inter-driver hardware lock to use wait_event(). - Removed macros defined inside structure definitions. - Removed volatile usage. - Removed wrapper RD_REG_READ/WRITE macros for readl/writel - Bug fix for msi logic. - Removed unused debug print functions. - probe now propagates error codes from api to caller. - Removed internal send queue and lock dependency. Looking forward to any and all feedback. Regards, Ron Mercer Qlogic Corporation - 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] Fixup struct ip_mc_list::multiaddr type
All users except two expect 32-bit big-endian value. One is of
->multiaddr = ->multiaddr
variety. And last one is "%08lX".
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
include/linux/igmp.h |2 +-
net/ipv4/igmp.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -2361,7 +2361,7 @@ static int igmp_mc_seq_show(struct seq_f
}
seq_printf(seq,
- "\t\t\t\t%08lX %5d %d:%08lX\t\t%d\n",
+ "\t\t\t\t%08X %5d %d:%08lX\t\t%d\n",
im->multiaddr, im->users,
im->tm_running, im->tm_running ?
jiffies_to_clock_t(im->timer.expires-jiffies) : 0,
--- a/include/linux/igmp.h
+++ b/include/linux/igmp.h
@@ -169,7 +169,7 @@ struct ip_sf_list
struct ip_mc_list
{
struct in_device*interface;
- unsigned long multiaddr;
+ __be32 multiaddr;
struct ip_sf_list *sources;
struct ip_sf_list *tomb;
unsigned intsfmode;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, 2.6.17-rc4-git10] ieee80211softmac_io.c: fix warning "defined but not used"
On Tue, May 23, 2006 at 03:49:40PM +0200, Toralf Förster wrote:
> Got this compiler warning today and Johannes Berg <[EMAIL PROTECTED]> wrote:
>
> Yeah, known 'bug', we have that code there but never use it. Feel free
> to submit a patch (to John Linville, CC netdev and softmac-dev) to
> remove it.
>
> Signed-off-by: Toralf Foerster <[EMAIL PROTECTED]>
This patch is whitespace-damaged. Please teach your mailer not to
convert tabs to spaces and resubmit.
Thanks!
John
> ---
> linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c.old
> 2006-05-12 09:44:47.0 +0200
> +++
> linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c
> 2006-05-23 15:16:38.0 +0200
> @@ -456,31 +456,3 @@
> return IEEE80211_2ADDR_LEN;
> }
>
> -
> -/* Sends a control packet */
> -static int
> -ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
> - struct ieee80211softmac_network *net, u32 type, u32 arg)
> -{
> - void *pkt = NULL;
> - u32 pkt_size = 0;
--
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
[PATCH] GRE: fixup gre_keymap_lookup() return type
GRE keys are 16-bit wide.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
net/ipv4/netfilter/ip_conntrack_proto_gre.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/net/ipv4/netfilter/ip_conntrack_proto_gre.c
+++ b/net/ipv4/netfilter/ip_conntrack_proto_gre.c
@@ -77,10 +77,10 @@ static inline int gre_key_cmpfn(const st
}
/* look up the source key for a given tuple */
-static u_int32_t gre_keymap_lookup(struct ip_conntrack_tuple *t)
+static __be16 gre_keymap_lookup(struct ip_conntrack_tuple *t)
{
struct ip_ct_gre_keymap *km;
- u_int32_t key = 0;
+ __be16 key = 0;
read_lock_bh(&ip_ct_gre_lock);
km = LIST_FIND(&gre_keymap_list, gre_key_cmpfn,
@@ -190,7 +190,7 @@ static int gre_pkt_to_tuple(const struct
struct ip_conntrack_tuple *tuple)
{
struct gre_hdr_pptp _pgrehdr, *pgrehdr;
- u_int32_t srckey;
+ __be16 srckey;
struct gre_hdr _grehdr, *grehdr;
/* first only delinearize old RFC1701 GRE header */
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
On Fri, 26 May 2006, Paul Moore wrote: > The NetLabel netlink protocol does have a "version" message which can be > used to get the version. My main reason for doing this is not to signal > changes to existing messages, i.e. break backward compatability, but to > signal to user space applications that the kernel supports a newer protocol. > > The printk() above is just informative, if that is your main concern I > can yank it. Yes, please do. Linux kernel subsystems don't have versions, use the main kernel version if you need to. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Netfilter and SMP
> Can somebody provide me with some information on how to configure my > SMP system so that both processors share the network traffic load. You would need multiple active incoming network interfaces. Linux right now doesn't support load balancing from a single interrupt. Even if it did that would likely require hardware support for MSI-X. > My second question was that if there is any known method to gracefully > handle failures in a netfilter module. Currently any failure in > netfilter would cause the kernel panic. Write a user space module using nf queue? -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] network dev.c comment cleanups
Noticed that dev_alloc_name() comment was incorrect, and more spellung errors.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- br.orig/net/core/dev.c
+++ br/net/core/dev.c
@@ -127,7 +127,7 @@
* sure which should go first, but I bet it won't make much
* difference if we are running VLANs. The good news is that
* this protocol won't be in the list unless compiled in, so
- * the average user (w/out VLANs) will not be adversly affected.
+ * the average user (w/out VLANs) will not be adversely affected.
* --BLG
*
* 0800IP
@@ -149,7 +149,7 @@ static struct list_head ptype_base[16];
static struct list_head ptype_all; /* Taps */
/*
- * The @dev_base list is protected by @dev_base_lock and the rtln
+ * The @dev_base list is protected by @dev_base_lock and the rtnl
* semaphore.
*
* Pure readers hold dev_base_lock for reading.
@@ -641,10 +641,12 @@ int dev_valid_name(const char *name)
* @name: name format string
*
* Passed a format string - eg "lt%d" it will try and find a suitable
- * id. Not efficient for many devices, not called a lot. The caller
- * must hold the dev_base or rtnl lock while allocating the name and
- * adding the device in order to avoid duplicates. Returns the number
- * of the unit assigned or a negative errno code.
+ * id. It scans list of devices to build up a free map, then chooses
+ * the first empty slot. The caller must hold the dev_base or rtnl lock
+ * while allocating the name and adding the device in order to avoid
+ * duplicates.
+ * Limited to bits_per_byte * page size devices (ie 32K on most platforms).
+ * Returns the number of the unit assigned or a negative errno code.
*/
int dev_alloc_name(struct net_device *dev, const char *name)
@@ -744,7 +746,7 @@ int dev_change_name(struct net_device *d
}
/**
- * netdev_features_change - device changes fatures
+ * netdev_features_change - device changes features
* @dev: device to cause notification
*
* Called to indicate a device has changed features.
@@ -2196,7 +2198,7 @@ int netdev_set_master(struct net_device
* @dev: device
* @inc: modifier
*
- * Add or remove promsicuity from a device. While the count in the device
+ * Add or remove promiscuity from a device. While the count in the device
* remains above zero the interface remains promiscuous. Once it hits zero
* the device reverts back to normal filtering operation. A negative inc
* value is used to drop promiscuity on the device.
@@ -3122,7 +3124,7 @@ EXPORT_SYMBOL(alloc_netdev);
void free_netdev(struct net_device *dev)
{
#ifdef CONFIG_SYSFS
- /* Compatiablity with error handling in drivers */
+ /* Compatibility with error handling in drivers */
if (dev->reg_state == NETREG_UNINITIALIZED) {
kfree((char *)dev - dev->padded);
return;
-
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 7/9] ixgb: replace netdev->priv with netdev_priv()
fix netdev->priv ==> netdev_priv(netdev)
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_ethtool.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
index 6d8192f..949f69d 100644
--- a/drivers/net/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ixgb/ixgb_ethtool.c
@@ -254,14 +254,14 @@ ixgb_set_tso(struct net_device *netdev,
static uint32_t
ixgb_get_msglevel(struct net_device *netdev)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
return adapter->msg_enable;
}
static void
ixgb_set_msglevel(struct net_device *netdev, uint32_t data)
{
- struct ixgb_adapter *adapter = netdev->priv;
+ struct ixgb_adapter *adapter = netdev_priv(netdev);
adapter->msg_enable = data;
}
#define IXGB_GET_STAT(_A_, _R_) _A_->stats._R_
--
Auke Kok <[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
[PATCH 9/9] ixgb: update version, dates
increase the year dates to 2006 and bump the version to 1.0.109-k2 Signed-off-by: Auke Kok <[EMAIL PROTECTED]> Signed-off-by: John Ronciak <[EMAIL PROTECTED]> --- drivers/net/ixgb/Makefile |2 +- drivers/net/ixgb/ixgb.h |2 +- drivers/net/ixgb/ixgb_ee.c |2 +- drivers/net/ixgb/ixgb_ee.h |2 +- drivers/net/ixgb/ixgb_ethtool.c |2 +- drivers/net/ixgb/ixgb_hw.c |2 +- drivers/net/ixgb/ixgb_hw.h |2 +- drivers/net/ixgb/ixgb_ids.h |2 +- drivers/net/ixgb/ixgb_main.c|6 +++--- drivers/net/ixgb/ixgb_osdep.h |2 +- drivers/net/ixgb/ixgb_param.c |2 +- 11 files changed, 13 insertions(+), 13 deletions(-) diff --git a/drivers/net/ixgb/Makefile b/drivers/net/ixgb/Makefile index 7c7aff1..a8a2d3d 100644 --- a/drivers/net/ixgb/Makefile +++ b/drivers/net/ixgb/Makefile @@ -1,7 +1,7 @@ # # -# Copyright(c) 1999 - 2002 Intel Corporation. All rights reserved. +# Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved. # # This program is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by the Free diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h index bdbaf5a..a83ef28 100644 --- a/drivers/net/ixgb/ixgb.h +++ b/drivers/net/ixgb/ixgb.h @@ -1,7 +1,7 @@ /*** - Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff --git a/drivers/net/ixgb/ixgb_ee.c b/drivers/net/ixgb/ixgb_ee.c index 661a46b..8357c55 100644 --- a/drivers/net/ixgb/ixgb_ee.c +++ b/drivers/net/ixgb/ixgb_ee.c @@ -1,7 +1,7 @@ /*** - Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff --git a/drivers/net/ixgb/ixgb_ee.h b/drivers/net/ixgb/ixgb_ee.h index 5190aa8..bf6fa22 100644 --- a/drivers/net/ixgb/ixgb_ee.h +++ b/drivers/net/ixgb/ixgb_ee.h @@ -1,7 +1,7 @@ /*** - Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c index 949f69d..cf19b89 100644 --- a/drivers/net/ixgb/ixgb_ethtool.c +++ b/drivers/net/ixgb/ixgb_ethtool.c @@ -1,7 +1,7 @@ /*** - Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff --git a/drivers/net/ixgb/ixgb_hw.c b/drivers/net/ixgb/ixgb_hw.c index 620cad4..f7fa10e 100644 --- a/drivers/net/ixgb/ixgb_hw.c +++ b/drivers/net/ixgb/ixgb_hw.c @@ -1,7 +1,7 @@ /*** - Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff --git a/drivers/net/ixgb/ixgb_hw.h b/drivers/net/ixgb/ixgb_hw.h index 19513c6..cb45689 100644 --- a/drivers/net/ixgb/ixgb_hw.h +++ b/drivers/net/ixgb/ixgb_hw.h @@ -1,7 +1,7 @@ /*** - Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2006 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free diff --git a/drivers/net/ixgb/ixgb_ids.h b/drivers/net/ixgb/ixgb_ids.h index e119c05..40a085f 100644 --- a/drivers/net/ixgb/ixgb_ids.h +++ b/drivers/net/ixgb/ixgb_ids.h @@ -1,7 +1,7 @@ /*** - Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
[PATCH 5/9] ixgb: remove lock access in the fast path
This mimics a change made in the e1000 driver that imitates a slick
tg3 way of avoiding grabbing the lock around restarting the tx queue.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_main.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index b825850..a714c4d 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -1800,13 +1800,13 @@ ixgb_clean_tx_irq(struct ixgb_adapter *a
tx_ring->next_to_clean = i;
- spin_lock(&adapter->tx_lock);
- if(cleaned && netif_queue_stopped(netdev) && netif_carrier_ok(netdev) &&
- (IXGB_DESC_UNUSED(tx_ring) > IXGB_TX_QUEUE_WAKE)) {
-
- netif_wake_queue(netdev);
+ if (unlikely(netif_queue_stopped(netdev))) {
+ spin_lock(&adapter->tx_lock);
+ if (netif_queue_stopped(netdev) && netif_carrier_ok(netdev) &&
+ (IXGB_DESC_UNUSED(tx_ring) > IXGB_TX_QUEUE_WAKE))
+ netif_wake_queue(netdev);
+ spin_unlock(&adapter->tx_lock);
}
- spin_unlock(&adapter->tx_lock);
if(adapter->detect_tx_hung) {
/* detect a transmit hang in hardware, this serializes the
--
Auke Kok <[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
[PATCH 2/9] ixgb: fix interface losing macaddr on ifdn/up
user contributed fix for LAA across down/up, from [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> Signed-off-by: John Ronciak <[EMAIL PROTECTED]> --- drivers/net/ixgb/ixgb_main.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c index 954894b..26c777f 100644 --- a/drivers/net/ixgb/ixgb_main.c +++ b/drivers/net/ixgb/ixgb_main.c @@ -238,6 +238,7 @@ ixgb_up(struct ixgb_adapter *adapter) /* hardware has been reset, we need to reload some things */ + ixgb_rar_set(hw, netdev->dev_addr, 0); ixgb_set_multi(netdev); ixgb_restore_vlan(adapter); -- Auke Kok <[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
[PATCH 8/9] ixgb: remove changelog
same as e1000 - remove the changelog from the driver code itself.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_main.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 037b5c3..aecdc00 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -28,22 +28,6 @@
#include "ixgb.h"
-/* Change Log
- * 1.0.96 04/19/05
- * - Make needlessly global code static -- [EMAIL PROTECTED]
- * - ethtool cleanup -- [EMAIL PROTECTED]
- * - Support for MODULE_VERSION -- [EMAIL PROTECTED]
- * - add skb_header_cloned check to the tso path -- [EMAIL PROTECTED]
- * 1.0.88 01/05/05
- * - include fix to the condition that determines when to quit NAPI - Robert
Olsson
- * - use netif_poll_{disable/enable} to synchronize between NAPI and i/f
up/down
- * 1.0.84 10/26/04
- * - reset buffer_info->dma in Tx resource cleanup logic
- * 1.0.83 10/12/04
- * - sparse cleanup - [EMAIL PROTECTED]
- * - fix tx resource cleanup logic
- */
-
char ixgb_driver_name[] = "ixgb";
static char ixgb_driver_string[] = "Intel(R) PRO/10GbE Network Driver";
--
Auke Kok <[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
[PATCH 6/9] ixgb: remove inlines, allow compiler to choose
deinline a few large functions as to allow the compiler to pick.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_main.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index a714c4d..037b5c3 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -203,7 +203,7 @@ module_exit(ixgb_exit_module);
* @adapter: board private structure
**/
-static inline void
+static void
ixgb_irq_disable(struct ixgb_adapter *adapter)
{
atomic_inc(&adapter->irq_sem);
@@ -217,7 +217,7 @@ ixgb_irq_disable(struct ixgb_adapter *ad
* @adapter: board private structure
**/
-static inline void
+static void
ixgb_irq_enable(struct ixgb_adapter *adapter)
{
if(atomic_dec_and_test(&adapter->irq_sem)) {
@@ -918,7 +918,7 @@ ixgb_free_tx_resources(struct ixgb_adapt
adapter->tx_ring.desc = NULL;
}
-static inline void
+static void
ixgb_unmap_and_free_tx_resource(struct ixgb_adapter *adapter,
struct ixgb_buffer *buffer_info)
{
@@ -1179,7 +1179,7 @@ ixgb_watchdog(unsigned long data)
#define IXGB_TX_FLAGS_VLAN 0x0002
#define IXGB_TX_FLAGS_TSO 0x0004
-static inline int
+static int
ixgb_tso(struct ixgb_adapter *adapter, struct sk_buff *skb)
{
#ifdef NETIF_F_TSO
@@ -1241,7 +1241,7 @@ ixgb_tso(struct ixgb_adapter *adapter, s
return 0;
}
-static inline boolean_t
+static boolean_t
ixgb_tx_csum(struct ixgb_adapter *adapter, struct sk_buff *skb)
{
struct ixgb_context_desc *context_desc;
@@ -1279,7 +1279,7 @@ ixgb_tx_csum(struct ixgb_adapter *adapte
#define IXGB_MAX_TXD_PWR 14
#define IXGB_MAX_DATA_PER_TXD (1
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] ixgb: driver update to 1.0.109-k2
Hi, Here are the ixgb driver updates for 1.0.109-k2. This corresponds with the release of 1.0.109 on e1000.sf.net, and fixes several issues. e1000 update will come soon... Summary: [1] fix smp polling race condition [2] fix interface losing macaddr on ifdn/up [3] revert an unwanted fix regarding tso/descriptors [4] allocate only buffersize needed [5] remove lock access in the fast path [6] remove inlines, allow compiler to choose [7] replace netdev->priv with netdev_priv() [8] remove changelog [9] update version, dates These changes are available through git. git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 ixgb-1.0.109-k2 these patches are against netdev-2.6#upstream a24e2513c2d03c9a92739ec6fa7e7208f792881e Cheers, Auke --- drivers/net/ixgb/Makefile |2 - drivers/net/ixgb/ixgb.h |2 - drivers/net/ixgb/ixgb_ee.c |2 - drivers/net/ixgb/ixgb_ee.h |2 - drivers/net/ixgb/ixgb_ethtool.c |6 +- drivers/net/ixgb/ixgb_hw.c |2 - drivers/net/ixgb/ixgb_hw.h |2 - drivers/net/ixgb/ixgb_ids.h |2 - drivers/net/ixgb/ixgb_main.c| 110 +++ drivers/net/ixgb/ixgb_osdep.h |2 - drivers/net/ixgb/ixgb_param.c |2 - 11 files changed, 43 insertions(+), 91 deletions(-) -- Auke Kok <[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
[PATCH 1/9] ixgb: fix smp polling race condition
Moved interrupt masking to before requesting the interrupt from the OS.
Moved interrupt enable to after netif_poll_enable. This fixes a racy
BUG() where polling would be running on another CPU at the same time
that netif_poll_enable would run.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_main.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 0a0c876..954894b 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -247,6 +247,9 @@ ixgb_up(struct ixgb_adapter *adapter)
ixgb_configure_rx(adapter);
ixgb_alloc_rx_buffers(adapter);
+ /* disable interrupts and get the hardware into a known state */
+ IXGB_WRITE_REG(&adapter->hw, IMC, 0x);
+
#ifdef CONFIG_PCI_MSI
{
boolean_t pcix = (IXGB_READ_REG(&adapter->hw, STATUS) &
@@ -272,9 +275,6 @@ ixgb_up(struct ixgb_adapter *adapter)
return err;
}
- /* disable interrupts and get the hardware into a known state */
- IXGB_WRITE_REG(&adapter->hw, IMC, 0x);
-
if((hw->max_frame_size != max_frame) ||
(hw->max_frame_size !=
(IXGB_READ_REG(hw, MFS) >> IXGB_MFS_SHIFT))) {
@@ -295,11 +295,12 @@ ixgb_up(struct ixgb_adapter *adapter)
}
mod_timer(&adapter->watchdog_timer, jiffies);
- ixgb_irq_enable(adapter);
#ifdef CONFIG_IXGB_NAPI
netif_poll_enable(netdev);
#endif
+ ixgb_irq_enable(adapter);
+
return 0;
}
--
Auke Kok <[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
[PATCH 3/9] ixgb: revert an unwanted fix regarding tso/descriptors
There seemed to be another bug introduced as well as a performance hit
with the addtion of the sentinel descriptor workaround. Removal of
this workaround appears to prevent the hang. We'll take a risk
and remove it, as we had never seen the originally reported bug
under linux.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_main.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 26c777f..5561ab6 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -1295,7 +1295,6 @@ ixgb_tx_map(struct ixgb_adapter *adapter
struct ixgb_buffer *buffer_info;
int len = skb->len;
unsigned int offset = 0, size, count = 0, i;
- unsigned int mss = skb_shinfo(skb)->tso_size;
unsigned int nr_frags = skb_shinfo(skb)->nr_frags;
unsigned int f;
@@ -1307,11 +1306,6 @@ ixgb_tx_map(struct ixgb_adapter *adapter
while(len) {
buffer_info = &tx_ring->buffer_info[i];
size = min(len, IXGB_MAX_JUMBO_FRAME_SIZE);
- /* Workaround for premature desc write-backs
-* in TSO mode. Append 4-byte sentinel desc */
- if(unlikely(mss && !nr_frags && size == len && size > 8))
- size -= 4;
-
buffer_info->length = size;
buffer_info->dma =
pci_map_single(adapter->pdev,
@@ -1337,12 +1331,6 @@ ixgb_tx_map(struct ixgb_adapter *adapter
while(len) {
buffer_info = &tx_ring->buffer_info[i];
size = min(len, IXGB_MAX_JUMBO_FRAME_SIZE);
- /* Workaround for premature desc write-backs
-* in TSO mode. Append 4-byte sentinel desc */
- if(unlikely(mss && (f == (nr_frags-1)) && (size == len)
- && (size > 8)))
- size -= 4;
-
buffer_info->length = size;
buffer_info->dma =
pci_map_page(adapter->pdev,
@@ -1421,8 +1409,7 @@ ixgb_tx_queue(struct ixgb_adapter *adapt
#define TXD_USE_COUNT(S) (((S) >> IXGB_MAX_TXD_PWR) + \
(((S) & (IXGB_MAX_DATA_PER_TXD - 1)) ? 1 : 0))
#define DESC_NEEDED TXD_USE_COUNT(IXGB_MAX_DATA_PER_TXD) + \
- MAX_SKB_FRAGS * TXD_USE_COUNT(PAGE_SIZE) + 1 \
- /* one more for TSO workaround */ + 1
+ MAX_SKB_FRAGS * TXD_USE_COUNT(PAGE_SIZE) + 1
static int
ixgb_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
--
Auke Kok <[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
[PATCH 4/9] ixgb: allocate only buffersize needed
In order to help correct window size growth, use the MFS register
to limit the packet sizes received and allocate only the buffer
size necessary
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
index 0905a82..84a8064 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -574,9 +574,8 @@ ixgb_sw_init(struct ixgb_adapter *adapte
hw->subsystem_vendor_id = pdev->subsystem_vendor;
hw->subsystem_id = pdev->subsystem_device;
- adapter->rx_buffer_len = IXGB_RXBUFFER_2048;
-
hw->max_frame_size = netdev->mtu + ENET_HEADER_SIZE + ENET_FCS_LENGTH;
+ adapter->rx_buffer_len = hw->max_frame_size;
if((hw->device_id == IXGB_DEVICE_ID_82597EX)
|| (hw->device_id == IXGB_DEVICE_ID_82597EX_CX4)
@@ -820,21 +819,14 @@ ixgb_setup_rctl(struct ixgb_adapter *ada
rctl |= IXGB_RCTL_SECRC;
- switch (adapter->rx_buffer_len) {
- case IXGB_RXBUFFER_2048:
- default:
+ if (adapter->rx_buffer_len <= IXGB_RXBUFFER_2048)
rctl |= IXGB_RCTL_BSIZE_2048;
- break;
- case IXGB_RXBUFFER_4096:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_4096)
rctl |= IXGB_RCTL_BSIZE_4096;
- break;
- case IXGB_RXBUFFER_8192:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_8192)
rctl |= IXGB_RCTL_BSIZE_8192;
- break;
- case IXGB_RXBUFFER_16384:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_16384)
rctl |= IXGB_RCTL_BSIZE_16384;
- break;
- }
IXGB_WRITE_REG(&adapter->hw, RCTL, rctl);
}
@@ -1551,25 +1543,12 @@ ixgb_change_mtu(struct net_device *netde
DPRINTK(PROBE, ERR, "Invalid MTU setting %d\n", new_mtu);
return -EINVAL;
}
-
- if((max_frame <= IXGB_MAX_ENET_FRAME_SIZE_WITHOUT_FCS + ENET_FCS_LENGTH)
- || (max_frame <= IXGB_RXBUFFER_2048)) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_2048;
-
- } else if(max_frame <= IXGB_RXBUFFER_4096) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_4096;
- } else if(max_frame <= IXGB_RXBUFFER_8192) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_8192;
+ adapter->rx_buffer_len = max_frame;
- } else {
- adapter->rx_buffer_len = IXGB_RXBUFFER_16384;
- }
-
netdev->mtu = new_mtu;
-
- if(old_max_frame != max_frame && netif_running(netdev)) {
+ if ((old_max_frame != max_frame) && netif_running(netdev)) {
ixgb_down(adapter, TRUE);
ixgb_up(adapter);
}
---
drivers/net/ixgb/ixgb_main.c | 35 +++
1 files changed, 7 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 5561ab6..b825850 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -576,9 +576,8 @@ ixgb_sw_init(struct ixgb_adapter *adapte
hw->subsystem_vendor_id = pdev->subsystem_vendor;
hw->subsystem_id = pdev->subsystem_device;
- adapter->rx_buffer_len = IXGB_RXBUFFER_2048;
-
hw->max_frame_size = netdev->mtu + ENET_HEADER_SIZE + ENET_FCS_LENGTH;
+ adapter->rx_buffer_len = hw->max_frame_size;
if((hw->device_id == IXGB_DEVICE_ID_82597EX)
|| (hw->device_id == IXGB_DEVICE_ID_82597EX_CX4)
@@ -822,21 +821,14 @@ ixgb_setup_rctl(struct ixgb_adapter *ada
rctl |= IXGB_RCTL_SECRC;
- switch (adapter->rx_buffer_len) {
- case IXGB_RXBUFFER_2048:
- default:
+ if (adapter->rx_buffer_len <= IXGB_RXBUFFER_2048)
rctl |= IXGB_RCTL_BSIZE_2048;
- break;
- case IXGB_RXBUFFER_4096:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_4096)
rctl |= IXGB_RCTL_BSIZE_4096;
- break;
- case IXGB_RXBUFFER_8192:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_8192)
rctl |= IXGB_RCTL_BSIZE_8192;
- break;
- case IXGB_RXBUFFER_16384:
+ else if (adapter->rx_buffer_len <= IXGB_RXBUFFER_16384)
rctl |= IXGB_RCTL_BSIZE_16384;
- break;
- }
IXGB_WRITE_REG(&adapter->hw, RCTL, rctl);
}
@@ -1546,24 +1538,11 @@ ixgb_change_mtu(struct net_device *netde
return -EINVAL;
}
- if((max_frame <= IXGB_MAX_ENET_FRAME_SIZE_WITHOUT_FCS + ENET_FCS_LENGTH)
- || (max_frame <= IXGB_RXBUFFER_2048)) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_2048;
-
- } else if(max_frame <= IXGB_RXBUFFER_4096) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_4096;
-
- } else if(max_frame <= IXGB_RXBUFFER_8192) {
- adapter->rx_buffer_len = IXGB_RXBUFFER_8192;
-
- } else {
- adapter->rx_buffer_len = IXGB_
Re: [RFC 0/4] NetLabel
James Morris wrote: > On Fri, 26 May 2006, Paul Moore wrote: >>>- Why does this module have a version number? >>> >>>+ printk(KERN_INFO "NetLabel: Initializing (v%s %s)\n", >>>+ NETLBL_VER_STR, NETLBL_VER_DATE); >>> >> >>The version number is there primarily to help signal possible >>differences in the NetLabel netlink protocol. > > How will this ever help anything? > > If you change that protocol, userspace applications will break, which is > not acceptable. You can add versioning at the protocol level or via > adding a new netlink family in the future, but existing apps cannot break > and you need to maintain compatibility. > The NetLabel netlink protocol does have a "version" message which can be used to get the version. My main reason for doing this is not to signal changes to existing messages, i.e. break backward compatability, but to signal to user space applications that the kernel supports a newer protocol. The printk() above is just informative, if that is your main concern I can yank it. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
Same issue, I would drop them. Paul Moore wrote: Mikel L. Matthews wrote: Paul Moore wrote: James Morris wrote: Outgoing fragment *should* be labeled correctly assuming the Linux base network stack does the right thing (I haven't tested this yet). The issue we are discussing here is what to do about incoming packets where the fragments are not consistently labeled. -- Thanks, Mike Mikel L. Matthews Chief Technology Officer Innovative Security Systems, Inc. (dba Argus Systems Group) 1809 Woodfield Dr. Savoy IL 61874 +1-217-355-6308 www.argus-systems.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: [RFC 0/4] NetLabel
Mikel L. Matthews wrote: > Paul Moore wrote: >>James Morris wrote: >>>On Thu, 25 May 2006, Paul Moore wrote: >>> This patch introduces a new kernel feature designed to support labeled networking protocols such as RIPSO and CIPSO. These protocols are required to interoperate with existing "trusted" operating systems such as Trusted Solaris. >>> >>>A few initial comments. >>> >>>- Did you decide that you definitely need to verify labels on fragments? >>> >>>I can see the code's been added to do that, but wonder about a comment >>>made during earlier discussion that mislabeled fragments could only come >>>from a misbehaving trusted system. What is the threat model here? >>> >> >>This is one part of the patch that I really don't have a strong feeling >>for either way. There was some concern on the LSM list that not >>checking the fragment options might be an issue so I added some code to >>check the fragment options. Personally I think we are probably okay >>without it as the un-autenticated/un-verified nature of these labeling >>protocols more or less requires either a trusted network/hosts. >> >>If the community decides that this check is not required then I can >>simply drop all of the changes in ip_fragment.c. > > If you state you are labeling session packets (tcp or udp), that would > lead one to believe all packets are labeled (including fragments). Based > on our past evaluations I don't think non-labeled fragments would make > it through an evaluation if CIPSO/RIPSO were part of the TOE/security > Target. > Outgoing fragment *should* be labeled correctly assuming the Linux base network stack does the right thing (I haven't tested this yet). The issue we are discussing here is what to do about incoming packets where the fragments are not consistently labeled. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] Resending NetXen 1G/10G NIC driver patch
You might also want to add support for setting dev->perm_addr and using ethtool_op_get_perm_addr() in ethtool_ops - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
Paul Moore wrote: James Morris wrote: On Thu, 25 May 2006, Paul Moore wrote: This patch introduces a new kernel feature designed to support labeled networking protocols such as RIPSO and CIPSO. These protocols are required to interoperate with existing "trusted" operating systems such as Trusted Solaris. A few initial comments. - Did you decide that you definitely need to verify labels on fragments? I can see the code's been added to do that, but wonder about a comment made during earlier discussion that mislabeled fragments could only come from a misbehaving trusted system. What is the threat model here? This is one part of the patch that I really don't have a strong feeling for either way. There was some concern on the LSM list that not checking the fragment options might be an issue so I added some code to check the fragment options. Personally I think we are probably okay without it as the un-autenticated/un-verified nature of these labeling protocols more or less requires either a trusted network/hosts. If the community decides that this check is not required then I can simply drop all of the changes in ip_fragment.c. If you state you are labeling session packets (tcp or udp), that would lead one to believe all packets are labeled (including fragments). Based on our past evaluations I don't think non-labeled fragments would make it through an evaluation if CIPSO/RIPSO were part of the TOE/security Target. - Can you explain how module loading and module refcounting for these modules work? (e.g. what causes netlabel_cipso_v4 to be loaded, is it always safe to unload if the refcount is zero?) -- Thanks, Mike Mikel L. Matthews Chief Technology Officer Innovative Security Systems, Inc. (dba Argus Systems Group) 1809 Woodfield Dr. Savoy IL 61874 +1-217-355-6308 www.argus-systems.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: [RFC 0/4] NetLabel
On Fri, 26 May 2006, Paul Moore wrote: > There may be an issue with packets generated by the kernel directly and > not as a result of an incoming packet but I can't think of a case where > this would happen (although I suspect I am just not thinking hard > enough). Do you have a scenario in mind? There are several possibilities, I believe. The networking code would need to be audited to find them all. > Okay. I suspect this code will go away, but just for my own education > were you thinking of something like this? > > static inline int my_func(void) > #ifdef CONFIG_NETLABEL_CIPSOV4 > /* real stuff */ > #else > /* compile away into a zero */ > return 0; > #endif > } > > ... or something else? No. You put the real function in a .c file and the dummy inline in a .h file. There are many examples of this in the kernel. > > - Why does this module have a version number? > > > > + printk(KERN_INFO "NetLabel: Initializing (v%s %s)\n", > > + NETLBL_VER_STR, NETLBL_VER_DATE); > > > > The version number is there primarily to help signal possible > differences in the NetLabel netlink protocol. How will this ever help anything? If you change that protocol, userspace applications will break, which is not acceptable. You can add versioning at the protocol level or via adding a new netlink family in the future, but existing apps cannot break and you need to maintain compatibility. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] NetLabel
James Morris wrote:
> On Thu, 25 May 2006, Paul Moore wrote:
>>This patch introduces a new kernel feature designed to support labeled
>>networking protocols such as RIPSO and CIPSO. These protocols are required to
>>interoperate with existing "trusted" operating systems such as Trusted
>>Solaris.
>
> A few initial comments.
>
> - Did you decide that you definitely need to verify labels on fragments?
>
> I can see the code's been added to do that, but wonder about a comment
> made during earlier discussion that mislabeled fragments could only come
> from a misbehaving trusted system. What is the threat model here?
>
This is one part of the patch that I really don't have a strong feeling
for either way. There was some concern on the LSM list that not
checking the fragment options might be an issue so I added some code to
check the fragment options. Personally I think we are probably okay
without it as the un-autenticated/un-verified nature of these labeling
protocols more or less requires either a trusted network/hosts.
If the community decides that this check is not required then I can
simply drop all of the changes in ip_fragment.c.
> - Can you explain how module loading and module refcounting for these
> modules work? (e.g. what causes netlabel_cipso_v4 to be loaded, is it
> always safe to unload if the refcount is zero?)
Heh, not really :)
This is part of the "not ready for submission" qualifier I mentioned at
the top of my post. Honestly I'm not sure it makes sense to have this
code as a loadable module anyway I just used some of the module bits as
it was the first example of code that I saw in the kernel which would
call init/exit functions.
If people think that this code should be made into a fully
loadable/unloadable module then there is definitely more work to be done
in this area as I really haven't looked into it too deeply. However, if
people are okay with it not being a module then I will find a proper way
of doing initialization without using the module bits.
Sorry for the confusion, I forgot to mention it earlier.
> - What about user APIs for setting and retrieving labels?
The NetLabel mechanism supports getting the labels off of a packet
directly or from the top most packet on the incoming socket queue. I
have left it up to the LSM to decide how to expose that functionality to
the user. In SELinux this is done by using the SO_PEERSEC option
similar to how you would do it if you were using the IPsec SA labeling.
It works by looking at the top most packet in the socket receive queue
for TCP and at the packet itself for UDP.
You can set/reset the label by calling the NetLabel function to set the
label of a socket; right now the label of outgoing packets is tightly
tied to the label of the socket from which they were sent. The NetLabel
code does support changing the label of a socket but I have not added
the code to SELinux to support that because I am not clear that is a
good thing to do from a SELinux point of view, currently the label is
set when the socket is created. However, should people decide this is a
good thing, one possibility would be to enable the SO_PEERSEC option for
setsockopt().
> - What about labeling of kernel-generated packets?
Kernel generated packets which are created in response to an incoming
packet, i.e. ICMP errors, get the label of the packet which caused the
response. This seems to be correct from the draft's point of view as
well as several people on the LSM list.
There may be an issue with packets generated by the kernel directly and
not as a result of an incoming packet but I can't think of a case where
this would happen (although I suspect I am just not thinking hard
enough). Do you have a scenario in mind?
> - Don't put #ifdef'd code into mainline code.
>
> e.g. in net/ipv4/ip_fragment.c
>
> +#ifdef CONFIG_NETLABEL_CIPSOV4
> + if (sopt->cipso) {
>
> This needs to be a function which is compiled away as a static inline when
> not selected. This stuff should have zero impact on the networking code
> if not enabled.
Okay. I suspect this code will go away, but just for my own education
were you thinking of something like this?
static inline int my_func(void)
#ifdef CONFIG_NETLABEL_CIPSOV4
/* real stuff */
#else
/* compile away into a zero */
return 0;
#endif
}
... or something else?
> - Try and add entries for security/selinux/nlmsgtab.c for the new Netlink
> protocol.
>
> - This does not follow normal kernel coding practices:
>
> {snip}
>
> - This kind of stuff should be removed before merging:
>
> {snip}
>
Okay.
> - Why does this module have a version number?
>
> + printk(KERN_INFO "NetLabel: Initializing (v%s %s)\n",
> + NETLBL_VER_STR, NETLBL_VER_DATE);
>
The version number is there primarily to help signal possible
differences in the NetLabel netlink protocol.
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe n
Netfilter and SMP
Hi, I am developing a netfilter based application on an SMP (AMD 64;dual core) system (kernel 2.6). One thing that I noticed over a period of time was that most of the network traffic was handled by only one of the processor. Only under high network traffic (roughly 10,000 packet/sec or more) did the second processor got invloved invloved in traffic handling. Even then more than 90 percent of the traffic was being handled by one of the processor. Can somebody provide me with some information on how to configure my SMP system so that both processors share the network traffic load. My second question was that if there is any known method to gracefully handle failures in a netfilter module. Currently any failure in netfilter would cause the kernel panic. Regards, Majid - 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: skge driver oops
Please give this a try, it rearranges the transmit buffer management,
and may avoid issues with partial completions causing SKB reuse.
--- skge.orig/drivers/net/skge.c
+++ skge/drivers/net/skge.c
@@ -2372,7 +2372,8 @@ static int skge_xmit_frame(struct sk_buf
frag->size, PCI_DMA_TODEVICE);
e = e->next;
- e->skb = NULL;
+ e->skb = skb;
+
tf = e->desc;
tf->dma_lo = map;
tf->dma_hi = (u64) map >> 32;
@@ -2408,36 +2409,42 @@ static int skge_xmit_frame(struct sk_buf
return NETDEV_TX_OK;
}
-static void skge_tx_complete(struct skge_port *skge, struct skge_element *last)
+
+static void skge_tx_done(struct skge_port *skge, struct skge_element *e)
{
struct pci_dev *pdev = skge->hw->pdev;
- struct skge_element *e;
+ const struct skge_tx_desc *td = e->desc;
- for (e = skge->tx_ring.to_clean; e != last; e = e->next) {
- struct sk_buff *skb = e->skb;
- int i;
-
- e->skb = NULL;
+ /* skb header vs. fragment */
+ if (td->control & BMU_STF)
pci_unmap_single(pdev, pci_unmap_addr(e, mapaddr),
-skb_headlen(skb), PCI_DMA_TODEVICE);
+pci_unmap_len(e, maplen),
+PCI_DMA_TODEVICE);
+ else
+ pci_unmap_page(pdev, pci_unmap_addr(e, mapaddr),
+ pci_unmap_len(e, maplen),
+ PCI_DMA_TODEVICE);
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
- e = e->next;
- pci_unmap_page(pdev, pci_unmap_addr(e, mapaddr),
- skb_shinfo(skb)->frags[i].size,
- PCI_DMA_TODEVICE);
- }
+ if (td->control & BMU_EOF) {
+ if (unlikely(netif_msg_tx_done(skge)))
+ printk(KERN_DEBUG PFX "%s: tx done slot %td\n",
+ skge->netdev->name, e - skge->tx_ring.start);
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(e->skb);
}
- skge->tx_ring.to_clean = e;
+ e->skb = NULL;
}
+/* Free all buffers in transmit ring */
static void skge_tx_clean(struct skge_port *skge)
{
+ struct skge_element *e;
spin_lock_bh(&skge->tx_lock);
- skge_tx_complete(skge, skge->tx_ring.to_use);
+ for (e = skge->tx_ring.to_clean; e != skge->tx_ring.to_use; e = e->next)
+ skge_tx_done(skge, e);
+
+ skge->tx_ring.to_clean = e;
netif_wake_queue(skge->netdev);
spin_unlock_bh(&skge->tx_lock);
}
@@ -2665,30 +2672,24 @@ resubmit:
return NULL;
}
-static void skge_tx_done(struct skge_port *skge)
+/* Free all buffers in Tx ring which are no longer owned by device */
+static void skge_tx_complete(struct skge_port *skge)
{
struct skge_ring *ring = &skge->tx_ring;
- struct skge_element *e, *last;
+ struct skge_element *e;
spin_lock(&skge->tx_lock);
- last = ring->to_clean;
+ skge_write8(skge->hw, Q_ADDR(txqaddr[skge->port], Q_CSR), CSR_IRQ_CL_F);
+
for (e = ring->to_clean; e != ring->to_use; e = e->next) {
struct skge_tx_desc *td = e->desc;
if (td->control & BMU_OWN)
break;
- if (td->control & BMU_EOF) {
- last = e->next;
- if (unlikely(netif_msg_tx_done(skge)))
- printk(KERN_DEBUG PFX "%s: tx done slot %td\n",
- skge->netdev->name, e - ring->start);
- }
+ skge_tx_done(skge, e);
}
-
- skge_tx_complete(skge, last);
-
- skge_write8(skge->hw, Q_ADDR(txqaddr[skge->port], Q_CSR), CSR_IRQ_CL_F);
+ skge->tx_ring.to_clean = e;
if (skge_avail(&skge->tx_ring) > TX_LOW_WATER)
netif_wake_queue(skge->netdev);
@@ -2705,7 +2706,7 @@ static int skge_poll(struct net_device *
int to_do = min(dev->quota, *budget);
int work_done = 0;
- skge_tx_done(skge);
+ skge_tx_complete(skge);
for (e = ring->to_clean; prefetch(e->next), work_done < to_do; e =
e->next) {
struct skge_rx_desc *rd = e->desc;
-
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/9] Resending NetXen 1G/10G NIC driver patch
On Fri, 26 May 2006 14:14:32 +
Pradeep Dalvi <[EMAIL PROTECTED]> wrote:
> Following are the minor changes for [PATCH 1/9] in accordance with the
> given suggestions.
>
> Regards,
> pradeep
>
> diff -u linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
> linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
> --- linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
> 2006-05-25 02:43:22.0 -0700
> +++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
> 2006-05-26 04:05:34.0 -0700
> @@ -145,7 +145,7 @@
>
> ecmd->port = PORT_TP;
>
> - if (port->state) {
> + if (dev->flags & IFF_UP) {
if (netif_running(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
Re: [PATCH 9/9] Resending NetXen 1G/10G NIC driver patch
diff -u linux-2.6.16.18/drivers/net/netxen/netxen_nic_niu.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_niu.c
--- linux-2.6.16.18/drivers/net/netxen/netxen_nic_niu.c 2006-05-25
02:43:22.0 -0700
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_niu.c 2006-05-26
04:05:34.0 -0700
@@ -34,22 +34,6 @@
#include "netxen_nic.h"
#include
-void netxen_delay(int value)
-{
- unsigned long remainder;
-
- remainder = value / 5;
- do {
- if (remainder > 1000) {
- udelay(1000);
- remainder -= 1000;
- } else {
- udelay(remainder + 1);
- remainder = 0;
- }
- } while (remainder > 0);
-}
-
/**
* netxen_niu_gbe_phy_read - read a register from the GbE PHY via
* mii management interface.
@@ -78,7 +62,7 @@
/* MII mgmt all goes through port 0 MAC interface, so it cannot
be in reset */
if (netxen_nic_hw_read_wx(adapter, NETXEN_NIU_GB_MAC_CONFIG_0
(0),
&mac_cfg0, 4))
- return -1;
+ return -EIO;
if (mac_cfg0.soft_reset) {
struct netxen_niu_gb_mac_config_0_t temp;
*(netxen_crbword_t *) & temp = 0;
@@ -89,7 +73,7 @@
if (netxen_nic_hw_write_wx(adapter,
NETXEN_NIU_GB_MAC_CONFIG_0
(0),
&temp, 4))
- return -1;
+ return -EIO;
restore = 1;
}
@@ -99,34 +83,34 @@
mii_cfg.reset = 1;
if (netxen_nic_hw_write_wx(adapter,
NETXEN_NIU_GB_MII_MGMT_CONFIG(0),
&mii_cfg, 4))
- return -1;
+ return -EIO;
mii_cfg.reset = 0;
if (netxen_nic_hw_write_wx(adapter,
NETXEN_NIU_GB_MII_MGMT_CONFIG(0),
&mii_cfg, 4))
- return -1;
+ return -EIO;
*(netxen_crbword_t *) & address = 0;
address.reg_addr = reg;
address.phy_addr = phy;
if (netxen_nic_hw_write_wx(adapter, NETXEN_NIU_GB_MII_MGMT_ADDR
(0),
&address, 4))
- return -1;
+ return -EIO;
*(netxen_crbword_t *) & command = 0;/* turn off any prior
activity */
if (netxen_nic_hw_write_wx(adapter,
NETXEN_NIU_GB_MII_MGMT_COMMAND(0),
&command, 4))
- return -1;
+ return -EIO;
/* send read command */
command.read_cycle = 1;
if (netxen_nic_hw_write_wx(adapter,
NETXEN_NIU_GB_MII_MGMT_COMMAND(0),
&command, 4))
- return -1;
+ return -EIO;
*(netxen_crbword_t *) & status = 0;
do {
if (netxen_nic_hw_read_wx(adapter,
NETXEN_NIU_GB_MII_MGMT_INDICATE(0),
&status, 4))
- return -1;
+ return -EIO;
timeout++;
} while ((status.busy || status.notvalid)
&& (timeout++ < NETXEN_NIU_PHY_WAITMAX));
@@ -135,7 +119,7 @@
if (netxen_nic_hw_read_wx(adapter,
NETXEN_NIU_GB_MII_MGMT_STATUS
(0),
readval, 4))
- return -1;
+ return -EIO;
result = 0;
} else
result = -1;
@@ -144,7 +128,7 @@
if (netxen_nic_hw_write_wx(adapter,
NETXEN_NIU_GB_MAC_CONFIG_0
(0),
&mac_cfg0, 4))
- return -1;
+ return -EIO;
return result;
}
@@ -176,7 +160,7 @@
/* MII mgmt all goes through port 0 MAC interface, so it cannot
be in reset */
if (netxen_nic_hw_read_wx(adapter, NETXEN_NIU_GB_MAC_CONFIG_0
(0),
&mac_cfg0, 4))
- return -1;
+ return -EIO;
if (mac_cfg0.soft_reset) {
struct netxen_niu_gb_mac_config_0_t temp;
*(netxen_crbword_t *) & temp = 0;
@@ -187,46 +171,46 @@
if (netxen_nic_hw_write_wx(adapter,
NETXEN_NIU_GB_MAC_CONFIG_0
(0),
&temp, 4))
- return -1;
+ return -EIO;
restore = 1;
}
*(netxen_crbword_t *) & command = 0;/* turn off any prior
activity */
if (netxen_nic_hw_write_wx(adapter,
NETXEN_NIU_GB_MII_MGMT_COMMAND(0),
&command, 4))
- return -1;
+ return -EIO;
*(netxen_crbword_t *) & address = 0;
address.reg_addr = reg;
Re: [PATCH 8/9] Resending NetXen 1G/10G NIC driver patch
diff -u linux-2.6.16.18/drivers/net/netxen/netxen_nic_main.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_main.c
--- linux-2.6.16.18/drivers/net/netxen/netxen_nic_main.c
2006-05-25 02:43:22.0 -0700
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_main.c
2006-05-26 04:05:34.0 -0700
@@ -259,14 +259,12 @@
pci_read_config_byte(pdev, PCI_REVISION_ID, &adapter-
>ahw.revision_id);
pci_read_config_word(pdev, PCI_COMMAND, &adapter-
>ahw.pci_cmd_word);
-#if defined(CONFIG_PCI_MSI)
- adapter->flags |= NETXEN_NIC_MSI_ENABLED;
if (pci_enable_msi(pdev)) {
adapter->flags &= ~NETXEN_NIC_MSI_ENABLED;
printk(KERN_WARNING "%s: unable to allocate MSI
interrupt"
" error\n", netxen_nic_driver_name);
- }
-#endif
+ } else
+ adapter->flags |= NETXEN_NIC_MSI_ENABLED;
if (is_flash_supported(adapter) == 0 &&
get_flash_mac_addr(adapter, mac_addr) == 0)
@@ -295,7 +293,6 @@
port = netdev_priv(netdev);
port->netdev = netdev;
port->pdev = pdev;
- port->hw.port = port;
port->adapter = adapter;
port->portnum = i; /* Gigabit port number starting
from 0-3 */
port->flags &= ~NETXEN_NETDEV_STATUS;
@@ -329,27 +326,25 @@
boardno = netxen_nic_get_board_num(adapter);
if (valid_mac) {
unsigned char *p = (unsigned char *)&mac_addr
[i];
- port->hw.mac_addr[0] = *(p + 5);
- port->hw.mac_addr[1] = *(p + 4);
- port->hw.mac_addr[2] = *(p + 3);
- port->hw.mac_addr[3] = *(p + 2);
- port->hw.mac_addr[4] = *(p + 1);
- port->hw.mac_addr[5] = *(p + 0);
-
- if (!is_valid_ether_addr(port->hw.mac_addr)) {
- printk(KERN_ERR"%s: Bad MAC address"
- "%02x:%02x:%02x:%02x:%02x:%
02x.\n",
+ netdev->dev_addr[0] = *(p + 5);
+ netdev->dev_addr[1] = *(p + 4);
+ netdev->dev_addr[2] = *(p + 3);
+ netdev->dev_addr[3] = *(p + 2);
+ netdev->dev_addr[4] = *(p + 1);
+ netdev->dev_addr[5] = *(p + 0);
+
+ if (!is_valid_ether_addr(netdev->dev_addr)) {
+ printk(KERN_ERR
+ "%s: Bad MAC address %02x:%02x:%
02x:%02x:%02x:%02x.\n",
netxen_nic_driver_name,
- port->hw.mac_addr[0],
- port->hw.mac_addr[1],
- port->hw.mac_addr[2],
- port->hw.mac_addr[3],
- port->hw.mac_addr[4],
- port->hw.mac_addr[5]);
+ netdev->dev_addr[0],
+ netdev->dev_addr[1],
+ netdev->dev_addr[2],
+ netdev->dev_addr[3],
+ netdev->dev_addr[4],
+ netdev->dev_addr[5]);
} else {
- memcpy(netdev->dev_addr, port-
>hw.mac_addr,
- netdev->addr_len);
- netxen_nic_macaddr_set(port, port-
>hw.mac_addr);
+ netxen_nic_macaddr_set(port, netdev-
>dev_addr);
}
}
INIT_WORK(adapter->tx_timeout_task + i,
@@ -629,14 +624,13 @@
/* Done here again so that even if phantom sw overwrote it,
we set it */
- netxen_nic_macaddr_set(port, port->hw.mac_addr);
+ netxen_nic_macaddr_set(port, netdev->dev_addr);
netxen_nic_set_link_parameters(port);
netxen_nic_set_multi(netdev);
if (!adapter->driver_mismatch)
netif_start_queue(netdev);
- port->state = NETXEN_PORT_UP;
return 0;
}
@@ -728,7 +722,7 @@
if (((skb->nh.iph)->ihl * sizeof(u32)) +
((skb->h.th)->doff * sizeof(u32)) +
sizeof(struct ethhdr) >
- (sizeof(struct cmd_desc_type0_t) -
IP_ALIGNMENT_BYTES)) {
+ (sizeof(struct cmd_desc_type0_t) - NET_IP_ALIGN)) {
no_of_desc++;
}
}
@@ -852,10 +846,10 @@
int hdr_len, first_hdr_len, more_hdr;
hdr_len = hw->cmd_desc_head
[saved_producer].total_hdr_length;
if (hdr_len >
- (sizeof(struct cmd_desc_type0_t) -
IP_ALIGNMENT_BYTES)) {
+
Re: [PATCH 7/9] Resending NetXen 1G/10G NIC driver patch
diff -u linux-2.6.16.18/drivers/net/netxen/netxen_nic_isr.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_isr.c
--- linux-2.6.16.18/drivers/net/netxen/netxen_nic_isr.c 2006-05-25
02:43:22.0 -0700
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_isr.c 2006-05-26
04:05:34.0 -0700
@@ -45,9 +45,6 @@
struct netxen_cmd_buffer *cmd_buff;
struct netxen_skb_frag *buffrag;
- port->state = NETXEN_PORT_DOWN;
- /* should we disable to phy for the port*/
-
/* disable phy_ints */
netxen_nic_disable_phy_interrupts(adapter, (long)port->portnum);
@@ -97,7 +94,6 @@
if (netif_running(netdev)) {
netif_carrier_off(netdev);
netif_stop_queue(netdev);
- port->state = NETXEN_PORT_SUSPEND;
netxen_nic_down(port);
}
@@ -108,10 +104,8 @@
{
u32 ret;
struct net_device *netdev = pci_get_drvdata(pdev);
- struct netxen_port *port = netdev_priv(netdev);
ret = pci_enable_device(pdev);
- port->state = NETXEN_PORT_UP;
netif_device_attach(netdev);
return ret;
}
On Thu, 2006-05-25 at 03:55 -0700, Linsys Contractor Amit S. Kale wrote:
> diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_ioctl.h
> linux-2.6.16.18/drivers/net/netxen/netxen_nic_ioctl.h
> --- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_ioctl.h
> 1969-12-31 16:00:00.0 -0800
> +++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_ioctl.h 2006-05-25
> 02:43:22.0 -0700
> @@ -0,0 +1,75 @@
> +/*
> + * Copyright (C) 2003 - 2006 NetXen, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
> + * MA 02111-1307, USA.
> + *
> + * The full GNU General Public License is included in this distribution
> + * in the file called LICENSE.
> + *
> + * Contact Information:
> + *[EMAIL PROTECTED]
> + * NetXen,
> + * 3965 Freedom Circle, Fourth floor,
> + * Santa Clara, CA 95054
> + */
> +
> +#ifndef __NETXEN_NIC_IOCTL_H__
> +#define __NETXEN_NIC_IOCTL_H__
> +
> +#include
> +
> +#define NETXEN_CMD_STARTSIOCDEVPRIVATE
> +#define NETXEN_NIC_CMD (NETXEN_CMD_START + 1)
> +#define NETXEN_NIC_NAME (NETXEN_CMD_START + 2)
> +
> +typedef enum {
> + netxen_nic_cmd_none = 0,
> + netxen_nic_cmd_pci_read,
> + netxen_nic_cmd_pci_write,
> + netxen_nic_cmd_pci_mem_read,
> + netxen_nic_cmd_pci_mem_write,
> + netxen_nic_cmd_pci_config_read,
> + netxen_nic_cmd_pci_config_write,
> + netxen_nic_cmd_get_stats,
> + netxen_nic_cmd_clear_stats,
> + netxen_nic_cmd_get_version
> +} netxen_nic_ioctl_cmd_t;
> +
> +struct netxen_nic_ioctl_data {
> + u32 cmd;
> + u32 unused1;
> + u64 off;
> + u32 size;
> + u32 rv;
> + char u[64];
> + void *ptr;
> +};
> +
> +struct netxen_statistics {
> + u64 rx_packets;
> + u64 tx_packets;
> + u64 rx_bytes;
> + u64 rx_errors;
> + u64 tx_bytes;
> + u64 tx_errors;
> + u64 rx_crc_errors;
> + u64 rx_short_length_error;
> + u64 rx_long_length_error;
> + u64 rx_mac_errors;
> +};
> +
> +#endif /* __NETXEN_NIC_IOCTL_H_ */
> diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_isr.c
> linux-2.6.16.18/drivers/net/netxen/netxen_nic_isr.c
> --- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_isr.c 1969-12-31
> 16:00:00.0 -0800
> +++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_isr.c 2006-05-25
> 02:43:22.0 -0700
> @@ -0,0 +1,428 @@
> +/*
> + * Copyright (C) 2003 - 2006 NetXen, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
>
Re: [PATCH 2/9] Resending NetXen 1G/10G NIC driver patch
Following are the minor changes for [PATCH 2/9] in accordance with the
given suggestions.
Regards,
pradeep
diff -u linux-2.6.16.18/drivers/net/netxen/netxen_nic.h
linux-2.6.16.18/drivers/net/netxen/netxen_nic.h
--- linux-2.6.16.18/drivers/net/netxen/netxen_nic.h 2006-05-25
02:43:22.0 -0700
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic.h 2006-05-26
04:05:34.0 -0700
@@ -98,12 +98,11 @@
(void *)(ptrdiff_t)(adapter->ahw.pci_base+ (reg)\
- NETXEN_CRB_PCIX_HOST2 + NETXEN_CRB_PCIX_HOST)
-#define IP_ALIGNMENT_BYTES 2 /* make ip aligned on 16 bytes
addr */
#define MAX_RX_BUFFER_LENGTH 2000
#define MAX_RX_JUMBO_BUFFER_LENGTH 9046
-#define RX_DMA_MAP_LEN (MAX_RX_BUFFER_LENGTH -
IP_ALIGNMENT_BYTES)
+#define RX_DMA_MAP_LEN (MAX_RX_BUFFER_LENGTH -
NET_IP_ALIGN)
#define RX_JUMBO_DMA_MAP_LEN \
- (MAX_RX_JUMBO_BUFFER_LENGTH - IP_ALIGNMENT_BYTES)
+ (MAX_RX_JUMBO_BUFFER_LENGTH - NET_IP_ALIGN)
/* Opcodes to be used with the commands */
#defineTX_ETHER_PKT 0x01
@@ -608,7 +607,7 @@
struct netxen_board_info boardcfg;
u32 xg_linkup;
struct netxen_adapter *adapter;
- struct cmd_desc_type0_t *cmd_desc_head; /* Address of cmd ring
in Phantom */
+ struct cmd_desc_type0_t *cmd_desc_head;
u32 cmd_producer;
u32 cmd_consumer;
u32 rcv_flag;
@@ -695,8 +694,6 @@
struct work_struct watchdog_task;
struct work_struct tx_timeout_task[4];
struct timer_list watchdog_timer;
- struct tasklet_struct tx_tasklet;
- struct tasklet_struct rx_tasklet;
u32 curr_window;
@@ -742,20 +739,6 @@
struct net_device *netdev;
};
-struct netxen_port_hw {
- unsigned char mac_addr[MAX_ADDR_LEN];
- int mtu;
- struct pci_dev *pdev;
- struct netxen_port *port;
-};
-
-/* Following structure is for specific port information*/
-
-#defineNETXEN_PORT_UP 0
-#defineNETXEN_PORT_DOWN1
-#defineNETXEN_PORT_INITIALIAZED2
-#defineNETXEN_PORT_SUSPEND 3
-
/* Max number of xmit producer threads that can run simultaneously */
#defineMAX_XMIT_PRODUCERS 16
@@ -785,11 +768,9 @@
struct netxen_port {
struct netxen_adapter *adapter;
- struct netxen_port_hw hw; /* port hardware structure */
u16 portnum;/* GBE port number */
u16 link_speed;
u16 link_duplex;
- u16 state; /* state of the port */
u16 link_autoneg;
int flags;
On Thu, 2006-05-25 at 09:42 -0700, Stephen Hemminger wrote:
> On Thu, 25 May 2006 03:51:03 -0700 (PDT)
> "Linsys Contractor Amit S. Kale" <[EMAIL PROTECTED]> wrote:
>
> > diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic.h
> > linux-2.6.16.18/drivers/net/netxen/netxen_nic.h
> > --- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic.h1969-12-31
> > 16:00:00.0 -0800
> > +++ linux-2.6.16.18/drivers/net/netxen/netxen_nic.h 2006-05-25
> > 02:43:22.0 -0700
> > @@ -0,0 +1,950 @@
> >
> > +#define IP_ALIGNMENT_BYTES 2 /* make ip aligned on 16 bytes addr */
>
> Please use NET_IP_ALIGN, it does the right architecture dependent
> offset.
>
> ...
> > +#define NETXEN_PCI_ID(X) { PCI_DEVICE(PCI_VENDOR_ID_NX, (X)) }
>
> Nested macro's on macro's, just use PCI_DEVICE()
>
> > +
> > +#define PFX "netxen: "
> > +
> > +/* Note: Make sure to not call this before adapter->port is valid */
> > +#if !defined(NETXEN_DEBUG)
> > +#define DPRINTK(klevel, fmt, args...) do { \
> > + } while (0)
> > +#else
> > +#define DPRINTK(klevel, fmt, args...) do { \
> > + printk(KERN_##klevel PFX "%s: %s: " fmt, __FUNCTION__,\
> > + (adapter != NULL && adapter->port != NULL && \
> > + adapter->port[0] != NULL && \
> > + adapter->port[0]->netdev != NULL) ? \
> > + adapter->port[0]->netdev->name : NULL, \
> > + ## args); } while(0)
> > +#endif
> > +
>
> Ugh. Macro with magic variable. if you need to keep this, pass adapter.
>
>
> > +struct netdev_list {
> > + struct netdev_list *next;
> > + struct net_device *netdev;
> > +};
>
> Why not use regular list.h or simple linked list. Even better
> figure out how to not need need "list of devices at all"
>
> > +struct netxen_port_hw {
> > + unsigned char mac_addr[MAX_ADDR_LEN];
> > + int mtu;
> > + struct pci_dev *pdev;
> > + struct netxen_port *port;
> > +};
>
> Isn't mtu redundant with dev->mtu and mac_addr redundant
> with dev->dev_addr
>
>
> > +/* Following structure is for specific port information*/
> > +
> > +#defineNETXEN_PORT_UP 0
> > +#defineNETXEN_PORT_DOWN1
> > +#defineNETXEN_PORT_INITIALIAZED2
> > +#defineNETXEN_PORT_SUSPEND 3
>
> Don't mirror port state with netdevice state becaus
Re: [PATCH 1/9] Resending NetXen 1G/10G NIC driver patch
Following are the minor changes for [PATCH 1/9] in accordance with the
given suggestions.
Regards,
pradeep
diff -u linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
--- linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
2006-05-25 02:43:22.0 -0700
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
2006-05-26 04:05:34.0 -0700
@@ -145,7 +145,7 @@
ecmd->port = PORT_TP;
- if (port->state) {
+ if (dev->flags & IFF_UP) {
ecmd->speed = port->link_speed;
ecmd->duplex = port->link_duplex;
} else
@@ -512,16 +512,6 @@
ring->rx_jumbo_pending = 0;
}
-/*
- * Note: This change will be reflected in all the four ports as there
is
- * only one common adapter.
- */
-static int
-netxen_nic_set_ringparam(struct net_device *dev, struct
ethtool_ringparam *ring)
-{
- return 0;
-}
-
static void
netxen_nic_get_pauseparam(struct net_device *dev,
struct ethtool_pauseparam *pause)
@@ -781,7 +771,6 @@
.get_eeprom_len = netxen_nic_get_eeprom_len,
.get_eeprom = netxen_nic_get_eeprom,
.get_ringparam = netxen_nic_get_ringparam,
- .set_ringparam = netxen_nic_set_ringparam,
.get_pauseparam = netxen_nic_get_pauseparam,
.set_pauseparam = netxen_nic_set_pauseparam,
.get_rx_csum = netxen_nic_get_rx_csum,
On Thu, 2006-05-25 at 09:33 -0700, Stephen Hemminger wrote:
> Minor nits.
>
> On Thu, 25 May 2006 03:48:38 -0700 (PDT)
> "Linsys Contractor Amit S. Kale" <[EMAIL PROTECTED]> wrote:
>
> > +/*
> > + * Note: This change will be reflected in all the four ports as there is
> > + * only one common adapter.
> > + */
> > +static int
> > +netxen_nic_set_ringparam(struct net_device *dev, struct ethtool_ringparam
> > *ring)
> > +{
> > + return 0;
> > +}
>
> Why not just return have no hook if you can't set parameters. Then the ioctl
> will return not supported -EOPNOTSUPP
>
> >
> > +static u32 netxen_nic_get_rx_csum(struct net_device *dev)
> > +{
> > + return (dev->features & NETIF_F_HW_CSUM);
> > +}
>
>
> You got receive and transmit checksum confused. You need to separate
> checksumming on output (dev->features & NETIF_F_HW_CSUM) versus receive
> checksum (controlled by hardware and usually a flag in private data
> structure).
>
> > +static int netxen_nic_set_rx_csum(struct net_device *dev, u32 data)
> > +{
> > + if (data)
> > + dev->features |= NETIF_F_HW_CSUM;
> > + else
> > + dev->features &= (~NETIF_F_HW_CSUM);
> > +
> > + if (netif_running(dev)) {
> > + dev->stop(dev); /* verify */
> > + dev->open(dev);
>
> What if open fail fails? Then you have an "interesting" recovery
> situation.
> > + }
> > + return 0;
> > +}
> >
>
--
pradeep
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ip_conntrack_helper_pptp.c: fix sstate/cstate typo
Alexey Dobriyan wrote:
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
> ---
>
> --- a/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
> +++ b/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
> @@ -469,8 +469,8 @@ pptp_inbound_pkt(struct sk_buff **pskb,
> DEBUGP("%s but no session\n", pptp_msg_name[msg]);
> break;
> }
> - if (info->sstate != PPTP_CALL_IN_REP
> - && info->sstate != PPTP_CALL_IN_CONF) {
> + if (info->cstate != PPTP_CALL_IN_REP
> + && info->cstate != PPTP_CALL_IN_CONF) {
> DEBUGP("%s but never sent IN_CALL_REPLY\n",
> pptp_msg_name[msg]);
> break;
Looks correct to me, but I'm not that familiar with the code.
Harald, do you want me to apply this?
-
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 4/9] Resending NetXen 1G/10G NIC driver patch
diff -u linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.c
--- linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.c 2006-05-25
02:43:22.0 -0700
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.c 2006-05-26
04:05:34.0 -0700
@@ -61,7 +61,6 @@
DPRINTK(INFO, "valid ether addr\n");
memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
- memcpy(port->hw.mac_addr, addr->sa_data, netdev->addr_len);
netxen_nic_macaddr_set(port, addr->sa_data);
@@ -102,7 +101,6 @@
netxen_nic_set_mtu(port, new_mtu);
netdev->mtu = new_mtu;
- port->hw.mtu = new_mtu;
return 0;
}
@@ -628,8 +626,9 @@
return val;
}
+/* Change the window to 0, write and change back to window 1. */
void netxen_nic_write_w0(struct netxen_adapter *adapter, u32 index, u32
value)
-{ /* Change the window to 0, write and
change back to window 1. */
+{
unsigned long flags;
void *addr;
@@ -641,8 +640,9 @@
write_unlock_irqrestore(&adapter->adapter_lock, flags);
}
+/* Change the window to 0, read and change back to window 1. */
void netxen_nic_read_w0(struct netxen_adapter *adapter, u32 index, u32
* value)
-{ /* Change the window to 0, read and
change back to window 1. */
+{
unsigned long flags;
void *addr;
@@ -1188,7 +1188,6 @@
NETXEN_NIU_GB_MII_MGMT_ADDR_PHY_STATUS,
(netxen_crbword_t *) & status)
== 0) {
if (status.link) {
- port->state = 1;
switch (status.speed) {
case 0:
port->link_speed = SPEED_10;
@@ -1224,7 +1223,6 @@
goto link_down;
} else {
link_down:
- port->state = -1;
port->link_speed = -1;
port->link_duplex = -1;
}
On Thu, 2006-05-25 at 03:53 -0700, Linsys Contractor Amit S. Kale wrote:
> diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hw.c
> linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.c
> --- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hw.c 1969-12-31
> 16:00:00.0 -0800
> +++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.c2006-05-25
> 02:43:22.0 -0700
> @@ -0,0 +1,1289 @@
> +/*
> + * Copyright (C) 2003 - 2006 NetXen, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
> + * MA 02111-1307, USA.
> + *
> + * The full GNU General Public License is included in this distribution
> + * in the file called LICENSE.
> + *
> + * Contact Information:
> + *[EMAIL PROTECTED]
> + * NetXen,
> + * 3965 Freedom Circle, Fourth floor,
> + * Santa Clara, CA 95054
> + *
> + *
> + * Source file for NIC routines to access the Phantom hardware
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include "netxen_nic.h"
> +#include "netxen_nic_hw.h"
> +#include "netxen_nic_phan_reg.h"
> +
> +/* PCI Windowing for DDR regions. */
> +
> +#define ADDR_IN_RANGE(addr, low, high) \
> + (((addr) <= (high)) && ((addr) >= (low)))
> +
> +static unsigned long netxen_nic_pci_set_window(unsigned long long pci_base,
> +unsigned long long addr);
> +void netxen_free_hw_resources(struct netxen_adapter *adapter);
> +
> +int netxen_nic_set_mac(struct net_device *netdev, void *p)
> +{
> + struct netxen_port *port = netdev_priv(netdev);
> + struct sockaddr *addr = p;
> +
> + if (netif_running(netdev))
> + return -EBUSY;
> +
> + if (!is_valid_ether_addr(addr->sa_data))
> + return -EADDRNOTAVAIL;
> +
> + DPRINTK(INFO, "valid ether addr\n");
> + memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
> + memcpy(port->hw.mac_addr, addr->sa_data, netdev->addr_len);
> +
> + netxen_nic_macaddr_set(port, addr->sa_data);
> +
> + return 0;
> +}
> +
> +/**
> + * netxen_nic_set_multi - Multicast
> + **/
> +void netxen_nic_set_multi(struct net_dev
Re: [PATCH 6/9] Resending NetXen 1G/10G NIC driver patch
diff -u linux-2.6.16.18/drivers/net/netxen/netxen_nic_init.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_init.c
--- linux-2.6.16.18/drivers/net/netxen/netxen_nic_init.c
2006-05-25 02:43:22.0 -0700
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_init.c
2006-05-26 04:05:34.0 -0700
@@ -200,8 +200,8 @@
}
/*
- * netxen_decode_crb_addr(0 - utility to translate from internal
Phantom
- * CRB address to external PCI CRB address.
+ * netxen_decode_crb_addr(0 - utility to translate from internal
Phantom CRB address
+ * to external PCI CRB address.
*/
unsigned long netxen_decode_crb_addr(unsigned long addr)
{
@@ -869,7 +869,6 @@
for (p = 0; p < adapter->ahw.max_ports; p++) {
nport = adapter->port[p];
if (netif_queue_stopped(nport->netdev)
- && (nport->state == NETXEN_PORT_UP)
&& (nport->flags & NETXEN_NETDEV_STATUS)) {
netif_wake_queue(nport->netdev);
nport->flags &= ~NETXEN_NETDEV_STATUS;
@@ -920,7 +919,7 @@
}
count++;/* now there should be no failure */
pdesc = &rcv_desc->desc_head[producer];
- skb_reserve(skb, IP_ALIGNMENT_BYTES);
+ skb_reserve(skb, NET_IP_ALIGN);
/*
* This will be setup when we receive the
* buffer after it has been filled
On Thu, 2006-05-25 at 09:47 -0700, Stephen Hemminger wrote:
> Why is this necessary. Additional private API seems like leftover
> debug code.
>
> > +int
> > +netxen_nic_do_ioctl(struct netxen_adapter *adapter, void *u_data,
> > + struct netxen_port *port)
> > +{
> > + struct netxen_nic_ioctl_data data;
> > + struct netxen_nic_ioctl_data *up_data;
> > + int retval = 0;
> > + struct netxen_statistics netxen_stats;
> > +
> > + up_data = (void *)u_data;
> > +
> > + DPRINTK(INFO, "doing ioctl for %p\n", adapter);
> > + if (copy_from_user(&data, up_data, sizeof(data))) {
> > + /* evil user tried to crash the kernel */
> > + DPRINTK(ERR, "bad copy from userland: %d\n", (int)sizeof(data));
> > + retval = -EFAULT;
> > + goto error_out;
> > + }
> > +
> > + /* Shouldn't access beyond legal limits of "char u[64];" member */
> > + if (!data.ptr && (data.size > sizeof(data.u))) {
> > + /* evil user tried to crash the kernel */
> > + DPRINTK(ERR, "bad size: %d\n", data.size);
> > + retval = -EFAULT;
> > + goto error_out;
> > + }
> > +
> > + switch (data.cmd) {
> > + case netxen_nic_cmd_pci_read:
> > + if ((retval = netxen_nic_hw_read_wx(adapter, data.off,
> > + &(data.u), data.size)))
> > + goto error_out;
> > + if (copy_to_user((void *)&(up_data->u), &(data.u), data.size)) {
> > + DPRINTK(ERR, "bad copy to userland: %d\n",
> > + (int)sizeof(data));
> > + retval = -EFAULT;
> > + goto error_out;
> > + }
> > + data.rv = 0;
> > + break;
> > +
>
> Can't you access the same registers area with ethtool.
>
>
> > + case netxen_nic_cmd_pci_write:
> > + data.rv = netxen_nic_hw_write_wx(adapter, data.off, &(data.u),
> > +data.size);
> > + break;
> > +
> > + case netxen_nic_cmd_pci_mem_read:
> > + DPRINTK(INFO, "doing %s for %p\n",
> > + "netxen_nic_cmd_pci_mm_rd", adapter);
> > + netxen_nic_pci_mem_read(adapter, data.off, &(data.u),
> > + data.size);
> > + if (copy_to_user((void *)&(up_data->u), &(data.u), data.size)) {
> > + DPRINTK(ERR, "bad copy to userland: %d\n",
> > + (int)sizeof(data));
> > + retval = -EFAULT;
> > + goto error_out;
> > + }
> > + data.rv = 0;
> > + DPRINTK(INFO, "read %lx\n", (unsigned long)data.u);
> > + break;
>
> PCI memory is accessible directly through sysfs for diagnostic tools.
>
>
> > + case netxen_nic_cmd_pci_mem_write:
> > + netxen_nic_pci_mem_write(adapter, data.off, &(data.u),
> > +data.size);
> > + data.rv = 0;/* write always succeeds */
> > + break;
> > +
> > + case netxen_nic_cmd_pci_config_read:
> > + switch (data.size) {
> > + case 1:
> > + data.rv = pci_read_config_byte(adapter->ahw.pdev,
> > + data.off,
> > + (char *)&(data.u));
> > + break;
> > + case 2:
> > + data.rv = pci_read_config_word(ad
Re: Fix SO_ORIGINAL_DST information leak (CVE-2006-1343)
Marcel Holtmann wrote: > Hi, > > the fix for CVE-2006-1343 (information leak) never made it upstream: > > http://marc.theaimsgroup.com/?l=linux-netdev&m=114148078223594&w=2 > > So here it is again against the latest git repository and with the > additional line in net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c. Applied, thanks Marcel. I think I missed this one because I saw it appear in 2.4, so I concluded that Dave already applied it. Looking at the Changelog it was Marcelo himself. - 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: Safe remote kernel install howto (Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc))
Hi Andi, Andi Kleen wrote: > > 4. Put "sysctl -w kernel.panic_on_oops=1" as early as possible > > in your boot scripts[1]. > > You can as well boot with oops=panic Only on x86_64 as of Linux 2.6.16. But maybe this could be put into kernel/panic.c instead :-) Regards Ingo Oeser - 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: Safe remote kernel install howto (Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc))
> 4. Put "sysctl -w kernel.panic_on_oops=1" as early as possible > in your boot scripts[1]. You can as well boot with oops=panic -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Safe remote kernel install howto (Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc))
Ingo Oeser wrote: > Hi Meelis, > >> Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out >> remotely at the moment. > > Here it my paranoid boot setup: > > 1. Use "lilo -R new-kernel", to boot a kernel only > once and reboot the default kernel next time. > > 2. Force reboot on any panic after 10 seconds: > append="panic=10" in /etc/lilo.conf > > 3. Schedule automatic reboot in case of impossible login > echo "/bin/sync; /sbin/reboot -f "|at now + 15min Instead of this, I usually use a system startup script like this: case "$(cat /proc/cmdline)" in *linux-test*) (sleep 300; [ -f /var/run/noreboot ] || reboot) & ;; esac which means that if the kernel image is named 'linux-test', it will be rebooted in 15 minutes after booting if no /var/run/noreboot file exist. So if I'm able to log in, i just touch /var/run/noreboot and be done with it. And oh, yes, for this to work, in lilo.conf the new entry should be labeled linux-test -- ie, install new kernel, add new entry into lilo.conf with label=linux-test, run `lilo && lilo -R linux-test && init 6' and.. wait ;) After successeful reboot (and touching /var/run/noreboot), edit lilo.conf, restore the proper label, set proper order of entries if needed and re-run lilo. /mjt - 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
Safe remote kernel install howto (Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc))
Hi Meelis, > Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out > remotely at the moment. Here it my paranoid boot setup: 1. Use "lilo -R new-kernel", to boot a kernel only once and reboot the default kernel next time. 2. Force reboot on any panic after 10 seconds: append="panic=10" in /etc/lilo.conf 3. Schedule automatic reboot in case of impossible login echo "/bin/sync; /sbin/reboot -f "|at now + 15min 4. Put "sysctl -w kernel.panic_on_oops=1" as early as possible in your boot scripts[1]. And now reboot into the new kernel, try to login and delete the reboot cronjob. If this doesn't work, just wait 15min and have the last stable kernel booted automatically. This method saved me and our customers a lot of time already :-) Regards Ingo Oeser [1] This should be the default and should be disabled by the init scripts as soon as we reach the desired runlevel (S99oops_not_fatal). - 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: Safe remote kernel install howto (Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc))
Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out remotely at the moment. Here it my paranoid boot setup: Thanks, but it's not much use here, since the machine is a PReP powerpc machine that can boot one kernel from disk (directly loaded from boot partition, no fancy bootloader) or netboot via serial console for test kernels. However, if the test kernel hangs, it hangs and I would need remote power cycling device that I do not have. -- Meelis Roos ([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
[PATCH] ip_conntrack_helper_pptp.c: fix sstate/cstate typo
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
--- a/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
+++ b/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
@@ -469,8 +469,8 @@ pptp_inbound_pkt(struct sk_buff **pskb,
DEBUGP("%s but no session\n", pptp_msg_name[msg]);
break;
}
- if (info->sstate != PPTP_CALL_IN_REP
- && info->sstate != PPTP_CALL_IN_CONF) {
+ if (info->cstate != PPTP_CALL_IN_REP
+ && info->cstate != PPTP_CALL_IN_CONF) {
DEBUGP("%s but never sent IN_CALL_REPLY\n",
pptp_msg_name[msg]);
break;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Buesch napsal(a):
> On Friday 26 May 2006 12:33, you wrote:
>> --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> @@ -2131,6 +2131,13 @@ out:
>> return err;
>> }
>>
>> +#ifdef CONFIG_BCM947XX
>> +static struct pci_device_id bcm43xx_ids[] = {
>
> Call it
> static struct pci_device_id bcm43xx_47xx_ids[] = {
> please.
>
> And; _important_; if you submit this change, _also_
> do a patch against the devicescape version of the driver in
> John Linville's wireless-dev tree
> drivers/net/wireless/d80211/bcm43xx
> in the tree at
> git://kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
Ok, thanks.
- --
Jiri Slaby www.fi.muni.cz/~xslaby
\_.-^-._ [EMAIL PROTECTED] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEduvXMsxVwznUen4RAqQcAJ9j870AGMn5jXW68tEQHZXltAenmQCfX9Ik
oyRfuNnKxGHu8HGVvcDVJHM=
=/NUD
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix SO_ORIGINAL_DST information leak (CVE-2006-1343)
Hi,
the fix for CVE-2006-1343 (information leak) never made it upstream:
http://marc.theaimsgroup.com/?l=linux-netdev&m=114148078223594&w=2
So here it is again against the latest git repository and with the
additional line in net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c.
Regards
Marcel
[PATCH] Fix small information leak in SO_ORIGINAL_DST
It appears that sockaddr_in.sin_zero is not zeroed during
getsockopt(...SO_ORIGINAL_DST...) operation. This can lead
to an information leak (CVE-2006-1343).
Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>
---
commit 8b9b62a6bb6c5488fd094d97216787e191721a15
tree fac8f79c318f37d4cb6795e540b77be61c9d1f5d
parent 705af309505681f197f81618440954d10f120dc0
author Marcel Holtmann <[EMAIL PROTECTED]> Fri, 26 May 2006 13:45:42 +0200
committer Marcel Holtmann <[EMAIL PROTECTED]> Fri, 26 May 2006 13:45:42 +0200
net/ipv4/netfilter/ip_conntrack_core.c |1 +
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_core.c
b/net/ipv4/netfilter/ip_conntrack_core.c
index 979a2ea..a297da7 100644
--- a/net/ipv4/netfilter/ip_conntrack_core.c
+++ b/net/ipv4/netfilter/ip_conntrack_core.c
@@ -1318,6 +1318,7 @@ getorigdst(struct sock *sk, int optval,
.tuple.dst.u.tcp.port;
sin.sin_addr.s_addr = ct->tuplehash[IP_CT_DIR_ORIGINAL]
.tuple.dst.ip;
+ memset(sin.sin_zero, 0, sizeof(sin.sin_zero));
DEBUGP("SO_ORIGINAL_DST: %u.%u.%u.%u %u\n",
NIPQUAD(sin.sin_addr.s_addr), ntohs(sin.sin_port));
diff --git a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
index 5bc9f64..77d9744 100644
--- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
@@ -348,6 +348,7 @@ getorigdst(struct sock *sk, int optval,
.tuple.dst.u.tcp.port;
sin.sin_addr.s_addr = ct->tuplehash[IP_CT_DIR_ORIGINAL]
.tuple.dst.u3.ip;
+ memset(sin.sin_zero, 0, sizeof(sin.sin_zero));
DEBUGP("SO_ORIGINAL_DST: %u.%u.%u.%u %u\n",
NIPQUAD(sin.sin_addr.s_addr), ntohs(sin.sin_port));
Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
On Friday 26 May 2006 12:33, you wrote:
> --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -2131,6 +2131,13 @@ out:
> return err;
> }
>
> +#ifdef CONFIG_BCM947XX
> +static struct pci_device_id bcm43xx_ids[] = {
Call it
static struct pci_device_id bcm43xx_47xx_ids[] = {
please.
And; _important_; if you submit this change, _also_
do a patch against the devicescape version of the driver in
John Linville's wireless-dev tree
drivers/net/wireless/d80211/bcm43xx
in the tree at
git://kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
-
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] pci: bcm43xx avoid pci_find_device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Garzik napsal(a): > Jiri Slaby wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jeff Garzik napsal(a): >>> The point is that you don't need to loop over the table, >>> pci_match_one_device() does that for you. >> The problem is, that there is no such function, I think. >> If you take a look at pci_dev_present: > > The function you want is pci_dev_present(). Nope, it returns only 0/1. regards, - -- Jiri Slaby www.fi.muni.cz/~xslaby \_.-^-._ [EMAIL PROTECTED] _.-^-._/ B67499670407CE62ACC8 22A032CC55C339D47A7E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEduafMsxVwznUen4RAjfzAKCaxRAK1nN5qx+akiA59E5Mq/ZPcgCffRwa vwAz0SPClr6sCYy+DOjtilE= =DHzA -END PGP SIGNATURE- - 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] pci: bcm43xx avoid pci_find_device
Jiri Slaby wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Garzik napsal(a): The point is that you don't need to loop over the table, pci_match_one_device() does that for you. The problem is, that there is no such function, I think. If you take a look at pci_dev_present: The function you want is pci_dev_present(). 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] [IPV6] ROUTE: Don't try less preferred routes for on-link routes.
David,
In article <[EMAIL PROTECTED]> (at Fri, 26 May 2006 13:44:59 +0300 (EEST)),
Meelis Roos <[EMAIL PROTECTED]> says:
> >> The unreachable route works now but LAN routing still does not work.
> >> Locally generated ICMPv6 packets that should go to LAN interface still
> >> go to tun6to4.
> >
> > Please try this.
>
> This works for both unreachable and LAN routes, thanks!
Please push this to 2.6.17-final.
Regards,
---
[IPV6] ROUTE: Don't try less preferred routes for on-link routes.
In addition to the real on-link routes, NONEXTHOP routes
should be considered on-link.
Problem reported by Meelis Roos <[EMAIL PROTECTED]>.
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Acked-by: Meelis Roos <[EMAIL PROTECTED]>
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 0190e39..8a77793 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -280,10 +280,13 @@ static int inline rt6_check_neigh(struct
{
struct neighbour *neigh = rt->rt6i_nexthop;
int m = 0;
- if (neigh) {
+ if (rt->rt6i_flags & RTF_NONEXTHOP ||
+ !(rt->rt6i_flags & RTF_GATEWAY))
+ m = 1;
+ else if (neigh) {
read_lock_bh(&neigh->lock);
if (neigh->nud_state & NUD_VALID)
- m = 1;
+ m = 2;
read_unlock_bh(&neigh->lock);
}
return m;
@@ -292,15 +295,18 @@ static int inline rt6_check_neigh(struct
static int rt6_score_route(struct rt6_info *rt, int oif,
int strict)
{
- int m = rt6_check_dev(rt, oif);
+ int m, n;
+
+ m = rt6_check_dev(rt, oif);
if (!m && (strict & RT6_SELECT_F_IFACE))
return -1;
#ifdef CONFIG_IPV6_ROUTER_PREF
m |= IPV6_DECODE_PREF(IPV6_EXTRACT_PREF(rt->rt6i_flags)) << 2;
#endif
- if (rt6_check_neigh(rt))
+ n = rt6_check_neigh(rt);
+ if (n > 1)
m |= 16;
- else if (strict & RT6_SELECT_F_REACHABLE)
+ else if (!n && strict & RT6_SELECT_F_REACHABLE)
return -1;
return m;
}
--
YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
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 3/4] myri10ge - Driver core
On Fri, 2006-05-26 at 06:30 -0400, Jeff Garzik wrote: > Benjamin Herrenschmidt wrote: > >>> No proper interface exposed, he'll have to do an #ifdef powerpc here or > >>> such and use __ioremap with explicit page attributes. I have a hack to > >>> do that automatically for memory covered by prefetchable PCI BARs when > >>> mmap'ing from userland but not for kernel ioremap. > >> Stupid question: pci_iomap() is NOT what you are looking for, right? > >> > >> Implementation is at the end of lib/iomap.c > > > > No, there is no difference there, pci_iomap won't help for passing in > > platform specific page attributes for things like write combining. > > Since we already have ioremap_nocache(), maybe adding ioremap_wcomb() is > appropriate? Yes, but be careful there.. on ppc, not setting the page "guarded" bit will enable write combining on various CPUs but will also enable speculative reads, prefetch, etc... so it's not "just" WC, you have to know for sure what you are doing with that memory (basically, enable side-effects). Ben. - 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] pci: bcm43xx avoid pci_find_device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Garzik napsal(a): > The point is that you don't need to loop over the table, > pci_match_one_device() does that for you. The problem is, that there is no such function, I think. If you take a look at pci_dev_present: http://sosdg.org/~coywolf/lxr/source/drivers/pci/search.c#L270 They traverse the table in similar way as I do. pci_match_one_device() just checks (one to one) values without any looping. regards, - -- Jiri Slaby www.fi.muni.cz/~xslaby \_.-^-._ [EMAIL PROTECTED] _.-^-._/ B67499670407CE62ACC8 22A032CC55C339D47A7E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEdt5HMsxVwznUen4RAqt8AJ9pzaDey2zn399lrahelv17w8IiDgCguUwa 4xOX7pUX2Au/WBsbJbnNwBE= =P1cu -END PGP SIGNATURE- - 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: ipv6 routing broken in 2.6.17-rc3,4
The unreachable route works now but LAN routing still does not work. Locally generated ICMPv6 packets that should go to LAN interface still go to tun6to4. Please try this. This works for both unreachable and LAN routes, thanks! -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
Jiri Slaby wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Garzik napsal(a):
Jiri Slaby wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Garzik napsal(a):
Jiri Slaby wrote:
bcm43xx avoid pci_find_device
Change pci_find_device to safer pci_get_device with support for more
devices.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 1d3b6caf027fe53351c645523587aeac40bc3e47
tree ae37c86b633442cdf8a7a19ac287542724081c90
parent ab3443d79c94d0ae6a9e020daefa4d29eccff50d
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 26 May 2006 01:49:12
+0159
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 26 May 2006
01:49:12 +0159
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index b488f77..56d2fc6 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2131,6 +2131,13 @@ out:
return err;
}
+#ifdef CONFIG_BCM947XX
+static struct pci_device_id bcm43xx_ids[] = {
+{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
+{ 0 }
+};
Table is here ^^^. You just add an entry, and that's it.
+#endif
+
static int bcm43xx_initialize_irq(struct bcm43xx_private *bcm)
{
int res;
@@ -2141,10 +2148,15 @@ static int bcm43xx_initialize_irq(struct
#ifdef CONFIG_BCM947XX
if (bcm->pci_dev->bus->number == 0) {
struct pci_dev *d = NULL;
-/* FIXME: we will probably need more device IDs here... */
-d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
-if (d != NULL) {
-bcm->irq = d->irq;
+struct pci_device_id *id = bcm43xx_ids;
+while (id->vendor) {
+d = pci_get_device(id->vendor, id->device, NULL);
+if (d != NULL) {
+bcm->irq = d->irq;
+pci_dev_put(d);
+break;
You'll want to use pci_match_device() or pci_match_one_device()
[I forget which one]
Why? Matching is done by pci_get_device() or pci_get_subsys(),
respectively.
[pci_match_device() is for matching dev <-> drv, you meant
pci_match_one_device()]
The FIXME says "we will probably need more device IDs here."
Yup.
Thus, if you are touching this area, it would make sense to add the
capability to easily add a second (and third, fourth...) PCI ID. And
that means pci_match_one_device() and a pci_device_id table.
But the while loop do the work: unless id->vendor != NULL, do the matching with
the current raw (id) of the table, then jump to the next raw (id++).
pci_get_device returns NULL if the device with id->vendor, id->device wasn't
found, then we try next raw, otherwise, we break the loop.
Implementations before and now do the same strangeness -- assume there is only
one device (?shouldn't matter?, since it is embedded).
The point is that you don't need to loop over the table,
pci_match_one_device() does that for you.
And this code, like the gt96100_eth code, is testing the existence of
certain platform devices, to be certain that it can proceed with certain
platform-specific duties.
Thus we don't care about matching multiple devices -- an unlikely case
-- but we do care about making the code as small as possible by calling
a standard PCI match function which searches through a list of PCI IDs.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Garzik napsal(a):
> Jiri Slaby wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Jeff Garzik napsal(a):
>>> Jiri Slaby wrote:
bcm43xx avoid pci_find_device
Change pci_find_device to safer pci_get_device with support for more
devices.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 1d3b6caf027fe53351c645523587aeac40bc3e47
tree ae37c86b633442cdf8a7a19ac287542724081c90
parent ab3443d79c94d0ae6a9e020daefa4d29eccff50d
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 26 May 2006 01:49:12
+0159
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 26 May 2006
01:49:12 +0159
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index b488f77..56d2fc6 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2131,6 +2131,13 @@ out:
return err;
}
+#ifdef CONFIG_BCM947XX
+static struct pci_device_id bcm43xx_ids[] = {
+{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
+{ 0 }
+};
Table is here ^^^. You just add an entry, and that's it.
+#endif
+
static int bcm43xx_initialize_irq(struct bcm43xx_private *bcm)
{
int res;
@@ -2141,10 +2148,15 @@ static int bcm43xx_initialize_irq(struct
#ifdef CONFIG_BCM947XX
if (bcm->pci_dev->bus->number == 0) {
struct pci_dev *d = NULL;
-/* FIXME: we will probably need more device IDs here... */
-d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
-if (d != NULL) {
-bcm->irq = d->irq;
+struct pci_device_id *id = bcm43xx_ids;
+while (id->vendor) {
+d = pci_get_device(id->vendor, id->device, NULL);
+if (d != NULL) {
+bcm->irq = d->irq;
+pci_dev_put(d);
+break;
>>> You'll want to use pci_match_device() or pci_match_one_device()
>>> [I forget which one]
>> Why? Matching is done by pci_get_device() or pci_get_subsys(),
>> respectively.
>> [pci_match_device() is for matching dev <-> drv, you meant
>> pci_match_one_device()]
>
> The FIXME says "we will probably need more device IDs here."
Yup.
>
> Thus, if you are touching this area, it would make sense to add the
> capability to easily add a second (and third, fourth...) PCI ID. And
> that means pci_match_one_device() and a pci_device_id table.
But the while loop do the work: unless id->vendor != NULL, do the matching with
the current raw (id) of the table, then jump to the next raw (id++).
pci_get_device returns NULL if the device with id->vendor, id->device wasn't
found, then we try next raw, otherwise, we break the loop.
Implementations before and now do the same strangeness -- assume there is only
one device (?shouldn't matter?, since it is embedded).
cheers,
- --
Jiri Slaby www.fi.muni.cz/~xslaby
\_.-^-._ [EMAIL PROTECTED] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEdtlbMsxVwznUen4RAo/OAJsHy6sED+a9QYmbcaGTMUjwSYm4vACgwfQL
GhmfbtwskPB3Dnvw8HfJzpE=
=+kxv
-END PGP SIGNATURE-
-
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 3/4] myri10ge - Driver core
Benjamin Herrenschmidt wrote: No proper interface exposed, he'll have to do an #ifdef powerpc here or such and use __ioremap with explicit page attributes. I have a hack to do that automatically for memory covered by prefetchable PCI BARs when mmap'ing from userland but not for kernel ioremap. Stupid question: pci_iomap() is NOT what you are looking for, right? Implementation is at the end of lib/iomap.c No, there is no difference there, pci_iomap won't help for passing in platform specific page attributes for things like write combining. Since we already have ioremap_nocache(), maybe adding ioremap_wcomb() is appropriate? Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
Jiri Slaby wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Garzik napsal(a):
Jiri Slaby wrote:
bcm43xx avoid pci_find_device
Change pci_find_device to safer pci_get_device with support for more
devices.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 1d3b6caf027fe53351c645523587aeac40bc3e47
tree ae37c86b633442cdf8a7a19ac287542724081c90
parent ab3443d79c94d0ae6a9e020daefa4d29eccff50d
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 26 May 2006 01:49:12
+0159
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 26 May 2006
01:49:12 +0159
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index b488f77..56d2fc6 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2131,6 +2131,13 @@ out:
return err;
}
+#ifdef CONFIG_BCM947XX
+static struct pci_device_id bcm43xx_ids[] = {
+{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
+{ 0 }
+};
+#endif
+
static int bcm43xx_initialize_irq(struct bcm43xx_private *bcm)
{
int res;
@@ -2141,10 +2148,15 @@ static int bcm43xx_initialize_irq(struct
#ifdef CONFIG_BCM947XX
if (bcm->pci_dev->bus->number == 0) {
struct pci_dev *d = NULL;
-/* FIXME: we will probably need more device IDs here... */
-d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
-if (d != NULL) {
-bcm->irq = d->irq;
+struct pci_device_id *id = bcm43xx_ids;
+while (id->vendor) {
+d = pci_get_device(id->vendor, id->device, NULL);
+if (d != NULL) {
+bcm->irq = d->irq;
+pci_dev_put(d);
+break;
You'll want to use pci_match_device() or pci_match_one_device()
[I forget which one]
Why? Matching is done by pci_get_device() or pci_get_subsys(), respectively.
[pci_match_device() is for matching dev <-> drv, you meant
pci_match_one_device()]
The FIXME says "we will probably need more device IDs here."
Thus, if you are touching this area, it would make sense to add the
capability to easily add a second (and third, fourth...) PCI ID. And
that means pci_match_one_device() and a pci_device_id table.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Garzik napsal(a):
> Jiri Slaby wrote:
>> bcm43xx avoid pci_find_device
>>
>> Change pci_find_device to safer pci_get_device with support for more
>> devices.
>>
>> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
>>
>> ---
>> commit 1d3b6caf027fe53351c645523587aeac40bc3e47
>> tree ae37c86b633442cdf8a7a19ac287542724081c90
>> parent ab3443d79c94d0ae6a9e020daefa4d29eccff50d
>> author Jiri Slaby <[EMAIL PROTECTED]> Fri, 26 May 2006 01:49:12
>> +0159
>> committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 26 May 2006
>> 01:49:12 +0159
>>
>> drivers/net/wireless/bcm43xx/bcm43xx_main.c | 20
>> 1 files changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> index b488f77..56d2fc6 100644
>> --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> @@ -2131,6 +2131,13 @@ out:
>> return err;
>> }
>>
>> +#ifdef CONFIG_BCM947XX
>> +static struct pci_device_id bcm43xx_ids[] = {
>> +{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
>> +{ 0 }
>> +};
>> +#endif
>> +
>> static int bcm43xx_initialize_irq(struct bcm43xx_private *bcm)
>> {
>> int res;
>> @@ -2141,10 +2148,15 @@ static int bcm43xx_initialize_irq(struct
>> #ifdef CONFIG_BCM947XX
>> if (bcm->pci_dev->bus->number == 0) {
>> struct pci_dev *d = NULL;
>> -/* FIXME: we will probably need more device IDs here... */
>> -d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
>> -if (d != NULL) {
>> -bcm->irq = d->irq;
>> +struct pci_device_id *id = bcm43xx_ids;
>> +while (id->vendor) {
>> +d = pci_get_device(id->vendor, id->device, NULL);
>> +if (d != NULL) {
>> +bcm->irq = d->irq;
>> +pci_dev_put(d);
>> +break;
>
> You'll want to use pci_match_device() or pci_match_one_device()
> [I forget which one]
Why? Matching is done by pci_get_device() or pci_get_subsys(), respectively.
[pci_match_device() is for matching dev <-> drv, you meant
pci_match_one_device()]
thanks,
- --
Jiri Slaby www.fi.muni.cz/~xslaby
\_.-^-._ [EMAIL PROTECTED] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEdtY+MsxVwznUen4RAkmFAJ9FFm6nCgnGCdZAcPqv2H99rBNMzwCeK3DA
nPBv8s+ldDrSOpin+mGdDdg=
=MBag
-END PGP SIGNATURE-
-
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: ipv6 routing broken in 2.6.17-rc3,4
In article <[EMAIL PROTECTED]> (at Fri, 26 May 2006 11:35:53 +0300 (EEST)),
Meelis Roos <[EMAIL PROTECTED]> says:
> The unreachable route works now but LAN routing still does not work.
> Locally generated ICMPv6 packets that should go to LAN interface still
> go to tun6to4.
Please try this.
[IPV6] ROUTE: Don't try less preferred routes for on-link routes.
In addition to the real on-link routes, NONEXTHOP routes
should be considered on-link.
Problem reported by Meelis Roos <[EMAIL PROTECTED]>.
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 0190e39..8a77793 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -280,10 +280,13 @@ static int inline rt6_check_neigh(struct
{
struct neighbour *neigh = rt->rt6i_nexthop;
int m = 0;
- if (neigh) {
+ if (rt->rt6i_flags & RTF_NONEXTHOP ||
+ !(rt->rt6i_flags & RTF_GATEWAY))
+ m = 1;
+ else if (neigh) {
read_lock_bh(&neigh->lock);
if (neigh->nud_state & NUD_VALID)
- m = 1;
+ m = 2;
read_unlock_bh(&neigh->lock);
}
return m;
@@ -292,15 +295,18 @@ static int inline rt6_check_neigh(struct
static int rt6_score_route(struct rt6_info *rt, int oif,
int strict)
{
- int m = rt6_check_dev(rt, oif);
+ int m, n;
+
+ m = rt6_check_dev(rt, oif);
if (!m && (strict & RT6_SELECT_F_IFACE))
return -1;
#ifdef CONFIG_IPV6_ROUTER_PREF
m |= IPV6_DECODE_PREF(IPV6_EXTRACT_PREF(rt->rt6i_flags)) << 2;
#endif
- if (rt6_check_neigh(rt))
+ n = rt6_check_neigh(rt);
+ if (n > 1)
m |= 16;
- else if (strict & RT6_SELECT_F_REACHABLE)
+ else if (!n && strict & RT6_SELECT_F_REACHABLE)
return -1;
return m;
}
--yoshfuji
-
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 3/4] myri10ge - Driver core
> > No proper interface exposed, he'll have to do an #ifdef powerpc here or > > such and use __ioremap with explicit page attributes. I have a hack to > > do that automatically for memory covered by prefetchable PCI BARs when > > mmap'ing from userland but not for kernel ioremap. > > Stupid question: pci_iomap() is NOT what you are looking for, right? > > Implementation is at the end of lib/iomap.c No, there is no difference there, pci_iomap won't help for passing in platform specific page attributes for things like write combining. Ben. - 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: reminder, 2.6.18 window...
> The current patch is fine if your hardware implements the required atomicity > itself. Near all do optionally, but it would make increasing the statistics a magnitude more expensive. Atomic operations don't come cheap on modern systems. And you would need to change the fast path increments to atomic for this. I suspect it could be done without atomics with some tricks (e.g. use a double set of counters and switch on clear and use RCU), but it would make the whole thing quite complex and still have more overhead in the fast path than the current code. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] myri10ge - Driver core
Hi there, Benjamin Herrenschmidt wrote: > On Wed, 2006-05-24 at 01:39 +1000, Anton Blanchard wrote: > > > > +#ifdef CONFIG_MTRR > > > + mgp->mtrr = mtrr_add(mgp->iomem_base, mgp->board_span, > > > + MTRR_TYPE_WRCOMB, 1); > > > +#endif > > ... > > > + mgp->sram = ioremap(mgp->iomem_base, mgp->board_span); > > > > Not sure how we are meant to specify write through in drivers. Any ideas > > Ben? > > No proper interface exposed, he'll have to do an #ifdef powerpc here or > such and use __ioremap with explicit page attributes. I have a hack to > do that automatically for memory covered by prefetchable PCI BARs when > mmap'ing from userland but not for kernel ioremap. Stupid question: pci_iomap() is NOT what you are looking for, right? Implementation is at the end of lib/iomap.c Regards Ingo Oeser - 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: reminder, 2.6.18 window...
On Wednesday 24 May 2006 22:08, Jeff Garzik wrote: > Brent Cook wrote: > > Note that this is just clearing the hardware statistics on the interface, > > and > > would not require any kind of atomic_increment addition for interfaces that > > support that. It would be kind-of awkward to implement this on drivers that > > > > increment stats in hardware though (lo, vlan, br, etc.) This also brings up > > the question of resetting the stats for 'netstat -s' > > If you don't atomically clear the statistics, then you are leaving open > a window where the stats could easily be corrupted, if the network > interface is under load. It could be handled by RCU with some moderately complex code (clear and clear again after a RCU quiescent period) But the real problem is that the user will always miss events during the clear operation. That is why it is inherently racy. An atomic user visible get-and-clear wouldn't have this problem, but it would be probably nasty to implement lockless without risking livelock on a busy system. And I also doubt it would have a nice user interface in the file system. And really is it that hard to do a before-after diff? I don't think so. > > See... this opens doors to tons of complexity. Agreed. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
On Wednesday 24 May 2006 10:01, Phil Dibowitz wrote: > David Miller wrote: > > Some time in the next few weeks, it is likely that the 2.6.18 > > merge window will open up shortly after a 2.6.17 release. > > > > So if you have major 2.6.18 submissions planned for the networking, > > you need to start thinking about getting it to me now. > > > > There is a 2.6.18 tree up at: > > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.18.git > > > > All it has right now is the I/O AT stuff at the moment, and I plan to > > put Stephen Hemminger's LLC multicast/datagram changes in there as > > well. > > David, > > I posted a patch for adding support for network device statistic > resetting via ethtool. I saw no objections to it... I think it's a bad idea because it's inherently racey (I think I objected originally too) Similar patches were rejected a couple of times over the years already. > I'd like to get this into 2.6.18. It's self-contained, so it has little > chance of breaking other things and adds a useful feature that I've seen > a lot of requests for. It's broken by design. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] bridge: fix locking and memory leak in br_add_bridge
On Thu, 25 May 2006 09:23:31 -0700, Stephen Hemminger wrote: > + unregister_netdevice(dev); > + err: > rtnl_unlock(); > + if (ret) > + free_netdev(dev); > return ret; I don't think this is correct. netdev_run_todo calls dev->destructor which is set to free_netdev by br_dev_setup. So you're calling free_netdev on already freed device. 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: ipv6 routing broken in 2.6.17-rc3,4
(To YOSHIFUJI Hideaki: this is about the http://comments.gmane.org/gmane.linux.network/35262 thread) : I guess rt6_select() is returning &ip6_null_entry and the caller is finding next best route; e.g. default route. Does this solve your problem? Sorry, typo... The unreachable route works now but LAN routing still does not work. Locally generated ICMPv6 packets that should go to LAN interface still go to tun6to4. -- Meelis Roos ([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: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
Meelis, it would really help if you could try 2.6.16 and in case that doesn't work 2.6.15 to give an idea about whether this is a recent regression or an old problem. We had a number of changes in this area in the last two kernel versions that could be related. Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out remotely at the moment. Will see if I can find the boot cure - there used to be a Motorola Powerstack-specific patch to make it boot that Debian 2.6.18 and IIRC 2.6.12 packages included and that was integrated somewhere later - maybe it's missing fom 2.6.15. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ixgb: driver update to 1.0.104-k4
Kok, Auke wrote: Hi, This is another resend of patches sent earlier by Jeff Kirsher and completes the resend for 1.0.104-kX. Summary: [1] add performance enhancements to the buffer_info struct [2] implement copybreak [3] increment version to 1.0.104-k4 These changes are available through git. git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 ixgb-1.0.104-k4 pulled - 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
