[git patches] net driver fixes
Minor stuff except for the xen-netfront fix. e1000 change is an
adds-pci-ids-only change.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
MAINTAINERS |6 ++
drivers/net/3c59x.c |1 +
drivers/net/ax88796.c |5 +++--
drivers/net/e1000/e1000_ethtool.c |2 ++
drivers/net/e1000/e1000_hw.c |5 +
drivers/net/e1000/e1000_hw.h |3 +++
drivers/net/e1000/e1000_main.c|4
drivers/net/myri10ge/myri10ge.c | 25 ++---
drivers/net/natsemi.c |3 +++
drivers/net/via-rhine.c |6 ++
drivers/net/xen-netfront.c|7 ---
11 files changed, 55 insertions(+), 12 deletions(-)
Andrew Morton (2):
ax88796 printk fixes
natsemi: fix netdev error acounting
Auke Kok (1):
e1000: Add device IDs of new 82571 board variants
Brice Goglin (1):
myri10ge: Use the pause counter to avoid a needless device reset
Dustin Marquess (1):
via-rhine: disable rx_copybreak on archs that don't allow unaligned DMA
access
Jeremy Fitzhardinge (1):
xen-netfront: Avoid deref'ing skbafter it is potentially freed.
Steffen Klassert (2):
3c59x: fix duplex configuration
3c59x maintainer
diff --git a/MAINTAINERS b/MAINTAINERS
index d3a0684..e4dde7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -97,6 +97,12 @@ M: [EMAIL PROTECTED]
L: netdev@vger.kernel.org
S: Maintained
+3C59X NETWORK DRIVER
+P: Steffen Klassert
+M: [EMAIL PROTECTED]
+L: netdev@vger.kernel.org
+S: Maintained
+
3CR990 NETWORK DRIVER
P: David Dillow
M: [EMAIL PROTECTED]
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 001c66d..a8c0f43 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -1555,6 +1555,7 @@ vortex_up(struct net_device *dev)
mii_reg1 = mdio_read(dev, vp-phys[0], MII_BMSR);
mii_reg5 = mdio_read(dev, vp-phys[0], MII_LPA);
vp-partner_flow_ctrl = ((mii_reg5 0x0400) != 0);
+ vp-mii.full_duplex = vp-full_duplex;
vortex_check_media(dev, 1);
}
diff --git a/drivers/net/ax88796.c b/drivers/net/ax88796.c
index 83da177..90e0734 100644
--- a/drivers/net/ax88796.c
+++ b/drivers/net/ax88796.c
@@ -821,8 +821,9 @@ static int ax_probe(struct platform_device *pdev)
dev-base_addr = (unsigned long)ei_status.mem;
if (ei_status.mem == NULL) {
- dev_err(pdev-dev, Cannot ioremap area (%08zx,%08zx)\n,
- res-start, res-end);
+ dev_err(pdev-dev, Cannot ioremap area (%08llx,%08llx)\n,
+ (unsigned long long)res-start,
+ (unsigned long long)res-end);
ret = -ENXIO;
goto exit_req;
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index c90c92e..4c3785c 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -1706,6 +1706,7 @@ static int e1000_wol_exclusion(struct e1000_adapter
*adapter, struct ethtool_wol
case E1000_DEV_ID_82545EM_COPPER:
case E1000_DEV_ID_82546GB_QUAD_COPPER:
case E1000_DEV_ID_82546GB_PCIE:
+ case E1000_DEV_ID_82571EB_SERDES_QUAD:
/* these don't support WoL at all */
wol-supported = 0;
break;
@@ -1723,6 +1724,7 @@ static int e1000_wol_exclusion(struct e1000_adapter
*adapter, struct ethtool_wol
retval = 0;
break;
case E1000_DEV_ID_82571EB_QUAD_COPPER:
+ case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
case E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3:
/* quad port adapters only support WoL on port A */
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index 9be4469..ba120f7 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -384,7 +384,10 @@ e1000_set_mac_type(struct e1000_hw *hw)
case E1000_DEV_ID_82571EB_COPPER:
case E1000_DEV_ID_82571EB_FIBER:
case E1000_DEV_ID_82571EB_SERDES:
+ case E1000_DEV_ID_82571EB_SERDES_DUAL:
+ case E1000_DEV_ID_82571EB_SERDES_QUAD:
case E1000_DEV_ID_82571EB_QUAD_COPPER:
+ case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
hw-mac_type = e1000_82571;
break;
@@ -485,6 +488,8 @@ e1000_set_media_type(struct e1000_hw *hw)
case E1000_DEV_ID_82545GM_SERDES:
case E1000_DEV_ID_82546GB_SERDES:
case E1000_DEV_ID_82571EB_SERDES:
+case E1000_DEV_ID_82571EB_SERDES_DUAL:
+case E1000_DEV_ID_82571EB_SERDES_QUAD:
case E1000_DEV_ID_82572EI_SERDES:
case E1000_DEV_ID_80003ES2LAN_SERDES_DPT:
Re: [patch]support for USB autosuspend in the asix driver
On Monday 13 August 2007, Jeff Garzik wrote: Oliver Neukum wrote: Hi, this implements support for USB autosuspend in the asix USB ethernet driver. Regards Oliver Signed-off-by: Oliver Neukum [EMAIL PROTECTED] David, does this look OK to you? I never saw much comment from anybody, and cannot really comment on the USB parts. I didn't see anything obviously wrong. I presume Oliver tested this with actual ASIX hardware ... assuming that, it's OK by me. - Dave 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]support for USB autosuspend in the asix driver
Am Dienstag 14 August 2007 schrieb David Brownell: On Monday 13 August 2007, Jeff Garzik wrote: Oliver Neukum wrote: Hi, this implements support for USB autosuspend in the asix USB ethernet driver. Regards Oliver Signed-off-by: Oliver Neukum [EMAIL PROTECTED] David, does this look OK to you? I never saw much comment from anybody, and cannot really comment on the USB parts. I didn't see anything obviously wrong. I presume Oliver tested this with actual ASIX hardware ... assuming that, it's OK by me. I've tested it. It works. Regards Oliver - 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 6/24] make atomic_read() behave consistently on frv
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
What do you think of this crazy idea?
/* Enforce a compiler barrier for only operations to location X.
* Call multiple times to provide an ordering between multiple
* memory locations. Other memory operations can be assumed by
* the compiler to remain unchanged and may be reordered
*/
#define order(x) asm volatile( : +m (x))
Yes this is a very good idea. This also makes it explicit
that the coder is depending on this rather than the more
vague connotations of atomic_read.
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: Block device throttling [Re: Distributed storage.]
On Mon, Aug 13, 2007 at 06:04:06AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: Perhaps you never worried about the resources that the device mapper mapping function allocates to handle each bio and so did not consider this hole significant. These resources can be significant, as is the case with ddsnap. It is essential to close that window through with the virtual device's queue limit may be violated. Not doing so will allow deadlock. This is not a bug, this is special kind of calculation - total limit is number of physical devices multiplied by theirs limits. It was done _on purpose_ to allow different device to have different limits (for example in distributed storage project it is possible to have both remote and local node in the same device, but local device should not have _any_ limit at all, but network one should). Virtual device essentially has _no_ limit. And that as done on purpose. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9 Rev3] Implement batching skb API and support in IPoIB
Hi Dave, David Miller [EMAIL PROTECTED] wrote on 08/08/2007 04:19:00 PM: From: Krishna Kumar [EMAIL PROTECTED] Date: Wed, 08 Aug 2007 15:01:14 +0530 RESULTS: The performance improvement for TCP No Delay is in the range of -8% to 320% (with -8% being the sole negative), with many individual tests giving 50% or more improvement (I think it is to do with the hw slots getting full quicker resulting in more batching when the queue gets woken). The results for TCP is in the range of -11% to 93%, with most of the tests (8/12) giving improvements. Not because I think it obviates your work, but rather because I'm curious, could you test a TSO-in-hardware driver converted to batching and see how TSO alone compares to batching for a pure TCP workload? I personally don't think it will help for that case at all as TSO likely does better job of coalescing the work _and_ reducing bus traffic as well as work in the TCP stack. I used E1000 (guess the choice is OK as e1000_tso returns TRUE. My hw is 82547GI). You are right, it doesn't help TSO case at all (infact degrades). Two things to note though: - E1000 may not be suitable for adding batching (which is no longer a new API, as I have changed it already). - Small skbs where TSO doesn't come into picture still seems to improve. A couple of cases for large skbs did result in some improved (like 4K, TCP No Delay, 32 procs). [Total segments retransmission for original code test run: 2220 for new code test run: 1620. So the retransmission problem that I was getting seems to be an IPoIB bug, though I did have to fix one bug in my networking component where I was calling qdisc_run(NULL) for regular xmit path and change to always use batching. The problem is that skb1 - skb10 may be present in the queue after each of them failed to be sent out, then net_tx_action fires which batches all of these into the blist and tries to send them out again, which also fails (eg tx lock fail or queue full), then the next single skb xmit will send the latest skb ignoring the 10 skbs that are already waiting in the batching list. These 10 skbs are sent out only the next time net_tx_action is called, so out of order skbs result. This fix reduced retransmissions from 180,000 to 55,000 or so. When I changed IPoIB driver to use iterative sends of each skb instead of creating multiple Work Request's, that number went down to 15]. I ran 3 iterations of 45 sec tests (total 1 hour 16 min, but I will run a longer one tonight). The results are (results in KB/s, and %): Test Case Org BW New BW % Change TCP Size:32 Procs:1 18483918112.01 Size:32 Procs:8 21888 21555 -1.52 Size:32 Procs:3219317 22433 16.13 Size:256 Procs:115584 25991 66.78 Size:256 Procs:8110937 74565 -32.78 Size:256 Procs:32 105767 98967 -6.42 Size:4096 Procs:1 81910 96073 17.29 Size:4096 Procs:8 113302 94040 -17.00 Size:4096 Procs:32 109664 105522 -3.77 TCP No Delay: -- Size:32 Procs:1 2688317718.19 Size:32 Procs:8 656810588 61.20 Size:32 Procs:326573783819.24 Size:256 Procs:1786912724 61.69 Size:256 Procs:865652 45652 -30.46 Size:256 Procs:32 95114 112279 18.04 Size:4096 Procs:1 95302 84664 -11.16 Size:4096 Procs:8 19 89111 -19.80 Size:4096 Procs:32 109249 113919 4.27 I will submit Rev4 with suggested changes (including single merged API) on Thursday after some more testing. Thanks, - KK - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.4.35-pre1: new e1000 driver breaks old hardware
Kok, Auke wrote: Wolfgang Nothdurft wrote: Hi, with the new e1000 driver version 7.3.20 the onboard gigabit nic 82547EI (8086:1019) doesn't work correctly. After transferring about 100 megabytes over a gigabit link the transfer stopped and I have to reinit the link either by doing a ifconfig down/up or unplugging the network cable. The RxIntDelay is set to 0 like described in the docu. Playing with this Parameter only increases the amount of traffic to be send and the error occurs later. have you tried (the default) 8000 ? Do you get the same problem when you run 2.6.21 with 7.5.5.1 or 7.3.20 ? This happens also with the 7.4.35 and 7.5.5 driver from the intel side. The driver 5.7.6 from kernel 2.4.33.3 and the 6.1.16 from intel works very well on this hardware. Also other gigabit nics we use didn't have this problem. Is this issue already known? this is the first time I have heard this issue. Is there any solution yet? I'm not that good :) Can you file a bugreport on e1000.sf.net and attach the usual (ethtool -e, dmesg, ifconfig -a, lspci -vv) debugging output and problem description for us? I'll try to see if I can have our labs setup a repro case, which might be hard given the adapter type, but we will do our best. Auke - 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 Any news about this issue? The bug report is http://sourceforge.net/tracker/index.php?func=detailaid=1739537group_id=42302atid=447449 Kind Regards Wolfgang -- Wolfgang Nothdurft [EMAIL PROTECTED] Linogate Internet Technologies fon: +49 (0)821 - 25 96 - 0 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9 Rev3] Implement batching skb API and support in IPoIB
Forgot to mention one thing: This fix reduced retransmissions from 180,000 to 55,000 or so. When I changed IPoIB driver to use iterative sends of each skb instead of creating multiple Work Request's, that number went down to 15]. This also reduced TCP No Delay performance from huge percentages like 200-400% and now is almost the same as original code. So fixing this problem in IPoIB (driver?) will enable to use the multiple Work Request Work Completion, rather than limiting batching to single WR/WC. thanks, - KK __ Hi Dave, David Miller [EMAIL PROTECTED] wrote on 08/08/2007 04:19:00 PM: From: Krishna Kumar [EMAIL PROTECTED] Date: Wed, 08 Aug 2007 15:01:14 +0530 RESULTS: The performance improvement for TCP No Delay is in the range of -8% to 320% (with -8% being the sole negative), with many individual tests giving 50% or more improvement (I think it is to do with the hw slots getting full quicker resulting in more batching when the queue gets woken). The results for TCP is in the range of -11% to 93%, with most of the tests (8/12) giving improvements. Not because I think it obviates your work, but rather because I'm curious, could you test a TSO-in-hardware driver converted to batching and see how TSO alone compares to batching for a pure TCP workload? I personally don't think it will help for that case at all as TSO likely does better job of coalescing the work _and_ reducing bus traffic as well as work in the TCP stack. I used E1000 (guess the choice is OK as e1000_tso returns TRUE. My hw is 82547GI). You are right, it doesn't help TSO case at all (infact degrades). Two things to note though: - E1000 may not be suitable for adding batching (which is no longer a new API, as I have changed it already). - Small skbs where TSO doesn't come into picture still seems to improve. A couple of cases for large skbs did result in some improved (like 4K, TCP No Delay, 32 procs). [Total segments retransmission for original code test run: 2220 for new code test run: 1620. So the retransmission problem that I was getting seems to be an IPoIB bug, though I did have to fix one bug in my networking component where I was calling qdisc_run(NULL) for regular xmit path and change to always use batching. The problem is that skb1 - skb10 may be present in the queue after each of them failed to be sent out, then net_tx_action fires which batches all of these into the blist and tries to send them out again, which also fails (eg tx lock fail or queue full), then the next single skb xmit will send the latest skb ignoring the 10 skbs that are already waiting in the batching list. These 10 skbs are sent out only the next time net_tx_action is called, so out of order skbs result. This fix reduced retransmissions from 180,000 to 55,000 or so. When I changed IPoIB driver to use iterative sends of each skb instead of creating multiple Work Request's, that number went down to 15]. I ran 3 iterations of 45 sec tests (total 1 hour 16 min, but I will run a longer one tonight). The results are (results in KB/s, and %): Test Case Org BW New BW % Change TCP Size:32 Procs:1 18483918112.01 Size:32 Procs:8 21888 21555 -1.52 Size:32 Procs:3219317 22433 16.13 Size:256 Procs:115584 25991 66.78 Size:256 Procs:8110937 74565 -32.78 Size:256 Procs:32 105767 98967 -6.42 Size:4096 Procs:1 81910 96073 17.29 Size:4096 Procs:8 113302 94040 -17.00 Size:4096 Procs:32 109664 105522 -3.77 TCP No Delay: -- Size:32 Procs:1 2688317718.19 Size:32 Procs:8 656810588 61.20 Size:32 Procs:326573783819.24 Size:256 Procs:1786912724 61.69 Size:256 Procs:865652 45652 -30.46 Size:256 Procs:32 95114 112279 18.04 Size:4096 Procs:1 95302 84664 -11.16 Size:4096 Procs:8 19 89111 -19.80 Size:4096 Procs:32 109249 113919 4.27 I will submit Rev4 with suggested changes (including single merged API) on Thursday after some more testing. Thanks, - KK - 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 - 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 08/18] 3c59x: check return of pci_enable_device()
On Tue, Aug 14, 2007 at 01:33:26AM -0400, Jeff Garzik wrote:
I would strongly prefer that vortex_up return a value, since all the
important callers of this function can themselves return an error back
to the system.
we can definitely return a meaningful return value here, if
pci_enable_device() fails, and I would rather not apply a patch that
fails to propagate a serious condition (pci_enable_device failure is
indeed serious) when it is possible to do so
OK. Any comments on this revised version? I have only ignored the return of
vortex_up in vortex_error. It is not immediately clear what to do if
vortex_up still fails there after a pci reset.
Mark
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 001c66d..a1dfd6b 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -705,7 +705,7 @@ static struct {
static int vortex_probe1(struct device *gendev, void __iomem *ioaddr, int irq,
int chip_idx, int card_idx);
-static void vortex_up(struct net_device *dev);
+static int vortex_up(struct net_device *dev);
static void vortex_down(struct net_device *dev, int final);
static int vortex_open(struct net_device *dev);
static void mdio_sync(void __iomem *ioaddr, int bits);
@@ -841,8 +841,11 @@ static int vortex_resume(struct pci_dev *pdev)
return -EBUSY;
}
if (netif_running(dev)) {
- vortex_up(dev);
- netif_device_attach(dev);
+ err = vortex_up(dev);
+ if (err)
+ return err;
+ else
+ netif_device_attach(dev);
}
}
return 0;
@@ -1484,19 +1487,24 @@ static void vortex_check_media(struct net_device *dev,
unsigned int init)
}
}
-static void
+static int
vortex_up(struct net_device *dev)
{
struct vortex_private *vp = netdev_priv(dev);
void __iomem *ioaddr = vp-ioaddr;
unsigned int config;
- int i, mii_reg1, mii_reg5;
+ int i, mii_reg1, mii_reg5, err;
if (VORTEX_PCI(vp)) {
pci_set_power_state(VORTEX_PCI(vp), PCI_D0);/* Go active */
if (vp-pm_state_valid)
pci_restore_state(VORTEX_PCI(vp));
- pci_enable_device(VORTEX_PCI(vp));
+ err = pci_enable_device(VORTEX_PCI(vp));
+ if (err) {
+ printk(KERN_WARNING %s: Could not enable device \n,
+ dev-name);
+ goto err_out;
+ }
}
/* Before initializing select the active media port. */
@@ -1660,6 +1668,8 @@ vortex_up(struct net_device *dev)
if (vp-cb_fn_base) /* The PCMCIA people are
idiots. */
iowrite32(0x8000, vp-cb_fn_base + 4);
netif_start_queue (dev);
+err_out:
+ return err;
}
static int
@@ -1673,7 +1683,7 @@ vortex_open(struct net_device *dev)
if ((retval = request_irq(dev-irq, vp-full_bus_master_rx ?
boomerang_interrupt : vortex_interrupt,
IRQF_SHARED, dev-name, dev))) {
printk(KERN_ERR %s: Could not reserve IRQ %d\n, dev-name,
dev-irq);
- goto out;
+ goto err;
}
if (vp-full_bus_master_rx) { /* Boomerang bus master. */
@@ -1702,20 +1712,22 @@ vortex_open(struct net_device *dev)
}
}
retval = -ENOMEM;
- goto out_free_irq;
+ goto err_free_irq;
}
/* Wrap the ring. */
vp-rx_ring[i-1].next = cpu_to_le32(vp-rx_ring_dma);
}
- vortex_up(dev);
- return 0;
+ retval = vortex_up(dev);
+ if (!retval)
+ goto out;
-out_free_irq:
+err_free_irq:
free_irq(dev-irq, dev);
-out:
+err:
if (vortex_debug 1)
printk(KERN_ERR %s: vortex_open() fails: returning %d\n,
dev-name, retval);
+out:
return retval;
}
-
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: dm9000: add set_mac_address()
On Sun, Aug 12, 2007 at 07:08:52PM -0400, Jeff Garzik wrote: set_mac_address should not write to the SROM, as Michael noted. The proper operations are: probe time: read MAC address from SROM dev open (interface up): write dev-dev_addr[] to RX filter (or identity) registers EEPROM update support is available separately, via an ethtool sub-ioctl. This sounds sensible, I am working on adding ethtool support and should have a patch available in the next day or so. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - 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: Davicom Ethernet (onboard) with many Tx timeouts...
On Wed, Jan 03, 2007 at 10:33:08PM -0200, D?niel Fraga wrote: Linux 2.6.19 (but this problem occurs with previous kernels too) gcc 4.1.1 pentium 3 Module dmfe.ko dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17) hmm, dmfe does not cover the dm9000, a little missleading? -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' - 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: Block device throttling [Re: Distributed storage.]
On Tuesday 14 August 2007 01:46, Evgeniy Polyakov wrote: On Mon, Aug 13, 2007 at 06:04:06AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: Perhaps you never worried about the resources that the device mapper mapping function allocates to handle each bio and so did not consider this hole significant. These resources can be significant, as is the case with ddsnap. It is essential to close that window through with the virtual device's queue limit may be violated. Not doing so will allow deadlock. This is not a bug, this is special kind of calculation - total limit is number of physical devices multiplied by theirs limits. It was done _on purpose_ to allow different device to have different limits (for example in distributed storage project it is possible to have both remote and local node in the same device, but local device should not have _any_ limit at all, but network one should). Virtual device essentially has _no_ limit. And that as done on purpose. And it will not solve the deadlock problem in general. (Maybe it works for your virtual device, but I wonder...) If the virtual device allocates memory during generic_make_request then the memory needs to be throttled. Regards, Daniel - 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] [DM9000] External PHY support
This patch adds a flag to the DM9000 platform data which, when set,
configures the device to use an external PHY.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
drivers/net/dm9000.c |6 ++
include/linux/dm9000.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index ee578d9..820f0d3 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -124,6 +124,7 @@ typedef struct board_info {
u16 dbug_cnt;
u8 io_mode; /* 0:word, 2:byte */
u8 phy_addr;
+ unsigned int flags;
void (*inblk)(void __iomem *port, void *data, int length);
void (*outblk)(void __iomem *port, void *data, int length);
@@ -513,6 +514,8 @@ dm9000_probe(struct platform_device *pdev)
if (pdata-dumpblk != NULL)
db-dumpblk = pdata-dumpblk;
+
+ db-flags = pdata-flags;
}
dm9000_reset(db);
@@ -655,6 +658,9 @@ dm9000_init_dm9000(struct net_device *dev)
iow(db, DM9000_GPCR, GPCR_GEP_CNTL);/* Let GPIO0 output */
iow(db, DM9000_GPR, 0); /* Enable PHY */
+ if (db-flags DM9000_PLATF_EXT_PHY)
+ iow(db, DM9000_NCR, NCR_EXT_PHY);
+
/* Program operating register */
iow(db, DM9000_TCR, 0); /* TX Polling clear */
iow(db, DM9000_BPTR, 0x3f); /* Less 3Kb, 200us */
diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
index 0008e2a..ea530fd 100644
--- a/include/linux/dm9000.h
+++ b/include/linux/dm9000.h
@@ -19,6 +19,7 @@
#define DM9000_PLATF_8BITONLY (0x0001)
#define DM9000_PLATF_16BITONLY (0x0002)
#define DM9000_PLATF_32BITONLY (0x0004)
+#define DM9000_PLATF_EXT_PHY (0x0008)
/* platfrom data for platfrom device structure's platfrom_data field */
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
-
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: Block device throttling [Re: Distributed storage.]
On Tue, Aug 14, 2007 at 04:13:10AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: On Tuesday 14 August 2007 01:46, Evgeniy Polyakov wrote: On Mon, Aug 13, 2007 at 06:04:06AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: Perhaps you never worried about the resources that the device mapper mapping function allocates to handle each bio and so did not consider this hole significant. These resources can be significant, as is the case with ddsnap. It is essential to close that window through with the virtual device's queue limit may be violated. Not doing so will allow deadlock. This is not a bug, this is special kind of calculation - total limit is number of physical devices multiplied by theirs limits. It was done _on purpose_ to allow different device to have different limits (for example in distributed storage project it is possible to have both remote and local node in the same device, but local device should not have _any_ limit at all, but network one should). Virtual device essentially has _no_ limit. And that as done on purpose. And it will not solve the deadlock problem in general. (Maybe it works for your virtual device, but I wonder...) If the virtual device allocates memory during generic_make_request then the memory needs to be throttled. Daniel, if device process bio by itself, it has a limit and thus it will wait in generic_make_request(), if it queues it to different device, then the same logic applies there. If virutal device does not process bio, its limit will always be recharged to underlying devices, and overall limit is equal to number of physical device (or devices which do process bio) multiplied by theirs limits. This does _work_ and I showed example how limits are processed and who and where will sleep. This solution is not narrow fix, please check my examples I showed before. Regards, Daniel -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Block device throttling [Re: Distributed storage.]
On Tuesday 14 August 2007 04:30, Evgeniy Polyakov wrote: And it will not solve the deadlock problem in general. (Maybe it works for your virtual device, but I wonder...) If the virtual device allocates memory during generic_make_request then the memory needs to be throttled. Daniel, if device process bio by itself, it has a limit and thus it will wait in generic_make_request() What will make it wait? - 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: Block device throttling [Re: Distributed storage.]
On Tue, Aug 14, 2007 at 04:35:43AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: On Tuesday 14 August 2007 04:30, Evgeniy Polyakov wrote: And it will not solve the deadlock problem in general. (Maybe it works for your virtual device, but I wonder...) If the virtual device allocates memory during generic_make_request then the memory needs to be throttled. Daniel, if device process bio by itself, it has a limit and thus it will wait in generic_make_request() What will make it wait? gneric_make_request() for given block device. Example: virt_device - do_smth_with_bio -bio_endio(). | / \ phys0 phys1 Each of three devices above works with bio, each one eventually calls bio_endio() and bio-bi_bdev will be one of the three above devices. Thus, when system calls generic_make_request(bio-bi_bdev == virt_device), one of the three limits will be charged, depending on the fact, that virtual device forward bio to physical devices or not. Actually virtual device limit will be charged too first, but if bio is forwarded, its portion will be reduced from virtual device's limit. Now, if virtual device allocates bio itself (like device mapper), then this new bio will be forwarded to physical devices via gneric_make_request() and thus it will sleep in the physical device's queue, if it is filled. So, if each of three devices has a limit of 10 bios, then actual number of bios in flight is maximum 3 * 10, since each device will be charged up to _its_ maximum limit, not limit for the first device in the chain. So, you set 10 to virtual device and its can process bio itself (like send it to network), then this is number of bios in flight, which are processed by _this_ device and not forwarded further. Actual number of bios you can flush into virtual device is its own limit plus limits of all physical devices atached to it. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [DM9000] Add support for big-endian hosts
This patch splits the receive status in 8bit wide fields and convert the
packet length from little endian to CPU byte order.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
drivers/net/dm9000.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 264fa0e..ee578d9 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -879,7 +879,8 @@ dm9000_timer(unsigned long data)
}
struct dm9000_rxhdr {
- u16 RxStatus;
+ u8 RxPktReady;
+ u8 RxStatus;
u16 RxLen;
} __attribute__((__packed__));
@@ -920,7 +921,7 @@ dm9000_rx(struct net_device *dev)
(db-inblk)(db-io_data, rxhdr, sizeof(rxhdr));
- RxLen = rxhdr.RxLen;
+ RxLen = le16_to_cpu(rxhdr.RxLen);
/* Packet Status check */
if (RxLen 0x40) {
@@ -932,17 +933,17 @@ dm9000_rx(struct net_device *dev)
PRINTK1(RST: RX Len:%x\n, RxLen);
}
- if (rxhdr.RxStatus 0xbf00) {
+ if (rxhdr.RxStatus 0xbf) {
GoodPacket = false;
- if (rxhdr.RxStatus 0x100) {
+ if (rxhdr.RxStatus 0x01) {
PRINTK1(fifo error\n);
db-stats.rx_fifo_errors++;
}
- if (rxhdr.RxStatus 0x200) {
+ if (rxhdr.RxStatus 0x02) {
PRINTK1(crc error\n);
db-stats.rx_crc_errors++;
}
- if (rxhdr.RxStatus 0x8000) {
+ if (rxhdr.RxStatus 0x80) {
PRINTK1(length error\n);
db-stats.rx_length_errors++;
}
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
-
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] netfilter : xt_u32 bug correction
Hi all This applies to net-2.6 (so should be forwared to Linus for 2.6.23 inclusion ?) Thank you [PATCH] netfilter : xt_u32 bug correction An extraneous ; makes xt_u32 match useless Signed-off-by: Eric Dumazet [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] netfilter : xt_u32 bug correction
Hi all This applies to net-2.6 (so should be forwared to Linus for 2.6.23 inclusion ?) Sorry for the first mail without attachment. Thank you [PATCH] netfilter : xt_u32 bug correction An extraneous ; makes xt_u32 match useless Signed-off-by: Eric Dumazet [EMAIL PROTECTED] diff --git a/net/netfilter/xt_u32.c b/net/netfilter/xt_u32.c index 04b677a..89b2d5c 100644 --- a/net/netfilter/xt_u32.c +++ b/net/netfilter/xt_u32.c @@ -35,7 +35,7 @@ static bool u32_match_it(const struct xt_u32 *data, at = 0; pos = ct-location[0].number; - if (skb-len 4 || pos skb-len - 4); + if (skb-len 4 || pos skb-len - 4) return false; ret = skb_copy_bits(skb, pos, val, sizeof(val)); - 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: Block device throttling [Re: Distributed storage.]
On Tuesday 14 August 2007 04:50, Evgeniy Polyakov wrote: On Tue, Aug 14, 2007 at 04:35:43AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: On Tuesday 14 August 2007 04:30, Evgeniy Polyakov wrote: And it will not solve the deadlock problem in general. (Maybe it works for your virtual device, but I wonder...) If the virtual device allocates memory during generic_make_request then the memory needs to be throttled. Daniel, if device process bio by itself, it has a limit and thus it will wait in generic_make_request() What will make it wait? gneric_make_request() for given block device. Not good enough, that only makes one thread wait. Look here: http://lkml.org/lkml/2007/8/13/788 An unlimited number of threads can come in, each consuming resources of the virtual device, and violating the throttling rules. The throttling of the virtual device must begin in generic_make_request and last to -endio. You release the throttle of the virtual device at the point you remap the bio to an underlying device, which you have convinced yourself is ok, but it is not. You seem to miss the fact that whatever resources the virtual device has allocated are no longer protected by the throttle count *of the virtual device*, or you do not see why that is a bad thing. It is a very bad thing, roughly like leaving some shared data outside a spin_lock/unlock. Regards, Daniel - 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: Block device throttling [Re: Distributed storage.]
On Tue, Aug 14, 2007 at 05:32:29AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: On Tuesday 14 August 2007 04:50, Evgeniy Polyakov wrote: On Tue, Aug 14, 2007 at 04:35:43AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: On Tuesday 14 August 2007 04:30, Evgeniy Polyakov wrote: And it will not solve the deadlock problem in general. (Maybe it works for your virtual device, but I wonder...) If the virtual device allocates memory during generic_make_request then the memory needs to be throttled. Daniel, if device process bio by itself, it has a limit and thus it will wait in generic_make_request() What will make it wait? gneric_make_request() for given block device. Not good enough, that only makes one thread wait. Look here: http://lkml.org/lkml/2007/8/13/788 An unlimited number of threads can come in, each consuming resources of the virtual device, and violating the throttling rules. The throttling of the virtual device must begin in generic_make_request and last to -endio. You release the throttle of the virtual device at the point you remap the bio to an underlying device, which you have convinced yourself is ok, but it is not. You seem to miss the fact that whatever resources the virtual device has allocated are no longer protected by the throttle count *of the virtual device*, or you do not Because it is charged to another device. No matter how many of them are chained, limit is applied to the last device being used. So, if you have unlimited number of threads, each one allocates a request, forward it down to low-level devices, each one will eventually sleep, but yes, each one _can_ allocate _one_ request before it goes sleeping. It is done to allow fain-grained limits, since some devices (like locally attached disks) do not require throttling. Here is an example with threads you mentioned: http://article.gmane.org/gmane.linux.file-systems/17644 -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Block device throttling [Re: Distributed storage.]
On Tuesday 14 August 2007 05:46, Evgeniy Polyakov wrote: The throttling of the virtual device must begin in generic_make_request and last to -endio. You release the throttle of the virtual device at the point you remap the bio to an underlying device, which you have convinced yourself is ok, but it is not. You seem to miss the fact that whatever resources the virtual device has allocated are no longer protected by the throttle count *of the virtual device*, or you do not Because it is charged to another device. Great. You charged the resource to another device, but you did not limit the amount of resources that the first device can consume. Which misses the whole point. Regards, Daniel - 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: BUG: when using 'brctl stp'
Bridge locking for /sys/class/net/br0/bridge/stp_enabled
was wrong. Another bug in bridge utilities makes it such that
this interface, meant it wasn't being used. The locking needs to be removed
from set_stp_state(), the lock is already acquired down in
br_stp_start()/br_stp_stop.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/net/bridge/br_sysfs_br.c 2007-07-16 14:24:18.0 +0100
+++ b/net/bridge/br_sysfs_br.c 2007-08-14 13:44:23.0 +0100
@@ -150,9 +150,7 @@ static ssize_t show_stp_state(struct dev
static void set_stp_state(struct net_bridge *br, unsigned long val)
{
rtnl_lock();
- spin_unlock_bh(br-lock);
br_stp_set_enabled(br, val);
- spin_lock_bh(br-lock);
rtnl_unlock();
}
-
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: BUG: when using 'brctl stp'
On Tue, Aug 14, 2007 at 02:11:05PM +0100, Stephen Hemminger wrote:
Bridge locking for /sys/class/net/br0/bridge/stp_enabled
was wrong. Another bug in bridge utilities makes it such that
this interface, meant it wasn't being used. The locking needs
to be removed from set_stp_state(), the lock is already acquired
down in br_stp_start()/br_stp_stop.
The 'locking' in set_stp_state() is actually dropping the lock
around the br_stp_set_enabled() invocation, not acquiring it:
@@ -150,9 +150,7 @@ static ssize_t show_stp_state(struct dev
static void set_stp_state(struct net_bridge *br, unsigned long val)
{
rtnl_lock();
- spin_unlock_bh(br-lock);
br_stp_set_enabled(br, val);
- spin_lock_bh(br-lock);
rtnl_unlock();
}
-
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] bridge: sysfs locking fix.
Forget earlier patch, it is wrong...
The stp change code generates sleeping function called from invalid context
because rtnl_lock() called with BH disabled. This fixes it by not acquiring then
dropping the bridge lock.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/net/bridge/br_sysfs_br.c 2007-08-06 09:26:48.0 +0100
+++ b/net/bridge/br_sysfs_br.c 2007-08-14 14:29:52.0 +0100
@@ -147,20 +147,26 @@ static ssize_t show_stp_state(struct dev
return sprintf(buf, %d\n, br-stp_enabled);
}
-static void set_stp_state(struct net_bridge *br, unsigned long val)
-{
- rtnl_lock();
- spin_unlock_bh(br-lock);
- br_stp_set_enabled(br, val);
- spin_lock_bh(br-lock);
- rtnl_unlock();
-}
static ssize_t store_stp_state(struct device *d,
struct device_attribute *attr, const char *buf,
size_t len)
{
- return store_bridge_parm(d, buf, len, set_stp_state);
+ struct net_bridge *br = to_bridge(d);
+ char *endp;
+ unsigned long val;
+
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
+ val = simple_strtoul(buf, endp, 0);
+ if (endp == buf)
+ return -EINVAL;
+
+ rtnl_lock();
+ br_stp_set_enabled(br, val);
+ rtnl_unlock();
+
}
static DEVICE_ATTR(stp_state, S_IRUGO | S_IWUSR, show_stp_state,
store_stp_state);
-
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: possible BUG while using CUPS
On 08/13/2007 11:46 AM, Udo van den Heuvel wrote: Michal Piotrowski wrote: On 11/08/07, Udo van den Heuvel [EMAIL PROTECTED] wrote: Using Cups 1.2.12 on Linux 2.6.22.1. (...) I clikc that link and hear the ping-ping of the BUG: This is very interesting. Can you reproduce this bug? I think so. (at least: I have seen it before: clicking around in Cups and this crash/bug/whatever.) This is on a VIA Epia EK8000. ksymoops did not really help me, this is all output I got. Ideas? BTW. Please try 2.6.22.2. Compiling... If you can reproduce that, do it after booting with kstack=2048 and post that so we can see the whole stack in the oops message. - 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] [396/2many] MAINTAINERS - QLOGIC QLAxxx NETWORK DRIVER
On Sun, Aug 12, 2007 at 11:34:33PM -0700, [EMAIL PROTECTED] wrote: Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 1fa922a..6a99fe5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3790,6 +3790,8 @@ P: Ron Mercer M: [EMAIL PROTECTED] L: netdev@vger.kernel.org S: Supported +F: Documentation/networking/LICENSE.qla3xxx +F: drivers/net/qla3xxx.* QNX4 FILESYSTEM P: Anders Larsen Acked-by: Ron Mercer [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] netfilter : xt_u32 bug correction
Eric Dumazet wrote: [PATCH] netfilter : xt_u32 bug correction Applied, thanks Eric. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] e1000e: remove namespace collisions with e1000
if you grep around this effort was already started using the 'e1e_' prefix. I like the shorter prefix, but your call ultimately. Either way, make sure to make the driver consistent there too. should it then be consistent with the overall driver name too? certainly calling things e1e or e1ke or heck, even elke if one wanted to be a triffle playful would certainly help distinguish this driver from its grandfather. rick jones - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/24] make atomic_read() behave consistently on frv
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote: Paul E. McKenney wrote: On Mon, Aug 13, 2007 at 01:15:52PM +0800, Herbert Xu wrote: Paul E. McKenney [EMAIL PROTECTED] wrote: On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote: Chris Snook [EMAIL PROTECTED] wrote: cpu_relax() contains a barrier, so it should do the right thing. For non-smp architectures, I'm concerned about interacting with interrupt handlers. Some drivers do use atomic_* operations. What problems with interrupt handlers? Access to int/long must be atomic or we're in big trouble anyway. Reordering due to compiler optimizations. CPU reordering does not affect interactions with interrupt handlers on a given CPU, but reordering due to compiler code-movement optimization does. Since volatile can in some cases suppress code-movement optimizations, it can affect interactions with interrupt handlers. If such reordering matters, then you should use one of the *mb macros or barrier() rather than relying on possibly hidden volatile cast. If communicating among CPUs, sure. However, when communicating between mainline and interrupt/NMI handlers on the same CPU, the barrier() and most expecially the *mb() macros are gross overkill. So there really truly is a place for volatile -- not a large place, to be sure, but a place nonetheless. I really would like all volatile users to go away and be replaced by explicit barriers. It makes things nicer and more explicit... for atomic_t type there probably aren't many optimisations that can be made which volatile would disallow (in actual kernel code), but for others (eg. bitops, maybe atomic ops in UP kernels), there would be. Maybe it is the safe way to go, but it does obscure cases where there is a real need for barriers. I prefer burying barriers into other primitives. Many atomic operations are allowed to be reordered between CPUs, so I don't have a good idea for the rationale to order them within the CPU (also loads and stores to long and ptr types are not ordered like this, although we do consider those to be atomic operations too). barrier() in a way is like enforcing sequential memory ordering between process and interrupt context, wheras volatile is just enforcing coherency of a single memory location (and as such is cheaper). barrier() is useful, but it has the very painful side-effect of forcing the compiler to dump temporaries. So we do need something that is not quite so global in effect. What do you think of this crazy idea? /* Enforce a compiler barrier for only operations to location X. * Call multiple times to provide an ordering between multiple * memory locations. Other memory operations can be assumed by * the compiler to remain unchanged and may be reordered */ #define order(x) asm volatile( : +m (x)) There was something very similar discussed earlier in this thread, with quite a bit of debate as to exactly what the m flag should look like. I suggested something similar named ACCESS_ONCE in the context of RCU (http://lkml.org/lkml/2007/7/11/664): #define ACCESS_ONCE(x) (*(volatile typeof(x) *)(x)) The nice thing about this is that it works for both loads and stores. Not clear that order() above does this -- I get compiler errors when I try something like b = order(a) or order(a) = 1 using gcc 4.1.2. Thanx, 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: Distributed storage. Mirroring to any number of devices.
On Aug 14 2007 20:29, Evgeniy Polyakov wrote: I'm pleased to announce second release of the distributed storage subsystem, which allows to form a storage on top of remote and local nodes, which in turn can be exported to another storage as a node to form tree-like storages. I'll be quick: what is it good for, are there any users, and what could it have to do with DRBD and all the other distribution storage talk that has come up lately (namely NBD w/Raid1)? Jan -- - 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: [net-2.6.24] forcedeth does not compile without CONFIG_FORCEDETH_NAPI set
Samuel Ortiz wrote:
Hi Oliver,
On Fri, Aug 10, 2007 at 07:34:03PM +0200, Oliver Hartkopp wrote:
Checking some other source with the current net-2.6.24 GIT, i just
discovered this:
CC drivers/net/mii.o
CC drivers/net/Space.o
CC drivers/net/loopback.o
CC drivers/net/b44.o
CC drivers/net/forcedeth.o
drivers/net/forcedeth.c: In function nv_nic_irq:
drivers/net/forcedeth.c:3017: error: RX_WORK_PER_LOOP undeclared (first
use in this function)
drivers/net/forcedeth.c:3017: error: (Each undeclared identifier is
reported only once
drivers/net/forcedeth.c:3017: error: for each function it appears in.)
make[2]: *** [drivers/net/forcedeth.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
This only occurs the CONFIG_FORCEDETH_NAPI is _disabled_.
This fixes the build:
--
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]
drivers/net/forcedeth.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 37732f9..90eef4a 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -2973,6 +2973,8 @@ static void nv_link_irq(struct net_device *dev)
dprintk(KERN_DEBUG %s: link change notification done.\n, dev-name);
}
+#define TX_WORK_PER_LOOP 64
+#define RX_WORK_PER_LOOP 64
static irqreturn_t nv_nic_irq(int foo, void *data)
{
struct net_device *dev = (struct net_device *) data;
@@ -3083,8 +3085,6 @@ static irqreturn_t nv_nic_irq(int foo, void *data)
return IRQ_RETVAL(i);
}
-#define TX_WORK_PER_LOOP 64
-#define RX_WORK_PER_LOOP 64
/**
* All _optimized functions are used to help increase performance
* (reduce CPU and increase throughput). They use descripter version 3,
Hi Samuel,
indeed a small thing that fixed the build problem :-)
Thanks for your patch best regards,
Oliver
Acked-by: Oliver Hartkopp [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: Distributed storage. Mirroring to any number of devices.
On Tue, Aug 14, 2007 at 07:20:49PM +0200, Jan Engelhardt ([EMAIL PROTECTED]) wrote: I'm pleased to announce second release of the distributed storage subsystem, which allows to form a storage on top of remote and local nodes, which in turn can be exported to another storage as a node to form tree-like storages. I'll be quick: what is it good for, are there any users, and what could it have to do with DRBD and all the other distribution storage talk that has come up lately (namely NBD w/Raid1)? It has number of advantages, outlined in the first release and on the project homepage, namely: * non-blocking processing without busy loops (compared to iSCSI and NBD) * small, plugable architecture * failover recovery (reconnect to remote target) * autoconfiguration * no additional allocatins (not including network part) - at least two in device mapper for fast path * very simple - try to compare with iSCSI * works with different network protocols * storage can be formed on top of remote nodes and be exported simultaneously (iSCSI is peer-to-peer only, NBD requires device mapper, is synchronous and wants special userspace thread) Compared to DRBD, which is a mirroring of the local requests to remote node, and raid on top of NBD, DST supports multiple remote nodes, it allows to remove any of them and then turn it back into the storage without breaking the dataflow, dst core will reconnect automatically to the failed remote nodes, it allows to work with detouched devices just like with usual filesystems (in case it was not formed as a part of linear storage, since in that case meta information is spreaded between nodes). It does not require special processes on behalf of network connection, everything will be performed automatically on behalf of DST core workers, it allows to export new device, created on top of mirror or linear combination of the others, which in turn can be formed on top of another and so on... This was designed to allow to create a distributed storage with completely transparent failover recovery, with ability to detouch remote nodes from mirror array to became standalone realtime backups (or snapshots) and turn it back into the storage without stopping main device node. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] b44-ssb: Powerup the bus before using the device.
We must turn on buspower before poking with the device
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev-new/drivers/net/b44.c
===
--- wireless-dev-new.orig/drivers/net/b44.c 2007-08-11 00:45:55.0
+0200
+++ wireless-dev-new/drivers/net/b44.c 2007-08-12 22:18:34.0 +0200
@@ -2154,17 +2154,23 @@ static int __devinit b44_init_one(struct
netif_carrier_off(dev);
+ err = ssb_bus_powerup(sdev-bus, 0);
+ if (err) {
+ dev_err(sdev-dev,
+ Failed to powerup the bus\n);
+ goto err_out_free_dev;
+ }
err = ssb_dma_set_mask(sdev, DMA_30BIT_MASK);
if (err) {
dev_err(sdev-dev,
Required 30BIT DMA mask unsupported by the system.\n);
- goto err_out_free_dev;
+ goto err_out_powerdown;
}
err = b44_get_invariants(bp);
if (err) {
dev_err(sdev-dev,
Problem fetching invariants of chip, aborting.\n);
- goto err_out_free_dev;
+ goto err_out_powerdown;
}
bp-mii_if.dev = dev;
@@ -2184,7 +2190,7 @@ static int __devinit b44_init_one(struct
err = register_netdev(dev);
if (err) {
dev_err(sdev-dev, Cannot register net device, aborting.\n);
- goto out;
+ goto err_out_powerdown;
}
ssb_set_drvdata(sdev, dev);
@@ -2201,6 +2207,9 @@ static int __devinit b44_init_one(struct
return 0;
+err_out_powerdown:
+ ssb_bus_may_powerdown(sdev-bus);
+
err_out_free_dev:
free_netdev(dev);
@@ -2208,13 +2217,14 @@ out:
return err;
}
-static void __devexit b44_remove_one(struct ssb_device *pdev)
+static void __devexit b44_remove_one(struct ssb_device *sdev)
{
- struct net_device *dev = ssb_get_drvdata(pdev);
+ struct net_device *dev = ssb_get_drvdata(sdev);
unregister_netdev(dev);
+ ssb_bus_may_powerdown(sdev-bus);
free_netdev(dev);
- ssb_set_drvdata(pdev, NULL);
+ ssb_set_drvdata(sdev, NULL);
}
static int b44_suspend(struct ssb_device *sdev, pm_message_t state)
@@ -2251,6 +2261,13 @@ static int b44_resume(struct ssb_device
struct b44 *bp = netdev_priv(dev);
int rc = 0;
+ rc = ssb_bus_powerup(sdev-bus, 0);
+ if (rc) {
+ dev_err(sdev-dev,
+ Failed to powerup the bus\n);
+ return rc;
+ }
+
if (!netif_running(dev))
return 0;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xen-netfront: Avoid deref'ing skbafter it is potentially freed.
Jesper Juhl wrote: This moves the updating of both tx_bytes and tx_packets inside the spinlock, but as far as I can see we only _really_ need to move the tx_bytes update. Considering that we generally want to do as little work as possible while holding a lock, wouldn't the following be slightly better? Hm, I think it would be better to keep them together. The second add is going to be pretty much free, particularly since the tx_bytes add will probably pull tx_packets into cache. I have a followup patch to convert it to using the netdevice stats structure, which will definitely put them in the same cacheline (though perhaps the stats structure should group tx and rx members together?). J J - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: troubles with r8169
On Sunday 12 August 2007 21:06:43 Vadim Dyadkin wrote: Robert Hancock пишет: This could well be a problem with the nvidia driver as it shares the same IRQ. The first step would be to see if the problem still shows up without the nvidia binary module loaded. Thank for your answer. This problem never shows up if I use only nvidia driver (the work without network), or if I use only r8169 (without x.org). If I use both of them I have the hang. Usually the hang appears if OpenGL is used or network rate is maximal. I tested this regimes many times before. If you haven't already, I'd drop [EMAIL PROTECTED] an email to see if they have any insight. Not that this can't be a kernel bug, just that it's a bit difficult for kernel developers to debug when you're using a driver for which we don't have the sources. As for changing the IRQ assignments, I don't have any immediate suggestions. I notice that this laptop has a dual core processor, so I'm guessing disabling APIC isn't an option. Have you tried that anyway, just to see if the IRQ assignment differs? -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - 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] iproute2: sch_rr support in tc
Stephen, These patches are resubmissions of patches that were approved, but didn't get merged. The first patch is Patrick McHardy's nested compat attribute patch to the netlink libraries. The second patch adds multiqueue and sch_rr functionality to tc. The multiqueue features have been merged to 2.6.23, so we'll need these patches to manage the new kernel features. These patches are unmodified from the version that was approved. They've been applied to the latest iproute2 commit. -- PJ Waskiewicz [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] IPROUTE2: RTNETLINK nested attributes
From: Patrick McHardy [EMAIL PROTECTED]
This adds capability for iproute2 to send nested attributes to the
kernel, while maintaining backwards compatibility.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
include/libnetlink.h |9 +
lib/libnetlink.c | 46 ++
2 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/include/libnetlink.h b/include/libnetlink.h
index 49e248e..b67c5a5 100644
--- a/include/libnetlink.h
+++ b/include/libnetlink.h
@@ -39,15 +39,24 @@ extern int rtnl_send(struct rtnl_handle *rth, const char
*buf, int);
extern int addattr32(struct nlmsghdr *n, int maxlen, int type, __u32 data);
extern int addattr_l(struct nlmsghdr *n, int maxlen, int type, const void
*data, int alen);
extern int addraw_l(struct nlmsghdr *n, int maxlen, const void *data, int len);
+extern struct rtattr *addattr_nest(struct nlmsghdr *n, int maxlen, int type);
+extern int addattr_nest_end(struct nlmsghdr *n, struct rtattr *nest);
+extern struct rtattr *addattr_nest_compat(struct nlmsghdr *n, int maxlen, int
type, const void *data, int len);
+extern int addattr_nest_compat_end(struct nlmsghdr *n, struct rtattr *nest);
extern int rta_addattr32(struct rtattr *rta, int maxlen, int type, __u32 data);
extern int rta_addattr_l(struct rtattr *rta, int maxlen, int type, const void
*data, int alen);
extern int parse_rtattr(struct rtattr *tb[], int max, struct rtattr *rta, int
len);
extern int parse_rtattr_byindex(struct rtattr *tb[], int max, struct rtattr
*rta, int len);
+extern int __parse_rtattr_nested_compat(struct rtattr *tb[], int max, struct
rtattr *rta, int len);
#define parse_rtattr_nested(tb, max, rta) \
(parse_rtattr((tb), (max), RTA_DATA(rta), RTA_PAYLOAD(rta)))
+#define parse_rtattr_nested_compat(tb, max, rta, data, len) \
+({ data = RTA_PAYLOAD(rta) = len ? RTA_DATA(rta) : NULL; \
+ __parse_rtattr_nested_compat(tb, max, rta, len); })
+
extern int rtnl_listen(struct rtnl_handle *, rtnl_filter_t handler,
void *jarg);
extern int rtnl_from_file(FILE *, rtnl_filter_t handler,
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 555dd5c..12883fe 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -527,6 +527,39 @@ int addraw_l(struct nlmsghdr *n, int maxlen, const void
*data, int len)
return 0;
}
+struct rtattr *addattr_nest(struct nlmsghdr *n, int maxlen, int type)
+{
+ struct rtattr *nest = NLMSG_TAIL(n);
+
+ addattr_l(n, maxlen, type, NULL, 0);
+ return nest;
+}
+
+int addattr_nest_end(struct nlmsghdr *n, struct rtattr *nest)
+{
+ nest-rta_len = (void *)NLMSG_TAIL(n) - (void *)nest;
+ return n-nlmsg_len;
+}
+
+struct rtattr *addattr_nest_compat(struct nlmsghdr *n, int maxlen, int type,
+ const void *data, int len)
+{
+ struct rtattr *start = NLMSG_TAIL(n);
+
+ addattr_l(n, maxlen, type, data, len);
+ addattr_nest(n, maxlen, type);
+ return start;
+}
+
+int addattr_nest_compat_end(struct nlmsghdr *n, struct rtattr *start)
+{
+ struct rtattr *nest = (void *)start + NLMSG_ALIGN(start-rta_len);
+
+ start-rta_len = (void *)NLMSG_TAIL(n) - (void *)start;
+ addattr_nest_end(n, nest);
+ return n-nlmsg_len;
+}
+
int rta_addattr32(struct rtattr *rta, int maxlen, int type, __u32 data)
{
int len = RTA_LENGTH(4);
@@ -589,3 +622,16 @@ int parse_rtattr_byindex(struct rtattr *tb[], int max,
struct rtattr *rta, int l
fprintf(stderr, !!!Deficit %d, rta_len=%d\n, len,
rta-rta_len);
return i;
}
+
+int __parse_rtattr_nested_compat(struct rtattr *tb[], int max, struct rtattr
*rta,
+int len)
+{
+ if (RTA_PAYLOAD(rta) len)
+ return -1;
+ if (RTA_PAYLOAD(rta) = RTA_ALIGN(len) + sizeof(struct rtattr)) {
+ rta = RTA_DATA(rta) + RTA_ALIGN(len);
+ return parse_rtattr_nested(tb, max, rta);
+ }
+ memset(tb, 0, sizeof(struct rtattr *) * max);
+ return 0;
+}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] iproute2: sch_rr support in tc
This patch applies on top of Patrick McHardy's RTNETLINK
patches to add nested compat attributes. This is needed to maintain
ABI for sch_{rr|prio} in the kernel with respect to tc. A new option,
namely multiqueue, was added to sch_prio and sch_rr. This will allow
a user to turn multiqueue support on for sch_prio or sch_rr at loadtime.
Also, tc qdisc ls will display whether or not multiqueue is enabled on
that qdisc. When in multiqueue mode, a user can specify a value of 0 for
bands, and the number of bands will be created to match the number of
queues on the device.
This patch is to support the new sch_rr (round-robin) qdisc being proposed
in NET for multiqueue network device support in the Linux network stack.
It uses q_prio.c as the template, since the qdiscs are nearly identical,
outside of the -dequeue() routine.
Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
---
include/linux/pkt_sched.h |9 +++
tc/q_prio.c | 24 +++--
tc/q_rr.c | 127 +
3 files changed, 155 insertions(+), 5 deletions(-)
diff --git a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h
index d10f353..4f1531b 100644
--- a/include/linux/pkt_sched.h
+++ b/include/linux/pkt_sched.h
@@ -101,6 +101,15 @@ struct tc_prio_qopt
__u8priomap[TC_PRIO_MAX+1]; /* Map: logical priority - PRIO band */
};
+enum
+{
+TCA_PRIO_UNSPEC,
+TCA_PRIO_MQ,
+__TCA_PRIO_MAX
+};
+
+#define TCA_PRIO_MAX(__TCA_PRIO_MAX - 1)
+
/* TBF section */
struct tc_tbf_qopt
diff --git a/tc/q_prio.c b/tc/q_prio.c
index d696e1b..6883edb 100644
--- a/tc/q_prio.c
+++ b/tc/q_prio.c
@@ -29,7 +29,7 @@
static void explain(void)
{
- fprintf(stderr, Usage: ... prio bands NUMBER priomap P1 P2...\n);
+ fprintf(stderr, Usage: ... prio bands NUMBER priomap P1
P2...[multiqueue]\n);
}
#define usage() return(-1)
@@ -40,6 +40,8 @@ static int prio_parse_opt(struct qdisc_util *qu, int argc,
char **argv, struct n
int pmap_mode = 0;
int idx = 0;
struct tc_prio_qopt opt={3,{ 1, 2, 2, 2, 1, 2, 0, 0, 1, 1, 1, 1, 1, 1,
1, 1 }};
+ struct rtattr *nest;
+ unsigned char mq = 0;
while (argc 0) {
if (strcmp(*argv, bands) == 0) {
@@ -57,6 +59,8 @@ static int prio_parse_opt(struct qdisc_util *qu, int argc,
char **argv, struct n
return -1;
}
pmap_mode = 1;
+ } else if (strcmp(*argv, multiqueue) == 0) {
+ mq = 1;
} else if (strcmp(*argv, help) == 0) {
explain();
return -1;
@@ -90,7 +94,10 @@ static int prio_parse_opt(struct qdisc_util *qu, int argc,
char **argv, struct n
opt.priomap[idx] = opt.priomap[TC_PRIO_BESTEFFORT];
}
*/
- addattr_l(n, 1024, TCA_OPTIONS, opt, sizeof(opt));
+ nest = addattr_nest_compat(n, 1024, TCA_OPTIONS, opt, sizeof(opt));
+ if (mq)
+ addattr_l(n, 1024, TCA_PRIO_MQ, NULL, 0);
+ addattr_nest_compat_end(n, nest);
return 0;
}
@@ -98,16 +105,23 @@ int prio_print_opt(struct qdisc_util *qu, FILE *f, struct
rtattr *opt)
{
int i;
struct tc_prio_qopt *qopt;
+ struct rtattr *tb[TCA_PRIO_MAX+1];
if (opt == NULL)
return 0;
- if (RTA_PAYLOAD(opt) sizeof(*qopt))
- return -1;
- qopt = RTA_DATA(opt);
+ if (parse_rtattr_nested_compat(tb, TCA_PRIO_MAX, opt, qopt,
+ sizeof(*qopt)))
+return -1;
+
fprintf(f, bands %u priomap , qopt-bands);
for (i=0; i=TC_PRIO_MAX; i++)
fprintf(f, %d, qopt-priomap[i]);
+
+ if (tb[TCA_PRIO_MQ])
+ fprintf(f, multiqueue: %s ,
+ *(unsigned char *)RTA_DATA(tb[TCA_PRIO_MQ]) ? on : off);
+
return 0;
}
diff --git a/tc/q_rr.c b/tc/q_rr.c
new file mode 100644
index 000..9335c47
--- /dev/null
+++ b/tc/q_rr.c
@@ -0,0 +1,127 @@
+/*
+ * q_rr.c RR.
+ *
+ * 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.
+ *
+ * Authors:PJ Waskiewicz, [EMAIL PROTECTED]
+ * Original Authors: Alexey Kuznetsov, [EMAIL PROTECTED] (from PRIO)
+ *
+ * Changes:
+ *
+ * Ole Husgaard [EMAIL PROTECTED]: 990513: prio2band map was always reset.
+ * J Hadi Salim [EMAIL PROTECTED]: 990609: priomap fix.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include syslog.h
+#include fcntl.h
+#include sys/socket.h
+#include netinet/in.h
+#include arpa/inet.h
+#include string.h
+
+#include utils.h
+#include tc_util.h
+
+static void
Re: [PATCH] [DM9000] Add support for big-endian hosts
On Tue, Aug 14, 2007 at 01:22:32PM +0200, Laurent Pinchart wrote:
This patch splits the receive status in 8bit wide fields and convert the
packet length from little endian to CPU byte order.
Which version of the the kernel was this against, it applies with
fuzz to 2.6.23-rc3:
$ patch -p1 ~/dm9000-fix-endianness.patch
patching file drivers/net/dm9000.c
Hunk #1 succeeded at 894 (offset 15 lines).
Hunk #2 succeeded at 936 (offset 15 lines).
Hunk #3 succeeded at 948 (offset 15 lines).
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
drivers/net/dm9000.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 264fa0e..ee578d9 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -879,7 +879,8 @@ dm9000_timer(unsigned long data)
}
struct dm9000_rxhdr {
- u16 RxStatus;
+ u8 RxPktReady;
+ u8 RxStatus;
u16 RxLen;
} __attribute__((__packed__));
@@ -920,7 +921,7 @@ dm9000_rx(struct net_device *dev)
(db-inblk)(db-io_data, rxhdr, sizeof(rxhdr));
- RxLen = rxhdr.RxLen;
+ RxLen = le16_to_cpu(rxhdr.RxLen);
/* Packet Status check */
if (RxLen 0x40) {
@@ -932,17 +933,17 @@ dm9000_rx(struct net_device *dev)
PRINTK1(RST: RX Len:%x\n, RxLen);
}
- if (rxhdr.RxStatus 0xbf00) {
+ if (rxhdr.RxStatus 0xbf) {
GoodPacket = false;
- if (rxhdr.RxStatus 0x100) {
+ if (rxhdr.RxStatus 0x01) {
PRINTK1(fifo error\n);
db-stats.rx_fifo_errors++;
}
- if (rxhdr.RxStatus 0x200) {
+ if (rxhdr.RxStatus 0x02) {
PRINTK1(crc error\n);
db-stats.rx_crc_errors++;
}
- if (rxhdr.RxStatus 0x8000) {
+ if (rxhdr.RxStatus 0x80) {
PRINTK1(length error\n);
db-stats.rx_length_errors++;
}
--
1.5.0
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
-
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] [DM9000] External PHY support
On Tue, Aug 14, 2007 at 01:29:35PM +0200, Laurent Pinchart wrote:
This patch adds a flag to the DM9000 platform data which, when set,
configures the device to use an external PHY.
This patch applies with fuzz:
$ patch -p1 ~/dm9000-external-phy.patch
patching file drivers/net/dm9000.c
Hunk #1 succeeded at 136 (offset 12 lines).
Hunk #2 succeeded at 529 (offset 15 lines).
Hunk #3 succeeded at 673 (offset 15 lines).
patching file include/linux/dm9000.h
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
drivers/net/dm9000.c |6 ++
include/linux/dm9000.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index ee578d9..820f0d3 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -124,6 +124,7 @@ typedef struct board_info {
u16 dbug_cnt;
u8 io_mode; /* 0:word, 2:byte */
u8 phy_addr;
+ unsigned int flags;
void (*inblk)(void __iomem *port, void *data, int length);
void (*outblk)(void __iomem *port, void *data, int length);
@@ -513,6 +514,8 @@ dm9000_probe(struct platform_device *pdev)
if (pdata-dumpblk != NULL)
db-dumpblk = pdata-dumpblk;
+
+ db-flags = pdata-flags;
}
dm9000_reset(db);
@@ -655,6 +658,9 @@ dm9000_init_dm9000(struct net_device *dev)
iow(db, DM9000_GPCR, GPCR_GEP_CNTL);/* Let GPIO0 output */
iow(db, DM9000_GPR, 0); /* Enable PHY */
+ if (db-flags DM9000_PLATF_EXT_PHY)
+ iow(db, DM9000_NCR, NCR_EXT_PHY);
+
/* Program operating register */
iow(db, DM9000_TCR, 0); /* TX Polling clear */
iow(db, DM9000_BPTR, 0x3f); /* Less 3Kb, 200us */
diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
index 0008e2a..ea530fd 100644
--- a/include/linux/dm9000.h
+++ b/include/linux/dm9000.h
@@ -19,6 +19,7 @@
#define DM9000_PLATF_8BITONLY(0x0001)
#define DM9000_PLATF_16BITONLY (0x0002)
#define DM9000_PLATF_32BITONLY (0x0004)
+#define DM9000_PLATF_EXT_PHY (0x0008)
/* platfrom data for platfrom device structure's platfrom_data field */
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
-
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] ax25: don't free pointers to statically allocated data
commit 8d5cf596d10d740b69b5f4bbdb54b85abf75810d started to add statically
allocated ax25_protocol's to list. However kfree() was still in place waiting
for unsuspecting ones on module removal.
Steps to reproduce:
modprobe netrom
rmmod netrom
P.S.: code would benefit greatly from list_add/list_del usage
kernel BUG at mm/slab.c:592!
invalid opcode: [1] PREEMPT SMP
CPU 0
Modules linked in: netrom ax25 af_packet usbcore rtc_cmos rtc_core rtc_lib
Pid: 4477, comm: rmmod Not tainted 2.6.23-rc3-bloat #2
RIP: 0010:[802ac646] [802ac646] kfree+0x1c6/0x260
RSP: :810079a05e48 EFLAGS: 00010046
RAX: RBX: RCX: 8100c000
RDX: 81007e552458 RSI: RDI: 805d
RBP: 810079a05e88 R08: 0001 R09:
R10: 0001 R11: R12: 8805d080
R13: 8805d080 R14: R15: 0282
FS: 2b73fc98aae0() GS:805dc000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0053f3b8 CR3: 79ff2000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process rmmod (pid: 4477, threadinfo 810079a04000, task 8100775aa480)
Stack: 810079a05e68 0246 8804eca0
8805d080 00cf 0880
810079a05eb8 8803ec90 810079a05eb8
Call Trace:
[8803ec90] :ax25:ax25_protocol_release+0xa0/0xb0
[88056ecb] :netrom:nr_exit+0x6b/0xf0
[80268bf0] sys_delete_module+0x170/0x1f0
[8025da35] trace_hardirqs_on+0xd5/0x170
[804835aa] trace_hardirqs_on_thunk+0x35/0x37
[8020c13e] system_call+0x7e/0x83
Code: 0f 0b eb fe 66 66 90 66 66 90 48 8b 52 10 48 8b 02 25 00 40
RIP [802ac646] kfree+0x1c6/0x260
RSP 810079a05e48
Kernel panic - not syncing: Fatal exception
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
---
net/ax25/ax25_iface.c |2 --
1 file changed, 2 deletions(-)
--- a/net/ax25/ax25_iface.c
+++ b/net/ax25/ax25_iface.c
@@ -69,7 +69,6 @@ void ax25_protocol_release(unsigned int pid)
if (protocol-pid == pid) {
protocol_list = protocol-next;
write_unlock_bh(protocol_list_lock);
- kfree(protocol);
return;
}
@@ -78,7 +77,6 @@ void ax25_protocol_release(unsigned int pid)
s = protocol-next;
protocol-next = protocol-next-next;
write_unlock_bh(protocol_list_lock);
- kfree(s);
return;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [459/2many] MAINTAINERS - SPIDERNET NETWORK DRIVER for CELL
On Mon, Aug 13, 2007 at 10:07:25AM -0700, Joe Perches wrote: On Mon, 2007-08-13 at 10:45 -0500, Linas Vepstas wrote: Note quite right. spider-pic is not part of spider_net. SPIDERNET NETWORK DRIVER for CELL P:Linas Vepstas M:[EMAIL PROTECTED] L:netdev@vger.kernel.org S:Supported F:Documentation/networking/spider_net.txt F:drivers/net/spider_net* Works for me. Acked-by: Linas Vepstas [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] bridge: sysfs locking fix.
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 14 Aug 2007 14:50:52 +0100 Forget earlier patch, it is wrong... The stp change code generates sleeping function called from invalid context because rtnl_lock() called with BH disabled. This fixes it by not acquiring then dropping the bridge lock. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Applied, thanks Stephen. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] Add ETHTOOL_[GS]FLAGS sub-ioctls
Rick Jones wrote: David Miller wrote: From: Ben Greear [EMAIL PROTECTED] Date: Fri, 10 Aug 2007 15:40:02 -0700 For GSO on output, is there a generic fallback for any driver that does not specifically implement GSO? Absolutely, in fact that's mainly what it's there for. I don't think there is any issue. The knob is there via ethtool for people who really want to disable it. Just to be paranoid (who me?) we are then at a point where what happened a couple months ago with forwarding between 10G and IPoIB won't happen again - where things failed because a 10G NIC had LRO enabled by default? we still have the NETIF_F_LRO flag which Jeff will keep around. Perhaps the IPoIB code can force this to _off_ when setting it up? (or at least warn about it). Auke - 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 07/18] PCI-X/PCI-Express read control interfaces: use them in e1000
[EMAIL PROTECTED] wrote:
From: Peter Oruba [EMAIL PROTECTED]
These driver changes incorporate the proposed PCI-X / PCI-Express read byte
count interface. Reading and setting those valuse doesn't take place
manually, instead wrapping functions are called to allow quirks for some
PCI bridges.
Signed-off by: Peter Oruba [EMAIL PROTECTED]
Based on work by Stephen Hemminger [EMAIL PROTECTED]
Cc: Auke Kok [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_hw.c | 25 +++--
drivers/net/e1000/e1000_hw.h |2 ++
drivers/net/e1000/e1000_main.c | 14 ++
3 files changed, 19 insertions(+), 22 deletions(-)
diff -puN
drivers/net/e1000/e1000_hw.c~pci-x-pci-express-read-control-interfaces-e1000
drivers/net/e1000/e1000_hw.c
---
a/drivers/net/e1000/e1000_hw.c~pci-x-pci-express-read-control-interfaces-e1000
+++ a/drivers/net/e1000/e1000_hw.c
@@ -865,10 +865,6 @@ e1000_init_hw(struct e1000_hw *hw)
uint32_t ctrl;
uint32_t i;
int32_t ret_val;
-uint16_t pcix_cmd_word;
-uint16_t pcix_stat_hi_word;
-uint16_t cmd_mmrbc;
-uint16_t stat_mmrbc;
uint32_t mta_size;
uint32_t reg_data;
uint32_t ctrl_ext;
@@ -958,24 +954,9 @@ e1000_init_hw(struct e1000_hw *hw)
break;
default:
/* Workaround for PCI-X problem when BIOS sets MMRBC incorrectly. */
-if (hw-bus_type == e1000_bus_type_pcix) {
-e1000_read_pci_cfg(hw, PCIX_COMMAND_REGISTER, pcix_cmd_word);
-e1000_read_pci_cfg(hw, PCIX_STATUS_REGISTER_HI,
-pcix_stat_hi_word);
-cmd_mmrbc = (pcix_cmd_word PCIX_COMMAND_MMRBC_MASK)
-PCIX_COMMAND_MMRBC_SHIFT;
-stat_mmrbc = (pcix_stat_hi_word PCIX_STATUS_HI_MMRBC_MASK)
-PCIX_STATUS_HI_MMRBC_SHIFT;
-if (stat_mmrbc == PCIX_STATUS_HI_MMRBC_4K)
-stat_mmrbc = PCIX_STATUS_HI_MMRBC_2K;
-if (cmd_mmrbc stat_mmrbc) {
-pcix_cmd_word = ~PCIX_COMMAND_MMRBC_MASK;
-pcix_cmd_word |= stat_mmrbc PCIX_COMMAND_MMRBC_SHIFT;
-e1000_write_pci_cfg(hw, PCIX_COMMAND_REGISTER,
-pcix_cmd_word);
-}
-}
-break;
+ if (hw-bus_type == e1000_bus_type_pcix e1000_pcix_get_mmrbc(hw)
2048)
+ e1000_pcix_set_mmrbc(hw, 2048);
+ break;
}
/* More time needed for PHY to initialize */
diff -puN
drivers/net/e1000/e1000_hw.h~pci-x-pci-express-read-control-interfaces-e1000
drivers/net/e1000/e1000_hw.h
---
a/drivers/net/e1000/e1000_hw.h~pci-x-pci-express-read-control-interfaces-e1000
+++ a/drivers/net/e1000/e1000_hw.h
@@ -424,6 +424,8 @@ void e1000_pci_clear_mwi(struct e1000_hw
void e1000_read_pci_cfg(struct e1000_hw *hw, uint32_t reg, uint16_t * value);
void e1000_write_pci_cfg(struct e1000_hw *hw, uint32_t reg, uint16_t * value);
int32_t e1000_read_pcie_cap_reg(struct e1000_hw *hw, uint32_t reg, uint16_t
*value);
+void e1000_pcix_set_mmrbc(struct e1000_hw *hw, int mmrbc);
+int e1000_pcix_get_mmrbc(struct e1000_hw *hw);
/* Port I/O is only supported on 82544 and newer */
void e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value);
int32_t e1000_disable_pciex_master(struct e1000_hw *hw);
diff -puN
drivers/net/e1000/e1000_main.c~pci-x-pci-express-read-control-interfaces-e1000
drivers/net/e1000/e1000_main.c
---
a/drivers/net/e1000/e1000_main.c~pci-x-pci-express-read-control-interfaces-e1000
+++ a/drivers/net/e1000/e1000_main.c
@@ -4906,6 +4906,20 @@ e1000_write_pci_cfg(struct e1000_hw *hw,
pci_write_config_word(adapter-pdev, reg, *value);
}
+int
+e1000_pcix_get_mmrbc(struct e1000_hw *hw)
+{
+ struct e1000_adapter *adapter = hw-back;
+ return pcix_get_mmrbc(adapter-pdev);
+}
+
+void
+e1000_pcix_set_mmrbc(struct e1000_hw *hw, int mmrbc)
+{
+ struct e1000_adapter *adapter = hw-back;
+ pcix_set_mmrbc(adapter-pdev, mmrbc);
+}
+
int32_t
e1000_read_pcie_cap_reg(struct e1000_hw *hw, uint32_t reg, uint16_t *value)
{
_
Jeff,
This has been sitting in -mm long enough I think. Please merge in upstream.
Acked-by: Auke Kok [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 12/18] e1000: #if 0 two functions
Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
From: Adrian Bunk [EMAIL PROTECTED]
e1000_{read,write}_pci_cfg() are no longer used.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Cc: Auke Kok [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_hw.h |2 --
drivers/net/e1000/e1000_main.c |4
2 files changed, 4 insertions(+), 2 deletions(-)
if it's truly dead code in upstream, we should just remove it from e1000
if I apply this to #master and compile, it blows up: the two functions are still
in use there. I also don't see any difference with current #upstream
so, I don't know what is in -mm at the moment, but we do not want this in jeff's
tree.
Auke
-
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 12/18] e1000: #if 0 two functions
Kok, Auke wrote:
Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
From: Adrian Bunk [EMAIL PROTECTED]
e1000_{read,write}_pci_cfg() are no longer used.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Cc: Auke Kok [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_hw.h |2 --
drivers/net/e1000/e1000_main.c |4
2 files changed, 4 insertions(+), 2 deletions(-)
if it's truly dead code in upstream, we should just remove it from e1000
if I apply this to #master and compile, it blows up: the two functions are still
in use there. I also don't see any difference with current #upstream
so, I don't know what is in -mm at the moment, but we do not want this in jeff's
tree.
whoops, I fail to correlate this with the mmrbc patch I just acked 5 minutes
ago, which removes the need for these functions.
I'll push a patch to remove these functions once I hear what the plan is for the
mmrbc patch.
Cheers,
Auke
-
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] IOAT: Fix ioatdma descriptor cache miss
(copying from linux-kernel to net-dev)
The layout for struct ioat_desc_sw is non-optimal and causes an extra
cache hit for every descriptor processed. By tightening up the struct
layout and removing one item, we pull in the fields that get used in
the speedpath and get a little better performance.
Before:
---
struct ioat_desc_sw {
struct ioat_dma_descriptor * hw; /* 0 8
*/
struct list_head node; /* 816
*/
inttx_cnt; /*24 4
*/
/* XXX 4 bytes hole, try to pack */
dma_addr_t src; /*32 8
*/
__u32 src_len; /*40 4
*/
/* XXX 4 bytes hole, try to pack */
dma_addr_t dst; /*48 8
*/
__u32 dst_len; /*56 4
*/
/* XXX 4 bytes hole, try to pack */
/* --- cacheline 1 boundary (64 bytes) --- */
struct dma_async_tx_descriptor async_tx; /*64 144
*/
/* --- cacheline 3 boundary (192 bytes) was 16 bytes ago --- */
/* size: 208, cachelines: 4 */
/* sum members: 196, holes: 3, sum holes: 12 */
/* last cacheline: 16 bytes */
}; /* definitions: 1 */
After:
--
struct ioat_desc_sw {
struct ioat_dma_descriptor * hw; /* 0 8
*/
struct list_head node; /* 816
*/
inttx_cnt; /*24 4
*/
__u32 len; /*28 4
*/
dma_addr_t src; /*32 8
*/
dma_addr_t dst; /*40 8
*/
struct dma_async_tx_descriptor async_tx; /*48 144
*/
/* --- cacheline 3 boundary (192 bytes) --- */
/* size: 192, cachelines: 3 */
}; /* definitions: 1 */
Signed-off-by: Shannon Nelson [EMAIL PROTECTED]
---
drivers/dma/ioatdma.c |7 +++
drivers/dma/ioatdma.h |3 +--
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
index 5fbe56b..2d1f178 100644
--- a/drivers/dma/ioatdma.c
+++ b/drivers/dma/ioatdma.c
@@ -347,8 +347,7 @@ ioat_dma_prep_memcpy(struct dma_chan *chan, size_t
len, int int_en)
new-async_tx.ack = 0; /* client is in control of this ack */
new-async_tx.cookie = -EBUSY;
- pci_unmap_len_set(new, src_len, orig_len);
- pci_unmap_len_set(new, dst_len, orig_len);
+ pci_unmap_len_set(new, len, orig_len);
spin_unlock_bh(ioat_chan-desc_lock);
return new ? new-async_tx : NULL;
@@ -423,11 +422,11 @@ static void ioat_dma_memcpy_cleanup(struct
ioat_dma_chan *chan)
*/
pci_unmap_page(chan-device-pdev,
pci_unmap_addr(desc, dst),
- pci_unmap_len(desc, dst_len),
+ pci_unmap_len(desc, len),
PCI_DMA_FROMDEVICE);
pci_unmap_page(chan-device-pdev,
pci_unmap_addr(desc, src),
- pci_unmap_len(desc, src_len),
+ pci_unmap_len(desc, len),
PCI_DMA_TODEVICE);
}
diff --git a/drivers/dma/ioatdma.h b/drivers/dma/ioatdma.h
index d372647..bf4dad7 100644
--- a/drivers/dma/ioatdma.h
+++ b/drivers/dma/ioatdma.h
@@ -111,10 +111,9 @@ struct ioat_desc_sw {
struct ioat_dma_descriptor *hw;
struct list_head node;
int tx_cnt;
+ DECLARE_PCI_UNMAP_LEN(len)
DECLARE_PCI_UNMAP_ADDR(src)
- DECLARE_PCI_UNMAP_LEN(src_len)
DECLARE_PCI_UNMAP_ADDR(dst)
- DECLARE_PCI_UNMAP_LEN(dst_len)
struct dma_async_tx_descriptor async_tx;
};
-
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: Realtek r8168 slow outbound transfer - potential fix/workaround
Bruce Cole [EMAIL PROTECTED] : [...] What's the status of this fix? It (or something more refined) seems necessary to correct the current performance problems with this driver. An explanation or something more refined would be welcome. [...] I can troubleshoot in more detail if that would help get a proper fix developed. Can you try 2.6.23-rc3 with NAPI enabled and send a complete dmesg + /proc/interrupts + ethtool -S output ? -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] unexport dev_ethtool
This patch removes the no longer used EXPORT_SYMBOL(dev_ethtool). Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- 37bcb29c1a1fefe6da0ea9e54a5cde09a82318f0 diff --git a/net/core/ethtool.c b/net/core/ethtool.c index 2ab0a60..c5e0593 100644 --- a/net/core/ethtool.c +++ b/net/core/ethtool.c @@ -948,7 +948,6 @@ int dev_ethtool(struct ifreq *ifr) return rc; } -EXPORT_SYMBOL(dev_ethtool); EXPORT_SYMBOL(ethtool_op_get_link); EXPORT_SYMBOL(ethtool_op_get_sg); EXPORT_SYMBOL(ethtool_op_get_tso); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] e1000e: remove namespace collisions with e1000
Rick Jones wrote: if you grep around this effort was already started using the 'e1e_' prefix. I like the shorter prefix, but your call ultimately. Either way, make sure to make the driver consistent there too. should it then be consistent with the overall driver name too? certainly calling things e1e or e1ke or heck, even elke if one wanted to be a triffle playful would certainly help distinguish this driver from its grandfather. I think we are passed the time for the name-a-driver raffle now. We've informed a lot of people that the name will be e1000e, so I definately prefer using this internally as well. As for the e1000_get_speed_and_duplex_fiber_serdes long names, those are an eyesore to me as well... Auke - 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] net/8021q/vlanproc.c: fix check-after-use
The Coverity checker spotted that we'd have already oops'ed if vlandev
was NULL.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.23-rc1-mm2/net/8021q/vlanproc.c.old 2007-08-08
06:22:40.0 +0200
+++ linux-2.6.23-rc1-mm2/net/8021q/vlanproc.c 2007-08-08 06:23:13.0
+0200
@@ -314,17 +314,17 @@
static int vlandev_seq_show(struct seq_file *seq, void *offset)
{
struct net_device *vlandev = (struct net_device *) seq-private;
const struct vlan_dev_info *dev_info = VLAN_DEV_INFO(vlandev);
struct net_device_stats *stats;
static const char fmt[] = %30s %12lu\n;
int i;
- if ((vlandev == NULL) || (!(vlandev-priv_flags IFF_802_1Q_VLAN)))
+ if (!(vlandev-priv_flags IFF_802_1Q_VLAN))
return 0;
seq_printf(seq, %s VID: %d REORDER_HDR: %i dev-priv_flags:
%hx\n,
vlandev-name, dev_info-vlan_id,
(int)(dev_info-flags 1), vlandev-priv_flags);
stats = vlan_dev_get_stats(vlandev);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] unexport dev_ethtool
On Tue, Aug 14, 2007 at 11:22:03PM +0200, Adrian Bunk wrote: This patch removes the no longer used EXPORT_SYMBOL(dev_ethtool). Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: Matthew Wilcox [EMAIL PROTECTED] -- Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - 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] econet: remove econet_packet_type on unload
Steps to reproduce: modprobe econet rmmod econet modprobe econet Unable to handle kernel paging request at 8870a098 RIP: [8040bfb8] dev_add_pack+0x48/0x90 PGD 203067 PUD 207063 PMD 7817f067 PTE 0 Oops: 0002 [1] PREEMPT SMP CPU 1 Modules linked in: econet [mny] Pid: 10671, comm: modprobe Not tainted 2.6.23-rc3-bloat #6 RIP: 0010:[8040bfb8] [8040bfb8] dev_add_pack+0x48/0x90 RSP: :810076293df8 EFLAGS: 00010202 RAX: 88659090 RBX: 88659060 RCX: 8870a090 RDX: 0080 RSI: 805ec660 RDI: 810078ce4680 RBP: 810076293e08 R08: 0002 R09: R10: 8040bf88 R11: 0001 R12: 810076293e18 R13: 001b R14: 810076dd06b0 R15: 886590c0 FS: 2b96a525dae0() GS:81007e0e2138() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 8870a098 CR3: 7bb67000 CR4: 26e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 10671, threadinfo 810076292000, task 810078ce4680) Stack: 810076dd06b0 810076293e38 8865b180 0080 886590c0 810076dd01c8 810076293f78 8026723c 810076293e48 886590d8 Call Trace: [8865b180] :econet:econet_proto_init+0x180/0x1da [8026723c] sys_init_module+0x15c/0x19e0 [8020c13e] system_call+0x7e/0x83 Code: 48 89 41 08 48 89 82 e0 c5 5e 80 48 c7 c7 a0 08 5d 80 e8 f1 RIP [8040bfb8] dev_add_pack+0x48/0x90 RSP 810076293df8 CR2: 8870a098 Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- net/econet/af_econet.c |3 +++ 1 file changed, 3 insertions(+) --- a/net/econet/af_econet.c +++ b/net/econet/af_econet.c @@ -1146,6 +1146,9 @@ static void __exit econet_proto_exit(void) sock_release(udpsock); #endif unregister_netdevice_notifier(econet_netdev_notifier); +#ifdef CONFIG_ECONET_NATIVE + dev_remove_pack(econet_packet_type); +#endif sock_unregister(econet_family_ops.family); proto_unregister(econet_proto); } - 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] remove Documentation/networking/net-modules.txt
According to git, the only one who touched this file during the last 5 years was me when removing drivers... modinfo offers less ancient information. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- This patch has been sent on: - 23 Jul 2007 Documentation/networking/00-INDEX|2 Documentation/networking/net-modules.txt | 315 --- 2 files changed, 317 deletions(-) --- linux-2.6.22-rc6-mm1/Documentation/networking/00-INDEX.old 2007-07-23 20:28:51.0 +0200 +++ linux-2.6.22-rc6-mm1/Documentation/networking/00-INDEX 2007-07-23 20:28:59.0 +0200 @@ -80,8 +80,6 @@ - Behaviour of cards under Multicast ncsa-telnet - notes on how NCSA telnet (DOS) breaks with MTU discovery enabled. -net-modules.txt - - info and insmod parameters for all network driver modules. netdevices.txt - info on network device driver functions exported to the kernel. olympic.txt --- linux-2.6.22-rc6-mm1/Documentation/networking/net-modules.txt 2007-07-12 20:43:37.0 +0200 +++ /dev/null 2006-09-19 00:45:31.0 +0200 @@ -1,315 +0,0 @@ -Wed 2-Aug-95 [EMAIL PROTECTED] - - Linux network driver modules - - Do not mistake this for README.modules at the top-level - directory! That document tells about modules in general, while - this one tells only about network device driver modules. - - This is a potpourri of INSMOD-time(*) configuration options - (if such exists) and their default values of various modules - in the Linux network drivers collection. - - Some modules have also hidden (= non-documented) tunable values. - The choice of not documenting them is based on general belief, that - the less the user needs to know, the better. (There are things that - driver developers can use, others should not confuse themselves.) - - In many cases it is highly preferred that insmod:ing is done - ONLY with defining an explicit address for the card, AND BY - NOT USING AUTO-PROBING! - - Now most cards have some explicitly defined base address that they - are compiled with (to avoid auto-probing, among other things). - If that compiled value does not match your actual configuration, - do use the io=0xXXX -parameter for the insmod, and give there - a value matching your environment. - - If you are adventurous, you can ask the driver to autoprobe - by using the io=0 parameter, however it is a potentially dangerous - thing to do in a live system. (If you don't know where the - card is located, you can try autoprobing, and after possible - crash recovery, insmod with proper IO-address..) - - -- - (*) INSMOD-time means when you load module with - /sbin/insmod you can feed it optional parameters. - See man insmod. - -- - - - 8390 based Network Modules (Paul Gortmaker, Nov 12, 1995) - -- - -(Includes: smc-ultra, ne, wd, 3c503, hp, hp-plus, e2100 and ac3200) - -The 8390 series of network drivers now support multiple card systems without -reloading the same module multiple times (memory efficient!) This is done by -specifying multiple comma separated values, such as: - - insmod 3c503.o io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1 - -The above would have the one module controlling four 3c503 cards, with card 2 -and 4 using external transceivers. The insmod manual describes the usage -of comma separated value lists. - -It is *STRONGLY RECOMMENDED* that you supply io= instead of autoprobing. -If an io= argument is not supplied, then the ISA drivers will complain -about autoprobing being not recommended, and begrudgingly autoprobe for -a *SINGLE CARD ONLY* -- if you want to use multiple cards you *have* to -supply an io=0xNNN,0xQQQ,... argument. - -The ne module is an exception to the above. A NE2000 is essentially an -8390 chip, some bus glue and some RAM. Because of this, the ne probe is -more invasive than the rest, and so at boot we make sure the ne probe is -done last of all the 8390 cards (so that it won't trip over other 8390 based -cards) With modules we can't ensure that all other non-ne 8390 cards have -already been found. Because of this, the ne module REQUIRES an io=0xNNN -argument passed in via insmod. It will refuse to autoprobe. - -It is also worth noting that auto-IRQ probably isn't as reliable during -the flurry of interrupt activity on a running machine. Cards such as the -ne2000 that can't get the IRQ setting from an EEPROM or configuration -register are probably best supplied with an irq=M argument as well. - - --- -Card/Module List - Configurable Parameters and Default Values --- - -3c501.c: -
Re: [PATCH 6/24] make atomic_read() behave consistently on frv
On Tuesday 14 August 2007, Paul E. McKenney wrote: #define order(x) asm volatile( : +m (x)) There was something very similar discussed earlier in this thread, with quite a bit of debate as to exactly what the m flag should look like. I suggested something similar named ACCESS_ONCE in the context of RCU (http://lkml.org/lkml/2007/7/11/664): #define ACCESS_ONCE(x) (*(volatile typeof(x) *)(x)) The nice thing about this is that it works for both loads and stores. Not clear that order() above does this -- I get compiler errors when I try something like b = order(a) or order(a) = 1 using gcc 4.1.2. Well, it serves a different purpose: While your ACCESS_ONCE() macro is an lvalue, the order() macro is a statement that can be used in place of the barrier() macro. order() is the most lightweight barrier as it only enforces ordering on a single variable in the compiler, but does not have any side-effects visible to other threads, like the cache line access in ACCESS_ONCE has. Arnd - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] remove Documentation/networking/net-modules.txt
Adrian Bunk wrote: According to git, the only one who touched this file during the last 5 years was me when removing drivers... modinfo offers less ancient information. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- This patch has been sent on: - 23 Jul 2007 Documentation/networking/00-INDEX|2 Documentation/networking/net-modules.txt | 315 --- 2 files changed, 317 deletions(-) NAK, IMO it's still use for ancient drivers - 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: [3/4] 2.6.23-rc3: known regressions
Michal Piotrowski [EMAIL PROTECTED] : [...] Networking Subject : NETDEV WATCHDOG: eth0: transmit timed out References : http://lkml.org/lkml/2007/8/13/737 Last known good : ? Submitter : Karl Meyer [EMAIL PROTECTED] Caused-By : ? Handled-By : ? Handled-By : [EMAIL PROTECTED] Status : unknown Subject : Weird network problems with 2.6.23-rc2 References : http://lkml.org/lkml/2007/8/11/40 Last known good : ? Submitter : Shish [EMAIL PROTECTED] Caused-By : ? Handled-By : ? Status : unknown The PR does not give any driver nor hardware detail. :o/ Subject : BUG: when using 'brctl stp' References : http://lkml.org/lkml/2007/8/10/441 Last known good : 2.6.23-rc1 Submitter : Daniel K. [EMAIL PROTECTED] Caused-By : ? Handled-By : ? Handled-By : [EMAIL PROTECTED] Status : unknown Status : fix applied by David Miller -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] remove Documentation/networking/net-modules.txt
On Tue, Aug 14, 2007 at 06:04:01PM -0400, Jeff Garzik wrote: Adrian Bunk wrote: According to git, the only one who touched this file during the last 5 years was me when removing drivers... modinfo offers less ancient information. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- This patch has been sent on: - 23 Jul 2007 Documentation/networking/00-INDEX|2 Documentation/networking/net-modules.txt | 315 --- 2 files changed, 317 deletions(-) NAK, IMO it's still use for ancient drivers Is there any that lacks a MODULE_PARM_DESC()? If yes, shouln't we fix such drivers instead? Even for ancient drivers net-modules.txt is outdated and sometimes lists no longer existing or doesn't document more recent parameters. cu 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: [PATCH 0/24] make atomic_read() behave consistently across all architectures
On Thu, 9 Aug 2007, Chris Snook wrote: This patchset makes the behavior of atomic_read uniform by removing the volatile keyword from all atomic_t and atomic64_t definitions that currently have it, and instead explicitly casts the variable as volatile in atomic_read(). This leaves little room for creative optimization by the compiler, and is in keeping with the principles behind volatile considered harmful. volatile is generally harmful even in atomic_read(). Barriers control visibility and AFAICT things are fine. - 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 6/24] make atomic_read() behave consistently on frv
On Wed, Aug 15, 2007 at 12:01:54AM +0200, Arnd Bergmann wrote: On Tuesday 14 August 2007, Paul E. McKenney wrote: #define order(x) asm volatile( : +m (x)) There was something very similar discussed earlier in this thread, with quite a bit of debate as to exactly what the m flag should look like. I suggested something similar named ACCESS_ONCE in the context of RCU (http://lkml.org/lkml/2007/7/11/664): #define ACCESS_ONCE(x) (*(volatile typeof(x) *)(x)) The nice thing about this is that it works for both loads and stores. Not clear that order() above does this -- I get compiler errors when I try something like b = order(a) or order(a) = 1 using gcc 4.1.2. Well, it serves a different purpose: While your ACCESS_ONCE() macro is an lvalue, the order() macro is a statement that can be used in place of the barrier() macro. order() is the most lightweight barrier as it only enforces ordering on a single variable in the compiler, but does not have any side-effects visible to other threads, like the cache line access in ACCESS_ONCE has. ACCESS_ONCE() is indeed intended to be used when actually loading or storing the variable. That said, I must admit that it is not clear to me why you would want to add an extra order() rather than ACCESS_ONCE()ing one or both of the adjacent accesses to that same variable. So, what am I missing? Thanx, 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: [PATCH 0/24] make atomic_read() behave consistently across all architectures
Christoph Lameter wrote: On Thu, 9 Aug 2007, Chris Snook wrote: This patchset makes the behavior of atomic_read uniform by removing the volatile keyword from all atomic_t and atomic64_t definitions that currently have it, and instead explicitly casts the variable as volatile in atomic_read(). This leaves little room for creative optimization by the compiler, and is in keeping with the principles behind volatile considered harmful. volatile is generally harmful even in atomic_read(). Barriers control visibility and AFAICT things are fine. But barriers force a flush of *everything* in scope, which we generally don't want. On the other hand, we pretty much always want to flush atomic_* operations. One way or another, we should be restricting the volatile behavior to the thing that needs it. On most architectures, this patch set just moves that from the declaration, where it is considered harmful, to the use, where it is considered an occasional necessary evil. See the resubmitted patchset, which also puts a cast in the atomic[64]_set operations. -- Chris - 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/24] make atomic_read() behave consistently across all architectures
On Tue, 14 Aug 2007, Chris Snook wrote: But barriers force a flush of *everything* in scope, which we generally don't want. On the other hand, we pretty much always want to flush atomic_* operations. One way or another, we should be restricting the volatile behavior to the thing that needs it. On most architectures, this patch set just moves that from the declaration, where it is considered harmful, to the use, where it is considered an occasional necessary evil. Then we would need atomic_read() and atomic_read_volatile() atomic_read_volatile() would imply an object sized memory barrier before and after? - 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/24] make atomic_read() behave consistently across all architectures
On Tue, 14 Aug 2007, Christoph Lameter wrote: On Thu, 9 Aug 2007, Chris Snook wrote: This patchset makes the behavior of atomic_read uniform by removing the volatile keyword from all atomic_t and atomic64_t definitions that currently have it, and instead explicitly casts the variable as volatile in atomic_read(). This leaves little room for creative optimization by the compiler, and is in keeping with the principles behind volatile considered harmful. volatile is generally harmful even in atomic_read(). Barriers control visibility and AFAICT things are fine. Frankly, I don't see the need for this series myself either. Personal opinion (others may differ), but I consider volatile to be a sad / unfortunate wart in C (numerous threads on this list and on the gcc lists/bugzilla over the years stand testimony to this) and if we _can_ steer clear of it, then why not -- why use this ill-defined primitive whose implementation has often differed over compiler versions and platforms? Granted, barrier() _is_ heavy-handed in that it makes the optimizer forget _everything_, but then somebody did post a forget() macro on this thread itself ... [ BTW, why do we want the compiler to not optimize atomic_read()'s in the first place? Atomic ops guarantee atomicity, which has nothing to do with volatility -- users that expect volatility from atomic ops are the ones who must be fixed instead, IMHO. ] - 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/24] make atomic_read() behave consistently across all architectures
Satyam Sharma wrote: On Tue, 14 Aug 2007, Christoph Lameter wrote: On Thu, 9 Aug 2007, Chris Snook wrote: This patchset makes the behavior of atomic_read uniform by removing the volatile keyword from all atomic_t and atomic64_t definitions that currently have it, and instead explicitly casts the variable as volatile in atomic_read(). This leaves little room for creative optimization by the compiler, and is in keeping with the principles behind volatile considered harmful. volatile is generally harmful even in atomic_read(). Barriers control visibility and AFAICT things are fine. Frankly, I don't see the need for this series myself either. Personal opinion (others may differ), but I consider volatile to be a sad / unfortunate wart in C (numerous threads on this list and on the gcc lists/bugzilla over the years stand testimony to this) and if we _can_ steer clear of it, then why not -- why use this ill-defined primitive whose implementation has often differed over compiler versions and platforms? Granted, barrier() _is_ heavy-handed in that it makes the optimizer forget _everything_, but then somebody did post a forget() macro on this thread itself ... [ BTW, why do we want the compiler to not optimize atomic_read()'s in the first place? Atomic ops guarantee atomicity, which has nothing to do with volatility -- users that expect volatility from atomic ops are the ones who must be fixed instead, IMHO. ] Because atomic operations are generally used for synchronization, which requires volatile behavior. Most such codepaths currently use an inefficient barrier(). Some forget to and we get bugs, because people assume that atomic_read() actually reads something, and atomic_write() actually writes something. Worse, these are architecture-specific, even compiler version-specific bugs that are often difficult to track down. -- Chris - 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] pcnet32: add suspend and resume capability
Add suspend and resume capability to the driver.
Tested both to ram and to disk on x86_64 platform.
Signed-off-by: Don Fry [EMAIL PROTECTED]
---
--- linux-2.6.23-rc3/drivers/net/pcnet32.c.orig 2007-08-14 13:52:24.0
-0700
+++ linux-2.6.23-rc3/drivers/net/pcnet32.c 2007-08-14 14:16:55.0
-0700
@@ -23,11 +23,11 @@
#define DRV_NAME pcnet32
#ifdef CONFIG_PCNET32_NAPI
-#define DRV_VERSION1.33-NAPI
+#define DRV_VERSION1.34-NAPI
#else
-#define DRV_VERSION1.33
+#define DRV_VERSION1.34
#endif
-#define DRV_RELDATE27.Jun.2006
+#define DRV_RELDATE14.Aug.2007
#define PFXDRV_NAME :
static const char *const version =
@@ -2943,6 +2943,33 @@ static void pcnet32_watchdog(struct net_
mod_timer((lp-watchdog_timer), PCNET32_WATCHDOG_TIMEOUT);
}
+static int pcnet32_pm_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+
+ if (netif_running(dev)) {
+ netif_device_detach(dev);
+ pcnet32_close(dev);
+ }
+ pci_save_state(pdev);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
+ return 0;
+}
+
+static int pcnet32_pm_resume(struct pci_dev *pdev)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+
+ if (netif_running(dev)) {
+ pcnet32_open(dev);
+ netif_device_attach(dev);
+ }
+ return 0;
+}
+
static void __devexit pcnet32_remove_one(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
@@ -2966,6 +2993,8 @@ static struct pci_driver pcnet32_driver
.probe = pcnet32_probe_pci,
.remove = __devexit_p(pcnet32_remove_one),
.id_table = pcnet32_pci_tbl,
+ .suspend = pcnet32_pm_suspend,
+ .resume = pcnet32_pm_resume,
};
/* An additional parameter that may be passed in... */
-
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/24] make atomic_read() behave consistently across all architectures
On Tue, 14 Aug 2007, Chris Snook wrote: Because atomic operations are generally used for synchronization, which requires volatile behavior. Most such codepaths currently use an inefficient barrier(). Some forget to and we get bugs, because people assume that atomic_read() actually reads something, and atomic_write() actually writes something. Worse, these are architecture-specific, even compiler version-specific bugs that are often difficult to track down. Looks like we need to have lock and unlock semantics? atomic_read() which has no barrier or volatile implications. atomic_read_for_lock Acquire semantics? atomic_read_for_unlock Release semantics? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/13] cxgb3 - Update rx coalescing length
Jeff Garzik wrote:
Divy Le Ray wrote:
From: Divy Le Ray [EMAIL PROTECTED]
Set max Rx coalescing length to 12288
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/common.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index c46c249..55922ed 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -104,7 +104,7 @@ enum {
PROTO_SRAM_LINES = 128, /* size of TP sram */
};
-#define MAX_RX_COALESCING_LEN 16224U
+#define MAX_RX_COALESCING_LEN 12288U
neither the patch nor description explains -why-
We're seeing back pressure from PCIe with large bursts, this patch
allows to cut down on the burst size.
Divy
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/13] cxgb3 - use immediate data for offload Tx
Jeff Garzik wrote: Divy Le Ray wrote: From: Divy Le Ray [EMAIL PROTECTED] Send small TX_DATA work requests as immediate data even when there are fragments. Signed-off-by: Divy Le Ray [EMAIL PROTECTED] --- drivers/net/cxgb3/sge.c | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) needs additional explanation. don't just describe the new post-change behavior, describe why this change is needed. It's an optimization avoiding doing multiple DMAs for small fragmented packets. The driver already implements this optimization for small contiguous packets. Divy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
On Wed, Aug 15, 2007 at 04:38:54AM +0530, Satyam Sharma wrote: On Tue, 14 Aug 2007, Christoph Lameter wrote: On Thu, 9 Aug 2007, Chris Snook wrote: This patchset makes the behavior of atomic_read uniform by removing the volatile keyword from all atomic_t and atomic64_t definitions that currently have it, and instead explicitly casts the variable as volatile in atomic_read(). This leaves little room for creative optimization by the compiler, and is in keeping with the principles behind volatile considered harmful. volatile is generally harmful even in atomic_read(). Barriers control visibility and AFAICT things are fine. Frankly, I don't see the need for this series myself either. Personal opinion (others may differ), but I consider volatile to be a sad / unfortunate wart in C (numerous threads on this list and on the gcc lists/bugzilla over the years stand testimony to this) and if we _can_ steer clear of it, then why not -- why use this ill-defined primitive whose implementation has often differed over compiler versions and platforms? Granted, barrier() _is_ heavy-handed in that it makes the optimizer forget _everything_, but then somebody did post a forget() macro on this thread itself ... [ BTW, why do we want the compiler to not optimize atomic_read()'s in the first place? Atomic ops guarantee atomicity, which has nothing to do with volatility -- users that expect volatility from atomic ops are the ones who must be fixed instead, IMHO. ] Interactions between mainline code and interrupt/NMI handlers on the same CPU (for example, when both are using per-CPU variables. See examples previously posted in this thread, or look at the rcu_read_lock() and rcu_read_unlock() implementations in http://lkml.org/lkml/2007/8/7/280. Thanx, 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: [PATCH 5/13] cxgb3 - Expose HW memory page info
Jeff Garzik wrote: Divy Le Ray wrote: From: Divy Le Ray [EMAIL PROTECTED] Let the RDMA driver get HW page info to work around HW issues. Assign explicit enum values. Signed-off-by: Divy Le Ray [EMAIL PROTECTED] HW issues -- you need to go into far more detail, when adding a new interface. what hw issues? why was this the best/only solution? A HW issue requires limiting the receive window size to 23 pages of internal memory. These pages can be configured to different sizes, thus the RDMA driver needs to know the page size to enforce the upper limit. Divy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/13] cxgb3 - Update internal memory management
Jeff Garzik wrote: Divy Le Ray wrote: From: Divy Le Ray [EMAIL PROTECTED] Set PM1 internal memory to round robin mode Signed-off-by: Divy Le Ray [EMAIL PROTECTED] why? For multiport adapters, it balances access to this internal memory. Divy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] econet: remove econet_packet_type on unload
From: Alexey Dobriyan [EMAIL PROTECTED] Date: Wed, 15 Aug 2007 01:25:53 +0400 Steps to reproduce: modprobe econet rmmod econet modprobe econet Unable to handle kernel paging request at 8870a098 RIP: [8040bfb8] dev_add_pack+0x48/0x90 ... Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] Patch applied, thanks a lot Alexey. - 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] ax25: don't free pointers to statically allocated data
From: Alexey Dobriyan [EMAIL PROTECTED] Date: Tue, 14 Aug 2007 23:30:38 +0400 commit 8d5cf596d10d740b69b5f4bbdb54b85abf75810d started to add statically allocated ax25_protocol's to list. However kfree() was still in place waiting for unsuspecting ones on module removal. Steps to reproduce: modprobe netrom rmmod netrom P.S.: code would benefit greatly from list_add/list_del usage kernel BUG at mm/slab.c:592! invalid opcode: [1] PREEMPT SMP ... Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] Also applied, thanks a lot. - 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] IOAT: Fix ioatdma descriptor cache miss
From: Nelson, Shannon [EMAIL PROTECTED] Date: Tue, 14 Aug 2007 14:20:02 -0700 The layout for struct ioat_desc_sw is non-optimal and causes an extra cache hit for every descriptor processed. By tightening up the struct layout and removing one item, we pull in the fields that get used in the speedpath and get a little better performance. ... Signed-off-by: Shannon Nelson [EMAIL PROTECTED] Patch applied, thanks. @@ -347,8 +347,7 @@ ioat_dma_prep_memcpy(struct dma_chan *chan, size_t len, int int_en) Your email client is wrapping long lines in patches, corrupting them. I fixed it up this time, but please take care of this in the future. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] unexport dev_ethtool
From: Matthew Wilcox [EMAIL PROTECTED] Date: Tue, 14 Aug 2007 15:23:26 -0600 On Tue, Aug 14, 2007 at 11:22:03PM +0200, Adrian Bunk wrote: This patch removes the no longer used EXPORT_SYMBOL(dev_ethtool). Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: Matthew Wilcox [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] net/8021q/vlanproc.c: fix check-after-use
From: Adrian Bunk [EMAIL PROTECTED] Date: Tue, 14 Aug 2007 23:22:44 +0200 The Coverity checker spotted that we'd have already oops'ed if vlandev was NULL. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Fair enough, applied, thanks Adrian. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Please pull 'fixes-davem' branch of wireless-2.6
These are a few more items intended for 2.6.23.
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-davem
Thanks!
John
---
The following changes since commit 39d3520c92cf7a28c07229ca00cc35a1e8026c77:
Linus Torvalds (1):
Linux 2.6.23-rc3
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
fixes-davem
Johannes Berg (1):
mac80211: fix tx status frame code
John W. Linville (1):
mac80211: probe for hidden SSIDs in pre-auth scan
net/mac80211/ieee80211.c |1 -
net/mac80211/ieee80211_sta.c |6 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index 8ec5ed1..7286c38 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -4678,7 +4678,6 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct
sk_buff *skb,
memset(skb-cb, 0, sizeof(skb-cb));
netif_rx(skb);
skb = skb2;
- break;
}
}
out:
diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index 7ba352e..0d99b68 100644
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -2154,7 +2154,11 @@ static int ieee80211_sta_config_auth(struct net_device
*dev,
return 0;
} else {
if (ifsta-state != IEEE80211_AUTHENTICATE) {
- ieee80211_sta_start_scan(dev, NULL, 0);
+ if (ifsta-auto_ssid_sel)
+ ieee80211_sta_start_scan(dev, NULL, 0);
+ else
+ ieee80211_sta_start_scan(dev, ifsta-ssid,
+ifsta-ssid_len);
ifsta-state = IEEE80211_AUTHENTICATE;
set_bit(IEEE80211_STA_REQ_AUTH, ifsta-request);
} else
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please pull 'upstream-davem' branch of wireless-2.6
More items intended for 2.6.24, based-off the preceding fixes-davem
request.
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem
Thanks!
John
---
The following changes since commit b9bf1e60a294fc7795d5198f94a917290e52865b:
John W. Linville (1):
mac80211: probe for hidden SSIDs in pre-auth scan
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-davem
Johannes Berg (1):
radiotap parser: accept all other fields
Larry Finger (1):
mac80211: Add SIOCGIWTXPOWER routine
net/mac80211/ieee80211_ioctl.c | 16 +++-
net/wireless/radiotap.c|6 +-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
index e7904db..f459d89 100644
--- a/net/mac80211/ieee80211_ioctl.c
+++ b/net/mac80211/ieee80211_ioctl.c
@@ -798,6 +798,20 @@ static int ieee80211_ioctl_giwrate(struct net_device *dev,
return 0;
}
+static int ieee80211_ioctl_giwtxpower(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *data, char *extra)
+{
+ struct ieee80211_local *local = wdev_priv(dev-ieee80211_ptr);
+
+ data-txpower.fixed = 1;
+ data-txpower.disabled = !(local-hw.conf.radio_enabled);
+ data-txpower.value = local-hw.conf.power_level;
+ data-txpower.flags = IW_TXPOW_DBM;
+
+ return 0;
+}
+
static int ieee80211_ioctl_siwrts(struct net_device *dev,
struct iw_request_info *info,
struct iw_param *rts, char *extra)
@@ -1580,7 +1594,7 @@ static const iw_handler ieee80211_handler[] =
(iw_handler) ieee80211_ioctl_siwfrag, /* SIOCSIWFRAG */
(iw_handler) ieee80211_ioctl_giwfrag, /* SIOCGIWFRAG */
(iw_handler) NULL, /* SIOCSIWTXPOW */
- (iw_handler) NULL, /* SIOCGIWTXPOW */
+ (iw_handler) ieee80211_ioctl_giwtxpower,/* SIOCGIWTXPOW */
(iw_handler) ieee80211_ioctl_siwretry, /* SIOCSIWRETRY */
(iw_handler) ieee80211_ioctl_giwretry, /* SIOCGIWRETRY */
(iw_handler) ieee80211_ioctl_siwencode, /* SIOCSIWENCODE */
diff --git a/net/wireless/radiotap.c b/net/wireless/radiotap.c
index 68c11d0..28fbd0b 100644
--- a/net/wireless/radiotap.c
+++ b/net/wireless/radiotap.c
@@ -161,7 +161,11 @@ int ieee80211_radiotap_iterator_next(
[IEEE80211_RADIOTAP_DBM_TX_POWER] = 0x11,
[IEEE80211_RADIOTAP_ANTENNA] = 0x11,
[IEEE80211_RADIOTAP_DB_ANTSIGNAL] = 0x11,
- [IEEE80211_RADIOTAP_DB_ANTNOISE] = 0x11
+ [IEEE80211_RADIOTAP_DB_ANTNOISE] = 0x11,
+ [IEEE80211_RADIOTAP_RX_FLAGS] = 0x22,
+ [IEEE80211_RADIOTAP_TX_FLAGS] = 0x22,
+ [IEEE80211_RADIOTAP_RTS_RETRIES] = 0x11,
+ [IEEE80211_RADIOTAP_DATA_RETRIES] = 0x11,
/*
* add more here as they are defined in
* include/net/ieee80211_radiotap.h
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please pull 'upstream-jgarzik' branch of wireless-2.6
A few items intended for 2.6.24.
Individual patches here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-jgarzik/
Thanks!
John
---
The following changes since commit 39d3520c92cf7a28c07229ca00cc35a1e8026c77:
Linus Torvalds (1):
Linux 2.6.23-rc3
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-jgarzik
Daniel Drake (2):
zd1211rw: Add ID for Sitecom WL-162
zd1211rw: Add ID for ZyXEL M-202 XtremeMIMO
Mariusz Kozlowski (1):
drivers/net/wireless/wl3501_cs.c: remove redundant memset
Ulrich Kunitz (2):
zd1211rw: removed noisy debug messages
zd1211rw: consistent handling of ZD1211 specific rates
drivers/net/wireless/wl3501_cs.c |1 -
drivers/net/wireless/zd1211rw/zd_chip.c | 69 +++---
drivers/net/wireless/zd1211rw/zd_ieee80211.h | 43 +++
drivers/net/wireless/zd1211rw/zd_mac.c | 99 +++---
drivers/net/wireless/zd1211rw/zd_mac.h | 65 +++--
drivers/net/wireless/zd1211rw/zd_usb.c |2 +
6 files changed, 128 insertions(+), 151 deletions(-)
diff --git a/drivers/net/wireless/wl3501_cs.c b/drivers/net/wireless/wl3501_cs.c
index c8b5c22..62b8669 100644
--- a/drivers/net/wireless/wl3501_cs.c
+++ b/drivers/net/wireless/wl3501_cs.c
@@ -1841,7 +1841,6 @@ static int wl3501_get_encode(struct net_device *dev,
tocopy = min_t(u8, len_keys, wrqu-encoding.length);
tocopy = min_t(u8, tocopy, 100);
wrqu-encoding.length = tocopy;
- memset(extra, 0, tocopy);
memcpy(extra, keys, tocopy);
out:
return rc;
diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c
b/drivers/net/wireless/zd1211rw/zd_chip.c
index c39f198..4959042 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.c
+++ b/drivers/net/wireless/zd1211rw/zd_chip.c
@@ -500,8 +500,6 @@ int zd_chip_lock_phy_regs(struct zd_chip *chip)
return r;
}
- dev_dbg_f(zd_chip_dev(chip),
- CR_REG1: 0x%02x - 0x%02x\n, tmp, tmp ~UNLOCK_PHY_REGS);
tmp = ~UNLOCK_PHY_REGS;
r = zd_iowrite32_locked(chip, tmp, CR_REG1);
@@ -523,8 +521,6 @@ int zd_chip_unlock_phy_regs(struct zd_chip *chip)
return r;
}
- dev_dbg_f(zd_chip_dev(chip),
- CR_REG1: 0x%02x - 0x%02x\n, tmp, tmp | UNLOCK_PHY_REGS);
tmp |= UNLOCK_PHY_REGS;
r = zd_iowrite32_locked(chip, tmp, CR_REG1);
@@ -841,8 +837,6 @@ static int get_aw_pt_bi(struct zd_chip *chip, struct
aw_pt_bi *s)
s-atim_wnd_period = values[0];
s-pre_tbtt = values[1];
s-beacon_interval = values[2];
- dev_dbg_f(zd_chip_dev(chip), aw %u pt %u bi %u\n,
- s-atim_wnd_period, s-pre_tbtt, s-beacon_interval);
return 0;
}
@@ -864,9 +858,6 @@ static int set_aw_pt_bi(struct zd_chip *chip, struct
aw_pt_bi *s)
reqs[2].addr = CR_BCN_INTERVAL;
reqs[2].value = s-beacon_interval;
- dev_dbg_f(zd_chip_dev(chip),
- aw %u pt %u bi %u\n, s-atim_wnd_period, s-pre_tbtt,
- s-beacon_interval);
return zd_iowrite32a_locked(chip, reqs, ARRAY_SIZE(reqs));
}
@@ -1018,19 +1009,19 @@ int zd_chip_set_rts_cts_rate_locked(struct zd_chip
*chip,
u32 value = 0;
/* Modulation bit */
- if (ZD_CS_TYPE(rts_rate) == ZD_CS_OFDM)
+ if (ZD_MODULATION_TYPE(rts_rate) == ZD_OFDM)
rts_mod = ZD_RX_OFDM;
dev_dbg_f(zd_chip_dev(chip), rts_rate=%x preamble=%x\n,
rts_rate, preamble);
- value |= rts_rate RTSCTS_SH_RTS_RATE;
+ value |= ZD_PURE_RATE(rts_rate) RTSCTS_SH_RTS_RATE;
value |= rts_mod RTSCTS_SH_RTS_MOD_TYPE;
value |= preamble RTSCTS_SH_RTS_PMB_TYPE;
value |= preamble RTSCTS_SH_CTS_PMB_TYPE;
/* We always send 11M self-CTS messages, like the vendor driver. */
- value |= ZD_CCK_RATE_11M RTSCTS_SH_CTS_RATE;
+ value |= ZD_PURE_RATE(ZD_CCK_RATE_11M) RTSCTS_SH_CTS_RATE;
value |= ZD_RX_CCK RTSCTS_SH_CTS_MOD_TYPE;
return zd_iowrite32_locked(chip, value, CR_RTS_CTS_RATE);
@@ -1160,16 +1151,12 @@ out:
static int update_pwr_int(struct zd_chip *chip, u8 channel)
{
u8 value = chip-pwr_int_values[channel - 1];
- dev_dbg_f(zd_chip_dev(chip), channel %d pwr_int %#04x\n,
-channel, value);
return zd_iowrite16_locked(chip, value, CR31);
}
static int update_pwr_cal(struct zd_chip *chip, u8 channel)
{
u8 value = chip-pwr_cal_values[channel-1];
- dev_dbg_f(zd_chip_dev(chip), channel %d pwr_cal %#04x\n,
-channel, value);
return zd_iowrite16_locked(chip, value, CR68);
}
@@ -1184,9 +1171,6 @@ static int update_ofdm_cal(struct zd_chip *chip, u8
channel)
ioreqs[2].addr = CR65;
ioreqs[2].value =
Re: [RFC: -mm patch] improve the SSB dependencies
On Mon, Aug 13, 2007 at 12:44:02AM +0200, Adrian Bunk wrote: On Sun, Aug 12, 2007 at 02:00:26PM +0200, Michael Buesch wrote: Ok, I'll give it a try, with small modifications. Thanks. On Sunday 12 August 2007, Adrian Bunk wrote: Additional changes in this patch: - small help text changes - B44_PCI is no longer usr visible (automatically enabled when possible) I think we want that to be selectable, as it's not needed on some embedded devices. And we need to save memory there. ... Makes sense, but then: config B44_PCI bool Broadcom 440x PCI device support if EMBEDDED ... default y ... I don't care about how many options we present if CONFIG_EMBEDDED=y, but for the normal CONFIG_EMBEDDED=n case we should not bother the user with this option. Was all this resolved? Was there another patch? If so, I missed it... John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'fixes-davem' branch of wireless-2.6
From: John W. Linville [EMAIL PROTECTED] Date: Tue, 14 Aug 2007 20:32:34 -0400 These are a few more items intended for 2.6.23. ... The following changes since commit 39d3520c92cf7a28c07229ca00cc35a1e8026c77: Linus Torvalds (1): Linux 2.6.23-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-davem Johannes Berg (1): mac80211: fix tx status frame code John W. Linville (1): mac80211: probe for hidden SSIDs in pre-auth scan Pulled, thanks John. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] bonding: eliminate RTNL assertion spew
Andy,
Is there an updated version of this patch?
Please advise, thanks.
On 1/10/07, Andy Gospodarek [EMAIL PROTECTED] wrote:
On Tue, Jan 09, 2007 at 03:09:35PM -0800, Stephen Hemminger wrote:
On Tue, 9 Jan 2007 17:59:01 -0500
Andy Gospodarek [EMAIL PROTECTED] wrote:
These changes eliminate the messages indicating that the rtnetlink lock
isn't held when bonding tries to change the MAC address of an interface.
These calls generally come from timer-pops, but also from sysfs events
since neither hold the rtnl lock.
The spew generally looks something like this:
RTNL: assertion failed at net/core/fib_rules.c (391)
[c028d12e] fib_rules_event+0x3a/0xeb
[c02da576] notifier_call_chain+0x19/0x29
[c0280ce6] dev_set_mac_address+0x46/0x4b
[f8a2a686] alb_set_slave_mac_addr+0x5d/0x88 [bonding]
[f8a2aa7e] alb_swap_mac_addr+0x88/0x134 [bonding]
[f8a25ed9] bond_change_active_slave+0x1a1/0x2c5 [bonding]
[f8a262e8] bond_select_active_slave+0xa8/0xe1 [bonding]
[f8a27ecb] bond_mii_monitor+0x3af/0x3fd [bonding]
[c0121896] run_workqueue+0x85/0xc5
[f8a27b1c] bond_mii_monitor+0x0/0x3fd [bonding]
[c0121d83] worker_thread+0xe8/0x119
[c079] default_wake_function+0x0/0xc
[c0121c9b] worker_thread+0x0/0x119
[c0124099] kthread+0xad/0xd8
[c0123fec] kthread+0x0/0xd8
.
This patch was mostly inspired from parts of some potential bonding
updates Jay Vosburgh [EMAIL PROTECTED] and I discussed in December, so
he deserves most of the credit for the idea.
I've tested it on several systems and it works as I expect. Deadlocks
between the rtnl and global bond lock are avoided since we drop the
global bond lock before taking the rtnl lock.
This seems like the ugly way to do it. Couldn't you just change figure out
how to acquire RTNL first. It wouldn't hurt to acquire it in the monitor
routine even if you don't need it.
Conditional locking is a bad road to start down.
Stephen and Jeff,
Does this seem like a better alternative? Taking the rtnetlink lock
before the global bond luck should avoid deadlocks since it is done that
way throughout the bonding code. I didn't notice any immediate problems,
but it was by no means and exhaustive stress test.
Thanks,
-andy
Signed-off-by: Andy Gospodarek [EMAIL PROTECTED]
---
bond_main.c | 15 +++
bond_sysfs.c |6 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 6482aed..e324235 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2024,6 +2024,9 @@ void bond_mii_monitor(struct net_device
int delta_in_ticks;
int i;
+ /* grab rtnl lock before taking bond lock*/
+ rtnl_lock();
+
read_lock(bond-lock);
delta_in_ticks = (bond-params.miimon * HZ) / 1000;
@@ -2252,6 +2255,8 @@ re_arm:
}
out:
read_unlock(bond-lock);
+
+ rtnl_unlock();
}
@@ -2557,6 +2562,9 @@ void bond_loadbalance_arp_mon(struct net
int delta_in_ticks;
int i;
+ /* grab rtnl lock before taking bond lock*/
+ rtnl_lock();
+
read_lock(bond-lock);
delta_in_ticks = (bond-params.arp_interval * HZ) / 1000;
@@ -2663,6 +2671,8 @@ re_arm:
}
out:
read_unlock(bond-lock);
+
+ rtnl_unlock();
}
/*
@@ -2687,6 +2697,9 @@ void bond_activebackup_arp_mon(struct ne
int delta_in_ticks;
int i;
+ /* grab rtnl lock before taking bond lock*/
+ rtnl_lock();
+
read_lock(bond-lock);
delta_in_ticks = (bond-params.arp_interval * HZ) / 1000;
@@ -2911,6 +2924,8 @@ re_arm:
}
out:
read_unlock(bond-lock);
+
+ rtnl_unlock();
}
/*--
proc/seq_file---*/
diff --git a/drivers/net/bonding/bond_sysfs.c
b/drivers/net/bonding/bond_sysfs.c
index ced9ed8..d23057a 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -1028,6 +1028,8 @@ static ssize_t bonding_store_primary(str
struct slave *slave;
struct bonding *bond = to_bond(cd);
+ /* grab rtnl lock before taking bond lock*/
+ rtnl_lock();
write_lock_bh(bond-lock);
if (!USES_PRIMARY(bond-params.mode)) {
printk(KERN_INFO DRV_NAME
@@ -1063,6 +1065,7 @@ static ssize_t bonding_store_primary(str
}
out:
write_unlock_bh(bond-lock);
+ rtnl_unlock();
return count;
}
static CLASS_DEVICE_ATTR(primary, S_IRUGO | S_IWUSR, bonding_show_primary,
bonding_store_primary);
@@ -1134,6 +1137,8 @@ static ssize_t bonding_store_active_slav
struct slave *new_active = NULL;
struct bonding *bond = to_bond(cd);
+ /* grab rtnl lock before taking bond lock*/
+ rtnl_lock();
Re: [PATCH 1/1] bonding: eliminate RTNL assertion spew
On 8/14/07, Mike Snitzer [EMAIL PROTECTED] wrote: Andy, Is there an updated version of this patch? Please advise, thanks. Mike, There is a version that Jay and I have been testing and if you would like to help out, we could probably send you some patches. Jay has split the entire patch into smaller chunks, and we hope to post the entire thing quite soon (days not months). -andy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Realtek r8168 slow outbound transfer - potential fix/workaround
[EMAIL PROTECTED] wrote: Bruce, I settled on using ndelay(10) rather than udelay(25) in the end.. it's probably a bit safer less likely to cause problems with higher throughputs. Yes, I saw that you later recommended the change but opted to try it the way you tested first. When I was diagnosing the problem I used 2 machines. One machine was running Samba on linux (the 'problem' machine), and one was a windows XP machine. Likewise, tho I also tested vista. I used tcpdump to capture the traffic on the Samba machine, and used wireshark to capture the traffic on the windows machine. What i found was happening was that samba was attempting to send two packets to the windows machine in quick succession (ie. something in the order of a 1/10,000th or less of a second apart). Although both packets showed up in the tcpdump output from the linux machine, only the first packet appeared to be making it to the windows machine. Because the second packet was 'lost', it had to be retried after a delay and this is what was causing the abysmal performance. The reasoning behind my patch was that I figured the TxPoll register wasn't being given enough time to reset itself after sending the previous packet. I may or may not have been correct with that assumption, but as you noticed the delay does seem to make it behave a bit better. Disclaimer: I haven't seen the definition for that register so I'm just guessing here. I suppose the danger is that your fix may just be changing the timing around such that the time-dependent bug does not occur as readily, yet a bug remains. Does anyone have the programming spec for this chip from realtek, or are we all just forced to guess :)? I understand that Francios came up with a similar patch that he said also worked, and that he thought was a bit more robust than my method. I'd check with him on what the status of that particular patch is. Thanks, I don't see that patch in 2.6.23-rc3 but I'll try Francios' recommendations first and if that doesn't work I'll test out things with the shorter ndelay(). - 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
