From: Andi Kleen <ak@suse.de>
To: vgoyal@in.ibm.com
Cc: Steve Fox <drfickle@us.ibm.com>,
Badari Pulavarty <pbadari@us.ibm.com>,
Martin Bligh <mbligh@mbligh.org>, Andrew Morton <akpm@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org, kmannth@us.ibm.com,
Andy Whitcroft <apw@shadowen.org>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: 2.6.18-mm2 boot failure on x86-64
Date: Thu, 5 Oct 2006 21:08:55 +0200 [thread overview]
Message-ID: <200610052108.55208.ak@suse.de> (raw)
In-Reply-To: <20061005185217.GF20551@in.ibm.com>
On Thursday 05 October 2006 20:52, Vivek Goyal wrote:
> On Thu, Oct 05, 2006 at 08:27:02PM +0200, Andi Kleen wrote:
> > On Thursday 05 October 2006 19:57, Steve Fox wrote:
> > > On Thu, 2006-10-05 at 17:40 +0200, Andi Kleen wrote:
> > >
> > > > Please don't snip the Code: line. It is fairly important.
> > >
> > > Sorry about that. The remote console I was using appears to overwrite
> > > some text after I force the reboot. Here's a clean one.
> > >
> > > global ffffffffffffffff
> >
> > Ok that definitely shouldn't be in there.
> >
> > I guess we need to track when it gets corrupted. Can you send the full
> > boot log with this patch applied?
> >
>
> Just recalled one more observation about the problem when keith had
> reported it last. If I just move .bss before .data_nosave instead
> of it being at the end, keith's problem had disappeared.
Yes, that could well be that it's something in the new bootmap
management. Steve's box failed at
Using ACPI (MADT) for SMP configuration information
Nosave address range: 000000000009a000 - 000000000009b000
Nosave address range: 000000000009b000 - 00000000000a0000
Nosave address range: 00000000000a0000 - 00000000000e0000
Nosave address range: 00000000000e0000 - 0000000000100000
Nosave address range: 00000000bff76000 - 00000000bff77000
Nosave address range: 00000000bff77000 - 00000000bff98000
Nosave address range: 00000000bff98000 - 00000000bff99000
Nosave address range: 00000000bff99000 - 00000000c0000000
Nosave address range: 00000000c0000000 - 00000000fec00000
Nosave address range: 00000000fec00000 - 0000000100000000
Allocating PCI resources starting at c4000000 (gap: c0000000:3ec00000)
afinfo corrupted at init/main.c:512
which is directly after that code does lots of stuff.
Mel might want to take a look (and perhaps
also cut down a little on the ugly printks ...)
BTW I found one of my test systems too now which does a lot of:
I'm about to leave for vacation so i won't have time to track it down
any time soon. But here is it for reference.
-Andi
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 8000000
Bad page state in process 'swapper'
page:ffff810003ee5480 flags:0x0000000000000000 mapping:0000000000000000 mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[<ffffffff8020ac84>] show_trace+0x34/0x47
[<ffffffff8020aca9>] dump_stack+0x12/0x17
[<ffffffff802586a7>] bad_page+0x57/0x81
[<ffffffff80258791>] __free_pages_ok+0x64/0x247
[<ffffffff807cca72>] free_all_bootmem_core+0xcc/0x1a9
[<ffffffff807ca08b>] numa_free_all_bootmem+0x3b/0x77
[<ffffffff807c915e>] mem_init+0x44/0x186
[<ffffffff807bc5f0>] start_kernel+0x17b/0x207
[<ffffffff807bc168>] _sinittext+0x168/0x16c
Bad page state in process 'swapper'
page:ffff810003ee54b8 flags:0x0000000000000000 mapping:0000000000000000 mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[<ffffffff8020ac84>] show_trace+0x34/0x47
[<ffffffff8020aca9>] dump_stack+0x12/0x17
[<ffffffff802586a7>] bad_page+0x57/0x81
[<ffffffff80258791>] __free_pages_ok+0x64/0x247
[<ffffffff807cca72>] free_all_bootmem_core+0xcc/0x1a9
[<ffffffff807ca08b>] numa_free_all_bootmem+0x3b/0x77
[<ffffffff807c915e>] mem_init+0x44/0x186
[<ffffffff807bc5f0>] start_kernel+0x17b/0x207
[<ffffffff807bc168>] _sinittext+0x168/0x16c
... lots more of those ...
next prev parent reply other threads:[~2006-10-05 19:09 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060928014623.ccc9b885.akpm@osdl.org>
[not found] ` <efh217$8au$1@sea.gmane.org>
2006-09-28 21:01 ` 2.6.18-mm2 Andrew Morton
2006-09-28 22:45 ` 2.6.18-mm2 Stephen Hemminger
2006-10-04 13:42 ` 2.6.18-mm2 boot failure on x86-64 Steve Fox
2006-10-04 15:45 ` Andrew Morton
2006-10-04 15:55 ` Vivek Goyal
2006-10-04 15:56 ` Andi Kleen
2006-10-05 1:57 ` Keith Mannthey
2006-10-04 16:41 ` Steve Fox
2006-10-05 0:06 ` Andrew Morton
2006-10-05 0:51 ` Vivek Goyal
2006-10-05 0:57 ` Andi Kleen
2006-10-05 1:08 ` Martin Bligh
2006-10-05 2:05 ` Keith Mannthey
2006-10-05 14:53 ` Steve Fox
2006-10-05 15:12 ` Badari Pulavarty
2006-10-05 15:32 ` Steve Fox
2006-10-05 15:40 ` Andi Kleen
2006-10-05 17:57 ` Steve Fox
2006-10-05 18:27 ` Andi Kleen
2006-10-05 18:51 ` Steve Fox
2006-10-05 19:05 ` Andi Kleen
2006-10-05 20:42 ` Steve Fox
2006-10-05 20:50 ` Andi Kleen
2006-10-06 2:23 ` Steve Fox
2006-10-06 14:33 ` Mel Gorman
2006-10-06 15:36 ` Vivek Goyal
2006-10-06 17:11 ` Mel Gorman
2006-10-06 17:34 ` Vivek Goyal
2006-10-06 17:59 ` Vivek Goyal
2006-10-06 18:03 ` Steve Fox
2006-10-06 20:04 ` Vivek Goyal
2006-10-09 9:53 ` Mel Gorman
2006-10-16 18:16 ` Vivek Goyal
2006-10-16 23:58 ` Andrew Morton
2006-10-17 12:18 ` Adrian Bunk
2006-10-17 17:32 ` Mel Gorman
2006-10-05 18:52 ` Vivek Goyal
2006-10-05 19:08 ` Andi Kleen [this message]
2006-10-05 20:25 ` Steve Fox
2006-10-05 20:39 ` Mel Gorman
2006-10-05 20:51 ` Andi Kleen
2006-10-05 23:14 ` 2.6.18-mm2 boot failure on x86-64 II Andi Kleen
2006-10-05 23:32 ` keith mannthey
2006-10-05 23:35 ` Andi Kleen
2006-10-05 23:58 ` keith mannthey
2006-10-06 0:02 ` Badari Pulavarty
2006-10-06 0:12 ` Andrew Morton
[not found] ` <200609290319.k8T3JOwS005455@turing-police.cc.vt.edu>
[not found] ` <20060928202931.dc324339.akpm@osdl.org>
[not found] ` <200609291519.k8TFJfvw004256@turing-police.cc.vt.edu>
[not found] ` <20060929124558.33ef6c75.akpm@osdl.org>
2006-09-30 0:01 ` 2.6.18-mm2 - oops in cache_alloc_refill() Valdis.Kletnieks
2006-09-30 1:20 ` Andrew Morton
2006-09-30 1:33 ` Jean Tourrilhes
2006-09-30 3:31 ` Valdis.Kletnieks
2006-09-30 7:50 ` Valdis.Kletnieks
2006-09-30 8:33 ` Andrew Morton
2006-09-30 1:40 ` Jean Tourrilhes
2006-09-30 3:31 ` Valdis.Kletnieks
2006-09-30 1:57 ` Makefile for linux modules x z
2006-09-30 8:55 ` Sam Ravnborg
2006-09-30 1:59 ` x z
2006-10-02 17:52 ` 2.6.18-mm2 - oops in cache_alloc_refill() Jean Tourrilhes
2006-10-02 19:57 ` Valdis.Kletnieks
2006-10-03 15:58 ` Samuel Tardieu
2006-10-03 16:34 ` Jean Tourrilhes
2006-10-03 16:45 ` Samuel Tardieu
2006-10-03 17:07 ` Jean Tourrilhes
2006-10-05 22:37 ` Pavel Roskin
2006-10-05 22:42 ` Jean Tourrilhes
[not found] ` <20060930133706.GA3291@melchior.yamamaya.is-a-geek.org>
2006-09-30 19:53 ` 2.6.18-mm2 Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200610052108.55208.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=drfickle@us.ibm.com \
--cc=kmannth@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@mbligh.org \
--cc=mel@csn.ul.ie \
--cc=netdev@vger.kernel.org \
--cc=pbadari@us.ibm.com \
--cc=vgoyal@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).