Re: 2.6.9-rc4-mm1 OOPs on AMD64

From: Rafael J. Wysocki
Date: Tue Oct 12 2004 - 03:53:34 EST

On Tuesday 12 of October 2004 01:10, Badari Pulavarty wrote:
> On Mon, 2004-10-11 at 15:38, Andrew Morton wrote:
> > Andi Kleen <ak@xxxxxxx> wrote:
> > >
> > > > Console: colour VGA+ 80x25
> > > > Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
> > > > Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
> > > > Bad page state at free_hot_cold_page (in process 'swapper', page
> > > > 000001017ac06070)
> > > > flags:0x00000000 mapping:0000000000000000 mapcount:1 count:0
> > >
> > > Some memory corruption or confused memory allocator.
> >
> > I'd be suspecting no-buddy-bitmap-patch-*.patch
> >
>
> Nope. This is not it..
>
> Andi, do you know which is the last good -mm kernel on AMD ?
> Is it 2.6.9-rc3-mm3 ? The last I tested on AMD was 2.6.9-rc2-mm3 :(

I've been running 2.6.9-rc3-mm3 on AMD64 for quite some time without much
problems, except that X apparently gets killed from time to time (this is not
reproducible). However, I had to reverse the
optimize-profile-path-slightly.patch (attached) and I applied a couple of
other patches (attached too).

Greets,
RJW

--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
From akpm@xxxxxxxx Thu Oct 7 23:40:45 2004
Return-Path: <linux-kernel-owner+rjwysocki=40sisk.pl-S268236AbUJGVky@xxxxxxxxxxxxxxx>
Delivered-To: rafael@xxxxxxxxxxxxxxxxxxxxxxxxx
Received: (qmail 27817 invoked from network); 8 Oct 2004 02:19:04 -0000
Received: from localhost (?aP3k60+qaf6+JSF3i6QxSh+NouiH61rg?@127.0.0.1)
by localhost with SMTP; 8 Oct 2004 02:19:04 -0000
Received: from mail.digitalservice.pl ([127.0.0.1])
by localhost (grendel [127.0.0.1]) (amavisd-new, port 10024) with SMTP
id 27682-04 for <rafael@xxxxxxxxxxxxxxxxxxxxxxxxx>;
Fri, 8 Oct 2004 04:18:59 +0200 (CEST)
Received: (qmail 27810 invoked by uid 529); 8 Oct 2004 02:18:59 -0000
Delivered-To: sisk-rjwysocki@xxxxxxx
Received: (qmail 27807 invoked from network); 8 Oct 2004 02:18:59 -0000
Received: from vger.kernel.org (12.107.209.244)
by grendel.digitalservice.pl with SMTP; 8 Oct 2004 02:18:59 -0000
Received: (majordomo@xxxxxxxxxxxxxxx) by vger.kernel.org via listexpand
id S268236AbUJGVky (ORCPT <rfc822;rjwysocki@xxxxxxx>);
Thu, 7 Oct 2004 17:40:54 -0400
Received: (majordomo@xxxxxxxxxxxxxxx) by vger.kernel.org id S267890AbUJGViE
(ORCPT <rfc822;linux-kernel-outgoing>);
Thu, 7 Oct 2004 17:38:04 -0400
Received: from fw.osdl.org ([65.172.181.6]:28811 "EHLO mail.osdl.org")
by vger.kernel.org with ESMTP id S268229AbUJGVhB (ORCPT
<rfc822;linux-kernel@xxxxxxxxxxxxxxx>);
Thu, 7 Oct 2004 17:37:01 -0400
Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2])
by mail.osdl.org (8.11.6/8.11.6) with SMTP id i97Lamf32753;
Thu, 7 Oct 2004 14:36:48 -0700
Date: Thu, 7 Oct 2004 14:40:45 -0700
From: Andrew Morton <akpm@xxxxxxxx>
To: "Rafael J. Wysocki" <rjw@xxxxxxx>
Cc: ak@xxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: 2.6.9-rc3-mm3: build problem on dual-Opteron w/ NUMA
Message-Id: <20041007144045.29e64ef0.akpm@xxxxxxxx>
In-Reply-To: <200410072301.39399.rjw@xxxxxxx>
References: <20041007015139.6f5b833b.akpm@xxxxxxxx>
<200410072301.39399.rjw@xxxxxxx>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain;
charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@xxxxxxxxxxxxxxx
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
X-Virus-Scanned: by amavisd-new at grendel.digitalservice.pl using MkS_Vir for Linux (beta)
Status: RO
X-Status: R
X-KMail-EncryptionState: N
X-KMail-SignatureState: N
X-KMail-MDN-Sent:

