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
On Fri, Jun 21, 2019 at 11:33 AM Joe Perches wrote:
>
> On Fri, 2019-06-21 at 13:12 -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 21, 2019 at 12:27 PM Joe Perches wrote:
> []
> > > Subsystem specific local PCI #defines without generic
> > > naming is poor style and makes treewide grep and
> > > ref
THOR("Qualcomm Atheros Inc., ");
> -MODULE_DESCRIPTION("Qualcom Atheros 100/1000M Ethernet Network Driver");
> +MODULE_DESCRIPTION("Qualcomm Atheros 100/1000M Ethernet Network Driver");
> MODULE_LICENSE("GPL");
> MODULE_VERSION(ATL1C_DRV_VERSION);
&
Andre Noll wrote:
we are experiencing massive performance problems with two of our
Linux servers that contain 3ware controllers on a Tyan mainboard and
a couple of 1T disks.
During the daily cron job that uses rsync to sync a 500G file system
from another machine to the raid on the 3ware control
From: Chris Snook <[EMAIL PROTECTED]>
Make MARKERS depend on MODULES to prevent build failures with certain configs.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff --git a/init/Kconfig b/init/Kconfig
index dcef8b5..933df15 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -
From: Chris Snook <[EMAIL PROTECTED]>
Make LKDTM depend on BLOCK to prevent build failures with certain configs.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index a370fe8..24b327c 100644
--- a/lib/Kconfig.debug
+++ b/lib/K
Tony Breeds wrote:
On Thu, Feb 14, 2008 at 08:24:27PM -0500, Chris Snook wrote:
Stephen Rothwell wrote:
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome, but
Stephen Rothwell wrote:
Hi all,
Initial status can be seen here
http://kisskb.ellerman.id.au/kisskb/branch/9/ (I hope to make a better
URL soon). Suggestions for more compiler/config combinations are
welcome, but we can't necessarily commit to fulfilling all you
wishes. :-)
i386 allmodconfi
Dhaval Giani wrote:
I am getting the following oops on bootup on 2.6.25-rc1
...
I am booting using kexec with maxcpus=1. It does not have any problems
with maxcpus=2 or higher.
Sounds like another (the same?) kexec cpu numbering bug. Can you
post/link the entire dmesg from both a cold boot
Gene Heskett wrote:
Greetings;
I just rebooted to a new config of 2.6.24, basically trying to strip out the
building of modules I don't use. And I enabled a couple of checks that
weren't checked in the kernel-hacking menu. .config posted on request.
Now the messages log is being spammed at
veerasena reddy wrote:
I have a requirement where i need to execute a user process even when
the kernel is utilizing 100% of CPU time.
In the realtime kernel, hardware interrupt handlers are prioritized
threads, so you can give the userspace process a higher realtime priority.
-- Chr
Lars Noschinski wrote:
Hello!
For an university project, we had to write a toy filesystem (ext2-like),
for which I would like to implement sparse file support. For this, I
digged through the ext2 source code; but I could not find the point,
where ext2 detects holes.
As far as I can see from fs
Yinghai Lu wrote:
On Jan 31, 2008 12:33 AM, Chris Snook <[EMAIL PROTECTED]> wrote:
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
but that file is not need for x86_64
Which means there's no conflict
Yinghai Lu wrote:
why not rename relocs.c to relocs_32.c?
Because we're trying to get rid of all the _32 and _64 files?
-- Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
Gene Heskett wrote:
Greetings all;
This line showed up in my log a couple of hours ago, several minutes removed
from anything else I was doing at the time:
rarian-sk-get-c[31855]: segfault at eip 00b7c153 esp bf9ddf0c error 4
The system acts and feels normal.
Does anyone have a clu
While pondering ways to optimize I/O and swapping on large NUMA machines, I
noticed that the numa_node field in struct device isn't actually used anywhere.
We just have a couple dozen lines of code to conditionally create a sysfs file
that will always return -1. Is anyone even working on code
Al Boldi wrote:
Greetings!
data=ordered mode has proven reliable over the years, and it does this by
ordering filedata flushes before metadata flushes. But this sometimes
causes contention in the order of a 10x slowdown for certain apps, either
due to the misuse of fsync or due to inherent b
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
Vineet Gupta wrote:
I'm trying to implement atomic ops for a CPU which has no inherent
support for Read-Modify-Write Ops. Instead of using a global spin lock
which protects all the atomic APIs, I want to use a spin lock per
instance of atomic_t.
What operations are you using to implement spinlo
Martin Knoblauch wrote:
Hi,
currently I am tracking down an "interesting" effect when writing to a
Solars-10/Sparc based server. The server exports two filesystems. One UFS,
one VXFS. The filesystems are mounted NFS3/TCP, no special options. Linux
kernel in question is 2.6.24-rc6, but it happens
Joe Perches wrote:
drivers/net/atl1/atl1_hw.c |2 +-
drivers/net/atl1/atl1_main.c |2 +-
The atl1 code will be heavily reworked in the 2.6.25 merge window, so this may
cause headaches. Please remove these chunks before merging.
The spelling corr
Muhammad Nowbuth wrote:
Hi all,
Could anyone give some ideas of future pending works which are needed
on the linux kernel?
http://kernelnewbies.org/KernelHacking
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
No. Kernel programming requires what is essentially assembly language with a
lot of syntactic sugar, which C provides. Higher-level languages abstract away
too much detail to be suitable for the sort of bit-pe
H. Peter Anvin wrote:
NOTE: This patch uses a bc(1) script to compute the appropriate
constants.
Perhaps dc would be more appropriate? That's included in busybox.
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
CTED]>
Cc: Chris Snook <[EMAIL PROTECTED]>
Acked-By: Chris Snook <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info
[EMAIL PROTECTED] wrote:
Linux version 2.4.9-e.38smp ([EMAIL PROTECTED]) (gcc
version 2.96 2731 (Red Hat Linux 7.2 2.96-124.7.2)) #1 SMP Wed Feb
11 00:09:01 EST 2004
Ancient vendor kernels are very out of scope for this mailing list. The
following links may be useful:
https://bugzilla
Florian Boelstler wrote:
While running that test driver a delay of about 10ms _exactly_ occurs
every 10 minutes.
This is precisely the sort of thing that BIOS/firmware-level SMI handlers do,
particularly those that have monitoring or management features. Try to
determine if the kernel is doi
Yoav Artzi wrote:
According to my knowledge the PAGE_SIZE on 32bit architectures in 4KB.
Logically, the PAGE_SIZE on 64bit architectures should be 8KB. That's at
least the way I understand it. However, looking at the kernel code of
x86_64, I see the PAGE_SIZE is 4KB.
Can anyone explain to me
ciol wrote:
Chris Snook wrote:
Why are you asking the developers? We do this for the sake of the users.
The kernel is the software of the developers.
The kernel is a technology. A distribution is a product. When decisions about
technology and decisions about products are made
Benny Halevy wrote:
Greetings,
I would like to hear peoples opinion about the indentation convention
described below that I personally found the most practical with
several different editors.
The gist of it is that tabs should be used for nesting, not for decoration.
Indent your code with as ma
ciol wrote:
Hi, I'd like to ask you a few questions:
* Do you like the way linux distributions integrate the kernel?
* Wouldn't you prefer they ship with the stable and still maintained
2.6.16.X, while providing optionally the latest kernel for those who
want or just have a new hardware?
*
Don Porter wrote:
From: Donald E. Porter <[EMAIL PROTECTED]>
In the bulk page allocation/free routines in mm/page_alloc.c, the zone
lock is held across all iterations. For certain parallel workloads, I
have found that releasing and reacquiring the lock for each iteration
yields better performan
Zurk Tech wrote:
dmesg (new) with disabled GART error reporting if anyone wants to
compare to previous dmesg with GART error reporting :
A few unrelated observations about Barcelona support...
Marking TSC unstable due to TSCs unsynchronized
This is probably wrong. The TSC is on the northbr
Latchesar Ionkov wrote:
Sample ramfs file server that uses the in-kernel 9P file server support.
This code is for reference only.
Reference code generally goes in Documentation/
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Zurk Tech wrote:
Hi guys,
I have a tyan s3992 h2000 with single barcelona amd quad core cpu (the
other cpu socket is empty). cat /proc/cpuinfo shows amd quad core
processor
but core : 1ive compiled the kernel from scratch with smp and
amd64 + the numa stuff. i also tried debian etchs amd64 sm
From: Chris Snook <[EMAIL PROTECTED]>
Unify x86 div64.h headers.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff -Nurp a/include/asm-x86/div64_32.h b/include/asm-x86/div64_32.h
--- a/include/asm-x86/div64_32.h2007-10-20 07:33:53.0 -0400
+++ b/include/asm-x8
From: Chris Snook <[EMAIL PROTECTED]>
Unify x86 a.out_32.h and a.out_64.h
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff -Nurp a/include/asm-x86/a.out_32.h b/include/asm-x86/a.out_32.h
--- a/include/asm-x86/a.out_32.h2007-10-20 06:20:01.0 -0400
+++ b/inc
From: Chris Snook <[EMAIL PROTECTED]>
Merge mmu_32.h and mmu_64.h into mmu.h.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
diff -Nurp a/include/asm-x86/mmu_32.h b/include/asm-x86/mmu_32.h
--- a/include/asm-x86/mmu_32.h 2007-10-20 02:42:24.0 -0400
+++ b/include/asm-x86/mm
From: Chris Snook <[EMAIL PROTECTED]>
Most of types_32.h and types_64.h are the same. Merge the common definitions
into types.h, keeping the differences in their own files. Also #error if
types_{32,64}.h is included directly. Tested with allmodconfig on x86_64.
Signed-off-by: Chris
Konstantin Kalin wrote:
P.S. It's simple to add DEV_HAS_CORRECT_MACADDR to pci_device_tlb for
these types of Ethernet. But I think it's not right decision because it
would break older revisions of these models.
Any reason you can't distinguish based on PCI ID?
-- Chris
-
To unsubscrib
Pavel Machek wrote:
Hi!
I've found that gbit vs. 100mbit power consumption difference is about
1W -- pretty significant. (Maybe powertop should include it in the
tips section? :).
Energy Star people insist that machines should switch down to 100mbit
when network is idle, and I guess that makes
Giuliano Gagliardi wrote:
Hello,
I have a server that has to switch to different user ids, but because it does
other complex things, I would rather not have it run as root.
Well, it's probably going to have to *start* as root, or use something like
sudo. It's probably easiest to have it sta
Justin Piszcz wrote:
Kernel: 2.6.23-rc8 (older kernels do this as well)
When running the following command:
/usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n
16:10:16:64
It hangs unless I increase various parameters md/raid such as the
stripe_cache_size etc..
# ps auxww |
from the
declaration of atomic64_t. The following patch fixes that inconsistency,
without delving into anything more controversial.
From: Chris Snook <[EMAIL PROTECTED]>
The volatile keyword has already been removed from the declaration of atomic_t
on x86_64. For consistency, remove i
David Madore wrote:
On Mon, Sep 17, 2007 at 11:11:52AM -0700, Jeremy Fitzhardinge wrote:
Boot memtest86 for a little while before booting the kernel? And if you
haven't already run it for a while, then that would be your first step
anyway.
Indeed, that does the trick, thanks for the suggestio
Lukas Hejtmanek wrote:
Hello,
is it expected that application sending 8900bytes datagram through 10Gbps NIC
utilizes CPU to 100% and similarly the receiver also utilizes CPU to 100%.
Is it something wrong or this is quite OK?
(The box is dual single core Opteron 2.4GHz with Myricom 10GE NIC.)
Venkat Subbiah wrote:
Since most network devices have a single status register for both
receiver and transmit (and errors and the like), which needs a lock to
protect access, you will likely end up with serious thrashing of moving
the lock between cpus.
Any ways to measure the trashing of locks?
From: Chris Snook <[EMAIL PROTECTED]>
The volatile keyword has already been removed from the declaration of atomic_t
on x86_64. For consistency, remove it from atomic64_t as well.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- a/include/asm-x86_64/atomic.h 2007
Jesse Barnes wrote:
I just narrowed down a weird problem where I was losing more than 50% of
my vblank interrupts to what seems to be the hires timers patch. Stock
2.6.23-rc5 works fine, but the latest (171) kernel from rawhide drops
most of my interrupts unless I also have another interrupt s
Venkat Subbiah wrote:
Most of the load in my system is triggered by a single ethernet IRQ.
Essentially the IRQ schedules a tasklet and most of the work is done in the
taskelet which is scheduled in the IRQ. From what I read looks like the
tasklet would be executed on the same CPU on which it was
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
Yishai Hadas wrote:
Hi List,
I'm looking for any mechanism in a multi-threaded process to monitor the
health of its running threads - or by a specific monitor thread or by
any other mechanism.
It includes the following aspects:
1) Threads are running and not stuck on any lock.
If you're
Justin Piszcz wrote:
Is there anyway to get/see what parameters were passed to a kernel
module? Running modinfo -p will show the defaults, but for
example, st, the scsi tape driver, is there a way to see what it is
currently using? I know in dmesg it shows this when you load it
initially (but
Xu Yang wrote:
Hello everyone,
Just got a rough question in my head.
don't know whether anyone interested .
mutex vs cache coherency protocol(for multiprocessor)
both of these two can be used to protect shared resource in the memory.
are both of them necessary?
for example:
in a multiproce
James Georgas wrote:
> That's the vmalloc address space. You only get 896 MB in the NORMAL
> zone on i386, to leave room for vmalloc. If you don't like it, go
64-bit.
>
> -- Chris
I like it fine. I just didn't understand it. Thanks for answering.
So, basically, the vmalloc address
James C. Georgas wrote:
I'm not sure I understand how the kernel calculates the amount of
physical RAM it can map during the boot process.
I've quoted two blocks of kernel messages below, one for a kernel with
NOHIGHMEM and another for a kernel with HIGHMEM4G.
If I do the math on the BIOS provi
Michal Piotrowski wrote:
Hi,
Here is something that might be useful for gamers and audio/video editors
http://www.stardust.webpages.pl/files/tools/deskopt/
You can easily tune CFS/CFQ scheduler params
I would think that gamers and AV editors would want to be using deadline
(or maybe even as)
Anand Jahagirdar wrote:
Hi
consider a case:
if non root user request admin for more number of processes than root
user,admin needs to modify settings in /etc/security/limits.conf file
and if that user is not trustworthy and if does fork bombing attack it
will kill the box.
If root is dumb en
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
Krzysztof Halasa wrote:
Hi,
"Anand Jahagirdar" <[EMAIL PROTECTED]> writes:
I am forwarding one more improved patch which i have modified as
per your suggestions. Insted of KERN_INFO i have used KERN_NOTICE and
i have added one more if block to check hard limit. how good it is?
Not very, s
Hirokazu Takata wrote:
I think the parameter of atomic_read() should have "const"
qualifier to avoid these warnings, and IMHO this modification might be
worth applying on other archs.
I agree.
Here is an additional patch to revise the previous one for m32r.
I'll incorporate this change if
Joe Perches wrote:
On Mon, 2007-08-20 at 15:31 -0400, Chris Snook wrote:
Until I can pass a patch or source file as an argument to a script and get out
the URL of the git tree it needs to go into on the path to Linus's tree,
MAINTAINERS is inadequate. If I ask for the MAINTAINER in
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
Joe Perches wrote:
On Sat, 2007-08-18 at 13:35 -0400, Robert P. J. Day wrote:
$ show_subsystem drivers/bluetooth/bpa10x.c
BLUETOOTH
"what's a subsystem"?
I'm not sure there is an appropriate definition.
If there is an appropriate definition, why
should anyone care what subsystem a particul
Anand Jahagirdar wrote:
Hi
As Per the Previous Discussion of my Patch,I think insted of using
KERN_CRIT,it is better to lower the priority level to KERN_WARNING.
thats why i used KERN_WARNING.it will warn administrator and its
administrator responsibility to take whatever action he want to tak
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
Joe Perches wrote:
I've got a tree with a directory full of separate
MAINTAINER blocks that looks like:
00_file_description
3c359_network_driver
3c505_network_driver
3c59x_network_driver
3cr990_network_driver
...
zd1211rw_wireless_driver
zf_machz_watchdog
zr36067_video_for_linux_driver
zs_decsta
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
Anand Jahagirdar wrote:
Hello All
I have searched for Maintainers List to get the correct
Maintainer for my patch. But i am not getting exact maintainer to
which i should forward my patch. Will any body please tell me,to which
maintainer i should forward my patch for its inclusion?
Su
sk malik wrote:
Solaris 10 people are talkin a lot about the
predictive self healing thing.
Do we have something similar planned/going on for
linux. Or there is no use of this tecnology ;)
Doing this in-kernel would violate the separation of policy and
mechanism. There's nothing wrong with p
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:
On Wed, Aug 15, 2007 at 01:02:23PM -0400, Chris Snook wrote:
Herbert Xu wrote:
Andi Kleen <[EMAIL PROTECTED]> wrote:
My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
textdata bss dec hex filename
3434150 249176 176128 3859454
In the fallout from the recent atomic_t volatility discussions, patches
have been posted to moot the compiler correctness issues by implementing
atomic[64]_[read|set] in inline assembly on powerpc, i386, and x86_64.
While I personally don't consider such implementations to be critically
necessa
Herbert Xu wrote:
Andi Kleen <[EMAIL PROTECTED]> wrote:
My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
textdata bss dec hex filename
3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
3435308 249176 176128 3860612 3ae884 atomic_inlineasm/vmlinu
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
Christoph Lameter wrote:
On Tue, 14 Aug 2007, Chris Snook wrote:
volatile means that there is some vague notion of "read it now". But that
really does not exist. Instead we control visibility via barriers (smp_wmb,
smp_rmb). Would it not be best to not have volatile at all in atomic
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 Mon, 13 Aug 2007, Chris Snook wrote:
@@ -38,7 +45,7 @@
Next, we have:
- #define atomic_read(v) ((v)->counter)
+ #define atomic_read(v) (*(volatile int *)&(v)->counter)
which simply reads the current value of the counter.
volatile means
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
Christoph Lameter wrote:
On Tue, 14 Aug 2007, Luck, Tony wrote:
I re-tried the macros ... the three warnings from mm/slub.c all result in
broken code ... and quite rightly too, they all come from code that does:
atomic_read(&n->nr_slabs)
But the nr_slabs field is an atomic_long_t, so
Luck, Tony wrote:
Use volatile consistently in atomic.h on ia64.
This will do weird things without Andreas Schwab's fix:
http://lkml.org/lkml/2007/8/10/410
The build is very noisy with the inline versions of atomic_{read,set}
and their 64-bit siblings. Here are the prime culprits (some of them
Joe Perches wrote:
On Mon, 2007-08-13 at 02:49 -0400, Chris Snook wrote:
Actually, now that I've seen the format in the intro patch,
it would be simpler just to use this:
F: drivers/net/atl1/
ATL1 ETHERNET DRIVER
P: Jay Cliburn
M: [EMAIL PROTECTED]
P: Chris Sn
On Mon, Aug 13, 2007 at 01:19:31PM +0100, Russell King wrote:
> On Mon, Aug 13, 2007 at 07:09:46AM -0400, Chris Snook wrote:
> > By popular demand, I've redone the patchset to include volatile casts in
> > atomic_set as well. I've also converted the macros to inline fun
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on xtensa.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-xtensa/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-xtensa/atomic.h
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on x86_64.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-x86_64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-x86_64/atomic.h
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on v850.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-v850/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-v850/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on alpha.
Leave sparc-internal atomic24_t type alone.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-sparc/atomic.h2007-07-08
19:32:17.0 -0400
+++ linu
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on sparc64.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-sparc64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-sparc64/atomic.h
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on sh.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-sh/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-sh/atomic.h2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on sh64.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-sh64/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-sh64/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on s390.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-s390/atomic.h 2007-08-13
03:14:13.0 -0400
+++ linux-2.6.23-rc3/include/asm-s390/atomic.h 2007
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on parisc.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-parisc/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-parisc/atomic.h
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on mips.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-mips/atomic.h 2007-08-13
03:14:13.0 -0400
+++ linux-2.6.23-rc3/include/asm-mips/atomic.h 2007
1 - 100 of 246 matches
Mail list logo
