figuration mostly-modular, based on standard SuSE kernel's
> > > /proc/config.gz, just compiling into the kernel everything I need to
> > > boot without an initrd and omitting some parts I'm not interested in.
> > > (.config attached.) What else might be relevant?
> >
from the machine. (Probably Murphy at work.)
It's pretty rare: I have seen it four times on 2.6.21-rc3-mm2 and
once on 2.6.21-rc5, on a machine which spends about equal amounts
of time running the latest stable, rc, and mm kernels. OTOH, so far
it hasn't ever happened with any 2.6.20
figuration mostly-modular, based on standard SuSE kernel's
> > > /proc/config.gz, just compiling into the kernel everything I need to
> > > boot without an initrd and omitting some parts I'm not interested in.
> > > (.config attached.) What else might be relevant?
> >
from the machine. (Probably Murphy at work.)
It's pretty rare: I have seen it four times on 2.6.21-rc3-mm2 and
once on 2.6.21-rc5, on a machine which spends about equal amounts
of time running the latest stable, rc, and mm kernels. OTOH, so far
it hasn't ever happened with any 2.6.20
>> (.config attached.) What else might be relevant?
>>
>> Again, this is a Heisenbug, ie. it's not reproducible and invariably
>> happens when I'm away from the machine. (Probably Murphy at work.)
>> It's pretty rare: I have seen it four times on 2.6.21-rc3-mm2 and
&g
parts I'm not interested in.
> > (.config attached.) What else might be relevant?
> >
> > Again, this is a Heisenbug, ie. it's not reproducible and invariably
> > happens when I'm away from the machine. (Probably Murphy at work.)
> > It's pretty rare: I have seen it four tim
> /proc/config.gz, just compiling into the kernel everything I need to
> boot without an initrd and omitting some parts I'm not interested in.
> (.config attached.) What else might be relevant?
>
> Again, this is a Heisenbug, ie. it's not reproducible and invariably
> happens when
not interested in.
(.config attached.) What else might be relevant?
Again, this is a Heisenbug, ie. it's not reproducible and invariably
happens when I'm away from the machine. (Probably Murphy at work.)
It's pretty rare: I have seen it four times on 2.6.21-rc3-mm2 and
once on 2.6.21-rc5
times on 2.6.21-rc3-mm2 and
once on 2.6.21-rc5, on a machine which spends about equal amounts
of time running the latest stable, rc, and mm kernels. OTOH, so far
it hasn't ever happened with any 2.6.20 or earlier kernel. Nor have
I seen it with 2.6.21-rc[1-4] or 2.6.21-rc4-mm
an initrd and omitting some parts I'm not interested in.
(.config attached.) What else might be relevant?
Again, this is a Heisenbug, ie. it's not reproducible and invariably
happens when I'm away from the machine. (Probably Murphy at work.)
It's pretty rare: I have seen it four times on 2.6.21-rc3
o the kernel everything I need to
> boot without an initrd and omitting some parts I'm not interested in.
> (.config attached.) What else might be relevant?
>
> Again, this is a Heisenbug, ie. it's not reproducible and invariably
> happens when I'm away from the machine. (Probably Mur
else might be relevant?
Again, this is a Heisenbug, ie. it's not reproducible and invariably
happens when I'm away from the machine. (Probably Murphy at work.)
It's pretty rare: I have seen it four times on 2.6.21-rc3-mm2 and
once on 2.6.21-rc5, on a machine which spends about equal amounts
On a SuSE 10.0 system running kernel 2.6.21-rc3-mm2, it has now
happened for the 4th time that I came back after a couple of hours
to find that all KDE processes of the session I had left running had
died. The X server and applications (2x konsole, emacs, ksysguard)
were still running, but the K
On a SuSE 10.0 system running kernel 2.6.21-rc3-mm2, it has now
happened for the 4th time that I came back after a couple of hours
to find that all KDE processes of the session I had left running had
died. The X server and applications (2x konsole, emacs, ksysguard)
were still running, but the K
Previously had #include , and mine just had
"struct task_struct;" instead for its forward references. asm-x86_64/elf.h
uses current->field in the ELF_CORE_COPY_REGS macro, expanded in
linux/elfcore.h in elf_core_copy_regs. So it needs sched.h but is no
longer getting it implicitly. Since
Peter Zijlstra a écrit :
Unfortunately not, nonlinear vmas don't have a linear relation between
address and offset. What you would need to do is do a linear walk of the
page tables. But even that might not suffice if nonlinear vmas may form
a non-injective, surjective mapping.
/me checks..
On Tue, 2007-03-20 at 16:32 +0100, Pierre Peiffer wrote:
> Peter Zijlstra a écrit :
> >> +static void *get_futex_address(union futex_key *key)
> >> +{
> >> + void *uaddr;
> >> +
> >> + if (key->both.offset & 1) {
> >> + /* shared mapping */
> >> + uaddr =
Sam Ravnborg wrote:
On Mon, Mar 19, 2007 at 05:27:11PM -0700, Randy Dunlap wrote:
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
- This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler
Peter Zijlstra a écrit :
+static void *get_futex_address(union futex_key *key)
+{
+ void *uaddr;
+
+ if (key->both.offset & 1) {
+ /* shared mapping */
+ uaddr = (void*)((key->shared.pgoff << PAGE_SHIFT)
+ + key->shared.offset
On Mon, Mar 19, 2007 at 05:27:11PM -0700, Randy Dunlap wrote:
> On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
> >
> > - This is the same as 2.6.21-rc3-m
On Mon, Mar 19, 2007 at 05:27:11PM -0700, Randy Dunlap wrote:
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
- This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
Peter Zijlstra a écrit :
+static void *get_futex_address(union futex_key *key)
+{
+ void *uaddr;
+
+ if (key-both.offset 1) {
+ /* shared mapping */
+ uaddr = (void*)((key-shared.pgoff PAGE_SHIFT)
+ + key-shared.offset - 1);
Sam Ravnborg wrote:
On Mon, Mar 19, 2007 at 05:27:11PM -0700, Randy Dunlap wrote:
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
- This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler
On Tue, 2007-03-20 at 16:32 +0100, Pierre Peiffer wrote:
Peter Zijlstra a écrit :
+static void *get_futex_address(union futex_key *key)
+{
+ void *uaddr;
+
+ if (key-both.offset 1) {
+ /* shared mapping */
+ uaddr = (void*)((key-shared.pgoff PAGE_SHIFT)
+
Peter Zijlstra a écrit :
Unfortunately not, nonlinear vmas don't have a linear relation between
address and offset. What you would need to do is do a linear walk of the
page tables. But even that might not suffice if nonlinear vmas may form
a non-injective, surjective mapping.
/me checks..
Previously linux/ptrace.h had #include linux/sched.h, and mine just had
struct task_struct; instead for its forward references. asm-x86_64/elf.h
uses current-field in the ELF_CORE_COPY_REGS macro, expanded in
linux/elfcore.h in elf_core_copy_regs. So it needs sched.h but is no
longer getting it
nel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
> > >
> > > - This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
> > > were dropped.
> > >
> > > This is for A/B comparison purposes, and because those changes crashed
>
On Mon, 19 Mar 2007 17:27:11 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
> >
> > - This is the same
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
>
> - This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
> were dropped.
>
> This is for A/
On Mon, 2007-03-19 at 12:55 -0700, Andrew Morton wrote:
> On Mon, 19 Mar 2007 12:17:24 -0700
> Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/
On Mon, 19 Mar 2007 12:17:24 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
> >
> > - This is the same
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
>
> - This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
> were dropped.
>
> This is for A/
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
>
> - This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
> were dropped.
>
> This is for A/
On Mon, 19 Mar 2007 17:18:44 + Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> [applogies in advance if this has already been asked]
>
> I note that PG_booked and PG_readahead are both using bit 20 in
> 2.6.21-rc3-mm2. Is this intentional or perhaps a miss-merge. They do
>
[applogies in advance if this has already been asked]
I note that PG_booked and PG_readahead are both using bit 20 in
2.6.21-rc3-mm2. Is this intentional or perhaps a miss-merge. They do
not sound obviously non-overlapping to my mind.
-apw
-
To unsubscribe from this list: send the line
[applogies in advance if this has already been asked]
I note that PG_booked and PG_readahead are both using bit 20 in
2.6.21-rc3-mm2. Is this intentional or perhaps a miss-merge. They do
not sound obviously non-overlapping to my mind.
-apw
-
To unsubscribe from this list: send the line
On Mon, 19 Mar 2007 17:18:44 + Andy Whitcroft [EMAIL PROTECTED] wrote:
[applogies in advance if this has already been asked]
I note that PG_booked and PG_readahead are both using bit 20 in
2.6.21-rc3-mm2. Is this intentional or perhaps a miss-merge. They do
not sound obviously non
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
- This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
were dropped.
This is for A/B comparison purposes, and because
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
- This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
were dropped.
This is for A/B comparison purposes, and because
On Mon, 19 Mar 2007 12:17:24 -0700
Randy Dunlap [EMAIL PROTECTED] wrote:
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
- This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler
On Mon, 2007-03-19 at 12:55 -0700, Andrew Morton wrote:
On Mon, 19 Mar 2007 12:17:24 -0700
Randy Dunlap [EMAIL PROTECTED] wrote:
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
- This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
were dropped.
This is for A/B comparison purposes, and because
On Mon, 19 Mar 2007 17:27:11 -0700
Randy Dunlap [EMAIL PROTECTED] wrote:
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
- This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler
On Mon, 19 Mar 2007 17:39:15 -0700 Andrew Morton wrote:
On Mon, 19 Mar 2007 17:27:11 -0700
Randy Dunlap [EMAIL PROTECTED] wrote:
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2
Len Brown wrote:
On Monday 12 March 2007 09:25, Luming Yu wrote:
try acpi=off please.
Ok, it boots up fine with acpi=off.
Now the next step is to try without the mm patch?
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Hi!
> >> > Killing the known corner case starvation scenarios
> >is wonderful, but
> >> > let's not just pretend that interactive tasks don't
> >have any special
> >> > requirements.
> >>
> >> Now you're really making a stretch of things. Where
> >on earth did I say that
> >> interactive tasks
What follows is a patch series for the updated version of the Rotating
Staircase DeadLine cpu scheduler.
The dropping of one patch in the series and modest rewrite of certain
components means a fresh patch series is most appropriate, apologies for any
inconvenience.
Changes
- Implemented
On Tue, 2007-03-13 at 10:52 +0100, [EMAIL PROTECTED] wrote:
> plain text document attachment (futex-requeue-pi.diff)
> This patch provides the futex_requeue_pi functionality.
>
> This provides an optimization, already used for (normal) futexes, to be used
> for
> PI-futexes.
>
> This
On Tue, 2007-03-13 at 10:52 +0100, [EMAIL PROTECTED] wrote:
plain text document attachment (futex-requeue-pi.diff)
This patch provides the futex_requeue_pi functionality.
This provides an optimization, already used for (normal) futexes, to be used
for
PI-futexes.
This optimization is
What follows is a patch series for the updated version of the Rotating
Staircase DeadLine cpu scheduler.
The dropping of one patch in the series and modest rewrite of certain
components means a fresh patch series is most appropriate, apologies for any
inconvenience.
Changes
- Implemented
Hi!
Killing the known corner case starvation scenarios
is wonderful, but
let's not just pretend that interactive tasks don't
have any special
requirements.
Now you're really making a stretch of things. Where
on earth did I say that
interactive tasks don't have special
Len Brown wrote:
On Monday 12 March 2007 09:25, Luming Yu wrote:
try acpi=off please.
Ok, it boots up fine with acpi=off.
Now the next step is to try without the mm patch?
Helge Hafting
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Andrew Morton wrote:
> Well OK. But that doesn't actually explain why 64-bit mutexes are needed.
> It just says they are required.
I can show you the code but it's not easy to understand. For
complicated syn objects like rwlocks the state information is more than
just locked or not. Currently
On Thu, 15 Mar 2007 12:12:11 -0700 Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Why do we want 64-bit futexes?
>
> I sent this to you already on 1/12/2007:
>
> http://udrepper.livejournal.com/13123.html
>
Well OK. But that doesn't actually explain why 64-bit mutexes
Andrew Morton wrote:
> Why do we want 64-bit futexes?
I sent this to you already on 1/12/2007:
http://udrepper.livejournal.com/13123.html
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
> On Tue, 13 Mar 2007 10:52:07 +0100 [EMAIL PROTECTED] wrote:
> This last patch is an adaptation of the sys_futex64 syscall provided in -rt
> patch (originally written by Ingo). It allows the use of 64bit futex.
>
> I have re-worked most of the code to avoid the duplication of the code.
>
> It
On Tue, 13 Mar 2007 10:52:07 +0100 [EMAIL PROTECTED] wrote:
This last patch is an adaptation of the sys_futex64 syscall provided in -rt
patch (originally written by Ingo). It allows the use of 64bit futex.
I have re-worked most of the code to avoid the duplication of the code.
It does not
Andrew Morton wrote:
Why do we want 64-bit futexes?
I sent this to you already on 1/12/2007:
http://udrepper.livejournal.com/13123.html
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
On Thu, 15 Mar 2007 12:12:11 -0700 Ulrich Drepper [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Why do we want 64-bit futexes?
I sent this to you already on 1/12/2007:
http://udrepper.livejournal.com/13123.html
Well OK. But that doesn't actually explain why 64-bit mutexes are needed.
Andrew Morton wrote:
Well OK. But that doesn't actually explain why 64-bit mutexes are needed.
It just says they are required.
I can show you the code but it's not easy to understand. For
complicated syn objects like rwlocks the state information is more than
just locked or not. Currently we
Bjorn Helgaas <[EMAIL PROTECTED]> writes:
> In 2.6.21-rc3-mm2 (plus some move_freepages() bugfixes), I hit one
> of the warnings added by Eric's msi-debug-code.patch. This is on an
> ia64 box, an HP rx2600. Let me know if I can collect more information.
I think we are good. How
On Wed, 14 Mar 2007, Bjorn Helgaas wrote:
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
Virtual mem_map starts at 0xa0007fffc720
Zone PFN ranges:
Total aside, a message should have been printed out here with
"sizeof(struct page) = ??" when loglevel was set to 8. I wanted it so I
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
> >
> > Virtual mem_map starts at 0xa0007fffc720
> > Zone PFN ranges:
>
> Total aside, a message should have been printed out here with
> "sizeof(struct page) = ??" when loglevel was set to 8. I wanted it so I
> could work out PFNs from
On Wed, 14 Mar 2007, Bjorn Helgaas wrote:
On Wednesday 14 March 2007 11:21, Mel Gorman wrote:
Can you tell me if the faulting line was at the check for PageBuddy?
I don't know, sorry.
No problem, the fact the patch booted lets me know that calling
PageBuddy() on an invalid page had the
() is called.
Boots fine with this patch:
Linux version 2.6.21-rc3-mm2 ([EMAIL PROTECTED]) (gcc version 4.0.3 (Debian
4.0.3-1)) #8 SMP Wed Mar 14 11:34:23 MST 2007
EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS=0x3fb3a000
HCDP=0x3fb2c000
booting generic kernel on platform hp
ck for PageBuddy? Can you
also apply the following patch and boot with loglevel=8 please? The
patch moves the check for pfn_valid() before PageBuddy() is called.
Thanks
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.21-rc3-mm2-bjorn_testfix/mm/page_alloc.c
linux-2.6.21-rc3-mm2-bjorn
_, zone->name, zone->zone_start_pfn, start_page,
+ end_page);
+
#ifndef CONFIG_HOLES_IN_ZONE
/*
* page_zone is not safe to call in this context when
and it crashed like this. Let me know if I can collect more information
for you.
Linux version 2.6.21-rc3-mm2
t a patch that simply deletes this check because it should be redundant.
Just in case, I'd like to preserve the check in the non-HOLES_IN_ZONE
case for now.
Can you try this patch please? It should apply on top of Yasunori Goto's
patch.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
On Wednesday 14 March 2007 03:44, Mel Gorman wrote:
> Please try the following patch from Yasunori Goto.
> ...
> --- current_test.orig/mm/page_alloc.c 2007-03-08 15:44:10.0 +0900
> +++ current_test/mm/page_alloc.c 2007-03-08 16:17:29.0 +0900
> @@ -707,7 +707,7 @@ int
nori Goto <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>
Cc: linux-kernel@vger.kernel.org, Mel Gorman <[EMAIL PROTECTED]>
Subject: [PATCH] fix BUG_ON check at move_freepages() (Re: 2.6.21-rc3-mm2)
Hello.
The BUG_ON() check at move_freepages() is wrong.
Its end_page is start_p
On Wed, 2007-03-14 at 04:25 +0100, Gabriel C wrote:
> [EMAIL PROTECTED] wrote:
> > On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
> >
> >> with latest xorg, xlib will be using xcb internally,
> >>
> >
> > Out of curiosity, when is this "latest" Xorg going to escape to distros,
> >
On Wed, 2007-03-14 at 04:25 +0100, Gabriel C wrote:
[EMAIL PROTECTED] wrote:
On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
with latest xorg, xlib will be using xcb internally,
Out of curiosity, when is this latest Xorg going to escape to distros,
Already is
[EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org, Mel Gorman [EMAIL PROTECTED]
Subject: [PATCH] fix BUG_ON check at move_freepages() (Re: 2.6.21-rc3-mm2)
Hello.
The BUG_ON() check at move_freepages() is wrong.
Its end_page is start_page + MAX_ORDER_NR_PAGES. So, it can be
next zone. BUG_ON
On Wednesday 14 March 2007 03:44, Mel Gorman wrote:
Please try the following patch from Yasunori Goto.
...
--- current_test.orig/mm/page_alloc.c 2007-03-08 15:44:10.0 +0900
+++ current_test/mm/page_alloc.c 2007-03-08 16:17:29.0 +0900
@@ -707,7 +707,7 @@ int
-HOLES_IN_ZONE
case for now.
Can you try this patch please? It should apply on top of Yasunori Goto's
patch.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.21-rc3-mm2-goto/mm/page_alloc.c
linux-2.6.21-rc3-mm2-bjorn_testfix/mm/page_alloc.c
--- linux
CONFIG_HOLES_IN_ZONE
/*
* page_zone is not safe to call in this context when
and it crashed like this. Let me know if I can collect more information
for you.
Linux version 2.6.21-rc3-mm2 ([EMAIL PROTECTED]) (gcc version 4.0.3 (Debian
4.0.3-1)) #7 SMP Wed Mar 14 09:42:50 MST 2007
EFI v1.10
was at the check for PageBuddy? Can you
also apply the following patch and boot with loglevel=8 please? The
patch moves the check for pfn_valid() before PageBuddy() is called.
Thanks
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.21-rc3-mm2-bjorn_testfix/mm/page_alloc.c
linux-2.6.21-rc3-mm2
.
Boots fine with this patch:
Linux version 2.6.21-rc3-mm2 ([EMAIL PROTECTED]) (gcc version 4.0.3 (Debian
4.0.3-1)) #8 SMP Wed Mar 14 11:34:23 MST 2007
EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS=0x3fb3a000
HCDP=0x3fb2c000
booting generic kernel on platform hpzx1
PCDP: v0
On Wed, 14 Mar 2007, Bjorn Helgaas wrote:
On Wednesday 14 March 2007 11:21, Mel Gorman wrote:
Can you tell me if the faulting line was at the check for PageBuddy?
I don't know, sorry.
No problem, the fact the patch booted lets me know that calling
PageBuddy() on an invalid page had the
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
SNIP
Virtual mem_map starts at 0xa0007fffc720
Zone PFN ranges:
Total aside, a message should have been printed out here with
sizeof(struct page) = ?? when loglevel was set to 8. I wanted it so I
could work out PFNs from the
On Wed, 14 Mar 2007, Bjorn Helgaas wrote:
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
SNIP
Virtual mem_map starts at 0xa0007fffc720
Zone PFN ranges:
Total aside, a message should have been printed out here with
sizeof(struct page) = ?? when loglevel was set to 8. I wanted it so I
Bjorn Helgaas [EMAIL PROTECTED] writes:
In 2.6.21-rc3-mm2 (plus some move_freepages() bugfixes), I hit one
of the warnings added by Eric's msi-debug-code.patch. This is on an
ia64 box, an HP rx2600. Let me know if I can collect more information.
I think we are good. How pci_save_state
FYI, I'm seeing the following oops with 2.6.21-rc3-mm1 (and -mm2)
on the HP rx2600 and an Intel Tiger (both ia64 boxes).
I haven't investigated this other than to determine that it
does not occur with 2.6.21-rc3 or 2.6.20-rc3-mm1, and the
instruction at move_freepages+0x10 is a load of the value
[EMAIL PROTECTED] wrote:
On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
with latest xorg, xlib will be using xcb internally,
Out of curiosity, when is this "latest" Xorg going to escape to distros,
Already is .. Xorg 7.2+ libx11 build with xcb enabled..
and is it far
On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
> with latest xorg, xlib will be using xcb internally,
Out of curiosity, when is this "latest" Xorg going to escape to distros,
and is it far enough along that beta testers can gather usable numbers?
pgpt7KqlXv9Rp.pgp
Description: PGP
> a previous discussion that said 4 was the default...I don't see
> why. nice uses +10 by default on all linux distro...So I suspect
> that if Mike just used "nice lame" instead of "nice +5 lame", he
> would have got what he wanted.
tcsh, and probably csh, has a builtin 'nice' with default +4.
On Tue, Mar 13, 2007 at 01:10:40PM -0700, Jeremy Fitzhardinge wrote:
> David Schwartz wrote:
> Hm, well. The general preference has been for the kernel to do a
> good-enough job on getting the common cases right without tuning, and
> then only add knobs for the really tricky cases it can't do
On Tue, Mar 13, 2007 at 12:58:01PM -0700, David Schwartz wrote:
> > But saying that the user needs to explicitly hold the schedulers hand
> > and nice everything to tell it how to schedule seems to be an abdication
> > of duty, an admission of failure. We can't expect users to finesse all
> >
David Schwartz wrote:
>> There's a distinction between giving it more cpu and giving it higher
>> priority: the important part about having high priority is getting low
>> latency access to the cpu when its needed.
>>
>
> I agree. Tasks that voluntarily relinquish their timeslices should get
> There's a distinction between giving it more cpu and giving it higher
> priority: the important part about having high priority is getting low
> latency access to the cpu when its needed.
I agree. Tasks that voluntarily relinquish their timeslices should get lower
latency compared to other
David Schwartz wrote:
> Good interactivity for tasks that aren't themselves CPU hogs. A task should
> get low latency if and only if it's yielding the CPU voluntarily most of the
> time. If it's not, it can only get better interactivity at the cost of
> fairness, and you have to *ask* for that.
On Mon, 12 Mar 2007 20:06:43 BST, Xavier Bestel said:
> Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> > Again I think your test is not a valid testcase. Why use two threads for
> > your
> > encoding with one cpu? Is that what other dedicated desktop OSs would do?
>
> One thought
> "Serge" == Serge Belyshev <[EMAIL PROTECTED]> writes:
Serge> Mike Galbraith <[EMAIL PROTECTED]> writes:
Serge> [snip]
>> It seems to be a plain linear slowdown. The lurchiness I'm experiencing
>> varies in intensity, and is impossible to quantify. I see neither
>> lurchiness nor slowdown
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > [...] The situation as we speak is that you can run cpu intensive
> > tasks while watching eye-candy. With RSDL, you can't, you feel the
> > non-interactive load instantly. [...]
>
> i have to agree with Mike that this is a material regression
On Tue, Mar 13, 2007 at 10:33:18AM +0100, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:
>
> > Con, we want RSDL to /improve/ interactivity. Having new scheduler
> > interactivity logic that behaves /worse/ in the presence of CPU hogs,
> > which CPU hogs are even
On Tue, 2007-03-13 at 14:41 +0300, Serge Belyshev wrote:
> Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> [snip]
> > It seems to be a plain linear slowdown. The lurchiness I'm experiencing
> > varies in intensity, and is impossible to quantify. I see neither
> > lurchiness nor slowdown in
Mike Galbraith <[EMAIL PROTECTED]> writes:
[snip]
> It seems to be a plain linear slowdown. The lurchiness I'm experiencing
> varies in intensity, and is impossible to quantify. I see neither
> lurchiness nor slowdown in mainline through -j8.
>
Whaa? make -j8 on mainline makes my desktop box
On Tue, 2007-03-13 at 21:06 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 20:39, Ingo Molnar wrote:
> > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > I just retested with the encoders at nice 0, and the x/gforce combo is
> > > terrible. [...]
> >
> > ok. So nice levels had nothing to do
On Tue, Mar 13, 2007 at 08:41:05PM +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 20:29, Ingo Molnar wrote:
> > So the question is: if all tasks are on the same nice level, how does,
> > in Mike's test scenario, RSDL behave relative to the current
> > interactivity code?
...
> The only way
On Tue, 2007-03-13 at 20:31 +1100, Con Kolivas wrote:
> nice on my debian etch seems to choose nice +10 without arguments contrary to
> a previous discussion that said 4 was the default. However 4 is a good value
> to use as a base of sorts.
I don't see why. nice uses +10 by default on all
1 - 100 of 300 matches
Mail list logo
