On Thu, Nov 15, 2007 at 11:02:19PM -0800, Andrew Morton wrote:
> On Thu, 15 Nov 2007 21:02:46 -0800 "Abhishek Rai" <[EMAIL PROTECTED]> wrote:
...
> > 3. e2fsck speedup with metaclustering varies from disk
> > to disk with most benefit coming from disks which have a large number
> > of indirect
Subject: PCI: Add PCI quirk function for some chipsets
From: Zhao Yakui <[EMAIL PROTECTED]>
PCI quirk function is added for some chipsets so that the resources
behind LPC bridge can be reserved.
Signed-off-by: Li Shaohua <[EMAIL PROTECTED]>
Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
---
Subject: PNP: Increase the value of PNP constant
From: Zhao Yakui <[EMAIL PROTECTED]>
On some systems the number of resources(IO,MEM) returnedy by PNP
device is greater than the PNP constant, for example motherboard devices.
It brings that some resources can't be reserved and resource
On Thu, Nov 15, 2007 at 11:01:43PM -0600, Rob Landley wrote:
> On Thursday 15 November 2007 21:08:32 WANG Cong wrote:
> > On Thu, Nov 15, 2007 at 01:06:08PM -0800, Greg KH wrote:
> > >Hm, not good. I'll let Jeff handle this :)
> >
> > Could you please try this patch? Can it fix the error?
> >
> >
On Fri, 16 Nov 2007 08:17:08 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > It sounds like it would work OK. What is the setup cost for a usleep?
> > I'd have thought that code which does something like
> >
> > while (i++ < 1000) {
> >
On Fri, 16 Nov 2007 07:13:32 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > > x86: disable preemption in delay_tsc()
> > > >
> > > > Marin Mitov points out that delay_tsc() can misbehave if it is
> > > > preempted and
On Thu, 15 Nov 2007 21:02:46 -0800 "Abhishek Rai" <[EMAIL PROTECTED]> wrote:
> (This patch was previously posted on linux-ext4 where Andreas Dilger
> offered some valuable comments on it).
>
> This patch modifies the block allocation strategy in ext3 in order to
> improve fsck performance. This
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Is there a version of these that works with 2.6.23.1 ?
>
> yes, i've backported it and have uploaded the v2.6.23 version to:
>
>
> http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.23.1-combo.patch
btw., if the trace is too
On Sunday 28 October 2007 21:51, Al Viro wrote:
> -#define MAX_FAULT_REASON_IDX ARRAY_SIZE(fault_reason_strings)
> +#define MAX_FAULT_REASON_IDX ARRAY_SIZE(fault_reason_strings) - 1
The macro is unsafe without yet another ()s around it.
--
vda
-
To unsubscribe from this list: send
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> It sounds like it would work OK. What is the setup cost for a usleep?
> I'd have thought that code which does something like
>
> while (i++ < 1000) {
> foo();
> udelay(1);
> }
>
> would take qiute a bit
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > x86: disable preemption in delay_tsc()
> > >
> > > Marin Mitov points out that delay_tsc() can misbehave if it is
> > > preempted and rescheduled on a different CPU which has a skewed
> > > TSC. Fix it by disabling preemption.
> > >
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> Do we still need to have the realtime-lsm.patch? It has been
> considered obsolete for over a year now. Can we finally remove it.
yeah, we can drop it.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe
* Micah Dowty <[EMAIL PROTECTED]> wrote:
> > I am a bit at a loss as to how this could relate to the patch. This
> > looks like a load balance logic issue that causes the load
> > calculation to go wrong?
>
> My best guess is that this has something to do with the timing with
> which we
On Thu, Nov 15, 2007 at 01:10:16PM -0800, Lucy McCoy wrote:
Hi Lucy,
> I'm not familiar with the termios stuff on Linux so can you take a look
> at the following modified code to see if this solves your NULL ptr problem?
will test the patch tomorrow and get back to you with results.
> Does
On Fri, 16 Nov 2007 05:12:21 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Eric Dumazet a écrit :
> > Arjan van de Ven a écrit :
> >> On Thu, 15 Nov 2007 04:01:48 GMT
> >> Linux Kernel Mailing List wrote:
> >>
> >>> Gitweb:
> >>>
* Mark Lord <[EMAIL PROTECTED]> wrote:
>> sorry, wrong URLs, the correct links are:
>>
>>
>> http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch
>>http://redhat.com/~mingo/latency-tracing-patches/trace-cmd.c
> ..
>
> Is there a version of these
Hi Roman.
> > If user did NOT specify ARCH we should use the kernel configuration - which
> > your solution fail to do.
>
> To make this easy I attached the patch which reverts the problematic
> changes and then you only need this simple change to force the 64BIT value
> for ARCH={i386,x86_64},
On Nov 15, 2007 10:34 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Nov 2007 22:24:12 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > The problem with the first bisect-try was, that everything between
> > bisect-good:
On Thu, 15 Nov 2007 16:59:35 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Index: linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c
> > ===
> > --- linux-2.6.24-rc2-mm1.orig/arch/x86/mm/init_64.c
> > +++
On Thursday 15 November 2007 21:08:32 WANG Cong wrote:
> On Thu, Nov 15, 2007 at 01:06:08PM -0800, Greg KH wrote:
> >Hm, not good. I'll let Jeff handle this :)
>
> Could you please try this patch? Can it fix the error?
>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
Oh what a good idea.
(This patch was previously posted on linux-ext4 where Andreas Dilger
offered some valuable comments on it).
This patch modifies the block allocation strategy in ext3 in order to
improve fsck performance. This was initially sent out as a patch for
ext2, but given the lack of ongoing development on
On Thu, 15 Nov 2007 16:53:30 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > - return __alloc_bootmem_node(NODE_DATA(node), size, size,
> > + return __earlyonly_bootmem_alloc(node, size, size,
> > __pa(MAX_DMA_ADDRESS));
> > }
> >
>
> AFACIT
On Nov 15, 2007 7:39 PM, Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> On Thu, 15 Nov 2007, Mark Knecht wrote:
>
>
> > On Nov 15, 2007 10:40 AM, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > > Finally!
> > >
> > > We are pleased to announce 2.6.24-rc2-rt1.
> > >
> >
> >
> > Hi Steve,
> >Not
Eric Dumazet a écrit :
Arjan van de Ven a écrit :
On Thu, 15 Nov 2007 04:01:48 GMT
Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d90bf5a976793edfa88d3bb2393f0231eb8ce1e5
Commit:
From: Arjan van de Ven <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 19:38:02 -0800
> On Thu, 15 Nov 2007 04:01:48 GMT
> Linux Kernel Mailing List wrote:
>
> > Using a "if (need_resched())" test before calling
> > "cond_resched();" is necessary to avoid spending too much time doing
> > the
Updated version against mainline. Looks even a bit cleaner.
x86_64: Make sparsemem/vmemmap the default memory model V2
V1->V2:
- Rediff against new upstream x86 code that unifies the Kconfig files.
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that
Arjan van de Ven a écrit :
On Thu, 15 Nov 2007 04:01:48 GMT
Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d90bf5a976793edfa88d3bb2393f0231eb8ce1e5
Commit: d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 Parent:
On Thu, 15 Nov 2007 19:41:16 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Nov 2007 04:00:47 GMT
> Linux Kernel Mailing List wrote:
>
> > Gitweb:
> > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=35d5d08a085c56f153458c3f5d8ce24123617faf
> >
On Fri, 16 Nov 2007 02:28:09 +0100 (CET) Roman Zippel wrote:
> Hi,
>
> On Thu, 15 Nov 2007, Sam Ravnborg wrote:
>
> > You suggest just to check ARCH value and not apply your patch. This was
> > not my initial understanding as was hopefully obvious from my reply.
>
> This patch only adds some
On Thu, 15 Nov 2007, Mark Knecht wrote:
> On Nov 15, 2007 10:40 AM, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > Finally!
> >
> > We are pleased to announce 2.6.24-rc2-rt1.
> >
>
>
> Hi Steve,
>Not sure I've ever posted on this list. Always looking to help out
> at my low level.
>
>
On Thu, 15 Nov 2007 04:00:47 GMT
Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=35d5d08a085c56f153458c3f5d8ce24123617faf
> Commit: 35d5d08a085c56f153458c3f5d8ce24123617faf Parent:
>
On Thu, 15 Nov 2007 04:01:48 GMT
Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d90bf5a976793edfa88d3bb2393f0231eb8ce1e5
> Commit: d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 Parent:
>
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like
Move the instrumentation Kconfig to
arch/Kconfig for architecture dependent options
- oprofile
- kprobes
and
init/Kconfig for architecture independent options
- profiling
- markers
Remove the "Instrumentation Support" menu. Everything moves to "General setup".
Delete the
Puts the content of arch/Kconfig in the "General setup" menu.
Linus:
> Should it come with a re-duplication of it's content into each
> architecture, which was the case previously ? The oprofile and kprobes
> menu entries were litteraly cut and pasted from one architecture to
> another. Should
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like
Should hopefully be the final form.
Please wait 1-2 days before merge, just in case Sam changes his mind ;)
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To
Aristeu Rozanski wrote:
> Hello Dan,
>> Patch is valid only for 2.6.23.x, guessing from the recent arch/ changes
>> in 2.6.24-rc.
>>
>> set_rtc_mmss() was used to be called from interrupt context in 2.6.22,
>> however in 2.6.23, it is called from a timer context, where interrupts
>> are enabled.
On Thu, Nov 15, 2007 at 04:22:14PM -0800, Jeremy Fitzhardinge wrote:
> activate_mm() does that.
Yup, which I realized ~10 seconds after sending mail...
Oh well.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line
On Thu, Nov 15, 2007 at 04:15:21PM -0800, Andrew Morton wrote:
> I assumed from the above that Karol was the author of this patch. Please
> let me know if that was wrong.
He is - I forgot the From line...
Jeff
--
Work email - jdike at linux dot intel dot com
-
On Thu, 15 Nov 2007, David Miller wrote:
> > There is no assembly code required. I overdid it in the patch that I sent
> > you trying to make sparc64 use large mappings like x86_64 NUMA. You really
> > do not need that. Look at the IA64 and i386 configurations. There is no C
> > code required.
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 19:10:15 -0800 (PST)
> On Thu, 15 Nov 2007, David Miller wrote:
>
> > > I have not looked at sparc32 sorry. If you simply set up a couple of
> > > configuration values in arch/sparc32/Kconfig then everything will be fine.
> >
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Dumazet wrote:
> I am not sure how compat is handled ? (ie running a 32bit task in a
> 64bit kernel)
I already mentioned that I have a patch here. I'll test it first, though.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain
On Thu, 15 Nov 2007, David Miller wrote:
> > I have not looked at sparc32 sorry. If you simply set up a couple of
> > configuration values in arch/sparc32/Kconfig then everything will be fine.
>
> There is assembler code to write, which as I stated several
> times nobody is going to work on or
On Thu, Nov 15, 2007 at 01:06:08PM -0800, Greg KH wrote:
>On Thu, Nov 15, 2007 at 02:57:21PM -0600, Rob Landley wrote:
>> On Thursday 15 November 2007 00:02:55 Greg KH wrote:
>> > On Wed, Nov 14, 2007 at 11:58:15PM -0600, Rob Landley wrote:
>> > > On Wednesday 14 November 2007 12:54:44 Greg KH
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Thu, 15 Nov 2007 21:23:19 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]>
> wrote:
>
> > * Andrew Morton ([EMAIL PROTECTED]) wrote:
> > > On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > >
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 18:55:21 -0800 (PST)
> On Thu, 15 Nov 2007, David Miller wrote:
>
> > Sparc32 is still broken, as just one of several possible examples.
>
> I have not looked at sparc32 sorry. If you simply set up a couple of
> configuration
Ulrich Drepper a écrit :
This is a first user of sys_indirect. Several of the socket-related system
calls which produce a file handle now can be passed an additional parameter
to set the FD_CLOEXEC flag.
- retval = sock_map_fd(sock);
+ retval = sock_map_fd_flags(sock,
On Thu, 15 Nov 2007, David Miller wrote:
> If you're talking about the VMEMMAP thing, that patch didn't remove
> the problem, it simply added optimizations for sparc64 so that you could
> sweep the problem under the rug.
The virtual mapping of the cpu areas is used by the patch I
posted for
Ulrich Drepper a écrit :
This is the actual architecture-independent part of the system call
implementation.
+
+long sys_indirect(struct indirect_registers __user *userregs,
+ void __user *userparams, size_t paramslen)
+{
+ struct indirect_registers regs;
+ long
On Thu, 15 Nov 2007 18:24:54 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Thu, 15 Nov 2007, Andrew Morton wrote:
>
> > Unfortunately some loon has gone and merged the i386 and x86_64 Kconfig
> > files. I was fixing that up but I worry what effects these Kconfig changes
> >
* Mike Mason ([EMAIL PROTECTED]) wrote:
> snip
>> +void list_modules(void *call_data)
>> +{
>> +/* Enumerate loaded modules */
>> +struct list_head*i;
>> +struct module*mod;
>> +unsigned long refcount = 0;
>> +
>> +mutex_lock(_mutex);
>> +list_for_each(i, ) {
>>
VMCOREINFO_SIZE() should be renamed VMCOREINFO_STRUCT_SIZE() since it's always
returning the size of the struct with a given name. This change would allow
VMCOREINFO_TYPEDEF_SIZE() to simply become VMCOREINFO_SIZE() since it need not
be used exclusively for typedefs.
This discussion is the
This patch fixes the configuration dependencies in the vmcoreinfo data.
i386's "node_data" is defined in arch/x86/mm/discontig_32.c,
and x86_64's one is defined in arch/x86/mm/numa_64.c.
They depend on CONFIG_NUMA:
arch/x86/mm/Makefile_32:7
obj-$(CONFIG_NUMA) += discontig_32.o
This patch adds the array length of "free_area.free_list" to the vmcoreinfo
data so that makedumpfile (dump filtering command) can exclude all free pages
in linux-2.6.24.
makedumpfile creates a small dumpfile by excluding unnecessary pages for the
analysis. To distinguish unnecessary pages,
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 18:19:37 -0800 (PST)
> On Thu, 15 Nov 2007, David Miller wrote:
>
> > Well, the first version of the patch set, the one I tested, did
> > require a lot of BSS space. And that's the one they are writing
> > about.
>
> I am
After some archeology (see http://logfs.org/logfs/inode_state_bits) I
finally figured out what the three I_DIRTY bits do. Maybe others would
prefer less effort to reach this insight.
Signed-off-by: Jörn Engel <[EMAIL PROTECTED]>
---
include/linux/fs.h |8
1 file changed, 4
Ulrich Drepper a écrit :
This part adds support for sys_indirect on x86 and x86-64.
arch/x86/ia32/ia32entry.S|1 +
b/arch/x86/kernel/syscall_table_32.S |1 +
b/include/asm-x86/indirect.h |5 +
b/include/asm-x86/indirect_32.h | 23
On Thu, Nov 15, 2007 at 06:31:49PM -0800, Christoph Lameter wrote:
> On Thu, 15 Nov 2007, Micah Dowty wrote:
>
> > On all kernels I've tested from after your patch was committed, I can
> > reproduce a problem where a single high-priority thread which wakes up
> > very frequently can artificially
From: Greg KH <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 16:31:02 -0800
> On Thu, Nov 15, 2007 at 03:31:22PM +0800, Herbert Xu wrote:
> > On Wed, Nov 14, 2007 at 11:00:39PM -0800, David Miller wrote:
> > >
> > > I was just about to mention this and what I think we should do
> > > instead is keep
Move the instrumentation Kconfig to
arch/Kconfig for architecture dependent options
- oprofile
- kprobes
and
init/Kconfig for architecture independent options
- profiling
- markers
Remove the "Instrumentation Support" menu. Everything moves to "General setup".
Delete the
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like
Hi Andrew,
This patchset should apply flawlessly to 2.6.24-rc2-git5.
Sorry again for the inconvenience.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe
Puts the content of arch/Kconfig in the "General setup" menu.
Linus:
> Should it come with a re-duplication of it's content into each
> architecture, which was the case previously ? The oprofile and kprobes
> menu entries were litteraly cut and pasted from one architecture to
> another. Should
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like
It is better that the existing offsetof() is used for VMCOREINFO_OFFSET().
This discussion is the following:
http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/0584.html
Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>
---
diff -rpuN a/include/linux/kexec.h b/include/linux/kexec.h
---
For readability, all the calls to vmcoreinfo_append_str() are changed to macros
having a prefix "VMCOREINFO_".
This discussion is the following:
http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/0584.html
Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>
---
diff -rpuN
On Thu, 15 Nov 2007, Micah Dowty wrote:
> On all kernels I've tested from after your patch was committed, I can
> reproduce a problem where a single high-priority thread which wakes up
> very frequently can artificially inflate the SMP balancer's load
> average for one CPU, causing other tasks to
Hi,
This patchset is for the vmcoreinfo data.
The vmcoreinfo data has the minimum debugging information only
for dump filtering. makedumpfile (dump filtering command) gets
it to distinguish unnecessary pages, and makedumpfile creates
a small dumpfile.
[PATCH 1/5] Rename vmcoreinfo's macros
On Thu, 15 Nov 2007 21:23:19 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> * Andrew Morton ([EMAIL PROTECTED]) wrote:
> > On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]>
> > wrote:
> >
> > > arch/x86/Kconfig.i386 |1 +
> > > arch/x86/Kconfig.x86_64
On Fri, Nov 16, 2007 at 01:34:54AM +0100, Jesper Juhl wrote:
>On 13/11/2007, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>> Jesper Juhl wrote:
>> > In kernel/exit.c we have this code :
>> >
>> > static void exit_mm(struct task_struct * tsk)
>> > {
>> > struct mm_struct *mm = tsk->mm;
>>
* Mike Mason ([EMAIL PROTECTED]) wrote:
> This patch uses _trace_mark in lockdep.c and printk.c. I assume they
> should be trace_mark (no '_' prefix).
>
Since it folows the markers with immediate values patch, it requires to
use the underscored version, because the lockdep code can be called
On Thu, 15 Nov 2007, john cooper wrote:
>
> It isn't an issue of getting a hook into the FUNCTION_PROLOGUE
> (mcount() here) but rather of emulating the CALLER_ADDR[0123]
> defs which map onto the gcc internal __builtin_return_address().
> Doing so using the affectionately dubbed "Three Stooges
On Thu, 15 Nov 2007, Andrew Morton wrote:
> Unfortunately some loon has gone and merged the i386 and x86_64 Kconfig
> files. I was fixing that up but I worry what effects these Kconfig changes
> might have on, for example, i386 NUMA setups.
>
> So I'll duck this version, sorry.
Is there a tree
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]>
> wrote:
>
> > arch/x86/Kconfig.i386 |1 +
> > arch/x86/Kconfig.x86_64|1 +
>
> these no longer exist.
Ok, should I prepare a fix or is it duplicated
On Thu, 15 Nov 2007, David Miller wrote:
> Well, the first version of the patch set, the one I tested, did
> require a lot of BSS space. And that's the one they are writing
> about.
I am running the same version that you also ran. The problem is that you
did not configure the stuff properly
I have created bug 9391 on bugzilla.kernel.org containing pretty much
everything.
--
Jon
-
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
On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> arch/x86/Kconfig.i386 |1 +
> arch/x86/Kconfig.x86_64|1 +
these no longer exist.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like
Linus:
On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line like
depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like
Puts the content of arch/Kconfig in the "General setup" menu.
Linus:
> Should it come with a re-duplication of it's content into each
> architecture, which was the case previously ? The oprofile and kprobes
> menu entries were litteraly cut and pasted from one architecture to
> another. Should
Move the instrumentation Kconfig to
arch/Kconfig for architecture dependent options
- oprofile
- kprobes
and
init/Kconfig for architecture independent options
- profiling
- markers
Remove the "Instrumentation Support" menu. Everything moves to "General setup".
Delete the
Hi Andrew,
Here are the patches updated following Sam Ravnborg's comments.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line
Steven Rostedt wrote:
On Thu, 15 Nov 2007, Tim Bird wrote:
john cooper wrote:
The more daunting problem stems from limitations in the MIPS
ABI which makes the latency trace support problematic.
Rather than rehash the issue:
http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html
Until
On Fri, Nov 16, 2007 at 10:13:42AM +0900, Yasunori Goto wrote:
> > >
> > > Care to try this:
> > > + system_kset = kset_create_and_register("system", NULL,
> > > + _kset->kobj,
> > > NULL);
> > >
> > > We should not join the kset, only use
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
> You suggest just to check ARCH value and not apply your patch. This was
> not my initial understanding as was hopefully obvious from my reply.
This patch only adds some extra features.
> If user did NOT specify ARCH we should use the kernel
unsubscribe linux-kernel
-
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/
On Thu, 15 Nov 2007 21:01:32 -0400
Kevin Winchester <[EMAIL PROTECTED]> wrote:
> On November 15, 2007 08:44:41 pm Andrew Morton wrote:
> > On Thu, 15 Nov 2007 20:28:29 -0400
> >
> > Kevin Winchester <[EMAIL PROTECTED]> wrote:
> > > On November 15, 2007 06:02:09 am Andy Whitcroft wrote:
>
> > > I
On Thu, 15 Nov 2007, Tim Bird wrote:
> john cooper wrote:
> > The more daunting problem stems from limitations in the MIPS
> > ABI which makes the latency trace support problematic.
> > Rather than rehash the issue:
> >
> > http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html
> >
> >
On November 15, 2007 08:44:41 pm Andrew Morton wrote:
> On Thu, 15 Nov 2007 20:28:29 -0400
>
> Kevin Winchester <[EMAIL PROTECTED]> wrote:
> > On November 15, 2007 06:02:09 am Andy Whitcroft wrote:
> > I see this as well - the computer boots fine but no network. The only
> > clues in the dmesg
On Thu, 15 Nov 2007 19:36:39 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> Changes __meminit to __init_refok.
> ==
> WARNING: vmlinux.o(.text+0x1d07c): Section mismatch: reference to
> .init.text:find_e820_area (between 'init_memory_mapping' and
> 'arch_add_memory')
> ==
>
>
> >
> > Care to try this:
> > + system_kset = kset_create_and_register("system", NULL,
> > + _kset->kobj, NULL);
> >
> > We should not join the kset, only use it as a parent.
>
> Yes, that fixes the problem for me!
>
> Can anyone else
On Nov 16, 2007 8:49 AM, Greg KH <[EMAIL PROTECTED]> wrote:
>
> On Fri, Nov 16, 2007 at 08:39:12AM +0800, Dave Young wrote:
> > On Nov 16, 2007 3:23 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Nov 14, 2007 at 10:19:48AM -0800, Greg KH wrote:
> > > > On Wed, Nov 14, 2007 at
On Fri, Nov 16, 2007 at 08:39:12AM +0800, Dave Young wrote:
> On Nov 16, 2007 3:23 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Nov 14, 2007 at 10:19:48AM -0800, Greg KH wrote:
> > > On Wed, Nov 14, 2007 at 06:02:07PM +0100, Jiri Kosina wrote:
> > > > On Wed, 14 Nov 2007, Jiri Kosina
On Thu, 15 Nov 2007 19:35:44 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> Fixes section mismatch below.
>
> WARNING: vmlinux.o(.text+0x946b5): Section mismatch: reference to .init.text:'
> __alloc_bootmem_node (between 'vmemmap_alloc_block' and
> 'vmemmap_pgd_populate')
>
> Changelog
>
Stefan Monnier wrote:
So I'd like to be able to say "these areas of my file-system hold data
that you can discard whenever you need space". So I can freely fill up
my disk with such irrelevant data, safe in the knowledge that if I ever
need this disk space it'll be automatically reclaimed.
> So the _only_ explanation today for 12GB on a 32-bit machine is
> (a) insanity
> or
> (b) being so lazy as to not bother to upgrade
> and in either case, my personal reaction is "I'm *not* crazy, and yes, I'm
> lazy too, and I can't give a rats *ss about those problems".
12GB-16GB worked
On Thu, 15 Nov 2007 20:28:29 -0400
Kevin Winchester <[EMAIL PROTECTED]> wrote:
> On November 15, 2007 06:02:09 am Andy Whitcroft wrote:
> > When testing some of the later 2.6.24-rc2-mm1+hotfix combinations on three
> > of our test systems one job from each batch (1/4) failed. In each case the
>
On Fri, Nov 16, 2007 at 12:59:41AM +0100, Jiri Slaby wrote:
> On 11/14/2007 10:48 PM, Rafael J. Wysocki wrote:
> > On Wednesday, 14 of November 2007, Jiri Slaby wrote:
> >> On 11/14/2007 02:59 AM, Andrew Morton wrote:
> >>>
William Lee Irwin III wrote:
There may be bigger fish to fry in terms of per-process overhead, if
you're trying to cut that down. The trouble with trying to address
some of those is that there is mutual antagonism between compactness
and expansibility in the process address space layout, so
1 - 100 of 890 matches
Mail list logo
