David Miller [EMAIL PROTECTED] wrote on 08/09/2007 09:57:27 AM:
Patrick had suggested calling dev_hard_start_xmit() instead of
conditionally calling the new API and to remove the new API
entirely. The driver determines whether batching is required or
not depending on (skb==NULL) or not.
From: Thomas Graf [EMAIL PROTECTED]
Date: Tue, 31 Jul 2007 23:12:06 +0200
Introduces neigh_cleanup_and_release() to be used after a
neighbour has been removed from its neighbour table. Serves
as preparation to add event notifications.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Applied to
From: Thomas Graf [EMAIL PROTECTED]
Date: Tue, 31 Jul 2007 23:12:35 +0200
Currently neighbour event notifications are limited to update
notifications and only sent if the ARP daemon is enabled. This
patch extends the existing notification code by also reporting
neighbours being removed due to
David Miller wrote:
From: Jan-Bernd Themann [EMAIL PROTECTED]
Date: Fri, 3 Aug 2007 14:41:14 +0200
I think this patch could be the final version for now. It has been tested
on two platforms (power and x86_64) and works very well.
I checked in the LRO patch and the two sample driver ports
to
Hi Jeff,
Aside from the LRO patch that DaveM queued for 2.6.24, here's a small
fix for myri10ge in 2.6.23:
1. Use the pause counter to avoid a needless device reset
Please apply, thanks,
Brice
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
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
I had to add the following patch to fix the build after
the LRO changes, I have no idea how you could have compile
tested that patch let alone done any real testing on it :-/
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 4cc5e6f..0ac0610 100644
---
Here is a small part of missing pieces of IPv6 support for the server.
It deals with the ip_map caching code part.
It changes the ip_map structure to be able to store INET6 addresses.
It adds also the changes in address hashing, and mapping to test it with
INET addresses.
Signed-off-by:
Linus Torvalds wrote:
On Wed, 8 Aug 2007, Chris Snook wrote:
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
can
Hi,
I see there is a bit of complaining on this original resend temporary
patch. But, since it seems to do a good job for some people, here is
my proposal to limit the 'range of fire' a little bit.
Marcin and Jean-Baptiste: try to test this with 2.6.23-rc2, please.
(Unless Ingo or Thomas
On Thu, Aug 09, 2007 at 03:31:10AM -0400, Chris Snook wrote:
Linus Torvalds wrote:
I'd be *much* happier with atomic_read() doing the volatile instead.
The fact is, volatile on data structures is a bug. It's a wart in the C
language. It shouldn't be used. Volatile accesses in *code* can
Jerry Jiang [EMAIL PROTECTED] wrote:
On Wed, 8 Aug 2007 21:18:25 -0700 (PDT)
On Wed, 8 Aug 2007, Chris Snook wrote:
Some architectures currently do not declare the contents of an atomic_t to
be
volatile. This causes confusion since atomic_read() might not actually
read anything if an
On Thu, 09 Aug 2007 11:10:16 +0200
Bodo Eggert [EMAIL PROTECTED] wrote:
Why the *volatile-accesses-in-code* is acceptable, does C standard make it
clear?
http://lwn.net/Articles/233482/
I have read this article before, but What Linus said only focusing on
the conclusion-- The semantics
Ok, as is clear for some the net-2.6.24 tree has been cut
and is at:
kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.24.git
Contents:
1) napi_struct V6 :-)
2) LRO with EHEA and Myri10g ports
3) mac80211 merge with John Linville
4) Some netlink bits from Thomas Graf
5) VETH driver
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:
From: John W. Linville [EMAIL PROTECTED]
Date: Mon, 6 Aug 2007 17:01:31 -0400
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-davem
Pulled, thanks John.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Wed, Aug 08, 2007 at 01:42:43PM +0200, Jarek Poplawski wrote:
Read below please:
On Wed, Aug 08, 2007 at 01:09:36PM +0200, Marcin Ślusarz wrote:
2007/8/7, Jarek Poplawski [EMAIL PROTECTED]:
So, the let's try this idea yet: modified Ingo's x86: activate
HARDIRQS_SW_RESEND patch.
On Thu, 9 Aug 2007, David Miller wrote:
Ok, as is clear for some the net-2.6.24 tree has been cut
and is at:
kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.24.git
I'll be going over the TCP bits Ilpo and I have been discussing
...In case I didn't make it clear previously,
From: Aurelien Jarno [EMAIL PROTECTED]
Fixes various things on the SSB
PCI core driver:
- Correctly write the configuration register value in
ssb_extpci_write_config() for len = 1 or len = 2.
- Set the PCI_LATENCY_TIMER to handle devices on the PCI bus.
- Set the PCI arbiter control to
More comments
---
diff -Nurp NULL ofa_kernel-1.2/drivers/infiniband/hw/nes/nes_hw.c
--- NULL 1969-12-31 18:00:00.0 -0600
+++ ofa_kernel-1.2/drivers/infiniband/hw/nes/nes_hw.c 2007-08-06
20:09:04.0 -0500
+
+#include nes.h
+u32 crit_err_count = 0;
Possible global namespace
On Thu, Aug 09, 2007 at 03:47:57AM -0400, Chris Snook wrote:
If they're not doing anything, sure. Plenty of loops actually do some sort
of real work while waiting for their halt condition, possibly even work
which is necessary for their halt condition to occur, and you definitely
don't
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Thu, 9 Aug 2007 12:50:51 +0300 (EEST)
At least these are trivial to take (after rebase, some come nicely even
from the before tree):
40564051bdb237231e625ba674fdedf6e8373027 [TCP]: Remove num_acked0 checks
from cong.ctrl mods pkts_acked
Herbert Xu wrote:
On Thu, Aug 09, 2007 at 03:47:57AM -0400, Chris Snook wrote:
If they're not doing anything, sure. Plenty of loops actually do some sort
of real work while waiting for their halt condition, possibly even work
which is necessary for their halt condition to occur, and you
Aurélien Charbon wrote:
Here is a small part of missing pieces of IPv6 support for the server.
It deals with the ip_map caching code part.
It changes the ip_map structure to be able to store INET6 addresses.
It adds also the changes in address hashing, and mapping to test it with
INET
On Thursday 09 August 2007 02:15:33 Andi Kleen wrote:
On Wed, Aug 08, 2007 at 05:08:44PM -0400, Chris Snook wrote:
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
From: Heiko Carstens [EMAIL PROTECTED]
Date: Wed, 8 Aug 2007 11:33:00 +0200
Just saw
Michael Buesch wrote:
On Thursday 09 August 2007 02:15:33 Andi Kleen wrote:
On Wed, Aug 08, 2007 at 05:08:44PM -0400, Chris Snook wrote:
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
From: Heiko Carstens [EMAIL PROTECTED]
Date: Wed, 8 Aug 2007 11:33:00
On Thu, 2007-08-09 at 08:40 -0400, Chris Snook wrote:
#define reload_var(x) __asm__ __volatile__ (whatever, x)
I don't know inline assembly that much, but isn't it possible
with that to kind of fake-touch the variable, so the compiler
must reload it (and only it) to make sure it's up to
As recent discussions[1], and bugs[2] have shown, there is a great deal of
confusion about the expected behavior of atomic_read(), compounded by the
fact that it is not the same on all architectures. Since users expect calls
to atomic_read() to actually perform a read, it is not desirable to
This fixes the SSB dependency hell and introduces some
fake-options that only give some advice on what to select.
We live with these fake options only until menuconfig is able
to tell more about needed dependencies and how to resolve them.
Cc: Andrew Morton [EMAIL PROTECTED]
Signed-off-by:
Andrew Morton pisze:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc2/2.6.23-rc2-mm1/
I am experiencing some problems with 8139too
[ 28.847004] 8139too :02:0d.0: region #0 not a PIO resource, aborting
[ 28.854722] Bad IO access at port 0 ()
[ 28.859459]
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on alpha.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-alpha/atomic.h2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-alpha/atomic.h 2007-08-09
David Miller wrote:
I had to add the following patch to fix the build after
the LRO changes, I have no idea how you could have compile
tested that patch let alone done any real testing on it :-/
Whoops. I'm very sorry about that. Future patches will be submitted
by our Linux guy, who knows
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on arm.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-arm/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-arm/atomic.h 2007-08-09 06:30:40.0
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on blackfin. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
---
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on frv. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
---
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on i386, to ensure memory is actually read
each time.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-i386/atomic.h 2007-07-08
19:32:17.0 -0400
+++
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on h8300. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
---
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on ia64.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-ia64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-ia64/atomic.h 2007-08-09
On Thu, Aug 09, 2007 at 01:51:06AM -0700, Andrew Morton wrote:
...
- There is a new e1000 driver in git-netdev-all, called e1000e. I'm sure
the developers would like it tested. Please cc netdev@vger.kernel.org on
any reports.
...
Changes since 2.6.23-rc2-mm1:
...
git-netdev-all.patch
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on m32r.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-m32r/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-m32r/atomic.h 2007-08-09 06:55:53.0
On Thursday 09 August 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly casts the variable as volatile in
atomic_read(). This leaves
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on m68knommu. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
---
Isn't it possible through some inline assembly trick
that only a certain variable has to be reloaded?
A volatile cast does that already
-Andi
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on avr32.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-avr32/atomic.h2007-08-08
17:48:52.0 -0400
+++ linux-2.6.23-rc2/include/asm-avr32/atomic.h 2007-08-09 06:33:39.0
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on m68k. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
---
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on mips.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-mips/atomic.h 2007-08-08
17:48:53.0 -0400
+++ linux-2.6.23-rc2/include/asm-mips/atomic.h 2007-08-09
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on parisc.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-parisc/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-parisc/atomic.h2007-08-09
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on powerpc.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-powerpc/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-powerpc/atomic.h 2007-08-09
From: Chris Snook [EMAIL PROTECTED]
Make atomic[64]_read() volatile on s390, to ensure memory is actually read
each time.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-s390/atomic.h 2007-08-08
17:48:53.0 -0400
+++
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on sh64.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-sh64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-sh64/atomic.h 2007-08-09 07:22:50.0
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on sh.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-sh/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-sh/atomic.h2007-08-09 07:21:33.0
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on sparc64.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-sparc64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-sparc64/atomic.h 2007-08-09
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on sparc.
Leave atomic24_t alone, since it's only used by sparc-specific code.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-sparc/atomic.h2007-07-08
19:32:17.0 -0400
+++
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on v850. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
---
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on cris.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-cris/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-cris/atomic.h 2007-08-09 06:38:28.0
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() consistent with atomic64_read() and other architectures
on x86_64.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-x86_64/atomic.h 2007-07-08
19:32:17.0 -0400
+++
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on xtensa.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/include/asm-xtensa/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc2/include/asm-xtensa/atomic.h2007-08-09
Hello folks,
I've discovered two strange behaviours (bugs?) about timestamp
generation:
1. If a program opens an AF_PACKET socket and setup a reception ring
with setsockopt(sock, SOL_PACKET, PACKET_RX_RING), timestamps are
automatically (re)enabled at the reception of every packet.
2. Setting
On Thu, 9 Aug 2007, David Miller wrote:
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Thu, 9 Aug 2007 12:50:51 +0300 (EEST)
Ok, in order to get this started I merged the above patches
into net-2.6.24
I'm exhausted and done for today. :-)
:-)
We can work on the other bits next.
Next
It seems, we can start to think about some preferred solutions,
already. Here are some of my preliminary conclusions and suggestions.
The problem of timeouts with some 'older' network cards seems to hit
mainly x86_64 arch, and after diagnosing and testing (still beeing
done) it's caused by
Paul E. McKenney wrote:
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
architecture-specific compiler-induced bugs due to the fact that
atomic_set() used to imply volatile behavior but no longer does.
When we make the
Arnd Bergmann wrote:
On Thursday 09 August 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly casts the variable as volatile in
From: Chris Snook [EMAIL PROTECTED]
Update atomic_ops.txt to reflect the newly consistent behavior of
atomic_read(), and to note that volatile (in declarations) is now
considered harmful.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc2-orig/Documentation/atomic_ops.txt
On Thu, Aug 09, 2007 at 09:24:42AM -0400, Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on alpha.
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
architecture-specific
On Thu, Aug 09, 2007 at 04:21:54PM +0200, Unai Uribarri ([EMAIL PROTECTED])
wrote:
The attached patch removes the automatic timestamp activation, that
only mmap'ed AF_PACKET sockets perform. I known it can break user
applications, but I believe that it's the correct solution.
How tcpdump with
On Thu, 9 Aug 2007, Jerry Jiang wrote:
and still not to said Why the *volatile-accesses-in-code* is
acceptable
I don't think volatile is necessarily wonderful in code _either_. So I
think the atomic_read() issue would be even better off if we just made
sure everybody behaves well and has
On Thu, Aug 09, 2007 at 10:53:14AM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
architecture-specific compiler-induced bugs due to the fact that
atomic_set() used to
Thanks for these comments.
Chuck Lever wrote:
Some naive questions:
1. If IPv6 support is not configured into the kernel, how does an
IPv6-only cache work?
Yes it should work.
The INET6 structures are only used as containers for both type of address.
I have tested by unabling IPv6 options
Aurélien Charbon wrote:
@@ -112,12 +112,16 @@
return (hash ^ (hash8)) 0xff;
}
#endif
+static inline int hash_ip6(struct in6_addr ip)
+{
+return (hash_ip(ip.s6_addr32[0]) ^ hash_ip(ip.s6_addr32[1])
^ hash_ip(ip.s6_addr32[2]) ^ hash_ip(ip.s6_addr32[3])) ;
+}
How have you
Hi,
I'm opening this ticket as a new subject, even though it looks like it
might be related to the thread Networking dies after random time.
Sorry for the wide CC list, but since my network hasn't died since I
rebooted into 2.6.23-rc2 (after 30+ days at 2.6.22-rc7), I'm wondering
if the problem
On Thu, Aug 09, 2007 at 06:04:34PM +0200, Andi Kleen wrote:
Jarek Poplawski [EMAIL PROTECTED] writes:
It seems, we can start to think about some preferred solutions,
already. Here are some of my preliminary conclusions and suggestions.
The problem of timeouts with some 'older' network
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 10:53:14AM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
architecture-specific compiler-induced bugs due to the fact that
On Thu, Aug 09, 2007 at 11:03:03AM -0400, John Stoffel wrote:
Hi,
Hi, read below, please...
I'm opening this ticket as a new subject, even though it looks like it
might be related to the thread Networking dies after random time.
Sorry for the wide CC list, but since my network hasn't
We can't have split stores because we don't use atomic64_t on 32-bit
architectures.
That's not true; the compiler is free to split all stores
(and reads) from memory however it wants. It is debatable
whether volatile would prevent this as well, certainly
it is unsafe if you want to be
Historically this has been
+accomplished by declaring the counter itself to be volatile, but the
+ambiguity of the C standard on the semantics of volatile make this
practice
+vulnerable to overly creative interpretation by compilers.
It's even worse when accessing through a volatile casted
On Thu, Aug 09, 2007 at 11:24:22AM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 10:53:14AM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
Why not the same access-once semantics for atomic_set() as
for atomic_read()? As this patch stands, it might introduce
Segher Boessenkool wrote:
We can't have split stores because we don't use atomic64_t on 32-bit
architectures.
That's not true; the compiler is free to split all stores
(and reads) from memory however it wants. It is debatable
whether volatile would prevent this as well, certainly
it is unsafe
Segher Boessenkool wrote:
Historically this has been
+accomplished by declaring the counter itself to be volatile, but the
+ambiguity of the C standard on the semantics of volatile make this
practice
+vulnerable to overly creative interpretation by compilers.
It's even worse when accessing
On Thu, Aug 09, 2007 at 10:09:08AM -0400, Chris Snook wrote:
Purify volatile use for atomic_t on sh64.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
On Thu, Aug 09, 2007 at 10:10:34AM -0400, Chris Snook wrote:
Purify volatile use for atomic_t on sh.
Signed-off-by: Chris Snook [EMAIL
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
include/linux/ethtool.h |8 +++
include/linux/netdevice.h |1 +
net/core/ethtool.c| 53 +
3 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
ethtool-copy.h |8
ethtool.8 |8 ++--
ethtool.c | 39 +--
3 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 3a63224..ab9d688
Paul E. McKenney wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad to help pummel any
compiler writer that pulls such a dirty trick, but the C standard really
does permit this.
Yes, but we don't write code for
On Thu, Aug 09, 2007 at 10:01:54AM -0400, Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic[64]_t on parisc.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Sure, why not.
ACKed-by: Kyle McMartin [EMAIL PROTECTED]
-
To unsubscribe from this list: send
On Thu, Aug 09, 2007 at 09:30:28AM -0400, Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Purify volatile use for atomic_t on arm.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Acked-by: Russell King [EMAIL PROTECTED]
--
Russell King
Linux kernel2.6 ARM Linux -
On Thu, Aug 09, 2007 at 12:36:17PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad to help pummel any
compiler writer that pulls such a dirty trick, but the C standard
Dave, could you please hold this portion of the patch for a moment. I
will test this patch ASAP. According to our previous experience, this
changes significant changes some IPoIB driver performance.
If you adjust your quantum while doing that testing you may find an
optimal value.
Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Make atomic_read() volatile on frv. This ensures that busy-waiting
for an interrupt handler to change an atomic_t won't get compiled to an
infinite loop, consistent with SMP architectures.
To head off the criticism, I admit this is an
Adrian Bunk wrote:
On Thu, Aug 09, 2007 at 01:51:06AM -0700, Andrew Morton wrote:
...
- There is a new e1000 driver in git-netdev-all, called e1000e. I'm sure
the developers would like it tested. Please cc netdev@vger.kernel.org on
any reports.
...
Changes since 2.6.23-rc2-mm1:
...
On Thursday 09 August 2007, Chris Snook wrote:
a) chicken and egg: asm-generic/atomic.h depends on definitions in
asm/atomic.h
Ok, I see.
If you can find a way to reshuffle the code and make it simpler, I personally
am
all for it. I'm skeptical that you'll get much to show for the
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 12:36:17PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad to help pummel any
compiler writer that pulls such a dirty
+config INFINIBAND_NES
+tristate NetEffect RNIC Driver
+depends on PCI INET INFINIBAND
You don't need the dependency on INFINIBAND any more, because the
whole drivers/infiniband/Kconfig file is guarded by an if INFINIBAND
- R.
-
To unsubscribe from this list: send the line
+ifdef CONFIG_INFINIBAND_NES_DEBUG
+EXTRA_CFLAGS += -DNES_DEBUG
+endif
I would just use the CONFIG_INFINIBAND_NES_DEBUG symbol directly in
your code.
+EXTRA_CFLAGS += -DNES_MINICM
If you're defining this unconditionally, can you just get rid of all
the tests of this symbol?
- R.
-
To
+atomic_t cm_connects;
+atomic_t cm_accepts;
+atomic_t cm_disconnects;
+atomic_t cm_closes;
+atomic_t cm_connecteds;
+atomic_t cm_connect_reqs;
+atomic_t cm_rejects;
do you really want to take the hit of a LOCK prefix each time you
increment a stat???
I think these are
On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 12:36:17PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
The compiler is within its rights to read a 32-bit quantity 16 bits at
at time, even on a 32-bit machine. I would be glad
On 08/09/2007 03:31 AM, Chris Snook wrote:
Fair enough. Casting to (volatile int *) will give us the behavior
people expect when using atomic_t without needing to use inefficient
barriers.
You can use this forget() macro to make the compiler reread a variable:
#define forget(var) asm
Dave, could you please hold this portion of the patch for a moment. I will
test this patch ASAP. According to our previous experience, this changes
significant changes some IPoIB driver performance.
I reverted everything Roland had an issue with, I got tired of arguing
my position
On Thu, 2007-08-09 at 13:36 -0400, Chuck Ebbert wrote:
Fair enough. Casting to (volatile int *) will give us the behavior
people expect when using atomic_t without needing to use inefficient
barriers.
You can use this forget() macro to make the compiler reread a
variable:
#define
On Thu, 9 Aug 2007, Chuck Ebbert wrote:
You can use this forget() macro to make the compiler reread a variable:
#define forget(var) asm volatile ( : =m(var))
No. That will also make the compiler forget any previous writes to it,
so it changes behaviour.
You'd have to use +m.
On jue, 2007-08-09 at 18:33 +0400, Evgeniy Polyakov wrote:
On Thu, Aug 09, 2007 at 04:21:54PM +0200, Unai Uribarri ([EMAIL PROTECTED])
wrote:
The attached patch removes the automatic timestamp activation, that
only mmap'ed AF_PACKET sockets perform. I known it can break user
applications,
1 - 100 of 162 matches
Mail list logo
