;
+
netdev-ethtool_ops = atl1_ethtool_ops;
adapter-bd_number = cards_found;
adapter-pci_using_64 = pci_using_64;
As the comments indicate, I was going to get around to doing this in my
Copious Free Time anyway, so:
Acked-By: Chris Snook [EMAIL PROTECTED]
-
To unsubscribe from
Luca Tettamanti wrote:
Il Mon, Jun 25, 2007 at 07:42:44AM -0500, Jay Cliburn ha scritto:
Jay L. T. Cornwall wrote:
Jay Cliburn wrote:
For reasons not yet clear to me, it appears the L1 driver has a bug or
the device itself has trouble with DMA in high memory. This patch,
drafted by Luca
Jay L. T. Cornwall wrote:
Chris Snook wrote:
What boards have we seen this on? It's quite possible this is:
I can reproduce on an Asus P5K with a Core 2 Duo E6600.
lspci identifies the controller as:
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
Ethernet Adapter
Rick Jones wrote:
It seems that every driver, when providing support for ethtool -S
functionality, has considerable lattitude when it comes to the stats
provided. Clearly this is very nice for the driver writer(s) as it
allows them to provide whatever stats they feel are most natural for
Happy Boxing Day!
If you just turned on your shiny new box and discovered that it's got
an Attansic L1 gigabit ethernet chip in it, and can't get Linux to
recognize it, fear not. Jay and I are still working on getting the
driver ready for merging. A lot of the fancy stuff is un(der)tested,
From: Chris Snook [EMAIL PROTECTED]
Add PCI ID for the Attansic L2 100 Mb ethernet adapter.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.21-rc5.orig/include/linux/pci_ids.h 2007-03-27
23:26:50.0 -0400
+++ linux-2.6.21-rc5/include/linux/pci_ids.h2007-03-28 15:11
From: Chris Snook [EMAIL PROTECTED]
Some atl1 boards get their MAC address written directly to the register
by the BIOS during POST, rather than storing it in EEPROM that's
accessible to the driver. If the MAC register on one of these boards
is changed and then the module is unloaded
Jeff Garzik wrote:
Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Some atl1 boards get their MAC address written directly to the register
by the BIOS during POST, rather than storing it in EEPROM that's
accessible to the driver. If the MAC register on one of these boards
is changed
Jeff Garzik wrote:
Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Add PCI ID for the Attansic L2 100 Mb ethernet adapter.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.21-rc5.orig/include/linux/pci_ids.h2007-03-27
23:26:50.0 -0400
+++ linux-2.6.21-rc5
Kok, Auke wrote:
Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Remove unnecessary irq_sem accounting from e1000. Tested with no
problems.
the major problem with this is that one of the e1000 parts (82547) still
requires the irq_sem. I doubt that you tested that card specifically
Jay Cliburn wrote:
Please accept the following trivial patches to the atl1 driver.
- use dev_printk macros
- fix whitespace damage
Acked-By: Chris Snook [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
Al Viro wrote:
Spot the bug...
Signed-off-by: Al Viro [EMAIL PROTECTED]
---
diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c
index 08b2d78..e28707a 100644
--- a/drivers/net/atl1/atl1_hw.c
+++ b/drivers/net/atl1/atl1_hw.c
@@ -357,7 +357,7 @@ void atl1_hash_set(struct atl1_hw
Hey folks --
While digging through the atl1 source, I was troubled by the code using
irq_sem. I did some digging and found the same code in e1000 and ixgb. I'm
not entirely sure what it was originally intended to do, but it doesn't seem
to be doing anything useful now, except possibly
From: Chris Snook [EMAIL PROTECTED]
Remove unnecessary irq_sem code from atl1 driver. Tested with no problems.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Signed-off-by: Jay Cliburn [EMAIL PROTECTED]
--
diff -urp linux-2.6.20-git14.orig/drivers/net/atl1/atl1.h
linux-2.6.20-git14/drivers/net
From: Chris Snook [EMAIL PROTECTED]
Remove unnecessary irq_sem accounting from e1000. Tested with no problems.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--
diff -urp linux-2.6.20-git14.orig/drivers/net/e1000/e1000.h
linux-2.6.20-git14/drivers/net/e1000/e1000.h
--- linux-2.6.20-git14.orig
From: Chris Snook [EMAIL PROTECTED]
Remove irq_sem from ixgb. Currently untested, but similar to tested patches
on atl1 and e1000.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--
diff -urp linux-2.6.20-git14.orig/drivers/net/ixgb/ixgb.h
linux-2.6.20-git14/drivers/net/ixgb/ixgb.h
--- linux
Jeff Garzik wrote:
Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Remove unnecessary irq_sem code from atl1 driver. Tested with no
problems.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Signed-off-by: Jay Cliburn [EMAIL PROTECTED]
ACK, but patch does not apply:
Applying 'remove
Chuck Ebbert wrote:
I have a report of random errors when using the atl1 driver
with kernel 2.6.22.1. Could that be a problem fixed by the
recent changes to DMA setup in 2.6.23-rc?
I hope so. As far as we can tell the driver and the NIC itself are doing the
right thing, and the pci layer or
Chuck Ebbert wrote:
On 07/25/2007 05:22 PM, Chris Snook wrote:
Chuck Ebbert wrote:
I have a report of random errors when using the atl1 driver
with kernel 2.6.22.1. Could that be a problem fixed by the
recent changes to DMA setup in 2.6.23-rc?
I hope so. As far as we can tell the driver
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 this while grepping for atomic_reads in a while loops.
Maybe we should re-add the volatile to atomic_t. Not sure.
I think
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 02:31:15PM -0700, Andrew Morton wrote:
On Wed, 08 Aug 2007 17:08:44 -0400
Chris Snook [EMAIL PROTECTED] wrote:
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
From: Heiko Carstens [EMAIL PROTECTED]
Date: Wed
From: Chris Snook [EMAIL PROTECTED]
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 break code that loops
Jesper Juhl wrote:
On 09/08/2007, Chris Snook [EMAIL PROTECTED] wrote:
From: Chris Snook [EMAIL PROTECTED]
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
Lennert Buytenhek wrote:
On Wed, Aug 08, 2007 at 07:07:33PM -0400, Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
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
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
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
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
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
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 09:19
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]
--- linux-2.6.23
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]
--- linux-2.6.23-rc2
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
+++ linux-2.6.23-rc2/include/asm-i386
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]
--- linux-2.6.23-rc2
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 06:53
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
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]
--- linux-2.6.23
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]
--- linux-2.6.23-rc2
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 07:02
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
07:11
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
07
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
+++ linux-2.6.23-rc2/include/asm
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
07
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
+++ linux
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]
--- linux-2.6.23-rc2
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
+++ linux-2.6.23-rc2/include/asm
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
07:54
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
atomic_read
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 2007
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
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
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
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
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
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
If you're depending on volatile writes
being visible to other CPUs, you're screwed either way, because the CPU can
hold that data in cache as long as it wants before it writes
Segher Boessenkool wrote:
The only safe way to get atomic accesses is to write
assembler code. Are there any downsides to that? I don't
see any.
The assumption that aligned word reads and writes are atomic, and that
words are aligned unless explicitly packed otherwise, is endemic in
the
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
If you're depending on volatile writes
being visible to other CPUs, you're screwed either
Segher Boessenkool 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
Geert Uytterhoeven wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
Segher Boessenkool wrote:
The only safe way to get atomic accesses is to write
assembler code. Are there any downsides to that? I don't
see any.
The assumption that aligned word reads and writes are atomic, and that
words
Segher Boessenkool wrote:
Explicit
+casting in atomic_read() ensures consistent behavior across
architectures
+and compilers.
Even modulo compiler bugs, what makes you believe that?
When you declare a variable volatile, you don't actually tell the
compiler where you want to override its
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 03:24:40PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
Paul E. McKenney wrote:
On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote
David Howells wrote:
Chris Snook [EMAIL PROTECTED] wrote:
To head off the criticism, I admit this is an oversimplification, and true
busy-waiters should be using cpu_relax(), which contains a barrier.
Why would you want to use cpu_relax()? That's there to waste time efficiently,
isn't
Luck, Tony wrote:
+#define atomic_read(v) (*(volatile __s32 *)(v)-counter)
+#define atomic64_read(v) (*(volatile __s64 *)(v)-counter)
#define atomic_set(v,i)(((v)-counter) = (i))
#define atomic64_set(v,i) (((v)-counter) = (i))
Losing the volatile from the
Luck, Tony wrote:
Use atomic64_read to read an atomic64_t.
Thanks Andreas!
Chris: This bug is why the 8-byte loads got changed to 4-byte + sign-extend
by your change to atomic_read().
I figured as much. Thanks for confirming this.
With this applied together with shuffling the volatile
Linus Torvalds wrote:
On Fri, 10 Aug 2007, Luck, Tony wrote:
Here are the functions in which they occur in the object file. You
may have to chase down some inlining to find the function that
actually uses atomic_*().
Could you just make the atomic_read() and atomic_set() functions be
inline
Paul Mackerras wrote:
Chris Snook writes:
I'll do this for the whole patchset. Stay tuned for the resubmit.
Could you incorporate Segher's patch to turn atomic_{read,set} into
asm on powerpc? Segher claims that using asm is really the only
reliable way to ensure that gcc does what we want
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
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
Christoph Lameter wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly casts the variable as volatile in
atomic_read
Satyam Sharma wrote:
On Tue, 14 Aug 2007, Christoph Lameter wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly
Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
Because atomic operations are generally used for synchronization, which requires
volatile behavior. Most such codepaths currently use an inefficient barrier().
Some forget to and we get bugs, because people assume that atomic_read
Ilpo Järvinen wrote:
On Thu, 16 Aug 2007, Herbert Xu wrote:
We've been through that already. If it's a busy-wait it
should use cpu_relax.
I looked around a bit by using some command lines and ended up wondering
if these are equal to busy-wait case (and should be fixed) or not:
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 10:06:31AM +0200, Stefan Richter wrote:
Do you (or anyone else for that matter) have an example of this?
The only code I somewhat know, the ieee1394 subsystem, was perhaps
authored and is currently maintained with the expectation that each
occurrence
Ilpo Järvinen wrote:
On Thu, 16 Aug 2007, Herbert Xu wrote:
We've been through that already. If it's a busy-wait it
should use cpu_relax.
I looked around a bit by using some command lines and ended up wondering
if these are equal to busy-wait case (and should be fixed) or not:
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
Can you find an actual atomic_read code snippet there that is
broken without the volatile modifier?
A whole bunch of atomic_read uses will be broken without the volatile
modifier once we start removing barriers
Linus Torvalds wrote:
So the only reason to add back volatile to the atomic_read() sequence is
not to fix bugs, but to _hide_ the bugs better. They're still there, they
are just a lot harder to trigger, and tend to be a lot subtler.
What about barrier removal? With consistent semantics we
Stefan Richter wrote:
Nick Piggin wrote:
Stefan Richter wrote:
Nick Piggin wrote:
I don't know why people would assume volatile of atomics. AFAIK, most
of the documentation is pretty clear that all the atomic stuff can be
reordered etc. except for those that modify and return a value.
Christoph Lameter wrote:
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
I had totally forgotten
Herbert Xu wrote:
On Mon, Aug 20, 2007 at 09:15:11AM -0400, Chris Snook wrote:
Linus Torvalds wrote:
So the only reason to add back volatile to the atomic_read() sequence is
not to fix bugs, but to _hide_ the bugs better. They're still there, they
are just a lot harder to trigger, and tend
David Miller wrote:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 20 Aug 2007 22:46:47 -0700 (PDT)
Ie a barrier() is likely _cheaper_ than the code generation downside
from using volatile.
Assuming GCC were ever better about the code generation badness
with volatile that has been
Denys Vlasenko wrote:
On Friday 24 August 2007 18:06, Christoph Lameter wrote:
On Fri, 24 Aug 2007, Satyam Sharma wrote:
But if people do seem to have a mixed / confused notion of atomicity
and barriers, and if there's consensus, then as I'd said earlier, I
have no issues in going with the
From: Chris Snook [EMAIL PROTECTED]
Introduce Kconfig ATL1_EXPERIMENTAL to separate mature code from less mature
code in the atl1 driver, and remove EXPERIMENTAL designation for ATL1.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Acked-by: Jay Cliburn [EMAIL PROTECTED]
--- a/drivers/net/Kconfig
From: Chris Snook [EMAIL PROTECTED]
Make certain problematic optimizations build-time configurable.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Acked-by: Jay Cliburn [EMAIL PROTECTED]
--- a/drivers/net/atl1/atl1_main.c 2007-09-04 10:12:38.0 -0400
+++ b/drivers/net/atl1/atl1_main.c
Jeff Garzik wrote:
Chris Snook wrote:
The atl1 driver is currently marked EXPERIMENTAL, because a few
supposedly performance-enhancing features still have problems. When
these features are disabled, the driver is completely stable, fully
functional, and performs well.
Patch 1/2 Creates
Luca wrote:
On 9/8/07, Chris Snook [EMAIL PROTECTED] wrote:
From: Chris Snook [EMAIL PROTECTED]
Make certain problematic optimizations build-time configurable.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Acked-by: Jay Cliburn [EMAIL PROTECTED]
--- a/drivers/net/atl1/atl1_main.c 2007-09
From: Chris Snook [EMAIL PROTECTED]
Unambiguously document the fact that atomic_read() and atomic_set()
do not imply any ordering or memory access, and that callers are
obligated to explicitly invoke barriers as needed to ensure that
changes to atomic variables are visible in all contexts
2.6.23-rc7 kernel, with
the atl1 driver
included in that kernel?
-- Chris
??2007-09-20??Chris Snook [EMAIL PROTECTED] ??
wrote:
Dear csnook,
I have one problem in my NIC driver: whenever I use
netif_receive_skb(skb) or netif_rx(skb) to indicate received
Greetings, netdev!
Since the Linux Driver Project apparently has a glut of talent, I figured I'd
ask for a little help with an existing driver. As some of you may know, Jay
Cliburn and I have been working on atl1 since last summer, and we've gotten the
driver merged and stable. It does the
Hey folks --
I've begun cleaning up the atl2 vendor driver for merging. It's very similar
to the atl1 driver, and needs a lot of the same work, though I have already
fixed the 64-bit DMA data corrupter that atl1 users remember so fondly. Right
now this is very raw, and there is a large
Jeff Garzik wrote:
Chris Snook wrote:
Hey folks --
I've begun cleaning up the atl2 vendor driver for merging. It's
very similar to the atl1 driver, and needs a lot of the same work,
though I have already fixed the 64-bit DMA data corrupter that atl1
users remember so fondly. Right now
[EMAIL PROTECTED] wrote:
Hi,
I want to make a bond with my wireless card. The ipw driver create two
interfaces (wlan0 and wmaster0). When i switch the rf_kill button,
ifplug detect wlan0 unplugged but not wmaster0. If i down wlan0 (while
rf_kil ), bonding detect the inactivity when i up the
Jay Cliburn wrote:
On Tue, 22 Jan 2008 04:56:11 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
From: Jay Cliburn [EMAIL PROTECTED]
Update initialization parameters to match the current vendor driver
version 1.2.40.2.
[...]
ACK without any better knowledge... but is
?
This satisfies me.
Acked-by: Chris Snook [EMAIL PROTECTED]
From df475e2eea401f9dc18ca23dab538b99fb9e710c Mon Sep 17 00:00:00 2001
From: Jay Cliburn [EMAIL PROTECTED]
Date: Wed, 23 Jan 2008 21:36:36 -0600
Subject: [PATCH] atl1: simplify tx packet descriptor
The transmit packet descriptor
1 - 100 of 101 matches
Mail list logo
