Re: [RFC] new qla3xxx NIC Driver v2.02.00k29
On Wed, 24 May 2006, Jeff Garzik wrote: > >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: > > > >LICENSE.qla3xxx > >qla3xxxsrc-v2.02.00k29.tgz > > > >ftp://ftp.qlogic.com/network/upstream/20.02.00k29/ > > Two points: > > 1) the ftp:// URL doesn't work for me. that should have read as: ftp://ftp.qlogic.com/outgoing/linux/network/upstream/20.02.00k29/qla3xxxsrc-v2.02.00-k29.tgz > 2) Why do we need another license? I believe he is referring to this one: ftp://ftp.qlogic.com/outgoing/linux/network/upstream/2.02.00k19/LICENSE.qla3xxx which is QLogic's boiler-plate license for drivers which support hardware that can potentially be programmed with an external firmware blob. In this case, the QLA3xxx boards currently run with the 'onboard' firmware image. Above and beyond the standard GPL licencing of the driver sources, the license goes further and states that any firmware-blob will be licensed under the three-clause BSD license. This is similar to QLogic's FC driver: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=9e15b4f9cd289f116a1448986847a6313d13bf5f;hb=a8bd60705aa17a998516837d9c1e503ad4cbd7fc;f=Documentation/scsi/LICENSE.qla2xxx -- av - To unsubscribe from this list: send 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...
Brian Haley wrote: > > I don't have any problem with Phil's changes. Thanks Brian, and Andy, and Ben for your support and ideas. > So how is this different than if an SNMP station probes my system, > then I reboot, then they probe again. Things will seem to have gone > backwards, but they deal with that just fine. Right. Reboots, rmmod/modprobe's, etc. can all cause this. Most management interfaces seem to handle such things. > DEC/Compaq/HP has allowed this on Tru64 UNIX since 1999 because we had > customers that wanted it, noone ever complained about complications > with SNMP. We did save the last time the stats were zero'd in the > struct for posterity, but that was never get-able via SNMP: ... > Maybe saving a "ztime" would make people happier? I could certainly do this. It would of course change the structure making the patch slightly more invasive, but it people want this, I can do it. Andy wrote: > On Wed, 2006-05-24 at 14:23 -0400, Jeff Garzik wrote: > >> I disagree that we should bother about clearing statistics. It >> always adds more complication than necessary. Few (if any) other >> statistics in Linux permit easy clearing, > > iptables -Z Good call - I forgot about that. Ben Greear wrote: >> Are SNMP traps generated by going into single-user mode? Rather like >> what I was saying to Brian earlier. I suspect though that an rmmod >> doesn't generate an SNMP trap - unless perhaps that to do the rmmod >> one has to first ifdown the interface and that might? > > If the interface comes back, it will (may?) have a different device id > (if-index), > even if the name is the same. Right - but most GUI management interfaces I've seen key off of interface name *not* ifindex. Certainly Cacti, which I use, does. > Regardless, not everyone uses SNMP, so clearing stats can still be > useful. Even > if it is not implemented perfectly (ie, no locking, so it's possible > that a clear > will not totally clear some stats), it will still be right most of the > time, and > that will help the casual user who is trying to diagnose network errors > with only > console access to the system... (ie, ifconfig -a). Right. I think the point here is that it does _NOT_ inherently break things. If you don't like the behavior, don't run "ethtool -z eth0", it's that simple. A co-worker suggested today, that maybe it'd appease people if the final ethtool patch made it a capitol option that you can only run by itself. I.e. if you can't call it with anything else, it's more difficult to call my accident. I'd be willing to this. As for the clearing, in this case, the clearing is done by a command to the hardware - and I believe the hardware does that atomically. However, I could certainly add a spinlock around it if someone sees a need. -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." - Dr. Seuss signature.asc Description: OpenPGP digital signature
[PATCH] r8169: add new PCI ID
Hi,
This patch add new PCI ID for r8169 driver.
RTL8110SBL has this PCI ID.
Please aply.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -pruN -X tb0287/Documentation/dontdiff tb0287-orig/drivers/net/r8169.c
tb0287/drivers/net/r8169.c
--- tb0287-orig/drivers/net/r8169.c 2006-05-25 10:09:43.981416000 +0900
+++ tb0287/drivers/net/r8169.c 2006-05-25 09:58:45.932290500 +0900
@@ -184,6 +184,7 @@ static const struct {
static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
{ PCI_DEVICE(0x16ec,0x0116), },
{ PCI_VENDOR_ID_LINKSYS,0x1032, PCI_ANY_ID, 0x0024, },
-
To unsubscribe from this list: send 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
Ron Mercer wrote: 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: LICENSE.qla3xxx qla3xxxsrc-v2.02.00k29.tgz ftp://ftp.qlogic.com/network/upstream/20.02.00k29/ Two points: 1) the ftp:// URL doesn't work for me. 2) Why do we need another license? 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 kill pci_find_device
Jiri Slaby wrote:
bcm43xx kill pci_find_device
Change pci_find_device to safer pci_get_device.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 75664d3c6fe1d8d00b87e42cc001cb5d90613dae
tree ebcec31955a991f1661197c7e8bcdd682e030681
parent 431ef31d431939bc9370f952d9510ab9e5b0ad47
author Jiri Slaby <[EMAIL PROTECTED]> Thu, 25 May 2006 02:04:38 +0159
committer Jiri Slaby <[EMAIL PROTECTED]> Thu, 25 May 2006 02:04:38 +0159
drivers/net/wireless/bcm43xx/bcm43xx_main.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index b488f77..f770f59 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2142,9 +2142,10 @@ #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);
+ d = pci_get_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
if (d != NULL) {
bcm->irq = d->irq;
+ pci_dev_put(d);
Given the FIXME, if you are going to touch this area, it seems logical
to add a PCI device match 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
[PATCH 4/4] [IrDA] ali-ircc: using device model power management
This patch gets rid of the old power management code and now uses the
device model for the ali-ircc driver.
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
drivers/net/irda/ali-ircc.c | 106 +--
1 files changed, 51 insertions(+), 55 deletions(-)
3e4b76aae7a8b088e1c8724aaedc1e63eae589a2
diff --git a/drivers/net/irda/ali-ircc.c b/drivers/net/irda/ali-ircc.c
index 2e7882e..bf1fca5 100644
--- a/drivers/net/irda/ali-ircc.c
+++ b/drivers/net/irda/ali-ircc.c
@@ -34,14 +34,12 @@ #include
#include
#include
#include
+#include
#include
#include
#include
-#include
-#include
-
#include
#include
#include
@@ -51,7 +49,19 @@ #include "ali-ircc.h"
#define CHIP_IO_EXTENT 8
#define BROKEN_DONGLE_ID
-static char *driver_name = "ali-ircc";
+#define ALI_IRCC_DRIVER_NAME "ali-ircc"
+
+/* Power Management */
+static int ali_ircc_suspend(struct platform_device *dev, pm_message_t state);
+static int ali_ircc_resume(struct platform_device *dev);
+
+static struct platform_driver ali_ircc_driver = {
+ .suspend= ali_ircc_suspend,
+ .resume = ali_ircc_resume,
+ .driver = {
+ .name = ALI_IRCC_DRIVER_NAME,
+ },
+};
/* Module parameters */
static int qos_mtt_bits = 0x07; /* 1 ms or more */
@@ -97,10 +107,7 @@ static int ali_ircc_is_receiving(struct
static int ali_ircc_net_open(struct net_device *dev);
static int ali_ircc_net_close(struct net_device *dev);
static int ali_ircc_net_ioctl(struct net_device *dev, struct ifreq *rq, int
cmd);
-static int ali_ircc_pmproc(struct pm_dev *dev, pm_request_t rqst, void *data);
static void ali_ircc_change_speed(struct ali_ircc_cb *self, __u32 baud);
-static void ali_ircc_suspend(struct ali_ircc_cb *self);
-static void ali_ircc_wakeup(struct ali_ircc_cb *self);
static struct net_device_stats *ali_ircc_net_get_stats(struct net_device *dev);
/* SIR function */
@@ -145,6 +152,14 @@ static int __init ali_ircc_init(void)
int i = 0;
IRDA_DEBUG(2, "%s(), Start \n",
__FUNCTION__);
+
+ ret = platform_driver_register(&ali_ircc_driver);
+if (ret) {
+IRDA_ERROR("%s, Can't register driver!\n",
+ ALI_IRCC_DRIVER_NAME);
+return ret;
+}
+
/* Probe for all the ALi chipsets we know about */
for (chip= chips; chip->name; chip++, i++)
@@ -214,6 +229,10 @@ static int __init ali_ircc_init(void)
}
IRDA_DEBUG(2, "%s(), - End -\n",
__FUNCTION__);
+
+ if (ret)
+ platform_driver_unregister(&ali_ircc_driver);
+
return ret;
}
@@ -228,14 +247,14 @@ static void __exit ali_ircc_cleanup(void
int i;
IRDA_DEBUG(2, "%s(), Start \n",
__FUNCTION__);
-
- pm_unregister_all(ali_ircc_pmproc);
for (i=0; i < 4; i++) {
if (dev_self[i])
ali_ircc_close(dev_self[i]);
}
+ platform_driver_unregister(&ali_ircc_driver);
+
IRDA_DEBUG(2, "%s(), - End -\n",
__FUNCTION__);
}
@@ -249,7 +268,6 @@ static int ali_ircc_open(int i, chipio_t
{
struct net_device *dev;
struct ali_ircc_cb *self;
- struct pm_dev *pmdev;
int dongle_id;
int err;
@@ -284,7 +302,8 @@ static int ali_ircc_open(int i, chipio_t
self->io.fifo_size = 16; /* SIR: 16, FIR: 32 Benjamin
2000/11/1 */
/* Reserve the ioports that we need */
- if (!request_region(self->io.fir_base, self->io.fir_ext, driver_name)) {
+ if (!request_region(self->io.fir_base, self->io.fir_ext,
+ ALI_IRCC_DRIVER_NAME)) {
IRDA_WARNING("%s(), can't get iobase of 0x%03x\n", __FUNCTION__,
self->io.fir_base);
err = -ENODEV;
@@ -354,13 +373,10 @@ static int ali_ircc_open(int i, chipio_t
/* Check dongle id */
dongle_id = ali_ircc_read_dongle_id(i, info);
- IRDA_MESSAGE("%s(), %s, Found dongle: %s\n", __FUNCTION__, driver_name,
dongle_types[dongle_id]);
+ IRDA_MESSAGE("%s(), %s, Found dongle: %s\n", __FUNCTION__,
+ALI_IRCC_DRIVER_NAME, dongle_types[dongle_id]);
self->io.dongle_id = dongle_id;
-
-pmdev = pm_register(PM_SYS_DEV, PM_SYS_IRDA, ali_ircc_pmproc);
-if (pmdev)
-pmdev->data = self;
IRDA_DEBUG(2, "%s(), - End -\n",
__FUNCTION__);
@@ -548,12 +564,11 @@ static int ali_ircc_setup(chipio_t *info
/* Should be 0x00 in the M1535/M1535D */
if(version != 0x00)
{
- IRDA_ERROR("%s,
[PATCH 3/4] [IrDA] stir4200, switching to the kthread API
stir4200 uses a kernel thread for its TX/RX operations, and it is now
converted to the kernel kthread API.
Tested on an STIR4200 based dongle.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
drivers/net/irda/stir4200.c | 38 ++
1 files changed, 14 insertions(+), 24 deletions(-)
57a09954136abe1a184ff117f92cc7ebd8b93a49
diff --git a/drivers/net/irda/stir4200.c b/drivers/net/irda/stir4200.c
index 31867e4..d61b208 100644
--- a/drivers/net/irda/stir4200.c
+++ b/drivers/net/irda/stir4200.c
@@ -50,6 +50,7 @@ #include
#include
#include
#include
+#include
#include
#include
#include
@@ -173,9 +174,7 @@ struct stir_cb {
struct qos_info qos;
unsigned speed;/* Current speed */
- wait_queue_head_t thr_wait; /* transmit thread wakeup */
- struct completion thr_exited;
- pid_t thr_pid;
+struct task_struct *thread; /* transmit thread */
struct sk_buff*tx_pending;
void *io_buf; /* transmit/receive buffer */
@@ -577,7 +576,7 @@ static int stir_hard_xmit(struct sk_buff
SKB_LINEAR_ASSERT(skb);
skb = xchg(&stir->tx_pending, skb);
- wake_up(&stir->thr_wait);
+wake_up_process(stir->thread);
/* this should never happen unless stop/wakeup problem */
if (unlikely(skb)) {
@@ -753,13 +752,7 @@ static int stir_transmit_thread(void *ar
struct net_device *dev = stir->netdev;
struct sk_buff *skb;
- daemonize("%s", dev->name);
- allow_signal(SIGTERM);
-
- while (netif_running(dev)
- && netif_device_present(dev)
- && !signal_pending(current))
- {
+while (!kthread_should_stop()) {
#ifdef CONFIG_PM
/* if suspending, then power off and wait */
if (unlikely(freezing(current))) {
@@ -813,10 +806,11 @@ #endif
}
/* sleep if nothing to send */
- wait_event_interruptible(stir->thr_wait, stir->tx_pending);
- }
+set_current_state(TASK_INTERRUPTIBLE);
+schedule();
- complete_and_exit (&stir->thr_exited, 0);
+ }
+return 0;
}
@@ -859,7 +853,7 @@ static void stir_rcv_irq(struct urb *urb
warn("%s: usb receive submit error: %d",
stir->netdev->name, err);
stir->receiving = 0;
- wake_up(&stir->thr_wait);
+ wake_up_process(stir->thread);
}
}
@@ -928,10 +922,10 @@ static int stir_net_open(struct net_devi
}
/** Start kernel thread for transmit. */
- stir->thr_pid = kernel_thread(stir_transmit_thread, stir,
- CLONE_FS|CLONE_FILES);
- if (stir->thr_pid < 0) {
- err = stir->thr_pid;
+ stir->thread = kthread_run(stir_transmit_thread, stir,
+ "%s", stir->netdev->name);
+if (IS_ERR(stir->thread)) {
+err = PTR_ERR(stir->thread);
err("stir4200: unable to start kernel thread");
goto err_out6;
}
@@ -968,8 +962,7 @@ static int stir_net_close(struct net_dev
netif_stop_queue(netdev);
/* Kill transmit thread */
- kill_proc(stir->thr_pid, SIGTERM, 1);
- wait_for_completion(&stir->thr_exited);
+ kthread_stop(stir->thread);
kfree(stir->fifo_status);
/* Mop up receive urb's */
@@ -1084,9 +1077,6 @@ static int stir_probe(struct usb_interfa
stir->qos.min_turn_time.bits &= qos_mtt_bits;
irda_qos_bits_to_value(&stir->qos);
- init_completion (&stir->thr_exited);
- init_waitqueue_head (&stir->thr_wait);
-
/* Override the network functions we need to use */
net->hard_start_xmit = stir_hard_xmit;
net->open= stir_net_open;
--
1.3.2
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] [IrDA] Initial support for MCS7780 based dongles
The MosChip MCS7780 chipset is an IrDA USB bridge that
doesn't conform with the IrDA-USB standard and thus needs
its separate driver.
Tested on an actual MCS7780 based dongle.
Original implementation by Brian Pugh <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
drivers/net/irda/Kconfig | 15 +
drivers/net/irda/Makefile |1
drivers/net/irda/mcs7780.c | 1009
drivers/net/irda/mcs7780.h | 167 +++
4 files changed, 1192 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/irda/mcs7780.c
create mode 100644 drivers/net/irda/mcs7780.h
b85118a0356615f60897561812d020a252ee81d0
diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
index cff8598..d2ce489 100644
--- a/drivers/net/irda/Kconfig
+++ b/drivers/net/irda/Kconfig
@@ -417,5 +417,20 @@ config PXA_FICP
available capabilities may vary from one PXA2xx target to
another.
+config MCS_FIR
+ tristate "MosChip MCS7780 IrDA-USB dongle"
+ depends on IRDA && USB && EXPERIMENTAL
+ help
+ Say Y or M here if you want to build support for the MosChip
+ MCS7780 IrDA-USB bridge device driver.
+
+ USB bridge based on the MosChip MCS7780 don't conform to the
+ IrDA-USB device class specification, and therefore need their
+ own specific driver. Those dongles support SIR and FIR (4Mbps)
+ speeds.
+
+ To compile it as a module, choose M here: the module will be called
+ mcs7780.
+
endmenu
diff --git a/drivers/net/irda/Makefile b/drivers/net/irda/Makefile
index c1ce239..5be09f1 100644
--- a/drivers/net/irda/Makefile
+++ b/drivers/net/irda/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_ALI_FIR) += ali-ircc.o
obj-$(CONFIG_VLSI_FIR) += vlsi_ir.o
obj-$(CONFIG_VIA_FIR) += via-ircc.o
obj-$(CONFIG_PXA_FICP) += pxaficp_ir.o
+obj-$(CONFIG_MCS_FIR) += mcs7780.o
# Old dongle drivers for old SIR drivers
obj-$(CONFIG_ESI_DONGLE_OLD) += esi.o
obj-$(CONFIG_TEKRAM_DONGLE_OLD)+= tekram.o
diff --git a/drivers/net/irda/mcs7780.c b/drivers/net/irda/mcs7780.c
new file mode 100644
index 000..efae2aa
--- /dev/null
+++ b/drivers/net/irda/mcs7780.c
@@ -0,0 +1,1009 @@
+/*
+*
+* Filename: mcs7780.c
+* Version: 0.4-alpha
+* Description: Irda MosChip USB Dongle Driver
+* Authors: Lukasz Stelmach <[EMAIL PROTECTED]>
+* Brian Pugh <[EMAIL PROTECTED]>
+* Judy Fischbach <[EMAIL PROTECTED]>
+*
+* Based on stir4200 driver, but some things done differently.
+* Based on earlier driver by Paul Stewart <[EMAIL PROTECTED]>
+*
+* Copyright (C) 2000, Roman Weissgaerber <[EMAIL PROTECTED]>
+* Copyright (C) 2001, Dag Brattli <[EMAIL PROTECTED]>
+* Copyright (C) 2001, Jean Tourrilhes <[EMAIL PROTECTED]>
+* Copyright (C) 2004, Stephen Hemminger <[EMAIL PROTECTED]>
+* Copyright (C) 2005, Lukasz Stelmach <[EMAIL PROTECTED]>
+* Copyright (C) 2005, Brian Pugh <[EMAIL PROTECTED]>
+* Copyright (C) 2005, Judy Fischbach <[EMAIL PROTECTED]>
+*
+* 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+*
+*/
+
+/*
+ * MCS7780 is a simple USB to IrDA bridge by MosChip. It is neither
+ * compatibile with irda-usb nor with stir4200. Although it is quite
+ * similar to the later as far as general idea of operation is concerned.
+ * That is it requires the software to do all the framing job at SIR speeds.
+ * The hardware does take care of the framing at MIR and FIR speeds.
+ * It supports all speeds from 2400 through 4Mbps
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "mcs7780.h"
+
+#define MCS_VENDOR_ID 0x9710
+#define MCS_PRODUCT_ID 0x7780
+
+static struct usb_device_id mcs_table[] = {
+ /* MosChip Corp., MCS7780 FIR-USB Adapter */
+ {USB_DEVICE(MCS_VENDOR_ID, MCS_PRODUCT_ID)},
+ {},
+};
+
+MODULE_AUTHOR("Brian Pugh <[EMAI
[PATCH 1/4] [IrDA] *_DONGLE should depend on IRTTY_SIR
If a SIR dongle is built in the kernel while IRTTY_SIR is built as a module, kernel compilation will fail. Thus, the SIR dongle config should depend on the IRTTY_SIR. Closes kernel bug# 6512 (http://bugzilla.kernel.org/show_bug.cgi?id=6512) Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> --- drivers/net/irda/Kconfig | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) cf17d65eca0463ff3e078fab4db2caac57f5fa46 diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig index 5e6d007..cff8598 100644 --- a/drivers/net/irda/Kconfig +++ b/drivers/net/irda/Kconfig @@ -33,7 +33,7 @@ config DONGLE config ESI_DONGLE tristate "ESI JetEye PC dongle" - depends on DONGLE && IRDA + depends on IRTTY_SIR && DONGLE && IRDA help Say Y here if you want to build support for the Extended Systems JetEye PC dongle. To compile it as a module, choose M here. The ESI @@ -44,7 +44,7 @@ config ESI_DONGLE config ACTISYS_DONGLE tristate "ACTiSYS IR-220L and IR220L+ dongle" - depends on DONGLE && IRDA + depends on IRTTY_SIR && DONGLE && IRDA help Say Y here if you want to build support for the ACTiSYS IR-220L and IR220L+ dongles. To compile it as a module, choose M here. The @@ -55,7 +55,7 @@ config ACTISYS_DONGLE config TEKRAM_DONGLE tristate "Tekram IrMate 210B dongle" - depends on DONGLE && IRDA + depends on IRTTY_SIR && DONGLE && IRDA help Say Y here if you want to build support for the Tekram IrMate 210B dongle. To compile it as a module, choose M here. The Tekram dongle @@ -66,7 +66,7 @@ config TEKRAM_DONGLE config TOIM3232_DONGLE tristate "TOIM3232 IrDa dongle" - depends on DONGLE && IRDA + depends on IRTTY_SIR && DONGLE && IRDA help Say Y here if you want to build support for the Vishay/Temic TOIM3232 and TOIM4232 based dongles. @@ -74,7 +74,7 @@ config TOIM3232_DONGLE config LITELINK_DONGLE tristate "Parallax LiteLink dongle" - depends on DONGLE && IRDA + depends on IRTTY_SIR && DONGLE && IRDA help Say Y here if you want to build support for the Parallax Litelink dongle. To compile it as a module, choose M here. The Parallax @@ -85,7 +85,7 @@ config LITELINK_DONGLE config MA600_DONGLE tristate "Mobile Action MA600 dongle" - depends on DONGLE && IRDA && EXPERIMENTAL + depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL help Say Y here if you want to build support for the Mobile Action MA600 dongle. To compile it as a module, choose M here. The MA600 dongle @@ -98,7 +98,7 @@ config MA600_DONGLE config GIRBIL_DONGLE tristate "Greenwich GIrBIL dongle" - depends on DONGLE && IRDA && EXPERIMENTAL + depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL help Say Y here if you want to build support for the Greenwich GIrBIL dongle. If you want to compile it as a module, choose M here. @@ -109,7 +109,7 @@ config GIRBIL_DONGLE config MCP2120_DONGLE tristate "Microchip MCP2120" - depends on DONGLE && IRDA && EXPERIMENTAL + depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL help Say Y here if you want to build support for the Microchip MCP2120 dongle. If you want to compile it as a module, choose M here. @@ -123,7 +123,7 @@ config MCP2120_DONGLE config OLD_BELKIN_DONGLE tristate "Old Belkin dongle" - depends on DONGLE && IRDA && EXPERIMENTAL + depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL help Say Y here if you want to build support for the Adaptec Airport 1000 and 2000 dongles. If you want to compile it as a module, choose @@ -132,7 +132,7 @@ config OLD_BELKIN_DONGLE config ACT200L_DONGLE tristate "ACTiSYS IR-200L dongle" - depends on DONGLE && IRDA && EXPERIMENTAL + depends on IRTTY_SIR && DONGLE && IRDA && EXPERIMENTAL help Say Y here if you want to build support for the ACTiSYS IR-200L dongle. If you want to compile it as a module, choose M here. -- 1.3.2 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] new qla3xxx NIC Driver v2.02.00k29
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: LICENSE.qla3xxx qla3xxxsrc-v2.02.00k29.tgz ftp://ftp.qlogic.com/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
Re: [PATCH 2/4] b44: wol setup for older 4401
On Thu, 2006-05-25 at 00:13 +0200, Francois Romieu wrote:
> > + pwol_pattern = kmalloc(B44_WOL_PATTERN_SIZE, GFP_KERNEL);
> > + pwol_mask = kmalloc(B44_WOL_MASK_SIZE, GFP_KERNEL);
> > +
> kmalloc can fail. It should be checked.
Yep. Thanks.
> > + max = ETH_ALEN;
> > + for (i = 0; i < 14; ++i) {
> > + if (i == 13)
> > + max = 2;
> > + for (j = 0; j < max; ++j) {
> > + pwol_pattern[42 + 6 +
> > + (i * ETH_ALEN) + j] =
> > + bp->dev->dev_addr[j];
>
> Indentation went strange here.
>
Will adjust.
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
Re: [PATCH 2/4] b44: wol setup for older 4401
Gary Zambrano <[EMAIL PROTECTED]> :
[...]
> diff --git a/drivers/net/b44.c b/drivers/net/b44.c
> index b9e2462..6f4d1d4 100644
> --- a/drivers/net/b44.c
> +++ b/drivers/net/b44.c
[...]
> +static void b44_setup_pseudo_magicp(struct b44 *bp)
> +{
> +
> + u32 val;
> + int plen0, plen1, max, i, j;
> + u8 *pwol_pattern;
> + u8 *pwol_mask;
> +
> + pwol_pattern = kmalloc(B44_WOL_PATTERN_SIZE, GFP_KERNEL);
> + pwol_mask = kmalloc(B44_WOL_MASK_SIZE, GFP_KERNEL);
> +
> + /* UDP magic packet pattern */
> + memset(pwol_pattern, 0, B44_WOL_PATTERN_SIZE);
> + memset(pwol_pattern + 42, 0xff, 6); /* sync pattern */
kmalloc can fail. It should be checked.
> + max = ETH_ALEN;
> + for (i = 0; i < 14; ++i) {
> + if (i == 13)
> + max = 2;
> + for (j = 0; j < max; ++j) {
> + pwol_pattern[42 + 6 +
> + (i * ETH_ALEN) + j] =
> + bp->dev->dev_addr[j];
Indentation went strange here.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] b44: add wol and setup for later 4401
Gary Zambrano <[EMAIL PROTECTED]> :
>
> This patch adds set and get functions and support for the later 4401 revs.
>
> Signed-off-by: Gary Zambrano <[EMAIL PROTECTED]>
>
> diff --git a/drivers/net/b44.c b/drivers/net/b44.c
> index 7b3dfc4..e42e0aa 100644
> --- a/drivers/net/b44.c
> +++ b/drivers/net/b44.c
[...]
> @@ -1467,6 +1510,11 @@ static int b44_close(struct net_device *
>
> netif_poll_enable(dev);
>
> + if (bp->flags & B44_FLAG_WOL_ENABLE){
> + b44_init_hw(bp);
> + b44_setup_wol(bp);
> + }
> +
> b44_free_consistent(bp);
>
> return 0;
Should b44_setup_wol() not be used in b44_suspend() as well ?
(nit: s/){/) {/)
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] b44: add parameter to init_hw for wol
This patch adds a parameter to init_hw() for wol.
Signed-off-by: Gary Zambrano <[EMAIL PROTECTED]>
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 81d1f36..6eea1fc 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -107,7 +107,7 @@ MODULE_DEVICE_TABLE(pci, b44_pci_tbl);
static void b44_halt(struct b44 *);
static void b44_init_rings(struct b44 *);
-static void b44_init_hw(struct b44 *);
+static void b44_init_hw(struct b44 *, int);
static int dma_desc_align_mask;
static int dma_desc_sync_size;
@@ -875,7 +875,7 @@ static int b44_poll(struct net_device *n
spin_lock_irq(&bp->lock);
b44_halt(bp);
b44_init_rings(bp);
- b44_init_hw(bp);
+ b44_init_hw(bp, 1);
netif_wake_queue(bp->dev);
spin_unlock_irq(&bp->lock);
done = 1;
@@ -944,7 +944,7 @@ static void b44_tx_timeout(struct net_de
b44_halt(bp);
b44_init_rings(bp);
- b44_init_hw(bp);
+ b44_init_hw(bp, 1);
spin_unlock_irq(&bp->lock);
@@ -1059,7 +1059,7 @@ static int b44_change_mtu(struct net_dev
b44_halt(bp);
dev->mtu = new_mtu;
b44_init_rings(bp);
- b44_init_hw(bp);
+ b44_init_hw(bp, 1);
spin_unlock_irq(&bp->lock);
b44_enable_ints(bp);
@@ -1354,14 +1354,15 @@ static int b44_set_mac_addr(struct net_d
* packet processing. Invoked with bp->lock held.
*/
static void __b44_set_rx_mode(struct net_device *);
-static void b44_init_hw(struct b44 *bp)
+static void b44_init_hw(struct b44 *bp, int full)
{
u32 val;
b44_chip_reset(bp);
- b44_phy_reset(bp);
- b44_setup_phy(bp);
-
+ if (full) {
+ b44_phy_reset(bp);
+ b44_setup_phy(bp);
+ }
/* Enable CRC32, set proper LED modes and power on PHY */
bw32(bp, B44_MAC_CTRL, MAC_CTRL_CRC32_ENAB | MAC_CTRL_PHY_LEDCTRL);
bw32(bp, B44_RCV_LAZY, (1 << RCV_LAZY_FC_SHIFT));
@@ -1374,16 +1375,21 @@ static void b44_init_hw(struct b44 *bp)
bw32(bp, B44_TXMAXLEN, bp->dev->mtu + ETH_HLEN + 8 + RX_HEADER_LEN);
bw32(bp, B44_TX_WMARK, 56); /* XXX magic */
- bw32(bp, B44_DMATX_CTRL, DMATX_CTRL_ENABLE);
- bw32(bp, B44_DMATX_ADDR, bp->tx_ring_dma + bp->dma_offset);
- bw32(bp, B44_DMARX_CTRL, (DMARX_CTRL_ENABLE |
+ if (full){
+ bw32(bp, B44_DMATX_CTRL, DMATX_CTRL_ENABLE);
+ bw32(bp, B44_DMATX_ADDR, bp->tx_ring_dma + bp->dma_offset);
+ bw32(bp, B44_DMARX_CTRL, (DMARX_CTRL_ENABLE |
(bp->rx_offset << DMARX_CTRL_ROSHIFT)));
- bw32(bp, B44_DMARX_ADDR, bp->rx_ring_dma + bp->dma_offset);
+ bw32(bp, B44_DMARX_ADDR, bp->rx_ring_dma + bp->dma_offset);
- bw32(bp, B44_DMARX_PTR, bp->rx_pending);
- bp->rx_prod = bp->rx_pending;
+ bw32(bp, B44_DMARX_PTR, bp->rx_pending);
+ bp->rx_prod = bp->rx_pending;
- bw32(bp, B44_MIB_CTRL, MIB_CTRL_CLR_ON_READ);
+ bw32(bp, B44_MIB_CTRL, MIB_CTRL_CLR_ON_READ);
+ }else{
+ bw32(bp, B44_DMARX_CTRL, (DMARX_CTRL_ENABLE |
+ (bp->rx_offset << DMARX_CTRL_ROSHIFT)));
+ }
val = br32(bp, B44_ENET_CTRL);
bw32(bp, B44_ENET_CTRL, (val | ENET_CTRL_ENABLE));
@@ -1399,7 +1405,7 @@ static int b44_open(struct net_device *d
goto out;
b44_init_rings(bp);
- b44_init_hw(bp);
+ b44_init_hw(bp, 1);
b44_check_phy(bp);
@@ -1598,7 +1604,7 @@ static int b44_close(struct net_device *
netif_poll_enable(dev);
if (bp->flags & B44_FLAG_WOL_ENABLE){
- b44_init_hw(bp);
+ b44_init_hw(bp, 0);
b44_setup_wol(bp);
}
@@ -1860,7 +1866,7 @@ static int b44_set_ringparam(struct net_
b44_halt(bp);
b44_init_rings(bp);
- b44_init_hw(bp);
+ b44_init_hw(bp, 1);
netif_wake_queue(bp->dev);
spin_unlock_irq(&bp->lock);
@@ -1903,7 +1909,7 @@ static int b44_set_pauseparam(struct net
if (bp->flags & B44_FLAG_PAUSE_AUTO) {
b44_halt(bp);
b44_init_rings(bp);
- b44_init_hw(bp);
+ b44_init_hw(bp, 1);
} else {
__b44_set_flow_ctrl(bp, bp->flags);
}
@@ -2281,7 +2287,7 @@ static int b44_resume(struct pci_dev *pd
spin_lock_irq(&bp->lock);
b44_init_rings(bp);
- b44_init_hw(bp);
+ b44_init_hw(bp, 1);
netif_device_attach(bp->dev);
spin_unlock_irq(&bp->lock);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] b44: add wol and setup for later 4401
This patch adds set and get functions and support for the later 4401 revs.
Signed-off-by: Gary Zambrano <[EMAIL PROTECTED]>
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 7b3dfc4..e42e0aa 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -75,6 +75,12 @@
/* minimum number of free TX descriptors required to wake up TX process */
#define B44_TX_WAKEUP_THRESH (B44_TX_RING_SIZE / 4)
+/* b44 internal pattern match filter info */
+#define B44_WOL_PATTERN_BASE 0x400
+#define B44_WOL_PATTERN_SIZE 0x80
+#define B44_WOL_MASK_BASE 0x600
+#define B44_WOL_MASK_SIZE 0x10
+
static char version[] __devinitdata =
DRV_MODULE_NAME ".c:v" DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
@@ -1442,6 +1448,43 @@ static void b44_poll_controller(struct n
}
#endif
+
+static void b44_setup_wol(struct b44 *bp)
+{
+ u32 val;
+ u16 pmval;
+
+ bw32(bp, B44_RXCONFIG, RXCONFIG_ALLMULTI);
+
+ if (bp->flags & B44_FLAG_B0_ANDLATER) {
+
+ bw32 (bp, B44_WKUP_LEN, WKUP_LEN_DISABLE);
+
+ val = bp->dev->dev_addr[2] << 24 |
+ bp->dev->dev_addr[3] << 16 |
+ bp->dev->dev_addr[4] << 8 |
+ bp->dev->dev_addr[5];
+ bw32(bp, B44_ADDR_LO, val);
+
+ val = bp->dev->dev_addr[0] << 8 |
+ bp->dev->dev_addr[1];
+ bw32(bp, B44_ADDR_HI, val);
+
+ val = br32(bp, B44_DEVCTRL);
+ bw32(bp, B44_DEVCTRL, val | DEVCTRL_MPM | DEVCTRL_PFE);
+
+ } else {
+ b44_setup_pseudo_magicp(bp);
+ }
+
+ val = br32(bp, B44_SBTMSLOW);
+ bw32(bp, B44_SBTMSLOW, val | SBTMSLOW_PE);
+
+ pci_read_config_word(bp->pdev, SSB_PMCSR, &pmval);
+ pci_write_config_word(bp->pdev, SSB_PMCSR, pmval | SSB_PE);
+
+}
+
static int b44_close(struct net_device *dev)
{
struct b44 *bp = netdev_priv(dev);
@@ -1467,6 +1510,11 @@ static int b44_close(struct net_device *
netif_poll_enable(dev);
+ if (bp->flags & B44_FLAG_WOL_ENABLE){
+ b44_init_hw(bp);
+ b44_setup_wol(bp);
+ }
+
b44_free_consistent(bp);
return 0;
@@ -1810,12 +1858,38 @@ static void b44_get_ethtool_stats(struct
spin_unlock_irq(&bp->lock);
}
+static void b44_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct b44 *bp = netdev_priv(dev);
+
+ wol->supported = WAKE_MAGIC;
+ if (bp->flags & B44_FLAG_WOL_ENABLE)
+ wol->wolopts = WAKE_MAGIC;
+ else
+ wol->wolopts = 0;
+ memset(&wol->sopass, 0, sizeof(wol->sopass));
+}
+
+static int b44_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ struct b44 *bp = netdev_priv(dev);
+
+ if (wol->wolopts & WAKE_MAGIC)
+ bp->flags |= B44_FLAG_WOL_ENABLE;
+ else
+ bp->flags &= ~B44_FLAG_WOL_ENABLE;
+
+ return 0;
+}
+
static struct ethtool_ops b44_ethtool_ops = {
.get_drvinfo= b44_get_drvinfo,
.get_settings = b44_get_settings,
.set_settings = b44_set_settings,
.nway_reset = b44_nway_reset,
.get_link = ethtool_op_get_link,
+ .get_wol= b44_get_wol,
+ .set_wol= b44_set_wol,
.get_ringparam = b44_get_ringparam,
.set_ringparam = b44_set_ringparam,
.get_pauseparam = b44_get_pauseparam,
@@ -1894,6 +1968,10 @@ static int __devinit b44_get_invariants(
/* XXX - really required?
bp->flags |= B44_FLAG_BUGGY_TXPTR;
*/
+
+ if (ssb_get_core_rev(bp) >= 7)
+ bp->flags |= B44_FLAG_B0_ANDLATER;
+
out:
return err;
}
diff --git a/drivers/net/b44.h b/drivers/net/b44.h
index b178662..18baa19 100644
--- a/drivers/net/b44.h
+++ b/drivers/net/b44.h
@@ -24,6 +24,8 @@
#define WKUP_LEN_P3_MASK 0x7f00 /* Pattern 3 */
#define WKUP_LEN_P3_SHIFT 24
#define WKUP_LEN_D3 0x8000
+#define WKUP_LEN_DISABLE 0x80808080
+#define WKUP_LEN_ENABLE_TWO 0x8080
#define B44_ISTAT 0x0020UL /* Interrupt Status */
#define ISTAT_LS 0x0020 /* Link Change (B0 only) */
#define ISTAT_PME 0x0040 /* Power Management Event */
@@ -264,6 +266,8 @@
#define SBIDHIGH_VC_SHIFT 16
/* SSB PCI config space registers. */
+#define SSB_PMCSR 0x44
+#define SSB_PE0x100
#defineSSB_BAR0_WIN0x80
#defineSSB_BAR1_WIN0x84
#defineSSB_SPROM_CONTROL 0x88
@@ -420,6 +424,7 @@ struct b44 {
u32 dma_offset;
u32 flags;
+#define B44_FLAG_B0_ANDLATER 0x0001
#define B44_FLAG_BUGGY_TXPTR 0x0002
#define B44_FLAG_REORDER_BUG 0x0004
#define B44_FLAG_PAUSE_AUTO
[PATCH 2/4] b44: wol setup for older 4401
This patch adds wol support for the older 4401 revs.
Signed-off-by: Gary Zambrano <[EMAIL PROTECTED]>
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index b9e2462..6f4d1d4 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -1448,6 +1448,93 @@ static void b44_poll_controller(struct n
}
#endif
+static inline void bwfilter_table(struct b44 *bp,
+ u32 *pattern,
+ u32 bytes,
+ u32 table_offset)
+{
+ u32 i;
+
+ for (i = 0; i < bytes; i += sizeof(u32)) {
+ bw32(bp, B44_FILT_ADDR, table_offset + i);
+ bw32(bp, B44_FILT_DATA, pattern[i / sizeof(u32)]);
+ }
+}
+
+/* Setup two common magic packet patterns in the b44 WOL
+ * pattern matching filter.
+ */
+static void b44_setup_pseudo_magicp(struct b44 *bp)
+{
+
+ u32 val;
+ int plen0, plen1, max, i, j;
+ u8 *pwol_pattern;
+ u8 *pwol_mask;
+
+ pwol_pattern = kmalloc(B44_WOL_PATTERN_SIZE, GFP_KERNEL);
+ pwol_mask = kmalloc(B44_WOL_MASK_SIZE, GFP_KERNEL);
+
+ /* UDP magic packet pattern */
+ memset(pwol_pattern, 0, B44_WOL_PATTERN_SIZE);
+ memset(pwol_pattern + 42, 0xff, 6); /* sync pattern */
+ max = ETH_ALEN;
+ for (i = 0; i < 14; ++i) {
+ if (i == 13)
+ max = 2;
+ for (j = 0; j < max; ++j) {
+ pwol_pattern[42 + 6 +
+ (i * ETH_ALEN) + j] =
+ bp->dev->dev_addr[j];
+ }
+ }
+
+ memset(pwol_mask, 0, B44_WOL_MASK_SIZE);
+ pwol_mask[5] = 0xfc;
+ memset(pwol_mask + 6, 0xff, 10);
+ plen0 = B44_WOL_PATTERN_SIZE - 1;
+
+ bwfilter_table(bp, (u32 *)pwol_pattern,
+ B44_WOL_PATTERN_SIZE, B44_WOL_PATTERN_BASE);
+
+ bwfilter_table(bp, (u32 *)pwol_mask,
+ B44_WOL_MASK_SIZE, B44_WOL_MASK_BASE);
+
+ /* raw ethernet II magic packet pattern */
+ memset(pwol_pattern, 0, B44_WOL_PATTERN_SIZE);
+ memset(pwol_pattern + 14, 0xff, 6); /* sync pattern */
+ max = ETH_ALEN;
+ for (i = 0; i < 16; ++i) {
+ for (j = 0; j < max; ++j) {
+ pwol_pattern[14 + 6 +
+ (i * ETH_ALEN) + j] =
+ bp->dev->dev_addr[j];
+ }
+ }
+
+ memset(pwol_mask, 0, B44_WOL_MASK_SIZE);
+ pwol_mask[2] = 0xf0;
+ memset(pwol_mask + 3, 0xff, 11);
+ pwol_mask[14] = 0xf;
+ plen1 = 14 + 6 + 96 - 1;
+
+ bwfilter_table(bp, (u32 *)pwol_pattern, B44_WOL_PATTERN_SIZE,
+ B44_WOL_PATTERN_BASE + B44_WOL_PATTERN_SIZE);
+ bwfilter_table(bp, (u32 *)pwol_mask, B44_WOL_MASK_SIZE,
+ B44_WOL_MASK_BASE + B44_WOL_MASK_SIZE);
+
+ /* set this pattern's length: one less than the real length */
+ val = plen0 | (plen1 << 8) | WKUP_LEN_ENABLE_TWO;
+ bw32(bp, B44_WKUP_LEN, val);
+
+ /* enable chip wakeup pattern matching */
+ val = br32(bp, B44_DEVCTRL);
+ bw32(bp, B44_DEVCTRL, val | DEVCTRL_PFE);
+
+ kfree(pwol_mask);
+ kfree(pwol_pattern);
+
+}
static void b44_setup_wol(struct b44 *bp)
{
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
spidernet: replace whitespaces by tabs
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]>
Index: linux-2.6.17-rc4/drivers/net/sungem_phy.c
===
--- linux-2.6.17-rc4.orig/drivers/net/sungem_phy.c
+++ linux-2.6.17-rc4/drivers/net/sungem_phy.c
@@ -345,9 +345,9 @@ static int bcm5421_enable_fiber(struct m
static int bcm5461_enable_fiber(struct mii_phy* phy)
{
-phy_write(phy, MII_NCONFIG, 0xfc0c);
-phy_write(phy, MII_BMCR, 0x4140);
-phy_write(phy, MII_NCONFIG, 0xfc0b);
+ phy_write(phy, MII_NCONFIG, 0xfc0c);
+ phy_write(phy, MII_BMCR, 0x4140);
+ phy_write(phy, MII_NCONFIG, 0xfc0b);
phy_write(phy, MII_BMCR, 0x0140);
return 0;
-
To unsubscribe from this list: send 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] spidernet: enable support for bcm5461 ethernet phy
Jeff Garzik <[EMAIL PROTECTED]> wrote on 05/24/2006 07:29:24 AM: > NAK, failed to apply. Also, the whitespace above is borked. I think the patch is already in 2.6.17-rc4. I will send send a patch to turn the whitespaces into tabs. Jens - To unsubscribe from this list: send 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, > We didn't get any ppc64 with PCI-E to run Linux so far. What performance > drop should we expect with our current code ? We have seen > 20% improvement on ppc64 running some networking workloads when forcing 128 byte alignment (instead of 16 byte alignment). DMA writes have to get cacheline aligned (in power of 2 steps) on some IO chips. > I am not sure what you mean. > The only ppc64 with PCI-E that we have seen so far (a G5) couldn't do > write combining according to Apple. Im thinking more generally, MTRRs are x86 specific and it would be good to have a more generic way to enable write combining. Anton - To unsubscribe from this list: send 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...
Rick Jones wrote: Phil Dibowitz wrote: Does having the ability to boot into single user mode break networking? No, it *allows* you to break networking. Does the _support_ of rmmod break the kernel? No, but it *allows* you to. Are SNMP traps generated by going into single-user mode? Rather like what I was saying to Brian earlier. I suspect though that an rmmod doesn't generate an SNMP trap - unless perhaps that to do the rmmod one has to first ifdown the interface and that might? If the interface comes back, it will (may?) have a different device id (if-index), even if the name is the same. Regardless, not everyone uses SNMP, so clearing stats can still be useful. Even if it is not implemented perfectly (ie, no locking, so it's possible that a clear will not totally clear some stats), it will still be right most of the time, and that will help the casual user who is trying to diagnose network errors with only console access to the system... (ie, ifconfig -a). Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
Phil Dibowitz wrote: Well, I can show you support on my home switch (cabletron) - the network guys will be a little unhappy if I clear stats on our production network (cisco) without warning them: Isn't that last bit an example of why it might not be good to play-out that rope?-) Does having the ability to boot into single user mode break networking? No, it *allows* you to break networking. Does the _support_ of rmmod break the kernel? No, but it *allows* you to. Are SNMP traps generated by going into single-user mode? Rather like what I was saying to Brian earlier. I suspect though that an rmmod doesn't generate an SNMP trap - unless perhaps that to do the rmmod one has to first ifdown the interface and that might? rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
So how is this different than if an SNMP station probes my system, then I reboot, then they probe again. Things will seem to have gone backwards, but they deal with that just fine. In that case hasn't the system's uptime and/or last boot time in the MIB changed and so indicates to the management station that it has been rebooted? It is also possible that the shutdown procedures or the rebooting procedures would have generated an SNMP trap to the management station(s) informing them of the reboot. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
On Wed, 2006-05-24 at 14:23 -0400, Jeff Garzik wrote: > I disagree that we should bother about clearing statistics. It always > adds more complication than necessary. Few (if any) other statistics in > Linux permit easy clearing, iptables -Z > often because adding operations other than > 'increment' or 'read' requires adding expensive spinlocks or atomic > operations. Why is 'set to N' so different from 'increment'? - Andy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
Hi! > FLAME stands for "Forwarding Layer for Meshing" > > FLAME provides an intermediate layer between the network > layer (e.g. IPv4/IPv6) and the link (MAC) layer, > providing L2.5 meshing. Both network layer and MAC layer What is wrong with meshing on L3? (It is called flame so lets at least have nice flamewar :-) Pavel -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send 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 Wed, May 24, 2006 at 04:10:32PM -0400, jamal wrote: > Can you provide some link to a vendor that allows resetting ethernet > stats? I am almost certain, if they do they will have something or other > which indicates that such a reset happened. It is also easier for cisco > to have none standard feature "as of ios 15.16" which could support such > behavior because they bundle everything including network management > tools. We dont have that luxury. The BSDs may actually get away with it > because they bundle user space apps as well. Perhaps some > random Linux vendor as well.. Well, I can show you support on my home switch (cabletron) - the network guys will be a little unhappy if I clear stats on our production network (cisco) without warning them: * Cabletron Systems ELS100-24TXG SWITCH STATISTICS Access Control: READ/WRITE IDTRANSMITTEDRECEIVED FORWARDEDFILTERED DROPPED ERRORED - 11322815 1614038 1614038 0 0 51562 220670321814254518142349 0 196 0 3 17487573 1011964 1011964 0 0 0 4 18247 20528 20528 0 0 0 5 38775 0 0 0 0 0 6 38775 0 0 0 0 0 7 38775 0 0 0 0 0 8 38775 0 0 0 0 0 9 38820 0 0 0 0 0 10 38820 0 0 0 0 0 n. Next Pagep. Previous Pagef. First Pagel. Last Page s. Switch Summary d. Port Statistics t. Trunking Statistics r. Refresh c. Clear x. Previous Menu Enter Selection:c * Cabletron Systems ELS100-24TXG SWITCH STATISTICS Access Control: READ/WRITE IDTRANSMITTEDRECEIVED FORWARDEDFILTERED DROPPED ERRORED - 1 0 0 0 0 0 0 2 0 0 0 0 0 0 3 0 0 0 0 0 0 4 0 0 0 0 0 0 5 0 0 0 0 0 0 6 0 0 0 0 0 0 7 0 0 0 0 0 0 8 0 0 0 0 0 0 9 0 0 0 0 0 0 10 0 0 0 0 0 0 n. Next Pagep. Previous Pagef. First Pagel. Last Page s. Switch Summary d. Port Statistics t. Trunking Statistics r. Refresh c. Clear x. Previous Menu Enter Selection: > > If my patch was invasive and broke things, > > It _does break_ things for all known management apps. > This is not to say it is not useful for testing, development or > debugging (which is what you seem to be using it for) but it does mean > it is broken. Does having the ability to boot into single user mode break networking? No, it *allows* you to break networking. Does the _support_ of rmmod break the kernel? No, but it *allows* you to. Same thing here. The patch breaks nothing, it provides a tool that if used without proper understanding, could break things. Just like almost any other feature in the kernel. -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759 signature.asc Description: Digital signature
Re: reminder, 2.6.18 window...
jamal wrote: On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote: Right, I'm aware there are other ways of doing this - I've written scripts to record a hundreds of numbers, and then subtract them from each other. But those scripts are work arounds I don't have any problem with Phil's changes. It is not a work around, _it is design intent_. It is what network management tools have been expecting since the days of the caveman. These stats are supposed to be monotonically increasing; if that behavior is contradicted, a rollover of the counters is assumed. So how is this different than if an SNMP station probes my system, then I reboot, then they probe again. Things will seem to have gone backwards, but they deal with that just fine. for a feature _lacking_ in the kernel. A feature that, as I've mentioned, is supported on any piece of networking gear (and of course, lets not forget there's a specific option in the kernel config *just* for "behave like a router"). Can you provide some link to a vendor that allows resetting ethernet stats? I am almost certain, if they do they will have something or other which indicates that such a reset happened. DEC/Compaq/HP has allowed this on Tru64 UNIX since 1999 because we had customers that wanted it, noone ever complained about complications with SNMP. We did save the last time the stats were zero'd in the struct for posterity, but that was never get-able via SNMP: --> netstat -I tu0 -s tu0 Ethernet counters at Wed May 24 16:30:05 2006 609415 seconds since last zeroed 3943458720 bytes received 113576310 bytes sent ... Maybe saving a "ztime" would make people happier? It is also easier for cisco to have none standard feature "as of ios 15.16" which could support such behavior because they bundle everything including network management tools. I never received any free management tools with my Cisco routers :) , they charge big bucks for that stuff! If my patch was invasive and broke things, It _does break_ things for all known management apps. Can anyone show a management app this breaks? -Brian - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
Can you provide some link to a vendor that allows resetting ethernet stats? I am almost certain, if they do they will have something or other which indicates that such a reset happened. It is also easier for cisco to have none standard feature "as of ios 15.16" which could support such behavior because they bundle everything including network management tools. We dont have that luxury. The BSDs may actually get away with it because they bundle user space apps as well. Perhaps some random Linux vendor as well.. The lanadmin (think ethtool) command of HP-UX has had a way to clear the statistics reported by lanadmin. I do not know however, if that affects the stats in the actual SNMP interface MIBs as I've never had occasion to look. I still suggest beforeafter to people because clearing the lanadmin stats requires root privs and because it may not be a kosher thing to do on a customer system. HP-UX does not provide a way to clear the stats reported by netstat. fwiw, rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote: > > Right, I'm aware there are other ways of doing this - I've written scripts to > record a hundreds of numbers, and then subtract them from each other. But > those scripts are work arounds It is not a work around, _it is design intent_. It is what network management tools have been expecting since the days of the caveman. These stats are supposed to be monotonically increasing; if that behavior is contradicted, a rollover of the counters is assumed. > for a feature _lacking_ in the kernel. A > feature that, as I've mentioned, is supported on any piece of networking gear > (and of course, lets not forget there's a specific option in the kernel config > *just* for "behave like a router"). Can you provide some link to a vendor that allows resetting ethernet stats? I am almost certain, if they do they will have something or other which indicates that such a reset happened. It is also easier for cisco to have none standard feature "as of ios 15.16" which could support such behavior because they bundle everything including network management tools. We dont have that luxury. The BSDs may actually get away with it because they bundle user space apps as well. Perhaps some random Linux vendor as well.. > If my patch was invasive and broke things, It _does break_ things for all known management apps. This is not to say it is not useful for testing, development or debugging (which is what you seem to be using it for) but it does mean it is broken. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
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. This 'clearing' operation has implications on the rest of the statistics usage. More complexity, and breaking of apps, when we could just use the existing, working system? I'll take the "do nothing, break nothing, everything still works" route any day. What would be great is if ifconfig, netstat and their ilk just had a -z flag instead. This would write a file to the local user's home directory with a stats snapshot, and then every subsequent run would auto-calculate against the snapshot. You'd also need some way of resetting this when the stats actually _do_ reset (driver reload, reboot.) to avoid negative numbers. That way, you can get what you want without having to write a bunch of fragile, awkward scripts, and the kernel isn't throwing away information either. See... this opens doors to tons of complexity. 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: reminder, 2.6.18 window...
On Wednesday 24 May 2006 14:14, Phil Dibowitz wrote: > On Wed, May 24, 2006 at 03:05:54PM -0400, Jeff Garzik wrote: > > Phil Dibowitz wrote: > > Given any method of clearing statistics across your cluster, I'm certain > > you can come up with a similar method of obtaining the current statistic > > (the baseline). > > Right, I'm aware there are other ways of doing this - I've written scripts > to record a hundreds of numbers, and then subtract them from each other. > But those scripts are work arounds for a feature _lacking_ in the kernel. A > feature that, as I've mentioned, is supported on any piece of networking > gear (and of course, lets not forget there's a specific option in the > kernel config *just* for "behave like a router"). > > If my patch was invasive and broke things, I would understand the > hesitation, but this is a feature that allows people to *choose* to do this > if they need to and the code is pretty self-contained. I'm with you - this is a useful feature! But there aren't many other things I've found that can be cleared from the kernel other than by reloading a module, and dmesg -c. I think the object here isn't this particular patch, but the can-of-worms that it opens up. 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' What would be great is if ifconfig, netstat and their ilk just had a -z flag instead. This would write a file to the local user's home directory with a stats snapshot, and then every subsequent run would auto-calculate against the snapshot. You'd also need some way of resetting this when the stats actually _do_ reset (driver reload, reboot.) to avoid negative numbers. That way, you can get what you want without having to write a bunch of fragile, awkward scripts, and the kernel isn't throwing away information either. - Brent - To unsubscribe from this list: send 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 Wed, May 24, 2006 at 03:05:54PM -0400, Jeff Garzik wrote: > Phil Dibowitz wrote: > >On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote: > >>I disagree that we should bother about clearing statistics. It always > >>adds more complication than necessary. Few (if any) other statistics in > >>Linux permit easy clearing, often because adding operations other than > >>'increment' or 'read' requires adding expensive spinlocks or atomic > >>operations. > > > >Every networking device in the world supports clearing interface > >statistics. > >Why should linux not be able to do the most basic operation on any > >cisco/juniper/enterasys/whatever managed switch or router? > > > >It's a common operation on a network interface, I don't see why this is a > >concern. > > > >When I'm debugging a networking issue On a cluster of hundreds and hundreds > >of machines at work, I want to be able to reset them all quickly, and get a > >rough idea of if they're all climbing, if they're all climbing at the same > >rate, etc. And being able to do "for i in `cat hostlist`; do ssh $i > >ethtool -z > >eth0; done" is really, really, REALLY, useful. > > Obtaining the difference between two numbers is not that difficult. > > Given any method of clearing statistics across your cluster, I'm certain > you can come up with a similar method of obtaining the current statistic > (the baseline). Right, I'm aware there are other ways of doing this - I've written scripts to record a hundreds of numbers, and then subtract them from each other. But those scripts are work arounds for a feature _lacking_ in the kernel. A feature that, as I've mentioned, is supported on any piece of networking gear (and of course, lets not forget there's a specific option in the kernel config *just* for "behave like a router"). If my patch was invasive and broke things, I would understand the hesitation, but this is a feature that allows people to *choose* to do this if they need to and the code is pretty self-contained. -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759 signature.asc Description: Digital signature
Re: r8169 cardbus device naming weirdness
On Tue, May 23, 2006 at 10:51:08AM -0700, Stephen Hemminger wrote: > > Most likely some user space script is renaming it. > Each distro seems to have it's own way of doing configuration, and most > do something in response to the hotplug event from device registration. > So it was eth1 until what ever ran in response to the hotplug event > decide to change it. of course you're right. /me fist shakes at udev mh -- Martin Hicks || [EMAIL PROTECTED] || PGP/GnuPG: 0x4C7F2BEE - To unsubscribe from this list: send 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...
Phil Dibowitz wrote: On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote: I disagree that we should bother about clearing statistics. It always adds more complication than necessary. Few (if any) other statistics in Linux permit easy clearing, often because adding operations other than 'increment' or 'read' requires adding expensive spinlocks or atomic operations. Every networking device in the world supports clearing interface statistics. Why should linux not be able to do the most basic operation on any cisco/juniper/enterasys/whatever managed switch or router? It's a common operation on a network interface, I don't see why this is a concern. When I'm debugging a networking issue On a cluster of hundreds and hundreds of machines at work, I want to be able to reset them all quickly, and get a rough idea of if they're all climbing, if they're all climbing at the same rate, etc. And being able to do "for i in `cat hostlist`; do ssh $i ethtool -z eth0; done" is really, really, REALLY, useful. Obtaining the difference between two numbers is not that difficult. Given any method of clearing statistics across your cluster, I'm certain you can come up with a similar method of obtaining the current statistic (the baseline). 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: reminder, 2.6.18 window...
On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote: > I disagree that we should bother about clearing statistics. It always > adds more complication than necessary. Few (if any) other statistics in > Linux permit easy clearing, often because adding operations other than > 'increment' or 'read' requires adding expensive spinlocks or atomic > operations. Every networking device in the world supports clearing interface statistics. Why should linux not be able to do the most basic operation on any cisco/juniper/enterasys/whatever managed switch or router? It's a common operation on a network interface, I don't see why this is a concern. When I'm debugging a networking issue On a cluster of hundreds and hundreds of machines at work, I want to be able to reset them all quickly, and get a rough idea of if they're all climbing, if they're all climbing at the same rate, etc. And being able to do "for i in `cat hostlist`; do ssh $i ethtool -z eth0; done" is really, really, REALLY, useful. As for SNMP statistics, again, this is just like clearing stats on any other platform - it's a manual thing... you're *choosing* to reset the stats, and accept the consequences. Its not like the patch introduces some nightly resetting - it's just an _option_ to users It's about providing an option that requires no extra complications in the code (at least in this case), and that has been requested on every sysadmin-related list I'm on, and in most cases is a re-occuring topic. -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759 signature.asc Description: Digital signature
Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
On Tue, 2006-23-05 at 19:43 +0200, Simon Oosthoek wrote: > Stephen Hemminger wrote: > > On Tue, 23 May 2006 16:07:47 +0200 > > Herman Elfrink <[EMAIL PROTECTED]> wrote: > > > >> > >> FLAME stands for "Forwarding Layer for Meshing" > >> > > > > Didn't you just reinvent 802.1d bridging? and/or WDS? > > I wouldn't say "reinvent", but the difference is small but significant. > FLAME could be seen as ad hoc WDS, I think. It doesn't need to know > about the other "base-stations", which I think WDS does. > Essentially you are extending the broadcast domain i.e a bridge within on top of a bridge. I would question the scalability of such a beast in the presence of many nodes. Also take a look at some of the work Radia Perlman (who invented bridging really) is up to these days. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] bridge: netlink interface for link management
On Wed, 24 May 2006 14:11:55 -0400
jamal <[EMAIL PROTECTED]> wrote:
>
> Very nice.
>
> On Wed, 2006-24-05 at 10:12 -0700, Stephen Hemminger wrote:
> > plain text document attachment (bridge-netlink.patch)
> > Add basic netlink support to the Ethernet bridge. Including:
> > * dump interfaces in bridges
> > * monitor link status changes
> > * change state of bridge port
>
>
> > +static int br_fill_ifinfo(struct sk_buff *skb, const struct
> > net_bridge_port *port,
> > + u32 pid, u32 seq, int event, unsigned int flags)
> > +{
> > + const struct net_bridge *br = port->br;
> > + const struct net_device *dev = port->dev;
> > + struct ifinfomsg *r;
> > + struct nlmsghdr *nlh;
> > + unsigned char *b = skb->tail;
> > + u32 mtu = dev->mtu;
> > + u8 operstate = netif_running(dev) ? dev->operstate : IF_OPER_DOWN;
> > + u8 portstate = port->state;
> > +
> > + pr_debug("br_fill_info event %d port %s master %s\n",
> > +event, dev->name, br->dev->name);
> > +
> > + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags);
> > + r = NLMSG_DATA(nlh);
> > + r->ifi_family = AF_BRIDGE;
> > + r->__ifi_pad = 0;
> > + r->ifi_type = dev->type;
> > + r->ifi_index = dev->ifindex;
> > + r->ifi_flags = dev_get_flags(dev);
> > + r->ifi_change = 0;
> > +
> > + RTA_PUT(skb, IFLA_IFNAME, strlen(dev->name)+1, dev->name);
> > +
> > + RTA_PUT(skb, IFLA_MASTER, sizeof(int), &br->dev->ifindex);
> > +
> > + if (dev->addr_len)
> > + RTA_PUT(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr);
> > +
> > + RTA_PUT(skb, IFLA_MTU, sizeof(mtu), &mtu);
> > + if (dev->ifindex != dev->iflink)
> > + RTA_PUT(skb, IFLA_LINK, sizeof(int), &dev->iflink);
> > +
> > +
> > + RTA_PUT(skb, IFLA_OPERSTATE, sizeof(operstate), &operstate);
> > +
> > + if (event == RTM_NEWLINK)
> > + RTA_PUT(skb, IFLA_PROTINFO, sizeof(portstate), &portstate);
> > +
> > + nlh->nlmsg_len = skb->tail - b;
> > +
> > + return skb->len;
> > +
>
> Is it desirable to do the above? link events already happen for each
> netdevice, no? If not it would probably make more sense to export the
> link netlink code (instead of replicating it as above) and just call it
> for each netdevice.
The STP daemon only wants to know about interfaces in bridge, and it needs
to know the bridge port state.
> I think it is worth reporting all the children (their ifindices) of a
> bridge when eventing.
can easily track this in daemon.
> BTW, Where is the bridge state (as in learning, blocking etc) carried?
In IFLA_PROTINFO
> Having events for that i would deem as valuable.
>
> > +static int br_rtm_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, void
> > *arg)
> > +{
> > + struct rtattr **rta = arg;
> > + struct ifinfomsg *ifm = NLMSG_DATA(nlh);
> > + struct net_device *dev;
> > + struct net_bridge_port *p;
> > + u8 new_state;
> > +
> > + if (ifm->ifi_family != AF_BRIDGE)
> > + return -EPFNOSUPPORT;
> > +
> > + /* Must pass valid state as PROTINFO */
> > + if (rta[IFLA_PROTINFO-1]) {
>
> Why not a noun like IFLA_BRIDGE_STATE ?
Laziness. Just used "protocol specific portion"
>
>
> > + /* if kernel STP is running, don't allow changes */
> > + if (p->br->stp_enabled)
> > + return -EBUSY;
>
> Hopefully above to die some day...
>
> > +
> > + p->state = new_state;
> > + br_log_state(p);
>
> Assuming the above will generate an event which reports things like the
> children of the bridge and the STP state of the bridge etc i.e things in
> struct net_bridge_port mostly.
The br_log_state just does console printk's.
-
To unsubscribe from this list: send 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...
Those folks wanting link-level stats over an interval (I'm assuming that is wny someone would want to zero stats?) should feel free to embrace and extend beforeafter: ftp://ftp.cup.hp.com/dist/networking/tools/ rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
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... it impliments the framework as well as skge support, so it touches both your and Jeff's area. For your reference, here's the two times I've posted it this month - I'm happy to send it along again. 2006-05-18 RESEND: [PATCH] Interface Stat Clearing Framework, skge support, ethtool http://marc.theaimsgroup.com/?l=linux-netdev&m=114794065502155&w=2 2006-04-30 [PATCH] Interface Stat Clearing Framework, skge support, ethtool http://marc.theaimsgroup.com/?l=linux-netdev&m=114636704207480&w=2 I disagree that we should bother about clearing statistics. It always adds more complication than necessary. Few (if any) other statistics in Linux permit easy clearing, often because adding operations other than 'increment' or 'read' requires adding expensive spinlocks or atomic operations. 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: reminder, 2.6.18 window...
On Wed, 2006-24-05 at 01:01 -0700, Phil Dibowitz wrote: [..] > > For your reference, here's the two times I've posted it this month - I'm > happy to send it along again. The problem with resetting stats is it is _most definetely_ going to break management apps like SNMP. This is not to say this is not useful for testing and at times debugging - but backward compat and not pissing off the standards whic count on this long standing feature is more important. So if you can make it work without breaking apps, it will be more palatable i am sure to both Dave and Jeff. I would go as far as suggest that you should allow for arbitrary setting (of which 0 is a speacial case). cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] bridge: netlink interface for link management
Very nice.
On Wed, 2006-24-05 at 10:12 -0700, Stephen Hemminger wrote:
> plain text document attachment (bridge-netlink.patch)
> Add basic netlink support to the Ethernet bridge. Including:
> * dump interfaces in bridges
> * monitor link status changes
> * change state of bridge port
> +static int br_fill_ifinfo(struct sk_buff *skb, const struct net_bridge_port
> *port,
> + u32 pid, u32 seq, int event, unsigned int flags)
> +{
> + const struct net_bridge *br = port->br;
> + const struct net_device *dev = port->dev;
> + struct ifinfomsg *r;
> + struct nlmsghdr *nlh;
> + unsigned char *b = skb->tail;
> + u32 mtu = dev->mtu;
> + u8 operstate = netif_running(dev) ? dev->operstate : IF_OPER_DOWN;
> + u8 portstate = port->state;
> +
> + pr_debug("br_fill_info event %d port %s master %s\n",
> + event, dev->name, br->dev->name);
> +
> + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags);
> + r = NLMSG_DATA(nlh);
> + r->ifi_family = AF_BRIDGE;
> + r->__ifi_pad = 0;
> + r->ifi_type = dev->type;
> + r->ifi_index = dev->ifindex;
> + r->ifi_flags = dev_get_flags(dev);
> + r->ifi_change = 0;
> +
> + RTA_PUT(skb, IFLA_IFNAME, strlen(dev->name)+1, dev->name);
> +
> + RTA_PUT(skb, IFLA_MASTER, sizeof(int), &br->dev->ifindex);
> +
> + if (dev->addr_len)
> + RTA_PUT(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr);
> +
> + RTA_PUT(skb, IFLA_MTU, sizeof(mtu), &mtu);
> + if (dev->ifindex != dev->iflink)
> + RTA_PUT(skb, IFLA_LINK, sizeof(int), &dev->iflink);
> +
> +
> + RTA_PUT(skb, IFLA_OPERSTATE, sizeof(operstate), &operstate);
> +
> + if (event == RTM_NEWLINK)
> + RTA_PUT(skb, IFLA_PROTINFO, sizeof(portstate), &portstate);
> +
> + nlh->nlmsg_len = skb->tail - b;
> +
> + return skb->len;
> +
Is it desirable to do the above? link events already happen for each
netdevice, no? If not it would probably make more sense to export the
link netlink code (instead of replicating it as above) and just call it
for each netdevice.
I think it is worth reporting all the children (their ifindices) of a
bridge when eventing.
BTW, Where is the bridge state (as in learning, blocking etc) carried?
Having events for that i would deem as valuable.
> +static int br_rtm_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, void
> *arg)
> +{
> + struct rtattr **rta = arg;
> + struct ifinfomsg *ifm = NLMSG_DATA(nlh);
> + struct net_device *dev;
> + struct net_bridge_port *p;
> + u8 new_state;
> +
> + if (ifm->ifi_family != AF_BRIDGE)
> + return -EPFNOSUPPORT;
> +
> + /* Must pass valid state as PROTINFO */
> + if (rta[IFLA_PROTINFO-1]) {
Why not a noun like IFLA_BRIDGE_STATE ?
> + /* if kernel STP is running, don't allow changes */
> + if (p->br->stp_enabled)
> + return -EBUSY;
Hopefully above to die some day...
> +
> + p->state = new_state;
> + br_log_state(p);
Assuming the above will generate an event which reports things like the
children of the bridge and the STP state of the bridge etc i.e things in
struct net_bridge_port mostly.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2 hw csum failure [was Re: sky2 large MTU problems]
On Wed, 24 May 2006 10:28:52 +0100 "Daniel J Blueman" <[EMAIL PROTECTED]> wrote: > Having done some more stress testing with sky2 1.4 (in 2.6.17-rc4) and > the latest patch, I have found problems when streaming lots of data > out of the sky2 interface (eg via samba serving a large file to GigE > client). Ultimately, the interface will stop sending. > > Before this happens, I see lots of: > > kernel: lan0: hw csum failure. > kernel: [__skb_checksum_complete+86/96] __skb_checksum_complete+0x56/0x60 > kernel: [tcp_error+300/512] tcp_error+0x12c/0x200 > kernel: [poison_obj+41/96] poison_obj+0x29/0x60 > kernel: [tcp_error+0/512] tcp_error+0x0/0x200 > kernel: [ip_conntrack_in+157/1072] ip_conntrack_in+0x9d/0x430 > kernel: [kfree_skbmem+8/128] kfree_skbmem+0x8/0x80 > kernel: [arp_process+102/1408] arp_process+0x66/0x580 > kernel: [check_poison_obj+36/416] check_poison_obj+0x24/0x1a0 > kernel: [arp_process+102/1408] arp_process+0x66/0x580 > kernel: [nf_iterate+99/144] nf_iterate+0x63/0x90 > kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 > kernel: [nf_hook_slow+89/240] nf_hook_slow+0x59/0xf0 > kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 > kernel: [ip_rcv+386/1104] ip_rcv+0x182/0x450 > kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 > kernel: [packet_rcv_spkt+216/320] packet_rcv_spkt+0xd8/0x140 > kernel: [netif_receive_skb+476/784] netif_receive_skb+0x1dc/0x310 > kernel: [sky2_poll+879/2096] sky2_poll+0x36f/0x830 > kernel: [_spin_lock_irqsave+9/16] _spin_lock_irqsave+0x9/0x10 > kernel: [run_timer_softirq+290/416] run_timer_softirq+0x122/0x1a0 > kernel: [net_rx_action+108/256] net_rx_action+0x6c/0x100 > kernel: [__do_softirq+66/160] __do_softirq+0x42/0xa0 > kernel: [do_softirq+78/96] do_softirq+0x4e/0x60 > kernel: === > kernel: [do_IRQ+90/160] do_IRQ+0x5a/0xa0 > kernel: [remove_vma+69/80] remove_vma+0x45/0x50 > kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20 > kernel: [get_offset_pmtmr+151/3584] get_offset_pmtmr+0x97/0xe00 > kernel: [do_gettimeofday+26/208] do_gettimeofday+0x1a/0xd0 > kernel: [sys_gettimeofday+26/144] sys_gettimeofday+0x1a/0x90 > kernel: [syscall_call+7/11] syscall_call+0x7/0xb What ever the netfilter chain is, it is trimming or altering the packet without clearing or altering the hardware checksum. It is not a driver problem, we saw these in VLAN's and ebtables already. > One of these was preceeded by: > > kernel: sky2 lan0: rx error, status 0x977d977d length 0 The receive FIFO got overrun. You must not be running hardware flow control. > > This was happening with the default MTU of 1500, not just at MTU size > 9000 (but it was changed down from 9000). Hardware is Yukon-EC (0xb6) > rev 1. > > I'll do some more stress testing tonight without the MTU patch and > without the MTU being raised to 9000 initially and see what happens. > > Thanks for all your great work so far! - To unsubscribe from this list: send 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: [resend PATCH 1/1] b44: fix ethool link settings support
The first test is to check if any advertising value is given.
The else path is when advertising == 0.
The b44->flags do not have the same values as the given advertising bits.
When any (or all) of the ADVERTISE_ALL bits are passed to the driver the
b44->flags
are set accordingly.
I think it's ok.
Thanks,
Gary
On Wed, 2006-05-24 at 02:41 -0400, Jeff Garzik wrote:
> Gary Zambrano wrote:
> > + if (cmd->advertising & ADVERTISE_ALL) {
> > + if (cmd->advertising & ADVERTISE_10HALF)
> > + bp->flags |= B44_FLAG_ADV_10HALF;
> > + if (cmd->advertising & ADVERTISE_10FULL)
> > + bp->flags |= B44_FLAG_ADV_10FULL;
> > + if (cmd->advertising & ADVERTISE_100HALF)
> > + bp->flags |= B44_FLAG_ADV_100HALF;
> > + if (cmd->advertising & ADVERTISE_100FULL)
> > + bp->flags |= B44_FLAG_ADV_100FULL;
> > + } else {
> > + bp->flags |= (B44_FLAG_ADV_10HALF |
> > + B44_FLAG_ADV_10FULL |
> > + B44_FLAG_ADV_100HALF |
> > + B44_FLAG_ADV_100FULL);
> > + }
>
> The logic above is backwards. I presume the first test should be
> if (!(cmd->advertising & ADVERTISE_ALL))
>
> The rest looks OK.
>
> 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 2/3] bridge: fix module startup error handling
Return address in use, if some other kernel code has the SAP.
Propogate out error codes from netfilter registration and unwind.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- br.orig/net/bridge/br.c
+++ br/net/bridge/br.c
@@ -30,36 +30,44 @@ static struct llc_sap *br_stp_sap;
static int __init br_init(void)
{
+ int err;
+
br_stp_sap = llc_sap_open(LLC_SAP_BSPAN, br_stp_rcv);
if (!br_stp_sap) {
printk(KERN_ERR "bridge: can't register sap for STP\n");
- return -EBUSY;
+ return -EADDRINUSE;
}
br_fdb_init();
-#ifdef CONFIG_BRIDGE_NETFILTER
- if (br_netfilter_init())
- return 1;
-#endif
+ err = br_netfilter_init();
+ if (err)
+ goto err_out1;
+
+ err = register_netdevice_notifier(&br_device_notifier);
+ if (err)
+ goto err_out2;
+
brioctl_set(br_ioctl_deviceless_stub);
br_handle_frame_hook = br_handle_frame;
br_fdb_get_hook = br_fdb_get;
br_fdb_put_hook = br_fdb_put;
- register_netdevice_notifier(&br_device_notifier);
-
return 0;
+
+err_out2:
+ br_netfilter_fini();
+err_out1:
+ llc_sap_put(br_stp_sap);
+ return err;
}
static void __exit br_deinit(void)
{
rcu_assign_pointer(br_stp_sap->rcv_func, NULL);
-#ifdef CONFIG_BRIDGE_NETFILTER
br_netfilter_fini();
-#endif
unregister_netdevice_notifier(&br_device_notifier);
brioctl_set(NULL);
--- br.orig/net/bridge/br_private.h
+++ br/net/bridge/br_private.h
@@ -192,8 +192,13 @@ extern int br_dev_ioctl(struct net_devic
extern int br_ioctl_deviceless_stub(unsigned int cmd, void __user *arg);
/* br_netfilter.c */
+#ifdef CONFIG_BRIDGE_NETFILTER
extern int br_netfilter_init(void);
extern void br_netfilter_fini(void);
+#else
+#define br_netfilter_init()(0)
+#define br_netfilter_fini()do { } while(0)
+#endif
/* br_stp.c */
extern void br_log_state(const struct net_bridge_port *p);
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/3] bridge patches for 2.6.18
Some stuff for 2.6.18. The most important is adding netlink support for managing interfaces; this allows building STP as an application. -- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/3] bridge: netlink interface for link management
Add basic netlink support to the Ethernet bridge. Including:
* dump interfaces in bridges
* monitor link status changes
* change state of bridge port
For some demo programs see:
http://developer.osdl.org/shemminger/prototypes/brnl.tar.gz
These are to allow building a daemon that does alternative implementations
of Spanning Tree Protocol.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- br.orig/net/bridge/Makefile
+++ br/net/bridge/Makefile
@@ -6,7 +6,7 @@ obj-$(CONFIG_BRIDGE) += bridge.o
bridge-y := br.o br_device.o br_fdb.o br_forward.o br_if.o br_input.o \
br_ioctl.o br_notify.o br_stp.o br_stp_bpdu.o \
- br_stp_if.o br_stp_timer.o
+ br_stp_if.o br_stp_timer.o br_netlink.o
bridge-$(CONFIG_SYSFS) += br_sysfs_if.o br_sysfs_br.o
--- /dev/null
+++ br/net/bridge/br_netlink.c
@@ -0,0 +1,199 @@
+/*
+ * Bridge netlink control interface
+ *
+ * Authors:
+ * Stephen Hemminger <[EMAIL PROTECTED]>
+ *
+ * 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.
+ */
+
+#include
+#include
+#include "br_private.h"
+
+/*
+ * Create one netlink message for one interface
+ * Contains port and master info as well as carrier and bridge state.
+ */
+static int br_fill_ifinfo(struct sk_buff *skb, const struct net_bridge_port
*port,
+ u32 pid, u32 seq, int event, unsigned int flags)
+{
+ const struct net_bridge *br = port->br;
+ const struct net_device *dev = port->dev;
+ struct ifinfomsg *r;
+ struct nlmsghdr *nlh;
+ unsigned char *b = skb->tail;
+ u32 mtu = dev->mtu;
+ u8 operstate = netif_running(dev) ? dev->operstate : IF_OPER_DOWN;
+ u8 portstate = port->state;
+
+ pr_debug("br_fill_info event %d port %s master %s\n",
+event, dev->name, br->dev->name);
+
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags);
+ r = NLMSG_DATA(nlh);
+ r->ifi_family = AF_BRIDGE;
+ r->__ifi_pad = 0;
+ r->ifi_type = dev->type;
+ r->ifi_index = dev->ifindex;
+ r->ifi_flags = dev_get_flags(dev);
+ r->ifi_change = 0;
+
+ RTA_PUT(skb, IFLA_IFNAME, strlen(dev->name)+1, dev->name);
+
+ RTA_PUT(skb, IFLA_MASTER, sizeof(int), &br->dev->ifindex);
+
+ if (dev->addr_len)
+ RTA_PUT(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr);
+
+ RTA_PUT(skb, IFLA_MTU, sizeof(mtu), &mtu);
+ if (dev->ifindex != dev->iflink)
+ RTA_PUT(skb, IFLA_LINK, sizeof(int), &dev->iflink);
+
+
+ RTA_PUT(skb, IFLA_OPERSTATE, sizeof(operstate), &operstate);
+
+ if (event == RTM_NEWLINK)
+ RTA_PUT(skb, IFLA_PROTINFO, sizeof(portstate), &portstate);
+
+ nlh->nlmsg_len = skb->tail - b;
+
+ return skb->len;
+
+nlmsg_failure:
+rtattr_failure:
+
+ skb_trim(skb, b - skb->data);
+ return -EINVAL;
+}
+
+/*
+ * Notify listeners of a change in port information
+ */
+void br_ifinfo_notify(int event, struct net_bridge_port *port)
+{
+ struct sk_buff *skb;
+ int err = -ENOMEM;
+
+ pr_debug("bridge notify event=%d\n", event);
+ skb = alloc_skb(NLMSG_SPACE(sizeof(struct ifinfomsg) + 128),
+ GFP_ATOMIC);
+ if (!skb)
+ goto err_out;
+
+ err = br_fill_ifinfo(skb, port, current->pid, 0, event, 0);
+ if (err)
+ goto err_kfree;
+
+ NETLINK_CB(skb).dst_group = RTNLGRP_LINK;
+ netlink_broadcast(rtnl, skb, 0, RTNLGRP_LINK, GFP_ATOMIC);
+ return;
+
+err_kfree:
+ kfree_skb(skb);
+err_out:
+ netlink_set_err(rtnl, 0, RTNLGRP_LINK, err);
+}
+
+/*
+ * Dump information about all ports, in response to GETLINK
+ */
+static int br_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ struct net_device *dev;
+ int idx;
+ int s_idx = cb->args[0];
+ int err = 0;
+
+ read_lock(&dev_base_lock);
+ for (dev = dev_base, idx = 0; dev; dev = dev->next) {
+ struct net_bridge_port *p = dev->br_port;
+
+ /* not a bridge port */
+ if (!p)
+ continue;
+
+ if (idx < s_idx)
+ continue;
+
+ err = br_fill_ifinfo(skb, p, NETLINK_CB(cb->skb).pid,
+cb->nlh->nlmsg_seq, RTM_NEWLINK,
NLM_F_MULTI);
+ if (err <= 0)
+ break;
+ ++idx;
+ }
+ read_unlock(&dev_base_lock);
+
+ cb->args[0] = idx;
+
+ return skb->len;
+}
+
+/*
+ * Change state of port (ie from forwarding to blocking etc)
+ * Used by spanning tree in user space.
+ */
+static int br_rtm_setlink(struct sk_buf
[patch 1/3] bridge: optimize conditional in forward path
Small optimizations of bridge forwarding path.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- br.orig/net/bridge/br_forward.c
+++ br/net/bridge/br_forward.c
@@ -20,14 +20,11 @@
#include
#include "br_private.h"
+/* Don't forward packets to originating port or forwarding diasabled */
static inline int should_deliver(const struct net_bridge_port *p,
const struct sk_buff *skb)
{
- if (skb->dev == p->dev ||
- p->state != BR_STATE_FORWARDING)
- return 0;
-
- return 1;
+ return (skb->dev != p->dev && p->state == BR_STATE_FORWARDING);
}
static inline unsigned packet_length(const struct sk_buff *skb)
@@ -55,10 +52,9 @@ int br_dev_queue_push_xmit(struct sk_buf
int br_forward_finish(struct sk_buff *skb)
{
- NF_HOOK(PF_BRIDGE, NF_BR_POST_ROUTING, skb, NULL, skb->dev,
- br_dev_queue_push_xmit);
+ return NF_HOOK(PF_BRIDGE, NF_BR_POST_ROUTING, skb, NULL, skb->dev,
+ br_dev_queue_push_xmit);
- return 0;
}
static void __br_deliver(const struct net_bridge_port *to, struct sk_buff *skb)
--
-
To unsubscribe from this list: send 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] TCP Veno module for kernel 2.6.16.13
On Wed, 24 May 2006 17:16:52 +0100
Baruch Even <[EMAIL PROTECTED]> wrote:
> #ZHOU BIN# wrote:
> > From: Bin Zhou <[EMAIL PROTECTED]>
> > + else if (sysctl_tcp_abc) {
> > + /* RFC3465: Apppriate Byte Count
> > + * increase once for each full cwnd acked.
> > + * Veno has no idear about it so far, so we keep
> > + * it as Reno.
> > + */
> > + if (tp->bytes_acked >= tp->snd_cwnd*tp->mss_cache) {
> > + tp->bytes_acked -= tp->snd_cwnd*tp->mss_cache;
> > + if (tp->snd_cwnd < tp->snd_cwnd_clamp)
> > + tp->snd_cwnd++;
> > + }
>
> You should prefer to ignore abc instead. At least that's what everyone
> else is doing, the only place where abc is active is in NewReno.
>
> Baruch
That was intentional. When ABC was added, the desire was to not change existing
behavior for other congestion control methods.
-
To unsubscribe from this list: send 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] TCP Veno module for kernel 2.6.16.13
#ZHOU BIN# wrote:
> From: Bin Zhou <[EMAIL PROTECTED]>
> + else if (sysctl_tcp_abc) {
> + /* RFC3465: Apppriate Byte Count
> + * increase once for each full cwnd acked.
> + * Veno has no idear about it so far, so we keep
> + * it as Reno.
> + */
> + if (tp->bytes_acked >= tp->snd_cwnd*tp->mss_cache) {
> + tp->bytes_acked -= tp->snd_cwnd*tp->mss_cache;
> + if (tp->snd_cwnd < tp->snd_cwnd_clamp)
> + tp->snd_cwnd++;
> + }
You should prefer to ignore abc instead. At least that's what everyone
else is doing, the only place where abc is active is in NewReno.
Baruch
-
To unsubscribe from this list: send 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] TCP Veno module for kernel 2.6.16.13
On Wed, 24 May 2006, Stephen Hemminger wrote: > Hope you don't mind if I will run it through Lindent first to cleanup > whitespace. How about dropping the mixed caps, as well? -- 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] TCP Veno module for kernel 2.6.16.13
On Wed, 24 May 2006 19:08:05 +0800 "#ZHOU BIN#" <[EMAIL PROTECTED]> wrote: > From: Bin Zhou <[EMAIL PROTECTED]> > > TCP Veno module is a new congestion control module to improve TCP performance > over wireless networks. The key innovation in TCP Veno is the enhancement of > TCP Reno/Sack congestion control algorithm by using the estimated state of a > connection based on TCP Vegas. This scheme significantly reduces "blind" > reduction of TCP window regardless of the cause of packet loss. > > This work is based on the research paper "TCP Veno: TCP Enhancement for > Transmission over Wireless Access Networks." C. P. Fu, S. C. Liew, IEEE > Journal on Selected Areas in Communication, Feb. 2003. > > Original paper and many latest research works on veno can be reached at > http://www.ntu.edu.sg/home/ascpfu/veno/veno.html or through the > www.google.com by entering keywords "TCP Veno" > > > > Sign-off-by: Bin Zhou <[EMAIL PROTECTED]> >Cheng Peng Fu <[EMAIL PROTECTED]> I will put this in my tcp git tree (along with LP and Compound). Hope you don't mind if I will run it through Lindent first to cleanup whitespace. - To unsubscribe from this list: send 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' branch of wireless-2.6
On Wed, May 24, 2006 at 12:35:20AM -0400, Jeff Garzik wrote: > John W. Linville wrote: > >The following changes since commit > >01d654d25d23fb73deb7904ce1c0b3a0f5fc2908: > > John W. Linville: > >Merge branch 'upstream-fixes' into upstream > > > >are found in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git > > upstream > > > >Marcin Juszkiewicz: > > hostap: new pcmcia IDs > > > > drivers/net/wireless/hostap/hostap_cs.c |6 ++ > > 1 files changed, 6 insertions(+), 0 deletions(-) > > WTF??? I pull, and see diffstat: > > Merge db21e578e551421d76641d72cb3f8296ed3f9e61, made by recursive. > drivers/net/wireless/airo.c |2 ... > This is vastly different from any 'pull upstream' email I've received > from you. It is extremely uncool for me to pull, and receive something > other than what your email specified. Jeff, I am terribly sorry. I sent a request for this on 24 April, but it does not appear in the archives. It must have been dropped (probably due to size) by the netdev list filters, and I neglected to notice. /me wishes the list would send me a note when it drops stuff due to size... > Nonetheless, I looked over the changes and they look OK, so I took the > lazy route and kept them. I greatly appreciate that! > For the future, I would perhaps recommend creating an upstream-jeff > branch at the time of submission, if you insist upon continuing to push The point is well taken. It probably does make sense either to have an upstream-jeff branch or to make a new branch if you haven't yet pulled. I'll keep that in mind. 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
[PATCH] TCP Veno module for kernel 2.6.16.13
From: Bin Zhou <[EMAIL PROTECTED]> TCP Veno module is a new congestion control module to improve TCP performance over wireless networks. The key innovation in TCP Veno is the enhancement of TCP Reno/Sack congestion control algorithm by using the estimated state of a connection based on TCP Vegas. This scheme significantly reduces "blind" reduction of TCP window regardless of the cause of packet loss. This work is based on the research paper "TCP Veno: TCP Enhancement for Transmission over Wireless Access Networks." C. P. Fu, S. C. Liew, IEEE Journal on Selected Areas in Communication, Feb. 2003. Original paper and many latest research works on veno can be reached at http://www.ntu.edu.sg/home/ascpfu/veno/veno.html or through the www.google.com by entering keywords "TCP Veno" Sign-off-by: Bin Zhou <[EMAIL PROTECTED]> Cheng Peng Fu <[EMAIL PROTECTED]> diff -urN linux-2.6.16.13/net/ipv4/Kconfig linux-2.6.16.13-veno/net/ipv4/Kconfig --- linux-2.6.16.13/net/ipv4/Kconfig2006-05-03 05:38:44.0 +0800 +++ linux-2.6.16.13-veno/net/ipv4/Kconfig 2006-05-20 16:16:44.712926200 +0800 @@ -521,6 +521,18 @@ window. TCP Vegas should provide less packet loss, but it is not as aggressive as TCP Reno. +config TCP_CONG_VENO + tristate "TCP Veno" + depends on EXPERIMENTAL + default n + ---help--- + TCP Veno is a sender-side only enhancement of TCP to obtain better + throughput over wirless networks. TCP Veno makes use of state + distinguishing to circumvent the difficult judgment of the packet loss type. + TCP Veno cuts down less congestion window in response to random loss + packets. + See http://www.ntu.edu.sg/home5/ZHOU0022/papers/CPFu03a.pdf + config TCP_CONG_SCALABLE tristate "Scalable TCP" depends on EXPERIMENTAL diff -urN linux-2.6.16.13/net/ipv4/Makefile linux-2.6.16.13-veno/net/ipv4/Makefile --- linux-2.6.16.13/net/ipv4/Makefile 2006-05-03 05:38:44.0 +0800 +++ linux-2.6.16.13-veno/net/ipv4/Makefile 2006-05-20 15:57:45.308758200 +0800 @@ -40,6 +40,7 @@ obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o +obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ diff -urN linux-2.6.16.13/net/ipv4/tcp_veno.c linux-2.6.16.13-veno/net/ipv4/tcp_veno.c --- linux-2.6.16.13/net/ipv4/tcp_veno.c 1970-01-01 08:00:00.0 +0800 +++ linux-2.6.16.13-veno/net/ipv4/tcp_veno.c2006-05-21 11:11:36.190398400 +0800 @@ -0,0 +1,253 @@ +/* + * TCP Veno congestion control + * + * This is based on the congestion detection/avoidance scheme described in + *C. P. Fu, S. C. Liew. + *"TCP Veno: TCP Enhancement for Transmission over Wireless Access Networks." + *IEEE Journal on Selected Areas in Communication, + *Feb. 2003. + * See http://www.ntu.edu.sg/home5/ZHOU0022/papers/CPFu03a.pdf + */ + +#include +#include +#include +#include +#include + +#include + +/* Default values of the Veno variables, in fixed-point representation + * with V_PARAM_SHIFT bits to the right of the binary point. + */ +#define V_PARAM_SHIFT 1 +static int beta = 3minRTT = 0x7fff; +} + +static inline void veno_disable(struct sock *sk) +{ + struct veno *veno = inet_csk_ca(sk); + + /* turn off Veno */ + veno->doing_veno_now = 0; +} + +static void tcp_veno_init(struct sock *sk) +{ + struct veno *veno = inet_csk_ca(sk); + + veno->baseRTT = 0x7fff; + veno->inc = 1; + veno_enable(sk); +} + +/* Do RTT sampling needed for Veno. */ +static void tcp_veno_rtt_calc(struct sock *sk, u32 usrtt) +{ + struct veno *veno = inet_csk_ca(sk); + u32 vrtt = usrtt + 1; /* Never allow zero rtt or baseRTT */ + + /* Filter to find propagation delay: */ + if (vrtt < veno->baseRTT) + veno->baseRTT = vrtt; + + /* Find the min RTT during the last RTT to find +* the current prop. delay + queuing delay: +*/ + veno->minRTT = min(veno->minRTT, vrtt); + veno->cntRTT++; +} + +static void tcp_veno_state(struct sock *sk, u8 ca_state) +{ + + if (ca_state == TCP_CA_Open) + veno_enable(sk); + else + veno_disable(sk); +} + +/* + * If the connection is idle and we are restarting, + * then we don't want to do any Veno calculations + * until we get fresh RTT samples. So when we + * restart, we reset our Veno state to a clean + * state. After we get acks for this flight of + * packets, _then_ we can make Veno calculations + * again. + */ +static void tcp_veno_cwnd_event(struct sock *sk, enum tcp_ca_event event) +{ + if (event == CA_EVENT_CWND_RESTART || + event == CA_EVENT_TX_START) + tcp_veno_init(sk); +} + +
Re: [HAMRADIO] Remove remaining SET_MODULE_OWNER calls from hamradio drivers.
On Wed, May 24, 2006 at 01:30:26AM -0400, Jeff Garzik wrote: > Ralf Baechle DL5RB wrote: > >Signed-off-by: Ralf Baechle DL5RB <[EMAIL PROTECTED]> > > ACK but does not apply Of course not, DaveM applied the patch 3 weeks ago. Ralf - To unsubscribe from this list: send 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: [Netchannel] Full TCP receiving support.
Hello, developers. Initial TCP benchmark. After tweaking some stuff I run netchannel vs socket TCP benchmark. Unfortunately currently I'm unable to run 1Gbit test, since my test machine is slightly broken... So only 100Mbit for now. Performance graph attached. Speed is the same, CPU usage is the same (socket CPU usage is 1% (or 20% :) more than netchannel one, but let's throw this away as some experimental error). Netchannel was setup in copy_to_user mode, so it was not expected to be faster or eat less CPU, but main purpose of this test was to show that netchannels with _all_ protocol processing moved to process' context can be at least that fast as when it is splitted into pieces. I've found some links in the web and blogs where some developers completely disagree with VJ idea of moving stuff into process context... Well, this should break theirs mostly theoretical arguments. It is clear that using memcpy setup CPU usage numbers (at least) for netchannel are noticebly better than for sockets (see previous posted benchmarks). I will start changing core networking code to accept different copying "actor" methods which will allow to use netchannels preallocated mapped area instead of copy_to_user(). Full patch and userspace application are available from netchannel homepage [1]. Thank you. 1. Netchannel homepage. http://tservice.net.ru/~s0mbre/old/?section=projects&item=netchannel Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> -- Evgeniy Polyakov netchannel_speed.png Description: PNG image
Re: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
32-bit kernel, this is a Motorola Powerstack II macine with 604e. PReP subarch, only buildable from the old ARCH=ppc code (not yet migrated to ARCH=powerpc). Ah OK, I thought it was related to the new compat code, but that isn't the case. Your trace doesn't give much clues, except that it shows that iptables dies with a SIGSEGV, which might be a bug in userspace or in the kernel. Which was the last kernel that worked for you, and can you try that version again to rule out userspace bugs? Even worse. With yesterdays git iptable_nat loads but iptable_filter doesn't even load (Invalid argument). -- 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: Please pull 'upstream-fixes' branch of wireless-2.6
Jeff Garzik <[EMAIL PROTECTED]> wrote: > > John W. Linville wrote: > > The following changes since commit 353b28bafd1b962359a866ff263a7fad833d29a1: > > David S. Miller: > > [SPARC]: Add robust futex syscall entries. > > > > are found in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git > > upstream-fixes > > > > Florin Malita: > > orinoco: possible null pointer dereference in orinoco_rx_monitor() > > skipping, went in via akpm apparently. Yes, sorry, I screwed that up - I thought John's pull request went to Linus and when nothing had happened for 24 hrs, I sent the diff myself. Doh. - To unsubscribe from this list: send 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: [1/1] connector: export cn_already_initialized.
On Tue, May 16, 2006 at 04:14:06PM -0700, David S. Miller ([EMAIL PROTECTED]) wrote: > From: Evgeniy Polyakov <[EMAIL PROTECTED]> > Date: Sat, 6 May 2006 12:40:45 +0400 > > I think the right solution is to call external init functions after cn > > init function, but it's ordering is not always known. > > In-kernel build of connector subsystem can be handled by > making cn_init a "subsystem_init()", it will then be setup > before any possible static or modular reference as long as > those modules use module_init(). subsystem_init() seems to be kobject related initilizator. Maybe subsys_initcall()? I will cook up a patch if it works. Thank you. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] myri10ge - Driver core
Anton Blanchard wrote: >> +/* >> + * Set of routunes to get a new receive buffer. Any buffer which >> + * crosses a 4KB boundary must start on a 4KB boundary due to PCIe >> + * wdma restrictions. We also try to align any smaller allocation to >> + * at least a 16 byte boundary for efficiency. We assume the linux >> + * memory allocator works by powers of 2, and will not return memory >> + * smaller than 2KB which crosses a 4KB boundary. If it does, we fall >> + * back to allocating 2x as much space as required. >> + * >> + * We intend to replace large (>4KB) skb allocations by using >> + * pages directly and building a fraglist in the near future. >> + */ >> > > You go to a lot of trouble to align things. One thing on ppc64 is that > we really want to start all DMA writes on a cacheline boundary. We > enforce that in network drivers by making NET_IP_ALIGN = 0 and having > the drivers do: > > skb_reserve(skb, NET_IP_ALIGN); > > It sounds like your small allocations will be only aligned to 16 bytes. > We didn't get any ppc64 with PCI-E to run Linux so far. What performance drop should we expect with our current code ? > Id suggest using the dma API instead of the pci API. We have seen > machines in the field that have failed large pci_alloc_consistent calls > because it always asks for GFP_ATOMIC memory (it presumes the worst). > The dma API allows you to pass a GFP_ flag in which will have a much > better chance of succeeding when you dont need GFP_ATOMIC memory. > Good idea, thanks, >> +#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? > I am not sure what you mean. The only ppc64 with PCI-E that we have seen so far (a G5) couldn't do write combining according to Apple. Thanks, Brice - To unsubscribe from this list: send 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...
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... it impliments the framework as well as skge support, so it touches both your and Jeff's area. For your reference, here's the two times I've posted it this month - I'm happy to send it along again. 2006-05-18 RESEND: [PATCH] Interface Stat Clearing Framework, skge support, ethtool http://marc.theaimsgroup.com/?l=linux-netdev&m=114794065502155&w=2 2006-04-30 [PATCH] Interface Stat Clearing Framework, skge support, ethtool http://marc.theaimsgroup.com/?l=linux-netdev&m=114636704207480&w=2 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. Thanks. -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." - Dr. Seuss signature.asc Description: OpenPGP digital signature
[PATCH 5/5] s390: lcs driver bug fixes and improvements [2/2]
From: Klaus Wacker <[EMAIL PROTECTED]>
This is the second lcs driver patch containing the rest of lcs fixes.
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
---
drivers/s390/net/lcs.h | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
6956e921ffef4871ce2d422cbcbdad863f7ab0b3
diff --git a/drivers/s390/net/lcs.h b/drivers/s390/net/lcs.h
index 2fad5e4..9314393 100644
--- a/drivers/s390/net/lcs.h
+++ b/drivers/s390/net/lcs.h
@@ -73,13 +73,17 @@ do {
/**
* LCS sense byte definitions
*/
+#define LCS_SENSE_BYTE_0 0
+#define LCS_SENSE_BYTE_1 1
+#define LCS_SENSE_BYTE_2 2
+#define LCS_SENSE_BYTE_3 3
#define LCS_SENSE_INTERFACE_DISCONNECT 0x01
#define LCS_SENSE_EQUIPMENT_CHECK 0x10
#define LCS_SENSE_BUS_OUT_CHECK0x20
#define LCS_SENSE_INTERVENTION_REQUIRED 0x40
#define LCS_SENSE_CMD_REJECT 0x80
-#define LCS_SENSE_RESETTING_EVENT 0x0080
-#define LCS_SENSE_DEVICE_ONLINE0x0020
+#define LCS_SENSE_RESETTING_EVENT 0x80
+#define LCS_SENSE_DEVICE_ONLINE0x20
/**
* LCS packet type definitions
@@ -152,10 +156,9 @@ enum lcs_dev_states {
enum lcs_threads {
LCS_SET_MC_THREAD = 1,
- LCS_STARTLAN_THREAD = 2,
- LCS_STOPLAN_THREAD = 4,
- LCS_STARTUP_THREAD = 8,
+ LCS_RECOVERY_THREAD = 2,
};
+
/**
* LCS struct declarations
*/
@@ -286,6 +289,7 @@ struct lcs_card {
struct net_device_stats stats;
unsigned short (*lan_type_trans)(struct sk_buff *skb,
struct net_device *dev);
+ struct ccwgroup_device *gdev;
struct lcs_channel read;
struct lcs_channel write;
struct lcs_buffer *tx_buffer;
--
1.2.4
-
To unsubscribe from this list: send 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/5] s390: lcs driver bug fixes and improvements [1/2]
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]>
---
drivers/s390/net/lcs.c | 341
1 files changed, 171 insertions(+), 170 deletions(-)
c9db4a2d4c97370d5a65ef0654342052c80ed7a2
diff --git a/drivers/s390/net/lcs.c b/drivers/s390/net/lcs.c
index e65da92..c915bb5 100644
--- a/drivers/s390/net/lcs.c
+++ b/drivers/s390/net/lcs.c
@@ -68,6 +68,7 @@ static void lcs_tasklet(unsigned long);
static void lcs_start_kernel_thread(struct lcs_card *card);
static void lcs_get_frames_cb(struct lcs_channel *, struct lcs_buffer *);
static int lcs_send_delipm(struct lcs_card *, struct lcs_ipm_list *);
+static int lcs_recovery(void *ptr);
/**
* Debug Facility Stuff
@@ -429,12 +430,6 @@ lcs_setup_card(struct lcs_card *card)
card->tx_buffer = NULL;
card->tx_emitted = 0;
- /* Initialize kernel thread task used for LGW commands. */
- INIT_WORK(&card->kernel_thread_starter,
- (void *)lcs_start_kernel_thread,card);
- card->thread_start_mask = 0;
- card->thread_allowed_mask = 0;
- card->thread_running_mask = 0;
init_waitqueue_head(&card->wait_q);
spin_lock_init(&card->lock);
spin_lock_init(&card->ipm_lock);
@@ -675,8 +670,9 @@ lcs_ready_buffer(struct lcs_channel *cha
int index, rc;
LCS_DBF_TEXT(5, trace, "rdybuff");
- BUG_ON(buffer->state != BUF_STATE_LOCKED &&
- buffer->state != BUF_STATE_PROCESSED);
+ if (buffer->state != BUF_STATE_LOCKED &&
+ buffer->state != BUF_STATE_PROCESSED)
+ BUG();
spin_lock_irqsave(get_ccwdev_lock(channel->ccwdev), flags);
buffer->state = BUF_STATE_READY;
index = buffer - channel->iob;
@@ -700,7 +696,8 @@ __lcs_processed_buffer(struct lcs_channe
int index, prev, next;
LCS_DBF_TEXT(5, trace, "prcsbuff");
- BUG_ON(buffer->state != BUF_STATE_READY);
+ if (buffer->state != BUF_STATE_READY)
+ BUG();
buffer->state = BUF_STATE_PROCESSED;
index = buffer - channel->iob;
prev = (index - 1) & (LCS_NUM_BUFFS - 1);
@@ -732,8 +729,9 @@ lcs_release_buffer(struct lcs_channel *c
unsigned long flags;
LCS_DBF_TEXT(5, trace, "relbuff");
- BUG_ON(buffer->state != BUF_STATE_LOCKED &&
- buffer->state != BUF_STATE_PROCESSED);
+ if (buffer->state != BUF_STATE_LOCKED &&
+ buffer->state != BUF_STATE_PROCESSED)
+ BUG();
spin_lock_irqsave(get_ccwdev_lock(channel->ccwdev), flags);
buffer->state = BUF_STATE_EMPTY;
spin_unlock_irqrestore(get_ccwdev_lock(channel->ccwdev), flags);
@@ -1147,8 +1145,6 @@ list_modified:
list_add_tail(&ipm->list, &card->ipm_list);
}
spin_unlock_irqrestore(&card->ipm_lock, flags);
- if (card->state == DEV_STATE_UP)
- netif_wake_queue(card->dev);
}
/**
@@ -1231,17 +1227,17 @@ lcs_set_mc_addresses(struct lcs_card *ca
if (ipm != NULL)
continue; /* Address already in list. */
ipm = (struct lcs_ipm_list *)
- kmalloc(sizeof(struct lcs_ipm_list), GFP_ATOMIC);
+ kzalloc(sizeof(struct lcs_ipm_list), GFP_ATOMIC);
if (ipm == NULL) {
PRINT_INFO("Not enough memory to add "
"new multicast entry!\n");
break;
}
- memset(ipm, 0, sizeof(struct lcs_ipm_list));
memcpy(&ipm->ipm.mac_addr, buf, LCS_MAC_LENGTH);
ipm->ipm.ip_addr = im4->multiaddr;
ipm->ipm_state = LCS_IPM_STATE_SET_REQUIRED;
spin_lock_irqsave(&card->ipm_lock, flags);
+ LCS_DBF_HEX(2,trace,&ipm->ipm.ip_addr,4);
list_add(&ipm->list, &card->ipm_list);
spin_unlock_irqrestore(&card->ipm_lock, flags);
}
@@ -1269,7 +1265,15 @@ lcs_register_mc_addresses(void *data)
read_unlock(&in4_dev->mc_list_lock);
in_dev_put(in4_dev);
+ netif_carrier_off(card->dev);
+ netif_tx_disable(card->dev);
+ wait_event(card->write.wait_q,
+ (card->write.state !=
[PATCH 3/5] s390: qeth driver fixes
From: Ursula Braun <[EMAIL PROTECTED]>
From: Frank Blaschka <[EMAIL PROTECTED]>
From: Frank Pavlic <[EMAIL PROTECTED]>
- fix fake_ll during initial device bringup. fake_ll was
not active after first start of the device.
Problem only occured when qeth was built without IPV6 support.
- avoid skb usage after invocation of qeth_flush_buffers,
because skb might already be freed.
- remove yet another useless netif_wake_queue in
qeth_softsetup_ipv6 since this function is only called
when device is going online. In this case card->state will
never be in state UP. So let the net_device queue down .
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
---
drivers/s390/net/qeth_main.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
e32bb8db95c84a0af8c5688b92ed6691982e4f9c
diff --git a/drivers/s390/net/qeth_main.c b/drivers/s390/net/qeth_main.c
index 0f6648f..9dbb5be 100644
--- a/drivers/s390/net/qeth_main.c
+++ b/drivers/s390/net/qeth_main.c
@@ -3798,11 +3798,11 @@ qeth_open(struct net_device *dev)
QETH_DBF_TEXT(trace,4,"nomacadr");
return -EPERM;
}
- card->dev->flags |= IFF_UP;
- netif_start_queue(dev);
card->data.state = CH_STATE_UP;
card->state = CARD_STATE_UP;
-
+ card->dev->flags |= IFF_UP;
+ netif_start_queue(dev);
+
if (!card->lan_online && netif_carrier_ok(dev))
netif_carrier_off(dev);
return 0;
@@ -3958,7 +3958,7 @@ qeth_prepare_skb(struct qeth_card *card,
#endif
*hdr = (struct qeth_hdr *)
qeth_push_skb(card, skb, sizeof(struct qeth_hdr));
- if (hdr == NULL)
+ if (*hdr == NULL)
return -EINVAL;
return 0;
}
@@ -4416,6 +4416,8 @@ qeth_send_packet(struct qeth_card *card,
enum qeth_large_send_types large_send = QETH_LARGE_SEND_NO;
struct qeth_eddp_context *ctx = NULL;
int tx_bytes = skb->len;
+ unsigned short nr_frags = skb_shinfo(skb)->nr_frags;
+ unsigned short tso_size = skb_shinfo(skb)->tso_size;
int rc;
QETH_DBF_TEXT(trace, 6, "sendpkt");
@@ -4498,16 +4500,16 @@ qeth_send_packet(struct qeth_card *card,
card->stats.tx_packets++;
card->stats.tx_bytes += tx_bytes;
#ifdef CONFIG_QETH_PERF_STATS
- if (skb_shinfo(skb)->tso_size &&
+ if (tso_size &&
!(large_send == QETH_LARGE_SEND_NO)) {
- card->perf_stats.large_send_bytes += skb->len;
+ card->perf_stats.large_send_bytes += tx_bytes;
card->perf_stats.large_send_cnt++;
}
- if (skb_shinfo(skb)->nr_frags > 0){
+ if (nr_frags > 0){
card->perf_stats.sg_skbs_sent++;
/* nr_frags + skb->data */
card->perf_stats.sg_frags_sent +=
- skb_shinfo(skb)->nr_frags + 1;
+ nr_frags + 1;
}
#endif /* CONFIG_QETH_PERF_STATS */
}
@@ -6370,6 +6372,9 @@ qeth_netdev_init(struct net_device *dev)
if (!(card->info.unique_id & UNIQUE_ID_NOT_BY_CARD))
card->dev->dev_id = card->info.unique_id & 0x;
#endif
+ if (card->options.fake_ll &&
+ (qeth_get_netdev_flags(card) & IFF_NOARP))
+ dev->hard_header = qeth_fake_header;
dev->hard_header_parse = NULL;
dev->set_mac_address = qeth_layer2_set_mac_address;
dev->flags |= qeth_get_netdev_flags(card);
@@ -7031,14 +7036,12 @@ qeth_softsetup_ipv6(struct qeth_card *ca
QETH_DBF_TEXT(trace,3,"softipv6");
- netif_tx_disable(card->dev);
rc = qeth_send_startlan(card, QETH_PROT_IPV6);
if (rc) {
PRINT_ERR("IPv6 startlan failed on %s\n",
QETH_CARD_IFNAME(card));
return rc;
}
- netif_wake_queue(card->dev);
rc = qeth_query_ipassists(card,QETH_PROT_IPV6);
if (rc) {
PRINT_ERR("IPv6 query ipassist failed on %s\n",
--
1.2.4
-
To unsubscribe from this list: send 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/5] s390: qeth driver fixes
From: Ursula Braun <[EMAIL PROTECTED]>
From: Frank Pavlic <[EMAIL PROTECTED]>
- correct checking of sscanf-%n value in qeth_string_to_ipaddr().
- don't use netif_stop_queue outside the hard_start_xmit routine.
Rather use netif_tx_disable.
- don't call qeth_netdev_init on a recovery.
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
---
drivers/s390/net/qeth.h |2 +-
drivers/s390/net/qeth_main.c | 22 +++---
2 files changed, 12 insertions(+), 12 deletions(-)
ef153db1ac07db7ec4eba2ec29237c58944b5c7b
diff --git a/drivers/s390/net/qeth.h b/drivers/s390/net/qeth.h
index 4df0fcd..65e2b1b 100644
--- a/drivers/s390/net/qeth.h
+++ b/drivers/s390/net/qeth.h
@@ -1099,7 +1099,7 @@ qeth_string_to_ipaddr4(const char *buf,
rc = sscanf(buf, "%d.%d.%d.%d%n",
&in[0], &in[1], &in[2], &in[3], &count);
- if (rc != 4 || count)
+ if (rc != 4 || count<=0)
return -EINVAL;
for (count = 0; count < 4; count++) {
if (in[count] > 255)
diff --git a/drivers/s390/net/qeth_main.c b/drivers/s390/net/qeth_main.c
index cb14642..0f6648f 100644
--- a/drivers/s390/net/qeth_main.c
+++ b/drivers/s390/net/qeth_main.c
@@ -3817,7 +3817,7 @@ qeth_stop(struct net_device *dev)
card = (struct qeth_card *) dev->priv;
- netif_stop_queue(dev);
+ netif_tx_disable(dev);
card->dev->flags &= ~IFF_UP;
if (card->state == CARD_STATE_UP)
card->state = CARD_STATE_SOFTSETUP;
@@ -6359,12 +6359,9 @@ qeth_netdev_init(struct net_device *dev)
dev->vlan_rx_kill_vid = qeth_vlan_rx_kill_vid;
dev->vlan_rx_add_vid = qeth_vlan_rx_add_vid;
#endif
- dev->hard_header = card->orig_hard_header;
if (qeth_get_netdev_flags(card) & IFF_NOARP) {
dev->rebuild_header = NULL;
dev->hard_header = NULL;
- if (card->options.fake_ll)
- dev->hard_header = qeth_fake_header;
dev->header_cache_update = NULL;
dev->hard_header_cache = NULL;
}
@@ -6477,6 +6474,9 @@ retry:
/*network device will be recovered*/
if (card->dev) {
card->dev->hard_header = card->orig_hard_header;
+ if (card->options.fake_ll &&
+ (qeth_get_netdev_flags(card) & IFF_NOARP))
+ card->dev->hard_header = qeth_fake_header;
return 0;
}
/* at first set_online allocate netdev */
@@ -7031,7 +7031,7 @@ qeth_softsetup_ipv6(struct qeth_card *ca
QETH_DBF_TEXT(trace,3,"softipv6");
- netif_stop_queue(card->dev);
+ netif_tx_disable(card->dev);
rc = qeth_send_startlan(card, QETH_PROT_IPV6);
if (rc) {
PRINT_ERR("IPv6 startlan failed on %s\n",
@@ -7352,7 +7352,8 @@ qeth_set_large_send(struct qeth_card *ca
card->options.large_send = type;
return 0;
}
- netif_stop_queue(card->dev);
+ if (card->state == CARD_STATE_UP)
+ netif_tx_disable(card->dev);
card->options.large_send = type;
switch (card->options.large_send) {
case QETH_LARGE_SEND_EDDP:
@@ -7374,7 +7375,8 @@ qeth_set_large_send(struct qeth_card *ca
card->dev->features &= ~(NETIF_F_TSO | NETIF_F_SG);
break;
}
- netif_wake_queue(card->dev);
+ if (card->state == CARD_STATE_UP)
+ netif_wake_queue(card->dev);
return rc;
}
@@ -7427,7 +7429,7 @@ qeth_softsetup_card(struct qeth_card *ca
if ((rc = qeth_setrouting_v6(card)))
QETH_DBF_TEXT_(setup, 2, "5err%d", rc);
out:
- netif_stop_queue(card->dev);
+ netif_tx_disable(card->dev);
return 0;
}
@@ -7736,10 +7738,8 @@ static int
qeth_register_netdev(struct qeth_card *card)
{
QETH_DBF_TEXT(setup, 3, "regnetd");
- if (card->dev->reg_state != NETREG_UNINITIALIZED) {
- qeth_netdev_init(card->dev);
+ if (card->dev->reg_state != NETREG_UNINITIALIZED)
return 0;
- }
/* sysfs magic */
SET_NETDEV_DEV(card->dev, &card->gdev->dev);
return register_netdev(card->dev);
--
1.2.4
-
To unsubscribe from this list: send 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/5] s390: minor fix in cu3088
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]> --- drivers/s390/net/cu3088.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 99e5e7d1a3245f4416290a336bc9fc8107d05d5e diff --git a/drivers/s390/net/cu3088.c b/drivers/s390/net/cu3088.c index b125331..e1b8c9a 100644 --- a/drivers/s390/net/cu3088.c +++ b/drivers/s390/net/cu3088.c @@ -77,7 +77,7 @@ group_write(struct device_driver *drv, c int len; if (!(end = strchr(start, delim[i]))) - return count; + return -EINVAL; len = min_t(ptrdiff_t, BUS_ID_SIZE, end - start + 1); strlcpy (bus_ids[i], start, len); argv[i] = bus_ids[i]; -- 1.2.4 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
What's in netdev-2.6.git
The 'upstream' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git contains the following updates (queued for 2.6.18): Documentation/networking/README.ipw2200 | 10 MAINTAINERS |6 drivers/net/Kconfig | 33 drivers/net/Makefile|2 drivers/net/au1000_eth.c| 206 - drivers/net/cassini.c |9 drivers/net/e1000/Makefile |3 drivers/net/e1000/e1000.h |6 drivers/net/e1000/e1000_ethtool.c | 47 drivers/net/e1000/e1000_hw.c| 115 drivers/net/e1000/e1000_hw.h|7 drivers/net/e1000/e1000_main.c | 271 -- drivers/net/e1000/e1000_osdep.h |3 drivers/net/e1000/e1000_param.c |3 drivers/net/ibmlana.c | 20 drivers/net/ibmlana.h |6 drivers/net/ibmveth.c | 291 +- drivers/net/ibmveth.h | 11 drivers/net/ixgb/ixgb.h |9 drivers/net/ixgb/ixgb_ethtool.c | 55 drivers/net/ixgb/ixgb_hw.h |1 drivers/net/ixgb/ixgb_ids.h |4 drivers/net/ixgb/ixgb_main.c| 132 - drivers/net/ixgb/ixgb_param.c | 24 drivers/net/myri10ge/Makefile |5 drivers/net/myri10ge/myri10ge.c | 2851 drivers/net/myri10ge/myri10ge_mcp.h | 205 + drivers/net/myri10ge/myri10ge_mcp_gen_header.h | 58 drivers/net/pcmcia/pcnet_cs.c | 42 drivers/net/phy/Kconfig |6 drivers/net/phy/Makefile|1 drivers/net/phy/smsc.c | 101 drivers/net/s2io-regs.h | 32 drivers/net/s2io.c | 1476 +--- drivers/net/s2io.h | 59 drivers/net/sis900.c| 26 drivers/net/sis900.h| 10 drivers/net/sky2.c | 19 drivers/net/smc911x.c | 2307 +++ drivers/net/smc911x.h | 835 +++ drivers/net/smc91x.h| 18 drivers/net/wan/pci200syn.c | 27 drivers/net/wireless/Kconfig| 30 drivers/net/wireless/airo.c | 271 +- drivers/net/wireless/bcm43xx/bcm43xx.h |1 drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c |2 drivers/net/wireless/bcm43xx/bcm43xx_main.c | 35 drivers/net/wireless/hermes.c | 66 drivers/net/wireless/hermes.h | 43 drivers/net/wireless/hostap/hostap_80211_tx.c |1 drivers/net/wireless/hostap/hostap_ap.c | 11 drivers/net/wireless/hostap/hostap_cs.c |6 drivers/net/wireless/hostap/hostap_main.c |2 drivers/net/wireless/ipw2200.c | 849 ++- drivers/net/wireless/ipw2200.h | 83 drivers/net/wireless/orinoco.c | 251 -- drivers/net/wireless/orinoco.h | 19 drivers/net/wireless/orinoco_cs.c | 42 drivers/net/wireless/orinoco_nortel.c | 171 - drivers/net/wireless/orinoco_pci.c | 210 - drivers/net/wireless/orinoco_pci.h | 104 drivers/net/wireless/orinoco_plx.c | 223 - drivers/net/wireless/orinoco_tmd.c | 99 drivers/net/wireless/spectrum_cs.c | 81 drivers/pci/pci.c |3 drivers/s390/net/Makefile |3 drivers/s390/net/ctcmain.c | 45 drivers/s390/net/ctcmain.h | 12 drivers/s390/net/ctctty.c | 1259 -- drivers/s390/net/ctctty.h | 35 include/linux/pci.h |2 include/linux/pci_ids.h |2 include/net/ieee80211.h |6 include/net/ieee80211softmac.h | 38 include/net/ieee80211softmac_wx.h |5 net/ieee80211/ieee80211_crypt_tkip.c| 11 net/ieee80211/ieee80211_rx.c| 18 net/ieee80211/ieee80211_tx.c| 63 net/ieee80211/ieee80211_wx.c| 44 net/ieee80211/softmac/ieee80211softmac_assoc.c | 74 net/ieee80211/softmac/ieee80211softmac_auth.c |3 net/ieee80211/softmac/ieee80211softmac_event.c | 25 net/ieee80211/softmac/ieee80211softmac_module.c | 117 net/ieee80211/softmac/iee
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/sky2.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
Stephen Hemminger:
sky2: fix jumbo packet support
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 60779eb..9591096 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -979,6 +979,7 @@ static int sky2_rx_start(struct sky2_por
struct sky2_hw *hw = sky2->hw;
unsigned rxq = rxqaddr[sky2->port];
int i;
+ unsigned thresh;
sky2->rx_put = sky2->rx_next = 0;
sky2_qset(hw, rxq);
@@ -1003,9 +1004,21 @@ static int sky2_rx_start(struct sky2_por
sky2_rx_add(sky2, re->mapaddr);
}
- /* Truncate oversize frames */
- sky2_write16(hw, SK_REG(sky2->port, RX_GMF_TR_THR), sky2->rx_bufsize -
8);
- sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_ON);
+
+ /*
+* The receiver hangs if it receives frames larger than the
+* packet buffer. As a workaround, truncate oversize frames, but
+* the register is limited to 9 bits, so if you do frames > 2052
+* you better get the MTU right!
+*/
+ thresh = (sky2->rx_bufsize - 8) / sizeof(u32);
+ if (thresh > 0x1ff)
+ sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T),
RX_TRUNC_OFF);
+ else {
+ sky2_write16(hw, SK_REG(sky2->port, RX_GMF_TR_THR), thresh);
+ sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T),
RX_TRUNC_ON);
+ }
+
/* Tell chip about available buffers */
sky2_write16(hw, Y2_QADDR(rxq, PREF_UNIT_PUT_IDX), sky2->rx_put);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
