linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joshua Kinard <kumba@gentoo.org>
To: Linux/MIPS <linux-mips@linux-mips.org>
Subject: ARCS can't load CONFIG_DEBUG_LOCK_ALLOC kernel
Date: Wed, 15 Mar 2017 16:11:42 -0400	[thread overview]
Message-ID: <8b2d7473-ba4d-f2c9-27e7-b1a30b95c4f8@gentoo.org> (raw)

I've reported in the past that turning on CONFIG_DEBUG_LOCK_ALLOC produces a
kernel that can't boot on several SGI platforms.  It turns out that using
arcload (Stan's bootloader originally written for IP30), I can get some
debugging out on why.  I am still puzzled, but maybe this information can be
interpreted by someone else into something meaningful?

All addresses printed out of arcload are physical address.

ARCS Memory Map as printed by some debugging I added to the arcload binary:

0x00000000 - 0x00001000 ExceptionBlock
0x00001000 - 0x00002000 SystemParameterBlock
0x00002000 - 0x00004000 FirmwarePermanent
0x20004000 - 0x20f00000 FreeMemory***
0x20f00000 - 0x21000000 FirmwareTemporary
0x21000000 - 0x5fff0000 FreeMemory
0x5fff0000 - 0x5ffff000 LoadedProgram
0x5ffff000 - 0x60000000 FreeMemory
0x60000000 - 0xa0000000 FirmwarePermanent

The ***'ed FreeMemory segment is where the kernel is supposed to load.  Here's
the debugging for a kernel WITHOUT CONFIG_DEBUG_LOCK_ALLOC enabled (4102norm):

ELF Start: 0x20004000
Elf End  : 0x20a6fdd0
Size     : 0x00a6bdd0 (~10MB?)

# ls -l 4102norm
-rwxr-xr-x 1 root root 28M Mar 15 15:12 4102norm*


And the debugging kernel compiled with CONFIG_DEBUG_LOCK_ALLOC=y (no other
config changes from above):

ELF Start: 0x20004000
Elf End  : 0x2148bf80
Size     : 0x01487f80 (~20MB?)

# ls -l 4102dbg
-rwxr-xr-x 1 root root 29M Mar 15 15:21 4102dbg*


I am only using the traditional "vmlinux" make target, so there shouldn't be
any compression involved here.  Yet, it looks like, according to ARCS anyways,
that CONFIG_DEBUG_LOCK_ALLOC is adding an additional 10MB of "something", yet
the vmlinux file only grows by roughly 1MB.

If I examine both kernels with readelf and dump the program headers, I can see
these two sizes reflected under "MemSiz":

# mips64-unknown-linux-gnu-readelf -l 4102norm

Elf file type is EXEC (Executable file)
Entry point 0xa800000020700450
There are 2 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000004000 0xa800000020004000 0xa800000020004000
                 0x00000000009a5030 0x0000000000a6bdd0  RWE    10000
  NOTE           0x0000000000714bb0 0xa800000020714bb0 0xa800000020714bb0
                 0x0000000000000024 0x0000000000000024  R      4

# mips64-unknown-linux-gnu-readelf -l 4102dbg

Elf file type is EXEC (Executable file)
Entry point 0xa800000020749c80
There are 2 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000004000 0xa800000020004000 0xa800000020004000
                 0x0000000000a05850 0x0000000001487f80  RWE    10000
  NOTE           0x000000000075e330 0xa80000002075e330 0xa80000002075e330
                 0x0000000000000024 0x0000000000000024  R      4


So I'm not quite certain why ARCS or arcload dislike kernels with
CONFIG_DEBUG_LOCK_ALLOC=y.  This issue is known about on at least IP27 and IP30
platforms for the past few years, and it's been quite a hindrance in doing any
debugging of locks.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

             reply	other threads:[~2017-03-15 20:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-15 20:11 Joshua Kinard [this message]
2017-03-16  3:50 ` ARCS can't load CONFIG_DEBUG_LOCK_ALLOC kernel Joshua Kinard
2017-03-16 14:09   ` Ralf Baechle
2017-03-16 17:50     ` Joshua Kinard
2017-03-16 19:06       ` Ralf Baechle
2017-03-16 20:02         ` Joshua Kinard
2017-03-16 20:50           ` Ralf Baechle
2017-03-17  3:01             ` Joshua Kinard
2017-03-18 23:42               ` Joshua Kinard
2017-03-19  7:23                 ` Joshua Kinard
2017-03-19  8:55                   ` Ralf Baechle
2017-03-21 21:52                     ` Joshua Kinard

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=8b2d7473-ba4d-f2c9-27e7-b1a30b95c4f8@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=linux-mips@linux-mips.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;
as well as URLs for NNTP newsgroup(s).