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