[patch 3/3] Fix phy id for LXT971A/LXT972A
From: Uwe Zeisberger [EMAIL PROTECTED]
The phy ids used are taken from an driver that used a right shift of 4 to chop
off the revision number. This driver does not shift, so the id and mask
values are wrong and must be left shifted by 4 to actually detect the chips.
Signed-off-by: Uwe Zeisberger [EMAIL PROTECTED]
Acked-by: Andy Fleming [EMAIL PROTECTED]
[akpm: this is a previously-nacked patch, but the problem is real]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/phy/lxt.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff -puN drivers/net/phy/lxt.c~fix-phy-id-for-lxt971a-lxt972a
drivers/net/phy/lxt.c
--- a/drivers/net/phy/lxt.c~fix-phy-id-for-lxt971a-lxt972a
+++ a/drivers/net/phy/lxt.c
@@ -123,9 +123,9 @@ static int lxt971_config_intr(struct phy
}
static struct phy_driver lxt970_driver = {
- .phy_id = 0x0781,
+ .phy_id = 0x7810,
.name = LXT970,
- .phy_id_mask= 0x0fff,
+ .phy_id_mask= 0xfff0,
.features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init= lxt970_config_init,
@@ -137,9 +137,9 @@ static struct phy_driver lxt970_driver =
};
static struct phy_driver lxt971_driver = {
- .phy_id = 0x0001378e,
+ .phy_id = 0x001378e0,
.name = LXT971,
- .phy_id_mask= 0x0fff,
+ .phy_id_mask= 0xfff0,
.features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_aneg= genphy_config_aneg,
_
-
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] drivers/net/ns83820.c: add paramter to disable autonegotiation
From: Dan Faerch [EMAIL PROTECTED]
Adds ethtool command support to driver. Initially 2 commands are
implemented: force fullduplex and toggle autoneg.
Also added a disable_autoneg module argument to completely disable
autoneg on all cards using this driver.
Signed-off-by: Dan Faerch [EMAIL PROTECTED]
Cc: Benjamin LaHaise [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
[akpm: this is a previously-nacked patch, but the problem is real]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/ns83820.c | 183 +---
1 file changed, 172 insertions(+), 11 deletions(-)
diff -puN
drivers/net/ns83820.c~drivers-net-ns83820c-add-paramter-to-disable-auto
drivers/net/ns83820.c
--- a/drivers/net/ns83820.c~drivers-net-ns83820c-add-paramter-to-disable-auto
+++ a/drivers/net/ns83820.c
@@ -1,4 +1,4 @@
-#define VERSION 0.22
+#define VERSION 0.23
/* ns83820.c by Benjamin LaHaise with contributions.
*
* Questions/comments/discussion to [EMAIL PROTECTED]
@@ -68,6 +68,9 @@
* 200504060.22 - improved DAC ifdefs from Andi Kleen
* - removal of dead code from Adrian Bunk
* - fix half duplex collision behaviour
+ * 200602130.23 - Basic skeleton for adding ethtool commands.
+ * Setting of autoneg full-duplex via ethtool
+ * by Dan Faerch [EMAIL PROTECTED]
* Driver Overview
* ===
*
@@ -126,8 +129,9 @@
/* Global parameters. See module_param near the bottom. */
static int ihr = 2;
-static int reset_phy = 0;
-static int lnksts = 0; /* CFG_LNKSTS bit polarity */
+static int reset_phy;
+static int lnksts; /* CFG_LNKSTS bit polarity */
+static int disable_autoneg;
/* Dprintk is used for more interesting debug events */
#undef Dprintk
@@ -1259,6 +1263,154 @@ static struct net_device_stats *ns83820_
return dev-stats;
}
+/* Let ethtool retrieve info */
+static int ns83820_get_settings(struct net_device *ndev,
+ struct ethtool_cmd *cmd)
+{
+ struct ns83820 *dev = PRIV(ndev);
+ u32 cfg, tanar, tbicr;
+ int have_optical = 0;
+ int fullduplex = 0;
+
+ /*
+* Here's the list of available ethtool commands from other drivers:
+* cmd-advertising =
+* cmd-speed =
+* cmd-duplex =
+* cmd-port = 0;
+* cmd-phy_address =
+* cmd-transceiver = 0;
+* cmd-autoneg =
+* cmd-maxtxpkt = 0;
+* cmd-maxrxpkt = 0;
+*/
+
+ /* read current configuration */
+ cfg = readl(dev-base + CFG) ^ SPDSTS_POLARITY;
+ tanar = readl(dev-base + TANAR);
+ tbicr = readl(dev-base + TBICR);
+
+ if (dev-CFG_cache CFG_TBI_EN) {
+ /* we have an optical interface */
+ have_optical = 1;
+ fullduplex = (cfg CFG_DUPSTS) ? 1 : 0;
+
+ } else {
+ /* We have copper */
+ fullduplex = (cfg CFG_DUPSTS) ? 1 : 0;
+}
+
+ cmd-supported = SUPPORTED_Autoneg;
+
+ /* we have optical interface */
+ if (dev-CFG_cache CFG_TBI_EN) {
+ cmd-supported |= SUPPORTED_1000baseT_Half |
+ SUPPORTED_1000baseT_Full |
+ SUPPORTED_FIBRE;
+ cmd-port = PORT_FIBRE;
+ } /* TODO: else copper related support */
+
+ cmd-duplex = fullduplex ? DUPLEX_FULL : DUPLEX_HALF;
+ switch (cfg / CFG_SPDSTS0 3) {
+ case 2:
+ cmd-speed = SPEED_1000;
+ break;
+ case 1:
+ cmd-speed = SPEED_100;
+ break;
+ default:
+ cmd-speed = SPEED_10;
+ break;
+ }
+ cmd-autoneg = (tbicr TBICR_MR_AN_ENABLE) ? 1: 0;
+ return 0;
+}
+
+/* Let ethool change settings*/
+static int ns83820_set_settings(struct net_device *ndev,
+ struct ethtool_cmd *cmd)
+{
+ struct ns83820 *dev = PRIV(ndev);
+ u32 cfg, tanar;
+ int have_optical = 0;
+ int fullduplex = 0;
+
+ /* read current configuration */
+ cfg = readl(dev-base + CFG) ^ SPDSTS_POLARITY;
+ tanar = readl(dev-base + TANAR);
+
+ if (dev-CFG_cache CFG_TBI_EN) {
+ /* we have optical */
+ have_optical = 1;
+ fullduplex = (tanar TANAR_FULL_DUP);
+
+ } else {
+ /* we have copper */
+ fullduplex = cfg CFG_DUPSTS;
+ }
+
+ spin_lock_irq(dev-misc_lock);
+ spin_lock(dev-tx_lock);
+
+ /* Set duplex */
+ if (cmd-duplex != fullduplex) {
+ if (have_optical) {
+ /*set full duplex*/
+ if (cmd-duplex == DUPLEX_FULL) {
+ /* force full
[patch 1/3] natsemi: Add quirks for Aculab E1/T1 PMXc cPCI carrier cards
From: Mark Brown [EMAIL PROTECTED]
Aculab E1/T1 PMXc cPCI carrier card cards present a natsemi on the cPCI bus
wired up in a non-standard fashion. This patch provides support in the
natsemi driver for these cards by implementing a quirk mechanism and using
that to configure appropriate settings for the card: forcing 100M full duplex,
having a large EEPROM and using the MII port while ignoring PHYs.
Signed-off-by: Mark Brown [EMAIL PROTECTED]
Cc: Tim Hockin [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
[akpm: this is a previously-nacked patch, but the problem is real]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/natsemi.c | 94 --
include/linux/pci_ids.h |3 +
2 files changed, 63 insertions(+), 34 deletions(-)
diff -puN
drivers/net/natsemi.c~natsemi-add-quirks-for-aculab-e1-t1-pmxc-cpci-carrier-cards
drivers/net/natsemi.c
---
a/drivers/net/natsemi.c~natsemi-add-quirks-for-aculab-e1-t1-pmxc-cpci-carrier-cards
+++ a/drivers/net/natsemi.c
@@ -226,7 +226,6 @@ static int full_duplex[MAX_UNITS];
NATSEMI_PG1_NREGS)
#define NATSEMI_REGS_VER 1 /* v1 added RFDR registers */
#define NATSEMI_REGS_SIZE (NATSEMI_NREGS * sizeof(u32))
-#define NATSEMI_DEF_EEPROM_SIZE24 /* 12 16-bit values */
/* Buffer sizes:
* The nic writes 32-bit values, even if the upper bytes of
@@ -344,12 +343,14 @@ None characterised.
-enum pcistuff {
+enum natsemi_quirks {
PCI_USES_IO = 0x01,
PCI_USES_MEM = 0x02,
PCI_USES_MASTER = 0x04,
PCI_ADDR0 = 0x08,
PCI_ADDR1 = 0x10,
+ MEDIA_FORCE_100FD = 0x20,
+ MEDIA_IGNORE_PHY = 0x40,
};
/* MMIO operations required */
@@ -367,17 +368,21 @@ enum pcistuff {
#define MII_FX_SEL 0x0001 /* 100BASE-FX (fiber) */
#define MII_EN_SCRM0x0004 /* enable scrambler (tp) */
-
/* array of board data directly indexed by pci_tbl[x].driver_data */
static const struct {
const char *name;
unsigned long flags;
+ int quirks;
+ int eeprom_size;
} natsemi_pci_info[] __devinitdata = {
- { NatSemi DP8381[56], PCI_IOTYPE },
+ { NatSemi DP8381[56], PCI_IOTYPE, 0, 24 },
+ { Aculab E1/T1 PMXc cPCI carrier card, PCI_IOTYPE,
+ MEDIA_FORCE_100FD | MEDIA_IGNORE_PHY, 128 },
};
static struct pci_device_id natsemi_pci_tbl[] = {
- { PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_83815, PCI_ANY_ID, PCI_ANY_ID, },
+ { PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_83815, PCI_VENDOR_ID_ACULAB,
PCI_SUBDEVICE_ID_ACULAB_174, 0, 0, 1 },
+ { PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_83815, PCI_ANY_ID, PCI_ANY_ID, 0,
0, 0 },
{ 0, },
};
MODULE_DEVICE_TABLE(pci, natsemi_pci_tbl);
@@ -815,6 +820,39 @@ static void move_int_phy(struct net_devi
udelay(1);
}
+static void __devinit natsemi_init_media (struct net_device *dev)
+{
+ struct netdev_private *np = netdev_priv(dev);
+ u32 tmp;
+
+ tmp= mdio_read(dev, MII_BMCR);
+ np-speed = (tmp BMCR_SPEED100)? SPEED_100 : SPEED_10;
+ np-duplex = (tmp BMCR_FULLDPLX)? DUPLEX_FULL : DUPLEX_HALF;
+ np-autoneg= (tmp BMCR_ANENABLE)? AUTONEG_ENABLE: AUTONEG_DISABLE;
+ np-advertising= mdio_read(dev, MII_ADVERTISE);
+
+ if ((np-advertising ADVERTISE_ALL) != ADVERTISE_ALL
+ netif_msg_probe(np)) {
+ printk(KERN_INFO natsemi %s: Transceiver default
autonegotiation %s
+ 10%s %s duplex.\n,
+ pci_name(np-pci_dev),
+ (mdio_read(dev, MII_BMCR) BMCR_ANENABLE)?
+ enabled, advertise : disabled, force,
+ (np-advertising
+ (ADVERTISE_100FULL|ADVERTISE_100HALF))?
+ 0 : ,
+ (np-advertising
+ (ADVERTISE_100FULL|ADVERTISE_10FULL))?
+ full : half);
+ }
+ if (netif_msg_probe(np))
+ printk(KERN_INFO
+ natsemi %s: Transceiver status %#04x advertising
%#04x.\n,
+ pci_name(np-pci_dev), mdio_read(dev, MII_BMSR),
+ np-advertising);
+
+}
+
static int __devinit natsemi_probe1 (struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -894,17 +932,21 @@ static int __devinit natsemi_probe1 (str
np-msg_enable = (debug = 0) ? (1debug)-1 : NATSEMI_DEF_MSG;
np-hands_off = 0;
np-intr_status = 0;
- np-eeprom_size = NATSEMI_DEF_EEPROM_SIZE;
+ np-eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
option = find_cnt MAX_UNITS ? options[find_cnt] : 0;
if (dev-mem_start)
option = dev-mem_start;
/* Ignore the PHY status? */
- if (option 0x400) {
+ if (natsemi_pci_info[chip_idx].quirks MEDIA_IGNORE_PHY) {
[patch 2/2] tulip: NatSemi DP83840A PHY fix
From: Thibaut VARENE [EMAIL PROTECTED]
Fix a problem with Tulip 21142 HP branded PCI cards (PN#: B5509-66001),
which feature a NatSemi DP83840A PHY.
Without that patch, it is impossible to properly initialize the card's PHY,
and it's thus impossible to monitor/configure it.
It's a timing/posting problem, and it is solved exactly the same way Grant
fixed it elsewhere already.
Signed-off-by: Thibaut VARENE [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Acked-by: Grant Grundler [EMAIL PROTECTED]
Cc: Valerie Henson [EMAIL PROTECTED]
[akpm: this is a previously-nacked patch, but the problem is real]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/tulip/media.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff -puN drivers/net/tulip/media.c~tulip-natsemi-dp83840a-phy-fix
drivers/net/tulip/media.c
--- a/drivers/net/tulip/media.c~tulip-natsemi-dp83840a-phy-fix
+++ a/drivers/net/tulip/media.c
@@ -263,11 +263,27 @@ void tulip_select_media(struct net_devic
u16 *reset_sequence =
((u16*)(p+3))[init_length];
int reset_length = p[2 + init_length*2];
misc_info = reset_sequence + reset_length;
- if (startup)
+ if (startup) {
+ int timeout = 10; /* max 1 ms */
for (i = 0; i reset_length; i++)
iowrite32(get_u16(reset_sequence[i]) 16, ioaddr + CSR15);
+
+ /* flush posted writes */
+ ioread32(ioaddr + CSR15);
+
+ /* Sect 3.10.3 in DP83840A.pdf (p39) */
+ udelay(500);
+
+ /* Section 4.2 in DP83840A.pdf (p43) */
+ /* and IEEE 802.3 22.2.4.1.1 Reset */
+ while (timeout--
+ (tulip_mdio_read (dev, phy_num,
MII_BMCR) BMCR_RESET))
+ udelay(100);
+ }
for (i = 0; i init_length; i++)
iowrite32(get_u16(init_sequence[i])
16, ioaddr + CSR15);
+
+ ioread32(ioaddr + CSR15); /* flush posted
writes */
} else {
u8 *init_sequence = p + 2;
u8 *reset_sequence = p + 3 + init_length;
_
-
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/2] tulip: fix for 64-bit mips
From: Jim Gifford [EMAIL PROTECTED],
Grant Grundler [EMAIL PROTECTED],
Peter Horton [EMAIL PROTECTED]
With Grant's help I was able to get the tulip driver to work with 64 bit
MIPS.
Cc: Valerie Henson [EMAIL PROTECTED]
[akpm: this is a previously-nacked patch, but the problem is real]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/tulip/media.c | 22 --
drivers/net/tulip/tulip.h |7 +--
drivers/net/tulip/tulip_core.c |2 +-
3 files changed, 26 insertions(+), 5 deletions(-)
diff -puN drivers/net/tulip/media.c~tulip-fix-for-64-bit-mips
drivers/net/tulip/media.c
--- a/drivers/net/tulip/media.c~tulip-fix-for-64-bit-mips
+++ a/drivers/net/tulip/media.c
@@ -44,8 +44,10 @@ static const unsigned char comet_miireg2
/* MII transceiver control section.
Read and write the MII registers using software-generated serial
- MDIO protocol. See the MII specifications or DP83840A data sheet
- for details. */
+ MDIO protocol.
+ See IEEE 802.3-2002.pdf (Section 2, Chapter 22.2.4 Management functions)
+ or DP83840A data sheet for more details.
+ */
int tulip_mdio_read(struct net_device *dev, int phy_id, int location)
{
@@ -272,13 +274,29 @@ void tulip_select_media(struct net_devic
int reset_length = p[2 + init_length];
misc_info = (u16*)(reset_sequence +
reset_length);
if (startup) {
+ int timeout = 10; /* max 1 ms */
iowrite32(mtable-csr12dir | 0x100,
ioaddr + CSR12);
for (i = 0; i reset_length; i++)
iowrite32(reset_sequence[i],
ioaddr + CSR12);
+
+ /* flush posted writes */
+ ioread32(ioaddr + CSR12);
+
+ /* Sect 3.10.3 in DP83840A.pdf (p39) */
+ udelay(500);
+
+ /* Section 4.2 in DP83840A.pdf (p43) */
+ /* and IEEE 802.3 22.2.4.1.1 Reset */
+ while (timeout--
+ (tulip_mdio_read (dev, phy_num,
MII_BMCR) BMCR_RESET))
+ udelay(100);
}
for (i = 0; i init_length; i++)
iowrite32(init_sequence[i], ioaddr +
CSR12);
+
+ ioread32(ioaddr + CSR12); /* flush posted
writes */
}
+
tmp_info = get_u16(misc_info[1]);
if (tmp_info)
tp-advertising[phy_num] = tmp_info | 1;
diff -puN drivers/net/tulip/tulip_core.c~tulip-fix-for-64-bit-mips
drivers/net/tulip/tulip_core.c
--- a/drivers/net/tulip/tulip_core.c~tulip-fix-for-64-bit-mips
+++ a/drivers/net/tulip/tulip_core.c
@@ -22,7 +22,7 @@
#else
#define DRV_VERSION1.1.13
#endif
-#define DRV_RELDATEMay 11, 2002
+#define DRV_RELDATEDecember 15, 2004
#include linux/module.h
diff -puN drivers/net/tulip/tulip.h~tulip-fix-for-64-bit-mips
drivers/net/tulip/tulip.h
--- a/drivers/net/tulip/tulip.h~tulip-fix-for-64-bit-mips
+++ a/drivers/net/tulip/tulip.h
@@ -474,8 +474,11 @@ static inline void tulip_stop_rxtx(struc
udelay(10);
if (!i)
- printk(KERN_DEBUG %s: tulip_stop_rxtx() failed\n,
- pci_name(tp-pdev));
+ printk(KERN_DEBUG %s: tulip_stop_rxtx() failed
+(CSR5 0x%x CSR6 0x%x)\n,
+ pci_name(tp-pdev),
+ ioread32(ioaddr + CSR5),
+ ioread32(ioaddr + CSR6));
}
}
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/6] netpoll: don't spin forever sending to stopped queues
From: Jeremy Fitzhardinge [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Acked-by: Matt Mackall [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/core/netpoll.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff -puN
net/core/netpoll.c~netpoll-dont-spin-forever-sending-to-blocked-queues
net/core/netpoll.c
--- a/net/core/netpoll.c~netpoll-dont-spin-forever-sending-to-blocked-queues
+++ a/net/core/netpoll.c
@@ -279,14 +279,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)) {
- netif_tx_unlock(np-dev);
- netpoll_poll(np);
- udelay(50);
- continue;
- }
+ status = NETDEV_TX_BUSY;
+ if (!netif_queue_stopped(np-dev))
+ status = np-dev-hard_start_xmit(skb, np-dev);
- status = np-dev-hard_start_xmit(skb, np-dev);
netif_tx_unlock(np-dev);
/* success */
_
-
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/6] netpoll: break recursive loop in netpoll rx path
From: Neil Horman [EMAIL PROTECTED]
The netpoll system currently has a rx to tx path via:
netpoll_rx
__netpoll_rx
arp_reply
netpoll_send_skb
dev-hard_start_tx
This rx-tx loop places network drivers at risk of inadvertently causing a
deadlock or BUG halt by recursively trying to acquire a spinlock that is
used in both their rx and tx paths (this problem was origionally reported
to me in the 3c59x driver, which shares a spinlock between the
boomerang_interrupt and boomerang_start_xmit routines).
This patch breaks this loop, by queueing arp frames, so that they can be
responded to after all receive operations have been completed. Tested by
myself and the reported with successful results.
Specifically it was tested with netdump. Heres the BZ with details:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194055
Signed-off-by: Neil Horman [EMAIL PROTECTED]
Acked-by: Matt Mackall [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
include/linux/netpoll.h |1 +
net/core/netpoll.c | 26 --
2 files changed, 25 insertions(+), 2 deletions(-)
diff -puN
include/linux/netpoll.h~netpoll-break-recursive-loop-in-netpoll-rx-path
include/linux/netpoll.h
--- a/include/linux/netpoll.h~netpoll-break-recursive-loop-in-netpoll-rx-path
+++ a/include/linux/netpoll.h
@@ -31,6 +31,7 @@ struct netpoll_info {
int rx_flags;
spinlock_t rx_lock;
struct netpoll *rx_np; /* netpoll that registered an rx_hook */
+ struct sk_buff_head arp_tx; /* list of arp requests to reply to */
};
void netpoll_poll(struct netpoll *np);
diff -puN net/core/netpoll.c~netpoll-break-recursive-loop-in-netpoll-rx-path
net/core/netpoll.c
--- a/net/core/netpoll.c~netpoll-break-recursive-loop-in-netpoll-rx-path
+++ a/net/core/netpoll.c
@@ -54,6 +54,7 @@ static atomic_t trapped;
sizeof(struct iphdr) + sizeof(struct ethhdr))
static void zap_completion_queue(void);
+static void arp_reply(struct sk_buff *skb);
static void queue_process(void *p)
{
@@ -153,6 +154,22 @@ static void poll_napi(struct netpoll *np
}
}
+static void service_arp_queue(struct netpoll_info *npi)
+{
+ struct sk_buff *skb;
+
+ if (unlikely(!npi))
+ return;
+
+ skb = skb_dequeue(npi-arp_tx);
+
+ while (skb != NULL) {
+ arp_reply(skb);
+ skb = skb_dequeue(npi-arp_tx);
+ }
+ return;
+}
+
void netpoll_poll(struct netpoll *np)
{
if(!np-dev || !netif_running(np-dev) || !np-dev-poll_controller)
@@ -163,6 +180,8 @@ void netpoll_poll(struct netpoll *np)
if (np-dev-poll)
poll_napi(np);
+ service_arp_queue(np-dev-npinfo);
+
zap_completion_queue();
}
@@ -442,7 +461,9 @@ int __netpoll_rx(struct sk_buff *skb)
int proto, len, ulen;
struct iphdr *iph;
struct udphdr *uh;
- struct netpoll *np = skb-dev-npinfo-rx_np;
+ struct netpoll_info *npi = skb-dev-npinfo;
+ struct netpoll *np = npi-rx_np;
+
if (!np)
goto out;
@@ -452,7 +473,7 @@ int __netpoll_rx(struct sk_buff *skb)
/* check if netpoll clients need ARP */
if (skb-protocol == __constant_htons(ETH_P_ARP)
atomic_read(trapped)) {
- arp_reply(skb);
+ skb_queue_tail(npi-arp_tx, skb);
return 1;
}
@@ -647,6 +668,7 @@ int netpoll_setup(struct netpoll *np)
npinfo-poll_owner = -1;
npinfo-tries = MAX_RETRIES;
spin_lock_init(npinfo-rx_lock);
+ skb_queue_head_init(npinfo-arp_tx);
} else
npinfo = ndev-npinfo;
_
-
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/6] IRDA: add some IBM think pads
From: Ben Collins [EMAIL PROTECTED]
[UBUNTU:nsc-ircc] Add some IBM think pads
Add Thinkpad T60/X60/Z60/T43/R52 Infrared driver support.
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=7b8d2713435a9fb69719a282ba75e117f3f76a5b
Cc: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: Ben Collins [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/irda/nsc-ircc.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff -puN drivers/net/irda/nsc-ircc.c~irda-add-some-ibm-think-pads
drivers/net/irda/nsc-ircc.c
--- a/drivers/net/irda/nsc-ircc.c~irda-add-some-ibm-think-pads
+++ a/drivers/net/irda/nsc-ircc.c
@@ -115,8 +115,12 @@ static nsc_chip_t chips[] = {
/* Contributed by Jan Frey - IBM A30/A31 */
{ PC8739x, { 0x2e, 0x4e, 0x0 }, 0x20, 0xea, 0xff,
nsc_ircc_probe_39x, nsc_ircc_init_39x },
- { IBM, { 0x2e, 0x4e, 0x0 }, 0x20, 0xf4, 0xff,
- nsc_ircc_probe_39x, nsc_ircc_init_39x },
+ /* IBM ThinkPads using PC8738x (T60/X60/Z60) */
+ { IBM-PC8738x, { 0x2e, 0x4e, 0x0 }, 0x20, 0xf4, 0xff,
+ nsc_ircc_probe_39x, nsc_ircc_init_39x },
+ /* IBM ThinkPads using PC8394T (T43/R52/?) */
+ { IBM-PC8394T, { 0x2e, 0x4e, 0x0 }, 0x20, 0xf9, 0xff,
+ nsc_ircc_probe_39x, nsc_ircc_init_39x },
{ NULL }
};
_
-
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/6] ppp_async hang fix
From: [EMAIL PROTECTED] Adapted from http://bugzilla.kernel.org/show_bug.cgi?id=6530 Reschedule the async Tx tasklet if the transmit queue was full. Cc: Paul Mackerras [EMAIL PROTECTED] [akpm: submitted before, discussion petered off inconclusively] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/ppp_async.c |2 ++ 1 file changed, 2 insertions(+) diff -puN drivers/net/ppp_async.c~ppp_async-hang-fix drivers/net/ppp_async.c --- a/drivers/net/ppp_async.c~ppp_async-hang-fix +++ a/drivers/net/ppp_async.c @@ -516,6 +516,8 @@ static void ppp_async_process(unsigned l /* try to push more stuff out */ if (test_bit(XMIT_WAKEUP, ap-xmit_flags) ppp_async_push(ap)) ppp_output_wakeup(ap-chan); + else if (test_bit(XMIT_FULL, ap-xmit_flags)) + ppp_asynctty_wakeup(ap-tty); } /* _ - 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 5/6] atm/mpc.c warning fix
From: Andrew Morton [EMAIL PROTECTED]
net/atm/mpc.c: In function 'MPOA_res_reply_rcvd':
net/atm/mpc.c:1116: warning: unused variable 'ip'
Cc: chas williams [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/atm/mpc.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -puN net/atm/mpc.c~atm-mpcc-warning-fix net/atm/mpc.c
--- a/net/atm/mpc.c~atm-mpcc-warning-fix
+++ a/net/atm/mpc.c
@@ -1113,10 +1113,9 @@ static void check_qos_and_open_shortcut(
static void MPOA_res_reply_rcvd(struct k_message *msg, struct mpoa_client *mpc)
{
- unsigned char *ip;
-
uint32_t dst_ip = msg-content.in_info.in_dst_ip;
in_cache_entry *entry = mpc-in_ops-get(dst_ip, mpc);
+
dprintk(mpoa: (%s) MPOA_res_reply_rcvd: ip %u.%u.%u.%u\n,
mpc-dev-name, NIPQUAD(dst_ip));
ddprintk(mpoa: (%s) MPOA_res_reply_rcvd() entry = %p, mpc-dev-name,
entry);
if(entry == NULL){
_
-
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] Fix phy id for LXT971A/LXT972A
[EMAIL PROTECTED] wrote: From: Uwe Zeisberger [EMAIL PROTECTED] The phy ids used are taken from an driver that used a right shift of 4 to chop off the revision number. This driver does not shift, so the id and mask values are wrong and must be left shifted by 4 to actually detect the chips. Signed-off-by: Uwe Zeisberger [EMAIL PROTECTED] Acked-by: Andy Fleming [EMAIL PROTECTED] [akpm: this is a previously-nacked patch, but the problem is real] Signed-off-by: Andrew Morton [EMAIL PROTECTED] This was nak'd? Does anyone recall why? Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/2] tulip: fix for 64-bit mips
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2006-06-25 01:45]: Cc: Valerie Henson [EMAIL PROTECTED] [akpm: this is a previously-nacked patch, but the problem is real] And, for the record, Jeff's suggestion as to how to rework the patch: | Answer hasn't changed since this was last discussed: sleep, rather than | delay for an extra-long time. That's the only hurdle for the tulip | patches you keep resending. | Francois Romieu even had an untested patch that attempted this, | somewhere. Now we just need someone to complete this work... -- Martin Michlmayr [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 3/3] Fix phy id for LXT971A/LXT972A
On Sun, 25 Jun 2006 05:15:29 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: From: Uwe Zeisberger [EMAIL PROTECTED] The phy ids used are taken from an driver that used a right shift of 4 to chop off the revision number. This driver does not shift, so the id and mask values are wrong and must be left shifted by 4 to actually detect the chips. Signed-off-by: Uwe Zeisberger [EMAIL PROTECTED] Acked-by: Andy Fleming [EMAIL PROTECTED] [akpm: this is a previously-nacked patch, but the problem is real] Signed-off-by: Andrew Morton [EMAIL PROTECTED] This was nak'd? Does anyone recall why? No, it was not nacked - I'd simply misfiled it (actually, failed to refile it after we got a changelog). - 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/6] ppp_async hang fix
[EMAIL PROTECTED] writes: From: [EMAIL PROTECTED] Adapted from http://bugzilla.kernel.org/show_bug.cgi?id=6530 Reschedule the async Tx tasklet if the transmit queue was full. Cc: Paul Mackerras [EMAIL PROTECTED] [akpm: submitted before, discussion petered off inconclusively] NACK. This fix is inefficient and also unnecessary now that I have found and fixed the real problem, which was in n_tty.c. Paul. - 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: Streamline testing of 802.11 drivers
On Fri, 2006-06-23 at 18:56 -0400, Luis R. Rodriguez wrote: Thanks Larry -- I'm sorry for not mentioning in the original thread but basically miniPCI and USB is what we can slap onto our nodes so far. We'll have to figure something out for Cardbus.. I searched and it seems there some miniPCI bcm4306. I'll see if we can come up with a cardbus solution though as I'm sure there's gotta be some card which don't ship in other form factors. Will get back to you on that. I'd say most cards come at least in USB or miniPCI as they are/were mostly for use in laptops. bcm43xx certainly does, we still have some funds that were donated so we could probably fund a few bcm43xx cards for the testbed. johannes signature.asc Description: This is a digitally signed message part
Re: [patch 6/6] neighbour.c, pneigh_get_next() skips published entry
[EMAIL PROTECTED] wrote:
[akpm: submitted before, discussion ended inconclusively, iirc]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
I still need to try to reproduce this. I might be able to allocate some
time on this soon.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] skb_find_text ignores to argument
skb_find_text takes a to argument which is supposed to limit how
far into the skb it will search for the given text. At present,
it seems to ignore that argument on the first skb, and instead
return a match even if the text occurs beyond the limit.
Patch below fixes this, after adjusting for the from starting
point. This consequently fixes the netfilter string match's --to
handling, which currently is broken.
Phil
Signed-off-by: Phil Oester [EMAIL PROTECTED]
diff -ruN linux-orig/net/core/skbuff.c linux-new/net/core/skbuff.c
--- linux-orig/net/core/skbuff.c2006-06-25 01:26:02.0 -0400
+++ linux-new/net/core/skbuff.c 2006-06-25 01:29:40.0 -0400
@@ -1739,12 +1739,15 @@
unsigned int to, struct ts_config *config,
struct ts_state *state)
{
+ unsigned int ret;
+
config-get_next_block = skb_ts_get_next_block;
config-finish = skb_ts_finish;
skb_prepare_seq_read(skb, from, to, TS_SKB_CB(state));
- return textsearch_find(config, state);
+ ret = textsearch_find(config, state);
+ return (ret = to - from ? ret : UINT_MAX);
}
/**
Re: Streamline testing of 802.11 drivers
On 6/25/06, Johannes Berg [EMAIL PROTECTED] wrote: On Fri, 2006-06-23 at 18:56 -0400, Luis R. Rodriguez wrote: Thanks Larry -- I'm sorry for not mentioning in the original thread but basically miniPCI and USB is what we can slap onto our nodes so far. We'll have to figure something out for Cardbus.. I searched and it seems there some miniPCI bcm4306. I'll see if we can come up with a cardbus solution though as I'm sure there's gotta be some card which don't ship in other form factors. Will get back to you on that. I'd say most cards come at least in USB or miniPCI as they are/were mostly for use in laptops. bcm43xx certainly does, we still have some funds that were donated so we could probably fund a few bcm43xx cards for the testbed. Excellent, will make arrangements with you off the list. Luis - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.17-mm2: no QLA3YYY_NAPI help text
[ resent with a subject adapted to vger mail filter... ] On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote: ... Changes since 2.6.17-mm1: ... +qla3xxx-NIC-driver.patch ... Net driver updates. Includes a new driver from qlogic which almost compiles. ... The QLA3XXX_NAPI option lacks a help text. Please add a help text. TIA Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
-git: Why is drivers/net/wan/hdlc_generic.c:hdlc_setup() exported?
Commit 4a31e348e3ecaf54c50240109ac4574b180f8840 added an EXPORT_SYMBOL(hdlc_setup) with the justification hdlc_setup() is now EXPORTed as per David's request. Is a usage of this export pending for the near future or could this export be reverted until a user is submitted for inclusion? TIA Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: Network performance degradation from 2.6.11.12 to 2.6.16.20
I understand the saying beggars can't be choosers, but I have heard nothing on this issue since June 19th. Does anyone have any ideas on what is going on? Is there more information I can collect that would help diagnose this problem? And again, thanks for any and all help! -- Dr. Harry EdmonE-MAIL: [EMAIL PROTECTED] 206-543-0547 [EMAIL PROTECTED] Dept of Atmospheric Sciences FAX:206-543-0308 University of Washington, Box 351640, Seattle, WA 98195-1640 - 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: Network performance degradation from 2.6.11.12 to 2.6.16.20
Hi Andi, On Mon, Jun 19, 2006 at 05:24:31PM +0200, Andi Kleen wrote: If you use pmtmr try to reboot with kernel option clock=tsc. That's dangerous advice - when the system choses not to use TSC it often has a reason. On my Opteron AMD system i normally can route 400 kpps, but with timesource pmtmr i could only route around 83 kpps. (I found the timer to be the issue by using oprofile). Unless you're using packet sniffing or any other application that requests time stamps on a socket then the timer shouldn't make much difference. Incoming packets are only time stamped when someone asks for the timestamps. I encountered the same problem on a dual core opteron equipped with a broadcom NIC (tg3) under 2.4. It could receive 1 Mpps when using TSC as the clock source, but the time jumped back and forth, so I changed it to 'notsc', then the performance dropped dramatically to around the same value as above with one CPU saturated. I suspect that the clock precision is needed by the tg3 driver to correctly decide to switch to polling mode, but unfortunately, the performance drop rendered the solution so much unusable that I finally decided to use it only in uniprocessor with TSC enabled. -Andi Regards, Willy - 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]NET: Fix GSO problems in dev_hard_start_xmit()
Fix 2 problems in dev_hard_start_xmit():
1. nskb-next needs to link back to skb-next if hard_start_xmit()
returns non-zero.
2. Since the total number of GSO fragments may exceed MAX_SKB_FRAGS + 1,
it needs to stop transmitting if the netif_queue is stopped.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/net/core/dev.c b/net/core/dev.c
index d293e0f..84e06ae 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1325,9 +1325,12 @@ int dev_hard_start_xmit(struct sk_buff *
nskb-next = NULL;
rc = dev-hard_start_xmit(nskb, dev);
if (unlikely(rc)) {
+ nskb-next = skb-next;
skb-next = nskb;
return rc;
}
+ if (unlikely(netif_queue_stopped(dev) skb-next))
+ return NETDEV_TX_BUSY;
} while (skb-next);
skb-destructor = DEV_GSO_CB(skb)-destructor;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] make net/core/dev.c:netdev_nit static
netdev_nit can now become static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- include/linux/netdevice.h |1 - net/core/dev.c|2 +- 2 files changed, 1 insertion(+), 2 deletions(-) --- linux-2.6.17-mm2-full/include/linux/netdevice.h.old 2006-06-25 23:30:55.0 +0200 +++ linux-2.6.17-mm2-full/include/linux/netdevice.h 2006-06-25 23:31:02.0 +0200 @@ -699,7 +699,6 @@ extern voiddev_init(void); -extern int netdev_nit; extern int netdev_budget; /* Called by rtnetlink.c:rtnl_unlock() */ --- linux-2.6.17-mm2-full/net/core/dev.c.old2006-06-25 23:31:08.0 +0200 +++ linux-2.6.17-mm2-full/net/core/dev.c2006-06-25 23:31:19.0 +0200 @@ -230,7 +230,7 @@ * For efficiency */ -int netdev_nit; +static int netdev_nit; /* * Add a protocol ID to the list. Now that the input handler is - 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] tulip: fix for 64-bit mips
On Sun, Jun 25, 2006 at 10:31:08AM +0100, Martin Michlmayr wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] [2006-06-25 01:45]: Cc: Valerie Henson [EMAIL PROTECTED] [akpm: this is a previously-nacked patch, but the problem is real] ia64 and parisc need the changes to tulip_select_media() too. And, for the record, Jeff's suggestion as to how to rework the patch: | Answer hasn't changed since this was last discussed: sleep, rather than | delay for an extra-long time. That's the only hurdle for the tulip | patches you keep resending. | Francois Romieu even had an untested patch that attempted this, | somewhere. Now we just need someone to complete this work... Kyle McMartin has the work queue patch merged into the cvs.parisc-linux.org CVS tree. It would be easiest to accept this patch and then add the tulip work queue patch next. Note that the work queue does NOT solve all of the spin delay with interrupts blocked problems. tulip_stop_rxtx() polls for nearly as long and tulip_select_media(). thanks, grant -- Martin Michlmayr [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]NET: Fix GSO problems in dev_hard_start_xmit()
On Sun, Jun 25, 2006 at 03:38:05PM -0700, Michael Chan wrote:
Fix 2 problems in dev_hard_start_xmit():
1. nskb-next needs to link back to skb-next if hard_start_xmit()
returns non-zero.
2. Since the total number of GSO fragments may exceed MAX_SKB_FRAGS + 1,
it needs to stop transmitting if the netif_queue is stopped.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
Good catch.
Acked-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
On Fri, 2006-06-23 at 17:21 +0200, Patrick McHardy wrote: Not really. The randomization doesn't happen by default, but it doesn't influence this anyway. SFQ allows flows to send up to quantum bytes at a time before moving on to the next one. A flow that sends 75 * 20 byte will in the eyes of SFQ use 1500bytes, on the (ethernet) wire it needs 4800bytes. A flow that sents 1500byte packets will only need 1504 bytes on the wire, but will be treated equally. So it does make a different for SFQ. I hadn't even thought to check. My bad. The S in SFQ stands for stochastic, so something that does without randomisation the algorithm implemented couldn't really be called SFQ - particularly as it weakens the algorithm considerably. I hope that most users do specify a perturb. Your 20 byte example is hardly realistic. skb-len includes the 14 byte ethernet header, so there is a total of 6 data bytes in a 20 byte packet. The IP header alone is 20 bytes. TCP as implemented on Linux adds another 32 bytes (20 + the rtt option). In other words I agree with Jamal's comments elsewhere - optimising for MPU sized packets doesn't seem like a win. Not a problem as long as the new stuff doesn't break anything existing. My patch introduces a TCA_STAB (for size table), similar to the _RTAB attributes. Old iproute with new kernel and new iproute with old kernel both work fine. OK, good. Its not about cleanup, its about providing the same capabilities to all qdiscs instead of just a few selected ones and generalizing it so it is also usable for non-ATM overhead calculations. Perhaps I chose my words poorly. My intent was to contrast the size and goals of the two proposed patches. The ATM patch is a 37 line patch. It includes some minor cleanups. From the pseudo code you have posted what you are proposing is a more ambitious and much larger patch that moves a chunk of user space code into the kernel. I am a complete newbie when it comes to getting code into the kernel, but that strikes me as contentious. I would rather not have the ATM patch depend on it. By the by, here are a couple of observations: 1. The entries in the current rtab are already very closely related to packet lengths. They are actually the packet length multiplied by a constant that converts the units from bytes to jiffies. The constant is the same for all entries in the table. 2. As such, the current rtab could already be used by SFQ and any other qdisc that needs to know the packet length. That SFQ doesn't do this is probably because it doesn't effect its performance overly. 3. Be that as it may, the current RTAB isn't in the most convenient form for SFQ, and I am guessing it is in a very inconvenient form for HFSC. Adding a new version that is identical except that it contains the raw packet length would be a simple change. In that format it could be used by all qdiscs. The users of the existing rtab would have to do the multiplication that converts the packet length to jiffies in the kernel. This means the conceptually at least, should the gootput change you need to change this one constant, not the entire table. 4. Much as you seem to dislike having the rate / packet length calculations in user space, having them there makes it easy to add new technologies such as ATM. You just have to change a user space tool - not the kernel. 5. We still did have to modify the kernel for ATM. That was because of its rather unusual characteristics. However, it you look at the size of modifications made to the kernel verses the size made to the user space tool, (37 lines versus 303 lines,) the bulk of the work was does in user space. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
bcm43xx: transmit timed out and apparent hang with preemptible periodic work patches
With the bcm43xx periodic work patches that recently made it into Linus's tree, my PowerBook does not survive running overnight. Yesterday I reverted 91769e7dd9cef7988dc4280f74ed168351beb5b8 [PATCH] bcm43xx: preemptible periodic work 78ff56a06edc3407996173daf63e48f6b90c7062 [PATCH] bcm43xx: redesign locking and it was still alive this morning. The following is logged, but that may not be all since the screen was turned off and kern.log was marked for no-fsync. Jun 24 06:53:41 briny kernel: NETDEV WATCHDOG: eth1: transmit timed out Jun 24 06:53:41 briny kernel: bcm43xx: Controller RESET (TX timeout) ... Jun 24 06:53:41 briny kernel: bcm43xx: Chip ID 0x4306, rev 0x3 Jun 24 06:53:41 briny kernel: bcm43xx: Number of cores: 5 Jun 24 06:53:41 briny kernel: bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled Jun 24 06:53:41 briny kernel: bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled Jun 24 06:53:41 briny kernel: bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled Jun 24 06:53:41 briny kernel: bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled Jun 24 06:53:41 briny kernel: bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled Jun 24 06:53:41 briny kernel: bcm43xx: PHY connected Jun 24 06:53:41 briny kernel: bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2 Jun 24 06:53:41 briny kernel: bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jun 24 06:53:41 briny kernel: bcm43xx: Radio turned off Jun 24 06:53:41 briny kernel: bcm43xx: Radio turned off Jun 24 06:53:41 briny kernel: bcm43xx: Controller restarted Config options: CONFIG_BCM43XX=m CONFIG_BCM43XX_DEBUG=y CONFIG_BCM43XX_DMA=y CONFIG_BCM43XX_PIO=y CONFIG_BCM43XX_DMA_AND_PIO_MODE=y # CONFIG_BCM43XX_DMA_MODE is not set # CONFIG_BCM43XX_PIO_MODE is not set And preemptible made me check for PREEMPT options: # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set -- Paul Collins Melbourne, Australia Dag vijandelijk luchtschip de huismeester is dood - 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] Convert bcm43xx-softmac to use the ieee80211_is_valid_channel routine
The current version of bcm43xx-softmac uses local routines to check if a channel is valid. As noted
in the comments, these routines do not take any regulatory information into account. This patch
converts the code to use the equivalent routine in ieee80211, which is being converted to know about
regulatory information.
Signed-Off-By: Larry Finger [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.h
b/drivers/net/wireless/bcm43xx/bcm43xx_main.h
index 30a202b..1164936 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.h
@@ -112,30 +112,6 @@ int bcm43xx_channel_to_freq(struct bcm43
return bcm43xx_channel_to_freq_bg(channel);
}
-/* Lightweight function to check if a channel number is valid.
- * Note that this does _NOT_ check for geographical restrictions!
- */
-static inline
-int bcm43xx_is_valid_channel_a(u8 channel)
-{
- return (channel = IEEE80211_52GHZ_MIN_CHANNEL
- channel = IEEE80211_52GHZ_MAX_CHANNEL);
-}
-static inline
-int bcm43xx_is_valid_channel_bg(u8 channel)
-{
- return (channel = IEEE80211_24GHZ_MIN_CHANNEL
- channel = IEEE80211_24GHZ_MAX_CHANNEL);
-}
-static inline
-int bcm43xx_is_valid_channel(struct bcm43xx_private *bcm,
- u8 channel)
-{
- if (bcm43xx_current_phy(bcm)-type == BCM43xx_PHYTYPE_A)
- return bcm43xx_is_valid_channel_a(channel);
- return bcm43xx_is_valid_channel_bg(channel);
-}
-
void bcm43xx_tsf_read(struct bcm43xx_private *bcm, u64 *tsf);
void bcm43xx_tsf_write(struct bcm43xx_private *bcm, u64 tsf);
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
b/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
index af5c0bf..3900753 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
@@ -1594,11 +1594,11 @@ int bcm43xx_radio_selectchannel(struct b
u16 r8, tmp;
u16 freq;
- if ((radio-manufact == 0x17F)
+ if (!ieee80211_is_valid_channel(bcm-ieee, channel))
+ return -EINVAL;
+ if ((radio-manufact == 0x17F)
(radio-version == 0x2060)
(radio-revision == 1)) {
- if (channel 200)
- return -EINVAL;
freq = channel2freq_a(channel);
r8 = bcm43xx_radio_read16(bcm, 0x0008);
@@ -1651,9 +1651,6 @@ int bcm43xx_radio_selectchannel(struct b
TODO(); //TODO: TSSI2dbm workaround
bcm43xx_phy_xmitpower(bcm);//FIXME correct?
} else {
- if ((channel 1) || (channel 14))
- return -EINVAL;
-
if (synthetic_pu_workaround)
bcm43xx_synth_pu_workaround(bcm, channel);
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index c35cb3a..5c36e29 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -119,7 +119,7 @@ static int bcm43xx_wx_set_channelfreq(st
channel = bcm43xx_freq_to_channel(bcm, data-freq.m);
freq = data-freq.m;
}
- if (!bcm43xx_is_valid_channel(bcm, channel))
+ if (!ieee80211_is_valid_channel(bcm-ieee, channel))
goto out_unlock;
if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED) {
//ieee80211softmac_disassoc(softmac, $REASON);
-
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] cirrus ep93xx ethernet driver
The cirrus ep93xx is an ARM SoC that includes an ethernet MAC --
this patch adds a driver for that ethernet MAC.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
(This is, unfortunately, probably too late for 2.6.18, so I'm sending
it just for feedback.)
Index: linux-2.6.17-git5/drivers/net/arm/Kconfig
===
--- linux-2.6.17-git5.orig/drivers/net/arm/Kconfig
+++ linux-2.6.17-git5/drivers/net/arm/Kconfig
@@ -39,3 +39,10 @@ config ARM_AT91_ETHER
help
If you wish to compile a kernel for the AT91RM9200 and enable
ethernet support, then you should always answer Y to this.
+
+config EP93XX_ETH
+ tristate EP93xx Ethernet support
+ depends on NET_ETHERNET ARM ARCH_EP93XX
+ help
+ This is a driver for the ethernet hardware included in EP93xx CPUs.
+ Say Y if you are building a kernel for EP93xx based devices.
Index: linux-2.6.17-git5/drivers/net/arm/Makefile
===
--- linux-2.6.17-git5.orig/drivers/net/arm/Makefile
+++ linux-2.6.17-git5/drivers/net/arm/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_ARM_ETHERH)+= etherh.o
obj-$(CONFIG_ARM_ETHER3) += ether3.o
obj-$(CONFIG_ARM_ETHER1) += ether1.o
obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
+obj-$(CONFIG_EP93XX_ETH) += ep93xx_eth.o
Index: linux-2.6.17-git5/drivers/net/arm/ep93xx_eth.c
===
--- /dev/null
+++ linux-2.6.17-git5/drivers/net/arm/ep93xx_eth.c
@@ -0,0 +1,672 @@
+/*
+ * EP93xx ethernet network device driver
+ * Copyright (C) 2006 Lennert Buytenhek [EMAIL PROTECTED]
+ * Dedicated to Marija Kulikova.
+ *
+ * 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/dma-mapping.h
+#include linux/module.h
+#include linux/kernel.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/init.h
+#include linux/moduleparam.h
+#include linux/platform_device.h
+#include asm/arch/ep93xx-regs.h
+#include asm/arch/platform.h
+#include asm/io.h
+#include ep93xx_eth.h
+
+#define DRV_MODULE_VERSION 0.1
+
+#define RX_QUEUE_ENTRIES 64
+#define TX_QUEUE_ENTRIES 8
+
+struct ep93xx_descs
+{
+ struct ep93xx_rdesc rdesc[RX_QUEUE_ENTRIES];
+ struct ep93xx_tdesc tdesc[TX_QUEUE_ENTRIES];
+ struct ep93xx_rstat rstat[RX_QUEUE_ENTRIES];
+ struct ep93xx_tstat tstat[TX_QUEUE_ENTRIES];
+};
+
+struct ep93xx_priv
+{
+ struct resource *res;
+ void*base_addr;
+ int irq;
+
+ struct ep93xx_descs *descs;
+ dma_addr_t descs_dma_addr;
+
+ void*rx_buf[RX_QUEUE_ENTRIES];
+ void*tx_buf[TX_QUEUE_ENTRIES];
+
+ int rx_pointer;
+ int tx_clean_pointer;
+ int tx_pointer;
+ int tx_pending;
+
+ struct net_device_stats stats;
+};
+
+#define rdb(ep, off) __raw_readb((ep)-base_addr + (off))
+#define rdw(ep, off) __raw_readw((ep)-base_addr + (off))
+#define rdl(ep, off) __raw_readl((ep)-base_addr + (off))
+#define wrb(ep, off, val) __raw_writeb((val), (ep)-base_addr + (off))
+#define wrw(ep, off, val) __raw_writew((val), (ep)-base_addr + (off))
+#define wrl(ep, off, val) __raw_writel((val), (ep)-base_addr + (off))
+
+static int ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+ int entry;
+
+ if (unlikely(skb-len) PAGE_SIZE) {
+ ep-stats.tx_dropped++;
+ dev_kfree_skb(skb);
+ return 0;
+ }
+
+ entry = ep-tx_pointer;
+ ep-tx_pointer = (ep-tx_pointer + 1) % TX_QUEUE_ENTRIES;
+
+ ep-descs-tdesc[entry].tdesc1 =
+ TDESC1_EOF | (entry 16) | (skb-len 0xfff);
+ skb_copy_and_csum_dev(skb, ep-tx_buf[entry]);
+ dma_sync_single(NULL, ep-descs-tdesc[entry].buf_addr,
+ skb-len, DMA_TO_DEVICE);
+ dev_kfree_skb(skb);
+
+ dev-trans_start = jiffies;
+
+ local_irq_disable();
+ ep-tx_pending++;
+ if (ep-tx_pending == TX_QUEUE_ENTRIES)
+ netif_stop_queue(dev);
+ local_irq_enable();
+
+ wrl(ep, 0x00bc, 1);
+
+ return 0;
+}
+
+static int ep93xx_rx(struct net_device *dev, int *budget)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+ int tail_offset;
+ int rx_done;
+ int processed;
+
+ tail_offset = rdl(ep, 0x00a8) - ep-descs_dma_addr;
+
+ rx_done = 0;
+
Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
On Sun, 25 Jun 2006, Harry Edmon wrote: I understand the saying beggars can't be choosers, but I have heard nothing on this issue since June 19th. Does anyone have any ideas on what is going on? Is there more information I can collect that would help diagnose this problem? And again, thanks for any and all help! Harry, I'd suggest checking all the ethtool configuration settings (ethtool -a, -c, -g, -k) and statistics (ethtool -S) for both the working and problematic kernels, and then comparing them to see if anything jumps out at you. Also compare ifconfig settings and dmesg output. Check /proc/interrupts to see if there is any difference with the interrupt routing. Check sysctl.conf and rc.local for any special system configuration or device settings that might differ between the systems. The one thing that has caused me a lot of network performance issues on e1000 is having TSO enabled, so if that is enabled (check with ethtool -k), then I'd try disabling it to see if that helps. -Hope this helps -Bill - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
On 25/06/2006 12:13 AM, jamal wrote: You can actually stop reading here if you have gathered the view at this point that i am not objecting to the simple approach Patrick is going with... Perhaps this is my problem. I am not sure I understand what Patrick is proposing. I can wait for his patch, I guess. Indeed and i referred to it in the exchanges. And yes, I was arguing that the tc scheme you describe would not be so bad either if the cost of making a generic change is expensive. OK. I take it from this you think there is merit in the idea of adding code so the kernel can calculate the ATM link speeds correctly. The discussion is really about the best way to go about it? If so, excellent. I am not really too fussy about how it is achieved, I just want my VOIP connections to work well on stock kernels. There are a lot of link layer issues that you may end up knowing of (other than the ATM fragmentation overhead) in regards to something downstream and you keep adding knobs is just adding more bloat. Example: If that 3rd hop was wireless that happened to be doing CDMA RLP with a lot of retransmits, or wireless that varied its throughput from 1-3Mbps at any point in time or it was a satellite link that had a lot of latency etc etc. You could always have some way to tweak these via the kernel. In-fact people have written schedulers specifically for these sorts of link layer problems (I think even some of the IEEE 802.11 or wimax folks have standardized specific schedulers). You basically have to draw a line somewhere. My line was can it be done via user space? yes - do it there. If you mean by adding lots of knobs, you mean we need a knob for 802.11, a knob for ATM, a knob for ethernet and so on, then we do need lots of knobs. And you need to know which of those layers is the bottle neck, so you know what knob to fit. But you only ever need one knob on a given link. I can only think of two ways out of needing lots of knobs. One is to have a qdisc that doesn't need to know the link speed in order to shape traffic to it gets to the scheduling and not someone upstream. Sounds like black magic to me, but perhaps HFSC does this - I have not read the papers yet, but I plan to do so soon. The second way is to automatically calculate the link speed, using a daemon perhaps :). Again it sounds like black magic. Note that there is already code in the kernel that does this, but it lives in the layers above - in TCP and DCCP. I am referring to Westwood, and friends. These algorithms live in the layers above because the need feed back from the network - which can only come from the other end of connection unless ECN is working. I have not been able to figure out how Patrick intends to solve these problems from his posts so far, so I am waiting for his code. Hopefully it will include a lot of comments. Patrick seems to have a simple way to compensate generically for link layer fragmentation, so i will not argue the practically; hopefully that settles it? ;- Yes, it does. It will be interesting to see what Patrick comes up with. - 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: Network performance degradation from 2.6.11.12 to 2.6.16.20
I encountered the same problem on a dual core opteron equipped with a broadcom NIC (tg3) under 2.4. It could receive 1 Mpps when using TSC as the clock source, but the time jumped back and forth, so I changed it to 'notsc', then the performance dropped dramatically to around the same value as above with one CPU saturated. I suspect that the clock precision is needed by the tg3 driver to correctly decide to switch to polling mode, but unfortunately, the performance drop rendered the solution so much unusable that I finally decided to use it only in uniprocessor with TSC enabled. 2.6 is more clever at this than 2.4. In particular it does the timestamp for each packet only when actually needed, which is relativelt rare. Old experiences do not always apply to new kernels. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
