On Friday 18 January 2008 07:28:49 pm Dave Jones wrote:
> On Fri, Jan 18, 2008 at 10:02:10PM +0100, Ingo Molnar wrote:
> >
> > * Dave Jones <[EMAIL PROTECTED]> wrote:
> >
> > > > you mean modifies MTRRs? Which code is that? (besides the
> > > > /proc/mtrr userspace API)
> > >
> > > Thi
[PATCH] X86: disable X86_PAT really
when X86_PAT is not selected, we don't need to do anything in reserve_mattr and
free_mattr
also need to bail out if cpu not support PAT.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 1036134..b3cdee1 1
On 1/18/08, Michael Opdenacker <[EMAIL PROTECTED]> wrote:
> Do you mean "almost nothing"? It still allocates and adds a platform
> device, and the corresponding function always gets called at boot time.
Nothing significant then. I don't see any added functionality from this file.
--
Taral <[EMAI
On Fri, Jan 18, 2008 at 06:06:24PM -0700, Jordan Crouse wrote:
> I don't know how much of a hassle it would be for Andres to get a 2.6.24
> kernel running on the OLPC to make sure that this isn't a regression
> in the timer tick code (I suspect it isn't a regression, but you never
> know). I also
Teach c_p_a() to split and unsplit GB pages.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/mm/pageattr_64.c | 150 --
1 file changed, 119 insertions(+), 31 deletions(-)
Index: linux/arch/x86/mm/pageattr_64.c
This should decrease TLB pressure because the kernel will need
less TLB faults for its own data access.
Only done for 64bit because i386 does not support GB page tables.
This only applies to the data portion of the direct mapping; the
kernel text mapping stays with 2MB pages because the AMD Fam1
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
Documentation/x86_64/boot-options.txt |3 +++
arch/x86/mm/init_64.c | 12
include/asm-x86/pgtable_64.h |2 ++
3 files changed, 17 insertions(+)
Index: linux/arch/x86/mm/init_64.c
==
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/mm/fault_64.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux/arch/x86/mm/fault_64.c
===
--- linux.orig/arch/x86/mm/fault_64.c
+++ linux/arch/x86/mm
Split the existing LARGE_PAGE_SIZE/MASK macro into two new macros
PUD_PAGE_SIZE/MASK and PMD_PAGE_SIZE/MASK.
Fix up all callers to use the new names.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/boot/compressed/head_64.S |8
arch/x86/kernel/head_64.S |4
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-x86/pgtable_64.h |6 ++
1 file changed, 6 insertions(+)
Index: linux/include/asm-x86/pgtable_64.h
===
--- linux.orig/include/asm-x86/pgtable_64.h
+++ linux/inclu
This patch series supports using the new GB pages introduced with
AMD Quad Cores for the kernel direct mapping.
I addressed all reasonable feedback for the previous version I believe.
Changes against previous version:
- Ported on top of latest git-x86 with PAT series
- Fixed some white space
-
This was a long standing obscure problem in the relocatable kernel. The
AMD GART driver needs to unmap part of the GART in the kernel direct mapping to
prevent cache corruption. With the relocatable kernel it is in theory possible
that the separate kernel text mapping straddles that area too.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-x86/cpufeature.h |2 ++
1 file changed, 2 insertions(+)
Index: linux/include/asm-x86/cpufeature.h
===
--- linux.orig/include/asm-x86/cpufeature.h
+++ linux/include/a
Mel Gorman <[EMAIL PROTECTED]> writes:
> A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
> on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
> at the restrictions on setting NUMA on x86 to see if they could be lifted.
The problem with i386 CONFIG_N
One of my test systems didn't boot with latest git-x86.
I bisected it down to f1321f875910172bcc3e1f302fe145a9e4d3bdf7
With later patches the fault seemed to happen even earlier before
other initialization messages.
Config is available at http://halobates.de/config
-Andi
commit f1321f875910172
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roland McGrath wrote:
> +#define RUSAGE_LWP RUSAGE_THREAD /* Solaris name for same */
No need to clutter the kernel header with this, it'll be in the libc header.
Aside from that:
Acked-by: Ulrich Drepper <[EMAIL PROTECTED]>
- --
➧ Ulri
On Jan 18, 2008 9:17 PM, David Rientjes <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Jan 2008, Yinghai Lu wrote:
>
> > > > I got
> > > > SART: PXM 0 -> APIC 0 -> Node 255
> > > > SART: PXM 0 -> APIC 1 -> Node 255
> > > > SART: PXM 1 -> APIC 2 -> Node 255
> > > > SART: PXM 1 -> APIC 3 -> Node 255
> > > >
> syscall nr and pid at minimum then.
oprofile already supports logging the pid I believe. Otherwise
the pid filter in opreport could hardly work.
> Still doesn't work for modules either.
oprofile works fine for modules.
>
> what it ends up doing is using an entirely different interface for
>
From: Denis Cheng <[EMAIL PROTECTED]>
Date: Sat, 19 Jan 2008 13:29:51 +0800
Subject: [PATCH] kernel/params.c: fix the module name length in
param_sysfs_builtin
the original code use KOBJ_NAME_LEN for built-in module name length,
that's defined to 20 in linux/kobject.h, but this is not enough appea
Andi Kleen wrote:
another thing that the current profiling can't do, is to show what the
system is doing
when it hits the latency.. so someone calling fsync() will show up in the
waiting for
IO function, but not that it was due to an fsync().
Hmm so how about extending oprofile to always log
On Sat, Jan 19, 2008 at 06:33:30AM +0100, Andi Kleen wrote:
> > another thing that the current profiling can't do, is to show what the
> > system is doing
> > when it hits the latency.. so someone calling fsync() will show up in the
> > waiting for
> > IO function, but not that it was due to an f
> another thing that the current profiling can't do, is to show what the
> system is doing
> when it hits the latency.. so someone calling fsync() will show up in the
> waiting for
> IO function, but not that it was due to an fsync().
Hmm so how about extending oprofile to always log the syscall
Andi Kleen wrote:
yes indeed; I sort of use the same infrastructure inside the scheduler; the
biggest
reason I felt I had to do something different was that I wanted to do per
process
data collection, so that you can see for a specific process what was going
on.
Wouldn't it have been easier t
> yes indeed; I sort of use the same infrastructure inside the scheduler; the
> biggest
> reason I felt I had to do something different was that I wanted to do per
> process
> data collection, so that you can see for a specific process what was going
> on.
Wouldn't it have been easier then to j
On Fri, 18 Jan 2008, Yinghai Lu wrote:
> > > I got
> > > SART: PXM 0 -> APIC 0 -> Node 255
> > > SART: PXM 0 -> APIC 1 -> Node 255
> > > SART: PXM 1 -> APIC 2 -> Node 255
> > > SART: PXM 1 -> APIC 3 -> Node 255
> > >
> >
> > I assume this is a typo and those proximity mappings are actually from th
Hi there,
obviously this is a newbie question, but I couldn't find any
documentation on how to do it.. I tried several ways but couldnt do
it.
I designed a system call, so a user will call it, and a new file will
be created ('/tmp/filexx'). After that, I have another system call,
that will map the
Andi Kleen wrote:
Arjan van de Ven <[EMAIL PROTECTED]> writes:
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.
Just for completeness -- Linux already had a way to profile latencies
si
On Sat, 2008-01-19 at 06:08 +0100, Andi Kleen wrote:
> On Saturday 19 January 2008 05:22:29 Harvey Harrison wrote:
> > Adding the address of the faulting library missed removing a
> > line ending from X86_32.
> >
> > Also update the shorter printk format for X86_32 in fault_64.c
> > to make it eas
On Saturday 19 January 2008 05:22:29 Harvey Harrison wrote:
> Adding the address of the faulting library missed removing a
> line ending from X86_32.
>
> Also update the shorter printk format for X86_32 in fault_64.c
> to make it easier to se the remaining differences.
Thanks. I think it was corr
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> 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.
Just for completeness -- Linux already had a way to profile latencies
since quite some t
Hi Andrew,
Can you please queue this patch in -mm for .25. It was posted earlier
and nobody complained.
Thanks,
-Andi
Remove ibcs2 support in ELF loader too
ibcs2 support has never been supported on 2.6 kernels as far as I know,
and if it has it must have been an external patch. Anyways
On Thu, 17 Jan 2008, Olaf Hering wrote:
> On Thu, Jan 17, Olaf Hering wrote:
>
> > Since -mm boots further, what patch should I try?
>
> rc8-mm1 crashes as well, l3 passed to reap_alien() is NULL.
Sigh. It looks like we need alien cache structures in some cases for nodes
that have no memory. W
Fix information leak in CIFS client lookup
Putting arbitary file names on lookup failures into the system log is not
a good idea, because usually everybody can read dmesg and that is thus
an information leak if a directory was read protected.
Also changed the error printout for this case to a si
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
> It will relative to not throttling.
No it will not. Please reread Dominik's mail I linked to. It explains
it clearly.
> You made a claim that is -physically impossible- as stated, a claim I've
> seen here before and I'm correcting it. If something reduces heat, it
> must save power *by the def
Hi,
On Wed, 16 Jan 2008, Sam Ravnborg wrote:
> But one feature I really would like to see is named chocies so we can do
> stuff like:
>
> choice X86_PROCESSOR
>
> config GENERIC_PROCESSOR
> bool "A generic X86 processor"
> endchoice
>
>
> ...
>
> choice PPC_PROCESSOR
>
> config GENER
On Jan 18, 2008 8:36 PM, David Rientjes <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Jan 2008, Yinghai Lu wrote:
>
> > > +#if MAX_NUMNODES > 256
> > > +typedef u16 numanode_t;
> > > +#else
> > > +typedef u8 numanode_t;
> > > +#endif
> > > +
> > > #endif /* _LINUX_NUMA_H */
> >
> > that is wrong, you ca
On Sat, 2008-01-19 at 05:27 +0100, Andi Kleen wrote:
> > So while throttling may be less efficient in terms of watt seconds used
> > to compile something than running at full speed, it is incorrect to say
> > it uses less power. One machine running for an hour throttled to 50%
> > uses less power
On Fri, 18 Jan 2008, Yinghai Lu wrote:
> > +#if MAX_NUMNODES > 256
> > +typedef u16 numanode_t;
> > +#else
> > +typedef u8 numanode_t;
> > +#endif
> > +
> > #endif /* _LINUX_NUMA_H */
>
> that is wrong, you can not change pxm_to_node_map from int to u8 or u16.
>
Yeah, NID_INVAL is negative so
Hi,
On Wed, 16 Jan 2008, Jan Beulich wrote:
> now that I finally found time to look into the problems that caused the
> patch changing boolean/tristate choice behavior to be reverted I find
> that due to the way things worked in the past there are a couple of
> cases where config options not real
- is_cpu(INTEL) actually refers only to the MTRR architecture
and all AMD CPUs since K7 use the Intel MTRR architecture so the
fixup code runs on AMD too. Remove a comment claiming otherwise.
[Perhaps is_cpu should be renamed, the name is clearly confusing]
- Clarify another incorrect comment.
Newer AMD systems (since K8RevF) have a magic SYSCFG MSR bit to force WB
on memory beyond 4GB. This is not reflected in the standard MTRR
MSRs, so the MTRR checking routine would get confused and disable
perfectly good RAM beyond 4GB. Implement code for checking that bit.
Signed-off-by: Andi Kle
Hi -
On Fri, Jan 18, 2008 at 10:55:27PM -0500, Steven Rostedt wrote:
> [...]
> > All this complexity is to be justified by keeping the raw prev/next
> > pointers from being sent to a naive tracer? It seems to me way out of
> > proportion.
>
> Damn, and I just blew away all my marker code for som
On Fri, 18 Jan 2008 18:50:03 -0600
Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-01-18 at 17:54 -0500, Rik van Riel wrote:
> > Backup programs not seeing an updated mtime is a really big deal.
>
> And that's fixed with the 4-line approach.
>
> Reminds me, I've got a patch here for addre
> So while throttling may be less efficient in terms of watt seconds used
> to compile something than running at full speed, it is incorrect to say
> it uses less power. One machine running for an hour throttled to 50%
> uses less power (and therefore less battery and cooling) than another
> runnin
Adding the address of the faulting library missed removing a
line ending from X86_32.
Also update the shorter printk format for X86_32 in fault_64.c
to make it easier to se the remaining differences.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
Ingo, trivial printk update after Andi's p
On Sat, 2008-01-19 at 02:15 +0100, Andi Kleen wrote:
> On Fri, Jan 18, 2008 at 06:27:57PM -0600, Matt Mackall wrote:
> >
> > On Fri, 2008-01-18 at 22:11 +0100, Andi Kleen wrote:
> > > Chodorenko Michail <[EMAIL PROTECTED]> writes:
> > >
> > > > I have a laptop "Extensa 5220", with the processor
Hello,
Rusty Russell wrote:
> There are three possibilities: (1) force everyone to use void *, (2)
> force
> everyone to be type-correct, (3) allow both with some tricks. Currently
> we're on (1). For kthread, with only dozens of users, I chose (2) (very
> simple, easy to understand). I
On Jan 18, 2008 10:30 AM, <[EMAIL PROTECTED]> wrote:
> 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
On Saturday 19 January 2008 12:44:52 Tejun Heo wrote:
> Tejun Heo wrote:
> > so I think the question is "do we want to change all callbacks to
> > take native pointer type instead of void pointer?".
>
> Lemme clarity myself a bit. I'm not saying that we should convert all
> at once or literally ev
On Fri, 18 Jan 2008, Frank Ch. Eigler wrote:
>
> All this complexity is to be justified by keeping the raw prev/next
> pointers from being sent to a naive tracer? It seems to me way out of
> proportion.
Damn, and I just blew away all my marker code for something like this ;-)
Actually, you jus
Hi -
On Fri, Jan 18, 2008 at 06:19:29PM -0500, Mathieu Desnoyers wrote:
> [...]
> Almost.. I would add :
>
> static int trace_switch_to_enabled;
>
> > static inline trace_switch_to(struct task_struct *prev,
> > struct task_struct *next)
> > {
> if (likely(!trace_switch_to
Hi -
On Fri, Jan 18, 2008 at 05:49:19PM -0500, Steven Rostedt 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 c
On Fri, Jan 18, 2008 at 10:02:10PM +0100, Ingo Molnar wrote:
>
> * 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
> > kerne
looks very similar to
http://marc.info/?l=linux-kernel&m=119759817332220&w=2
http://marc.info/?l=linux-kernel&m=119902059626408&w=2
http://marc.info/?l=linux-kernel&m=119259674826979&w=2
http://lkml.org/lkml/2006/6/14/59
so you should try without CONFIG_MTD_PNC2000
that driver having problems f
On Fri, Jan 18, 2008 at 01:41:33PM +0800, Fengguang Wu wrote:
> > That is, think of large file writes like process scheduler batch
> > jobs - bulk throughput is what matters, so the larger the time slice
> > you give them the higher the throughput.
> >
> > IMO, the sort of result we should be look
> > I think it should be enabled on AMD too though. If the reordering breaks
> > it then blacklisting won't help anyways.
Actually it is already enabled on AMD. You check for is_cpu(INTEL)
but that just checks the generic MTRR architecture and all AMD CPUs
since K7 use that one too.
That is ok im
In copy_tlv() we have
tlv = kmalloc(data[1] * 4 + sizeof(data), GFP_KERNEL);
if (!tlv)
return NULL;
memcpy(tlv, data, sizeof(data));
if (copy_from_user(tlv + 2, _tlv + 2, data[1])) {
kfree(tlv);
return NULL;
}
w
export __supported_pte_mask variable as GPL symbol.
lguest is a user of it.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/setup64.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/setup64.c b/arch/x86/kernel/setup64.c
in
Exporrt check_tsc_unstable function as GPL symbol. lguest is
a user of it.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/tsc_64.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/tsc_64.c b/arch/x86/kernel/tsc_64.c
inde
x86_64 don't expose the intermediate representation with one underline,
_PAGE_KERNEL, just the double-underlined one.
Use it, to get a common ground between 32 and 64-bit
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
drivers/lguest/page_tables.c |4 ++--
1 files changed, 2
This patch adds the sched.h header explicitly to lguest_user file,
and avoid depending on it being included somewhere else.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
drivers/lguest/lguest_user.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/driver
This patch adds the hrtimer.h header explicitly to lg.h file,
and avoid depending on it being included somewhere else.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
drivers/lguest/lg.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/lguest/lg.h
This patch adds the ktime.h header explicitly to hypercalls file,
and avoid depending on it being included somewhere else.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
drivers/lguest/hypercalls.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/
Right now, I have lguest in-tree module compiling on x86_64.
It's not yet on a sendable state, since the module itself isn't loading.
However, this subset of the series is pretty straightforward, and I'm sending it
now aiming at reducing the delta size in the future ;-)
Have fun,
--
To unsubscr
Tejun Heo wrote:
> so I think the question is "do we want to change all callbacks to
> take native pointer type instead of void pointer?".
Lemme clarity myself a bit. I'm not saying that we should convert all
at once or literally every callback should be converted. What I'm
saying is whether we'
Hello, Rusty.
Rusty Russell wrote:
> On Saturday 19 January 2008 10:12:33 Tejun Heo wrote:
>> Type safety is good but I doubt this would be worth the complexity. It
>> has some benefits but there's much larger benefit in keeping things in
>> straight C. People know that functions take fixed type
This is a note to let you know that I've just added the patch titled
Subject: Driver Core: constify the name passed to
platform_device_register_simple
to my gregkh-2.6 tree. Its filename is
driver-core-constify-the-name-passed-to-platform_device_register_simple.patch
This tree can
On Saturday 19 January 2008 07:41:41 Jeff Garzik wrote:
> FWIW, I have been working in this area extensively.
Excellent...
> Check out the 'irq-cleanups' and 'irq-remove' branches of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
Your irq-cleanups branch is nice work! But
On Fri, Jan 11, 2008 at 01:57:27AM -0700, Jan Beulich wrote:
> The drivers picked just serve as examples (which I routinely build and
> hence am able to easily verify), i.e. as before he patch doesn't change
> all instances where 'const' could have been added as a result of the
> base change, only
On Fri, Jan 11, 2008 at 08:37:55AM +, Jan Beulich wrote:
> .. as all consumers of it don't require it to be modifiable.
>
> Unfortunately, due to the two-level constifications, this required
> touching quite many files, not all of which I am able to test - please
> bare with eventual mistakes
On Saturday 19 January 2008 10:12:33 Tejun Heo wrote:
> Type safety is good but I doubt this would be worth the complexity. It
> has some benefits but there's much larger benefit in keeping things in
> straight C. People know that functions take fixed types and are also
> familiar with the conven
On Jan 18, 2008 8:02 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * 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 rush
On my x86_64 machine, I got the following message
in log (kern = 2.6.23.14)
Jan 16 04:08:38 Astara kernel: BUG: MAX_LOCK_DEPTH too low!
Jan 16 04:08:38 Astara kernel: turning off the locking correctness
validator.
Have no idea what caused it as I found the message on my console
somewhat after
On Fri, Jan 18, 2008 at 12:26:13PM -0800, Chris Wright wrote:
> * 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 Oliveir
On 17/01/08 23:52 +0100, Arnd Hannemann wrote:
> >> Watchdog for the new API would be great :-)
> >
> > Coming soon.
As promised, a watchdog driver for the Geode GX/LX processors is attached.
I basically just ported the previous patch forward to 2.6.24.
I also have good news or bad news dependin
I agree that RUSAGE_THREAD is fine. (In fact, if you'd pressed me to
remember without looking, I would have assumed we put it in already.)
However, in the implementation, I would keep it cleaner by moving the
identical code from inside the loop under case RUSAGE_SELF into a shared
subfunction, rat
This adds the RUSAGE_THREAD option for the getrusage system call.
Solaris calls this RUSAGE_LWP and uses the same value (1).
That name is not a natural one for Linux, but we keep it as an alias.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
include/linux/resource.h |2 ++
kernel/sys.
On Fri, Jan 18, 2008 at 06:27:57PM -0600, Matt Mackall wrote:
>
> On Fri, 2008-01-18 at 22:11 +0100, Andi Kleen wrote:
> > Chodorenko Michail <[EMAIL PROTECTED]> writes:
> >
> > > I have a laptop "Extensa 5220", with the processor Celeron based on 'core'
> > > technology.
> > > There is ~ / arch/
On Fri, 2008-01-18 at 17:54 -0500, Rik van Riel wrote:
> On Fri, 18 Jan 2008 14:47:33 -0800 (PST)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > - keep it simple. Let's face it, Linux has never ever given those
> >guarantees before, and it's not is if anybody has really cared. Even
> >
On Thu, Jan 17, 2008 at 03:15:23PM -0800, Kevin Lloyd wrote:
> > > Correct, the 0x0023 is the only newly added device that requires the
> new
> > > features.
> >
> > Does that mean things will not work for this device if it is added to
> > the device table, without the code updates?
> Adding the de
This is a note to let you know that I've just added the patch titled
Subject: PM: Acquire device locks on suspend
to my gregkh-2.6 tree. Its filename is
pm-acquire-device-locks-on-suspend.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregk
On Fri, 2008-01-18 at 22:11 +0100, Andi Kleen wrote:
> 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
Oops, I overlooked the use of elf_core_copy_regs in kernel/kexec.c. It
is certainly safe and fine to reintroduce the old macro. Everything
removed in the "x86 user_regset cleanup" patch is purely removing code
and it doesn't hurt to have it back (it's just all unused except for this
kexec nit).
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 18 Jan 2008 15:17:21 -0500
>
> 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:
Pulled and pushed back o
James Bottomley wrote:
>> I'm just a bit reluctant to touch these drivers, since they're all
>> incredibly ancient. We don't have good luck with simple transformation
>> patches on the older drivers ... and it seems to take months before
>> anyone notices there's a problem.
>
> This is the patch
On Fri, January 18, 2008 20:16, Mingming Cao wrote:
> 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 41
On Fri, 2008-01-18 at 17:32 -0600, James Bottomley wrote:
> On Sat, 2008-01-19 at 08:27 +0900, Tejun Heo wrote:
> > James Bottomley wrote:
> > > On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
> > >> aha152x.c and fdomain are built twice - once for the isa driver and
> > >> once for the PCMCIA
James Bottomley wrote:
>> I personally think it's a bit odd to disallow building into kernel
>> because of the peculiarity of the implementation (including c files and
>> compiling them slightly differently) and also no one reporting doesn't
>> necessarily mean no one has attempted it and failed.
>
"J.A. Magallón" <[EMAIL PROTECTED]> writes:
> That's what __attribute__ ((pure)) is for, but if none of the
> functions is pure, the compiler can not be sure about side effects
> and can not reorder things. Don't forget that functions can do
> anything apart from mangling with their arguments.
Th
On Sat, 2008-01-19 at 08:27 +0900, Tejun Heo wrote:
> James Bottomley wrote:
> > On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
> >> aha152x.c and fdomain are built twice - once for the isa driver and
> >> once for the PCMCIA one. Through #ifdefs, the compiled codes are
> >> slightly differe
Tejun Heo wrote:
> James Bottomley wrote:
>> On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
>>> aha152x.c and fdomain are built twice - once for the isa driver and
>>> once for the PCMCIA one. Through #ifdefs, the compiled codes are
>>> slightly different; thus, global symbols need to be give
James Bottomley wrote:
> On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
>> aha152x.c and fdomain are built twice - once for the isa driver and
>> once for the PCMCIA one. Through #ifdefs, the compiled codes are
>> slightly different; thus, global symbols need to be given different
>> names de
Frank Ch. Eigler wrote:
Hi -
On Fri, Jan 18, 2008 at 02:33:34PM -0800, Arjan van de Ven wrote:
[...]
Can you suggest of some reason why all this instrumentation could
not be in the form of standard markers (perhaps conditionally
compiled out if necessary)?
sure. Every instrumentation you see
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> 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 th
Hi -
On Fri, Jan 18, 2008 at 02:33:34PM -0800, Arjan van de Ven wrote:
> [...]
> > Can you suggest of some reason why all this instrumentation could
> > not be in the form of standard markers (perhaps conditionally
> > compiled out if necessary)?
>
> sure. Every instrumentation you see is of the
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.c Thu Jan 17 16:54:00 2008 +1100
> +++ b/drivers/lguest/
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);
>> mprintk_push(&mp, ", %u sectors\n", 1024);
On Fri, Jan 18, Christoph Lameter wrote:
> Could you try this patch?
Does not help, same crash.
--
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 t
On Fri, 18 Jan 2008 14:47:33 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> - keep it simple. Let's face it, Linux has never ever given those
>guarantees before, and it's not is if anybody has really cared. Even
>now, the issue seems to be more about paper standards conformance
1 - 100 of 606 matches
Mail list logo
