* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jeff Garzik @ 2006-06-08 20:36 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, netdev
In-Reply-To: <1149797603.23938.251.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
> On Thu, 2006-06-08 at 14:34, Jeff Garzik wrote:
>> Jon Loeliger wrote:
>>> Signed-off-by: Kriston Carson <KristonCarson@freescale.com>
>>> Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
>>> Signed-off-by: Jon Loeliger <jdl@freescale.com>
>> ACK, but patch does not apply to netdev-2.6.git#upstream.
>>
>> Jeff
>
> Thanks, Jeff.
>
> Are you willing to take the netdev parts as-is, then?
> Or would you like me to reformat the netdev parts to
> apply against the netdev-2.6.git#upstream branch?
> The patch is currently for the Paul Mackerras powerpc.git
> tree as it stands now. Should we apply it through that
> path now as you have ACK'ed it?
Is it dependent on other stuff in Paul's tree?
Normally this should come through netdev-2.6.git#upstream...
Jeff
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Rafael J. Wysocki @ 2006-06-08 20:40 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Matt Mackall, Linux Kernel Mailing List, netdev
In-Reply-To: <44886381.9050506@goop.org>
On Thursday 08 June 2006 19:50, Jeremy Fitzhardinge wrote:
> I've been trying to get suspend/resume working well on my new laptop.
> In general, netconsole has been pretty useful for extracting oopses and
> other messages, but it is of more limited help in debugging the actual
> suspend/resume cycle. The problem looks like the e1000 driver won't
> suspend while netconsole is using it, so I have to rmmod/modprobe
> netconsole around the actual suspend/resume.
>
> This is a big problem during resume because the screen is also blank, so
> I get no useful clue as to what went wrong when things go wrong. I'm
> wondering if there's some way to keep netconsole alive to the last
> possible moment during suspend, and re-woken as soon as possible during
> resume. It would be nice to have a clean solution, but I'm willing to
> use a bletcherous hack if that's what it takes.
>
> Any ideas?
Please try doing "echo 8 > /proc/sys/kernel/printk" before suspend.
Greetings,
Rafael
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jon Loeliger @ 2006-06-08 20:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev@ozlabs.org, netdev
In-Reply-To: <44888A37.3090401@garzik.org>
On Thu, 2006-06-08 at 15:36, Jeff Garzik wrote:
> Is it dependent on other stuff in Paul's tree?
Yes, very much so. Most of this patch set is an
entirely new PPC board port against his arch/powerpc
basis. The new PHY is incidentally on that board,
but the patches for its introduction could be
introduced through the netdev tree if needed.
It would just need to be coordinated some. I am,
of course, willing to work it either way as needed.
jdl
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jeff Garzik @ 2006-06-08 20:46 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, netdev, Paul Mackerras
In-Reply-To: <1149799209.23938.256.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
> On Thu, 2006-06-08 at 15:36, Jeff Garzik wrote:
>> Is it dependent on other stuff in Paul's tree?
>
> Yes, very much so. Most of this patch set is an
> entirely new PPC board port against his arch/powerpc
> basis. The new PHY is incidentally on that board,
> but the patches for its introduction could be
> introduced through the netdev tree if needed.
> It would just need to be coordinated some. I am,
> of course, willing to work it either way as needed.
I leave it up to you and Paul to coordinate, then :)
I'm fine with the patch, and if its better to merge via linuxppc.git,
that's OK with me. If you would prefer to send it via my tree, to go
ahead and get it in, that's fine too.
Jeff
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jon Loeliger @ 2006-06-08 20:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras, netdev
In-Reply-To: <44888CB3.1060507@garzik.org>
On Thu, 2006-06-08 at 15:46, Jeff Garzik wrote:
> I leave it up to you and Paul to coordinate, then :)
>
> I'm fine with the patch, and if its better to merge via linuxppc.git,
> that's OK with me. If you would prefer to send it via my tree, to go
> ahead and get it in, that's fine too.
OK, thanks. I need to re-submit 5 of 10 parts for
other cleanup issues anyway, so I think I will:
- Resubmit the entire patch set,
- Resubmit netdev parts to Paul, and netdev with
an added ACK: by you line (OK?),
- Throw myself on the mercy of "Help us Obi-wan Mackerras"
and see what he says when he wakes up!
Thanks!
jdl
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jeff Garzik @ 2006-06-08 21:01 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, netdev, Paul Mackerras
In-Reply-To: <1149799949.23938.264.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
> On Thu, 2006-06-08 at 15:46, Jeff Garzik wrote:
>
>> I leave it up to you and Paul to coordinate, then :)
>>
>> I'm fine with the patch, and if its better to merge via linuxppc.git,
>> that's OK with me. If you would prefer to send it via my tree, to go
>> ahead and get it in, that's fine too.
>
> OK, thanks. I need to re-submit 5 of 10 parts for
> other cleanup issues anyway, so I think I will:
>
> - Resubmit the entire patch set,
> - Resubmit netdev parts to Paul, and netdev with
> an added ACK: by you line (OK?),
OK with me. Since we use a specific header to indicate such, that would be:
Acked-by: Jeff Garzik <jeff@garzik.org>
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Matt Mackall @ 2006-06-08 21:07 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <44886381.9050506@goop.org>
On Thu, Jun 08, 2006 at 10:50:57AM -0700, Jeremy Fitzhardinge wrote:
> I've been trying to get suspend/resume working well on my new laptop.
> In general, netconsole has been pretty useful for extracting oopses and
> other messages, but it is of more limited help in debugging the actual
> suspend/resume cycle. The problem looks like the e1000 driver won't
> suspend while netconsole is using it, so I have to rmmod/modprobe
> netconsole around the actual suspend/resume.
That's odd. Netpoll holds a reference to the device, of course, but so
does a normal "up" interface. So that shouldn't be the problem.
Another possibility is that outgoing packets from printks in the
driver are causing difficulty. Not sure what can be done about that.
> This is a big problem during resume because the screen is also blank, so
> I get no useful clue as to what went wrong when things go wrong. I'm
> wondering if there's some way to keep netconsole alive to the last
> possible moment during suspend, and re-woken as soon as possible during
> resume. It would be nice to have a clean solution, but I'm willing to
> use a bletcherous hack if that's what it takes.
It's generally going to suck, because unlike a polled serial port, the
device needs to be put to sleep. But if you're doing suspend to RAM,
you might be able to do something like this:
- unhook net device from suspend machinery (possibly just return success)
- bounce out of suspend before the final call to ACPI is made
Net effect is you do OS-level suspend and resume of everything but the
NIC without actually powering down the core. Which should let you
debug just about everything.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: New tulip maintainer...
From: Valerie Henson @ 2006-06-08 21:24 UTC (permalink / raw)
To: Grant Grundler; +Cc: Jeff Garzik, Andrew Morton, Netdev List
In-Reply-To: <20060608160639.GH8246@colo.lackof.org>
On 6/8/06, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Thu, Jun 08, 2006 at 11:41:28AM -0400, Jeff Garzik wrote:
> > Now that we have a new tulip maintainer, perhaps a resend of the
> > long-outstanding tulip phy patches could be resent?
>
> All the tulip patches I have are archived here:
> ftp://ftp.parisc-linux.org/patches/
>
> Anything else tulip I've been involved with is available
> via CVS from cvs.parisc-linux.org/linux-2.6/
>
> Thibaut Varene has also committed his changes to that CVS.
Hey folks,
Just a quick note to say that, yes, in a moment of weak-willed
delusion, I did let Jeff pressure me into becoming the tulip
maintainer. I will accept tokens of condolence in the form of beer,
money, and old tulip cards (email me for my shipping address).
I'm going to be a tiny bit busy the next couple of weeks - minor
things like running the file systems workshop and moving house - but I
am paying attention and will start testing and shipping patches as
soon as possible.
One quick note: please use my spiffy val_henson@linux.intel.com
address (see From: address) for Linux stuff. Besides giving props to
my employer, it's much easier to send/receive patches from that
account.
-VAL
^ permalink raw reply
* Re: [RFT] Realtek 8168 ethernet support
From: Randy.Dunlap @ 2006-06-08 21:31 UTC (permalink / raw)
To: Daniel Drake; +Cc: netdev
In-Reply-To: <20060601200200.A0E0689D05D@zog.reactivated.net>
On Thu, 1 Jun 2006 21:02:00 +0100 (BST) Daniel Drake wrote:
> I've produced this patch which should allow the r8169 driver to work with the
> new Realtek 8168 chips. These are found in PCI-Express form and onboard some
> newer motherboards.
>
> Does anyone own this hardware? I'm looking for someone to test it before I
> send it on.
>
> Signed-off-by: Daniel Drake <dsd@gentoo.org>
>
> Index: linux/drivers/net/r8169.c
> ===================================================================
> --- linux.orig/drivers/net/r8169.c
> +++ linux/drivers/net/r8169.c
> @@ -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, 0x8168), },
> { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
> { PCI_DEVICE(0x16ec, 0x0116), },
> { PCI_VENDOR_ID_LINKSYS, 0x1032, PCI_ANY_ID, 0x0024, },
The (GPL) RealTek driver (from
http://www.realtek.com.tw/downloads/downloads1-3.aspx?lineid=1&famid=4&series=2003072&Software=True)
contains this PCI device table:
static struct pci_device_id r1000_pci_tbl[] __devinitdata = {
{ 0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8167, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8168, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8136, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{0,}
};
Any reason not to include all of those?
Conversely, any reason to use the RealTek r1000 driver?
> @@ -1398,6 +1399,7 @@ rtl8169_init_board(struct pci_dev *pdev,
> struct net_device *dev;
> struct rtl8169_private *tp;
> int rc = -ENOMEM, i, acpi_idle_state = 0, pm_cap;
> + u32 mmio_base = 0;
>
> assert(ioaddr_out != NULL);
>
> @@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
> }
> }
>
> - /* make sure PCI base addr 1 is MMIO */
> - if (!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
> - if (netif_msg_probe(tp)) {
> - printk(KERN_ERR PFX
> - "region #1 not an MMIO resource, aborting\n");
> - }
> - rc = -ENODEV;
> - goto err_out_mwi;
> + /* find MMIO resource: this varies between 8168 and 8169 */
> + for (i = 0; i < 5; i++) {
> + /* check resource type */
> + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> + continue;
> +
> + /* check for weird/broken PCI region reporting */
> + if (pci_resource_len(pdev, i) < R8169_REGS_SIZE)
> + continue;
> +
> + mmio_base = pci_resource_start(pdev, i);
> + break;
> }
> - /* check for weird/broken PCI region reporting */
> - if (pci_resource_len(pdev, 1) < R8169_REGS_SIZE) {
> +
> + if (mmio_base == 0) {
> if (netif_msg_probe(tp)) {
> printk(KERN_ERR PFX
> - "Invalid PCI region size(s), aborting\n");
> + "couldn't find valid MMIO resource, aborting\n");
> }
> rc = -ENODEV;
> goto err_out_mwi;
> @@ -1490,7 +1496,7 @@ rtl8169_init_board(struct pci_dev *pdev,
> pci_set_master(pdev);
>
> /* ioremap MMIO region */
> - ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE);
> + ioaddr = ioremap(mmio_base, R8169_REGS_SIZE);
> if (ioaddr == NULL) {
> if (netif_msg_probe(tp))
> printk(KERN_ERR PFX "cannot remap MMIO, aborting\n");
> -
---
~Randy
^ permalink raw reply
* [git patches] net driver fixes
From: Jeff Garzik @ 2006-06-08 21:39 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, linux-kernel
Just got back from travelling, and am catching up. Thanks to Andrew for
working with me via email while I was on the road, he pushed a couple
patches already for me.
Here are the netdev fixes that were in my 'Pending' folder. I've got a
couple libata fixes to push as well, those may not come until tomorrow.
Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/e1000/e1000_ethtool.c | 5 +++-
drivers/net/e1000/e1000_main.c | 8 +------
drivers/net/wireless/bcm43xx/bcm43xx_dma.c | 31 ++++++++++++++++++++---------
3 files changed, 28 insertions(+), 16 deletions(-)
Auke Kok:
e1000: fix ethtool test irq alloc as "probe"
e1000: remove risky prefetch on next_skb->data
Michael Buesch:
bcm43xx: add DMA rx poll workaround to DMA4
diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index ecccca3..d1c705b 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -870,13 +870,16 @@ e1000_intr_test(struct e1000_adapter *ad
*data = 0;
/* Hook up test interrupt handler just for this test */
- if (!request_irq(irq, &e1000_test_intr, 0, netdev->name, netdev)) {
+ if (!request_irq(irq, &e1000_test_intr, SA_PROBEIRQ, netdev->name,
+ netdev)) {
shared_int = FALSE;
} else if (request_irq(irq, &e1000_test_intr, SA_SHIRQ,
netdev->name, netdev)){
*data = 1;
return -1;
}
+ DPRINTK(PROBE,INFO, "testing %s interrupt\n",
+ (shared_int ? "shared" : "unshared"));
/* Disable all the interrupts */
E1000_WRITE_REG(&adapter->hw, IMC, 0xFFFFFFFF);
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index ed15fca..97e71a4 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3519,7 +3519,7 @@ #endif
buffer_info = &rx_ring->buffer_info[i];
while (rx_desc->status & E1000_RXD_STAT_DD) {
- struct sk_buff *skb, *next_skb;
+ struct sk_buff *skb;
u8 status;
#ifdef CONFIG_E1000_NAPI
if (*work_done >= work_to_do)
@@ -3537,8 +3537,6 @@ #endif
prefetch(next_rxd);
next_buffer = &rx_ring->buffer_info[i];
- next_skb = next_buffer->skb;
- prefetch(next_skb->data - NET_IP_ALIGN);
cleaned = TRUE;
cleaned_count++;
@@ -3668,7 +3666,7 @@ #endif
struct e1000_buffer *buffer_info, *next_buffer;
struct e1000_ps_page *ps_page;
struct e1000_ps_page_dma *ps_page_dma;
- struct sk_buff *skb, *next_skb;
+ struct sk_buff *skb;
unsigned int i, j;
uint32_t length, staterr;
int cleaned_count = 0;
@@ -3697,8 +3695,6 @@ #endif
prefetch(next_rxd);
next_buffer = &rx_ring->buffer_info[i];
- next_skb = next_buffer->skb;
- prefetch(next_skb->data - NET_IP_ALIGN);
cleaned = TRUE;
cleaned_count++;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
index bbecba0..d0318e5 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -624,25 +624,28 @@ err_destroy_tx0:
static u16 generate_cookie(struct bcm43xx_dmaring *ring,
int slot)
{
- u16 cookie = 0x0000;
+ u16 cookie = 0xF000;
/* Use the upper 4 bits of the cookie as
* DMA controller ID and store the slot number
- * in the lower 12 bits
+ * in the lower 12 bits.
+ * Note that the cookie must never be 0, as this
+ * is a special value used in RX path.
*/
switch (ring->mmio_base) {
default:
assert(0);
case BCM43xx_MMIO_DMA1_BASE:
+ cookie = 0xA000;
break;
case BCM43xx_MMIO_DMA2_BASE:
- cookie = 0x1000;
+ cookie = 0xB000;
break;
case BCM43xx_MMIO_DMA3_BASE:
- cookie = 0x2000;
+ cookie = 0xC000;
break;
case BCM43xx_MMIO_DMA4_BASE:
- cookie = 0x3000;
+ cookie = 0xD000;
break;
}
assert(((u16)slot & 0xF000) == 0x0000);
@@ -660,16 +663,16 @@ struct bcm43xx_dmaring * parse_cookie(st
struct bcm43xx_dmaring *ring = NULL;
switch (cookie & 0xF000) {
- case 0x0000:
+ case 0xA000:
ring = dma->tx_ring0;
break;
- case 0x1000:
+ case 0xB000:
ring = dma->tx_ring1;
break;
- case 0x2000:
+ case 0xC000:
ring = dma->tx_ring2;
break;
- case 0x3000:
+ case 0xD000:
ring = dma->tx_ring3;
break;
default:
@@ -839,8 +842,18 @@ static void dma_rx(struct bcm43xx_dmarin
/* We received an xmit status. */
struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus *)skb->data;
struct bcm43xx_xmitstatus stat;
+ int i = 0;
stat.cookie = le16_to_cpu(hw->cookie);
+ while (stat.cookie == 0) {
+ if (unlikely(++i >= 10000)) {
+ assert(0);
+ break;
+ }
+ udelay(2);
+ barrier();
+ stat.cookie = le16_to_cpu(hw->cookie);
+ }
stat.flags = hw->flags;
stat.cnt1 = hw->cnt1;
stat.cnt2 = hw->cnt2;
^ permalink raw reply related
* [PATCH 8/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jon Loeliger @ 2006-06-08 22:02 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, netdev, jeff
Signed-off-by: Kriston Carson <KristonCarson@freescale.com>
Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Acked-by: Jeff Garzik <jeff@garzik.org>
---
drivers/net/Kconfig | 6 +-
drivers/net/phy/Kconfig | 5 ++
drivers/net/phy/Makefile | 1
drivers/net/phy/vitesse.c | 112 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 121 insertions(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index bdaaad8..c1c2758 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2179,11 +2179,11 @@ config SPIDER_NET
config GIANFAR
tristate "Gianfar Ethernet"
- depends on 85xx || 83xx
+ depends on 85xx || 83xx || PPC_86xx
select PHYLIB
help
- This driver supports the Gigabit TSEC on the MPC85xx
- family of chips, and the FEC on the 8540
+ This driver supports the Gigabit TSEC on the MPC83xx, MPC85xx,
+ and MPC86xx family of chips, and the FEC on the 8540.
config GFAR_NAPI
bool "NAPI Support"
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index fa39b94..76e51b1 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -44,6 +44,11 @@ config CICADA_PHY
depends on PHYLIB
---help---
Currently supports the cis8204
+config VITESSE_PHY
+ tristate "Drivers for the Vitesse PHYs"
+ depends on PHYLIB
+ ---help---
+ Currently supports the vsc8244
endmenu
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e4116a5..a8d066e 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_DAVICOM_PHY) += davicom.o
obj-$(CONFIG_CICADA_PHY) += cicada.o
obj-$(CONFIG_LXT_PHY) += lxt.o
obj-$(CONFIG_QSEMI_PHY) += qsemi.o
+obj-$(CONFIG_VITESSE_PHY) += vitesse.o
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
new file mode 100644
index 0000000..ffd215d
--- /dev/null
+++ b/drivers/net/phy/vitesse.c
@@ -0,0 +1,112 @@
+/*
+ * Driver for Vitesse PHYs
+ *
+ * Author: Kriston Carson
+ *
+ * Copyright (c) 2005 Freescale Semiconductor, Inc.
+ *
+ * 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 <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mii.h>
+#include <linux/ethtool.h>
+#include <linux/phy.h>
+
+/* Vitesse Extended Control Register 1 */
+#define MII_VSC8244_EXT_CON1 0x17
+#define MII_VSC8244_EXTCON1_INIT 0x0000
+
+/* Vitesse Interrupt Mask Register */
+#define MII_VSC8244_IMASK 0x19
+#define MII_VSC8244_IMASK_IEN 0x8000
+#define MII_VSC8244_IMASK_SPEED 0x4000
+#define MII_VSC8244_IMASK_LINK 0x2000
+#define MII_VSC8244_IMASK_DUPLEX 0x1000
+#define MII_VSC8244_IMASK_MASK 0xf000
+
+/* Vitesse Interrupt Status Register */
+#define MII_VSC8244_ISTAT 0x1a
+#define MII_VSC8244_ISTAT_STATUS 0x8000
+#define MII_VSC8244_ISTAT_SPEED 0x4000
+#define MII_VSC8244_ISTAT_LINK 0x2000
+#define MII_VSC8244_ISTAT_DUPLEX 0x1000
+
+/* Vitesse Auxiliary Control/Status Register */
+#define MII_VSC8244_AUX_CONSTAT 0x1c
+#define MII_VSC8244_AUXCONSTAT_INIT 0x0004
+#define MII_VSC8244_AUXCONSTAT_DUPLEX 0x0020
+#define MII_VSC8244_AUXCONSTAT_SPEED 0x0018
+#define MII_VSC8244_AUXCONSTAT_GBIT 0x0010
+#define MII_VSC8244_AUXCONSTAT_100 0x0008
+
+MODULE_DESCRIPTION("Vitesse PHY driver");
+MODULE_AUTHOR("Kriston Carson");
+MODULE_LICENSE("GPL");
+
+static int vsc824x_config_init(struct phy_device *phydev)
+{
+ int err;
+
+ err = phy_write(phydev, MII_VSC8244_AUX_CONSTAT,
+ MII_VSC8244_AUXCONSTAT_INIT);
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, MII_VSC8244_EXT_CON1,
+ MII_VSC8244_EXTCON1_INIT);
+ return err;
+}
+
+static int vsc824x_ack_interrupt(struct phy_device *phydev)
+{
+ int err = phy_read(phydev, MII_VSC8244_ISTAT);
+
+ return (err < 0) ? err : 0;
+}
+
+static int vsc824x_config_intr(struct phy_device *phydev)
+{
+ int err;
+
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ err = phy_write(phydev, MII_VSC8244_IMASK,
+ MII_VSC8244_IMASK_MASK);
+ else
+ err = phy_write(phydev, MII_VSC8244_IMASK, 0);
+ return err;
+}
+
+/* Vitesse 824x */
+static struct phy_driver vsc8244_driver = {
+ .phy_id = 0x000fc6c2,
+ .name = "Vitesse VSC8244",
+ .phy_id_mask = 0x000fffc0,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = &vsc824x_config_init,
+ .config_aneg = &genphy_config_aneg,
+ .read_status = &genphy_read_status,
+ .ack_interrupt = &vsc824x_ack_interrupt,
+ .config_intr = &vsc824x_config_intr,
+ .driver = { .owner = THIS_MODULE,},
+};
+
+static int __init vsc8244_init(void)
+{
+ return phy_driver_register(&vsc8244_driver);
+}
+
+static void __exit vsc8244_exit(void)
+{
+ phy_driver_unregister(&vsc8244_driver);
+}
+
+module_init(vsc8244_init);
+module_exit(vsc8244_exit);
^ permalink raw reply related
* Re: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: David Miller @ 2006-06-08 22:13 UTC (permalink / raw)
To: gerrit; +Cc: jmorris, alan, kuznet, pekkas, yoshfuji, kaber, linux-kernel,
netdev
In-Reply-To: <200606082109.34338.gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Thu, 8 Jun 2006 21:09:33 +0100
> That is why I held back regarding the IPv6 port: I can ensure that
> this (IPv4) code is up to standard and to date, but am lacking the
> required additional time to implement the same for IPv6. I am
> trying to contact people to help with the port, but for the moment I
> will take responsibility only for the IPv4 version.
It's not like an ipv6 port is such a big pile of work.
I'd say it would take you an afternoon, max.
You don't have to test it to the point where it is ISO9000 compliant,
that's not what is being asked of you.
^ permalink raw reply
* [IPV6]: Fix RTNLGRP_IPV6_IFINFO netlink notifications
From: Patrick McHardy @ 2006-06-08 22:56 UTC (permalink / raw)
To: David S. Miller; +Cc: Kernel Netdev Mailing List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1090 bytes --]
[IPV6]: Fix RTNLGRP_IPV6_IFINFO netlink notifications
The allocated skb is too small for the message, which results in an EINVAL
getting reported to the (innocent) multicast listeners.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit f71bc8ace692302ad3a80d84b8cbccbb14e88fe5
tree 21ccfa89e911ff8e6bda04ab817367f2ac4e3173
parent 1def630a6a49dda5bc89dfbd86656293640456f0
author Patrick McHardy <kaber@trash.net> Wed, 07 Jun 2006 09:25:26 +0200
committer Patrick McHardy <kaber@trash.net> Wed, 07 Jun 2006 09:25:26 +0200
net/ipv6/addrconf.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 445006e..cc81cab 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3235,8 +3235,7 @@ static int inet6_dump_ifinfo(struct sk_b
void inet6_ifinfo_notify(int event, struct inet6_dev *idev)
{
struct sk_buff *skb;
- /* 128 bytes ?? */
- int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+172);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
^ permalink raw reply related
* Re: Netchannels: netchannel vs. socket. 2:0.
From: Hans Henrik Happe @ 2006-06-08 23:00 UTC (permalink / raw)
To: netdev
In-Reply-To: <20060608171555.GA10273@2ka.mipt.ru>
On Thursday 08 June 2006 19:15, you wrote:
> After some enhancements made for netchannel subsystem I'm pleased to
> announce, that netchannel subsystem outperforms existing layered design
> both in CPU usage and network speed.
>
> Well, after such pretentious introduction I want to cool things down.
> CPU usage is about 1-2% less for netchannels and network performance is
> about 1-2 MB higher and sometimes exceeds 84 MB/sec which, I think,
> is maximum for given network setup (e1000 receive, r8169 send, 1500 MTU).
I have followed your work closely and have wondered how it affects latency?
I have somewhat limited knowledge about TCP and how the kernel handles it, but
I guess the path from NIC to userspace hasn't increased. What about syscall
overhead caused by userspace TCP processing?
H³
^ permalink raw reply
* netif_tx_disable vs netif_stop_queue (possible races?)
From: Daniel Drake @ 2006-06-08 23:14 UTC (permalink / raw)
To: netdev; +Cc: David Brownell
Hi,
In order to avoid disconnect races in ZD1211, I'm trying to convince
myself that other USB network drivers are race-free (and why).
I brought up a possible issue in usbnet with David Brownell, but it
appears neither of us are 100% clear on the details, so it would be good
to get some extra clarification.
USB devices can be yanked out by the user at *any* time, and typically
free_netdev is called in the disconnect handler, which frees all
device-specific structures.
The issue I brought up is that code using these structures may be
running concurrently on another CPU when the disconnect handler is
invoked, resulting in access to freed data.
More specifically, we're talking about drivers/usb/net/usbnet.c and the
usbnet_disconnect() function. The race I am highlighting is that
usbnet's hard_start_xmit handler (usbnet_start_xmit) may be running when
the disconnect happens.
Is this a possible scenario?
My thoughts on avoiding this are to ensure that the TX queue is stopped
and all current transmissions in usbnet_stop (the netdev->stop hook). I
understand that the stop function is called during disconnect, because
usbnet_disconnect() calls unregister_netdev(). The stop function already
has a call to netif_stop_queue but (based on my knowledge from LDD3)
this is not enough.
My understanding is that netif_stop_queue() should be used only inside a
hard_start_xmit function, when it wants to make sure that no more
transmissions are started until the queue is reopened.
I suggested that we use netif_tx_disable here, which is effectively the
same but because it takes the lock, it guarantees that no
hard_start_xmit transmissions are running on any CPU when it returns.
David pointed out that netif_tx_disable is rarely used, and a large
number of drivers call netif_stop_queue in their stop function, so if
what I suggest is true, there may be many such potential races
elsewhere. Am I missing something simple?
Thanks,
Daniel
^ permalink raw reply
* Re: [RFT] Realtek 8168 ethernet support
From: Francois Romieu @ 2006-06-08 23:41 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Daniel Drake, netdev
In-Reply-To: <20060608143133.7e36a0b7.rdunlap@xenotime.net>
Randy.Dunlap <rdunlap@xenotime.net> :
[...]
> static struct pci_device_id r1000_pci_tbl[] __devinitdata = {
> { 0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { 0x10ec, 0x8167, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { 0x10ec, 0x8168, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { 0x10ec, 0x8136, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> {0,}
> };
>
> Any reason not to include all of those?
Nothing worrying:
- 0x8167 and 0x8168 use a different PCI region;
- some phy differences. They appear when the r1000 driver is
compared to the previous r8169 driver from realtek.
I'll pack it with other changes.
> Conversely, any reason to use the RealTek r1000 driver?
Feel free to read it and make your own mind.
--
Ueimor
^ permalink raw reply
* Re: [IPV6]: Fix RTNLGRP_IPV6_IFINFO netlink notifications
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-06-09 2:23 UTC (permalink / raw)
To: kaber, davem; +Cc: netdev
In-Reply-To: <4488AB2E.3030301@trash.net>
Hello.
In article <4488AB2E.3030301@trash.net> (at Fri, 09 Jun 2006 00:56:46 +0200), Patrick McHardy <kaber@trash.net> says:
Okay, thanks.
I think it is better to eliminate these magic numbers.
How about this?
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 445006e..b5267c6 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2860,6 +2860,11 @@ inet6_rtm_newaddr(struct sk_buff *skb, s
return inet6_addr_add(ifm->ifa_index, pfx, ifm->ifa_prefixlen);
}
+/* Maximum length of ifa_cacheinfo attributes */
+#define INET6_IFADDR_RTA_SPACE \
+ RTA_SPACE(16) /* IFA_ADDRESS */ + \
+ RTA_SPACE(sizeof(struct ifa_cacheinfo)) /* CACHEINFO */
+
static int inet6_fill_ifaddr(struct sk_buff *skb, struct inet6_ifaddr *ifa,
u32 pid, u32 seq, int event, unsigned int flags)
{
@@ -3092,7 +3097,7 @@ static int inet6_dump_ifacaddr(struct sk
static void inet6_ifa_notify(int event, struct inet6_ifaddr *ifa)
{
struct sk_buff *skb;
- int size = NLMSG_SPACE(sizeof(struct ifaddrmsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct ifaddrmsg) + INET6_IFADDR_RTA_SPACE);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
@@ -3142,6 +3147,16 @@ static void inline ipv6_store_devconf(st
#endif
}
+/* Maximum length of ifinfomsg attributes */
+#define INET6_IFINFO_RTA_SPACE \
+ RTA_SPACE(IFNAMSIZ) /* IFNAME */ + \
+ RTA_SPACE(MAX_ADDR_LEN) /* ADDRESS */ + \
+ RTA_SPACE(sizeof(u32)) /* MTU */ + \
+ RTA_SPACE(0) /* PROTINFO */ + \
+ RTA_SPACE(sizeof(u32)) /* FLAGS */ + \
+ RTA_SPACE(sizeof(struct ifla_cacheinfo)) /* CACHEINFO */ + \
+ RTA_SPACE(sizeof(__s32[DEVCONF_MAX])) /* CONF */
+
static int inet6_fill_ifinfo(struct sk_buff *skb, struct inet6_dev *idev,
u32 pid, u32 seq, int event, unsigned int flags)
{
@@ -3235,8 +3250,7 @@ static int inet6_dump_ifinfo(struct sk_b
void inet6_ifinfo_notify(int event, struct inet6_dev *idev)
{
struct sk_buff *skb;
- /* 128 bytes ?? */
- int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct ifinfomsg) + INET6_IFINFO_RTA_SPACE);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
@@ -3252,6 +3266,11 @@ void inet6_ifinfo_notify(int event, stru
netlink_broadcast(rtnl, skb, 0, RTNLGRP_IPV6_IFINFO, GFP_ATOMIC);
}
+/* Maximum length of prefix_cacheinfo attributes */
+#define INET6_PREFIX_RTA_SPACE \
+ RTA_SPACE(sizeof(((struct prefix_info *)NULL)->prefix)) /* ADDRESS */ + \
+ RTA_SPACE(sizeof(struct prefix_cacheinfo)) /* CACHEINFO */
+
static int inet6_fill_prefix(struct sk_buff *skb, struct inet6_dev *idev,
struct prefix_info *pinfo, u32 pid, u32 seq,
int event, unsigned int flags)
@@ -3296,7 +3315,7 @@ static void inet6_prefix_notify(int even
struct prefix_info *pinfo)
{
struct sk_buff *skb;
- int size = NLMSG_SPACE(sizeof(struct prefixmsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct prefixmsg) + INET6_PREFIX_RTA_SPACE);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* Re: [RFT] Realtek 8168 ethernet support
From: Jeff Garzik @ 2006-06-09 2:40 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Daniel Drake, netdev
In-Reply-To: <20060608143133.7e36a0b7.rdunlap@xenotime.net>
Randy.Dunlap wrote:
> Conversely, any reason to use the RealTek r1000 driver?
FWIW, RealTek emailed me about merging r1000. I suggested that, if the
register sets were similar, that r8169 should be updated instead, to
preserve compatibility with existing users (and not lose existing work).
Jeff
^ permalink raw reply
* Re: [RFT] Realtek 8168 ethernet support
From: Randy.Dunlap @ 2006-06-09 2:49 UTC (permalink / raw)
To: Jeff Garzik; +Cc: dsd, netdev
In-Reply-To: <4488DF85.3090901@garzik.org>
On Thu, 08 Jun 2006 22:40:05 -0400 Jeff Garzik wrote:
> Randy.Dunlap wrote:
> > Conversely, any reason to use the RealTek r1000 driver?
>
> FWIW, RealTek emailed me about merging r1000. I suggested that, if the
> register sets were similar, that r8169 should be updated instead, to
> preserve compatibility with existing users (and not lose existing work).
Sounds good to me. I'm not terribly interested in seeing
multiple drivers for the same hardware in the kernel tree.
---
~Randy
^ permalink raw reply
* Re: Firewall question
From: Andi Kleen @ 2006-06-09 3:43 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: Alex Davis, netfilter, netdev
In-Reply-To: <20060608192628.GA561@csclub.uwaterloo.ca>
> Well the DSL modem only transfers whatever data the ISP end sends to it,
> which in your case is just PPP packets (LCC or LCP I think). No one out
> on the internet
No one out on the internet, but it would be trivial for someone outside
his house. All his traffic will be on a long unsecured cable.
That is why I would never bridge home ethernet traffic onto a DSL line.
-Andi
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Andi Kleen @ 2006-06-09 3:46 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Matt Mackall, Linux Kernel Mailing List, netdev
In-Reply-To: <44886381.9050506@goop.org>
On Thursday 08 June 2006 19:50, Jeremy Fitzhardinge wrote:
> I've been trying to get suspend/resume working well on my new laptop.
> In general, netconsole has been pretty useful for extracting oopses and
> other messages, but it is of more limited help in debugging the actual
> suspend/resume cycle. The problem looks like the e1000 driver won't
> suspend while netconsole is using it, so I have to rmmod/modprobe
> netconsole around the actual suspend/resume.
If your laptop has firewire you can also use firescope.
(ftp://ftp.suse.com/pub/people/ak/firescope/)
> This is a big problem during resume because the screen is also blank, so
> I get no useful clue as to what went wrong when things go wrong. I'm
> wondering if there's some way to keep netconsole alive to the last
> possible moment during suspend, and re-woken as soon as possible during
> resume. It would be nice to have a clean solution, but I'm willing to
> use a bletcherous hack if that's what it takes.
FW keeps running as long as nobody resets the ieee1394 chip.
Networking is much more complex and will likely never work well for such
low level debug situations. Netconsole is mostly useful to catch the
odd oops during runtime.
-Andi
^ permalink raw reply
* [PATCH] wan/sdla section fixes
From: Randy.Dunlap @ 2006-06-09 3:36 UTC (permalink / raw)
To: netdev; +Cc: mike.mclagan, khc, akpm
From: Randy Dunlap <rdunlap@xenotime.net>
Priority: tossup.
netdev->set_config can be called at any time, so these references
to __initdata would be a real problem.
However, problem has not been observed AFAIK.
Fix section mismatch warnings:
WARNING: drivers/net/wan/sdla.o - Section mismatch: reference to .init.data: from .text between 'sdla_set_config' (at offset 0x1b8e) and 'sdla_stats'
WARNING: drivers/net/wan/sdla.o - Section mismatch: reference to .init.data: from .text between 'sdla_set_config' (at offset 0x1e76) and 'sdla_stats'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
drivers/net/wan/sdla.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2617-rc6.orig/drivers/net/wan/sdla.c
+++ linux-2617-rc6/drivers/net/wan/sdla.c
@@ -60,9 +60,9 @@
static const char* version = "SDLA driver v0.30, 12 Sep 1996, mike.mclagan@linux.org";
-static unsigned int valid_port[] __initdata = { 0x250, 0x270, 0x280, 0x300, 0x350, 0x360, 0x380, 0x390};
+static unsigned int valid_port[] = { 0x250, 0x270, 0x280, 0x300, 0x350, 0x360, 0x380, 0x390};
-static unsigned int valid_mem[] __initdata = {
+static unsigned int valid_mem[] = {
0xA0000, 0xA2000, 0xA4000, 0xA6000, 0xA8000, 0xAA000, 0xAC000, 0xAE000,
0xB0000, 0xB2000, 0xB4000, 0xB6000, 0xB8000, 0xBA000, 0xBC000, 0xBE000,
0xC0000, 0xC2000, 0xC4000, 0xC6000, 0xC8000, 0xCA000, 0xCC000, 0xCE000,
---
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Jeremy Fitzhardinge @ 2006-06-09 1:54 UTC (permalink / raw)
To: Matt Mackall; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <20060608210702.GD24227@waste.org>
Matt Mackall wrote:
> That's odd. Netpoll holds a reference to the device, of course, but so
> does a normal "up" interface. So that shouldn't be the problem.
> Another possibility is that outgoing packets from printks in the
> driver are causing difficulty. Not sure what can be done about that.
>
I only tried once; maybe I misunderstood what was going on. I'll try
again tonight.
Oh, I think I see what's happening. The e1000 suspend routine does this:
if (netif_running(netdev))
e1000_down(adapter);
This leaves the interface up, but it stops the queue. Then
netpoll_send_skb() has this loop:
do {
npinfo->tries--;
spin_lock(&np->dev->xmit_lock);
np->dev->xmit_lock_owner = smp_processor_id();
/*
* network drivers do not expect to be called if the queue is
* stopped.
*/
if (netif_queue_stopped(np->dev)) {
np->dev->xmit_lock_owner = -1;
spin_unlock(&np->dev->xmit_lock);
netpoll_poll(np);
udelay(50);
continue;
}
/* ... */
again: /* proposed */
} while (npinfo->tries > 0);
so this will end up in an infinite loop, since netif_queue_stopped()
will always return true, and it never looks at npinfo->tries. Should
the "continue" be "goto again"?
Also, e1000_down does a netif_poll_disable(), but I'm not sure what that
actually does... Should it prevent netpoll from even trying to send?
> It's generally going to suck, because unlike a polled serial port, the
> device needs to be put to sleep. But if you're doing suspend to RAM,
>
I'm interested in suspend-to-ram. I presume that with suspend-to-disk,
booting with built-in netconsole will tell me useful stuff; that'll be
the next experiment.
> you might be able to do something like this:
>
> - unhook net device from suspend machinery (possibly just return success)
> - bounce out of suspend before the final call to ACPI is made
>
> Net effect is you do OS-level suspend and resume of everything but the
> NIC without actually powering down the core. Which should let you
> debug just about everything.
Well, the machine has to really suspend so that I can see (and debug) a
mostly normal resume. In particular, I need the hardware to be zapped
so I can see if it is being restarted properly.
What might work is to change the e1000 suspend routine to save enough
state for resume to work, but keep the interface up so that netconsole
can keep transmitting all the way up to the point that the final acpi
call powers off the machine.
Then the e1000 would resume normally, including restarting the xmit
queue so that netconsole can start again immediately; any netconsole
output before the e1000 resume would be lost, of course (I guess it
could be buffered). That would suit me for now.
J
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Jeremy Fitzhardinge @ 2006-06-09 1:56 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Matt Mackall, Linux Kernel Mailing List, netdev
In-Reply-To: <200606082240.31473.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> Please try doing "echo 8 > /proc/sys/kernel/printk" before suspend.
>
Um, why? That would increase the amount of log output, but I don't see
how it would help with netconsole preventing suspend, or not being able
to see console messages on a blank screen after resume.
J
^ permalink raw reply
* [PATCH RFC] netpoll: don't spin forever sending to stopped queues
From: Jeremy Fitzhardinge @ 2006-06-09 2:15 UTC (permalink / raw)
To: Matt Mackall; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <20060608210702.GD24227@waste.org>
Matt Mackall wrote:
> That's odd. Netpoll holds a reference to the device, of course, but so
> does a normal "up" interface. So that shouldn't be the problem.
> Another possibility is that outgoing packets from printks in the
> driver are causing difficulty. Not sure what can be done about that.
>
Here's a patch. I haven't tested it beyond compiling it, and I don't
know if it is actually correct. In this case, it seems pointless to
spin waiting for an even which will never happen. Should
netif_poll_disable() cause netpoll_send_skb() (or something) to not even
bother trying to send? netif_poll_disable seems mysteriously simple to me.
J
--
Subject: netpoll: don't spin forever sending to stopped queues
When transmitting a skb in netpoll_send_skb(), only retry a limited
number of times if the device queue is stopped.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
diff -r aac813f54617 net/core/netpoll.c
--- a/net/core/netpoll.c Wed Jun 07 14:53:40 2006 -0700
+++ b/net/core/netpoll.c Thu Jun 08 19:00:29 2006 -0700
@@ -280,15 +280,10 @@ static void netpoll_send_skb(struct netp
* network drivers do not expect to be called if the queue is
* stopped.
*/
- if (netif_queue_stopped(np->dev)) {
- np->dev->xmit_lock_owner = -1;
- spin_unlock(&np->dev->xmit_lock);
- netpoll_poll(np);
- udelay(50);
- continue;
- }
-
- status = np->dev->hard_start_xmit(skb, np->dev);
+ status = NETDEV_TX_BUSY;
+ if (!netif_queue_stopped(np->dev))
+ status = np->dev->hard_start_xmit(skb, np->dev);
+
np->dev->xmit_lock_owner = -1;
spin_unlock(&np->dev->xmit_lock);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox