On Mon, Jan 11, 2021 at 6:39 PM Jakub Kicinski wrote:
>
> On Sun, 10 Jan 2021 21:36:24 -0800 Chris Snook wrote:
> > On Sun, Jan 10, 2021 at 9:28 PM Jakub Kicinski wrote:
> > > Jay was not active in recent years and does not have plans
> > > to
On Sun, Jan 10, 2021 at 9:28 PM Jakub Kicinski wrote:
>
> Jay was not active in recent years and does not have plans
> to return to work on ATLX drivers.
>
> Subsystem ATLX ETHERNET DRIVERS
> Changes 20 / 116 (17%)
> Last activity: 2020-02-24
> Jay Cliburn :
>
On Tue, Nov 17, 2020 at 1:01 AM Heiner Kallweit wrote:
>
> Am 17.11.2020 um 08:43 schrieb Chris Snook:
> > The full text of the preceding comment explains the need:
> >
> > /*
> > * The atl1c chip can DMA to 64-bit addresses, but it uses a single
> > * shar
The full text of the preceding comment explains the need:
/*
* The atl1c chip can DMA to 64-bit addresses, but it uses a single
* shared register for the high 32 bits, so only a single, aligned,
* 4 GB physical address range can be used at a time.
*
* Supporting 64-bit DMA on this hardware is more
Jay Vosburgh wrote:
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
+ memcpy(stats,&local_stats,sizeof(net_device_stats));
FYI, this generates a compiler error (missing the word "struct"
in here). Other than not compiling, the patch seems reasonable. I'll
fix it up and include it i
this one any better?
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 tr
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 i
[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 i
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.
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 amou
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
n using the latest 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_s
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 context
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/driv
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 the
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
+++
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]>
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 the kconfig option CONFIG_ATL1_EXPERIMENTAL,
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 cons
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 di
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 tr
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 tha
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.
Which
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 c
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 that
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:
./drivers/
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 of
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:
./drivers/
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 atomi
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
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
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 fo
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 act
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 wh
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
inl
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 fro
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 efficientl
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:
If
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 fro
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 def
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
word
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 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 scre
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 ker
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
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
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:
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 these
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 th
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 unsaf
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
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 vola
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/at
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-
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
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
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 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:1
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
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:
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
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
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
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.h
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
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]>
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 PROTECTE
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
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
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]>
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
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 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 PROTECTE
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
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
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
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 allow
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
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, an
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, whi
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
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
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 a
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
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 PROTECT
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
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 and
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 c
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
th
Jeff Garzik wrote:
Jay Cliburn wrote:
On Mon, 25 Jun 2007 17:57:20 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
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 E6
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 Ad
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 Tett
rx_add_vid = atl1_vlan_rx_add_vid;
- netdev->vlan_rx_kill_vid = atl1_vlan_rx_kill_vid;
+
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
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
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 tha
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
+++ linu
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
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 un
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.h2
1 - 100 of 108 matches
Mail list logo
