[PATCH 10/10] change function orders in paravirt.h

__pmd, pmd_val and set_pud are used before they are defined (as static) We move them a little up in the file, so it doesn't happen. Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]> --- include/asm-x86/paravirt.h | 84 ++-- 1 files changed, 42

[PATCH 6/10] provide read and write cr8 paravirt hooks

Since the cr8 manipulation functions ended up staying in the tree, they can't be defined just when PARAVIRT is off: In this patch, those functions are defined for the PARAVIRT case too. Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]> --- include/asm-x86/system.h | 30 ++

[PATCH 7/10] fill pv_cpu_ops structure with cr8 fields

This patch fills in the read and write cr8 fields with their native version Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]> --- arch/x86/kernel/paravirt.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt

[PATCH 8/10] add asm_offset PARAVIRT constants

This patch adds the constant PARAVIRT needs in asm_offsets_64.c Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]> --- arch/x86/kernel/asm-offsets_64.c | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kern

[PATCH 5/10] puts read and write cr8 into pv_cpu_ops

This patch adds room for read and write_cr8 functions back in pv_cpu_ops struct Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]> --- include/asm-x86/paravirt.h | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/include/asm-x86/paravirt.h b/include/

[PATCH 1/10] add missing parameter for lookup_address

lookup_address() receives two parameters, but efi_64.c call is passing only one. It's actually preventing the tree from compiling Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]> --- arch/x86/kernel/efi_64.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/ar

[PATCH 4/10] put generic mm_hooks include into PARAVIRT

With PARAVIRT, we actually have arch_{dup,exit}_mmap functions, so we can't include the generic header Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]> --- include/asm-x86/mmu_context_64.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/asm-x86/mmu_co

[PATCH 3/10] provide a native_init_IRQ function to x86_64

x86_64 lacks a native_init_IRQ() function, so we turn the arch's init_IRQ() function into a native construct Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]> --- arch/x86/kernel/i8259_64.c |4 +++- include/asm-x86/hw_irq_64.h |1 + 2 files changed, 4 insertions(+), 1 deletion

[PATCH 0/10] Tree fixes for PARAVIRT

Hi, This small series provides some more fixes towards the goal to have the PARAVIRT selectable for x86_64. After that, just some more small steps are needed. The first fix is not even specific for PARAVIRT, and it's actually preventing the whole tree from booting. -- To unsubscribe from this l

[PATCH 2/10] add stringify header

We use a __stringify construction at paravirt_patch_64.c. It's better practice to include the stringify header directly Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]> --- arch/x86/kernel/paravirt_patch_64.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arc

Re: [BUG] 2.6.24-rc8 broke warm reboots on ASUS P5B-E Plus

On Thu, 17 Jan 2008 23:13:50 +0100, Mikael Pettersson wrote: > The problematic machine has an Intel P965/ICH8R based ASUS P5B-E Plus > mainboard with a Core2Duo 6600 processor. Kernels up to and including > 2.6.24-rc7 work fine on it. > > Kernel 2.6.24-rc8 boots Ok, but if I try to do a warm

Re: [PATCH 4/5] x86: Add config variables for SMP_MAX

Hi Mike, On Friday 18 January 2008, [EMAIL PROTECTED] wrote: > +config THREAD_ORDER > + int "Kernel stack size (in page order)" > + range 1 3 > + depends on X86_64_SMP > + default "3" if X86_SMP_MAX > + default "1" > + help > + Increases kernel stack size. > + Could

Re: regression: 100% io-wait with 2.6.24-rcX

On Jan 18, 2008 12:46 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Fri, 18 Jan 2008, Mel Gorman wrote: > > > > Right, and this is consistent with other complaints about the PFN of the > > page mattering to some hardware. > > I don't think it's actually the PFN per se. > > I think it's sim

Re: [PATCH 1/5] x86: Change size of node ids from u8 to u16 fixup

Jan Engelhardt wrote: > On Jan 18 2008 10:30, [EMAIL PROTECTED] wrote: >> --- a/include/linux/numa.h >> +++ b/include/linux/numa.h >> @@ -10,4 +10,10 @@ >> >> #define MAX_NUMNODES(1 << NODES_SHIFT) >> >> +#if MAX_NUMNODES > 256 >> +typedef u16 numanode_t; >> +#else >> +typedef u8 numanode_t; >>

Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

