Hi,
Here follows a highly experimental patch for the kernel that catches uses of
uninitialized memory. (Also see the commit message below for more technical
information.)
This is a very early stage implementation. In fact, don't even expect it to
work for you. The only supported arch is x86_32
Upon request I have updated the patch description
and hope it is now more explanatory.
IMHO this should go into 2.6.24.
BTW, the patch was tested with v2.6.24-rc3-19-g2ffbb83.
Regards,
Andreas
--
x86: correctly set UTS_MACHINE for make ARCH=x86
For a kernel built with make ARCH=x86 the
Any UUID generator that can produce duplicate UUIDs with probability
significantly less than purely random UUIDs is so badly broken that it
should not ever be used. Anyone who finds such a UUID generator should
immediately either fix it or throw it on the junk heap. Anyone who knowingly
uses
On Mon, Nov 19, 2007 at 02:32:41PM -0800, David Miller wrote:
From: David Brownell [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 11:59:55 -0800
This addition certainly won't hurt. Did we ever get any feedback as to
whether it actually helped?
ISTR that davem refused to try it, after
On Mon, Nov 19, 2007 at 02:46:09PM -0800, David Miller wrote:
Because sourceforge just farted another bounce at me
because someone CC:'d the sourceforge linux-usb-devel
list on a thread I was a part of, I've created:
[EMAIL PROTECTED]
so we don't need to have a
On Mon, Nov 19, 2007 at 11:22:06PM +0100, Dmitry Adamushko wrote:
You seem to have a configuration with domains which don't have
SD_BALANCE_NEWIDLE on (CONFIG_NUMA?) as there are no events (all
zeros above) for CPU_NEWLY_IDLE.
this one is being triggered whenever a cpu becomes idle
T'was done as a21101c46ca5b4320e31408853cdcbf7cb1ce4ed. The system is
a latitude x300 (i855GM). With '1', the old default, I can close and
re-open the lid and have nothing happening. With '0' the screen turns
black with the mouse cursor left frozen on top of it and the computer
crashed.
This patch adds and changes a few sanity checks in dmar.c.
1. The haw field in ACPI DMAR table in VT-d spec doesn't describe the range of
haw. But since DMA page size is 4KB in DMA remapping, haw should be at least
4KB. The current VT-d code in dmar.c returns failure when haw==0. This sanity
On Tuesday 20 November 2007 01:28:03 Mathieu Desnoyers wrote:
* Rusty Russell ([EMAIL PROTECTED]) wrote:
I think it would be easier to just fast-path the num_online_cpus == 1
case, even if you want to keep this update_early interface.
Nope, that could lead to problems. I call
On Mon, Nov 19, 2007 at 11:38:35AM -0700, Matthew Wilcox wrote:
On Mon, Nov 19, 2007 at 10:19:12AM -0800, Greg Kroah-Hartman wrote:
2.6.22-stable review patch. If anyone has any objections, please let us
know.
Makes sense to backport this.
Acked-by: Matthew Wilcox [EMAIL PROTECTED]
On Mon, Nov 19, 2007 at 07:04:57PM +, Hugh Dickins wrote:
On Mon, 19 Nov 2007, Greg Kroah-Hartman wrote:
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Andrew Morton [EMAIL PROTECTED]
patch
On Mon, Nov 19, 2007 at 08:02:42PM +0100, Ingo Molnar wrote:
* Greg Kroah-Hartman [EMAIL PROTECTED] wrote:
2.6.22-stable review patch. If anyone has any objections, please let
us know.
we shouldnt do this for 2.6.22 - it has no proper cpu_clock() facility
like .23 or .24. So lets
Quoting Chris Friedhoff ([EMAIL PROTECTED]):
Hello Serge,
just to let you know: with 2.6.24-rc3 I have the same problem.
Ok, so here is the flow.
First off, using runlevel 5 on FC7, using 'log out' correctly brings
you back to a new login prompt. Your problem is starting in runlevel
3, and
On Mon, 19 Nov 2007 13:50:30 +0100
Robert Gerlach [EMAIL PROTECTED] wrote:
Am Montag 19 November 2007 05:43:07 schrieb Stephen Hemminger:
On Sun, 18 Nov 2007 23:36:58 +0100
Robert Gerlach [EMAIL PROTECTED] wrote:
Am Dienstag 23 Oktober 2007 21:55:55 schrieb Stephen Hemminger:
On Sat, Nov 17, 2007 at 04:34:56PM -0800, Jeremy Fitzhardinge wrote:
Greg KH wrote:
Great, thanks for tracking this down.
Ingo, this corrisponds to changeset
a115d5caca1a2905ba7a32b408a6042b20179aaa in mainline. Is that patch
incorrect? Should this patch in the -stable tree be
On Sat, Nov 17, 2007 at 11:29:54AM -0700, Alex Chiang wrote:
Hi all,
This is v3 of the pci_slot patch series.
The major change is making the ACPI-PCI slot driver a Kconfig
option, as per the recommendations of others (Gary, Kenji-san).
Alex, What I was trying to suggest is a boot-time
On Monday, 19 of November 2007, Chris Friedhoff wrote:
dmesg output is added.
increasing CONFIG_BLK_DEV_RAM_SIZE from to 131072 hasn't changed
the non-functioning of 2.6.24-rc3
s2disk works with 2.6.23.8 ; I tested 4 cycles in a row, 2 from console
and 2 from within X
I've attached
ACPI uses NR_CPUS in various loops and in some it accesses per cpu
data of processors that are not present(!) and that will never be present.
The pointers to per cpu data are typically not initialized for processors
that are not present. So we seem to be reading something here from offset 0
in
Hello.
Paul Moore wrote:
My apologies, I mistakenly read the following if statement in your patch:
+ if (skb == skb_peek(sk-sk_receive_queue)) {
+ __skb_unlink(skb, sk-sk_receive_queue);
+ atomic_dec(skb-users);
+ }
I read the conditional as
On Mon, 19 Nov 2007, Nick Warne wrote:
[EMAIL PROTECTED]:nick$ sudo /usr/sbin/alsactl -F restore
/usr/sbin/alsactl: set_control:970: failed to obtain info for control
#228 (No such file or directory)
/usr/sbin/alsactl: set_control:970: failed to obtain info for control
#232 (No such file or
An obviously missing closing parenthesis.
Signed-off-by: Kevin Winchester [EMAIL PROTECTED]
---
This is more for practice sending patches than anything else, to make
sure they are not damaged in any way.
But it does bring up a good question. Are patches expected/wanted for
the mmotm kernels?
From: Greg KH [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 14:54:55 -0800
Woah, the [EMAIL PROTECTED] list is NOT a subscriber-only list at
all. It's wide open with a bunch of mailman rule filter to try to
handle the worst of the spam.
It does complain if you try to add too many cc:s to it,
Hi folks,
using the ondemand scaling governour I see some error messages
in kern.log, e.g.:
Nov 20 01:00:46 bugs kernel: BUG: soft lockup detected on CPU#0!
Nov 20 01:00:46 bugs kernel: [c013cf8d] softlockup_tick+0x91/0xa6
Nov 20 01:00:46 bugs kernel: [c012269c] update_process_times+0x3a/0x5d
We have definitions of the CR0 bits in processor-flags.h
Use them instead of hardcoded values in various places.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 205fd5b..93d25a7 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++
On 11/17/2007 07:55 PM, Ingo Molnar wrote:
* Greg KH [EMAIL PROTECTED] wrote:
Great, thanks for tracking this down.
Ingo, this corrisponds to changeset
a115d5caca1a2905ba7a32b408a6042b20179aaa in mainline. Is that patch
incorrect? Should this patch in the -stable tree be reverted?
On Mon, 2007-11-19 at 14:31 -0800, David Miller wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 06:51:14 +1100
On Mon, 2007-11-19 at 00:38 -0800, David Miller wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 16:35:23 +1100
Hello List,
I am trying to get throttling to work on the following processor with
linux 2.6.17-1.2142_FC4
with no luck.
AMD Athlon(tm) XP 1700+
cat /proc/acpi/processor/CPU0/info
processor id:0
acpi id: 0
bus mastering control: no
power management:yes
Trying to do a 32bit build on a 64bit machine.
I did..
make ARCH=i386 oldconfig
make ARCH=i386 arch/x86/
and got..
scripts/kconfig/conf -s arch/x86/Kconfig
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/linux/utsrelease.h
UPD
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 11:34:24 +1100
Do you still think we should introduce this __dma_cacheline_aligned ? Do
you see other cases of drivers where it would be useful ? It tend to
agree with your earlier statement that drivers doing that are
On Mon, Nov 19, 2007 at 07:41:31PM -0500, Stephen Clark wrote:
Hello List,
I am trying to get throttling to work on the following processor
I think by throttling, you actually mean changing frequency/voltage ?
(throttling is something else, where the CPU skips every n cycles,
which
From: Stephane Eranian [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 12:53:30 -0800
In anycase, I would be happy to integrate your sparc64 patches.
I sent these to Philip Mucci late last night, but in the meantime
I finished implementing breakpoint support as well for pfmon.
Let me clean up my
On Mon, 2007-11-19 at 16:46 -0800, David Miller wrote:
1) Require that entire buffers are commited by call sites,
and thus embedding DMA'd within non-DMA stuff isn't allowed
2) Add the __dma_cacheline_aligned tag.
But note that with #2 it could get quite ugly because the
alignment
Robert Hancock wrote:
Tejun Heo wrote:
Robert Hancock wrote:
This fixes some problems with ATAPI devices on nForce4 controllers in
ADMA mode
on systems with memory located above 4GB. We need to delay setting
the 64-bit
DMA mask until the PRD table and padding buffer are allocated so that
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 11:55:01 +1100
BTW. What is the status nowadays with skb's ?
Good question.
Some drivers are problematic (or were) because they put
DMA descriptor chaining information at the head of the
buffer, but those have been fixed
Dave Jones wrote:
On Mon, Nov 19, 2007 at 07:41:31PM -0500, Stephen Clark wrote:
Hello List,
I am trying to get throttling to work on the following processor
I think by throttling, you actually mean changing frequency/voltage ?
(throttling is something else, where the CPU skips every n
On Fri, 16 Nov 2007 14:39:57 -0800
mark gross [EMAIL PROTECTED] wrote:
-#define MAX_FAULT_REASON_IDX ARRAY_SIZE(fault_reason_strings) - 1
+#define MAX_FAULT_REASON_IDX (ARRAY_SIZE(fault_reason_strings) - 1)
hm. The logic in there looks screwy.
static char
On Tue, 20 Nov 2007, Tetsuo Handa wrote:
Hello.
Paul Moore wrote:
My apologies, I mistakenly read the following if statement in your patch:
+ if (skb == skb_peek(sk-sk_receive_queue)) {
+ __skb_unlink(skb, sk-sk_receive_queue);
+
On Mon, 19 Nov 2007 20:16:20 -0400
Kevin Winchester [EMAIL PROTECTED] wrote:
An obviously missing closing parenthesis.
I'm going through complete misery with that file.
---
This is more for practice sending patches than anything else, to make
sure they are not damaged in any way.
From: Stephane Eranian [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 14:48:46 -0800
Looks like we will have to use bytes (u8) instead. This may have some
performance impact as well. Several bitmaps are used in the context/interrupt
routines. Even with u8, there is still a problem with the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harald Dunkel
Sent: Monday, November 19, 2007 4:19 PM
To: Linux Kernel list
Subject: 2.6.23.8, ondemand scaling governor: BUG: soft
lockup detected on CPU#0!
Hi folks,
using the ondemand scaling
This is a pretty early draft stage of the patch. It works on
x86_64 only. Its a bit massive so I'd like to have some feedback
before proceeding (and maybe some help)?.
The support for other arches was not tested yet.
The patch establishes a new set of cpu operations that allow to
exploit single
ACPI uses NR_CPUS in various loops and in some it accesses per cpu
data of processors that are not present(!) and that will never be present.
The pointers to per cpu data are typically not initialized for processors
that are not present. So we seem to be reading something here from offset 0
in
Currently the per cpu subsystem is not able to use the atomic capabilities
of the processors we have.
This adds new functionality that allows the optimizing of per cpu variable
handliong. It in particular provides a simple way to exploit atomic operations
to avoid having to disable itnerrupts or
The core portion of the cpu allocator.
The per cpu allocator allows dynamic allocation of memory on all
processor simultaneously. A bitmap is used to track used areas.
The allocator implements tight packing to reduce the cache footprint
and increase speed since cacheline contention is typically
Using cpu alloc removes the needs for the per cpu arrays in the kmem_cache
struct.
These could get quite big if we have to support system of up to thousands of
cpus.
The use of alloc_percpu means that:
1. The size of kmem_cache for SMP configuration shrinks since we will only
need 1 pointer
Remove the fields in kmem_cache_cpu that were used to cache data from
kmem_cache when they were in different cachelines. The cacheline that holds
the per cpu array pointer now also holds these values. We can cut down the
kmem_cache_cpu size to almost half.
The get_freepointer() and
64 bit:
Set up a cpu area that allows the use of up 16MB for each processor.
Cpu memory use can grow a bit. F.e. if we assume that a pageset
occupies 64 bytes of memory and we have 3 zones in each of 1024 nodes
then we need 3 * 1k * 16k = 50 million pagesets or 3096 pagesets per
processor. This
Virtually map the cpu areas. This allows bigger maximum sizes and to only
populate the virtual mappings on demand.
In order to use the virtual mapping capability the arch must setup some
configuration variables in arch/xxx/Kconfig:
CONFIG_CPU_AREA_VIRTUAL to y
CONFIG_CPU_AREA_ORDER
to
Enable a simple virtual configuration with 32MB available per cpu so that
we do not use a static area on sparc64.
[Not tested. I have no sparc64]
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
arch/sparc64/Kconfig | 15 +++
arch/sparc64/kernel/vmlinux.lds.S |
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
lib/percpu_counter.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6/lib/percpu_counter.c
===
--- linux-2.6.orig/lib/percpu_counter.c
Typical use of per cpu memory for a small system of 8G 8p 4node is less than
64k per cpu memory. This is increasing rapidly for larger systems where we can
get up to 512k or 1M of memory used for cpu storage.
The maximum size allowed of the cpu area is 128MB of memory.
The cpu area is placed in
Use the new cpu_alloc functionality to avoid per cpu arrays in struct zone.
This drastically reduces the size of struct zone for systems with a large
amounts of processors and allows placement of critical variables of struct
zone in one cacheline even on very large systems.
Another effect is that
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
arch/ia64/kernel/crash.c |2 +-
drivers/base/cpu.c |2 +-
kernel/kexec.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/arch/ia64/kernel/crash.c
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
kernel/workqueue.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
Index: linux-2.6/kernel/workqueue.c
===
---
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
arch/x86/kernel/acpi/cstate.c |9 +
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c |7 ---
drivers/acpi/processor_perflib.c |4 ++--
3 files changed, 11 insertions(+), 9 deletions(-)
Index:
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
drivers/net/veth.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/drivers/net/veth.c
===
--- linux-2.6.orig/drivers/net/veth.c 2007-11-15
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
drivers/net/chelsio/sge.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
Index: linux-2.6/drivers/net/chelsio/sge.c
===
---
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
drivers/net/loopback.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
Index: linux-2.6/drivers/net/loopback.c
===
---
Use the cpu alloc functions for the mib handling functions in the net
layer. The API for snmp_mib_free() is changed to add a size parameter
since cpu_fre requires that.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
include/net/ip.h|2 +-
include/net/snmp.h | 15
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
net/core/sock.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/net/core/sock.c
===
--- linux-2.6.orig/net/core/sock.c 2007-11-18
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_irq.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
Index: linux-2.6/drivers/infiniband/hw/ehca/ehca_irq.c
===
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
crypto/async_tx/async_tx.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
Index: linux-2.6/crypto/async_tx/async_tx.c
===
---
There is no user of allocpercpu left after all the earlier patches were
applied. Remove the code that realizes allocpercpu.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
include/linux/percpu.h | 80 --
mm/Makefile|1
mm/allocpercpu.c
These are critical fast paths. Using a segment override instead of an address
calculation is reducing overhead.
Signed-off-by: Christoph LAmeter [EMAIL PROTECTED]
---
arch/x86/kernel/nmi_64.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index:
Use boot_cpu_alloc to allocate a cpu area chunk that is needed to store the
statically declared per cpu data and then point the per_cpu_offset pointers
to the cpu area.
The per cpu area is moved to a ZERO offset using some linker scripting.
All per cpu variable addresses become true offsets into
Declare the pda as a per cpu variable. This will have the effect of moving
the pda data into the cpu area managed by cpu alloc.
The boot_pdas are only needed in head64.c so move the declaration
over there and make it static.
Remove the code that allocates special pda data structures.
If we move the pda to the beginning of the cpu area then the gs segment will
also point to the beginning of the cpu area. After this patch we can use gs
on any percpu variable or cpu_alloc pointer from cpu 0 to get to the active
processors variable. There is no need anymore to add a per cpu offset
Support fast cpu ops in x86_64 by providing a series of functions that
generate the proper instructions. Define CONFIG_FAST_CPU_OPS so that core code
can exploit the availability of fast per cpu operations.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
arch/x86/Kconfig|
Replace all uses of __per_cpu_offset with CPU_PTR. This will avoid a lot
of lookups for per cpu offset calculations.
Keep per_cpu_offset() itself because lockdep uses it.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
arch/x86/kernel/smpboot_64.c |8 +++-
It is useless now since gs can always stand in for data_offset.
Move active_mm into the available slot in order to not upset the
established offsets.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
arch/x86/kernel/asm-offsets_64.c |1 -
arch/x86/kernel/entry_64.S |7
There needs to be a way to determine the offset for the CPU ops of per cpu
variables. The offset is simply the address of the variable. But we do not
want to code ugly things like
CPU_READ(per_cpu__statistics)
in the core. So define a new helper per_cpu_var(var) that simply adds
the
The use of CPU ops here avoids the offset calculations that we used to have
to do with per cpu ops. The result of this patch is that event counters are
coded with a single instruction the following way:
incq %gs:offset(%rip)
Without these patches this was:
mov%gs:0x8,%rdx
mov
Get rid of one of the leftover pda accessors and cut out some more of pda.h.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
include/asm-x86/pda.h | 35 +--
include/asm-x86/percpu_64.h | 30 ++
2 files changed, 31
Use the CPU_xx operations to deal with the per cpu data.
Avoid a loop to NR_CPUS here. Use the possible map instead.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
include/linux/module.h | 13 +
kernel/module.c| 17 +++--
2 files changed, 12
There is no user of local_t remaining after the cpu ops patchset. local_t
always suffered from the problem that the operations it generated were not
able to perform the relocation of a pointer to the target processor and the
atomic update at the same time. There was a need to disable preemption
The module subsystem cannot handle symbols that are zero. It prints out
a message that these symbols are unresolved. Define a constant
UNRESOLVED
that is used to hold the value used for unresolved symbols. Set it to 1
(its hopefully unlikely that a symbol will have the value 1). This is
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
net/ipv4/tcp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/net/ipv4/tcp.c
===
--- linux-2.6.orig/net/ipv4/tcp.c 2007-11-15
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
block/blktrace.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6/block/blktrace.c
===
--- linux-2.6.orig/block/blktrace.c 2007-11-15
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
fs/nfs/iostat.h |8
fs/nfs/super.c |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/fs/nfs/iostat.h
===
---
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
include/linux/genhd.h | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
Index: linux-2.6/include/linux/genhd.h
===
---
On Fri, Oct 26, 2007 at 04:26:00PM -0700, vince kim wrote:
This patch adds support LZO compression in mkcramfs tool, so it can
generate a cramfs image compress with LZO.
To compile mkcramfs with this patch, liblzo2-dev package must be
installed.
The patch is created against mkcramfs tool
On Mon, Nov 19, 2007 at 08:05:29PM -0500, Stephen Clark wrote:
I think by throttling, you actually mean changing frequency/voltage ?
(throttling is something else, where the CPU skips every n cycles,
which doesn't actually save any power)
well what about the info from /proc/
cat
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
kernel/rcutorture.c |4 ++--
kernel/srcu.c | 20
2 files changed, 10 insertions(+), 14 deletions(-)
Index: linux-2.6/kernel/rcutorture.c
===
---
Also remove the useless zeroing after allocation. Allocpercpu already
zeroed the objects.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
fs/xfs/xfs_mount.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
Index: linux-2.6/fs/xfs/xfs_mount.c
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
include/net/neighbour.h |6 +-
net/core/neighbour.c| 11 ++-
2 files changed, 7 insertions(+), 10 deletions(-)
Index: linux-2.6/include/net/neighbour.h
===
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
net/ipv4/ipcomp.c | 26 +-
net/ipv6/ipcomp6.c | 26 +-
2 files changed, 26 insertions(+), 26 deletions(-)
Index: linux-2.6/net/ipv4/ipcomp.c
Convert DMA engine to use CPU_xx operations. This also removes the use of
local_t
from the dmaengine.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
drivers/dma/dmaengine.c | 38 ++
include/linux/dmaengine.h | 16 ++--
2 files
Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
arch/ppc/platforms/ev64260.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/platforms/ev64260.c b/arch/ppc/platforms/ev64260.c
index 976270d..c1f77e1 100644
--- a/arch/ppc/platforms/ev64260.c
+++
Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
arch/s390/crypto/aes_s390.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/crypto/aes_s390.c
index 5126696..e2f6216 100644
--- a/arch/s390/crypto/aes_s390.c
+++
Gary Hade :
On Sat, Nov 17, 2007 at 11:29:54AM -0700, Alex Chiang wrote:
Hi all,
This is v3 of the pci_slot patch series.
The major change is making the ACPI-PCI slot driver a Kconfig
option, as per the recommendations of others (Gary, Kenji-san).
Alex, What I was trying to suggest
Christoph Lameter wrote:
For the UP and SMP case map the area using 4k ptes. Typical use of per cpu
data is around 16k for UP and SMP configurations. It goes up to 45k when the
per cpu area is managed by cpu_alloc (see special x86_64 patchset).
Allocating in 2M segments would be overkill.
For
On Nov 20, 2007 1:17 AM, David Miller [EMAIL PROTECTED] wrote:
From: Greg KH [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 14:54:55 -0800
Woah, the [EMAIL PROTECTED] list is NOT a subscriber-only list at
all. It's wide open with a bunch of mailman rule filter to try to
handle the worst of the
Dave Jones wrote:
and:
cat /proc/acpi/processor/CPU0/throttling
state count: 2
active state:T0
states:
*T0: 00%
T1: 50%
See above. These are throttling states, used typically
if the system is overheating.
And
Duh a patch did not make it due to XXX in the header.
I will put this also on git.kernel.org slab tree branch cpudata
x86_64: Strip down PDA operations through the use of CPU_XXX operations.
The *_pda operations behave in the same way as the CPU_XX ops. They both access
data
that is relative
Hi,
I have had this before and sent a mail about it.
It seems like the diskcache is still in use and is never shrunk. This
happened with a odd load though, trackerd started indexing a bit late
and the other workload which is a large bittorrent seed/download.
The bittorrent app is the one that
Takashi Iwai wrote:
I took at this problem (as I have an nvidia card on one of my
workstations), and found out that the following suffer from
EXPORT_SYMBOL_GPL changes:
Which kernel version are you using? This is different in .24-rc
compared to .23.
* local_disable_irq(),
On Sat, 17 Nov 2007 21:31:25 -0800
kernel coder [EMAIL PROTECTED] wrote:
hi,
I'm trying to add some code to netif_receive_skb function in
dev.c file . The cycles consumed by that code was around 16 cycles on
Dual Core Opetron machine.I'm working on that code for last 6 months
now and
In message [EMAIL PROTECTED], Hugh Dickins writes:
On Tue, 13 Nov 2007, Erez Zadok wrote:
[...]
I'm glad to report that this unionfs, not the one in 2.6.24-rc2-mm1
but the one including those 9 patches you posted, now gets through
my testing with tmpfs without a problem. I do still get
Greg KH wrote:
Can you try applying the patch below to see if that solves the problem
for you?
I don't think this patch will help; it only has cosmetic changes in
addition to the original message printing fix. I think it also needs
change a3b13c23f186ecb57204580cc1f2dbe9c284953a:
diff -r
Fix quoted string which do not have a space separating
the next word on continuation quoted strings.
for example:
a line with a word
but no space
is equivalent to:
a line with a wordbut no space
which becomes:
a line with a word
but no space
Signed-off-by: Joe Perches [EMAIL
901 - 1000 of 1206 matches
Mail list logo
