From: "Randy.Dunlap" <rdunlap@xenotime.net>
To: jzb@aexorsyst.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: mem= causes oops (was Re: BIOS causes (exposes?) modprobe (load_module) kernel oops)
Date: Fri, 24 Mar 2006 16:32:37 -0800 [thread overview]
Message-ID: <20060324163237.5743bd3c.rdunlap@xenotime.net> (raw)
In-Reply-To: <200603240936.13178.jzb@aexorsyst.com>
On Fri, 24 Mar 2006 09:36:13 -0800 John Z. Bohach wrote:
> On Wednesday 22 March 2006 21:42, Randy.Dunlap wrote:
> > > So it seems that the page fault handler is somehow affected by something
> > > that the BIOS has/has not done, long after the system has booted and been
> > > running, with many page faults under its belt...now I've seen it all...or
> > > not.
> >
> > Sounds like we need to see complete boot logs from both BIOSen boots.
> > Can you do that?
> >
> > I'm just guessing that the memory maps are different, but who knows.
>
> I got something...
>
> Here's the symbolic dump. I've gotten it to break on the BIOS it
> did work on, by adding 512 MB RAM and bringing the total RAM to 1GB.
> In fact, it now breaks during boot-up, and doesn't even give me a chance
> to modprobe anything. However, the cmdline is what makes it break/work:
>
> Here it is:
>
> fails with cmdline:
>
> Kernel command line: ro root=/dev/sda1 rootdelay=10 mem=0x200M console=ttyS0,115200n8
>
> works with:
>
> Kernel command line: ro root=/dev/sda1 rootdelay=10 console=ttyS0,115200n8
>
> Note the "mem=" being the differentiator!
OK, that is memory map difference.
Can you test a more recent kernel to see if it has the same problem?
(like 2.6.16 or 2.6.16-git9)
> So I guess BIOS is off the hook. Here's a more interesting dump of the new failing
> case (with 1 GB RAM, and mem=0x200M on command line). BTW, note that
> mem=0x200M works fine as long as there's only 512 MB in the system.
>
> (And also note that the kernel was built without ACPI (or APM) support).
>
> INIT: version 2.85 booting
> INIT: Entering runlevel: 3
> Starting system log daemon...
> [ 39.333210] Unable to handle kernel paging request at virtual address b7c4e000
> [ 39.340642] printing eip:
> [ 39.343414] c013213c
> [ 39.345653] *pde = 017eb067
> [ 39.348516] *pte = 00000000
> [ 39.351379] Oops: 0002 [#1]
> [ 39.354239] SMP DEBUG_PAGEALLOC
> [ 39.357476] Modules linked in:
> [ 39.360615] CPU: 0
> [ 39.360616] EIP: 0060:[<c013213c>] Not tainted VLI
> [ 39.360618] EFLAGS: 00010006 (2.6.14.2)
> [ 39.373302] EIP is at free_block+0x41/0xbc
> [ 39.377501] eax: c1508d40 ebx: dffb6000 ecx: dffb6b80 edx: b7c4e000
> [ 39.384458] esi: c1508d40 edi: 00000000 ebp: c1505280 esp: c1567ef4
> [ 39.391413] ds: 007b es: 007b ss: 0068
> [ 39.395622] Process events/0 (pid: 4, threadinfo=c1566000 task=c151fa30)
> [ 39.402309] Stack: c150aa14 00000003 c150aa00 c1505280 c0132963 c1505280 c150aa14 00000003
> [ 39.410930] 00000000 00000000 c1508368 c1508d10 c1508d40 c1505280 c0132a0d c1505280
> [ 39.419568] c150aa00 00000000 00000000 00000002 c15052dc 00000246 c14063e0 c14063e4
> [ 39.428186] Call Trace:
> [ 39.430878] [<c0132963>] drain_array_locked+0x61/0x8c
> [ 39.436161] [<c0132a0d>] cache_reap+0x7f/0x18f
> [ 39.440823] [<c011f86a>] worker_thread+0x16f/0x1dd
> [ 39.445843] [<c013298e>] cache_reap+0x0/0x18f
> [ 39.450420] [<c0110299>] default_wake_function+0x0/0x12
> [ 39.455879] [<c0110299>] default_wake_function+0x0/0x12
> [ 39.461338] [<c011f6fb>] worker_thread+0x0/0x1dd
> [ 39.466173] [<c0122d23>] kthread+0x7c/0xa6
> [ 39.470472] [<c0122ca7>] kthread+0x0/0xa6
> [ 39.474681] [<c0100ea5>] kernel_thread_helper+0x5/0xb
> [ 39.479967] Code: 24 18 8b 15 50 ec 31 c0 8b 0c b8 8d 81 00 00 00 40 c1 e8 0c c1 e0 05 8b 5c 02 1c 8b 44 24 20 8b 53
> [ 39.499780]
>
> [42949372.960000] Linux version 2.6.14.2 (root@zeus) (gcc version 3.3.4) #1 SMP Fri Mar 24 08:27:33 PST 2006
> [42949372.960000] BIOS-provided physical RAM map:
> [42949372.960000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> [42949372.960000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> [42949372.960000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> [42949372.960000] BIOS-e820: 0000000000100000 - 000000003fe30000 (usable)
> [42949372.960000] BIOS-e820: 000000003fe30000 - 000000003fe40000 (ACPI data)
> [42949372.960000] BIOS-e820: 000000003fe40000 - 000000003ff00000 (ACPI NVS)
> [42949372.960000] BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)
> [42949372.960000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> [42949372.960000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> [42949372.960000] user-defined physical RAM map:
> [42949372.960000] user: 0000000000000000 - 000000000009fc00 (usable)
> [42949372.960000] user: 000000000009fc00 - 00000000000a0000 (reserved)
> [42949372.960000] user: 00000000000e0000 - 0000000000100000 (reserved)
> [42949372.960000] user: 0000000000100000 - 0000000020000000 (usable)
> [42949372.960000] 512MB LOWMEM available.
> [42949372.960000] found SMP MP-table at 000ff780
> ...
>
> Thanks for taking a look...
---
~Randy
next prev parent reply other threads:[~2006-03-25 0:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-22 4:05 BIOS causes (exposes?) modprobe (load_module) kernel oops John Z. Bohach
2006-03-22 9:06 ` Arjan van de Ven
2006-03-23 3:48 ` John Z. Bohach
2006-03-23 5:26 ` John Z. Bohach
2006-03-23 5:42 ` Randy.Dunlap
2006-03-24 17:36 ` mem= causes oops (was Re: BIOS causes (exposes?) modprobe (load_module) kernel oops) John Z. Bohach
2006-03-25 0:32 ` Randy.Dunlap [this message]
2006-03-25 18:36 ` John Z. Bohach
2006-03-25 18:50 ` mem= causes oops Jan Engelhardt
2006-03-26 17:41 ` Randy.Dunlap
2006-03-26 18:40 ` Jan Engelhardt
2006-04-05 19:07 ` mem= causes oops (was Re: BIOS causes (exposes?) modprobe (load_module) kernel oops) Randy.Dunlap
2006-04-06 16:18 ` John Z. Bohach
2006-04-06 20:18 ` [PATCH] mpparse: prevent table index out-of-bounds Randy.Dunlap
2006-04-07 5:34 ` John Z. Bohach
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=20060324163237.5743bd3c.rdunlap@xenotime.net \
--to=rdunlap@xenotime.net \
--cc=jzb@aexorsyst.com \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®