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
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
> 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
>
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
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
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
Paul,
On Tue, Nov 20, 2007 at 08:43:32AM +1100, Paul Mackerras wrote:
> David Miller writes:
>
> > As a result I've found that perfmon2 is quite nice and allows
> > incredibly useful and powerful tools to be written. The syscalls
> > aren't that bad and really I see not reason to block it's
On Sun, 18 Nov 2007, root wrote:
> @@ -2155,6 +2155,7 @@ static struct kmem_cache_node *early_kme
> {
> struct page *page;
> struct kmem_cache_node *n;
> + unsigned long flags;
>
> BUG_ON(kmalloc_caches->size < sizeof(struct kmem_cache_node));
>
Well local_irq_save is
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 subscriber-only-posting
mailing list for USB stuff.
-
To unsubscribe from this list:
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
Chris
On Mon, 19 Nov 2007 19:58:36 +0100
"Rafael J. Wysocki" <[EMAIL
On Mon, 19 Nov 2007, Bastian Blank wrote:
> On Fri, Nov 09, 2007 at 04:42:48PM -0200, Glauber de Oliveira Costa wrote:
> > - wrmsrl(MSR_CSTAR, ia32_cstar_target);
> > + wrmsrl(MSR_CSTAR, (u64)ia32_cstar_target);
>
> Hmm, why do you add explicit casts? The compiler should convert that
>
Currently if you access a /proc that is not mounted with your
processes current pid namespace /proc/self will point at a completely
different process. Ouch!.
This patch fixes /proc/self to point to the current process if
it is available in the particular mount of /proc or to return
-ENOENT if
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 reporting an
> intermittent failure on the original patch
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
> >
> > You could make a dma_cacheline_aligned and
On Mon, 19 Nov 2007 15:04:18 -0700
Alex Chiang <[EMAIL PROTECTED]> wrote:
> Documentation/accounting/getdelays.c | 43 +-
> Documentation/feature-removal-schedule.txt |9 -
> Documentation/hwmon/sysfs-interface | 31 +
> Documentation/markers.txt|
On Mon, Nov 19, 2007 at 05:21:10PM -0500, J. Bruce Fields wrote:
> On Mon, Nov 19, 2007 at 11:15:05PM +0100, Rafael J. Wysocki wrote:
> > Subject : nfsd gets stuck when underlying filesystem is XFS
> > Submitter : Christian Kujau <[EMAIL PROTECTED]>
> > Chris Wedgwood
On Mon, Nov 19, 2007 at 11:15:05PM +0100, Rafael J. Wysocki wrote:
> Subject : nfsd gets stuck when underlying filesystem is XFS
> Submitter : Christian Kujau <[EMAIL PROTECTED]>
> Chris Wedgwood <[EMAIL PROTECTED]>
> References:
On Fri, Nov 09, 2007 at 04:42:48PM -0200, Glauber de Oliveira Costa wrote:
> - wrmsrl(MSR_CSTAR, ia32_cstar_target);
> + wrmsrl(MSR_CSTAR, (u64)ia32_cstar_target);
Hmm, why do you add explicit casts? The compiler should convert that
correctly on its own.
> +static inline void
On 19/11/2007, Micah Dowty <[EMAIL PROTECTED]> wrote:
> [ ... ]
>
> [EMAIL PROTECTED]:~$ cat /proc/schedstat
> version 14
> timestamp 4366722208
> cpu0 0 0 0 785868111 0 828020771 12621812 22703872 14096041 9504937730116
> 23603703739504 815398959
> domain0 03 8766051 8760123 95 14544377 6374 0
On Mon, 19 Nov 2007 21:53:05 + (GMT)
Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> > What are the prospects of the DRM TTM changes making it into 2.6.24? I
> > noticed that Andrew has them [1] in his mm tree... any chance of that
> > getting pushed into Linus' tree for 2.6.24?
> >
>
> No
On Mon, Nov 19, 2007 at 06:33:20PM +0100, Andreas Herrmann wrote:
> Hi,
>
> I suggest to add some documentation snippet to
>
> Documentation/x86/{kbuild,kconfig,README}
>
> or whatsoever to primarily describe the new ARCH=x86 build.
> As a starter I named it Documentation/x86/kbuild.
I
Currently we possibly lookup the pid in the wrong pid namespace. So
seq_file convert proc_pid_status which ensures the proper pid
namespaces is passed in, and ensures that we don't overflow any
internal buffers when generating /proc//status
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
This conversion is just for code cleanliness, uniformity, and general safety.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
fs/proc/array.c|8 +---
fs/proc/base.c |4 ++--
fs/proc/internal.h |2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git
This removes all the old vsyscall code from arch/x86/ia32/ that is
no longer used because arch/x86/vdso/ code has replaced it.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/Makefile_64 |3 -
arch/x86/ia32/Makefile | 37 -
Patch 3 of 3
This patch bumps the version of the driver from .14 to .18 to more closely
match the driver that HP ships. This driver already supports all the
hardware that the HP 3.6.18 version supports. So the versions should match,
also. Please consider this for inclusion.
Signed-off-by: Mike
This makes x86_64's ia32 emulation support share the sources used in the
32-bit kernel for the 32-bit vDSO and much of its setup code.
The 32-bit vDSO mapping now behaves the same on x86_64 as on native 32-bit.
The abi.syscall32 sysctl on x86_64 now takes the same values that
vm.vdso_enabled
This reorders the code in the 32-bit vDSO images to put the signal
trampolines first and __kernel_vsyscall after them. The order does
not matter to userland, it just uses what AT_SYSINFO or e_entry
says. Since the signal trampolines are the same size in both
versions of the vDSO, putting them
Currently (as pointed out by Oleg) do_task_stat has a race
when calling task_pid_nr_ns with the task exiting. In addition
do_task_stat is not currently displaying information in the
context of the pid namespace that mounted the /proc filesystem.
So "cut -d' ' -f 1 /proc//stat" may not equal .
Patch 2 of 3
This patch adds support for the blktrace utility. Please consider this for
inclusion. Seems there was already a call to blk_add_trace. This patch adds
ifdef's and includes the header file.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/drivers/block/cciss.c
This puts the syscall version of the 32-bit vDSO in arch/x86/vdso/vdso32/
for 64-bit IA32 support. This is not used yet, but it paves the way for
consolidating the 32-bit vDSO source and build logic all in one place.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/vdso/Makefile
This cleans up the arch/x86/vdso/Makefile rules for vdso.so to
share more code with the vdso32-*.so rules and remove old cruft.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/vdso/Makefile | 19 ---
1 files changed, 4 insertions(+), 15 deletions(-)
diff --git
This harmonizes the name for the entry point from the 32-bit sysenter
instruction across 32-bit and 64-bit kernels.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/entry_32.S | 10 +-
arch/x86/vdso/vdso32-setup.c |4 ++--
2 files changed, 7 insertions(+), 7
This changes the 64-bit kernel's support for the 32-bit sysenter
instruction to use stored fields rather than constants for the
user-mode return address, as the 32-bit kernel does. This adds a
sysenter_return field to struct thread_info, as 32-bit has. There
is no observable effect from this
This moves arch/x86/kernel/sysenter_32.c to arch/x86/vdso/vdso32-setup.c,
keeping all the code relating only to vDSO magic in the vdso/ subdirectory.
This is a pure renaming, but it paves the way to consolidating the code for
dealing with 32-bit vDSOs across CONFIG_X86_32 and
Remove errnoeous x character from dev_dbg() call that
stops the driver compiling under debug.
Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
Index: linux-2.6.22-quilt2/drivers/mfd/sm501.c
===
---
This updates the exceptions for absolute relocs for the new symbol name
convention used for symbols extracted from the vDSO images.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/boot/compressed/relocs.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff
This enables 'make vdso_install' for i386 as on x86_64 and powerpc.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/Makefile_32 |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/x86/Makefile_32 b/arch/x86/Makefile_32
index 99dc511..4c869ef 100644
This makes the i386 kernel use the new vDSO build in arch/x86/vdso/vdso32/
to replace the old one from arch/x86/kernel/.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/Makefile_32 |3 +-
arch/x86/kernel/Makefile_32 | 43
Currently many /proc/pid files use a crufty precursor to
the current seq_file api, and they don't have direct access
to the pid_namespace or the pid of for which they are displaying
data.
So implement proc_single_file_operations to make the seq_file
routines easy to use, and to give access to
This moves the i386 vDSO sources into arch/x86/vdso/vdso32/, a
new directory. This patch is a pure renaming, but paves the way
for consolidating the vDSO build logic.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/ia32/vsyscall-sigreturn.S |3 +--
This builds the 32-bit vDSO images in the arch/x86/vdso subdirectory.
Nothing uses the images yet, but this paves the way for consolidating
the vDSO build logic all in one place. The new images use a linker
script sharing the layout parts from vdso-layout.lds.S with the 64-bit
vDSO. A new
This revamps the vDSO linker script to lay things out with the best
packing of the data and good, separate alignment of the code. The
rigid layout using VDSO_TEXT_OFFSET no longer matters to the kernel.
I've moved the layout parts of the linker script into a new include
file, vdso-layout.lds.S;
This change harmonizes the asm-offsets macros used in the 32-bit vDSO
across 32-bit and 64-bit builds. It's a purely cosmetic change for now,
but it paves the way for consolidating the 32-bit vDSO builds.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/asm-offsets_32.c
- Make pci_slot the primary sysfs entity. hotplug_slot becomes a
subsidiary structure.
o pci_create_slot() creates and registers a slot with the PCI core
o pci_slot_add_hotplug() gives it hotplug capability
- Change the prototype of pci_hp_register() to take the bus and
slot
Patch 1 of 3
This patch creates more sysfs attributes to be exported by cciss. Hopefully
we can work better with udev. Please consider this patch for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 7d70496..2ba5a89 100644
Get rid of vdso-syms.o from the kernel link. We don't need it any more.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/vdso/Makefile | 15 ++-
1 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index
Hi Kristin,
* Kristen Carlson Accardi <[EMAIL PROTECTED]>:
> Alex Chiang <[EMAIL PROTECTED]> wrote:
>
> > I have done quite a bit more testing, and verified that this
> > series plays nicely with acpiphp during all stages of the
> > series. Notably, you can modprobe/rmmod acpiphp repeatedly
> >
This patch adds a new way of extracting symbols from the built vDSO image.
This is much simpler and less fragile than using ld -R; it removes the
need to control the DSO layout quite so exactly. I was clearly unduly
distracted by clever ld uses when I did the original vDSO implementation.
This patch changes the kernel's references to addresses in the vDSO image
to be based on the symbols defined by vdso-syms.lds instead of the old
vdso-syms.o symbols. This is all wrapped up in a macro defined by the new
asm-x86/vdso.h header; that's the only place in the kernel source that has
to
The following patches do a bunch of cleanup and rejiggering to the x86
vDSO implementation, but don't change any actual code in the routines in
the vDSO. They consolidate the 32-bit vDSO code and support for it
between i386 and x86_64/ia32. This makes them behave the same where
they didn't
There is a long standing ugliness with /proc//stat,
/proc//statm, and /proc//status that they do not
use the seqfile API.
In addition they are currently reporting pids in the pid namespace
of the current task instead of the pid namespace with which proc
was mounted which is confusing.
This
This adds new-style I2c device driver for O2 Micro/ETC OZ990 devices.
Button support was tested with a ETC OZ992S in a Fujitsu-Siemens C-6637.
Signed-off-by: Hendrik Sattler <[EMAIL PROTECTED]>
---
This new-style I2C driver supports buttons and LEDs attached to an
OZ990 or OZ992 device.
Index:
This message contains a list of some regressions from 2.6.23 which have been
reported since 2.6.24-rc1 was released and for which there are no fixes in the
mainline that I know of. If any of them have been fixed already, please let me
know.
If you know of any other unresolved regressions from
This is another approach for FJKEYINF support for the FSC Lifebook laptop
series.
In comparison to the apanel driver that was posted lately, it supports more
than one entry in the table and slits off the actual handling of the I2C
devices to seperate drivers, allowing resuse in other scenarios.
There is a kind of ongoing project to support the panel buttons in
FSC Lifebook laptops. This is another approach since the apanel driver
does not work for me. They are partly similar, though.
It seperates I2C chip support from the handling of the table
information. That improves readability a lot
> > I use libuuid and I assume libuuid uses some uuid generator support
> > from the kernel.
>
> No, it does not. It's pure userspace and may produce double UUIDs.
>
> > libuuid comes from a package that Ted's maintain IIRC.
> >
> > I (my company) use uuid to uniquely identify objects in a
On Mon, 2007-11-19 at 13:43 -0800, Roland Dreier wrote:
> > I've been debugging various issues on the PowerPC 44x embedded
> > architecture which happens to have non-coherent PCI DMA.
> >
> > One of the problem I'm hitting is that one really need to enforce
> > kmalloc alignement to cache
> What are the prospects of the DRM TTM changes making it into 2.6.24? I
> noticed that Andrew has them [1] in his mm tree... any chance of that
> getting pushed into Linus' tree for 2.6.24?
>
No the merge window for 2.6.24 closed a few weeks ago. TTM wasn't in -mm
for the 2.6.23 cycle as we
On Monday, 19 of November 2007, Pavel Machek wrote:
> Hi!
>
> I think that this worked before:
>
> [EMAIL PROTECTED]:/proc# find . -name "timer_info"
> find: WARNING: Hard link count is wrong for ./net: this may be a bug
> in your filesystem driver. Automatically turning on find's -noleaf
>
David Miller writes:
> As a result I've found that perfmon2 is quite nice and allows
> incredibly useful and powerful tools to be written. The syscalls
> aren't that bad and really I see not reason to block it's inclusion.
>
> I rescind all of my earlier objections, let's merge this soon :-)
Oleg noticed that the call of task_pid_nr_ns() in proc_pid_readdir
is racy with respect to tasks exiting.
After a bit of examination it also appears that the call itself
is completely unnecessary.
So to fix the problem this patch modifies next_tgid() to return
both a tgid and the task struct in
> I've been debugging various issues on the PowerPC 44x embedded
> architecture which happens to have non-coherent PCI DMA.
>
> One of the problem I'm hitting is that one really need to enforce
> kmalloc alignement to cache lines or bad things will happen (among
> others with USB), for some
El Lunes, 19 de Noviembre de 2007, Ingo Molnar escribió:
> * David <[EMAIL PROTECTED]> wrote:
> > I have removed all other patches, and applied only cfs v24 above
> > 2.6.23.8, and the compiler ran into (with CONFIG_FAIR_GROUP_SCHED
> > enabled):
>
> does the patch below help?
>
> Ingo
Yes,
What are the prospects of the DRM TTM changes making it into 2.6.24? I noticed
that Andrew has them [1] in his mm tree... any chance of that getting pushed
into Linus' tree for 2.6.24?
Cheers,
Waldo
[1] http://userweb.kernel.org/~akpm/mmotm/broken-out/git-drm.patch
Intel Corporation -
On Monday, 19 of November 2007, Rudolf Marek wrote:
> Hello all,
> >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> >>> platform_device_unregister, so coretemp seems to be what I have and you
> >>> don't.
> >
> > Yes.
> >
> > For the coretemp developers: coretemp_cpu_callback()
Sharp Zaurus SL-C3200 with CONFIG_MTD=m and CONFIG_MTD_SHARP_SL=y (as it
is bool) lost support for the ROM flash. With CONFIG_MTD=y it has no
problems.
It is caused by losing of compiled code of
drivers/mtd/maps/sharpsl-flash.o.
It was linked to drivers/mtd/maps/built-in.o and
Hi Linus,
Please pull from 'master' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git
or if master.kernel.org hasn't synced up yet:
master.kernel.org:/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git
This will update the following files:
On Mon, 2007-11-19 at 13:19 -0800, Dave Hansen wrote:
> On Mon, 2007-11-19 at 13:08 -0800, Andrew Morton wrote:
> > Heaven knows why though - why does __pfn_to_page() even exist?
> Perhaps it can go away with the
> discontig->sparsemem-vmemmap conversion.
In fact, Christoph Lameter's
On Mon, 2007-11-19 at 13:08 -0800, Andrew Morton wrote:
>
> > #else
> > -#define page_to_pfn __page_to_pfn
> > +#define page_to_pfn ((unsigned long)__page_to_pfn)
> > #define pfn_to_page __pfn_to_page
> > #endif /* CONFIG_OUT_OF_LINE_PFN_TO_PAGE */
>
> I'd have thought that __pfn_to_page()
On Thu, 2007-11-15 at 21:54 +0800, WANG Cong wrote:
> Since sparse_index_alloc() can return NULL on memory allocation failure,
> we must deal with the failure condition when calling it.
>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
> Cc: Christoph Lameter <[EMAIL PROTECTED]>
> Cc: Rik van Riel
On Mon, 19 Nov 2007 15:20:23 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> * Dave Hansen ([EMAIL PROTECTED]) wrote:
> > The only thing I might suggest doing differently is actually using the
> > page_to_pfn() definition itself:
> >
> > memory_model.h:#define page_to_pfn __page_to_pfn
> >
Hi!
> > On unloaded x60 system, 2.6.24-rc3 (tainted-pavel-so if someone can
> > reproduce it, it would be helpful):
> >
> > [EMAIL PROTECTED]:~$ while true; do time sleep 0.01; done
> > 0.00user 0.00system 0.01 (0m0.013s) elapsed 30.71%CPU
> > 0.00user 0.00system 0.02 (0m0.024s) elapsed 8.36%CPU
Torsten Kaiser wrote:
> On Nov 19, 2007 8:56 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>> * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
...
> Above this acquire/release sequence is the following comment:
> #ifdef CONFIG_LOCKDEP
> /*
> * It is permissible to free the
Hi!
I think that this worked before:
[EMAIL PROTECTED]:/proc# find . -name "timer_info"
find: WARNING: Hard link count is wrong for ./net: this may be a bug
in your filesystem driver. Automatically turning on find's -noleaf
option. Earlier results may have failed to include directories that
David,
On Mon, Nov 19, 2007 at 05:08:43AM -0800, David Miller wrote:
>
> Instead of blabbering further about this topic, I decided to put my
> code where my mouth is and spent the weekend porting the perfmon2
> kernel bits, and the user bits (libpfm and pfmon) to sparc64.
>
I appreciate your
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> On unloaded x60 system, 2.6.24-rc3 (tainted-pavel-so if someone can
> reproduce it, it would be helpful):
>
> [EMAIL PROTECTED]:~$ while true; do time sleep 0.01; done
> 0.00user 0.00system 0.01 (0m0.013s) elapsed 30.71%CPU
> 0.00user
* David <[EMAIL PROTECTED]> wrote:
> I have removed all other patches, and applied only cfs v24 above
> 2.6.23.8, and the compiler ran into (with CONFIG_FAIR_GROUP_SCHED
> enabled):
does the patch below help?
Ingo
Index: linux-cfs-2.6.23.8.q/kernel/sched.c
* David <[EMAIL PROTECTED]> wrote:
> I can send my config if needed
yes - please always include the config when reporting build failures.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Am Montag 19 November 2007 18:26:32 schrieben Sie:
> 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:
>
Hi!
On unloaded x60 system, 2.6.24-rc3 (tainted-pavel-so if someone can
reproduce it, it would be helpful):
[EMAIL PROTECTED]:~$ while true; do time sleep 0.01; done
0.00user 0.00system 0.01 (0m0.013s) elapsed 30.71%CPU
0.00user 0.00system 0.02 (0m0.024s) elapsed 8.36%CPU
0.00user 0.00system
On Mon, 19 Nov 2007, Rudolf Marek wrote:
> Hello all,
> >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> >>> platform_device_unregister, so coretemp seems to be what I have and you
> >>> don't.
> >
> > Yes.
> >
> > For the coretemp developers: coretemp_cpu_callback() needs to be
* Dave Hansen ([EMAIL PROTECTED]) wrote:
> The only thing I might suggest doing differently is actually using the
> page_to_pfn() definition itself:
>
> memory_model.h:#define page_to_pfn __page_to_pfn
>
> The full inline function version should do this already, and we
> shouldn't have any real
On Mon, 2007-11-19 at 14:52 -0500, Mathieu Desnoyers wrote:
> * Dave Hansen ([EMAIL PROTECTED]) wrote:
> > On Mon, 2007-11-19 at 13:52 -0500, Mathieu Desnoyers wrote:
> > > > > So I guess the result is a pointer ? Should this be expected ?
> > > >
> > > > Nope. 'pointer - pointer' is an integer.
Hello all,
gives coretemp_cpu_callback -> coretemp_device_remove ->
platform_device_unregister, so coretemp seems to be what I have and you don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more
careful about what it does. During a system sleep transition
* Dave Hansen ([EMAIL PROTECTED]) wrote:
> On Mon, 2007-11-19 at 13:52 -0500, Mathieu Desnoyers wrote:
> > > > So I guess the result is a pointer ? Should this be expected ?
> > >
> > > Nope. 'pointer - pointer' is an integer. Just solve this equation for
> > > integer:
> > >
> > >
> 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 reporting an
intermittent failure on the original patch (which only
addresses one end of that hardware race).
So, no ... but given we know that
> I'd like to be rid of it inside the command for various reasons: every
> command has one of these, and they're expensive in the allocation (at 96
> bytes). There's no reason we have to allocate and free that amount of
> space with every command. In theory, the number of these is bounded at
>
Adjustments:
auxvec.h, i2c-dev.h and vt.h *should* be unifdef'ed
i2o-dev.h does not need unifdef'ing
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 37bfa19..6a7a525 100644
--- a/include/linux/Kbuild
+++
On Mon, 2007-11-19 at 09:09 -0600, James Bottomley wrote:
> > What other drivers do is DMA to their own allocation and then memcpy to
> > the sense buffer.
> >
> > There is a movement to allocate the sense data as its own sg list, but
> > I don't think that patch has even been posted yet.
>
>
On Mon, 2007-11-19 at 05:32 -0700, Matthew Wilcox wrote:
> On Mon, Nov 19, 2007 at 04:35:23PM +1100, Benjamin Herrenschmidt wrote:
> > The other one I'm hitting now is that the SCSI layer nowadays embeds the
>
> 'nowadays'? It has always been so.
Wasn't it kmalloc'ed at one point ?
> >
El Lunes, 19 de Noviembre de 2007, Ingo Molnar escribió:
> * David <[EMAIL PROTECTED]> wrote:
> > Hi Ingo,
> >
> > Thnx a lot for theses backports...
> >
> > Ran into this while compiling a 2.6.23.8 with CFS v24
> >
> > Compiling with CONFIG_FAIR_GROUP_SCHED disabled :
> >
> > kernel/sysctl.c:305:
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
>
> > I'm not sure what is the best way to fix that. Internally, I've done
> > some test whacking some cacheline_aligned in the scsi_cmnd data
> >
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar
>
>
> * Erik Andersen <[EMAIL PROTECTED]> wrote:
>
> > On Mon Nov 19, 2007 at 04:17:56PM +0100, Ingo Molnar wrote:
> > >
> > > By popular demand, here is release -v24 of the CFS
>
On Mon, 2007-11-19 at 14:00 -0500, Mathieu Desnoyers wrote:
> > Well, using page_to_pfn turns out to be ugly in markers (and in
> > printks) then. Depending on the architecture, it will result in either
> > an unsigned long (x86_64) or an unsigned int (i386), which corresponds
>
> Well, it's
On Mon, 2007-11-19 at 13:52 -0500, Mathieu Desnoyers wrote:
> > > So I guess the result is a pointer ? Should this be expected ?
> >
> > Nope. 'pointer - pointer' is an integer. Just solve this equation for
> > integer:
> >
> > 'pointer + integer = pointer'
> >
>
> Well, using
On Nov 19, 2007 8:56 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
>
> > Trying the last NFSv4 patch (but that patch is only the cause, why I
> > had lockdep enabled) I got this:
> > [ 64.550203]
> > [ 64.550205] =
> > [
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 e423003028183df54f039dfda8b58c49e78c89d7 in mainline.
>
> This is a writeback-internal
On Mon Nov 19, 2007 at 07:52:37PM +0100, Ingo Molnar wrote:
>
> * Erik Andersen <[EMAIL PROTECTED]> wrote:
>
> > On Mon Nov 19, 2007 at 04:17:56PM +0100, Ingo Molnar wrote:
> > >
> > > By popular demand, here is release -v24 of the CFS scheduler patch.
> > >
> > > It is a full backport of the
There is an unmatched parenthesis in the locking commentary of radix_tree.h
which is trivially fixed by the patch below.
Signed-off-by: Tim Pepper <[EMAIL PROTECTED]>
Cc: Nick Piggin <[EMAIL PROTECTED]>
---
diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
---
* Rusty Russell ([EMAIL PROTECTED]) wrote:
[...]
> > +++ linux-2.6-lttng/arch/x86/kernel/immediate.c 2007-11-16
> > 08:56:22.0 -0500 @@ -0,0 +1,143 @@
> > +/*
> > + * Immediate Value - x86 architecture specific code.
>
> This is now almost entirely generic code, but I suppose we can
301 - 400 of 1206 matches
Mail list logo
