अभिजित भोपटकर (Abhijit Bhopatkar) wrote:
The mm structures of interactive tasks are marked and
the pages belonging to them are never shifted to inactive
list in lru algorithm. Thus keeping interactive tasks in
memory as long as possible.
The interactivity is already determined by schedular so
we
LAPLACE Cyprien wrote:
An example: in kernel/pid.c:alloc_pid(), if one of the guest CPUs is
descheduled when holding the pidmap_lock, what happens to the other
guest CPUs who want to alloc/free pids ? Are they blocked too ?
Yup. This is where it's really nice to have directed yields, where
Al Viro wrote:
NB: driver is choke-full of code that will break on big-endian; as long
as the hardware is onboard-only we can live with that, but sooner or
later that'll need fixing.
Signed-off-by: Al Viro [EMAIL PROTECTED]
---
drivers/net/atl1/atl1_main.c |4 ++--
1 files changed, 2
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
v j wrote:
You don't get it do you. Our source code is meaningless to the Open
Source community at large. It is only useful to our tiny set of
competitors that have nothing to do with Linux. The Embedded space is
very specific. We are only _using_ Linux. Just as we could have used
VxWorks or
Linus Torvalds wrote:
On Thu, 5 Apr 2007, Robin Holt wrote:
For testing, Jack Steiner create the following patch. All it does
is moves tasks which are transitioning to the zombie state from where
they are in the children list to the head of the list. In this way,
they will be the first found
Chris Snook wrote:
Linus Torvalds wrote:
On Thu, 5 Apr 2007, Robin Holt wrote:
For testing, Jack Steiner create the following patch. All it does
is moves tasks which are transitioning to the zombie state from where
they are in the children list to the head of the list. In this way
Eric W. Biederman wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
I'm not sure anybody would really be unhappy with pptr pointing to some
magic and special task that has pid 0 (which makes it clear to everybody
that the parent is something special), and that has SIGCHLD set to SIG_IGN
(which
The generic lseek code in fs/read_write.c uses hardcoded values for
SEEK_{SET,CUR,END}.
Patch 1 fixes the case statements to use the symbolic constants in
include/linux/fs.h, and should not be at all controversial.
Patch 2 adds a SEEK_MAX and uses it to validate user arguments. This makes
the
From: Chris Snook [EMAIL PROTECTED]
Convert magic numbers to SEEK_* values from fs.h
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--
--- a/fs/read_write.c 2007-02-20 14:49:45.0 -0500
+++ b/fs/read_write.c 2007-02-20 16:48:39.0 -0500
@@ -37,10 +37,10 @@ loff_t
From: Chris Snook [EMAIL PROTECTED]
Add SEEK_MAX and use it to validate lseek arguments from userspace.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--
diff -urp b/fs/read_write.c c/fs/read_write.c
--- b/fs/read_write.c 2007-02-20 16:48:39.0 -0500
+++ c/fs/read_write.c 2007-02-20 16
Paa Paa wrote:
I'm using Linux 2.6.20.4. I noticed that I get lower SATA hard drive
throughput with 2.6.20.4 than with 2.6.19. The reason was that 2.6.20
enables NCQ by defauly (queue_depth = 31/32 instead of 0/32). Transfer
rate was measured using hdparm -t:
With NCQ (queue_depth == 31):
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
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
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
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-07-08 19:32:17.0
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
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.)
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
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
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
[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:
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
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
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
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
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.html
Please read the FAQ at http://www.tux.org/lkml/
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
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
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 Snook [EMAIL
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/mmu_32.h 1969-12
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/include/asm-x86/a.out_32.h
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-x86/div64_32.h
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
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
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
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/Kconfig.debug
@@ -524,6
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 it from
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 |
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
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
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
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
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
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
Justin Piszcz wrote:
Is there anyway to get/see what parameters were passed to a kernel
module? Running modinfo -p module 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
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
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
Satyam Sharma wrote:
[ Just cleaning up my inbox, and stumbled across this thread ... ]
On 5/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Introduce CONFIG_STABLE to control checks only useful for development.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
[...]
menu General setup
Satyam Sharma wrote:
On 7/20/07, Chris Snook [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
[ Just cleaning up my inbox, and stumbled across this thread ... ]
On 5/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Introduce CONFIG_STABLE to control checks only useful for development
Satyam Sharma wrote:
On 7/20/07, Chris Snook [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
On 7/20/07, Chris Snook [EMAIL PROTECTED] wrote:
Satyam Sharma wrote:
[ Just cleaning up my inbox, and stumbled across this thread ... ]
On 5/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote
Tong Li wrote:
This patch extends CFS to achieve better fairness for SMPs. For example,
with 10 tasks (same priority) on 8 CPUs, it enables each task to receive
equal CPU time (80%). The code works on top of CFS and provides SMP
fairness at a coarser time grainularity; local on each CPU, it
Chris Snook wrote:
Tong Li wrote:
This patch extends CFS to achieve better fairness for SMPs. For
example, with 10 tasks (same priority) on 8 CPUs, it enables each task
to receive equal CPU time (80%). The code works on top of CFS and
provides SMP fairness at a coarser time grainularity
Tong Li wrote:
On Mon, 23 Jul 2007, Chris Snook wrote:
This patch is massive overkill. Maybe you're not seeing the overhead
on your 8-way box, but I bet we'd see it on a 4096-way NUMA box with a
partially-RT workload. Do you have any data justifying the need for
this patch?
Doing
Aaron Porter wrote:
I'm in the process up upgrading a pool of apache servers from
2.6.17.8 to 2.6.21.5, and we're seeing a pretty major change in behavior.
Under identical network load, 2.6.21 has a load average more than 3 times
higher, cpu 0 spends well over 90% of its time in
Aaron Porter wrote:
On Tue, Jul 24, 2007 at 08:48:00PM +0200, Andi Kleen wrote:
Aaron Porter [EMAIL PROTECTED] writes:
I'm in the process up upgrading a pool of apache servers from
2.6.17.8 to 2.6.21.5, and we're seeing a pretty major change in behavior.
Under identical network load,
Chris Friesen wrote:
Chris Snook wrote:
Concerns aside, I agree that fairness is important, and I'd really
like to see a test case that demonstrates the problem.
One place that might be useful is the case of fairness between resource
groups, where the load balancer needs to consider each
Li, Tong N wrote:
On Tue, 2007-07-24 at 16:39 -0400, Chris Snook wrote:
Divining the intentions of the administrator is an AI-complete problem and we're
not going to try to solve that in the kernel. An intelligent administrator
could also allocate 50% of each CPU to a resource group
Bill Huey (hui) wrote:
On Tue, Jul 24, 2007 at 04:39:47PM -0400, Chris Snook wrote:
Chris Friesen wrote:
We currently use CKRM on an SMP machine, but the only way we can get away
with it is because our main app is affined to one cpu and just about
everything else is affined to the other
Chris Friesen wrote:
Chris Snook wrote:
I don't think Chris's scenario has much bearing on your patch. What
he wants is to have a task that will always be running, but can't
monopolize either CPU. This is useful for certain realtime workloads,
but as I've said before, realtime requires
Chris Friesen wrote:
Ingo Molnar wrote:
the 3s is the problem: change that to 60s! We no way want to
over-migrate for SMP fairness, the change i did gives us reasonable
long-term SMP fairness without the need for high-rate rebalancing.
Actually, I do have requirements from our engineering
Li, Tong N wrote:
On Wed, 2007-07-25 at 16:55 -0400, Chris Snook wrote:
Chris Friesen wrote:
Ingo Molnar wrote:
the 3s is the problem: change that to 60s! We no way want to
over-migrate for SMP fairness, the change i did gives us reasonable
long-term SMP fairness without the need for high
Tong Li wrote:
I'd like to clarify that I'm not trying to push this particular code to
the kernel. I'm a researcher. My intent was to point out that we have a
problem in the scheduler and my dwrr algorithm can potentially help fix
it. The patch itself was merely a proof-of-concept. I'd be
Tong Li wrote:
On Fri, 27 Jul 2007, Chris Snook wrote:
Tong Li wrote:
I'd like to clarify that I'm not trying to push this particular code
to the kernel. I'm a researcher. My intent was to point out that we
have a problem in the scheduler and my dwrr algorithm can potentially
help fix
Tim Chen wrote:
Ingo,
Volanomark slows by 80% with CFS scheduler on 2.6.23-rc1.
Benchmark was run on a 2 socket Core2 machine.
The change in scheduler treatment of sched_yield
could play a part in changing Volanomark behavior.
In CFS, sched_yield is implemented
by dequeueing and
Al Boldi wrote:
People wrote:
I believe the users who say their apps really do get paged back in
though, so suspect that's not the case.
Stopping the bush-circumference beating, I do not. -ck (and gentoo) have
this massive Calimero thing going among their users where people are
much less
Bill Huey (hui) wrote:
On Fri, Jul 27, 2007 at 07:36:17PM -0400, Chris Snook wrote:
I don't think that achieving a constant error bound is always a good thing.
We all know that fairness has overhead. If I have 3 threads and 2
processors, and I have a choice between fairly giving each thread
Andrea Arcangeli wrote:
On Fri, Jul 27, 2007 at 08:31:19PM -0400, Chris Snook wrote:
I think Volanomark is being pretty stupid, and deserves to run slowly, but
Indeed, any app doing what volanomark does is pretty inefficient.
But this is not the point. I/O schedulers are pluggable to help
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
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,
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
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
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
[EMAIL PROTECTED] wrote:
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/MAINTAINERS b/MAINTAINERS
index b8bb108..d9d1bcc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -752,6 +752,7 @@ L: [EMAIL PROTECTED]
W:
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
Chris Snook wrote:
[EMAIL PROTECTED] wrote:
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/MAINTAINERS b/MAINTAINERS
index b8bb108..d9d1bcc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -752,6 +752,7 @@ L:[EMAIL PROTECTED]
W:http
Notably absent is a patch for powerpc. I expect Segher Boessenkool's assembly
implementation should suffice there:
http://lkml.org/lkml/2007/8/10/470
Thanks to all who commented on previous incarnations.
-- Chris Snook
-
To unsubscribe from this list: send the line unsubscribe linux
From: Chris Snook [EMAIL PROTECTED]
Document proper use of volatile for atomic_t operations.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/Documentation/atomic_ops.txt 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/Documentation/atomic_ops.txt 2007-08
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on alpha.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-alpha/atomic.h2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-alpha/atomic.h 2007-08-13 05:00
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on arm.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-arm/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-arm/atomic.h 2007-08-13 04:44
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on avr32.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-avr32/atomic.h2007-08-13
03:14:13.0 -0400
+++ linux-2.6.23-rc3/include/asm-avr32/atomic.h 2007-08-13 04:48
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on blackfin.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-blackfin/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-blackfin/atomic.h 2007-08-13
05
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on cris.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-cris/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-cris/atomic.h 2007-08-13 05:23
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on frv.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-frv/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-frv/atomic.h 2007-08-13 05:27
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on h8300.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-h8300/atomic.h2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-h8300/atomic.h 2007-08-13 05:29
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on i386.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-i386/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-i386/atomic.h 2007-08-13 05:31
From: Chris Snook [EMAIL PROTECTED]
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
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-ia64/atomic.h 2007-07-08
19:32
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on m32r.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-m32r/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-m32r/atomic.h 2007-08-13 05:42
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on m68knommu.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-m68knommu/atomic.h2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-m68knommu/atomic.h 2007
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on m68k.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-m68k/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-m68k/atomic.h 2007-08-13 05:45
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.h2007-08-13
05
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-08-13 06:04
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-08-13 05:52
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-08-13 06:19
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
+++ linux-2.6.23-rc3/include
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 2007-08-13
06
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-08-13 06:08
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-08-13 06:07
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.h2007-08-13
06
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.h2007-08-13
06
1 - 100 of 488 matches
Mail list logo