"Rafael J. Wysocki" <rjw@xxxxxxx> wrote:
>
> On Thursday 07 of October 2004 10:51, Andrew Morton
> >
> >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc3/2.6.9-rc3-mm3/
>
> It does not build on a dual-Opteron box w/ NUMA:
>
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/x86_64/kernel/built-in.o(.init.text+0x1fc1): In function
> `late_hpet_init':
> : undefined reference to `hpet_alloc'
> make: *** [.tmp_vmlinux1] Error 1
>
> The .config is available at:
> http://www.sisk.pl/kernel/041007/2.6.9-rc3-mm3-NUMA.config

akpm:/home/akpm> grep HPET 2.6.9-rc3-mm3-NUMA.config
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_HPET is not set

I'll take a punt and assume that CONFIG_HPET_TIMER requires CONFIG_HPET.


diff -puN arch/x86_64/Kconfig~hpet-dependency-fix arch/x86_64/Kconfig
--- 25/arch/x86_64/Kconfig~hpet-dependency-fix Thu Oct 7 14:38:35 2004
+++ 25-akpm/arch/x86_64/Kconfig Thu Oct 7 14:38:50 2004
@@ -60,6 +60,7 @@ config EARLY_PRINTK

config HPET_TIMER
bool
+ depends on HPET
default y
help
Use the IA-PC HPET (High Precision Event Timer) to manage
diff -puN arch/i386/Kconfig~hpet-dependency-fix arch/i386/Kconfig
--- 25/arch/i386/Kconfig~hpet-dependency-fix Thu Oct 7 14:39:03 2004
+++ 25-akpm/arch/i386/Kconfig Thu Oct 7 14:39:13 2004
@@ -429,6 +429,7 @@ config X86_OOSTORE

config HPET_TIMER
bool "HPET Timer Support"
+ depends on HPET
help
This enables the use of the HPET for the kernel's internal timer.
HPET is the next generation timer replacing legacy 8254s.
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