2008/1/18, Linus Torvalds <[EMAIL PROTECTED]>: > > > On Fri, 18 Jan 2008, Miklos Szeredi wrote: > > > > What I'm saying is that the times could be left un-updated for a long > > time if program doesn't do munmap() or msync(MS_SYNC) for a long time. > > Sure. > > But in those circumstances, the prog

Re: [PATCH 1/5] x86: Change size of node ids from u8 to u16 fixup

On Jan 18 2008 10:30, [EMAIL PROTECTED] wrote: >--- a/include/linux/numa.h >+++ b/include/linux/numa.h >@@ -10,4 +10,10 @@ > > #define MAX_NUMNODES(1 << NODES_SHIFT) > >+#if MAX_NUMNODES > 256 >+typedef u16 numanode_t; >+#else >+typedef u8 numanode_t; >+#endif >+ Do we really need numanode_

Re: SLUB: Increasing partial pages

On Wed, Jan 16, 2008 at 02:01:08PM -0800, Christoph Lameter wrote: > Dec 6th? I was on vacation then and it seems that I was unable to > reproduce the oopses. Can I get some backtraces or other information > that would allow me to diagnose the problem? I've found one backtrace which seems to be

Re: Why is the kfree() argument const?

On Friday 18 January 2008 11:31:05 am Zan Lynx wrote: > On Fri, 2008-01-18 at 11:14 -0800, Vadim Lobanov wrote: > > Second, even if const did have stronger semantics that forbade the value > > of x from being modified during execution of foo, the compiler still > > could not reorder the two functio

Re: [PATCH -v6 0/2] Fixing the issue with memory-mapped file times

2008/1/18, Miklos Szeredi <[EMAIL PROTECTED]>: > > 4. Performance test was done using the program available from the > > following link: > > > > http://bugzilla.kernel.org/attachment.cgi?id=14493 > > > > Result: the impact of the changes was negligible for files of a few > > hundred megabytes. > >

Re: [PATCH 1/7] Modules: Fold percpu_modcopy into module.c

On Saturday 19 January 2008 05:29:54 [EMAIL PROTECTED] wrote: > percpu_modcopy() is defined multiple times in arch files. However, the only > user is module.c. Put a static definition into module.c and remove > the definitions from the arch files. Acked-by: Rusty Russell <[EMAIL PROTECTED]> Thank

Re: [PATCH 1/1] Net: e100, fix iomap mem accesses

On 01/18/2008 08:38 PM, Jeff Garzik wrote: Jiri Slaby wrote: readX functions are not permitted on iomap-ped space change to ioreadX, also pci_unmap pci_map-ped space on exit (instead of iounmap). Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> --- drivers/net/e100.c |8 1 files chan

Re: [PATCH 1/1] Net: e100, fix iomap mem accesses

Jiri Slaby wrote: readX functions are not permitted on iomap-ped space change to ioreadX, also pci_unmap pci_map-ped space on exit (instead of iounmap). Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> --- drivers/net/e100.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff -

Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

