All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John Z. Bohach" <jzb@aexorsyst.com>
To: linux-kernel@vger.kernel.org
Subject: mem= causes oops (was Re: BIOS causes (exposes?) modprobe (load_module) kernel oops)
Date: Fri, 24 Mar 2006 09:36:13 -0800	[thread overview]
Message-ID: <200603240936.13178.jzb@aexorsyst.com> (raw)
In-Reply-To: <20060322214257.1ef798e5.rdunlap@xenotime.net>

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!

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...


  reply	other threads:[~2006-03-24 17:36 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         ` John Z. Bohach [this message]
2006-03-25  0:32           ` mem= causes oops (was Re: BIOS causes (exposes?) modprobe (load_module) kernel oops) Randy.Dunlap
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=200603240936.13178.jzb@aexorsyst.com \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.