From akpm@xxxxxxxx Fri Oct 8 00:07:08 2004
Return-Path: <linux-kernel-owner+rjwysocki=40sisk.pl-S269822AbUJGWGU@xxxxxxxxxxxxxxx>
Delivered-To: rafael@xxxxxxxxxxxxxxxxxxxxxxxxx
Received: (qmail 27028 invoked from network); 8 Oct 2004 01:54:04 -0000
Received: from localhost (?5asyZye8j+GX7oIq3vqJD07cTouNrac3?@127.0.0.1)
by localhost with SMTP; 8 Oct 2004 01:54:04 -0000
Received: from mail.digitalservice.pl ([127.0.0.1])
by localhost (grendel [127.0.0.1]) (amavisd-new, port 10024) with SMTP
id 26840-04 for <rafael@xxxxxxxxxxxxxxxxxxxxxxxxx>;
Fri, 8 Oct 2004 03:53:58 +0200 (CEST)
Received: (qmail 27007 invoked by uid 529); 8 Oct 2004 01:53:58 -0000
Delivered-To: sisk-rjwysocki@xxxxxxx
Received: (qmail 27004 invoked from network); 8 Oct 2004 01:53:57 -0000
Received: from vger.kernel.org (12.107.209.244)
by grendel.digitalservice.pl with SMTP; 8 Oct 2004 01:53:58 -0000
Received: (majordomo@xxxxxxxxxxxxxxx) by vger.kernel.org via listexpand
id S269822AbUJGWGU (ORCPT <rfc822;rjwysocki@xxxxxxx>);
Thu, 7 Oct 2004 18:06:20 -0400
Received: (majordomo@xxxxxxxxxxxxxxx) by vger.kernel.org id S269772AbUJGWES
(ORCPT <rfc822;linux-kernel-outgoing>);
Thu, 7 Oct 2004 18:04:18 -0400
Received: from fw.osdl.org ([65.172.181.6]:6815 "EHLO mail.osdl.org")
by vger.kernel.org with ESMTP id S269356AbUJGWDV (ORCPT
<rfc822;linux-kernel@xxxxxxxxxxxxxxx>);
Thu, 7 Oct 2004 18:03:21 -0400
Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2])
by mail.osdl.org (8.11.6/8.11.6) with SMTP id i97M3Cf05562;
Thu, 7 Oct 2004 15:03:12 -0700
Date: Thu, 7 Oct 2004 15:07:08 -0700
From: Andrew Morton <akpm@xxxxxxxx>
To: "J.A. Magallon" <jamagallon@xxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx,
wli@xxxxxxxxxxxxxx,
Ingo Molnar <mingo@xxxxxxx>
Subject: Re: 2.6.9-rc3-mm3
Message-Id: <20041007150708.5d60e1c3.akpm@xxxxxxxx>
In-Reply-To: <1097185597l.10532l.1l@xxxxxxxxxxxxxxxx>
References: <20041007015139.6f5b833b.akpm@xxxxxxxx>
<200410071041.20723.sandersn@xxxxxxxxxxxxxx>
<20041007025007.77ec1a44.akpm@xxxxxxxx>
<20041007114040.GV9106@xxxxxxxxxxxxxx>
<1097184341l.10532l.0l@xxxxxxxxxxxxxxxx>
<1097185597l.10532l.1l@xxxxxxxxxxxxxxxx>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain;
charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@xxxxxxxxxxxxxxx
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
X-Virus-Scanned: by amavisd-new at grendel.digitalservice.pl using MkS_Vir for Linux (beta)
Status: RO
X-Status: R
X-KMail-EncryptionState:
X-KMail-SignatureState:
X-KMail-MDN-Sent:

"J.A. Magallon" <jamagallon@xxxxxxx> wrote:
>
> On 2004.10.07, J.A. Magallon wrote:
> >
> > This conflicts with kernel/irq/proc.c:
> >
> > unsigned long prof_cpu_mask = -1;
> >
> > Shouldn't this be:
> >
> > cpumask_t prof_cpu_mask = CPU_MASK_NONE;
> >
> > This will show problems when NR_CPUS > sizeof(long)....
> >
>
> Err....
>
> There is a problem with this -mm:

Yes, there seems to be a mingo/wli bunfight over prof_cpu_mask.

Something like this, I think:

--- 25/kernel/irq/proc.c~prof-irq-mask-fixup Thu Oct 7 15:04:14 2004
+++ 25-akpm/kernel/irq/proc.c Thu Oct 7 15:05:30 2004
@@ -10,8 +10,6 @@
#include <linux/proc_fs.h>
#include <linux/interrupt.h>

-unsigned long prof_cpu_mask = -1;
-
static struct proc_dir_entry *root_irq_dir, *irq_dir[NR_IRQS];

