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 controllers (quite probably affected by both
driver and hardware
On Fri, 2008-01-18 at 09:27 -0800, Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
> > * Ian Campbell <[EMAIL PROTECTED]> wrote:
> >
> >
> >>> Eric Biederman had a patchset that makes a PAE kernel use PAE page
> >>> tables from the start. That is really The Right Thing[TM].
> >>>
> >>
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote on 01/18/2008 07:08:30 AM:
> Bryan Henderson wrote:
> >
> > We weren't actually talking about writing out the cache. While that
was
> > part of an earlier thread which ultimately conceded that disk drives
most
> > probably do not use the spinning
A few more high level annotations for LatencyTOP;
split into a separate patch since they're at a higher level
than the first part (and thus hide some lower level details
potentially, but could also obsolete several other low level
instrumentations)
---
fs/read_write.c |7 ++-
>> 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 if you inspect the code.
There's a strong chance that the patch
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
---
arch/x86/mm/fault_64.c|4
block/ll_rw_blk.c |
This patch is the core LatencyTOP kernel infrastructure;
it measures latencies in the scheduler and tracks it system
wide and per process
---
fs/proc/base.c | 61 +
include/linux/latencytop.h | 62 +
include/linux/sched.h |6
kernel/Makefile|
On Thu, Jan 17, 2008 at 09:02:44PM -0800, David Schwartz wrote:
> 3) It is most useful for 'kfree' to be non-const because destroying an
> object through a const pointer can easily be done in error. One of the
> reasons you provide a const pointer is because you need the function you
> pass the
Hello,
On Jan 18, 2008 4:55 PM, Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> On Fri, 18 Jan 2008, Francis Moreau wrote:
>
> > Maybe I missed it but I'm wondering why GIT is not used for
> > the RT development ? I can't find a rt tree anywhere and all
> > new rt release spoke about a patchset to
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 video --everyone knows the symptoms
of latency. But to know what's really
On Fri, 2008-01-18 at 18:23 +0100, Mariusz Kozlowski wrote:
> Hello,
>
> > > Do we need `offset' at all?
> >
> > Looks like no.
> >
> > I wonder if there's a good argument for adding a pte_offset_val() which
> > would let us do:
> >
> > pteval = pte_offset_val(pmd, addr);
> >
> > and shrink
* Pallipadi, Venkatesh <[EMAIL PROTECTED]> [2008-01-18 09:13:10]:
>
>
> >-Original Message-
> >From: Andreas Herrmann3 [mailto:[EMAIL PROTECTED]
> >Sent: Friday, January 18, 2008 8:11 AM
> >To: Pallipadi, Venkatesh
> >Cc: Ingo Molnar; Siddha, Suresh B; [EMAIL PROTECTED];
> >[EMAIL
J. Bruce Fields wrote:
On Fri, Jan 18, 2008 at 11:45:52AM -0500, Peter Staubach wrote:
Matthew Wilcox wrote:
On Fri, Jan 18, 2008 at 10:36:01AM -0500, Peter Staubach wrote:
static int path_lookup_create(int dfd, const char *name,
- unsigned int
On Fri, 18 Jan 2008, Jan Kiszka wrote:
> Steven Rostedt wrote:
> ...
> > @@ -978,7 +980,13 @@ void release_console_sem(void)
> > console_locked = 0;
> > up(_sem);
>
> Hmm, just looking at this fragment: Doesn't up() include the risk of
> running onto the runqueue lock as well?
In
Scott Wood schrieb:
+void watchdog_poke(void)
+{
+if (wdt) {
+out_be16(>swsrr, 0x556c);
+out_be16(>swsrr, 0xaa39);
+}
+}
This should be a function pointer, to allow for other watchdog types.
Thanks for the comments. Stephen Rothwell also asked if the filename
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 for system calls which take pathnames
as arguments.
On Thu, 2008-01-17 at 16:11 -0800, Roland Dreier wrote:
> Here all the patches I already have in my for-2.6.25 branch:
> 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 ?
-- Hal
Ingo Molnar wrote:
* Ian Campbell <[EMAIL PROTECTED]> wrote:
Eric Biederman had a patchset that makes a PAE kernel use PAE page
tables from the start. That is really The Right Thing[TM].
That's much saner than dup'ing up the early ioremap stuff to support
both PAE and non-PAE at
On Fri, Jan 18, 2008 at 06:00:37PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > # Select 32 or 64 bit
> > > config 64BIT
> > > - bool "64-bit kernel" if ARCH = "x86"
> > > + bool "64-bit kernel"
> > >
Add a generic option to clear any cpuid bit. I added it because it was
very easy to add with the new generic cpuid disable bitmap and perhaps
it will be useful in the future.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt | 13 +
To disable CLFLUSH usage, especially in change_page_attr().
Ingo asked for this.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |2 ++
arch/x86/kernel/cpu/common.c|7 +++
arch/x86/kernel/setup_64.c |7 +++
3 files
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 x86-64.
I also removed an #if
This cleans up quite a lot of code.
I think I test compiled all the affected variants (voyager, numaq),
but didn't test them, but the change is pretty straight forward for
them.
This means NUMAQ didn't compile, but I don't think it was related
to my patches.
Signed-off-by: Andi Kleen
Modern 32bit userland doesn't even boot when the TSC is disabled
because ld.so tends to contain RDTSCs. So make notsc only effective for the
kernel, similar to 64bit.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/common.c |1 -
1 file changed, 1 deletion(-)
Index:
There are already various options to disable specific cpuid bits
on the command line. They all use their own variable. Add a generic
mask to make this easier in the future.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/common.c |6 ++
arch/x86/kernel/setup_64.c
This convers nofxsr, mem=nopentium and nosep to use the new
generic cpuid disable bitmap instead of using own variables.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/common.c | 34 --
arch/x86/kernel/setup_32.c |5 +
2 files
* Andrew Morton <[EMAIL PROTECTED]> [2008-01-17 02:35:14]:
> - kvm probably doesn't work properly because I couldn't be bothered fixing
> the conflicts between git-kvm and the driver tree
>
Hi, Andrew,
The following changes got KVM up and running for me
This patch fixes the kvm build on
I added a noclflush option because Ingo asked for it to make
it possible to disable parts of the new CPA code.
While I was at it I did some generic cleanup in the area of cpuid disable
options and generalized them a bit. That is where the other patches come from.
-Andi
--
To unsubscribe from
xming wrote:
Would it be possible to map the eip and some top parts of the stack back
to kernel symbols? Seems to be the same place in both traces, which is
interesting.
Can you tell me how, or show me some pointers?
Do "nm -n vmlinux" on the kernel to set an address sorted list of
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);
> printf("%d", x);
>
> to:
>
> void foo(const int *x);
> printf("%d", x);
> foo(x);
That's
Hi Mark,
On Fri, Jan 18, 2008 at 04:27:06PM +, Mark Brown wrote:
> This patch series adds support for the touchscreen controllers provided
> by Wolfson Microelectronics WM97xx series chips in both polled and
> streaming modes.
>
Thank you for the patches. Some comments below.
> +static int
Versions: `2.6.17-1.2142_FC4' (fedora core) for x86_64;
`kernel-syms-2.6.22.5-31' (opensuse 10.3) for i586.
File system may contain data not to let any logged in user read. Wish
to specify more restrictive mode of files in it - files of all types,
including not only regular ones, but also
Hello,
> > Do we need `offset' at all?
>
> Looks like no.
>
> I wonder if there's a good argument for adding a pte_offset_val() which
> would let us do:
>
> pteval = pte_offset_val(pmd, addr);
>
> and shrink the map/unmap window and overhead here and possibly
> elsewhere?
>
> Anyway, updated
On Fri, 18 Jan 2008 13:36:11 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> > Subject: x86: Add support for the latest Intel processors to
> > Oprofile From: Arjan van de Ven <[EMAIL PROTECTED]>
> >
> > The latest Intel processors (the 45nm
On Fri, Jan 18, 2008 at 11:45:52AM -0500, Peter Staubach wrote:
> Matthew Wilcox wrote:
>> On Fri, Jan 18, 2008 at 10:36:01AM -0500, Peter Staubach wrote:
>>> static int path_lookup_create(int dfd, const char *name,
>>> - unsigned int lookup_flags, struct nameidata *nd,
> i pointed it out how to port a larger series ontop of a whitespace
> cleanup patch:
>
> http://lkml.org/lkml/2008/1/18/281
>
> the "there's an easy technique" bit.
But it will be even easier to just redo the cleanup stuff at the
end. If I do what you describe here I'm sure I will make a
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 for system calls which take pathnames
as arguments.
The VFS already
>-Original Message-
>From: Andreas Herrmann3 [mailto:[EMAIL PROTECTED]
>Sent: Friday, January 18, 2008 8:11 AM
>To: Pallipadi, Venkatesh
>Cc: Ingo Molnar; Siddha, Suresh B; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL
On Fri, 2008-01-18 at 17:29 +0100, Michael Opdenacker wrote:
> On 01/18/2008 02:50 PM, Matt Mackall wrote:
> > On Fri, 2008-01-18 at 14:03 +0100, Michael Opdenacker wrote:
> >
> >> However, wouldn't the Makefile look nicer if we introduced a
> >> CONFIG_PCSPEAKER setting as in the mips
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/
> >
> > - selinux is busted on one of my two selinux-enabled test
Jochen Friedrich wrote:
+void watchdog_poke(void)
+{
+if (wdt) {
+out_be16(>swsrr, 0x556c);
+out_be16(>swsrr, 0xaa39);
+}
+}
This should be a function pointer, to allow for other watchdog types.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe
Hey Jiri,
Jiri Kosina:
> this is really weird, that the keys do not produce any debugging output at
> all. Do you think you could use usbmon to see what data is coming from
> they keyboard through USB bus?
For the "TV" key:
f7d32680 3699560314 C Ii:2:006:2 0:8 3 = 064600
f7d32680 3699560330 S
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > # Select 32 or 64 bit
> > config 64BIT
> > - bool "64-bit kernel" if ARCH = "x86"
> > + bool "64-bit kernel"
> > default ARCH = "x86_64"
> > help
> > Say yes to build a 64-bit kernel
On 01/18/2008 02:50 PM, Matt Mackall wrote:
> On Fri, 2008-01-18 at 14:03 +0100, Michael Opdenacker wrote:
>
>> However, wouldn't the Makefile look nicer if we introduced a
>> CONFIG_PCSPEAKER setting as in the mips platform? We would just have:
>>
>> obj-$(CONFIG_PCSPEAKER) +=
On Jan 18, 2008 5:19 PM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > First of all this patch solves the lock-ups, it works as advertised :)
>
> OK, good. I guess events are getting lost somewhere with vcpu_info
> placement.
> Would it be possible to map the eip and some top parts of the
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 for system calls which take pathnames
as arguments.
The VFS already handles ESTALE.
If a pathname resolution encounters an
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/
> >
> > - selinux is busted on one of my two selinux-enabled test
Versions: `2.6.17-1.2142_FC4' (fedora core) for x86_64;
`2.6.22.5-31' (opensuse 10.3) for i586.
File system may contain data not to let any logged in user read. Wish
to specify more restrictive mode of files in it - files of all types,
including not only regular ones, but also directories, even
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> That rule of thumb makes sense if someone does a series from scratch,
> but redoing a large existing series just because someone else sneaked
> in a white space patch at the wrong time does not seem to be very
> efficient to me.
i pointed it out how
Matthew Wilcox wrote:
On Fri, Jan 18, 2008 at 10:36:01AM -0500, Peter Staubach wrote:
@@ -1025,12 +1027,27 @@ static int fastcall link_path_walk(const
mntget(save.mnt);
result = __link_path_walk(name, nd);
- if (result == -ESTALE) {
+ while (result == -ESTALE) {
+
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 revE though.
It should be easy enough to enable it for AMD as well,
Giacomo A. Catenazzi wrote :
> [EMAIL PROTECTED] wrote:
> > Giacomo Catenazzi wrote:
> >
> >> const No writes through this lvalue. In the absence of this qualifier,
> >> writes may occur
> >> through this lvalue.
> >>
> >> volatile No cacheing through this lvalue: each operation in the abstract
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 for system calls which take pathnames
as arguments.
The VFS already handles ESTALE.
If a pathname resolution encounters an ESTALE at any
Hi Ingo,
with the commit
42c9c06bec2f48002d5b6573c8700461120070a9
x86: ACPI: use ioremap_early() instead of __va()/__pa()
you made __acpi_map_table(), which is non-__init, call early_ioremap()
which is __init on 64bit (init_64.c) but non-__init on 32bit
(ioremap_32.c). This
On Thu, 17 Jan 2008 [EMAIL PROTECTED] wrote:
> time kernel thread does not get scheduled.
>
> The thread that calls system("run_my_script") is configured as SCHED_OTHER.
>
> The Kernel is 2.6.21.
Could you try the latest kernel, and if that still gives you problems, try
out Ingo's sched-devel
On Thu, Jan 17, 2008 at 03:04:10PM -0800, Venki Pallipadi wrote:
>
> Below is another potential fix for the problem here. Going through ACPI
> ioremap usages, we found at one place the mapping is cached for possible
> optimization reason and not unmapped later. Patch below always unmaps
> ioremap
On Fri, 18 Jan 2008 11:20:02 +0100 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
On Friday 18 January 2008 17:21:18 Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > > (except for the white space changes, but that can be redone once
> > > > everything settled down again). Then it will be bisectable.
> > >
> > > it's a revert barrier (within v2.6.25),
>
On Fri, 18 Jan 2008, Jan Kiszka wrote:
> Steven Rostedt wrote:
>
> > @@ -978,7 +980,13 @@ void release_console_sem(void)
> > console_locked = 0;
> > up(_sem);
>
> Hmm, just looking at this fragment: Doesn't up() include the risk of
> running onto the runqueue lock as well?
Very
On Thu, 2008-01-17 at 20:42 -0800, Andrew Morton wrote:
> On Fri, 18 Jan 2008 12:19:56 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote:
>
> > Hello.
> >
> > Andrew Morton wrote:
> > > I'd be suspecting git-sched, so in lieu of a full bisection search it
> > > would
> > > be great if one of you
This patch series adds support for the touchscreen controllers provided
by Wolfson Microelectronics WM97xx series chips in both polled and
streaming modes.
These drivers have been maintained out of tree since 2003. During that
time the driver the primary maintainer was Liam Girdwood and a number
Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
Signed-off-by: Graeme Gregory <[EMAIL PROTECTED]>
Signed-off-by: Mike Arthur <[EMAIL PROTECTED]>
Signed-off-by: Mark Brown <[EMAIL PROTECTED]>
Cc: Stanley Cai <[EMAIL PROTECTED]>
Cc: Rodolfo Giometti <[EMAIL PROTECTED]>
Cc: Russell King <[EMAIL
Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
Signed-off-by: Graeme Gregory <[EMAIL PROTECTED]>
Signed-off-by: Mike Arthur <[EMAIL PROTECTED]>
Signed-off-by: Mark Brown <[EMAIL PROTECTED]>
Cc: Stanley Cai <[EMAIL PROTECTED]>
Cc: Rodolfo Giometti <[EMAIL PROTECTED]>
Cc: Russell King <[EMAIL
Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
Signed-off-by: Graeme Gregory <[EMAIL PROTECTED]>
Signed-off-by: Mike Arthur <[EMAIL PROTECTED]>
Signed-off-by: Mark Brown <[EMAIL PROTECTED]>
Cc: Stanley Cai <[EMAIL PROTECTED]>
Cc: Rodolfo Giometti <[EMAIL PROTECTED]>
Cc: Russell King <[EMAIL
Signed-off-by: Mark Brown <[EMAIL PROTECTED]>
Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
---
MAINTAINERS|9 ++
drivers/input/touchscreen/Kconfig | 52
Signed-off-by: Liam Girdwood <[EMAIL PROTECTED]>
Signed-off-by: Graeme Gregory <[EMAIL PROTECTED]>
Signed-off-by: Mike Arthur <[EMAIL PROTECTED]>
Signed-off-by: Mark Brown <[EMAIL PROTECTED]>
Cc: Stanley Cai <[EMAIL PROTECTED]>
Cc: Rodolfo Giometti <[EMAIL PROTECTED]>
Cc: Russell King <[EMAIL
This patch series adds support for the touchscreen controllers provided
by Wolfson Microelectronics WM97xx series chips in both polled and
streaming modes. It has been updated to reflect feedback since the
submission last week, most substantially in that the Makefile has been
cleaned up and the
* Ian Campbell <[EMAIL PROTECTED]> wrote:
> > Eric Biederman had a patchset that makes a PAE kernel use PAE page
> > tables from the start. That is really The Right Thing[TM].
>
> That's much saner than dup'ing up the early ioremap stuff to support
> both PAE and non-PAE at runtime, which is
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > (except for the white space changes, but that can be redone once
> > > everything settled down again). Then it will be bisectable.
> >
> > it's a revert barrier (within v2.6.25),
>
> What is a revert barrier?
>
> Anyways of course the way to
From: Masami Hiramatsu <[EMAIL PROTECTED]>
Fix the order of atomic operations to prevent overwriting prev_kprobe[0].
To pop values from stack, we must decrement stack index right AFTER
reading values.
Signed-off-by: Masami Hiramatsu <[EMAIL PROTECTED]>
---
Details of this issue was reported to
xming wrote:
OK, I misunderstood your original report to mean that something was
complaining about "too much" output. You're saying that lots of console
output seems to lock the domain.
Sorry about that, and yes that is the case.
I've had a report about heavy disk IO seems to lock
* Mel Gorman <[EMAIL PROTECTED]> wrote:
> While there are a limited number of x86 sub-architecture types that
> can really support NUMA, there is nothing stopping other machines
> booting that type of kernel. The fact that X86_GENERICARCH can set
> NUMA currently is an indicator of that. This
* Mel Gorman <[EMAIL PROTECTED]> wrote:
> There is nothing inherent in HIGHMEM64G required for CONFIG_NUMA to
> work. It just limits potential testing coverage so remove the
> limitation.
thanks Mel, applied. Great change - this will trigger NUMA related build
(and boot) failures must faster
Ingo Molnar wrote:
> * Dhaval Giani <[EMAIL PROTECTED]> wrote:
>
>> grepping around and looking through the code, I notice it is because
>> these variables just do not exist for 32 bit NUMA. I am not sure how
>> to go about it, and will just leave it to folks who know what they are
>> doing
On Fri, Jan 18, 2008 at 02:22:42PM +0100, Sam Ravnborg wrote:
>On Fri, Jan 18, 2008 at 08:51:44PM +0800, WANG Cong wrote:
>> On Fri, Jan 18, 2008 at 01:46:27PM +0100, Sam Ravnborg wrote:
>> >On Fri, Jan 18, 2008 at 08:29:17PM +0800, WANG Cong wrote:
>> >> On Fri, Jan 18, 2008 at 01:18:27PM +0100,
On Friday 18 January 2008 17:07:57 Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > could you please make your queue bisectable?
> >
> > The idea was that you git revert the original patches I referenced and
> > then drop the undo patches since I reimplement all that in
On Fri, Jan 18, 2008 at 10:36:01AM -0500, Peter Staubach wrote:
> @@ -1025,12 +1027,27 @@ static int fastcall link_path_walk(const
> mntget(save.mnt);
>
> result = __link_path_walk(name, nd);
> - if (result == -ESTALE) {
> + while (result == -ESTALE) {
> + /*
> +
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 it?
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > could you please make your queue bisectable?
>
> The idea was that you git revert the original patches I referenced and
> then drop the undo patches since I reimplement all that in different
> ways (except for the white space changes, but that can
Ingo Molnar wrote:
sidenote, is this failure normal:
acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed
?
Yes, I see it on all boots. When booting native, I get a "acpiphp: too
many resources found" message (I'll get the exact wording next time I
boot).
the leaked
On Friday 18 January 2008 17:01:04 Andi Kleen wrote:
>
> > could you please make your queue bisectable?
>
> The idea was that you git revert the original patches
Or rather instead of git reverting drop them completely. I'm sure it can
be done somehow. You should also move
CPA: Implement
On (18/01/08 00:19), Martin Knoblauch didst pronounce:
> > > The effect is defintely depending on the IO hardware.
> > > performed the same tests
> > > on a different box with an AACRAID controller and there things
> > > look different.
> >
> > I take it different also means it does not
> could you please make your queue bisectable?
The idea was that you git revert the original patches I referenced
and then drop the undo patches since I reimplement all that in different ways
(except for the white space changes, but that can be redone once everything
settled down again). Then
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm, i just found a failing 64-bit .config while testing your CPA
> patchset:
>
> [1.916541] CPA mapping 4k 0 large 2048 gb 0 x 0[0-0] miss 0
> [1.919874] Unable to handle kernel paging request at 0335aea8
> RIP:
> [1.919874]
Hugh Dickins wrote:
Shouldn't that be
return (pte_val(pte) & ~_PAGE_NX) >> PAGE_SHIFT;
Yes, it should be.
Thanks,
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 18 Jan 2008, Francis Moreau wrote:
> Maybe I missed it but I'm wondering why GIT is not used for
> the RT development ? I can't find a rt tree anywhere and all
> new rt release spoke about a patchset to apply on mainline
> kernels.
The answer to this is pretty much the same as why the
On Fri, 2008-01-18 at 09:54 -0500, H. Peter Anvin wrote:
> huang ying wrote:
> >
> > If CONFIG_X86_PAE is defined, the set_pte, clear_pte etc will operate
> > 3-level page tables, while on i386, the early page table is always
> > 2-level, so set_pte, clear_pte etc functions can not be used here.
On Fri, 18 Jan 2008 15:31:15 +0100
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> (Old) mxser is obsoleted by mxser_new and scheduled for removal on Dec 2007.
> Remove it by renaming mxser_new to mxser.
>
> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>(info->board->chip_flag)) {
All 7 parts
Andrea Righi wrote:
[snip]
> +static ssize_t iothrottle_read(struct cgroup *cont, struct cftype *cft,
> +struct file *file, char __user *buf,
> +size_t nbytes, loff_t *ppos)
> +{
> + ssize_t count, ret;
> + unsigned long delta,
On Fri, Jan 18, 2008 at 10:35:50AM -0500, Peter Staubach wrote:
> Hi.
>
> Here is a patch set which modifies the system to enhance the
> ESTALE error handling for system calls which take pathnames
> as arguments.
I think your cover letter may be bigger than any of the actual
patches I'm not
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.
Ingo
-->
Arjan van de Ven (1):
x86: add support for the
Sam Ravnborg wrote:
> Hi Mike.
>
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -20,6 +20,7 @@ config X86
>> def_bool y
>> select HAVE_OPROFILE
>> select HAVE_KPROBES
>> +select HAVE_SETUP_PER_CPU_AREA if ARCH = "x86_64"
>
> It is simpler to just say:
>> +select
David Schwartz wrote:
2) The 'kfree' operation changes the logical state of the object pointed to,
as the object goes from existent to non-existent.
I don't think that kfree() itself changes the state of the object. It
doesn't call a destructor or anything like that, so the object itself
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm, i just found a failing 64-bit .config while testing your CPA
> patchset:
>
> [1.916541] CPA mapping 4k 0 large 2048 gb 0 x 0[0-0] miss 0
> [1.919874] Unable to handle kernel paging request at 0335aea8
> RIP:
> [1.919874]
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 disk drive write a
Hi.
The patch enhanced the ESTALE error handling for NFS mounted
file systems. It expands the number of places that the NFS
client checks for ESTALE returns from the server.
It also enhances the ESTALE handling for directories by
occasionally retrying revalidation to check to see whether the
Hi.
This is a patch to enhance ESTALE error handling during the
lookup process. The error, ESTALE, can occur when out of data
dentries, stored in the dcache, is used to translate a pathname
component to a dentry. When this occurs, the dentry which
contains the pointer to the inode which refers
Hi.
This patch adds handling for the error, ESTALE, to the system
calls which take pathnames as arguments. The algorithm used
is to detect that an ESTALE error has occurred during an
operation subsequent to the lookup process and then to unwind
appropriately and then to perform the lookup
While there are a limited number of x86 sub-architecture types that can
really support NUMA, there is nothing stopping other machines booting that
type of kernel. The fact that X86_GENERICARCH can set NUMA currently is an
indicator of that. This restriction only limits potential testing coverage.
Hi.
Here is a patch set which modifies the system to enhance the
ESTALE error handling for system calls which take pathnames
as arguments.
The error, ESTALE, was originally introduced to handle the
situation where a file handle, which NFS uses to uniquely
identify a file on the server, no
301 - 400 of 1161 matches
Mail list logo
