2008/1/18, Miklos Szeredi <[EMAIL PROTECTED]>:
> > unsigned long end;
> > - struct mm_struct *mm = current->mm;
> > + int error, unmapped_error;
> > struct vm_area_struct *vma;
> > - int unmapped_error = 0;
> > - int error = -EINVAL;
> > + struct mm_struct *mm;
> >
>
On Fri, 2008-01-18 at 12:17 +0100, Miklos Szeredi wrote:
> > diff --git a/mm/msync.c b/mm/msync.c
> > index 144a757..a1b3fc6 100644
> > --- a/mm/msync.c
> > +++ b/mm/msync.c
> > @@ -14,6 +14,122 @@
> > #include
> > #include
> >
> > +unsigned long masync_pte_range(struct vm_area_struct *vma,
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-01-18 at 11:44 +0100, Ingo Molnar 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
Jakob Oestergaard wrote:
On Thu, Jan 17, 2008 at 01:25:39PM -0800, Linus Torvalds wrote:
...
Why do you make that mistake, when it is PROVABLY NOT TRUE!
Try this trivial program:
int main(int argc, char **argv)
{
int i;
const int *c;
On Fri, Jan 18, 2008 at 02:50:48AM -0800, Harvey Harrison wrote:
>
> On Fri, 2008-01-18 at 11:44 +0100, Ingo Molnar wrote:
> > * Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > # Select 32 or 64 bit
> > > config 64BIT
> > > - bool "64-bit kernel" if ARCH = "x86"
> > > + bool "64-bit kernel"
>
On Thu, Jan 17, 2008 at 11:19:23AM -0800, Andrew Morton wrote:
> On Thu, 17 Jan 2008 16:23:51 - Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > This version brings a large number of fixes which have built up over
> > the Christmas period. Mostly these are fixes for false positives, both
> > t
On Fri, 18 Jan 2008, Jiri Kosina wrote:
>
> If this patch is going to be merged, you should perhaps adjust the comment
> introduced by the above mentioned commit, so that it reflects the new
> behavior.
Thanks for pointing this out. Updated patch below:
-- Steve
=
I thought that one cou
On Fri, Jan 18, 2008 at 11:45:12AM +0100, Kay Sievers wrote:
> On Fri, 2008-01-18 at 08:38 +0100, Jarek Poplawski wrote:
> > On Fri, Jan 18, 2008 at 01:31:17PM +0800, Dave Young wrote:
> > > On Jan 18, 2008 11:18 AM, Kay Sievers <[EMAIL PROTECTED]> wrote:
> > ...
> > > > Yeah, might be better to wa
Hello All
The TDM driver just now does not have a proper framework. Probably the
interface cannot be generalised as such. Hence we could not decide
whether it would be right to think of a TDM framework. Infact the
interface this TDM driver(for MPC8323ERDB) supplies may not be usable
for some other
> diff --git a/mm/msync.c b/mm/msync.c
> index 144a757..a1b3fc6 100644
> --- a/mm/msync.c
> +++ b/mm/msync.c
> @@ -14,6 +14,122 @@
> #include
> #include
>
> +unsigned long masync_pte_range(struct vm_area_struct *vma, pmd_t *pdm,
> + unsigned long addr, unsigned long end)
> +{
> +
On Thu, 17 Jan 2008, Steven Rostedt wrote:
> Thinking that it was locking up on my code I went looking down the wrong
> path. I finally found (after examining an NMI dump) that the lockup
> happened because printk was trying to wakeup the klogd daemon, which
> caused a deadlock when the try_to_
* Michael Opdenacker <[EMAIL PROTECTED]> wrote:
> obj-$(CONFIG_PARAVIRT) += paravirt_32.o
> -obj-y+= pcspeaker.o
> -
> obj-$(CONFIG_SCx200) += scx200_32.o
>
> +ifdef CONFIG_INPUT_PCSPKR
> + obj-y += pcspeaker.o
> +end
(This should be merged with fix-occasional-deadlock-in-raid5.patch)
As we don't call stripe_handle in make_request any more, we need to
clear STRIPE_DELAYED to (previously done by stripe_handle) to ensure
that we test if the stripe still needs to be delayed or not.
Signed-off-by: Neil Brown <[EM
Finish ITERATE_ to for_each conversion.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/md.c |8
./include/linux/raid/md_k.h | 14 --
2 files changed, 8 insertions(+), 14 deletions(-)
diff .prev/drivers/md/md.c ./drivers/md/md
Following are 4 patches for md.
The first two replace
md-allow-devices-to-be-shared-between-md-arrays.patch
which was recently remove. They should go at the same place in the
series, between
md-allow-a-maximum-extent-to-be-set-for-resyncing.patch
and
md-lock-address-when-changing-attr
* 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 - formerly known as x86_64
thx, i've added this to x
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
> NIP: 4570 LR: 0fc42dc0 CTR:
> REGS: c0077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
> MSR: 80001000 CR: 28022422 XER:
> DAR: c0077b6bfce0, DSISR: 0
On Jan 18, 2008 6:23 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Jan 2008 10:19:33 +0100,
> Cornelia Huck <[EMAIL PROTECTED]> wrote:
>
> > >
> > > 1314 if (IS_ERR(new_parent_kobj)) {
> > > 1315 error = PTR_ERR(new_parent_kobj);
> > > 1316 put_de
* Michael Ellerman <[EMAIL PROTECTED]> [2008-01-18 16:55:03]:
> On Sat, 2007-12-08 at 04:07 +0530, Balbir Singh wrote:
> > Here's a dumb simple implementation of fake NUMA nodes for PowerPC. Fake
> > NUMA nodes can be specified using the following command line option
> >
>
> >
> > Comments are
On Fri, 2008-01-18 at 11:38 +0100, Miklos Szeredi wrote:
> > On Fri, 2008-01-18 at 10:51 +0100, Miklos Szeredi wrote:
> >
> > > > diff --git a/mm/msync.c b/mm/msync.c
> > > > index a4de868..a49af28 100644
> > > > --- a/mm/msync.c
> > > > +++ b/mm/msync.c
> > > > @@ -13,11 +13,33 @@
> > > > #incl
On Fri, 18 Jan 2008 10:19:33 +0100,
Cornelia Huck <[EMAIL PROTECTED]> wrote:
> >
> > 1314 if (IS_ERR(new_parent_kobj)) {
> > 1315 error = PTR_ERR(new_parent_kobj);
> > 1316 put_device(new_parent);
> > 1317 goto out;
> > 1318 }
> > 13
Kamalesh Babulal writes:
> I tried reproducing the problem and was successful with following trace
> in which the pc is at 0x4570 as the above one
What did you do to trigger it?
> c0004544 :
> c0004544: 71 8a 40 00 andi. r10,r12,16384
> c0004548: 7c 2a 0
On Thu, Jan 17, 2008 at 10:43:15PM -0800, Michael Rubin wrote:
> On Jan 17, 2008 8:56 PM, Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > On Thu, Jan 17, 2008 at 01:07:05PM -0800, Michael Rubin wrote:
> > Suppose we want to grant longer expiration window for temp files,
> > adding a new list named s_di
On Fri, 2008-01-18 at 10:51 +0100, Miklos Szeredi wrote:
> > diff --git a/mm/msync.c b/mm/msync.c
> > index a4de868..a49af28 100644
> > --- a/mm/msync.c
> > +++ b/mm/msync.c
> > @@ -13,11 +13,33 @@
> > #include
> >
> > /*
> > + * Scan the PTEs for pages belonging to the VMA and mark them rea
On Thu, Jan 17, 2008 at 01:25:39PM -0800, Linus Torvalds wrote:
...
> Why do you make that mistake, when it is PROVABLY NOT TRUE!
>
> Try this trivial program:
>
> int main(int argc, char **argv)
> {
> int i;
> const int *c;
>
> i = 5;
* 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 it over to Greg - but Greg has not indicated it yet
> whether he has picked it up. Andre
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> Ingo,
> it seems you removed
> > patch
> > x86: validate against ACPI motherboard resources
> last night.
>
> was it dropped?
yeah, i bounced it over to Greg - but Greg has not indicated it yet
whether he has picked it up. Andrew has it in -rc8-mm
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Changes to previous versions:
> - Ported to the latest git-x86 including the PAT patchkit
> This undoes some changes in the PAT patches and reimplements them
> in a different way. End result should be equivalent, but this
> made it easier for me to merge
> Updating file times at write references to memory-mapped files and
> forcing file times update at the next write reference after
> calling the msync() system call with the MS_ASYNC flag.
>
> Signed-off-by: Anton Salikhmetov <[EMAIL PROTECTED]>
> ---
> mm/memory.c |6 ++
> mm/msync.c |
Kamalesh Babulal writes:
> >>> NIP: 4570 LR: 0fc42dc0 CTR:
> >>> REGS: c0077b6bf8c0 TRAP: 0300 Not tainted (2.6.24-rc8-mm1-autotest)
> >>> MSR: 80001000 CR: 28022422 XER:
> >>> DAR: c0077b6bfce0, DSISR: 0a00
Actually,
Hi!
> > 1. I doubt ZONE_DMA, please shipment ignore zone_dma patch(below).
>
> Your patch above solves the problem I had with early notification.
really!?
I am really happy!!
Thanks you.
- kosaki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
* Andrew Morton <[EMAIL PROTECTED]> [2008-01-17 10:40:21]:
> On Thu, 17 Jan 2008 18:16:22 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> > * Andrew Morton <[EMAIL PROTECTED]> [2008-01-17 02:35:14]:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.2
* Randy Dunlap <[EMAIL PROTECTED]> [2008-01-15 16:05:06]:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix gcc warnings in getdelays.c:
Hi, Randy,
Thanks for finding these problems and fixing them. The fixes look
quite straight forward.
Acked-by: Balbir Singh <[EMAIL PROTECTED]>
--
W
> On Fri, 2008-01-18 at 10:51 +0100, Miklos Szeredi wrote:
>
> > > diff --git a/mm/msync.c b/mm/msync.c
> > > index a4de868..a49af28 100644
> > > --- a/mm/msync.c
> > > +++ b/mm/msync.c
> > > @@ -13,11 +13,33 @@
> > > #include
> > >
> > > /*
> > > + * Scan the PTEs for pages belonging to the
2008/1/18, Peter Zijlstra <[EMAIL PROTECTED]>:
>
> On Fri, 2008-01-18 at 11:15 +0100, Peter Zijlstra wrote:
> > On Fri, 2008-01-18 at 10:51 +0100, Miklos Szeredi wrote:
> >
> > > > diff --git a/mm/msync.c b/mm/msync.c
> > > > index a4de868..a49af28 100644
> > > > --- a/mm/msync.c
> > > > +++ b/mm/m
If you try to start an array for which the number of raid disks is
listed as zero, md will currently try to read metadata off any devices
that have been given. This was done because the value of raid_disks
is used to signal whether array details have been provided by
userspace (raid_disks > 0) or
Currently, a given device is "claimed" by a particular array so
that it cannot be used by other arrays.
This is not ideal for DDF and other metadata schemes which have
their own partitioning concept.
So for externally managed metadata, just claim the device for
md in general, require that "offse
* Colin Fowler <[EMAIL PROTECTED]> wrote:
> > there are a handful of 'scheduler feature bits' in
> > /proc/sys/kernel/sched_features:
> >
> > enum {
> > SCHED_FEAT_NEW_FAIR_SLEEPERS= 1,
> > SCHED_FEAT_WAKEUP_PREEMPT = 2,
> > SCHED_FEAT_START_DEBIT = 4,
>
Hi,
we currently think this is due to a race condition in the packet queue
code. Ivo is currently reworking the packet queues, which I hope will
resolve this situation.
Mattias
On Thu, 2008-01-17 at 22:57 +0100, Alejandro Riveira Fernández wrote:
> Running
>
> Linux Varda 2.6.24-rc8 #1 SMP PREE
Hi Andrew,
> > > on X86, ZONE_DMA is very very small.
> > > It is often no used at all.
> >
> > In that case page-reclaim is supposed to set all_unreclaimable and
> > basically ignores the zone altogether until it looks like something might
> > have changed.
> >
> > Is that code not working? (
El Fri, 18 Jan 2008 11:56:05 +0100
Mattias Nissler <[EMAIL PROTECTED]> escribió:
> Hi,
>
> we currently think this is due to a race condition in the packet queue
> code. Ivo is currently reworking the packet queues, which I hope will
> resolve this situation.
Thanks for the quick answer.
>
>
On Fri, 18 Jan 2008 18:34:55 +0800,
"Dave Young" <[EMAIL PROTECTED]> wrote:
> On Jan 18, 2008 6:23 PM, Cornelia Huck <[EMAIL PROTECTED]> wrote:
> > On Fri, 18 Jan 2008 10:19:33 +0100,
> > Cornelia Huck <[EMAIL PROTECTED]> wrote:
> >
> > > >
> > > > 1314 if (IS_ERR(new_parent_kobj)) {
> > >
On Thu, Jan 17, 2008 at 08:39:23PM -0600, Matt Mackall wrote:
>
> On Thu, 2008-01-17 at 18:28 -0800, Andrew Morton wrote:
> > On Fri, 18 Jan 2008 02:02:17 + Byron Bradley <[EMAIL PROTECTED]> wrote:
> >
> > > In arch/arm/kernel/setup.c:setup_ramdisk(), rd_size is set from the
> > > boot tags.
> Possibly, I didn't see a quick way to break that iteration.
> >From a quick glance at prio_tree.c the iterator isn't valid anymore
> after releasing i_mmap_lock. Fixing that would be,.. 'fun'.
Maybe i_mmap_lock isn't needed at all, since msync holds mmap_sem,
which protects the prio tree as well
Allow to limit the block I/O bandwidth for specific process containers
(cgroups) imposing additional delays on I/O requests for those processes
that exceed the limits defined in the control group filesystem.
Example:
# mkdir /dev/cgroup
# mount -t cgroup -oio-throttle io-throttle /dev/cgroup
On Thu, 17 Jan 2008, Willy Tarreau wrote:
> Well, since there are commands that work on this (push and log at
> least), I believe that some operations could succeed. I *know* that
> remote cloning was impossible, and it *looked* like pulling too was
> during my attempts to fix the problem before un
On 01/18/2008 12:02 PM, Ingo Molnar wrote:
>
> why didnt you make this:
>
> obj-$(CONFIG_INPUT_PCSPKR) += pcspeaker.o
>
> ?
>
Many thanks for your feedback.
That's what I did first, but if CONFIG_INPUT_PCSPKR=m,
arch/x86/kernel/pcspeaker.c gets compiled as a module. While compiling
From: Robert Olsson <[EMAIL PROTECTED]>
Date: Wed, 16 Jan 2008 18:07:38 +0100
>
> eth0 e1000_irq_enable sem = 1<- High netload
> eth0 e1000_irq_enable sem = 1
> eth0 e1000_irq_enable sem = 1
> eth0 e1000_irq_enable sem = 1
> eth0 e1000_irq_enable sem = 1
> eth0 e1000_irq_enable sem = 1
> eth0
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Also, the mem -> node hash lookup is fixed.
> >
> > Based on 2.6.24-rc6-mm1 + change-NR_CPUS-V3 patchset
>
> hm, I've been hiding from those patches.
>
> Are they ready?
i'm carrying them in x86.git, and they are pretty robust, with one
outstand
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> > ok. So it seems we dont even need all that many special cases, a
> > "dont write MTRRs" and "use PATs everywhere" rule would just do the
> > right thing all across?
>
> Yes. The main thing required is on the lines of Jesse's patch. If the
> MT
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > Style question, would the following be preferred?
> >
> > config 64BIT
> > def_bool ARCH = "x86_64"
> > prompt "64-bit kernel"
> > help...
>
> No.
> It is most common to let the prompt follow the type and not
> as a separate property.
h
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> [PATCH] x86_64: only call early_init_amd one time
>
> Andi's patch
> "
> x86: move X86_FEATURE_CONSTANT_TSC into early cpu feature detection
>
> Need this in the next patch in time_init and that happens early.
>
> This includes a minor fix
On Fri, Jan 18, 2008 at 01:02:48PM +0100, Ingo Molnar wrote:
>
> * Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > > Style question, would the following be preferred?
> > >
> > > config 64BIT
> > > def_bool ARCH = "x86_64"
> > > prompt "64-bit kernel"
> > > help...
> >
> > No.
> > It is mos
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > (it doesnt matter if graphics does not resume fine - at least for my
> > tests)
> >
> > kprobes had similar problems and it now has a few simple smoke-tests
> > - which i just saw trigger on a patch that i did not notice would
> > break kprobes.
On Fri, 2008-01-18 at 17:28 +0530, Aggrwal Poonam wrote:
> Hello All
>
> The TDM driver just now does not have a proper framework. Probably the
> interface cannot be generalised as such. Hence we could not decide
> whether it would be right to think of a TDM framework. Infact the
> interface this
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> > I can propose a corresponding patch, and I'd suggest to make
> > CONFIG_PCSPEAKER depend on CONFIG_EMBEDDED.
>
> No, don't. It's fine the way it is. If INPUT_PCSPKR isn't set, we
> don't support the speaker, end of story.
yeah.
> Also, bear in mi
On Thu, 2008-01-17 at 21:08 -0800, Andrew Morton wrote:
> On Thu, 17 Jan 2008 19:29:18 -0600 Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> >
> > On Thu, 2008-01-17 at 15:10 -0600, Matt Mackall wrote:
> > > On Thu, 2008-01-17 at 02:35 -0800, Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/lin
Giacomo Catenazzi wrote:
And to demostrate that Linus is not the only person
with this view, I copy some paragraphs from C99 rationale
(you can find standard, rationale and other documents
in http://clc-wiki.net/wiki/C_standardisation:ISO )
Page 75 of C99 rationale:
Type qualifiers were introdu
On Tue, 15 Jan 2008, Jeremy Fitzhardinge wrote:
> In 32-bit PAE, mask NX from pte_pfn, since it isn't part of the PFN.
> This code is due for unification anyway, but this fixes a latent bug.
>
> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>
> ---
> include/asm-x86/pgtable-3level.h |
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) += pcspeaker.o
Yes, that would be cleaner. Not worth it fo
Hello,
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.
Another question, is there a TODO list somewhere which would
help to port the RT patch to a new archi
Rene,
Here is why you shouldn't leap so quickly to rudeness. Everything is
being repeated over and over and over again (as you put it) because
people like you shout down people like me without making any apparent
effort to understand the truth of the problem.
Rene Herman wrote:
> We've already
Mark Hansen wrote:
Hello,
Firstly, may I apologise as I am not a member of the LKML, and ask that
I be CC'd in any responses that may be forthcoming.
My question concerns the following patch which was incorporated into the
2.6.22 kernel (quoted from that change log):
Today, all threads wai
On 2.6.24-rc8-mm1:
uml:~# grep arch_dup_mmap /proc/slab_allocators
size-32: 10861 arch_dup_mmap+0x9f/0x130
Miklos
--
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
At Fri, 18 Jan 2008 15:10:08 +0100,
Rafael J. Wysocki wrote:
>
> On Friday, 18 of January 2008, Linus Torvalds wrote:
> >
> > On Thu, 17 Jan 2008, Andrew Morton wrote:
> > >
> > > > Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always
> > > > work on Lenovo X60s
> > > > Submi
From: David Brownell <[EMAIL PROTECTED]>
On the sam9 EK boards, the LCD backlight is hooked up to a PWM output
from the LCD controller. It's controlled by "contrast" registers though.
This patch lets boards declare that they have that kind of backlight
control. The driver can then export this
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. The
boot_ioremap use a trick to deal with this problem. The CONFIG_X86_PAE
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
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 c
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
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 http://vger.kernel
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.
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, iorat
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 point,
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
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, and
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) {
+
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 r
* 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 t
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
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 machin
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 resu
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 (fr
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 a
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 PROTE
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 PROTE
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
drivers/input/touchscreen/Makefi
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 px
* 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
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 up
* 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
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 show
* 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] []
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 proces
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 longer
There is nothing inherent in HIGHMEM64G required for CONFIG_NUMA to work. It
just limits potential testing coverage so remove the limitation.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -rup -X /usr/src/patchs
On Fri, 18 Jan 2008, 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 actual
On Fri, 2008-01-18 at 22:54 +0800, huang ying wrote:
> On Jan 18, 2008 4:48 PM, Ian Campbell <[EMAIL PROTECTED]> wrote:
> > On Tue, 2008-01-15 at 13:45 +0800, Huang, Ying wrote:
> > > +void __init bt_ioremap_init(void)
> > > +{
> > > [...]
> > > + *pgd = __pa(bm_pte) | _PAGE_TABLE;
> > > +}
>
I'm porting kernel 2.6.22.6 on custom embedded system (ARM1136).
During network subsystem initialization, kernel hangs in function
synchronize_rcu invoked by synchronize_net. In particular
wait_for_completion(&rcu.completion);
never returns and wakeme_after_rcu is never hit.
Anybody can give me
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 disk energy to write out the cache, the
claim was then made that the drive at least surviv
1 - 100 of 606 matches
Mail list logo