#ifdef CONFIG_SMP
@@ -65,34 +63,6 @@ static int irq_affinity_write_proc(struc

#endif

-static int prof_cpu_mask_read_proc(char *page, char **start, off_t off,
- int count, int *eof, void *data)
-{
- int len = cpumask_scnprintf(page, count, *(cpumask_t *)data);
-
- if (count - len < 2)
- return -EINVAL;
- len += sprintf(page + len, "\n");
- return len;
-}
-
-static int prof_cpu_mask_write_proc(struct file *file,
- const char __user *buffer,
- unsigned long count, void *data)
-{
- unsigned long full_count = count, err;
- cpumask_t *mask = (cpumask_t *)data;
- cpumask_t new_value;
-
- err = cpumask_parse(buffer, count, new_value);
- if (err)
- return err;
-
- *mask = new_value;
-
- return full_count;
-}
-
#define MAX_NAMELEN 128

void register_handler_proc(unsigned int irq, struct irqaction *action)
@@ -156,7 +126,6 @@ void unregister_handler_proc(unsigned in

void init_irq_proc(void)
{
- struct proc_dir_entry *entry;
int i;

/* create /proc/irq */
@@ -164,16 +133,6 @@ void init_irq_proc(void)
if (!root_irq_dir)
return;

- /* create /proc/irq/prof_cpu_mask */
- entry = create_proc_entry("prof_cpu_mask", 0600, root_irq_dir);
- if (!entry)
- return;
-
- entry->nlink = 1;
- entry->data = (void *)&prof_cpu_mask;
- entry->read_proc = prof_cpu_mask_read_proc;
- entry->write_proc = prof_cpu_mask_write_proc;
-
/*
* Create entries for all existing IRQs.
*/
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


From akpm@xxxxxxxx Thu Oct 7 23:33:59 2004
Return-Path: <linux-kernel-owner+rjwysocki=40sisk.pl-S268079AbUJGVk4@xxxxxxxxxxxxxxx>
Delivered-To: rafael@xxxxxxxxxxxxxxxxxxxxxxxxx
Received: (qmail 23775 invoked from network); 7 Oct 2004 21:48:48 -0000
Received: from localhost (?ebeyngtX+rDJog4oMS/oMfUR0ytakoI+?@127.0.0.1)
by localhost with SMTP; 7 Oct 2004 21:48:48 -0000
Received: from mail.digitalservice.pl ([127.0.0.1])
by localhost (grendel [127.0.0.1]) (amavisd-new, port 10024) with SMTP
id 23676-03 for <rafael@xxxxxxxxxxxxxxxxxxxxxxxxx>;
Thu, 7 Oct 2004 23:48:43 +0200 (CEST)
Received: (qmail 23768 invoked by uid 529); 7 Oct 2004 21:48:43 -0000
Delivered-To: sisk-rjwysocki@xxxxxxx
Received: (qmail 23765 invoked from network); 7 Oct 2004 21:48:43 -0000
Received: from vger.kernel.org (12.107.209.244)
by grendel.digitalservice.pl with SMTP; 7 Oct 2004 21:48:43 -0000
Received: (majordomo@xxxxxxxxxxxxxxx) by vger.kernel.org via listexpand
id S268079AbUJGVk4 (ORCPT <rfc822;rjwysocki@xxxxxxx>);
Thu, 7 Oct 2004 17:40:56 -0400
Received: (majordomo@xxxxxxxxxxxxxxx) by vger.kernel.org id S268080AbUJGVio
(ORCPT <rfc822;linux-kernel-outgoing>);
Thu, 7 Oct 2004 17:38:44 -0400
Received: from fw.osdl.org ([65.172.181.6]:11143 "EHLO mail.osdl.org")
by vger.kernel.org with ESMTP id S269830AbUJGVaW (ORCPT
<rfc822;linux-kernel@xxxxxxxxxxxxxxx>);
Thu, 7 Oct 2004 17:30:22 -0400
Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2])
by mail.osdl.org (8.11.6/8.11.6) with SMTP id i97LU3f30821;
Thu, 7 Oct 2004 14:30:04 -0700
Date: Thu, 7 Oct 2004 14:33:59 -0700
From: Andrew Morton <akpm@xxxxxxxx>
To: jschopp@xxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx,
Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
Subject: Re: 2.6.9-rc3-mm3
Message-Id: <20041007143359.6f11a398.akpm@xxxxxxxx>
In-Reply-To: <4165AD8B.9020207@xxxxxxxxxxxxxx>
References: <20041007015139.6f5b833b.akpm@xxxxxxxx>
<4165AD8B.9020207@xxxxxxxxxxxxxx>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain;
charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@xxxxxxxxxxxxxxx
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
X-Virus-Scanned: by amavisd-new at grendel.digitalservice.pl using MkS_Vir for Linux (beta)
Status: RO
X-Status: R
X-KMail-EncryptionState:
X-KMail-SignatureState:
X-KMail-MDN-Sent:

Joel Schopp <jschopp@xxxxxxxxxxxxxx> wrote:
>
> ppc64 defconfig doesn't compile for me.
>
> drivers/video/aty/radeon_monitor.c: In function `radeon_parse_montype_prop':
> drivers/video/aty/radeon_monitor.c:77: error: parse error before "else"

--- 25/drivers/video/aty/radeon_monitor.c~radeonfb-fix-warnings-about-uninitialized-variables-fix Thu Oct 7 14:32:40 2004
+++ 25-akpm/drivers/video/aty/radeon_monitor.c Thu Oct 7 14:32:59 2004
@@ -74,8 +74,7 @@ static int __devinit radeon_parse_montyp
printk(KERN_WARNING "radeonfb: Unknown OF display-type: %s\n",
pmt);
return MT_NONE;
- } else
- return MT_NONE;
+ }

for (i = 0; propnames[i] != NULL; ++i) {
pedid = (u8 *)get_property(dp, propnames[i], NULL);
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




Signed-off-by: Nick Piggin <nickpiggin@xxxxxxxxxxxx>


---

linux-2.6-npiggin/mm/vmscan.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)

diff -puN mm/vmscan.c~vm-fix-empty-zones mm/vmscan.c
--- linux-2.6/mm/vmscan.c~vm-fix-empty-zones 2004-10-08 12:44:14.000000000 +1000
+++ linux-2.6-npiggin/mm/vmscan.c 2004-10-08 14:28:04.000000000 +1000
@@ -851,6 +851,9 @@ shrink_caches(struct zone **zones, struc
for (i = 0; zones[i] != NULL; i++) {
struct zone *zone = zones[i];

+ if (zone->present_pages == 0)
+ continue;
+
zone->temp_priority = sc->priority;
if (zone->prev_priority > sc->priority)
zone->prev_priority = sc->priority;
@@ -1003,7 +1006,7 @@ static int balance_pgdat(pg_data_t *pgda
priority != DEF_PRIORITY)
continue;

- if (zone->free_pages <= zone->pages_high) {
+ if (zone->free_pages < zone->pages_high) {
end_zone = i;
goto scan;
}
@@ -1035,7 +1038,7 @@ scan:
continue;

if (nr_pages == 0) { /* Not software suspend */
- if (zone->free_pages <= zone->pages_high)
+ if (zone->free_pages < zone->pages_high)
all_zones_ok = 0;
}
zone->temp_priority = priority;
@@ -1142,7 +1145,7 @@ static int kswapd(void *p)
*/
void wakeup_kswapd(struct zone *zone)
{
- if (zone->free_pages > zone->pages_low)
+ if (zone->free_pages >= zone->pages_low)
return;
if (!waitqueue_active(&zone->zone_pgdat->kswapd_wait))
return;

_

From: Andi Kleen <ak@xxxxxx>

Check first before calling profile_pc() and doing other complicated checks
if profiling is enabled. This saves a few cycles in the profile tick and
protects the average user against potential bugs in profile_pc.

Signed-off-by: Andi Kleen <ak@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---

25-akpm/kernel/profile.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)

diff -puN kernel/profile.c~optimize-profile-path-slightly kernel/profile.c
--- 25/kernel/profile.c~optimize-profile-path-slightly Tue Oct 5 16:15:07 2004
+++ 25-akpm/kernel/profile.c Tue Oct 5 16:15:07 2004
@@ -381,12 +381,10 @@ static int __devinit profile_cpu_callbac
#define profile_flip_buffers() do { } while (0)
#define profile_discard_flip_buffers() do { } while (0)

-void profile_hit(int type, void *__pc)
+inline void profile_hit(int type, void *__pc)
{
unsigned long pc;

- if (prof_on != type || !prof_buffer)
- return;
pc = ((unsigned long)__pc - (unsigned long)_stext) >> prof_shift;
atomic_inc(&prof_buffer[min(pc, prof_len - 1)]);
}
@@ -396,6 +394,8 @@ void profile_tick(int type, struct pt_re
{
if (type == CPU_PROFILING)
profile_hook(regs);
+ if (prof_on != type || !prof_buffer)
+ return;
if (!user_mode(regs) && cpu_isset(smp_processor_id(), prof_cpu_mask))
profile_hit(type, (void *)profile_pc(regs));
}
_