Rusty Russell wrote:
On Saturday 19 January 2008 07:41:41 Jeff Garzik wrote:
You should be using irq_handler_t for all these.
Well, these are your drivers, but for mine I dislike the obfuscation.
It's not like you can declare the function itself to be an irq_handler_t, so
it's a strange
On Fri, 18 Jan 2008, Mathieu Desnoyers wrote:
>
> But I have not seen a lot of situations where that kind of glue-code was
> needed, so I think it makes sense to keep markers simple to use and
> efficient for the common case.
>
> Then, in this glue-code, we can put trace_mark() and calls to
Em Fri, Jan 18, 2008 at 02:33:34PM -0800, Arjan van de Ven escreveu:
> On Fri, 18 Jan 2008 17:26:09 -0500
> [EMAIL PROTECTED] (Frank Ch. Eigler) wrote:
>
> > Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >
> > > This patch contains the first set of instrumentations for
> > > latencytop; each
Sam Ravnborg wrote:
Are we going to see this for other archs than just x86?
If so then please add this to include/asm-generic/vmlinux.lds.h
In theory other architectures could use a similar mechanism, but for now
its x86 specific.
J
--
To unsubscribe from this list: send the line
On Fri, 18 Jan 2008, Ingo Oeser wrote:
>
> Can we get "if the write to the page hits the disk, the mtime has hit the disk
> already no less than SOME_GRANULARITY before"?
>
> That is very important for computer forensics. Esp. in saving your ass!
>
> Ok, now back again to making that fast
On Jan 18, 2008 3:00 PM, Mike Snitzer <[EMAIL PROTECTED]> wrote:
>
> 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
[PATCH] x86_64: only support sparsemem fix
sparsemem is only one supported, so could remove FLAT_NODE_MEM related, that is
only needed !SPARSEMEM
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Reviewed-by: Christoph Lameter <[EMAIL PROTECTED]>
--- a/arch/x86/mm/numa_64.c
+++
On Fri, 2008-01-18 at 22:09 +0100, Ingo Molnar wrote:
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > > Sounds fine! Don't hesitate to let us know about the lower-hanging
> > > fruit you're thinking about. Here are the main things I have so far:
> > >
> > > * Ideas in the existing
>Paul Menage wrote:
>> On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
>>> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
Allow to limit the block I/O bandwidth for specific process containers
(cgroups) imposing additional delays on I/O requests for
On Fri, 18 Jan 2008, Christoph Lameter wrote:
> Memoryless nodes: Set N_NORMAL_MEMORY for a node if we do not support HIGHMEM
If !CONFIG_HIGHMEM then
enum node_states {
#ifdef CONFIG_HIGHMEM
N_HIGH_MEMORY, /* The node has regular or high memory */
#else
N_HIGH_MEMORY =
I just had a talk with a colleague, John Palmer, who worked on disk drive
design for about 5 years in the '90s and he gave me a very confident,
credible explanation of some of the things we've been wondering about disk
drive power loss in this thread, complete with demonstrations of various
2008/1/19, Linus Torvalds <[EMAIL PROTECTED]>:
>
>
> On Sat, 19 Jan 2008, Anton Salikhmetov wrote:
> >
> > The page_check_address() function is called from the
> > page_mkclean_one() routine as follows:
>
> .. and the page_mkclean_one() function is totally different.
>
> Lookie here, this is the
On Fri, 18 Jan 2008 17:26:09 -0500
[EMAIL PROTECTED] (Frank Ch. Eigler) wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> > This patch contains the first set of instrumentations for
> > latencytop; each instrumentation needs to be evaluated for
> > usefulness before this can go into
Zachary Amsden wrote:
Why are we rushing so much to do 64-bit paravirt that we are breaking
working configurations? If the developement is going to be this
chaotic, it should be done and tested out of tree until it can
stabilize.
x86.git is out of the mainline tree, and it seems to be
On Fri, 18 Jan 2008 18:24:29 +0100, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 18, 2008 at 08:53:44AM -0500, Andy Lutomirski wrote:
> > I'd say this implies the exact opposite. It almost sounds like the
> > compiler is free to change:
> >
> > void foo(const int *x);
> > foo(x);
Hi Linus,
On Friday 18 January 2008, Linus Torvalds wrote:
> 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
EXPERIMENTAL and incomplete patch to make LOCKDEP behave better in
the face of irq chaining, by annotating irqs with a lock_class which
can reflect that hierarchy.
This version of the patch is incomplete in at least two respects:
- There's no spin_lock_irq_nested() primitive, so that locking
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> This patch contains the first set of instrumentations for latencytop;
> each instrumentation needs to be evaluated for usefulness before this
> can go into mainline; posting here just to show how the infrastructure
> can be used
> [...]
Can you
thanks, applied 1-4.
--
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/
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
> On Thu, 17 Jan 2008, Frank Ch. Eigler wrote:
>
> > Hi -
> >
> > On Thu, Jan 17, 2008 at 03:08:33PM -0500, Steven Rostedt wrote:
> > > [...]
> > > + trace_mark(kernel_sched_schedule,
> > > + "prev_pid %d next_pid %d prev_state
On Sat, 19 Jan 2008, Anton Salikhmetov wrote:
>
> The page_check_address() function is called from the
> page_mkclean_one() routine as follows:
.. and the page_mkclean_one() function is totally different.
Lookie here, this is the correct and complex sequence:
> entry =
On 1/18/08, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Could you try this patch?
>
> Memoryless nodes: Set N_NORMAL_MEMORY for a node if we do not support
> HIGHMEM
>
> It seems that we only scan through zones to set N_NORMAL_MEMORY only if
> CONFIG_HIGHMEM and CONFIG_NUMA are set. We need to
On Saturday 19 January 2008 07:45:41 Jeff Garzik wrote:
> Rusty Russell wrote:
> > -static irqreturn_t lguest_interrupt(int irq, void *_vq)
> > +static irqreturn_t lguest_interrupt(int irq, struct virtqueue *vq)
> > {
> > - struct virtqueue *vq = _vq;
> > struct lguest_device_desc *desc =
On Fri, 18 Jan 2008, James Cloos wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git
> http://www.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git
Thanks for doing this. We might want to add this to the wiki.
http://rt.wiki.kernel.org/index.php/Main_Page
-- Steve
Could you try this patch?
Memoryless nodes: Set N_NORMAL_MEMORY for a node if we do not support HIGHMEM
It seems that we only scan through zones to set N_NORMAL_MEMORY only if
CONFIG_HIGHMEM and CONFIG_NUMA are set. We need to set N_NORMAL_MEMORY
in the !CONFIG_HIGHMEM case.
Signed-off-by:
On Saturday 19 January 2008 07:41:41 Jeff Garzik wrote:
> You should be using irq_handler_t for all these.
Well, these are your drivers, but for mine I dislike the obfuscation.
It's not like you can declare the function itself to be an irq_handler_t, so
it's a strange turd to drop in a driver.
If a freescale watchdog device node is present, reset the watchdog
while waiting for serial input.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
arch/powerpc/boot/Makefile |2 +-
arch/powerpc/boot/cpm-serial.c |6 +++
arch/powerpc/boot/cuboot-8xx.c |1 +
On Jan 18, 2008, at 3:56 PM, Jochen Friedrich wrote:
Hi Kumar,
Ok now that makes sense, thanks
So I'll ask, what serial input are you waiting for from the boot
wrapper?
It's the editor for the kernel command line.
thanks, learn something everyday.
- k
--
To unsubscribe from this list:
> "Francis" == Francis Moreau <[EMAIL PROTECTED]> writes:
Francis> I can't find a rt tree anywhere and all new rt release spoke
Francis> about a patchset to apply on mainline kernels.
It is not perfect, but I do have a git repo of the rt history-of-patches
up at:
On Fri, 18 Jan 2008 16:43:45 -0500
"J. Bruce Fields" <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 14, 2008 at 09:05:18AM -0500, Jeff Layton wrote:
> > If we're shutting down all the nlm_hosts anyway, then it doesn't
> > make sense to allow RPC calls to linger. Allowing them to do so can
> > mean that
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Andi Kleen <[EMAIL PROTECTED]> writes:
>
> > The config option protects so little code that it is fairly pointless.
> > Also a lot of its code was related to itself only (as in panicing without
> > TSC). And TSC less CPUs are completely handled at
2008/1/19, Linus Torvalds <[EMAIL PROTECTED]>:
>
>
> On Sat, 19 Jan 2008, Anton Salikhmetov wrote:
> >
> > Before using pte_wrprotect() the vma_wrprotect() routine uses the
> > pte_offset_map_lock() macro to get the PTE and to acquire the ptl
> > spinlock. Why did you say that this code was not
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y.
> > Which means you did not even build-test it on 32-bit, let alone boot
> > test it...
>
> Why are we rushing so much to do 64-bit paravirt that we are breaking
> working
On Fri, 14 Dec 2007 13:54:59 -0800 (PST)
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9564
>
>Summary: Uninitialzed variable fields cvt.h_margin and
> cvt.v_margin
>Product: Drivers
>Version: 2.5
>
On Wed, 16 Jan 2008 14:09:02 -0800
Yinghai Lu <[EMAIL PROTECTED]> wrote:
> [PATCH] x86: MMCONF enable MCFG early
>
> patch
> x86: validate against ACPI motherboard resources
>
> changed the mmconf init sequence, and init MMCONF late in acpi_init.
>
> here change it back to old sequence
>
On Fri, Jan 18, 2008 at 06:11:45PM +, Dmitry Baryshkov wrote:
> 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
Hi Kumar,
Ok now that makes sense, thanks
So I'll ask, what serial input are you waiting for from the boot wrapper?
It's the editor for the kernel command line.
Thanks,
Jochen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Kumar Gala wrote:
So I'll ask, what serial input are you waiting for from the boot wrapper?
The bootwrapper has a command line editing prompt. It's fairly
gratuitous in the presence of semi-decent firmware, but it's there
nonetheless.
-Scott
--
To unsubscribe from this list: send the line
On Friday, 18 of January 2008, Rafael J. Wysocki wrote:
> On Friday, 18 of January 2008, Dave Jones wrote:
> > On Fri, Jan 18, 2008 at 02:34:59PM +0100, Rafael J. Wysocki wrote:
> > > On Thursday, 17 of January 2008, Andrew Morton wrote:
> > > >
> > > >
> >
On Jan 18, 2008, at 2:40 PM, Alan Cox wrote:
On Fri, 18 Jan 2008 19:47:43 +0100
Jochen Friedrich <[EMAIL PROTECTED]> wrote:
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
On Fri, Jan 18, 2008 at 04:48:44PM -0500, Jeff Layton wrote:
> On Fri, 18 Jan 2008 15:59:43 -0500
> "J. Bruce Fields" <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Jan 14, 2008 at 09:05:15AM -0500, Jeff Layton wrote:
> > > Move the initialzation in __svc_create_thread that happens prior to
> > >
On Fri, 18 Jan 2008 15:59:43 -0500
"J. Bruce Fields" <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 14, 2008 at 09:05:15AM -0500, Jeff Layton wrote:
> > Move the initialzation in __svc_create_thread that happens prior to
> > thread creation to a new function. Export the function to allow
> > services
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > > # Directories & files removed with 'make mrproper'
> > > -MRPROPER_DIRS += include/config include2 usr/include
> > > +MRPROPER_DIRS += include/config include2 usr/include arch/i386
> > > arch/x86_64
> > sigh - arch specific stuff in the
On Fri, 2008-01-18 at 22:37 +0100, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > The first fix is not even specific for PARAVIRT, and it's actually
> > > preventing the whole tree from booting.
> >
> > on CONFIG_EFI, indeed :)
>
> but in exchange you broke all of 32-bit
Hi,
just FYI, upgrading to -rc8 gave the following messages in kern.log in
the morning hours, when the backups were run:
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc8 #2
On Mon, Jan 14, 2008 at 09:05:18AM -0500, Jeff Layton wrote:
> If we're shutting down all the nlm_hosts anyway, then it doesn't make
> sense to allow RPC calls to linger. Allowing them to do so can mean
> that the RPC calls can outlive the currently running lockd and can lead
> to a use after free
On Fri, 18 Jan 2008, Mel Gorman wrote:
> static void check_for_regular_memory(pg_data_t *pgdat)
> {
> #ifdef CONFIG_HIGHMEM
> enum zone_type zone_type;
>
> for (zone_type = 0; zone_type <= ZONE_NORMAL; zone_type++) {
> struct zone *zone = >node_zones[zone_type];
>
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > The first fix is not even specific for PARAVIRT, and it's actually
> > preventing the whole tree from booting.
>
> on CONFIG_EFI, indeed :)
but in exchange you broke all of 32-bit with CONFIG_PARAVIRT=y. Which
means you did not even build-test it
On Fri, Jan 18, 2008 at 09:51:52PM +0100, Ingo Molnar wrote:
>
> * Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > > @@ -1088,7 +1088,7 @@ CLEAN_FILES += vmlinux System.map \
> > > .tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map
> > >
> > > # Directories & files
On Friday 18 January 2008 02:01:41 am Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Ingo,
> > > it seems you removed
> > > > patch
> > > > x86: validate against ACPI motherboard resources
> > > last night.
> > >
> > > was it dropped?
> >
> > yeah, i bounced
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 (18/01/08 10:47), Christoph Lameter didst pronounce:
> 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?
>
Doubtful. Node 0 has no memory but it is still being
On Sat, 19 Jan 2008, Anton Salikhmetov wrote:
>
> Before using pte_wrprotect() the vma_wrprotect() routine uses the
> pte_offset_map_lock() macro to get the PTE and to acquire the ptl
> spinlock. Why did you say that this code was not SMP-safe? It should
> be atomic, I think.
It's atomic WITH
On Fri, Jan 18, 2008 at 10:06:33PM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > > > thx, i've added this to x86.git.
> > >
> > > this broke "make ARCH=i386 randconfig" from working when there's a
> > > 64-bit .config present. (it will not properly generate a
On Friday 18 January 2008 22:12:38 Jeremy Fitzhardinge wrote:
> When booting under KVM, I get a pile of messages out of the CPA
> self-test. It makes it to usermode OK though.
Yes known problem. On some systems the self test interacts badly
with the split mappings created by the PAT code I
On Fri, 2008-01-18 at 12:19 -0800, Greg KH wrote:
> On Fri, Jan 18, 2008 at 03:12:33PM -0500, Lee Schermerhorn wrote:
> > I searched around the archives and web and didn't find any reports on
> > this [maybe just missed them?], so I MUST be doing something
> > wrong/stupid. My config [included]
When booting under KVM, I get a pile of messages out of the CPA
self-test. It makes it to usermode OK though.
J
Linux version 2.6.24-rc8 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070925 (Red
Hat 4.1.2-33)) #1879 SMP PREEMPT Fri Jan 18 11:58:38 PST 2008
BIOS-provided physical RAM map:
Chodorenko Michail <[EMAIL PROTECTED]> writes:
> 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
On Fri, 18 Jan 2008, Pierre Habouzit wrote:
> Hi,
>
> I just came across a strange behavior of epoll that seems to
> contradict the documentation. Here is what happens:
>
> * I have two processes P1 and P2, P1 accept()s connections, and send the
> resulting file descriptors to P2 through
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> > Sounds fine! Don't hesitate to let us know about the lower-hanging
> > fruit you're thinking about. Here are the main things I have so far:
> >
> > * Ideas in the existing Linux-Tiny patchset.
> > * Disable support for non-Intel processors
Andi Kleen <[EMAIL PROTECTED]> writes:
> The config option protects so little code that it is fairly pointless.
> Also a lot of its code was related to itself only (as in panicing without
> TSC). And TSC less CPUs are completely handled at runtime anyways.
>
> This makes 32bit behaviour match
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > thx, i've added this to x86.git.
> >
> > this broke "make ARCH=i386 randconfig" from working when there's a
> > 64-bit .config present. (it will not properly generate a 32-bit
> > config, but still a 64-bit config)
>
> Does it always generate a
* Pallipadi, Venkatesh <[EMAIL PROTECTED]> wrote:
> Ingo, can you remove this PAT MTRR exclusion.
yeah, already did that.
> Actually, this exclusion will not work at all with the current code.
> Infact it should be PAT selects MTRR, for the current code. As
> pat_init() is called during mtrr
2008/1/18, Linus Torvalds <[EMAIL PROTECTED]>:
>
>
> On Fri, 18 Jan 2008, Anton Salikhmetov wrote:
> >
> > The current solution doesn't hit the performance at all when compared to
> > the competitor POSIX-compliant systems. It is faster and does even more
> > than the POSIX standard requires.
>
>
> > Here are the top stack consumers with NR_CPUS = 4k.
> >
> > 16392 isolated_cpu_setup
> > 10328 build_sched_domains
> > 8248 numa_initmem_init
>
> These should run single threaded early at boot so you can probably
* Dave Jones <[EMAIL PROTECTED]> wrote:
> > you mean modifies MTRRs? Which code is that? (besides the
> > /proc/mtrr userspace API)
>
> 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
On Mon, Jan 14, 2008 at 09:05:15AM -0500, Jeff Layton wrote:
> Move the initialzation in __svc_create_thread that happens prior to
> thread creation to a new function. Export the function to allow
> services to have better control over the svc_rqst structs.
>
> Also rearrange the rqstp
> How big is the stack during early startup?
THREAD_ORDER (runs on init_stack's stack)
early init stack could be increased in theory with some effort,
but since that is all single threaded anyways just a few strategic
static __initdata's should be simple enough.
-Andi
--
To unsubscribe from
* Dave Jones <[EMAIL PROTECTED]> wrote:
> 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
> On Thu, 17 Jan 2008, David Schwartz wrote:
> > Nonsense. The 'kfree' function *destroys* the object pointer to by the
> > pointer. How can you describe that as not doing anything to the object?
>
> Here's an idea. Think it through.
>
> Why don't we need write permissions to a file to unlink
Ingo Molnar wrote:
> * Mike Travis <[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.
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > @@ -1088,7 +1088,7 @@ CLEAN_FILES +=vmlinux System.map \
> > .tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map
> >
> > # Directories & files removed with 'make mrproper'
> > -MRPROPER_DIRS += include/config
Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> 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.
>>
* Andi Kleen <[EMAIL PROTECTED]> 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
* Mike Travis <[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 you
Andi Kleen wrote:
> First I think you have to get rid of the THREAD_ORDER stuff -- your
> goal of the whole patchkit after all is to allow distributions to
> support NR_CPUS==4096 in the standard kernels and I doubt any
> distribution will over chose a THREAD_ORDER > 1 in their
> standard kernels
On Friday, 18 of January 2008, Dave Jones wrote:
> On Fri, Jan 18, 2008 at 02:34:59PM +0100, Rafael J. Wysocki wrote:
> > On Thursday, 17 of January 2008, Andrew Morton wrote:
> > >
> > >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/
> > >
> > >
* [EMAIL PROTECTED] <[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.
nack on kernel stack
Rusty Russell wrote:
Just a trivial example.
---
drivers/lguest/lguest_device.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -r 00ab7672f658 drivers/lguest/lguest_device.c
--- a/drivers/lguest/lguest_device.cThu Jan 17 16:54:00 2008 +1100
+++
On Fri, 18 Jan 2008 19:47:43 +0100
Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> 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
Rusty Russell wrote:
This patch lets interrupt handler functions have their natural type
(ie. exactly match the data pointer type); for transition it allows
the old irq_handler_t type as well.
To do this it uses a gcc extension, cast-to-union, which allows a type
to be cast to any type within
Rusty Russell wrote:
This improves typechecking of interrupt handlers by removing
unnecessary (void *) casts and storing handlers in correctly-typed
variables.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Ash Willis <[EMAIL PROTECTED]>
Cc: [EMAIL
On Fri, Jan 18, 2008 at 03:20:24PM -0200, Glauber de Oliveira Costa wrote:
> This patch adds the __parainstructions section to vmlinux.lds.S.
> It's needed for the patching system.
>
> Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
> ---
> arch/x86/kernel/vmlinux_64.lds.S |8
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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
First I think you have to get rid of the THREAD_ORDER stuff -- your
goal of the whole patchkit after all is to allow distributions to
support NR_CPUS==4096 in the standard kernels and I doubt any
distribution will over chose a THREAD_ORDER > 1 in their
standard kernels because it would be too
Michael Opdenacker wrote:
Applies to 2.6.24-rc8-git2
I was struggling to get my email-client no to mangle my patch files,
and I didn't find enough information in the SubmittingPatches file.
By looking for more information on the web, I eventually found the
email-clients.txt file, and it
Ric Wheeler wrote:
Theodore Tso wrote:
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
But I heard some years ago from a disk drive engineer that that is a
myth just like the rotational energy thing. I added that to the
discussion, but admitted that I haven't actually seen a
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
>
> 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.
thanks, applied.
> The first fix is not even specific for PARAVIRT, and
Just a trivial example.
---
drivers/lguest/lguest_device.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -r 00ab7672f658 drivers/lguest/lguest_device.c
--- a/drivers/lguest/lguest_device.cThu Jan 17 16:54:00 2008 +1100
+++ b/drivers/lguest/lguest_device.cThu Jan 17
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> 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]>
Good catch, I know I don't test with
This patch lets interrupt handler functions have their natural type
(ie. exactly match the data pointer type); for transition it allows
the old irq_handler_t type as well.
To do this it uses a gcc extension, cast-to-union, which allows a type
to be cast to any type within the union. When used in
Glauber de Oliveira Costa wrote:
__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.
Hm, in my original patches I put the #ifdef CONFIG_X86_PAE below the
PAGETABLE_LEVELS section. Does that work? Or is that
On Fri, 18 Jan 2008, Anton Salikhmetov wrote:
>
> The current solution doesn't hit the performance at all when compared to
> the competitor POSIX-compliant systems. It is faster and does even more
> than the POSIX standard requires.
Your current patches have two problems:
- they are simply
This improves typechecking of interrupt handlers by removing
unnecessary (void *) casts and storing handlers in correctly-typed
variables.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Ash Willis <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
On Fri, Jan 18, 2008 at 03:12:33PM -0500, Lee Schermerhorn wrote:
> I searched around the archives and web and didn't find any reports on
> this [maybe just missed them?], so I MUST be doing something
> wrong/stupid. My config [included] may be the culprit. Apologies for
> the long cc list. I'm
Please pull from the 'upstream' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream
to receive my 2.6.25 net driver queue into davem/net-2.6.25.git:
Adam Baker (2):
rt2x00: Unconstify rt2x00dev
rt2x00: Place mutex around USB register access
Ingo Oeser wrote:
> 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
I searched around the archives and web and didn't find any reports on
this [maybe just missed them?], so I MUST be doing something
wrong/stupid. My config [included] may be the culprit. Apologies for
the long cc list. I'm copying the kprobes and blktrace maintainers
[addresses from MAINTAINERS]
On Fri, 18 Jan 2008, Ingo Oeser wrote:
> Hi Mike,
>
> On Friday 18 January 2008, [EMAIL PROTECTED] wrote:
> > +config THREAD_ORDER
> > + int "Kernel stack size (in page order)"
> > + range 1 3
THREAD_ORDER can also be used to consolidate the stack size with the
choices available for i386.
This patch adds the __parainstructions section to vmlinux.lds.S.
It's needed for the patching system.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/vmlinux_64.lds.S |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git
101 - 200 of 1161 matches
Mail list logo
