public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Dave Airlie <airlied@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>
Subject: Re: Can not boot with CONFIG_NO_BOOTMEM=y on i686
Date: Fri, 26 Mar 2010 01:10:43 -0700	[thread overview]
Message-ID: <4BAC6C03.3030801@kernel.org> (raw)
In-Reply-To: <20100324090438.GA7512@dhcp-lab-161.englab.brq.redhat.com>

On 03/24/2010 02:04 AM, Stanislaw Gruszka wrote:
> On Tue, Mar 23, 2010 at 09:06:00PM -0700, Yinghai Lu wrote:
>> On 03/23/2010 04:35 AM, Stanislaw Gruszka wrote:
>>> On Sat, Mar 20, 2010 at 11:26:06AM -0700, Yinghai Lu wrote:
>>>>> After update to 2.6.34-rc1, I was experimented by strange oopses during
>>>>> boot, what looked like memory corruption. Bisection shows that first bad
>>>>> commit is 59be5a8e8ce765cf739ec7f07176219972de7481 ("x86: Make 32bit
>>>>> support NO_BOOTMEM"). When I disable CONFIG_NO_BOOTMEM I'm able to start
>>>>> system. Not sure what info is need to track down this issue, so please
>>>>> let me know.
>>>>
>>>> can you check patch
>>>>
>>>> https://patchwork.kernel.org/patch/87081/
>>>
>>> Patch helps somehow. Instead of many random oopses, now I have one and
>>> the same oops, here is photo:
>>> http://people.redhat.com/sgruszka/20100322_001.jpg
>>
>> how does e820 look like?
> 
> dmesg below, I hope everything you asked for is here:
> 
> Linux version 2.6.34-rc1 (stasiu@yellow) (gcc version 4.4.2 20091222 (Red Hat 4.4.2-20) (GCC) ) #26 SMP Tue Mar 23 11:31:22 CET 2010
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 0000000000096400 (usable)
>  BIOS-e820: 0000000000096400 - 00000000000a0000 (reserved)
>  BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
>  BIOS-e820: 0000000000100000 - 00000000cffc2840 (usable)
>  BIOS-e820: 00000000cffc2840 - 00000000d0000000 (reserved)
>  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
>  BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
...
> initial memory mapped : 0 - 01000000
> found SMP MP-table at [c00fe700] fe700
> init_memory_mapping: 0000000000000000-00000000373fe000
>  0000000000 - 0000400000 page 4k
>  0000400000 - 0037000000 page 2M
>  0037000000 - 00373fe000 page 4k
> kernel direct mapping tables up to 373fe000 @ 7000-d000
> RAMDISK: 373b8000 - 37fef224
> Allocated new RAMDISK: 00b2f000 - 01766224
> Move RAMDISK from 00000000373b8000 - 0000000037fef223 to 00b2f000 - 01766223
> Reserving 256MB of memory at 32MB for crashkernel (System RAM: 3327MB)

Please check if this one helps

Thanks

Yinghai

---
[PATCH] x86: Make sure free_init_pages() free pages in boundary

When CONFIG_NO_BOOTMEM, it could use memory more efficient, or more compact.

Example is:
Allocated new RAMDISK: 00ec2000 - 0248ce57
Move RAMDISK from 000000002ea04000 - 000000002ffcee56 to 00ec2000 - 0248ce56

The new RAMDISK's end is not page aligned.
Last page could use shared with other user.

When free_init_pages are called for initrd or .init, the page could be freed
could have chance to corrupt other data.

code segment in free_init_pages()
|        for (; addr < end; addr += PAGE_SIZE) {
|                ClearPageReserved(virt_to_page(addr));
|                init_page_count(virt_to_page(addr));
|                memset((void *)(addr & ~(PAGE_SIZE-1)),
|                        POISON_FREE_INITMEM, PAGE_SIZE);
|                free_page(addr);
|                totalram_pages++;
|        }
last half page could be used as one whole free page.

Try to make the boundaries to be page aligned.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/mm/init.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6/arch/x86/mm/init.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/init.c
+++ linux-2.6/arch/x86/mm/init.c
@@ -334,6 +334,10 @@ void free_init_pages(char *what, unsigne
 {
 	unsigned long addr = begin;
 
+	/* Make sure boundaries are page aligned */
+	addr = PFN_UP(addr) << PAGE_SHIFT;
+	end = PFN_DOWN(end) << PAGE_SHIFT;
+
 	if (addr >= end)
 		return;
 

  reply	other threads:[~2010-03-26  8:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-19 13:12 Can not boot with CONFIG_NO_BOOTMEM=y on i686 Stanislaw Gruszka
2010-03-20 18:26 ` Yinghai Lu
2010-03-23 11:35   ` Stanislaw Gruszka
2010-03-24  4:06     ` Yinghai Lu
2010-03-24  9:04       ` Stanislaw Gruszka
2010-03-26  8:10         ` Yinghai Lu [this message]
2010-03-26 12:10           ` Stanislaw Gruszka
2010-03-26 12:45           ` Johannes Weiner
2010-03-26 18:18             ` Yinghai Lu
2010-03-23  1:44 ` Dave Airlie
2010-03-29 21:05   ` H. Peter Anvin

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=4BAC6C03.3030801@kernel.org \
    --to=yinghai@kernel.org \
    --cc=airlied@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sgruszka@redhat.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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