On Fri, 18 Jan 2008, Miklos Szeredi wrote: > > What I'm saying is that the times could be left un-updated for a long > time if program doesn't do munmap() or msync(MS_SYNC) for a long time. Sure. But in those circumstances, the programmer cannot depend on the mtime *anyway* (because there is

Re: Why is the kfree() argument const?

On Fri, 2008-01-18 at 11:14 -0800, Vadim Lobanov wrote: [cut] > Second, even if const did have stronger semantics that forbade the value of x > from being modified during execution of foo, the compiler still could not > reorder the two function calls, before it cannot assume that the two > func

Re: [PATCH] ramdisk driver: make rd_size non-static

On Thu, Jan 17, 2008 at 06:28:51PM -0800, Andrew Morton wrote: > On Fri, 18 Jan 2008 02:02:17 + Byron Bradley <[EMAIL PROTECTED]> wrote: > > > In arch/arm/kernel/setup.c:setup_ramdisk(), rd_size is set from the > > boot tags. The replacement ramdisk driver has rd_size as static > > which cause

Re: regression: 100% io-wait with 2.6.24-rcX

On Fri, 18 Jan 2008, Martin Knoblauch wrote: > > just to make one thing clear - I am not so much concerned about the > performance of AACRAID. It is OK with or without Mel's patch. It is > better with Mel's patch. The regression in DIO compared to 2.6.19.2 is > completely independent of Mel's st

Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

> > > > But then background writeout, sync(2), etc, wouldn't update the times. > > Sure it would, but only when doing the final unmap. > > Did you miss the "on unmap and msync" part? No :) What I'm saying is that the times could be left un-updated for a long time if program doesn't do munmap()

Re: [PATCH] Shrink ext3_inode_info by 8 bytes for !POSIX_ACL.

On Sat, 2008-01-12 at 21:35 +0100, Indan Zupancic wrote: > i_file_acl and i_dir_acl aren't always needed. > > With certain configs this makes 10 ext3_inode_cache objects fit in > one slab instead of the current 9, as the size shrinks from 416 to > 408 bytes for 32 bit, !POSIX_ACL and !EXT3_FS_XATT

Re: Why is the kfree() argument const?

On Friday 18 January 2008 05:54:12 am Andy Lutomirski wrote: > It almost sounds like the compiler is free to change: > > void foo(const int *x); > foo(x); > printf("%d", x); > > to: > > void foo(const int *x); > printf("%d", x); > foo(x); > > especially if it can prove that the pointer to x doesn't

Re: SLUB: Increasing partial pages

On Wed, Jan 16, 2008 at 02:28:44PM -0800, Christoph Lameter wrote: > On Wed, 16 Jan 2008, Matthew Wilcox wrote: > > About 0.1-0.2% 0.3% is considered significant. > > The results are that stable? A kernel compilation which slightly > rearranges cachelines due to code and data changes typically l

Re: [PATCH 0/3] enhanced ESTALE error handling

J. Bruce Fields wrote: On Fri, Jan 18, 2008 at 01:12:03PM -0500, Peter Staubach wrote: Chuck Lever wrote: On Jan 18, 2008, at 12:30 PM, Peter Staubach wrote: I can probably imagine a situation where the pathname resolution would never finish, but I am not sure that it could ever

Re: [git pull] x86 fixes for v2.6.24

On Fri, Jan 18, 2008 at 04:48:09PM +0100, Ingo Molnar wrote: > > Linus, please pull the latest x86 git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git > > two fixes: a "make mrproper" bug and a new cpuid for oprofile, both > build/boot tested. > > In

Re: Why not creating a GIT RT tree ?

On Fri, 18 Jan 2008, Francis Moreau wrote: > > > > The answer to this is pretty much the same as why the -mm tree isn't in > > git either. > > > > Well not exactly. Unlike the mm tree which is made of a lots of patches > dealing with totaly unrelated subjects, the rt patches only hopefully deal >

Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

On Fri, 18 Jan 2008, Miklos Szeredi wrote: > > But then background writeout, sync(2), etc, wouldn't update the times. Sure it would, but only when doing the final unmap. Did you miss the "on unmap and msync" part? Linus -- To unsubscribe from this list: send the line "unsubscr

Re: Why is the kfree() argument const?

Olivier Galibert wrote: > On Fri, Jan 18, 2008 at 05:45:49PM +0100, [EMAIL PROTECTED] wrote: > > The malloc attribute is exactly about this : giving the compiler the > > indication that no other pointer aliases this object, allowing for > > better optimizations. > > If you put a malloc attribute

Re: [PATCHv2] x86: Use v8086_mode helper, trivial unification

Harvey Harrison wrote: On Fri, 2008-01-18 at 16:00 +0100, Ingo Molnar wrote: + /* +* Did it hit the DOS screen memory VA from vm86 mode? +*/ + if (v8086_mode(regs)) { + unsigned long bit = (address - 0xA) >> PAGE_SHIFT; + if (bit < 32)

Re: [PATCHSET] printk: implement printk_header() and merging printk

On Fri, 2008-01-18 at 11:44 -0700, Matthew Wilcox wrote: > On Fri, Jan 18, 2008 at 12:41:08PM -0600, Matt Mackall wrote: > > On Wed, 2008-01-16 at 10:00 +0900, Tejun Heo wrote: > > > And mprintk the following. > > > > > > code: > > > DEFINE_MPRINTK(mp, 2 * 80); > > > > > > mprintk_set_heade

Re: Why is the kfree() argument const?

On Friday 18 January 2008 03:47:01 am Giacomo A. Catenazzi wrote: > Changing the name of variables in your example: > > extern print_int(const int *); > > int main(int argc, char **argv) > { >extern int errno; > >errno = 0; >print_int(&i); >return errno; > } Except that changing in

PROBLEM: Celeron Core

I have a laptop "Extensa 5220", with the processor Celeron based on 'core' technology. There is ~ / arch/i386/kernel/cpu/cpufreq/p4-clockmod.c in the kernel source code but there's no line identification of my CPU for apply freqency change need to add a ID line 0х16 "t

Re: [PATCHv2] x86: Use v8086_mode helper, trivial unification

On Fri, 2008-01-18 at 16:00 +0100, Ingo Molnar wrote: > > > + /* > > > + * Did it hit the DOS screen memory VA from vm86 mode? > > > + */ > > > + if (v8086_mode(regs)) { > > > + unsigned long bit = (address - 0xA) >> PAGE_SHIFT; > > > + if (bit < 32) > > > + ts

Re: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text

On Friday, January 18, 2008 10:12 am Andi Kleen wrote: > I looked back then when I had bisected it down and I admit I didn't spot > the problem from source review. I think it came from the reordering so > blacklisting AMD alone wouldn't have helped. Might have been some > subtle race (e.g. long ago

[PATCH for -rc] kbuild: fix false section mismatch warning referring to .init.text.2

Hi Linus. Please pull following two-liner fix for modpost. It silence an annoying section mismatch warning. Pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/sam/fix-kbuild.git Sam >From 57ff41164d27cb577620a6e8085dd67cd8a87649 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg

Re: [Announce] Development release 0.1 of the LatencyTOP tool

On Fri, 2008-01-18 at 09:36 -0800, Arjan van de Ven wrote: > The Intel Open Source Technology Center is pleased to announce the > release of version 0.1 of LatencyTOP, a tool for developers to visualize > system latencies. > > http://www.latencytop.org > > Slow servers, Skipping audio, Jerky vid

Re: regression: 100% io-wait with 2.6.24-rcX

--- Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Fri, 18 Jan 2008, Mel Gorman wrote: > > > > Right, and this is consistent with other complaints about the PFN > > of the page mattering to some hardware. > > I don't think it's actually the PFN per se. > > I think it's simply that some c

Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

> > That would need a new page flag (PG_mmap_dirty?). Do we have one > > available? > > Yeah, that would be bad. We probably have flags free, but those page flags > are always a pain. Scratch that. > > How about just setting a per-vma dirty flag, and then instead of updating > the mtime when t

Re: [PATCH] X86: fix typo PAT to X86_PAT

On Fri, Jan 18, 2008 at 10:47:05AM -0800, Venki Pallipadi wrote: > >This exclusion is going to be a real pain in the ass for > >distro kernels. > >It's impossible for example to build a kernel that will now support > >the MTRR-alike registers on the AMD K6/early Cyrix etc and also > >support

Re: [PATCH 5/5] x86: Add debug of invalid per_cpu map accesses

On Fri, 18 Jan 2008, Andi Kleen wrote: > On Friday 18 January 2008 19:30:16 [EMAIL PROTECTED] wrote: > > Provide a means to trap usages of per_cpu map variables before > > they are setup. Define CONFIG_DEBUG_PER_CPU_MAPS to activate. > > Are you sure that debug option is generally useful enough

Re: [PATCH 0/3] x86: Reduce memory and intra-node effects with large count NR_CPUs fixup

On Fri, 18 Jan 2008, Mike Travis wrote: > I hadn't considered doing 32-bit NUMA changes as I didn't know if the > NR_CPUS count would really be increased for the 32-bit architecture. > I have been trying though not to break it. ;-) 32bit NUMA is tricky because ZONE_NORMAL memory is only availabl

Re: [Announce] Development release 0.1 of the LatencyTOP tool

At 18.36 18/01/2008, Arjan van de Ven wrote: >The Intel Open Source Technology Center is pleased to announce the >release of version 0.1 of LatencyTOP, a tool for developers to visualize >system latencies. > >http://www.latencytop.org > [...snip...] > >The most basic annotation looks like this (i

Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

> > > And even in that four-liner, I suspect that the *last* two lines are > > > actually incorrect: there's no point in updating the file time when the > > > page *becomes* dirty, > > > > Actually all four lines do that. The first two for a write access on > > a present, read-only pte, the oth

Re: crash in kmem_cache_init

On Thu, 17 Jan 2008, Olaf Hering wrote: > Normal 892928 -> 892928 > Movable zone start PFN for each node > early_node_map[1] active PFN ranges > 1:0 -> 892928 > Could not find start_pfn for node 0 We only have a single node that is node 1? And then we initialize nodes 0 to

Re: [PATCH 5/5] x86: Add debug of invalid per_cpu map accesses

Andi Kleen wrote: > On Friday 18 January 2008 19:30:16 [EMAIL PROTECTED] wrote: >> Provide a means to trap usages of per_cpu map variables before >> they are setup. Define CONFIG_DEBUG_PER_CPU_MAPS to activate. > > Are you sure that debug option is generally useful enough > to merge? It seems ver

Re: build #343 issue for v2.6.24-rc8-29-g03bbe08 : Section mismatch: reference to .init.text.1:start_kernel (between 'is386' and 'check_x87')

Hi Wang. > >> >Following untested patch should fix it. > >> > > >> > >> Still has the same problem. ;( > >Could you please doublecheck that you applied the patch and modpost is > >rebuilt. > >If you continue to see the problem could you send me the config (off-list) > >and > >I will fix it. > >

Re: [Announce] Development release 0.1 of the LatencyTOP tool

At 19.35 18/01/2008, Arjan van de Ven wrote: >Roberto Fichera wrote: >> At 18.36 18/01/2008, Arjan van de Ven wrote: >>> The Intel Open Source Technology Center is pleased to announce the >>> release of version 0.1 of LatencyTOP, a tool for developers to visualize >>> system latencies. >>> >>> http

Re: crash in kmem_cache_init

On Thu, 17 Jan 2008, Olaf Hering wrote: > early_node_map[1] active PFN ranges > 1:0 -> 892928 > Could not find start_pfn for node 0 Corrupted min_pfn? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More major

Re: [PATCH/RFCv2] [POWERPC] Add support for freescale watchdog to CPM serial driver.

Hi Alan, If a freescale watchdog device node is present, reset the watchdog while waiting for serial input. Why ? We normally rely on user space for watchdog management as only the fact user space is behaving really proves a box is happy ? This is in the boot wrapper code, not in the linux k

2.6.24-rc8 oops ext3_clear_inode+0x25/0xa0

Dear all, I've just got this oops (causing the machine to hang finally)... Any ideas? Soeren BUG: unable to handle kernel paging request at virtual address 66e88e66 printing eip: c01fac85 *pde = Oops: 0002 [#1] PREEMPT SMP Modules linked in: hci_usb hidp rfcomm l2cap bluetooth tun cpu

RE: [PATCH] X86: fix typo PAT to X86_PAT

>-Original Message- >From: Dave Jones [mailto:[EMAIL PROTECTED] >Sent: Friday, January 18, 2008 10:25 AM >To: Ingo Molnar >Cc: Yinghai Lu; Pallipadi, Venkatesh; LKML >Subject: Re: [PATCH] X86: fix typo PAT to X86_PAT > >On Fri, Jan 18, 2008 at 01:31:40PM +0100, Ingo Molnar wrote: > > >

Re: [PATCHSET] printk: implement printk_header() and merging printk

On Fri, Jan 18, 2008 at 12:41:08PM -0600, Matt Mackall wrote: > On Wed, 2008-01-16 at 10:00 +0900, Tejun Heo wrote: > > And mprintk the following. > > > > code: > > DEFINE_MPRINTK(mp, 2 * 80); > > > > mprintk_set_header(&mp, KERN_INFO "ata%u.%2u: ", 1, 0); > > mprintk_push(&mp, "ATA %d", 7

Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

On Fri, 18 Jan 2008, Miklos Szeredi wrote: > > That would need a new page flag (PG_mmap_dirty?). Do we have one > available? Yeah, that would be bad. We probably have flags free, but those page flags are always a pain. Scratch that. How about just setting a per-vma dirty flag, and then inste

Re: [PATCH/RFCv2] [POWERPC] Add support for freescale watchdog to CPM serial driver.

On Thu, 17 Jan 2008 13:32:35 +0100 Jochen Friedrich <[EMAIL PROTECTED]> wrote: > If a freescale watchdog device node is present, reset the watchdog > while waiting for serial input. Why ? We normally rely on user space for watchdog management as only the fact user space is behaving really proves

Re: crash in kmem_cache_init

On Fri, 18 Jan 2008, Olaf Hering wrote: > calls cache_grow with nodeid 0 > > [c075bbd0] [c00f82d0] .cache_alloc_refill+0x234/0x2c0 > calls cache_grow with nodeid 0 > > [c075bbe0] [c00f7f38] .cache_alloc_node+0x17c/0x1e8 > > calls cache_grow with nodeid 1 > > [c

Re: [PATCHSET] printk: implement printk_header() and merging printk

On Wed, 2008-01-16 at 10:00 +0900, Tejun Heo wrote: > And mprintk the following. > > code: > DEFINE_MPRINTK(mp, 2 * 80); > > mprintk_set_header(&mp, KERN_INFO "ata%u.%2u: ", 1, 0); > mprintk_push(&mp, "ATA %d", 7); > mprintk_push(&mp, ", %u sectors\n", 1024); > mprintk(&mp, "everythin

Re: [PATCH 0/3] enhanced ESTALE error handling

On Fri, Jan 18, 2008 at 01:12:03PM -0500, Peter Staubach wrote: > Chuck Lever wrote: >> On Jan 18, 2008, at 12:30 PM, Peter Staubach wrote: >>> I can probably imagine a situation where the pathname resolution >>> would never finish, but I am not sure that it could ever happen >>> in nature. >> >> U

Re: [Announce] Development release 0.1 of the LatencyTOP tool

Roberto Fichera wrote: At 18.36 18/01/2008, Arjan van de Ven wrote: The Intel Open Source Technology Center is pleased to announce the release of version 0.1 of LatencyTOP, a tool for developers to visualize system latencies. http://www.latencytop.org [...snip...] The most basic annotation

Re: [PATCH 5/5] x86: Add debug of invalid per_cpu map accesses

On Friday 18 January 2008 19:30:16 [EMAIL PROTECTED] wrote: > Provide a means to trap usages of per_cpu map variables before > they are setup. Define CONFIG_DEBUG_PER_CPU_MAPS to activate. Are you sure that debug option is generally useful enough to merge? It seems very specific to your patchkit,

Re: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text

On Thu, Jan 10, 2008 at 05:50:41PM -0500, [EMAIL PROTECTED] wrote: > (Personally, I keep a copy of Arjan's "restrict devmem" patch from Fedora > around, so I guess that says which camp I belong in, and the fact it's a > Fedora > patch and not mainstream says something too...) The way that pa

[PATCH 4/5] x86: Add config variables for SMP_MAX

Adds and increases some config variables to accomodate larger SMP configurations: NR_CPUS: max limit now 4096 NODES_SHIFT: max limit now 9 THREAD_ORDER: max limit now 3 X86_SMP_MAX: say Y to enable possible cpus == NR_CPUS Signed-off-by: Mike Travis <[EMAIL

[PATCH 3/5] x86: Change bios_cpu_apicid to percpu data variable fixup

Change static bios_cpu_apicid array to a per_cpu data variable. This includes using a static array used during initialization similar to the way x86_cpu_to_apicid[] is handled. There is one early use of bios_cpu_apicid in apic_is_clustered_box(). The other reference in cpu_present_to_apicid() is c

[PATCH 5/5] x86: Add debug of invalid per_cpu map accesses

Provide a means to trap usages of per_cpu map variables before they are setup. Define CONFIG_DEBUG_PER_CPU_MAPS to activate. Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- arch/x86/Kconfig.debug | 12 arch/x86/mm/numa_64.c |3 +++ include/asm-x86/topology.h |7

[PATCH 2/5] x86: Change NR_CPUS arrays in numa_64 fixup

Change the following static arrays sized by NR_CPUS to per_cpu data variables: char cpu_to_node_map[NR_CPUS]; Signed-off-by: Mike Travis <[EMAIL PROTECTED]> Reviewed-by: Christoph Lameter <[EMAIL PROTECTED]> --- fixup: - Split cpu_to_node function into "early" and "late" versions

[PATCH 1/5] x86: Change size of node ids from u8 to u16 fixup

Change the size of node ids for X86_64 from 8 bits to 16 bits to accomodate more than 256 nodes. Introduce a "numanode_t" type for x86-generic usage. Cc: Eric Dumazet <[EMAIL PROTECTED]> Signed-off-by: Mike Travis <[EMAIL PROTECTED]> Reviewed-by: Christoph Lameter <[EMAIL PROTECTED]> --- Fixup:

[PATCH 0/5] x86: Reduce memory usage for large count NR_CPUs fixup

Fixup change NR_CPUS patchset by rebasing on 2.6.24-rc8-mm1 from 2.6.24-rc6-mm1) and adding changes suggested by reviews. Additionally, some new config options have been added to enable large SMP configurations. Based on 2.6.24-rc8-mm1 Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- -- --

Re: UML is leaking memory in arch_dup_mmap

> On Fri, Jan 18, 2008 at 03:42:54PM +0100, Miklos Szeredi wrote: > > uml:~# grep arch_dup_mmap /proc/slab_allocators > > size-32: 10861 arch_dup_mmap+0x9f/0x130 > > Whoops - try the patch below. Yup, that seems to have solved it. Thanks. Miklos -- To unsubscribe from this list: send the line

[PATCH 6/7] s390: Use generic percpu

Change s390 percpu.h to use asm-generic/percpu.h Cc: [EMAIL PROTECTED] Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- V2->V3: On Thu, 29 Nov 2007, Martin Schwidefsky wrote: > On Wed, 2007-11-28 at 13:09 -0800, Christoph Lameter wrote: > >

[PATCH 7/7] percpu: Add debug detection of uninitialized usage of per_cpu variable

Provide a means to trap usages of per_cpu variables before the per_cpu_areas are setup. Define CONFIG_DEBUG_PER_CPU to activate. Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- include/asm-generic/percpu.h | 11 ++- lib/Kconfig.debug| 12 2 files changed,

[PATCH 4/7] ia64: Use generic percpu

ia64 has a special processor specific mapping that can be used to locate the offset for the current per cpu area. Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> Signed-off-by: Mike Travis <[EMAIL PROTECTED]> --- V1->V2: - Merge fixes - Remove tran

[PATCH 2/7] percpu: Change Kconfig ARCH_SETS_UP_PER_CPU_AREA to HAVE_SETUP_PER_CPU_AREA

Change "config ARCH_SETS_UP_PER_CPU_AREA" to "select HAVE_SETUP_PER_CPU_AREA" as suggested by Sam. Cc: Rusty Russell <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Cc: Sam Ravnborg <[EMAIL PROTECTED]> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> Signed-off-by: Mike Travis <[EMAIL P

[PATCH 3/7] Sparc64: Use generic percpu

Sparc64 has a way of providing the base address for the per cpu area of the currently executing processor in a global register. Sparc64 also provides a way to calculate the address of a per cpu area from a base address instead of performing an array lookup. Cc: David Miller <[EMAIL PROTECTED]> Si

[PATCH 5/7] Powerpc: Use generic per cpu

Powerpc has a way to determine the address of the per cpu area of the currently executing processor via the paca and the array of per cpu offsets is avoided by looking up the per cpu area from the remote paca's (copying x86_64). Cc: Paul Mackerras <[EMAIL PROTECTED]> Signed-off-by: Christoph Lamet

[PATCH 0/7] percpu: Per cpu code simplification fixup

This patchset simplifies the code that arches need to maintain to support per cpu functionality. Most of the code is moved into arch independent code. Only a minimal set of definitions is kept for each arch. The patch also unifies the x86 arch so that there is only a single asm-x86/percpu.h Base

[PATCH 1/7] Modules: Fold percpu_modcopy into module.c

percpu_modcopy() is defined multiple times in arch files. However, the only user is module.c. Put a static definition into module.c and remove the definitions from the arch files. Cc: Rusty Russell <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Christoph Lameter <[EMAIL PRO

Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

On Fri, 18 Jan 2008 19:11:47 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > And even in that four-liner, I suspect that the *last* two lines are > > actually incorrect: there's no point in updating the file time when the > > page *becomes* dirty, > > Actually all four lines do that. The f

RE: [ofa-general] InfiniBand/RDMA merge plans for 2.6.25

On Fri, 2008-01-18 at 09:42 -0800, Sean Hefty wrote: > >> Sean Hefty (6): > >> IB/mad: Fix incorrect access to items on local_list > > > >It wasn't clear to me that this issue was ever really nailed. Was the > >loop on this closed ? > > The error that this patches addresses is fairly obvious

Re: [PATCH] X86: fix typo PAT to X86_PAT

On Fri, Jan 18, 2008 at 01:31:40PM +0100, Ingo Molnar wrote: > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > > thanks. But, i think we should rather do the following: if X86_PAT > > > is eanbled then /proc/mtrr should be read-only. There's no problem > > > _looking_ at MTRR contents, as long

Re: [patch 2/2] 8250_pnp: register x86 COM ports at the conventional ttyS names

Rene Herman wrote: The number of places expected to contain something sensible should I believe first be verified at 0x410 -- the equipment word. Bits 11-9 (0x0e00) should be the number of serial ports, 0 to 4 (so 5-7 is also a sanity check) and if BIOSes can be expected to zero out the non-u

Re: Why is the kfree() argument const?

On Fri, Jan 18, 2008 at 05:45:49PM +0100, [EMAIL PROTECTED] wrote: > The malloc attribute is exactly about this : giving the compiler the > indication that no other pointer aliases this object, allowing for > better optimizations. If you put a malloc attribute on the allocator and no free attribut

Re: [PATCH 0/3] enhanced ESTALE error handling

Hi Peter- On Jan 18, 2008, at 12:30 PM, Peter Staubach wrote: Chuck Lever wrote: On Jan 18, 2008, at 11:55 AM, Peter Staubach wrote: Chuck Lever wrote: Hi Peter- On Jan 18, 2008, at 10:35 AM, Peter Staubach wrote: and the window in between the revalidation and the actual use of the file han

ACPI CPU hot removal: Problem with automatic scripting in response to hotplug events

I have an x86_64 system that's capable of doing ACPI CPU hot removal. One issue that's worrying me right now is that there isn't enough information to automatically script CPU removal when it's requested by the hardware platform. I'm doing my testing with 2.6.24-rc8 from kernel.org. I have appli

Re: [PATCH 0/3] enhanced ESTALE error handling

Chuck Lever wrote: On Jan 18, 2008, at 12:30 PM, Peter Staubach wrote: Chuck Lever wrote: On Jan 18, 2008, at 11:55 AM, Peter Staubach wrote: Chuck Lever wrote: Hi Peter- On Jan 18, 2008, at 10:35 AM, Peter Staubach wrote: Hi. Here is a patch set which modifies the system to enhance the ES

Re: [PATCH] Core driver for WM97xx touchscreens

Hi, Dmitry Torokhov wrote: > I will need some more time to review and understand the need for the new > bus in the driver. Most likely this can be converted to platform_bus. Maybe this can also get help from soon-to-be posted MFD (multi function devices) helpers. -- With best wishes Dmitry -

Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

> And even in that four-liner, I suspect that the *last* two lines are > actually incorrect: there's no point in updating the file time when the > page *becomes* dirty, Actually all four lines do that. The first two for a write access on a present, read-only pte, the other two for a write on a

Re: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text

On Fri, Jan 18, 2008 at 08:46:02AM -0800, Jesse Barnes wrote: > On Friday, January 18, 2008 5:12 am Andi Kleen wrote: > > > (AMD machines apparently don't need it > > > > That's not true -- we had AMD systems in the past with broken MTRRs for > > large memory configurations too, Mostly it was pre

Re: UML is leaking memory in arch_dup_mmap

On Fri, Jan 18, 2008 at 03:42:54PM +0100, Miklos Szeredi wrote: > uml:~# grep arch_dup_mmap /proc/slab_allocators > size-32: 10861 arch_dup_mmap+0x9f/0x130 Whoops - try the patch below. Jeff -- Work email - jdike at linux dot intel dot com Index: linux-2.6.22/a

Re: Why is the kfree() argument const?

On Jan 18, 2008 6:02 AM, David Schwartz <[EMAIL PROTECTED]> wrote: > > However, *destroying* an object is not a metadata operation -- it destroys > the data as well. This is kind of a philosophical point, but an object does > not have a "does this object exist" piece of metadata. If an object does

Re: 2.6.24-rc8-mm1

On Thu, Jan 17, 2008 at 02:35:14AM -0800, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/ > Odd nobody else has seen this... oldconfig fails for me on Debian... kconfig/conf.c is using setlocale() without including the locale.h heade

CONFIG_PREEMPT and real time kthreads

I've been trying to find information about the effects of CONFIG_PREEMPT on real time kernel threads. The description of CONFIG_PREEMPT says "...allow preemption of user processes that are executing system calls...". Most of the discussion seems to revolve around the modification of the lock

Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files

On Fri, 18 Jan 2008, Peter Zijlstra wrote: > > Bah, and will break on s390... so we'd need a page_mkclean() variant > that doesn't actually clear dirty. No, we simply want to not play all these very expensive games with dirty in the first place. Guys, mmap access times aren't important enough

Re: USB HID: Missing keys on Gyration Media Center Universal Remote Control

Me: > I'm starting to think that these last 3 keys are broken, or maybe > just not designed to be used as PC keys I decided to ask the folks at Gyration about this before tearing my (and Jiri's) hair out, and it seems that the 3 "missing keys" are actually not meant to send USB signals, only I

Re: [PATCH 0/3] enhanced ESTALE error handling

On Jan 18, 2008, at 12:30 PM, Peter Staubach wrote: Chuck Lever wrote: On Jan 18, 2008, at 11:55 AM, Peter Staubach wrote: Chuck Lever wrote: Hi Peter- On Jan 18, 2008, at 10:35 AM, Peter Staubach wrote: Hi. Here is a patch set which modifies the system to enhance the ESTALE error handling

<    1   2   3   4   5   6   7   >