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
[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_DP
Re: [PATCH] e1000: Add device IDs of new 82571 board variants
Auke Kok wrote: This patch adds support for 2 new board variants: - A Quad port fiber 82571 board - A blade version of the 82571 quad copper board Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- 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 4 files changed, 14 insertions(+), 0 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xen-netfront: remove dead code
Jeremy Fitzhardinge wrote: This patch removes some residual dead code left over from removing the "flip" receive mode. This patch doesn't change the generated output at all, since gcc already realized it was dead. This resolves the "regression" reported by Adrian. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Adrian Bunk <[EMAIL PROTECTED]> Cc: Michal Piotrowski <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xen-netfront: Avoid deref'ing skbafter it is potentially freed.
Jeremy Fitzhardinge wrote: xennet_tx_bug_gc can free the skb before we use it, so make sure we don't. Jeff, this is -rc material. Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/net/3c505: Convert to generic boolean
Richard Knutsson wrote: Convert to generic boolean Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]> --- Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64) Diffed against Linus' git-tree. Sent 2007-05-01, no replys applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers/net/tokenring/3c359.c
Surya Prabhakar N wrote: Hi, Replacing kmalloc with kzalloc and cleaning up memset in drivers/net/tokenring/3c359.c Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/net/tokenring: Convert to generic boolean
Richard Knutsson wrote: Convert to generic boolean Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]> --- Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64) Diffed against Linus' git-tree. Sent 2007-05-01, no replys applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 06/18] PCI-X/PCI-Express read control interfaces: use them in myrinet
Jeff Garzik wrote: > [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. >> > > I presume Brice will resend this one to me, next time he pushes... Ok, I'll take care of it. Brice - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/13] cxgb3 - log and clear PEX errors
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Clear pciE PEX errors late at module load time. Log details when PEX errors occur. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/t3_hw.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) ACK 10-12 - 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 13/13] cxgb3 - test MSI capabilities
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Check that the HW in really in MSI/MSI-X mode when it was succesfully enabled. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/cxgb3_main.c | 42 drivers/net/cxgb3/regs.h |4 2 files changed, 46 insertions(+), 0 deletions(-) we really don't need to be adding this to each driver - 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
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? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/13] cxgb3 - log adapter derial number
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Log HW serial number when cxgb3 module is loaded. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/common.h |2 ++ drivers/net/cxgb3/cxgb3_main.c |6 -- drivers/net/cxgb3/t3_hw.c |3 ++- 3 files changed, 8 insertions(+), 3 deletions(-) ACK patches 6-8 - 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
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. - 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
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? - 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
Chris Snook wrote: David Howells 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. I'm not sure that actually answers my question. Why not smp_rmb()? David I would assume because we want to waste time efficiently even on non-smp architectures, rather than frying the CPU or draining the battery. Certain looping execution patterns can cause the CPU to operate above thermal design power. I have fans on my workstation that only ever come on when running LINPACK, and that's generally memory bandwidth-bound. Just imagine what happens when you're executing the same few non-serializing instructions in a tight loop without ever stalling on memory fetches, or being scheduled out. If there's another reason, I'd like to hear it too, because I'm just guessing here. Well if there is only one memory location involved, then smp_rmb() isn't going to really do anything anyway, so it would be incorrect to use it. Consider that smp_rmb basically will do anything from flushing the pipeline to invalidating loads speculatively executed out of order. AFAIK it will not control the visibility of stores coming from other CPUs (that is up to the cache coherency). -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/13] cxgb3 - SGE doorbell overflow warning
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Log doorbell Fifo overflow Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/regs.h |8 drivers/net/cxgb3/sge.c |4 2 files changed, 12 insertions(+), 0 deletions(-) ACK, but not applied since patch #2 was not applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/13] cxgb3 - Update rx coalescing length
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-
-
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
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.
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).
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))
--
SUSE Labs, Novell Inc.
-
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/13] cxgb3 - MAC workaround update
Divy Le Ray wrote: From: Divy Le Ray <[EMAIL PROTECTED]> Update the MAC workaround to deal with switches that do not honor pause frames. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/common.h |1 + drivers/net/cxgb3/xgmac.c | 22 +++--- 2 files changed, 12 insertions(+), 11 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 17/18] 3c59x: fix duplex configuration
[EMAIL PROTECTED] wrote: From: Steffen Klassert <[EMAIL PROTECTED]> A special sequence of ifconfig up/down and plug/unplug the cable can break the duplex configuration of the driver. Setting vp->mii.full_duplex = vp->full_duplex in vortex_up should fix this. Addresses Bug 8575 3c59x duplex configuration broken http://bugzilla.kernel.org/show_bug.cgi?id=8575 Cc: Martin Buck <[EMAIL PROTECTED]> Signed-off-by: Steffen Klassert <[EMAIL PROTECTED]> Cc: Natalie Protasevich <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/3c59x.c |1 + 1 files changed, 1 insertion(+) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 18/18] 3c59x maintainer
[EMAIL PROTECTED] wrote: From: Steffen Klassert <[EMAIL PROTECTED]> Add 3c59x maintainer. Signed-off-by: Steffen Klassert <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- MAINTAINERS |6 ++ 1 files changed, 6 insertions(+) diff -puN MAINTAINERS~add-3c59x-maintainer MAINTAINERS --- a/MAINTAINERS~add-3c59x-maintainer +++ a/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 applied thanks Steffen! - 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 13/18] natsemi: fix netdev error acounting
[EMAIL PROTECTED] wrote: From: Andrew Morton <[EMAIL PROTECTED]> When a detailed netdev error is counted, we also must account for it in the aggregated error count. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=8106 Cc: Tim Hockin <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Cc: Chongfeng Hu <[EMAIL PROTECTED]> Cc: Natalie Protasevich <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 15/18] drivers/net: remove superfluous memset
[EMAIL PROTECTED] wrote: From: Mariusz Kozlowski <[EMAIL PROTECTED]> This patch covers something like this: dev = alloc_*dev(... ... priv = netdev_priv(dev); memset(priv, 0, sizeof(*priv)); The memset() here is superfluous. alloc_netdev() uses kzalloc() to allocate needed memory so there is no need to zero the priv region twice. Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/fs_enet/fs_enet-main.c |1 - drivers/net/myri10ge/myri10ge.c |1 - drivers/net/netxen/netxen_nic_main.c |1 - drivers/net/sunlance.c |1 - drivers/net/usb/pegasus.c|1 - drivers/net/usb/rtl8150.c|1 - 6 files changed, 6 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 12/18] e1000: #if 0 two functions
[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
-
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 09/18] Clean up duplicate includes in drivers/net/
[EMAIL PROTECTED] wrote: From: Jesper Juhl <[EMAIL PROTECTED]> This patch cleans up duplicate includes in drivers/net/ Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> Acked-by: "John W. Linville" <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/atl1/atl1_main.c |1 - drivers/net/bfin_mac.c |5 - drivers/net/bonding/bond_sysfs.c |1 - drivers/net/fs_enet/fs_enet-main.c |2 -- drivers/net/gianfar.h |1 - drivers/net/gianfar_ethtool.c |1 - drivers/net/irda/kingsun-sir.c |1 - drivers/net/irda/mcs7780.c |1 - drivers/net/mipsnet.c |1 - drivers/net/netxen/netxen_nic_main.c |1 - drivers/net/qla3xxx.c |1 - drivers/net/tsi108_eth.c |1 - drivers/net/wireless/ipw2200.h |1 - drivers/net/wireless/zd1211rw/zd_def.h |1 - 14 files changed, 19 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 10/18] ax88796 printk fixes
[EMAIL PROTECTED] wrote: From: Andrew Morton <[EMAIL PROTECTED]> drivers/net/ax88796.c: In function `ax_probe': drivers/net/ax88796.c:825: warning: size_t format, different type arg (arg 4) drivers/net/ax88796.c:825: warning: size_t format, different type arg (arg 5) resource_size_t isn't size_t. Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/ax88796.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 08/18] 3c59x: check return of pci_enable_device()
[EMAIL PROTECTED] wrote:
From: Mark Hindley <[EMAIL PROTECTED]>
Check return of pci_enable_device in vortex_up().
Signed-off-by: Mark Hindley <[EMAIL PROTECTED]>
Acked-by: Steffen Klassert <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/3c59x.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff -puN drivers/net/3c59x.c~3c59x-check-return-of-pci_enable_device
drivers/net/3c59x.c
--- a/drivers/net/3c59x.c~3c59x-check-return-of-pci_enable_device
+++ a/drivers/net/3c59x.c
@@ -1490,13 +1490,17 @@ 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);
+ }
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
-
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 06/18] PCI-X/PCI-Express read control interfaces: use them in myrinet
[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: Roland Dreier <[EMAIL PROTECTED]> Cc: Brice Goglin <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/myri10ge/myri10ge.c |3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/net/myri10ge/myri10ge.c~pci-x-pci-express-read-control-interfaces-myrinet drivers/net/myri10ge/myri10ge.c --- a/drivers/net/myri10ge/myri10ge.c~pci-x-pci-express-read-control-interfaces-myrinet +++ a/drivers/net/myri10ge/myri10ge.c @@ -2884,8 +2884,7 @@ static int myri10ge_probe(struct pci_dev status); goto abort_with_netdev; } - val = (val & ~PCI_EXP_DEVCTL_READRQ) | (5 << 12); - status = pci_write_config_word(pdev, cap + PCI_EXP_DEVCTL, val); + status = pcie_set_readrq(pdev, 4096); I presume Brice will resend this one to me, next time he pushes... - 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] Use the pause counter to avoid a needless device reset
Brice Goglin wrote: Use the pause counter to avoid a needless device reset, and print a message telling the admin that our link partner is flow controlling us down to 0 pkts/sec. Signed-off-by: Brice Goglin <[EMAIL PROTECTED]> --- drivers/net/myri10ge/myri10ge.c | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) applied please prefix your subject lines like this: [PATCH m/n] myri10ge: so that the automated tools (git-am from the git package) properly provide a one-line summary for your patch. for more info also see http://linux.yyz.us/patch-format.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 04/18] via-rhine: disable rx_copybreak on archs that don't allow unaligned DMA access
[EMAIL PROTECTED] wrote: From: Dustin Marquess <[EMAIL PROTECTED]> Patch to disable the rx_copybreak feature on hardware architectures that don't allow unaligned DMA access. #ifdef code taken from tulip_core.c. Problem pointed out by Ivan Kokshaysky. Signed-off-by: Dustin Marquess <[EMAIL PROTECTED]> Cc: Francois Romieu <[EMAIL PROTECTED]> Cc: Ivan Kokshaysky <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/via-rhine.c |6 ++ 1 files changed, 6 insertions(+) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 03/18] drivers/net/ns83820.c: add paramter to disable autonegotiation
applied the ethtool part of this - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] e1000e: error handling for pci_map_single calls.
Auke Kok wrote:
index d14cc4b..0e80406 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -1042,6 +1044,10 @@ static int e1000_setup_desc_rings(struct e1000_adapter
*adapter)
tx_ring->buffer_info[i].dma =
pci_map_single(pdev, skb->data, skb->len,
PCI_DMA_TODEVICE);
+ if (pci_dma_mapping_error(tx_ring->buffer_info[i].dma)) {
+ ret_val = 4;
+ goto err_nomem;
+ }
tx_desc->buffer_addr = cpu_to_le64(
tx_ring->buffer_info[i].dma);
tx_desc->lower.data = cpu_to_le32(skb->len);
@@ -1059,7 +1065,7 @@ static int e1000_setup_desc_rings(struct e1000_adapter
*adapter)
size = rx_ring->count * sizeof(struct e1000_buffer);
rx_ring->buffer_info = kmalloc(size, GFP_KERNEL);
if (!rx_ring->buffer_info) {
- ret_val = 4;
+ ret_val = 5;
goto err_nomem;
}
memset(rx_ring->buffer_info, 0, size);
@@ -1068,7 +1074,7 @@ static int e1000_setup_desc_rings(struct e1000_adapter
*adapter)
rx_ring->desc = dma_alloc_coherent(&pdev->dev, rx_ring->size,
&rx_ring->dma, GFP_KERNEL);
if (!rx_ring->desc) {
- ret_val = 5;
+ ret_val = 6;
goto err_nomem;
}
memset(rx_ring->desc, 0, rx_ring->size);
@@ -1093,7 +1099,7 @@ static int e1000_setup_desc_rings(struct e1000_adapter
*adapter)
skb = alloc_skb(2048 + NET_IP_ALIGN, GFP_KERNEL);
if (!skb) {
- ret_val = 6;
+ ret_val = 7;
goto err_nomem;
}
skb_reserve(skb, NET_IP_ALIGN);
@@ -1101,6 +1107,10 @@ static int e1000_setup_desc_rings(struct e1000_adapter
*adapter)
rx_ring->buffer_info[i].dma =
pci_map_single(pdev, skb->data, 2048,
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(rx_ring->buffer_info[i].dma)) {
+ ret_val = 8;
+ goto err_nomem;
+ }
rx_desc->buffer_addr =
cpu_to_le64(rx_ring->buffer_info[i].dma);
memset(skb->data, 0x00, skb->len);
this function is a bit fragile if two additional error checks cause a
'ret_val' ripple effect throughout the function.
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 51c9024..8ebe238 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -195,6 +195,11 @@ map_skb:
buffer_info->dma = pci_map_single(pdev, skb->data,
adapter->rx_buffer_len,
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(buffer_info->dma)) {
+ dev_err(&pdev->dev, "RX DMA map failed\n");
+ adapter->rx_dma_failed++;
+ break;
+ }
rx_desc = E1000_RX_DESC(*rx_ring, i);
rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma);
@@ -255,6 +260,13 @@ static void e1000_alloc_rx_buffers_ps(struct e1000_adapter
*adapter,
ps_page->page,
0, PAGE_SIZE,
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(
+ ps_page->dma)) {
+ dev_err(&adapter->pdev->dev,
+ "RX DMA page map failed\n");
+ adapter->rx_dma_failed++;
+ goto no_buffers;
+ }
}
/*
* Refresh the desc even if buffer_addrs
@@ -286,6 +298,14 @@ static void e1000_alloc_rx_buffers_ps(struct e1000_adapter
*adapter,
buffer_info->dma = pci_map_single(pdev, skb->data,
adapter->rx_ps_bsize0,
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(buffer_info->dma)) {
+ dev_err(&pdev->dev, "RX DMA map failed\n");
+ adapter->rx_dma_failed++;
+ /* cleanup skb */
+ dev_kfree_skb_any(skb);
+ buffer_info->skb = NULL;
+ break;
+ }
rx_desc->read.buffer_addr[0] = cpu_to_le6
Re: [PATCH 2/6] e1000e: remove namespace collisions with e1000
Auke Kok wrote: To prevent future collisions we rename all extern's from e1000_ to e1000e_*. The list of changed symbols was taken from e1000.h Compile tested with CONFIG_E1000=y and CONFIG_E1000E=y. Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000e/82571.c | 129 +- drivers/net/e1000e/e1000.h | 194 +++ drivers/net/e1000e/es2lan.c | 118 drivers/net/e1000e/ethtool.c | 62 ++-- drivers/net/e1000e/ich8lan.c | 92 +- drivers/net/e1000e/lib.c | 210 +- drivers/net/e1000e/netdev.c | 168 +- drivers/net/e1000e/param.c |8 +- drivers/net/e1000e/phy.c | 138 ++-- 9 files changed, 559 insertions(+), 560 deletions(-) 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. e1e_flush(), e1e_wphy(), etc. Overall I still want to push the driver towards shorter function and variable names. Things like e1000e_get_speed_and_duplex_fiber_serdes are just way too long. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] e1000e: Fix header includes [v2]
Auke Kok wrote: Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000e/82571.c |4 drivers/net/e1000e/e1000.h |7 --- drivers/net/e1000e/es2lan.c |5 + drivers/net/e1000e/ethtool.c |3 ++- drivers/net/e1000e/hw.h |2 ++ drivers/net/e1000e/ich8lan.c |5 + drivers/net/e1000e/lib.c |2 ++ drivers/net/e1000e/netdev.c |2 ++ drivers/net/e1000e/phy.c |2 ++ 9 files changed, 28 insertions(+), 4 deletions(-) applied 1-6, however, comments follow... - 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.24]S2io: Enhance device error/alarm handling
Ramkrishna Vepa wrote: - Added support to poll for entire set of device errors and alarms. - Optimized interrupt routine fast path. - Removed the unused variable, intr_type, in device private structure. Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]> Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]> please split this patch up into multiple patches. In general it's OK to combine several small, minor changes together, but this patch was pretty big. at that point, you need to start looking into splitting up patches into separate logical changes (intr_type clean in its own patch, irq handler optimization in its own patch, etc.). More patches means that each patch is smaller, making it easier to review. It also means that automated tools such as git-bisect can easily identify which change created a regression, should one appear. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/tulip/xircom_cb.c: remove superfulous priv assignment
Mariusz Kozlowski wrote:
Hello,
Unpatched version does sth like this:
dev = alloc_etherdev(...
private = netdev_priv(dev);
...
dev->priv = private;
which doesn't make much sense (does it?) because this is done in
alloc_netdev() already.
struct net_device *alloc_netdev(...
{
...
if (sizeof_priv)
dev->priv = netdev_priv(dev);
This patch removes superfluous code.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
applied
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.23 1/3]S2IO: Making MSIX as default intr_type
applied 1-3 to #upstream (2.6.23), but we'll want to look into why NAPI and MSI-X aren't playing well for you. especially look at NAPI changes in net-2.6.24. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] /drivers/net ucc_geth ioremap balancing/returncode check (resend)
resending patchset against 2.6.23-rc3 for /drivers/net ioremap balancing /
return check,
previous patchset contained wordwrap errors:
corrects:
--sbus_ioremap return unchecked.
--ioremap function unchecked
--function failure cases did not clean up ioremap'd values.
lne390.c -- believe had incorrect/not ideal variable check on if for iounmap
this audit was only for files directly in drivers/net directory, not the full
tree.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 12e01b2..30acbe2 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2430,6 +2430,11 @@ static int ucc_struct_init(struct ucc_geth_private
*ugeth)
ugeth->ug_regs = (struct ucc_geth *) ioremap(uf_info->regs,
sizeof(struct ucc_geth));
+ if (!ugeth->ug_regs){
+ ugeth_err("%s: Failed to ioremap.", __FUNCTION__);
+ return -ENOMEM;
+ }
+
return 0;
}
Choose the right car based on your needs. Check out Yahoo! Autos new Car
Finder tool.
http://autos.yahoo.com/carfinder/
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch]support for USB autosuspend in the asix driver
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. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] /drivers/net myri_sbus.c ioremap balancing/returncode check (resend)
resending patchset against 2.6.23-rc3 for /drivers/net ioremap balancing /
return check,
previous patchset contained wordwrap errors:
corrects:
--sbus_ioremap return unchecked.
--ioremap function unchecked
--function failure cases did not clean up ioremap'd values.
lne390.c -- believe had incorrect/not ideal variable check on if for iounmap
this audit was only for files directly in drivers/net directory, not the full
tree.
Signed-off-by: Scott Thompson hushmail.com>
--
diff --git a/drivers/net/myri_sbus.c b/drivers/net/myri_sbus.c
index 13444da..138aabd 100644
--- a/drivers/net/myri_sbus.c
+++ b/drivers/net/myri_sbus.c
@@ -1007,6 +1007,13 @@ static int __devinit myri_ether_init(struct sbus_dev
*sdev)
mp->lanai =
sbus_ioremap(&sdev->resource[0], (512 * 1024),
mp->eeprom.ramsz, "MyriCOM SRAM");
+
+
+ if (!mp->cregs || !mp->lregs || !mp->lanai ) {
+ printk("MyriCOM: Cannot map registers for ioremap
fail.\n");
+ goto err;
+ }
+
}
DET(("Registers mapped: cregs[%p] lregs[%p] lanai[%p]\n",
mp->cregs, mp->lregs, mp->lanai));
@@ -1108,6 +1115,16 @@ err_free_irq:
err:
/* This will also free the co-allocated 'dev->priv' */
free_netdev(dev);
+
+ if (mp->regs)
+ sbus_iounmap(mp->regs, mp->reg_size);
+ if (mp->cregs)
+ sbus_iounmap(mp->cregs, PAGE_SIZE);
+ if (mp->lregs)
+ sbus_iounmap(mp->lregs, (256 * 1024));
+ if (mp->lanai)
+ sbus_iounmap(mp->lanai, (512 * 1024));
+
return -ENODEV;
}
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
-
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/3] /drivers/net ioremap balancing/returncode check (resend)
resending patchset against 2.6.23-rc3 for /drivers/net ioremap balancing / return check, previous patchset contained wordwrap errors: corrects: --sbus_ioremap return unchecked. --ioremap function unchecked --function failure cases did not clean up ioremap'd values. lne390.c -- believe had incorrect/not ideal variable check on if for iounmap this audit was only for files directly in drivers/net directory, not the full tree. Signed-off-by: Scott Thompson hushmail.com> -- diff --git a/drivers/net/es3210.c b/drivers/net/es3210.c index 822e5bf..d7d6b90 100644 --- a/drivers/net/es3210.c +++ b/drivers/net/es3210.c @@ -307,6 +307,10 @@ out1: free_irq(dev->irq, dev); out: release_region(ioaddr + ES_SA_PROM, ES_IO_EXTENT); + + if (ei_status.mem) + iounmap(ei_status.mem); + return retval; } diff --git a/drivers/net/lne390.c b/drivers/net/lne390.c index 0a08d0c..f6d9fb6 100644 --- a/drivers/net/lne390.c +++ b/drivers/net/lne390.c @@ -290,7 +290,7 @@ static int __init lne390_probe1(struct net_device *dev, int ioaddr) goto unmap; return 0; unmap: - if (ei_status.reg0) + if (ei_status.mem) iounmap(ei_status.mem); cleanup: free_irq(dev->irq, dev); Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC - 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] drivers/net/3c505: Convert to generic boolean
Convert to generic boolean
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64)
Diffed against Linus' git-tree.
Sent 2007-05-01, no replys
diff --git a/drivers/net/3c505.c b/drivers/net/3c505.c
index e985a85..acede30 100644
--- a/drivers/net/3c505.c
+++ b/drivers/net/3c505.c
@@ -169,21 +169,6 @@ static int elp_debug;
/*
*
- * useful macros
- *
- */
-
-#ifndefTRUE
-#defineTRUE1
-#endif
-
-#ifndefFALSE
-#defineFALSE 0
-#endif
-
-
-/*
- *
* List of I/O-addresses we try to auto-sense
* Last element MUST BE 0!
*/
@@ -270,7 +255,7 @@ static inline void set_hsf(struct net_device *dev, int hsf)
spin_unlock_irqrestore(&adapter->lock, flags);
}
-static int start_receive(struct net_device *, pcb_struct *);
+static bool start_receive(struct net_device *, pcb_struct *);
static inline void adapter_reset(struct net_device *dev)
{
@@ -328,28 +313,28 @@ static inline void check_3c505_dma(struct net_device *dev)
}
/* Primitive functions used by send_pcb() */
-static inline unsigned int send_pcb_slow(unsigned int base_addr, unsigned char
byte)
+static inline bool send_pcb_slow(unsigned int base_addr, unsigned char byte)
{
unsigned long timeout;
outb_command(byte, base_addr);
for (timeout = jiffies + 5*HZ/100; time_before(jiffies, timeout);) {
if (inb_status(base_addr) & HCRE)
- return FALSE;
+ return false;
}
printk(KERN_WARNING "3c505: send_pcb_slow timed out\n");
- return TRUE;
+ return true;
}
-static inline unsigned int send_pcb_fast(unsigned int base_addr, unsigned char
byte)
+static inline bool send_pcb_fast(unsigned int base_addr, unsigned char byte)
{
unsigned int timeout;
outb_command(byte, base_addr);
for (timeout = 0; timeout < 4; timeout++) {
if (inb_status(base_addr) & HCRE)
- return FALSE;
+ return false;
}
printk(KERN_WARNING "3c505: send_pcb_fast timed out\n");
- return TRUE;
+ return true;
}
/* Check to see if the receiver needs restarting, and kick it if so */
@@ -386,7 +371,7 @@ static inline void prime_rx(struct net_device *dev)
* timeout is reduced to 500us).
*/
-static int send_pcb(struct net_device *dev, pcb_struct * pcb)
+static bool send_pcb(struct net_device *dev, pcb_struct * pcb)
{
int i;
unsigned long timeout;
@@ -396,14 +381,14 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
check_3c505_dma(dev);
if (adapter->dmaing && adapter->current_dma.direction == 0)
- return FALSE;
+ return false;
/* Avoid contention */
if (test_and_set_bit(1, &adapter->send_pcb_semaphore)) {
if (elp_debug >= 3) {
printk(KERN_DEBUG "%s: send_pcb entered while
threaded\n", dev->name);
}
- return FALSE;
+ return false;
}
/*
* load each byte into the command register and
@@ -435,7 +420,7 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
switch (GET_ASF(dev->base_addr)) {
case ASF_PCB_ACK:
adapter->send_pcb_semaphore = 0;
- return TRUE;
+ return true;
case ASF_PCB_NAK:
#ifdef ELP_DEBUG
@@ -453,7 +438,7 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
spin_unlock_irqrestore(&adapter->lock, flags);
abort:
adapter->send_pcb_semaphore = 0;
- return FALSE;
+ return false;
}
@@ -470,7 +455,7 @@ static int send_pcb(struct net_device *dev, pcb_struct *
pcb)
*
*/
-static int receive_pcb(struct net_device *dev, pcb_struct * pcb)
+static bool receive_pcb(struct net_device *dev, pcb_struct * pcb)
{
int i, j;
int total_length;
@@ -487,7 +472,7 @@ static int receive_pcb(struct net_device *dev, pcb_struct *
pcb)
while (((stat = get_status(dev->base_addr)) & ACRF) == 0 &&
time_before(jiffies, timeout));
if (time_after_eq(jiffies, timeout)) {
TIMEOUT_MSG(__LINE__);
- return FALSE;
+ return false;
}
pcb->command = inb_command(dev->base_addr);
@@ -497,14 +482,14 @@ static int receive_pcb(struct net_device *dev, pcb_struct
* pcb)
if (time_after_eq(jiffies, timeout)) {
TIMEOUT_MSG(__LINE__);
printk(KERN_INFO "%s: statu
[PATCH] drivers/net/tokenring: Convert to generic boolean
Convert to generic boolean
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested with all(yes|mod|no)config on x86(|_64) & sparc(|64)
Diffed against Linus' git-tree.
Sent 2007-05-01, no replys
diff --git a/drivers/net/tokenring/ibmtr.c b/drivers/net/tokenring/ibmtr.c
index 1e8958e..0c69eaa 100644
--- a/drivers/net/tokenring/ibmtr.c
+++ b/drivers/net/tokenring/ibmtr.c
@@ -116,9 +116,6 @@ in the event that chatty debug messages are desired - jjs
12/30/98 */
#define ENABLE_PAGING 1
#endif
-#define FALSE 0
-#define TRUE (!FALSE)
-
/* changes the output format of driver initialization */
#define TR_VERBOSE 0
@@ -1542,7 +1539,7 @@ static void initial_tok_int(struct net_device *dev)
ti->ring_speed = init_status & 0x01 ? 16 : 4;
DPRINTK("Initial interrupt : %d Mbps, shared RAM base %08x.\n",
ti->ring_speed, (unsigned int)dev->mem_start);
- ti->auto_speedsave=readb(ti->init_srb+INIT_STATUS_2_OFST)&4?TRUE:FALSE;
+ ti->auto_speedsave = (readb(ti->init_srb+INIT_STATUS_2_OFST) & 4) != 0;
if (ti->open_mode == MANUAL) wake_up(&ti->wait_for_reset);
elsetok_open_adapter((unsigned long)dev);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xen-netfront: Avoid deref'ing skbafter it is potentially freed.
On Monday 13 August 2007 21:54:37 Jeremy Fitzhardinge wrote: > xennet_tx_bug_gc can free the skb before we use it, so make sure we don't. > > Jeff, this is -rc material. > > Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> > Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> > Cc: Jeff Garzik <[EMAIL PROTECTED]> > > diff -r 8bfc43f6d1b0 drivers/net/xen-netfront.c > --- a/drivers/net/xen-netfront.c Tue Aug 07 14:26:30 2007 -0700 > +++ b/drivers/net/xen-netfront.c Mon Aug 13 09:39:15 2007 -0700 > @@ -566,15 +566,16 @@ static int xennet_start_xmit(struct sk_b > if (notify) > notify_remote_via_irq(np->netdev->irq); > > + np->stats.tx_bytes += skb->len; > + np->stats.tx_packets++; > + > + /* Note: It is not safe to access skb after xennet_tx_buf_gc()! */ > xennet_tx_buf_gc(dev); > > if (!netfront_tx_slot_available(np)) > netif_stop_queue(dev); > > spin_unlock_irq(&np->tx_lock); > - > - np->stats.tx_bytes += skb->len; > - np->stats.tx_packets++; > > return 0; > 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? Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/net/xen-netfront.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 489f69c..640e270 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -566,6 +566,9 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev) if (notify) notify_remote_via_irq(np->netdev->irq); + np->stats.tx_bytes += skb->len; + + /* Note: It is not safe to access skb after xennet_tx_buf_gc()! */ xennet_tx_buf_gc(dev); if (!netfront_tx_slot_available(np)) @@ -573,7 +576,6 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev) spin_unlock_irq(&np->tx_lock); - np->stats.tx_bytes += skb->len; np->stats.tx_packets++; 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: Problem with semantics?
Shay Goikhman <[EMAIL PROTECTED]> writes: > Dear Linux maintainers, > > I'm doing : > > setsockopt(s, SO_RCVTIMEO, t1 ); // set time-out > t1 on socket while block receiving on it > select(,,, &fd_set_including(s), .., &errs, t2); // block till > receive or time-out t 2 jointly on a set of sockets > > Apparently, I could no find reference on the coupled behavior of the two > above statements in Linux documentation. > As I understand the blocking semantics, I would expect that if t1 select should return after t1 with the descriptor 's' in 'errs' if 's' does > not become readable in the t1 interval. > > It is not so in life -- select ignores t1 altogether. > > Do you have some enlightening knowledge on the matter? RCVTIMEO only applies to recvmsg et.al., similar to SNDTIMEO only apply to sendmsg etc. But select/poll only report events, they do not actually send or receive by themselves. Michael, perhaps you can clarify that in the manpages -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Distributed storage.
On Monday 13 August 2007 02:12, Jens Axboe wrote: > > It is a system wide problem. Every block device needs throttling, > > otherwise queues expand without limit. Currently, block devices > > that use the standard request library get a slipshod form of > > throttling for free in the form of limiting in-flight request > > structs. Because the amount of IO carried by a single request can > > vary by two orders of magnitude, the system behavior of this > > approach is far from predictable. > > Is it? Consider just 10 standard sata disks. The next kernel revision > will have sg chaining support, so that allows 32MiB per request. Even > if we disregard reads (not so interesting in this discussion) and > just look at potentially pinned dirty data in a single queue, that > number comes to 4GiB PER disk. Or 40GiB for 10 disks. Auch. > > So I still think that this throttling needs to happen elsewhere, you > cannot rely the block layer throttling globally or for a single > device. It just doesn't make sense. You are right, so long as the unit of throttle accounting remains one request. This is not what we do in ddsnap. Instead we inc/dec the throttle counter by the number of bvecs in each bio, which produces a nice steady data flow to the disk under a wide variety of loads, and provides the memory resource bound we require. One throttle count per bvec will not be the right throttling metric for every driver. To customize this accounting metric for a given driver we already have the backing_dev_info structure, which provides per-device-instance accounting functions and instance data. Perfect! This allows us to factor the throttling mechanism out of the driver, so the only thing the driver has to do is define the throttle accounting if it needs a custom one. We can avoid affecting the traditional behavior quite easily, for example if backing_dev_info->throttle_fn (new method) is null then either not throttle at all (and rely on the struct request in-flight limit) or we can move the in-flight request throttling logic into core as the default throttling method, simplifying the request library and not changing its behavior. > > These deadlocks are first and foremost, block layer deficiencies. > > Even the network becomes part of the problem only because it lies > > in the block IO path. > > The block layer has NEVER guaranteed throttling, so it can - by > definition - not be a block layer deficiency. The block layer has always been deficient by not providing accurate throttling, or any throttling at all for some devices. We have practical proof that this causes deadlock and a good theoretical basis for describing exactly how it happens. To be sure, vm and net are co-conspirators, however the block layer really is the main actor in this little drama. 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: [PATCH RFC]: napi_struct V5
> > Could you explain why this is unfair? > > The simple answer is the core attempts DRR scheduling (search for the > paper by Varghese et al for more details) > If you have multiple users of a resource (network interfaces in this > case), then the quantum defines their weight. If you use more than your > fair quota, then you are being unfair. OK, I think we were talking past each other. As you noted later, the current behavior *is* fair, since it uses less than the full quota. What I couldn't understand was why everyone was telling me that using *less* than a full quota was unfair -- and now I think we all agree that it is fair. > Talk to your vendor (your hardware guys in your case ;->) next time > to fix their chip. The best scheme is to allow a Clear-on-write > only on the specific bit/event. Actually it is more of an IB spec issue than a hardware issue. IPoIB is really more of a protocol than a hardware driver in many ways; one analogy would be PPP, which runs on various serial drivers ranging from an analog modem to cellular data cards using USB serial to PPPoE. The primitives for event handling that the IB spec defines are such that this NAPI event handling gap is unavoidable. But in fact a lot of IB adapter hardware has somewhat better event handling so that the gap never occurs. We take advantage of this by having the "request event" operation simply be hard-coded never to return the missed event hint on hardware where we know the missed event is impossible by design. However IPoIB has to run on all IB hardware so we can only assume the least-common-denominator behavior, which means we have to have the missed event handling for the hardware where it does apply. > > The second one seems to perform better because in the missed event > > case, it gives a few more packets a chance to arrive so that we can > > amortize the polling overhead a little more. > > Theory makes sense. Have you validated? Yes, IBM (the people with the adapter hardware where this path triggers) did benchmarking and report that allowing the work to pile up makes a huge performance difference. In fact it is kind of suspicious that the difference is huge -- I wouldn't expect the missed event path to be common enough to make that much of a difference, but for some reason it is. - R. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.23] cxgb3 - Fix dev->priv usage
From: Divy Le Ray <[EMAIL PROTECTED]> Date: Mon, 13 Aug 2007 12:33:04 -0700 > From: Divy Le Ray <[EMAIL PROTECTED]> > > cxgb3 used netdev_priv() and dev->priv for different purposes. > In 2.6.23, netdev_priv() == dev->priv, cxgb3 needs a fix. > This patch is a partial backport of Dave Miller's changes in the > net-2.6.24 git branch. > > Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> Thank you for doing this backport. - 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 27/28] Introduce U16_MAX and U32_MAX
From: Satyam Sharma <[EMAIL PROTECTED]> Date: Mon, 13 Aug 2007 20:59:09 +0530 (IST) > On Fri, 10 Aug 2007, David Miller wrote: > > > 2) The reiserfs definition is going to define an equivalent > >value, so just adding an #undef and still letting reiserfs > >override is wrong. Why put a common define in kernel.h > >if other headers still keep their own crufty copy too? > > Because removing the (re-)definition of U32_MAX from in there in > reiserfs_fs.h will break builds of all userspace users of U32_MAX and > max_reiserfs_offset(), would it not? I haven't looked at any reiserfs > userspace tools source code, so possibly none such (that use > max_reiserfs_offset) exist, but I thought it better to be safe. > I'll have a look at the reiserfs-utils package, just in case. If this is the case then it would be better to pick different macro names from the one's reiserfs already defines in it's header exported userland interfaces. Or, alternatively, make sure reiserfs's headers get the appropriate headers and defines even when used in userspace. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] Net: mac80211, remove bitfields from struct ieee80211_txrx_data
Johannes Berg napsal(a): > On Sun, 2007-08-12 at 15:08 +0200, Jiri Slaby wrote: > >> -unsigned int fragmented:1; /* whether the MSDU was fragmented */ >> +/* whether the MSDU was fragmented */ >> +#define IEEE80211_TXRXD_FRAGMENTED BIT(0) >> +#define IEEE80211_TXRXD_TXUNICAST BIT(1) >> +#define IEEE80211_TXRXD_TXPS_BUFFERED BIT(2) >> +#define IEEE80211_TXRXD_TXPROBE_LAST_FRAG BIT(3) >> +#define IEEE80211_TXRXD_RXIN_SCAN BIT(4) > > I know this isn't the style currently used, but could you put these > definitions before the struct declaration? That way, kerneldoc doesn't > totally screw up. OK -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University - 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] Net: mac80211, remove bitfields from struct ieee80211_tx_packet_data
Johannes Berg napsal(a): > On Sun, 2007-08-12 at 15:08 +0200, Jiri Slaby wrote: > >> +if (control->flags & IEEE80211_TXCTL_REQ_TX_STATUS) >> +pkt_data->flags |= IEEE80211_TXPD_REQ_TX_STATUS; >> +if (control->flags & IEEE80211_TXCTL_DO_NOT_ENCRYPT) >> +pkt_data->flags |= IEEE80211_TXPD_DO_NOT_ENCRYPT; >> +if (control->flags & IEEE80211_TXCTL_REQUEUE) >> +pkt_data->flags |= IEEE80211_TXPD_REQUEUE; >> +if (control->type == IEEE80211_IF_TYPE_MGMT) >> +pkt_data->flags |= IEEE80211_TXPD_MGMT_IFACE; > > This looks weird. Can't we just use the same flags? I don't think, that it must be subset one of each another in the future. (This is why I created yet another bits defined). Do we still want the same flags? -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University - 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] xen-netfront: Avoid deref'ing skbafter it is potentially freed.
xennet_tx_bug_gc can free the skb before we use it, so make sure we don't. Jeff, this is -rc material. Signed-off-by: Keir Fraser <[EMAIL PROTECTED]> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> diff -r 8bfc43f6d1b0 drivers/net/xen-netfront.c --- a/drivers/net/xen-netfront.cTue Aug 07 14:26:30 2007 -0700 +++ b/drivers/net/xen-netfront.cMon Aug 13 09:39:15 2007 -0700 @@ -566,15 +566,16 @@ static int xennet_start_xmit(struct sk_b if (notify) notify_remote_via_irq(np->netdev->irq); + np->stats.tx_bytes += skb->len; + np->stats.tx_packets++; + + /* Note: It is not safe to access skb after xennet_tx_buf_gc()! */ xennet_tx_buf_gc(dev); if (!netfront_tx_slot_available(np)) netif_stop_queue(dev); spin_unlock_irq(&np->tx_lock); - - np->stats.tx_bytes += skb->len; - np->stats.tx_packets++; 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.6.23] cxgb3 - Fix dev->priv usage
From: Divy Le Ray <[EMAIL PROTECTED]>
cxgb3 used netdev_priv() and dev->priv for different purposes.
In 2.6.23, netdev_priv() == dev->priv, cxgb3 needs a fix.
This patch is a partial backport of Dave Miller's changes in the
net-2.6.24 git branch.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h | 10 +++
drivers/net/cxgb3/cxgb3_main.c| 126 +
drivers/net/cxgb3/cxgb3_offload.c |6 +-
drivers/net/cxgb3/sge.c | 23 ---
drivers/net/cxgb3/t3cdev.h|3 -
5 files changed, 100 insertions(+), 68 deletions(-)
diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h
index ab72563..c1dc344 100644
--- a/drivers/net/cxgb3/adapter.h
+++ b/drivers/net/cxgb3/adapter.h
@@ -50,7 +50,9 @@ typedef irqreturn_t(*intr_handler_t) (int, void *);
struct vlan_group;
+struct adapter;
struct port_info {
+ struct adapter *adapter;
struct vlan_group *vlan_grp;
const struct port_type_info *port_type;
u8 port_id;
@@ -246,6 +248,14 @@ static inline void t3_write_reg(struct adapter *adapter,
u32 reg_addr, u32 val)
writel(val, adapter->regs + reg_addr);
}
+/* Get the t3cdev associated with a net_device */
+static inline struct t3cdev *dev2t3cdev(struct net_device *dev)
+{
+ const struct port_info *pi = netdev_priv(dev);
+
+ return (struct t3cdev *)pi->adapter;
+}
+
static inline struct port_info *adap2pinfo(struct adapter *adap, int idx)
{
return netdev_priv(adap->port[idx]);
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index dc5d269..f3bf128 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -358,11 +358,14 @@ static int init_dummy_netdevs(struct adapter *adap)
for (j = 0; j < pi->nqsets - 1; j++) {
if (!adap->dummy_netdev[dummy_idx]) {
- nd = alloc_netdev(0, "", ether_setup);
+ struct port_info *p;
+
+ nd = alloc_netdev(sizeof(*p), "", ether_setup);
if (!nd)
goto free_all;
- nd->priv = adap;
+ p = netdev_priv(nd);
+ p->adapter = adap;
nd->weight = 64;
set_bit(__LINK_STATE_START, &nd->state);
adap->dummy_netdev[dummy_idx] = nd;
@@ -482,7 +485,8 @@ static ssize_t attr_store(struct device *d, struct
device_attribute *attr,
#define CXGB3_SHOW(name, val_expr) \
static ssize_t format_##name(struct net_device *dev, char *buf) \
{ \
- struct adapter *adap = dev->priv; \
+ struct port_info *pi = netdev_priv(dev); \
+ struct adapter *adap = pi->adapter; \
return sprintf(buf, "%u\n", val_expr); \
} \
static ssize_t show_##name(struct device *d, struct device_attribute *attr, \
@@ -493,7 +497,8 @@ static ssize_t show_##name(struct device *d, struct
device_attribute *attr, \
static ssize_t set_nfilters(struct net_device *dev, unsigned int val)
{
- struct adapter *adap = dev->priv;
+ struct port_info *pi = netdev_priv(dev);
+ struct adapter *adap = pi->adapter;
int min_tids = is_offload(adap) ? MC5_MIN_TIDS : 0;
if (adap->flags & FULL_INIT_DONE)
@@ -515,7 +520,8 @@ static ssize_t store_nfilters(struct device *d, struct
device_attribute *attr,
static ssize_t set_nservers(struct net_device *dev, unsigned int val)
{
- struct adapter *adap = dev->priv;
+ struct port_info *pi = netdev_priv(dev);
+ struct adapter *adap = pi->adapter;
if (adap->flags & FULL_INIT_DONE)
return -EBUSY;
@@ -556,9 +562,10 @@ static struct attribute_group cxgb3_attr_group = {.attrs =
cxgb3_attrs };
static ssize_t tm_attr_show(struct device *d, struct device_attribute *attr,
char *buf, int sched)
{
- ssize_t len;
+ struct port_info *pi = netdev_priv(to_net_dev(d));
+ struct adapter *adap = pi->adapter;
unsigned int v, addr, bpt, cpt;
- struct adapter *adap = to_net_dev(d)->priv;
+ ssize_t len;
addr = A_TP_TX_MOD_Q1_Q0_RATE_LIMIT - sched / 2;
rtnl_lock();
@@ -581,10 +588,11 @@ static ssize_t tm_attr_show(struct device *d, struct
device_attribute *attr,
static ssize_t tm_attr_store(struct device *d, struct device_attribute *attr,
const char *buf, size_t len, int sched)
{
+ struct port_info *pi = netdev_priv(to_net_dev(d));
+ struct adapter *adap = pi->adapter;
+ unsigned int val;
char *endp;
ssize_t ret;
- unsigned int val;
- struct adapter *adap = to_net_dev(d)->priv;
if (!capable(CAP_NET_ADMIN))
return -EPERM;
@@ -858,8 +866,9 @@ st
Re: Realtek r8168 slow outbound transfer - potential fix/workaround
David Gundersen <[EMAIL PROTECTED]> :
> Now, on to my workaround. Putting a spin style wait like the following
> in front of the line above seemed to solve the problem for me:
>
>
> if (RTL_R8(TxPoll) & NPQ) {
> for (i = 20; i > 0; i--) {
> if (!(RTL_R8(TxPoll) & NPQ))
>break;
> udelay(25);
> }
> }
>
> ...
>
> RTL_W8(TxPoll, NPQ);
What's the status of this fix? It (or something more refined) seems
necessary
to correct the current performance problems with this driver. Some
background:
I just got a motherboard (gigabyte ga-p35-ds3p) which has built-in ethernet
via the realtek rtl8111b chip. I've been experiencing serious performance
problems when it comes to transmitting files across the network using samba.
By serious I mean throughput is probably 200X slower than it should be.
This
is the same problem reported by several others. Some references:
"[Samba] Miserable read performance":
http://lists.samba.org/archive/samba/2007-July/133553.html
"[Samba] RE: Samba running slow"
http://lists.samba.org/archive/samba/2007-January/128846.html
"Re: Realtek RTL8111B serious performance issues"
http://www.mail-archive.com/netdev@vger.kernel.org/msg42860.html
I started with the stock 2.6.22.1 driver, then I tried the
20070628-2.6.22-rc6-r8169-test.patch on top of it, which made no difference.
Then I tried David Gundersen's spin-wait patch and performance was fixed!
Oddly enough, I don't see this performance problem when I test transmit
performance using ttcp, or even when I transfer files with scp. It
seems the
extra application layer latency of something like samba is necessary to
reproduce the problem.
I can troubleshoot in more detail if that would help get a proper fix
developed.
-
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 27/28] Introduce U16_MAX and U32_MAX
On Mon, 13 Aug 2007, Satyam Sharma wrote: > Hi David, > > > On Fri, 10 Aug 2007, David Miller wrote: > [...] > > 1) The reiserfs definition is better, it is _type_ based. > >Please use (~(__u16)0) and (~(__u32)0), respectively. > > Hmm, in that case ((__u16)0x) and ((__u32)0x) are probably > better and clearer -- as that's what u16_max and u32_max are, after all. > > We do require the (~0) thing for the max int/uint/long types, but that's > because those are types where the number-of-bits is not known when writing > the macro definition -- but that's not case with u16 and u32, so the > 0xff... variants are clearer, IMHO. > > > > 2) The reiserfs definition is going to define an equivalent > >value, so just adding an #undef and still letting reiserfs > >override is wrong. Why put a common define in kernel.h > >if other headers still keep their own crufty copy too? > > Because removing the (re-)definition of U32_MAX from in there in > reiserfs_fs.h will break builds of all userspace users of U32_MAX and > max_reiserfs_offset(), would it not? I haven't looked at any reiserfs > userspace tools source code, so possibly none such (that use > max_reiserfs_offset) exist, but I thought it better to be safe. > I'll have a look at the reiserfs-utils package, just in case. I checked with latest reiserfsprogs available from namesys.com and also reiserfs-utils package available from Fedora, and it appears there are no users of either U32_MAX or max_reiserfs_offset() in any userspace reiserfs tools, so we're safe in removing the U32_MAX from include/linux/reiserfs_fs.h. Thanks, Satyam - 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/2] 2.6.23-rc3: known regressions with patches
Hi all, Here is a list of some known regressions in 2.6.23-rc3 with patches available. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces NameRegressions fixed since 21-Jun-2007 Adrian Bunk9 Andi Kleen 5 Linus Torvalds 5 Andrew Morton 4 Al Viro3 Cornelia Huck 3 Jens Axboe 3 Tejun Heo 3 Modpost Subject : modpost bug breaks ia64 cross compilation References : http://lkml.org/lkml/2007/7/27/30 http://lkml.org/lkml/2007/7/27/418 Last known good : ? Submitter : Jan Dittmer <[EMAIL PROTECTED]> Caused-By : Thomas Renninger <[EMAIL PROTECTED]> commit 29b71a1ca74491fab9fed09e9d835d840d042690 Handled-By : ? Patch : http://lkml.org/lkml/2007/8/2/211 Status : patch was suggested MTD Subject : error: implicit declaration of function 'cfi_interleave' References : http://lkml.org/lkml/2007/8/6/272 Last known good : ? Submitter : Ingo Molnar <[EMAIL PROTECTED]> Caused-By : ? Handled-By : David Woodhouse <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/8/9/586 Status : patch available Networking Subject : sky2 boot crash in sky2_mac_intr References : http://lkml.org/lkml/2007/7/24/91 Last known good : ? Submitter : Florian Lohoff <[EMAIL PROTECTED]> Caused-By : Handled-By : Stephen Hemminger <[EMAIL PROTECTED]> Patch : http://marc.info/?l=linux-netdev&m=118651402523966&w=2 Status : patch available USB Subject : USB hard disk problem due to "usb-storage: implement autosuspend" patch References : http://lkml.org/lkml/2007/8/9/329 Last known good : ? Submitter : Dan Zwell <[EMAIL PROTECTED]> Caused-By : Alan Stern <[EMAIL PROTECTED]> commit 8dfe4b14869fd185ca25ee88b02ada58a3005eaf Handled-By : Alan Stern <[EMAIL PROTECTED]> Status : patch available Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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
Hi all, Here is a list of some known regressions in 2.6.23-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces NameRegressions fixed since 21-Jun-2007 Adrian Bunk9 Andi Kleen 5 Linus Torvalds 5 Andrew Morton 4 Al Viro3 Cornelia Huck 3 Jens Axboe 3 Tejun Heo 3 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 : ? 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 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 : ? Status : unknown Subject : IP v4 routing is broken References : http://www.stardust.webpages.pl/files/tbf/bugs/bug_report01.txt Last known good : 2.6.22-git2 Submitter : Uwe Bugla <[EMAIL PROTECTED]> Caused-By : ? Handled-By : ? Status : unknown Subject : New wake ups from sky2 References : http://lkml.org/lkml/2007/7/20/386 Last known good : ? Submitter : Thomas Meyer <[EMAIL PROTECTED]> Caused-By : Stephen Hemminger <[EMAIL PROTECTED]> commit eb35cf60e462491249166182e3e755d3d5d91a28 Handled-By : Stephen Hemminger <[EMAIL PROTECTED]> Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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/2many] MAINTAINERS - 3CR990 NETWORK DRIVER
On Sun, 2007-08-12 at 23:21 -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Acked-by: Dave Dillow <[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] [70/2many] MAINTAINERS - ARPD SUPPORT
On Mon, 13 Aug 2007 10:04:19 -0700 Joe Perches <[EMAIL PROTECTED]> wrote: > On Mon, 2007-08-13 at 17:35 +0100, Alan Cox wrote: > > I wouldn't add a pattern for this. > > Back to:ARPD SUPPORT > P:Jonathan Layes > L:netdev@vger.kernel.org > S:Maintained > > > Actually I think the entire thing is a > > bad idea but thats another matter. > > Of course it's not an end-all solution, > but what might work better? Working off the git tree as it shows who actually is making changes/updating stuff recently and why which is a major clue when tracing bugs - 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 8169 support question
Francois Romieu wrote: Chuck Lever <[EMAIL PROTECTED]> : [...] Not yet. I wanted to check with "the Maintainer" to see if it was worth trying. :-) The last time I tried a kernel build on one of these It is worth trying. FYI: I tested a 2.6.23-rc2 kernel over the weekend, and the NICs worked without issue. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE url:http://oss.oracle.com/~cel version:2.1 end:vcard
Disabling 64-bit DMA on atl1?
Jeff -- Can we please get Luca's patch merged for 2.6.23? The bug is a data corrupter, and the workaround doesn't cost us much. Both Jay and I have already acked it. http://lkml.org/lkml/2007/6/25/293 We'll do it "the right way" once Atheros tracks it down with hardware analyzers, but for now, let's fix the data corrupter. -- 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] [459/2many] MAINTAINERS - SPIDERNET NETWORK DRIVER for CELL
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* - 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
Problem with semantics?
Dear Linux maintainers, I'm doing : setsockopt(s, SO_RCVTIMEO, t1 ); // set time-out t1 on socket while block receiving on it select(,,, &fd_set_including(s), .., &errs, t2); // block till receive or time-out t 2 jointly on a set of sockets Apparently, I could no find reference on the coupled behavior of the two above statements in Linux documentation. As I understand the blocking semantics, I would expect that if t1http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT
On Mon, 2007-08-13 at 17:35 +0100, Alan Cox wrote: > I wouldn't add a pattern for this. Back to:ARPD SUPPORT P: Jonathan Layes L: netdev@vger.kernel.org S: Maintained > Actually I think the entire thing is a > bad idea but thats another matter. Of course it's not an end-all solution, but what might work better? - 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: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
(netdev Cced) Karl Meyer <[EMAIL PROTECTED]> : [...] > I am having trouble with the 2.6.23 kernel. With all versions since > 2.6.23-rc1 I have trouble with my network connection. When using the > network over a certain level (just browsing the web seems not to be > enough) e.g. when installing packages over the nvsv4 share, all > network stuff freezes for some time and syslog tells me: > Aug 13 13:16:09 frege NETDEV WATCHDOG: eth0: transmit timed out > Aug 13 13:16:39 frege NETDEV WATCHDOG: eth0: transmit timed out > Aug 13 13:17:09 frege NETDEV WATCHDOG: eth0: transmit timed out > Aug 13 13:17:57 frege NETDEV WATCHDOG: eth0: transmit timed out Can you: - send a complete dmesg + /proc/interrupts + .config - use git bisect to find a suspect changeset I do not expect any change of behavior between 2.6.22 and 25805dcf9d83098cf5492117ad2669cd14cc9b24 if it can help you narrow things down (assuming it is a r8169 regression). -- Ueimor - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT
On Mon, 13 Aug 2007 08:46:06 -0700 Joe Perches <[EMAIL PROTECTED]> wrote: > On Mon, 2007-08-13 at 11:49 +0100, Alan Cox wrote: > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 90c1b81..ac2226b 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -697,6 +697,7 @@ ARPD SUPPORT > > > P: Jonathan Layes > > > L: netdev@vger.kernel.org > > > S: Maintained > > > +F: net/ipv4/arp.c > > > > NAK > > > > arp.c is the netdev people, ARPD is a corner case bit of code within it, > > something your patterns don't actually cope with > > Suggestions? I wouldn't add a pattern for this. Actually I think the entire thing is a bad idea but thats another matter. - 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: [KJ] replacing kmalloc with kzalloc in drivers/net/sb1250-mac.c
On Mon, 13 Aug 2007, Surya Prabhakar N wrote: > Hi, >Replacing kmalloc with kzalloc and cleaning up memset in > drivers/net/sb1250-mac.c > > > Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]> > --- > > diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c > index e7fdcf1..2dca5a7 100644 > --- a/drivers/net/sb1250-mac.c > +++ b/drivers/net/sb1250-mac.c > @@ -760,7 +760,7 @@ static void sbdma_initctx(sbmacdma_t *d, > > d->sbdma_dscrtable_unaligned = > d->sbdma_dscrtable = (sbdmadscr_t *) ^^^ > - kmalloc((d->sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL); > + kzalloc((d->sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL); i'm fairly sure you can drop all of those superfluous casts when calling one of those memory allocation routines. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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
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... - 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] [70/2many] MAINTAINERS - ARPD SUPPORT
On Mon, 2007-08-13 at 11:49 +0100, Alan Cox wrote: > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 90c1b81..ac2226b 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -697,6 +697,7 @@ ARPD SUPPORT > > P: Jonathan Layes > > L: netdev@vger.kernel.org > > S: Maintained > > +F: net/ipv4/arp.c > > NAK > > arp.c is the netdev people, ARPD is a corner case bit of code within it, > something your patterns don't actually cope with Suggestions? - 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 Sun, Aug 12, 2007 at 11:36:42PM -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index b616562..fa8fb1c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4377,6 +4377,9 @@ P: Linas Vepstas > M: [EMAIL PROTECTED] > L: netdev@vger.kernel.org > S: Supported > +F: Documentation/networking/spider_net.txt > +F: arch/powerpc/platforms/cell/spider-pic.c > +F: drivers/net/spider_net* Note quite right. spider-pic is not part of spider_net. The rest loks fine. --linas - 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
Hi Udo, On 11/08/07, Udo van den Heuvel <[EMAIL PROTECTED]> wrote: > Using Cups 1.2.12 on Linux 2.6.22.1. > Managing a printer from a Win2K workstation via the http interface. > I am at: http://box:631/printers > I click Set as default. > I see: > 426 Upgrade Required > > You must access this page using the URL > https://box:631/admin/?op=set-as-default&printer_name=HP_DESKJET_3820_USB_1. > > I clikc that link and hear the ping-ping of the BUG: This is very interesting. Can you reproduce this bug? > > BUG: unable to handle kernel paging request at virtual address 730ca542 > printing eip: > 730ca542 > *pde = > Oops: [#1] > PREEMPT > Modules linked in: pwc nls_utf8 cifs sch_tbf ipt_recent xt_string > xt_MARK xt_length xt_tcpmss xt_mac xt_mark w83627hf hwmon_vid eeprom sit > tunnel4 nf_nat_h323 nf_conntrack_h323 nf_nat_ftp nf_conntrack_ftp > ipt_tos ipt_REDIRECT nf_nat_irc nf_conntrack_irc ipt_owner ipt_ttl ipv6 > ipt_MASQUERADE iptable_nat nf_nat xt_NOTRACK iptable_raw ipt_TOS > iptable_mangle ipt_LOG xt_TCPMSS xt_limit xt_state ipt_TARPIT ipt_REJECT > iptable_filter binfmt_misc lp nvram loop snd_via82xx snd_ac97_codec > ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq > snd_pcm_oss snd_mixer_oss snd_pcm compat_ioctl32 videodev snd_timer > snd_page_alloc snd_mpu401_uart snd_rawmidi v4l2_common snd_seq_device > v4l1_compat parport_pc parport snd usblp i2c_viapro uhci_hcd > CPU:0 > EIP:0060:[<730ca542>]Not tainted VLI > EFLAGS: 00010292 (2.6.22.1 #2) > EIP is at 0x730ca542 > eax: ebx: a69845a0 ecx: edx: > esi: 1057e3db edi: 67c88dd0 ebp: 898c1ad5 esp: d9f97f18 > ds: 007b es: 007b fs: gs: 0033 ss: 0068 > Process cupsd (pid: 2220, ti=d9f96000 task=db549420 task.ti=d9f96000) > Stack: b717a69a 240c98ab c2e35cdc 2f6eea16 64cf0972 c0a5a2b1 ba2d3d30 > f026206d >3301069b 39222156 d15922e5 eb1da2a4 656caba4 023f7970 33d43992 > cc0c5c41 >63ed81fc 5c760bf7 fe3db5c3 7cdbd9fc ba114508 0ff827b8 b51f3690 > 9e64614f > Call Trace: > [] show_trace_log_lvl+0x1a/0x2f > [] show_stack_log_lvl+0x9d/0xa5 > [] show_registers+0x1cd/0x2e3 > [] die+0xfe/0x200 > [] do_page_fault+0x432/0x505 > [] error_code+0x6a/0x70 > === > Code: Bad EIP value. > EIP: [<730ca542>] 0x730ca542 SS:ESP 0068:d9f97f18 > > > 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. Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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 27/28] Introduce U16_MAX and U32_MAX
Hi David, On Fri, 10 Aug 2007, David Miller wrote: > From: [EMAIL PROTECTED] > Date: Fri, 10 Aug 2007 14:12:10 -0700 > > > From: Satyam Sharma <[EMAIL PROTECTED]> > > > > ... in kernel.h and clean up home-grown macros elsewhere in the tree. > > > > Leave out the one in reiserfs_fs.h as it is in the userspace-visible part > > of that header. Still, #undef the (equivalent) kernel version there to > > avoid seeing "redefined, previous definition was here" gcc warnings. > > > > [EMAIL PROTECTED]: fix U16_MAX, U32_MAX defns] > > Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > I won't apply this one, for two reasons: > > 1) The reiserfs definition is better, it is _type_ based. >Please use (~(__u16)0) and (~(__u32)0), respectively. Hmm, in that case ((__u16)0x) and ((__u32)0x) are probably better and clearer -- as that's what u16_max and u32_max are, after all. We do require the (~0) thing for the max int/uint/long types, but that's because those are types where the number-of-bits is not known when writing the macro definition -- but that's not case with u16 and u32, so the 0xff... variants are clearer, IMHO. > 2) The reiserfs definition is going to define an equivalent >value, so just adding an #undef and still letting reiserfs >override is wrong. Why put a common define in kernel.h >if other headers still keep their own crufty copy too? Because removing the (re-)definition of U32_MAX from in there in reiserfs_fs.h will break builds of all userspace users of U32_MAX and max_reiserfs_offset(), would it not? I haven't looked at any reiserfs userspace tools source code, so possibly none such (that use max_reiserfs_offset) exist, but I thought it better to be safe. I'll have a look at the reiserfs-utils package, just in case. Thanks, Satyam - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [3/2many] MAINTAINERS - 3C359 NETWORK DRIVER
Hi, please in the future send just one patch for this; there's no real reason to split this up this finegrained... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
What does -EIOCBQUEUED do?
Hello. There are several locations that handle -EIOCBQUEUED error code. According to include/linux/errno.h , it seems this code is NFS related and caller will receive completion event later. But I couldn't figure out where is the beginning point and what is happening. What functions are called before aio_complete() is called? (For example, is udp_recvmsg() called if sock_recvmsg() for UDP socket returned -EIOCBQUEUED?) What memory regions are accessed before aio_complete() is called? (For example, is "struct msghdr"->msg_name accessed if sock_recvmsg() for UDP socket returned -EIOCBQUEUED?) Regards. - 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: drivers/net/tokenring/3c359.c
On Mon, 13 Aug 2007 15:43:30 +0530 Surya Prabhakar N <[EMAIL PROTECTED]> wrote: > Hi, >Replacing kmalloc with kzalloc and cleaning up memset in > drivers/net/tokenring/3c359.c > > > Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]> Acked-by: Alan Cox <[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 for 2.6.24] SCTP: Rewrite of sctp buffer management code
On Mon, Aug 13, 2007 at 09:24:00AM -0400, Vlad Yasevich wrote: > Dave, Neil > > Sorry about that. Not sure what happened to that patch. Here is > the good patch with witespace cleanups. > > -vlad > Thank you Vlad, that looks much better. Not sure what happened either Regards Neil -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ - 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 for 2.6.24] SCTP: Rewrite of sctp buffer management code
Dave, Neil
Sorry about that. Not sure what happened to that patch. Here is
the good patch with witespace cleanups.
-vlad
--
SCTP: Rewrite of sctp buffer management code
This patch introduces autotuning to the sctp buffer management code
similar to the TCP. The buffer space can be grown if the advertised
receive window still has room. This might happen if small message
sizes are used, which is common in telecom environmens.
New tunables are introduced that provide limits to buffer growth
and memory pressure is entered if to much buffer spaces is used.
Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
include/net/sctp/sctp.h |5 +++
net/sctp/endpointola.c |1
net/sctp/protocol.c | 32 +
net/sctp/sm_statefuns.c | 73 +++-
net/sctp/socket.c | 67
net/sctp/sysctl.c | 33 +
net/sctp/ulpevent.c | 18 +++
net/sctp/ulpqueue.c |1
8 files changed, 163 insertions(+), 67 deletions(-)
---
include/net/sctp/sctp.h |5 +++
net/sctp/endpointola.c |1 +
net/sctp/protocol.c | 32
net/sctp/sm_statefuns.c | 74 +++---
net/sctp/socket.c | 69 ---
net/sctp/sysctl.c | 33 +
net/sctp/ulpevent.c | 18 +++
net/sctp/ulpqueue.c |1 +
8 files changed, 165 insertions(+), 68 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index d529045..46d7d09 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -468,6 +468,11 @@ static inline void sctp_skb_set_owner_r(struct sk_buff
*skb, struct sock *sk)
skb->sk = sk;
skb->destructor = sctp_sock_rfree;
atomic_add(event->rmem_len, &sk->sk_rmem_alloc);
+ /*
+* This mimics the behavior of
+* sk_stream_set_owner_r
+*/
+ sk->sk_forward_alloc -= event->rmem_len;
}
/* Tests if the list has one and only one entry. */
diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
index 1404a9e..aba9258 100644
--- a/net/sctp/endpointola.c
+++ b/net/sctp/endpointola.c
@@ -103,6 +103,7 @@ static struct sctp_endpoint *sctp_endpoint_init(struct
sctp_endpoint *ep,
/* Use SCTP specific send buffer space queues. */
ep->sndbuf_policy = sctp_sndbuf_policy;
+
sk->sk_write_space = sctp_write_space;
sock_set_flag(sk, SOCK_USE_WRITE_QUEUE);
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index e98579b..a746ebf 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -82,6 +83,10 @@ static struct sctp_af *sctp_af_v6_specific;
struct kmem_cache *sctp_chunk_cachep __read_mostly;
struct kmem_cache *sctp_bucket_cachep __read_mostly;
+extern int sysctl_sctp_mem[3];
+extern int sysctl_sctp_rmem[3];
+extern int sysctl_sctp_wmem[3];
+
/* Return the address of the control sock. */
struct sock *sctp_get_ctl_sock(void)
{
@@ -969,6 +974,8 @@ SCTP_STATIC __init int sctp_init(void)
int i;
int status = -EINVAL;
unsigned long goal;
+ unsigned long limit;
+ int max_share;
int order;
/* SCTP_DEBUG sanity check. */
@@ -1059,6 +1066,31 @@ SCTP_STATIC __init int sctp_init(void)
/* Initialize handle used for association ids. */
idr_init(&sctp_assocs_id);
+ /* Set the pressure threshold to be a fraction of global memory that
+* is up to 1/2 at 256 MB, decreasing toward zero with the amount of
+* memory, with a floor of 128 pages.
+* Note this initalizes the data in sctpv6_prot too
+* Unabashedly stolen from tcp_init
+*/
+ limit = min(num_physpages, 1UL<<(28-PAGE_SHIFT)) >> (20-PAGE_SHIFT);
+ limit = (limit * (num_physpages >> (20-PAGE_SHIFT))) >> (PAGE_SHIFT-11);
+ limit = max(limit, 128UL);
+ sysctl_sctp_mem[0] = limit / 4 * 3;
+ sysctl_sctp_mem[1] = limit;
+ sysctl_sctp_mem[2] = sysctl_sctp_mem[0] * 2;
+
+ /* Set per-socket limits to no more than 1/128 the pressure threshold*/
+ limit = (sysctl_sctp_mem[1]) << (PAGE_SHIFT - 7);
+ max_share = min(4UL*1024*1024, limit);
+
+ sysctl_sctp_rmem[0] = PAGE_SIZE; /* give each asoc 1 page min */
+ sysctl_sctp_rmem[1] = (1500 *(sizeof(struct sk_buff) + 1));
+ sysctl_sctp_rmem[2] = max(sysctl_sctp_rmem[1], max_share);
+
+ sysctl_sctp_wmem[0] = SK_STREAM_MEM_QUANTUM;
+ sysctl_sctp_wmem[1] = 16*1024;
+ sysctl_sctp_wmem[2] = max(64*1024, max_share);
+
/* Size and allocate the association hash table.
* The methodology is similar to that of the tcp hash tables.
*/
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_s
Re: [PATCH] [374/2many] MAINTAINERS - PCNET32 NETWORK DRIVER
Am Montag 13 August 2007 09:18 schrieb Al Viro: > On Sun, Aug 12, 2007 at 11:46:49PM -0700, Joe Perches wrote: > > On Sun, 2007-08-12 at 23:36 -0700, David Miller wrote: > > > Ok, 374 patches is just rediculious. > > > > > > So many patches eats up an enormous amount of mailing list resources, > > > and for these patches in particular there are few reasons to split > > > them up at all. The fact that the split up landed you at 300+ patches > > > is a very good indication of that. > > > > More than ridiculous. Completely agree. > > > > I tried to send 1 patch over the last couple of days. > > Unfortunately, it's > 100KB and disappears into the void. > > So put it on anonftp/webpage/git tree and post the URI, damnit. > Of all ridiculous reasons for a mailbomb... Or make it 3 or 4 or even 40 patches, but not 500. Hans - 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
[kj] is_power_of_2 in net/core/neighbour.c
Replacing n & (n - 1) for power of 2 check by is_power_of_2(n) Signed-off-by: vignesh babu <[EMAIL PROTECTED]> --- diff --git a/net/core/neighbour.c b/net/core/neighbour.c index ca2a153..f7de8f2 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -33,6 +33,7 @@ #include #include #include +#include #define NEIGH_DEBUG 1 @@ -311,7 +312,7 @@ static void neigh_hash_grow(struct neigh_table *tbl, unsigned long new_entries) NEIGH_CACHE_STAT_INC(tbl, hash_grows); - BUG_ON(new_entries & (new_entries - 1)); + BUG_ON(!is_power_of_2(new_entries)); new_hash = neigh_hash_alloc(new_entries); if (!new_hash) return; -- Vignesh Babu BM _ "Why is it that every time I'm with you, makes me believe in magic?" - 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 Monday 13 August 2007 05:18, Evgeniy Polyakov wrote: > > Say you have a device mapper device with some physical device > > sitting underneath, the classic use case for this throttle code. > > Say 8,000 threads each submit an IO in parallel. The device mapper > > mapping function will be called 8,000 times with associated > > resource allocations, regardless of any throttling on the physical > > device queue. > > Each thread will sleep in generic_make_request(), if limit is > specified correctly, then allocated number of bios will be enough to > have a progress. The problem is, the sleep does not occur before the virtual device mapping function is called. Let's consider two devices, a physical device named pdev and a virtual device sitting on top of it called vdev. vdev's throttle limit is just one element, but we will see that in spite of this, two bios can be handled by the vdev's mapping method before any IO completes, which violates the throttling rules. According to your patch it works like this: Thread 1Thread 2 bio_queued is zero> vdev->q->bio_queued++ blk_set_bdev(bio, pdev) vdev->bio_queued-- bio_queued is zero> vdev->q->bio_queued++ whoops! Our virtual device mapping function has now allocated resources for two in-flight bios in spite of having its throttle limit set to 1. 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. 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: [PATCH] [504/2many] MAINTAINERS - USB PEGASUS DRIVER
On Sun, 12 Aug 2007, [EMAIL PROTECTED] wrote: Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches <[EMAIL PROTECTED]> diff --git a/MAINTAINERS b/MAINTAINERS index d822865..fc87fa7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4764,6 +4764,7 @@ L:[EMAIL PROTECTED] L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained +F: drivers/net/usb/pegasus.* USB PRINTER DRIVER (usblp) P: Pete Zaitcev Well, what can i say? "NO, don't do it!" is probably not going to work so i assume i will have to ACK. :-) Petko - 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
[kj] is_power_of_2 in net/pcmcia/pcnet_cs.c
Replacing n & (n - 1) for power of 2 check by is_power_of_2(n) Signed-off-by: vignesh babu <[EMAIL PROTECTED]> --- diff --git a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c index 63de89e..d23bf6e 100644 --- a/drivers/net/pcmcia/pcnet_cs.c +++ b/drivers/net/pcmcia/pcnet_cs.c @@ -36,6 +36,7 @@ #include #include #include +#include #include #include #include <../drivers/net/8390.h> @@ -1486,7 +1487,7 @@ static int setup_shmem_window(struct pcmcia_device *link, int start_pg, window_size = 32 * 1024; /* Make sure it's a power of two. */ -while ((window_size & (window_size - 1)) != 0) +while (!is_power_of_2(window_size)) window_size += window_size & ~(window_size - 1); /* Allocate a memory window */ -- Vignesh Babu BM _ "Why is it that every time I'm with you, makes me believe in magic?" - 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: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])
[EMAIL PROTECTED] wrote: Would this just be relevant to network devices or would it improve support for jostled usb and sata hot-plugging I wonder? good question, I suspect that some of the error handling would be similar (for devices that are unreachable not haning the system for example), but a lot of the rest would be different (do you really want to try to auto-resync to a drive that you _think_ just reappeared, Well, omit 'think' and the answer may be "yes". A lot of systems are quite simple and RAID is common on the desktop now. If jostled USB fits into this category - then "yes". what if it's a different drive? how can you be sure? And that's the key isn't it. We have the RAID device UUID and the superblock info. Isn't that enough? If not then given the work involved an extended superblock wouldn't be unreasonable. And I suspect the capability of devices would need recording in the superblock too? eg 'retry-on-fail' I can see how md would fail a device but may now periodically retry it. If a retry shows that it's back then it would validate it (UUID) and then resync it. ) the error rate of a network is gong to be significantly higher then for USB or SATA drives (although I suppose iscsi would be limilar) I do agree - I was looking for value-add for the existing subsystem. If this benefits existing RAID users then it's more likely to be attractive. David - 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] Net: mac80211, remove bitfields from struct ieee80211_tx_packet_data
On Sun, 2007-08-12 at 15:08 +0200, Jiri Slaby wrote: > + if (control->flags & IEEE80211_TXCTL_REQ_TX_STATUS) > + pkt_data->flags |= IEEE80211_TXPD_REQ_TX_STATUS; > + if (control->flags & IEEE80211_TXCTL_DO_NOT_ENCRYPT) > + pkt_data->flags |= IEEE80211_TXPD_DO_NOT_ENCRYPT; > + if (control->flags & IEEE80211_TXCTL_REQUEUE) > + pkt_data->flags |= IEEE80211_TXPD_REQUEUE; > + if (control->type == IEEE80211_IF_TYPE_MGMT) > + pkt_data->flags |= IEEE80211_TXPD_MGMT_IFACE; This looks weird. Can't we just use the same flags? johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/4] Net: mac80211, remove bitfields from struct ieee80211_txrx_data
On Sun, 2007-08-12 at 15:08 +0200, Jiri Slaby wrote: > - unsigned int fragmented:1; /* whether the MSDU was fragmented */ > + /* whether the MSDU was fragmented */ > +#define IEEE80211_TXRXD_FRAGMENTED BIT(0) > +#define IEEE80211_TXRXD_TXUNICASTBIT(1) > +#define IEEE80211_TXRXD_TXPS_BUFFEREDBIT(2) > +#define IEEE80211_TXRXD_TXPROBE_LAST_FRAGBIT(3) > +#define IEEE80211_TXRXD_RXIN_SCANBIT(4) I know this isn't the style currently used, but could you put these definitions before the struct declaration? That way, kerneldoc doesn't totally screw up. johannes signature.asc Description: This is a digitally signed message part
Re: Block device throttling [Re: Distributed storage.]
On Mon, Aug 13, 2007 at 05:18:14AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > > If limit is for > > 1gb of pending block io, and system has for example 2gbs of ram (or > > any other resonable parameters), then there is no way we can deadlock > > in allocation, since it will not force page reclaim mechanism. > > The problem is that sk_alloc (called from our block driver via > socket->write) would recurse into shrink_pages, which recursively > submits IO to our block driver and blocks on the throttle. Subtle > indeed, and yet another demonstration of why vm recursion is a Bad > Thing. > > I will find a traceback for you tomorrow, which makes this deadlock much > clearer. I see how it can happen, but device throttling is a solution we are trying to complete, which main aim _is_ to remove this problem. Lower per-device limit, so that the rest of the RAM allowed to allocate all needed data structures in the network path. Above example just has 1gb of ram, which should be enough for skbs, if it is not, decrease limit to 500 mb and so on, until weighted load of the system allows to always have a forward progress. -- 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 Mon, Aug 13, 2007 at 04:18:03AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > > No. Since all requests for virtual device end up in physical devices, > > which have limits, this mechanism works. Virtual device will > > essentially call either generic_make_request() for new physical > > device (and thus will sleep is limit is over), or will process bios > > directly, but in that case it will sleep in generic_make_request() > > for virutal device. > > What can happen is, as soon as you unthrottle the previous queue, > another thread can come in and put another request on it. Sure, that > thread will likely block on the physical throttle and so will the rest > of the incoming threads, but it still allows the higher level queue to > grow past any given limit, with the help of lots of threads. JVM for > example? No. You get one slot, and one thread will not be blocked, all others will. If lucky thread wants to put two requests it will be blocked on second request, since underlying physical device does not accept requests anymore an thus caller will sleep. > Say you have a device mapper device with some physical device sitting > underneath, the classic use case for this throttle code. Say 8,000 > threads each submit an IO in parallel. The device mapper mapping > function will be called 8,000 times with associated resource > allocations, regardless of any throttling on the physical device queue. Each thread will sleep in generic_make_request(), if limit is specified correctly, then allocated number of bios will be enough to have a progress. Here is an example: let's say system has 20.000 pages in RAM and 20.000 in swap, we have 8.000 threads, each one allocates a page, then next page and so on. System has one virtual device with two physical devices under it, each device gets half of requests. We set limit to 4.000 per physical device. All threads allocate a page and queue it to devices, so all threads succeeded in its first allocation, and each device has its queue full. Virtual device does not have a limit (or have it 4.000 too, but since it was each time recharged, it has zero blocks in-flight). New thread tries to allocate a page, it is allocated and queued to one of the devices, but since its queue is full, thread sleeps. So will do each other. Thus we ended up allocated 8.000 requests queued, and 8.000 in-flight, totally 16.000 which is smaller than amount of pages in RAM, so we are happy. Consider above as a special kind calculation i.e. number of _allocated_ pages is always number of physical device multiplied by each one's in-flight limit. By adjusting in-flight limit and knowing number of device it is completely possible to eliminate vm deadlock. If you do not like such calculation, solution is trivial: we can sleep _after_ ->make_request_fn() in generic_make_request() until number of in-flight bios is reduced by bio_endio(). -- 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 Monday 13 August 2007 05:04, Evgeniy Polyakov wrote: > On Mon, Aug 13, 2007 at 04:04:26AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > > On Monday 13 August 2007 01:14, Evgeniy Polyakov wrote: > > > > Oops, and there is also: > > > > > > > > 3) The bio throttle, which is supposed to prevent deadlock, can > > > > itself deadlock. Let me see if I can remember how it goes. > > > > > > > > * generic_make_request puts a bio in flight > > > > * the bio gets past the throttle and initiates network IO > > > > * net calls sk_alloc->alloc_pages->shrink_caches > > > > * shrink_caches submits a bio recursively to our block device > > > > * this bio blocks on the throttle > > > > * net may never get the memory it needs, and we are wedged > > > > > > If system is in such condition, it is already broken - throttle > > > limit must be lowered (next time) not to allow such situation. > > > > Agreed that the system is broken, however lowering the throttle > > limit gives no improvement in this case. > > How is it ever possible? The whole idea of throttling is to remove > such situation, and now you say it can not be solved. It was solved, by not throttling writeout that comes from shrink_caches. Ugly. > If limit is for > 1gb of pending block io, and system has for example 2gbs of ram (or > any other resonable parameters), then there is no way we can deadlock > in allocation, since it will not force page reclaim mechanism. The problem is that sk_alloc (called from our block driver via socket->write) would recurse into shrink_pages, which recursively submits IO to our block driver and blocks on the throttle. Subtle indeed, and yet another demonstration of why vm recursion is a Bad Thing. I will find a traceback for you tomorrow, which makes this deadlock much clearer. Regards - 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] [374/2many] MAINTAINERS - PCNET32 NETWORK DRIVER
On Sun, 12 Aug 2007, David Miller wrote: > Ok, 374 patches is just rediculious. > So many patches eats up an enormous amount of mailing list resources, > and for these patches in particular there are few reasons to split them > up at all. The fact that the split up landed you at 300+ patches is a > very good indication of that. Actually, I can see 546 patches up to now. Horrid. Besides that, it's very unfortunate that every single mail of this ridiculously hge patch series starts a new thread (no 'References' or 'In-Reply-To' header), so it's not possible to nuke it at once in an usual way. -- Jiri Kosina - 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 04:04:26AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > On Monday 13 August 2007 01:14, Evgeniy Polyakov wrote: > > > Oops, and there is also: > > > > > > 3) The bio throttle, which is supposed to prevent deadlock, can > > > itself deadlock. Let me see if I can remember how it goes. > > > > > > * generic_make_request puts a bio in flight > > > * the bio gets past the throttle and initiates network IO > > > * net calls sk_alloc->alloc_pages->shrink_caches > > > * shrink_caches submits a bio recursively to our block device > > > * this bio blocks on the throttle > > > * net may never get the memory it needs, and we are wedged > > > > If system is in such condition, it is already broken - throttle limit > > must be lowered (next time) not to allow such situation. > > Agreed that the system is broken, however lowering the throttle limit > gives no improvement in this case. How is it ever possible? The whole idea of throttling is to remove such situation, and now you say it can not be solved. If limit is for 1gb of pending block io, and system has for example 2gbs of ram (or any other resonable parameters), then there is no way we can deadlock in allocation, since it will not force page reclaim mechanism. -- 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: Distributed storage.
On Monday 13 August 2007 04:03, Evgeniy Polyakov wrote: > On Mon, Aug 13, 2007 at 03:12:33AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > > > This is not a very good solution, since it requires all users of > > > the bios to know how to free it. > > > > No, only the specific ->endio needs to know that, which is set by > > the bio owner, so this knowledge lies in exactly the right place. > > A small handful of generic endios all with the same destructor are > > used nearly everywhere. > > That is what I meant - there will be no way to just alloc a bio and > put it, helpers for generic bio sets must be exported and each and > every bi_end_io() must be changed to check reference counter and they > must know how they were allocated. There are fewer non-generic bio allocators than you think. > Endio callback is of course quite rare and additional atomic > reading will not kill the system, but why introduce another read? > It is possible to provide a flag for endio callback that it is last, > but it still requires to change every single callback - why do we > want this? We don't. Struct bio does not need to be shrunk. Jens wanted to talk about what fields could be eliminated if we wanted to shrink it. It is about time to let that lie, don't you think? > So, I'm a bit lost... > > You say it is too big Did not say that. > and some parts can be removed or combined True. > and then that size does not matter. Also true, backed up by numbers on real systems. > Last/not-last checks in the code is > not clear design, so I do not see why it is needed at all if not for > size shrinking. Not needed, indeed. Accurate throttling is needed. If the best way to throttle requires expanding struct bio a little then we should not let concerns about the cost of an int or two stand in the way. Like Jens, I am more concerned about the complexity cost, and that is minimized in my opinion by throttling in the generic code rather than with custom code in each specialized block driver. Your patch does throttle in the generic code, great. Next thing is to be sure that it completely closes the window for reserve leakage, which is not yet clear. 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 Monday 13 August 2007 01:23, Evgeniy Polyakov wrote: > On Sun, Aug 12, 2007 at 10:36:23PM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > > (previous incomplete message sent accidentally) > > > > On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote: > > > On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe wrote: > > > > > > So, what did we decide? To bloat bio a bit (add a queue pointer) > > > or to use physical device limits? The latter requires to replace > > > all occurence of bio->bi_bdev = something_new with > > > blk_set_bdev(bio, somthing_new), where queue limits will be > > > appropriately charged. So far I'm testing second case, but I only > > > changed DST for testing, can change all other users if needed > > > though. > > > > Adding a queue pointer to struct bio and using physical device > > limits as in your posted patch both suffer from the same problem: > > you release the throttling on the previous queue when the bio moves > > to a new one, which is a bug because memory consumption on the > > previous queue then becomes unbounded, or limited only by the > > number of struct requests that can be allocated. In other words, > > it reverts to the same situation we have now as soon as the IO > > stack has more than one queue. (Just a shorter version of my > > previous post.) > > No. Since all requests for virtual device end up in physical devices, > which have limits, this mechanism works. Virtual device will > essentially call either generic_make_request() for new physical > device (and thus will sleep is limit is over), or will process bios > directly, but in that case it will sleep in generic_make_request() > for virutal device. What can happen is, as soon as you unthrottle the previous queue, another thread can come in and put another request on it. Sure, that thread will likely block on the physical throttle and so will the rest of the incoming threads, but it still allows the higher level queue to grow past any given limit, with the help of lots of threads. JVM for example? Say you have a device mapper device with some physical device sitting underneath, the classic use case for this throttle code. Say 8,000 threads each submit an IO in parallel. The device mapper mapping function will be called 8,000 times with associated resource allocations, regardless of any throttling on the physical device queue. Anyway, your approach is awfully close to being airtight, there is just a small hole. I would be more than happy to be proved wrong about that, but the more I look, the more I see that hole. > > 1) One throttle count per submitted bio is too crude a measure. A > > bio can carry as few as one page or as many as 256 pages. If you > > take only > > It does not matter - we can count bytes, pages, bio vectors or > whatever we like, its just a matter of counter and can be changed > without problem. Quite true. In some cases the simple inc/dec per bio works just fine. But the general case where finer granularity is required comes up in existing code, so there needs to be a plan. 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 Monday 13 August 2007 01:14, Evgeniy Polyakov wrote: > > Oops, and there is also: > > > > 3) The bio throttle, which is supposed to prevent deadlock, can > > itself deadlock. Let me see if I can remember how it goes. > > > > * generic_make_request puts a bio in flight > > * the bio gets past the throttle and initiates network IO > > * net calls sk_alloc->alloc_pages->shrink_caches > > * shrink_caches submits a bio recursively to our block device > > * this bio blocks on the throttle > > * net may never get the memory it needs, and we are wedged > > If system is in such condition, it is already broken - throttle limit > must be lowered (next time) not to allow such situation. Agreed that the system is broken, however lowering the throttle limit gives no improvement in this case. This is not theoretical, but a testable, repeatable result. Instructions to reproduce should show up tomorrow. This bug is now solved in a kludgy way. Now, Peter's patch set offers a much cleaner way to fix this little problem, along with at least one other nasty that it already fixed. 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: Distributed storage.
On Mon, Aug 13, 2007 at 03:12:33AM -0700, Daniel Phillips ([EMAIL PROTECTED]) wrote: > > This is not a very good solution, since it requires all users of the > > bios to know how to free it. > > No, only the specific ->endio needs to know that, which is set by the > bio owner, so this knowledge lies in exactly the right place. A small > handful of generic endios all with the same destructor are used nearly > everywhere. That is what I meant - there will be no way to just alloc a bio and put it, helpers for generic bio sets must be exported and each and every bi_end_io() must be changed to check reference counter and they must know how they were allocated. > > Right now it is hidden. > > And adds additional atomic check (although reading is quite fast) in > > the end_io. > > Actual endio happens once in the lifetime of the transfer, this read > will be entirely lost in the noise. Not always. Sometimes it is called multiple times, but all bi_end_io() callbacks I checked (I believe all in mainline tree) tests if bi_size is zero or not. Endio callback is of course quite rare and additional atomic reading will not kill the system, but why introduce another read? It is possible to provide a flag for endio callback that it is last, but it still requires to change every single callback - why do we want this? > > And for what purpose? To eat 8 bytes on 64bit platform? > > This will not reduce its size noticebly, so the same number of bios > > will be in the cache's page, so what is a gain? All this cleanups and > > logic complicatins should be performed only if after size shring > > increased number of bios can fit into cache's page, will it be done > > after such cleanups? > > Well, exactly, My point from the beginning was that the size of struct > bio is not even close to being a problem and adding a few bytes to it > in the interest of doing the cleanest fix to a core kernel bug is just > not a dominant issue. So, I'm a bit lost... You say it is too big and some parts can be removed or combined, and then that size does not matter. Last/not-last checks in the code is not clear design, so I do not see why it is needed at all if not for size shrinking. > I suppose that leaving out the word "bloated" and skipping straight to > the "doesn't matter" proof would have saved some bandwidth. :) Likely it will. -- 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] [70/2many] MAINTAINERS - ARPD SUPPORT
On Sun, 12 Aug 2007 23:23:36 -0700 [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 90c1b81..ac2226b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -697,6 +697,7 @@ ARPD SUPPORT > P: Jonathan Layes > L: netdev@vger.kernel.org > S: Maintained > +F: net/ipv4/arp.c NAK arp.c is the netdev people, ARPD is a corner case bit of code within it, something your patterns don't actually cope with - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Distributed storage.
On Monday 13 August 2007 03:22, Jens Axboe wrote: > I never compared the bio to struct page, I'd obviously agree that > shrinking struct page was a worthy goal and that it'd be ok to uglify > some code to do that. The same isn't true for struct bio. I thought I just said that. 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: Distributed storage.
On Mon, Aug 13 2007, Daniel Phillips wrote: > On Monday 13 August 2007 03:06, Jens Axboe wrote: > > On Mon, Aug 13 2007, Daniel Phillips wrote: > > > Of course not. Nothing I said stops endio from being called in the > > > usual way as well. For this to work, endio just needs to know that > > > one call means "end" and the other means "destroy", this is > > > trivial. > > > > Sorry Daniel, but your suggestions would do nothing more than uglify > > the code and design. > > Pretty much exactly what was said about shrinking struct page, ask Bill. > The difference was, shrinking struct page actually mattered whereas > shrinking struct bio does not, and neither does expanding it by a few > bytes. Lets back this up a bit - this whole thing began with you saying that struct bio was bloated already, which I said wasn't true. You then continued to hand wave your wave through various suggestions to trim the obvious fat from that structure, none of which were nice or feasible. I never compared the bio to struct page, I'd obviously agree that shrinking struct page was a worthy goal and that it'd be ok to uglify some code to do that. The same isn't true for struct bio. And we can expand struct bio if we have to, naturally. And I've done it before, which I wrote in the initial mail. I just don't want to do it casually, then it WILL be bloated all of a sudden. Your laissez faire attitude towards adding members to struct bio "oh I'll just add it and someone less lazy than me will fix it up in the future" makes me happy that you are not maintaining anything that I use. I'll stop replying to your mails until something interesting surfaces. I've already made my points clear about both the above and the throttling. And I'd advise you to let Evgeniy take this forward, he seems a lot more adept to actually getting CODE done and - at least from my current and past perspective - is someone you can actually have a fruitful conversation with. -- Jens Axboe - 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.
On Monday 13 August 2007 03:06, Jens Axboe wrote: > On Mon, Aug 13 2007, Daniel Phillips wrote: > > Of course not. Nothing I said stops endio from being called in the > > usual way as well. For this to work, endio just needs to know that > > one call means "end" and the other means "destroy", this is > > trivial. > > Sorry Daniel, but your suggestions would do nothing more than uglify > the code and design. Pretty much exactly what was said about shrinking struct page, ask Bill. The difference was, shrinking struct page actually mattered whereas shrinking struct bio does not, and neither does expanding it by a few bytes. 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
drivers/net/tokenring/3c359.c
Hi,
Replacing kmalloc with kzalloc and cleaning up memset in
drivers/net/tokenring/3c359.c
Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/tokenring/3c359.c b/drivers/net/tokenring/3c359.c
index 9f1b6ab..d36dd53 100644
--- a/drivers/net/tokenring/3c359.c
+++ b/drivers/net/tokenring/3c359.c
@@ -641,14 +641,14 @@ static int xl_open(struct net_device *dev)
* Now to set up the Rx and Tx buffer structures
*/
/* These MUST be on 8 byte boundaries */
- xl_priv->xl_tx_ring = kmalloc((sizeof(struct xl_tx_desc) *
XL_TX_RING_SIZE) + 7, GFP_DMA | GFP_KERNEL) ;
+ xl_priv->xl_tx_ring = kzalloc((sizeof(struct xl_tx_desc) *
XL_TX_RING_SIZE) + 7, GFP_DMA | GFP_KERNEL) ;
if (xl_priv->xl_tx_ring == NULL) {
printk(KERN_WARNING "%s: Not enough memory to allocate rx
buffers.\n",
dev->name);
free_irq(dev->irq,dev);
return -ENOMEM;
}
- xl_priv->xl_rx_ring = kmalloc((sizeof(struct xl_rx_desc) *
XL_RX_RING_SIZE) +7, GFP_DMA | GFP_KERNEL) ;
+ xl_priv->xl_rx_ring = kzalloc((sizeof(struct xl_rx_desc) *
XL_RX_RING_SIZE) +7, GFP_DMA | GFP_KERNEL) ;
if (xl_priv->xl_tx_ring == NULL) {
printk(KERN_WARNING "%s: Not enough memory to allocate rx
buffers.\n",
dev->name);
@@ -656,8 +656,6 @@ static int xl_open(struct net_device *dev)
kfree(xl_priv->xl_tx_ring);
return -ENOMEM;
}
- memset(xl_priv->xl_tx_ring,0,sizeof(struct xl_tx_desc) *
XL_TX_RING_SIZE) ;
- memset(xl_priv->xl_rx_ring,0,sizeof(struct xl_rx_desc) *
XL_RX_RING_SIZE) ;
/* Setup Rx Ring */
for (i=0 ; i < XL_RX_RING_SIZE ; i++) {
--
thanks
surya.
-
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
