David Woodhouse writes:
> A GUI PPP dialer should be
> listing the available serial ports in the system whatever their names
> are.
How do you propose they do that? Neither kppp nor gnome-ppp seem to
be able to do that currently. Gnome-ppp offers just /dev/modem and
/dev/ttyS[0123]. Kppp offer
Eric Dumazet wrote:
> You were CC on this one, you can find an archive here :
You cc:ed my gmail account. I don't pick out mails sent to me there.
If you want me to look at something you have to send it to my
@redhat.com address.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain Vi
On Wed, 2007-04-04 at 14:28 +0800, Wu, Bryan wrote:
> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
> ---
> include/asm-blackfin/socket.h | 55
>
> include/asm-blackfin/sockios.h | 13 +
> 2 files changed, 68 insertions(+), 0 deletions(-)
> cre
Ulrich Drepper a écrit :
Nick Piggin wrote:
Sad. Although Ulrich did seem interested at one point I think? Ulrich,
do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
You were CC on this one, you can find an archive here :
http://lkml.
On Tue, Apr 03, 2007 at 07:04:58PM -0700, Paul Jackson wrote:
> Andrew wrote:
> > I'd have thought that in general an application should be querying its
> > present affinity mask - something like sched_getaffinity()? That fixes the
> > CPU hotplug issues too, of course.
>
> The sched_getaffinity
Ulrich Drepper wrote:
Nick Piggin wrote:
Sad. Although Ulrich did seem interested at one point I think? Ulrich,
do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
Private futexes.
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this
Nick Piggin wrote:
> Sad. Although Ulrich did seem interested at one point I think? Ulrich,
> do you agree at least with the interface that Eric is proposing?
I have no idea what you're talking about.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Desc
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/libata-core.c | 33 -
drivers/ata/libata-eh.c | 22 +++---
drivers/a
On Tue, 2007-04-03 at 20:22 -0700, Randy Dunlap wrote:
> > +/**
> > + * val_outside - is a value and length past a limit?
> > + * @val: the start value
> > + * @len: the length from the start
> > + * @limit: the first invalid value
> > + *
> > + * Like val + len > limit, except with overflow checki
On Tue, Apr 03, 2007 at 03:55:32PM +0200, Bernhard Kaindl wrote:
> PS: I attached a program which uses msr.ko (CONFIG_X86_MSR) from
> Processor type and features
> -> [M/*] /dev/cpu/*/msr - Model-specific register support
> to dump the contents of the fixed-range MTTRs to stdout.
>
>
(sorry to change the subjet, I was initially going to send the
threaded vma cache patches on list, but then decided they didn't
have enough changelog!)
Andrew Morton wrote:
On Wed, 04 Apr 2007 16:09:40 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew, do you have any objections to putting
On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote:
[...]
> Well, it works for me on 32-bit as well, right up to 100% full.
> No problems at all...
Maybe it depends on the kernel. I patched 2.6.20 with the patches
above and got the described behaviour.
Regards,
Tino
-
To unsubscribe fro
On Wed, 4 Apr 2007, Antoine Martin wrote:
> and this one:
> http://www.suse.de/~kraxel/uml/patches/2.6.18-rc4/uml-x11-fb
> which applied cleanly, but is not letting me set the option - Kconfig is
> beyond me:
>
> arch/um/Kconfig:144:warning: 'select' used by config symbol 'X11_FB' refer to
> undef
On 4/4/07, Rene Herman <[EMAIL PROTECTED]> wrote:
Taking forever to reproduce in as far as getting the oops. The thing is
now just locking hard each time. Will keep on trying...
Can you get anything out with sysrq-t? The original oops would be
enough to conclude it's a double-free if it weren't
David Woodhouse writes:
> > It 'should' be the case because that is what is easiest for users and
> > makes most sense from a user's point of view.
>
> I really don't buy that argument. People cope perfectly well
> with /dev/ttySA0 on StrongARM, with /dev/ttySC0 on SH, etc. If it isn't
Those are
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
include/asm-blackfin/pgtable.h | 44 +++
1 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/include/asm-blackfin/pgtable.h b/include/asm-blackfin/pgtable.h
index 9328537..5a8f9e4 100644
--- a/includ
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/lib/memchr.S | 31 +---
arch/blackfin/lib/memcmp.S | 46 ++
arch/blackfin/lib/memcpy.S | 24 +++---
arch/blackfin/lib/memmove.S | 12 ++
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
include/asm-blackfin/uaccess.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/asm-blackfin/uaccess.h b/include/asm-blackfin/uaccess.h
index ed931bb..bfcb679 100644
--- a/include/asm-blackfin/uaccess.h
+++ b/inclu
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
include/asm-blackfin/socket.h | 55
include/asm-blackfin/sockios.h | 13 +
2 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 include/asm-blackfin/socket.h
create mode 100644
USB gadget rndis: skb_push function may return a pointer which is not
aligned as required by struct rndis_packet_msg_type.
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
drivers/usb/gadget/rndis.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
mm/nommu.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 2d0a82f..0016557 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -261,6 +261,14 @@ void vunmap(void *addr)
}
/*
+ * Implement a
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/kernel/setup.c b/arch/blackfin/kernel/setup.c
index ce51882..9870c60 100644
--- a/arch/blackfin/kernel/setup.c
+++ b/arch/blackfin/k
On Wed, 04 Apr 2007 16:09:40 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew, do you have any objections to putting Eric's fairly
> important patch at least into -mm?
you know what to do ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH] Just include linux/kallsyms.h all the time as the header will
handle prototypes/defines when CONFIG_KALLSYMS is disabled ... fixes
build error when disabled due to print_ip_sym not being macroed away
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
arch/blackfin/kernel/traps.c |5 ++---
On Tue, 3 Apr 2007, Matt Mackall wrote:
> Make /proc/pid/clear_refs option under CONFIG_EMBEDDED
>
> This interface is primarily useful for doing memory profiling and not
> much use on deployed embedded boxes. Make it optional. Together with
> /proc/pid/smaps, this save a few K.
>
> Signed-off-b
On Tue, Apr 03 2007, Pekka J Enberg wrote:
> > mcdx:: close()
>
> However, we never hit do_mcdx_request(). Jens, do we need to do
> set_capacity() somewhere? I don't see other cdrom drivers doing it but
> they could be broken too...
Yeah, that would be appropriate.
--
Jens Axboe
-
To unsubsc
Robert Hancock wrote:
This adds some NCQ blacklist entries taken from the Silicon Image 3124/3132
Windows driver .inf files. There are some confirming reports of problems
with these drives under Linux (for example
http://lkml.org/lkml/2007/3/4/178)
so let's disable NCQ on these drives.
Signed-
Eric Dumazet wrote:
Nick Piggin a écrit :
Eric Dumazet wrote:
I do think such workloads might benefit from a vma_cache not shared
by all threads but private to each thread. A sequence could
invalidate the cache(s).
ie instead of a mm->mmap_cache, having a mm->sequence, and each
thread h
Mark Lord wrote:
Ideally, this would go into linux-2.6.21.
Preserve the LBA bit in the DevSel/Head register for HDIO_DRIVE_TASK.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- linux/drivers/ata/libata-scsi.c.orig2007-03-21
13:35:02.0 -0400
+++ linux/drivers/ata/libata-scsi.
On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > Why? What's so special about the name 'ttyS'?
>
> It's the name that users of Linux expect built-in serial ports to have.
Not really. The norm under Linux is for non-8250 ports to use
properly-registered dev
David Woodhouse writes:
> Why? What's so special about the name 'ttyS'?
It's the name that users of Linux expect built-in serial ports to have.
> > The built-in ports can generally be enumerated early on boot in a
> > stable order, and they should be assigned the low ttySn numbers,
> > regardles
Matt Mackall wrote:
On Wed, Apr 04, 2007 at 01:51:37PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
I think it would be better in mm/.
I originally was looking at putting it in mm
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Wed, 04 Apr 2007 01:19:59 -0400
> I don't see why that 'should' be the case. Certainly it _isn't_ the case
> on most supported platforms -- we have separate device numbers, and
> names, for most types of ports. There's only one or two drivers which
>
Alan Cox wrote:
Nothing terribly exciting here just odd glitches from the merge
ACK, will apply if I can sort out the confusion between -mm and local
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
H. Peter Anvin a écrit :
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor modifie
On Wed, 4 Apr 2007 00:33:36 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> This is an old bug. It has been happening forever, but I'd love to
> know how I can help get this tracked down and fixed.
Yes, I've been hitting something like that in the past 3-4 weeks. We
started to diagnose it but I
On Tue, 2007-04-03 at 17:37 +0200, Martin Mares wrote:
> Hello!
>
> > Does whatever defines what these escapes mean, have any comment to make
> > about UTF-8? If not, why can't we declare that UTF-8 mode is the "reset"
> > mode, the default that would be dropped to on a full reset, and if
> > anyo
Nick Piggin a écrit :
Eric Dumazet wrote:
I do think such workloads might benefit from a vma_cache not shared by
all threads but private to each thread. A sequence could invalidate
the cache(s).
ie instead of a mm->mmap_cache, having a mm->sequence, and each thread
having a current->mmap_c
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor modifies data within 2k of anothe
On Tue, 2007-04-03 at 17:35 +0100, Paul LeoNerd Evans wrote:
> On Tue, Apr 03, 2007 at 04:20:52PM +, Pavel Machek wrote:
> > HPA is right... this should be fixed in userland. Reset should reset a
> > console, and if you want utf-8, do \ec\ewhatever to get it.
>
> As I've already said elsewhere
This is an old bug. It has been happening forever, but I'd love to
know how I can help get this tracked down and fixed.
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV
Pro
H. Peter Anvin a écrit :
Eric Dumazet wrote:
There is one thing that always worried me.
Intel & AMD manuals make clear that mixing data and program in the
same page is bad for performance.
In particular, x86_64 vsyscall put jiffies and other
vsyscall_gtod_data_t right in the midle of code.
On Wed, Apr 04, 2007 at 01:51:37PM +1000, Nick Piggin wrote:
> Matt Mackall wrote:
> >Move the page walker code to lib/
> >
> >This lets it get shared outside of proc/ and linked in only when
> >needed.
>
> I think it would be better in mm/.
I originally was looking at putting it in mm/memory.c a
H. Peter Anvin wrote:
> Mutable data should be separated from code. I think any current CPU
> will do fine as long as they are in separate 128-byte chunks, but they
> need at least that much separation.
P4 manual says that if one processor modifies data within 2k of another
processor executing cod
On Wed, 2007-04-04 at 14:20 +1000, Paul Mackerras wrote:
> I never suggested *all* serial ports should be /dev/ttySn, I said that
> the built-in ports on the motherboard should be /dev/ttySn.
Why? What's so special about the name 'ttyS'?
> The built-in ports can generally be enumerated early on
Eric Dumazet wrote:
There is one thing that always worried me.
Intel & AMD manuals make clear that mixing data and program in the same
page is bad for performance.
In particular, x86_64 vsyscall put jiffies and other
vsyscall_gtod_data_t right in the midle of code. That is certainly not
wi
H. Peter Anvin a écrit :
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Sounds like it would need a device which can be waited upon for changes.
A vdso-like shared page could have a futex in it.
Yes, but a futex couldn't be waited upon with a bunch of other things as
part of a poll or a
On Tue, Apr 03, 2007 at 09:04:59PM -0700, Paul Menage wrote:
> Have you posted the cpuset implementation over your system yet?
Yep, here:
http://lists.linux-foundation.org/pipermail/containers/2007-March/001497.html
For some reason, the above mail didnt make it into lkml (maybe it
exceeded the m
Jan Engelhardt a écrit :
On Apr 2 2007 12:41, Eric Dumazet wrote:
The following patch does the right thing for pipes, I let you doing
the same for sockets...
Is struct sock->sk_receive_queue->qlen actually the thing I am
looking for? (Previously, I had struct sock->sk_rcvbuf, which was
obvious
On Sun, Apr 01, 2007 at 01:06:46PM +0530, Milind Arun Choudhary wrote:
> ROUND_UP macro cleanup, use ALIGN where ever appropriate
>
> Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]>
Also looks good to me. Just one white space nit we can fixup by hand.
Signed-off-by: Grant Grundler <[EMA
Don't know if this got reported yet. It's slightly stale
(against 2.6.21-rc4-git6), but I don't recall seeing
anything in the changelogs recently that would make this
irrelevant.
Dave
--
http://www.codemonkey.org.uk
--- Begin Message ---
Please do not reply directly to this email. All ad
On Sat, Mar 31, 2007 at 04:27:46PM +0530, Milind Arun Choudhary wrote:
> Clean up ROUND_?UP, Use ALIGN where ever appropriate.
>
> Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]>
Milind,
Looks good to me.
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
Kyle,
can you remind me how the
Alan Cox writes:
> That would be completely unmanagable on many systems with multiport
> controllers and interfaces where the naming tells you things like which
> cable port off which socket off which multiplexor is the one you are
> talking about.
I never suggested *all* serial ports should be /
On Mon, 2007-04-02 at 00:31 -0400, Dave Dillow wrote:
> On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
[snipped for brevity]
> > [EMAIL PROTECTED] music]# stat .
> > Device: fd00h/64768dInode: 10354963Links: 39
> > Now rebooted to 2.6.21-rc5:
> > Device: ee00h/60928dInode: 1035
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm/hugetlbpage.c |8
2 files changed, 15 insertions(+)
Index: linux-cell/arch/ia64/kernel/sys_ia64.c
=
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/i386/mm/hugetlbpage.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
--- linux-cell.orig/arch/parisc/kernel
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/sparc64/mm/huget
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
--- linux-cell.orig/arch/x86_64/kernel/s
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c 2007-03
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
This is a "first step" as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
The current get_unmapped_area code calls the f_ops->get_unmapped_area or
the arch one (via th
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/i386/mm/hugetlbpage.c
resend
On 4/3/07, Yinghai Lu <[EMAIL PROTECTED]> wrote:
please check the patch
YH
[PATCH] x86_64/acpi: make kernel to be compiled when CONFIG_ACPI_NUMA is set and power management with acpi is not enabled
when CONFIG_ACPI_NUMA is set, and power management with acpi is not used. the kernel c
On Wed, 2007-04-04 at 14:01 +1000, Benjamin Herrenschmidt wrote:
> This is a "first step" as there are still cleanups to be done in various
> areas touched by that code but I think it's probably good to go as is and
> at least enables me to implement what I need for PowerPC.
.../...
And sorry f
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/sparc64/mm/huget
On 4/3/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
User space queries like "what is the cpuset to which this task belongs",
where the answer needs to be something of the form "/dev/cpuset/C1"?
The patches address that requirement atm by having a dentry pointer in
struct cpuset itself.
Hav
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm/hugetlbpage.c |8
2 files changed, 15 insertions(+)
Index: linux-cell/arch/ia64/kernel/sys_ia64.c
=
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
--- linux-cell.orig/arch/parisc/kernel
This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
and change the caller now that everybody can handle it.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
mm/mmap.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
Index: linux-cell/mm/mmap.c
===
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
--- linux-cell.orig/arch/x86_64/kernel/s
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c 2007-03
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
mm/mmap.c | 16
1 file changed, 16 deletions(-)
Index: linux-cell/mm/mmap.c
===
--- linux-cell.orig/mm/mmap.c 2007-03-22 16:30:24.0 +1100
+++
Hi Yoichi,
Could you please try the patch below? It moves platform device creation
code into cobalt arch code to belletr follow driver model.
Thank you!
--
Dmitry
Input: cobalt buttons - separate device and driver registration
Create platform device for cobalt buttons as part of arch setup.
T
This is a "first step" as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
The current get_unmapped_area code calls the f_ops->get_unmapped_area or
the arch one (via th
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/b44.c |2 +-
drivers/net/cxgb3/common.h|9 +--
drivers/net/cxgb3/cxgb3_main.c| 3
please check the patch
YH
[PATCH] x86_64/acpi: make kernel to be compiled when CONFIG_ACPI_NUMA is set and power management with acpi is not enabled
when CONFIG_ACPI_NUMA is set, and power management with acpi is not used. the kernel can not be compiled.
drivers/acpi/bus.c: In function âacpi
Matt Mackall wrote:
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
I think it would be better in mm/.
So would clear_refs_pte_range, and clear_refs_write (in a more
generic form), IMO.
Sweet patchset, though.
--
SUSE Labs, Novell I
On Tue, 03 Apr 2007, Jeremy Fitzhardinge wrote:
> Attached. Is there some tool for decoding the DSDT?
iasl. The documentation is the ACPI Specification.
> >> ezr:pts/1; cat /proc/acpi/ibm/thermal
> >> temperatures: 72 55 -128 65 40 -128 35 -128 51 53 -128 -128 -128 -128
> >> -128 -128
> >
> >
vatsa wrote:
> User space queries like "what is the cpuset to which this task belongs",
> where the answer needs to be something of the form "/dev/cpuset/C1"?
I think that answer should be of the form "/C1", and not include the
cpuset file system mount point ... though for the purposes of the
pres
[EMAIL PROTECTED] wrote:
On Tue, 03 Apr 2007 19:20:04 PDT, Randy Dunlap said:
On Tue, 03 Apr 2007 21:35:54 -0400 [EMAIL PROTECTED] wrote:
I do a '/ACPI_SLEEP' inside that, and I get this output:
x Symbol: ACPI_SLEEP [=n] x
x Depends on: !X86_
On Fri, Mar 30, 2007 at 04:40:48AM +0200, Nick Piggin wrote:
>
> Well it would make life easier if we got rid of ZERO_PAGE completely,
> which I definitely wouldn't complain about ;)
So, what bad things (apart from my bugs in untested code) happen
if we do this? We can actually go further, and pr
On Tue, 03 Apr 2007 19:20:04 PDT, Randy Dunlap said:
> On Tue, 03 Apr 2007 21:35:54 -0400 [EMAIL PROTECTED] wrote:
> > I do a '/ACPI_SLEEP' inside that, and I get this output:
> >
> > x Symbol: ACPI_SLEEP [=n] x
> > x Depends on: !X86_NUMAQ && !X
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section mismatch warnings in mtrr code.
Fix line length on one source line.
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to
.init.data: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x103)
WARNING: arch/x86_64/kerne
On Wed, 04 Apr 2007 12:28:38 +1000 Rusty Russell wrote:
> lguest wants range checking, but unless there are other users I'm not
> sure this is worth the pain. Putting it out there in case it's useful.
>
> Cheers,
> Rusty.
> ==
> There are some places where we want to check if a value + length is
On Wed, 4 Apr 2007, Alan Cox wrote:
> You don't get machines with 64 ethernet ports on add-in cards. There are
> good reasons for the naming schemes in use.
If they made them I'd build one.
http://innerfire.net/pics/projects/21portfirewall_2.jpg
Gerhard
--
Gerhard Mack
[EMAIL PROTECTED
On Tue, Apr 03, 2007 at 07:45:16PM +0530, Gautham R Shenoy wrote:
> > Should we ignore this for the timebeing and take up later as and when
> > users report problems?
>
> In my case, the problem of freezer failing was due to the vfork freezer race
> in do_fork. The parent task was waiting_for_comp
Ulrich wrote:
> For sysconf() we still need better support. Maybe now somebody will
> step up and say they need faster sysconf as well.
That won't be me ;).
For any kernel compiled with CONFIG_CPUSETS (which includes the major
distros I am aware of), one can just count the bits in the top cpuset
On Tue, Apr 03, 2007 at 10:49:49AM -0700, Paul Menage wrote:
> > Why is the hierarchy bit important here? Usually controllers need to
> > know "tell me what cpuset this task belongs to", which is answered
> > by tsk->nsproxy->ctlr_data[CPUSET_ID].
>
> I was thinking of queries from userspace.
Use
1 - 100 of 484 matches
Mail list logo
