From: David Miller <davem@davemloft.net>
To: mroos@linux.ee
Cc: iamjoonsoo.kim@lge.com, linux-kernel@vger.kernel.org,
cl@linux.com, penberg@kernel.org, rientjes@google.com,
akpm@linux-foundation.org, linux-mm@kvack.org,
sparclinux@vger.kernel.org
Subject: Re: unaligned accesses in SLAB etc.
Date: Wed, 15 Oct 2014 23:11:54 -0400 (EDT) [thread overview]
Message-ID: <20141015.231154.1804074463934900124.davem@davemloft.net> (raw)
In-Reply-To: <alpine.LRH.2.11.1410152310080.11974@adalberg.ut.ee>
From: Meelis Roos <mroos@linux.ee>
Date: Wed, 15 Oct 2014 23:11:34 +0300 (EEST)
>> >> The gcc-4.9 case is interesting, are you saying that a gcc-4.9 compiled
>> >> kernel works fine on other systems?
>> >
>> > Yes, all USII based systems work fine with Debian gcc-4.9, as does
>> > T2000. Of USIII* systems, V210 and V440 exhibit the boot hang with
>> > gcc-4.9 and V480 crashes wit FATAL exception during boot that is
>> > probably earlier than the gcc boot hang so I do not know about V480 and
>> > gcc-4.9. V240 not tested because of fan failures, V245 is in the queue
>> > for setup but not tested so far.
>>
>> Ok, on the V210/V440 can you boot with "-p" on the kernel boot command
>> line and post the log? Let's start by seeing how far it gets, maybe
>> we can figure out roughly where it dies.
>
> http://www.spinics.net/lists/sparclinux/msg12238.html and
> http://www.spinics.net/lists/sparclinux/msg12468.html are my relevant
> posts about it. Should I get something more? It would be easy because of
> ALOM.
Less information than I had hoped :-/
I thought it was hanging "during boot" meaning before we try to
execute userspace. When in fact it seems to die exactly when we start
running the init process.
Wrt. disassembly of fault_in_user_windows(), that's not likely the
cause because if it were being miscompiled it would equally not work
on the other systems.
Something in the UltraSPARC-III specific code paths is going wrong
(either it is miscompiled, or the code makes an assumption that isn't
valid which has happened in the past).
Do you happen to have both gcc-4.9 and a previously working compiler
on these systems? If you do, we can build a kernel with gcc-4.9 and
then selectively compile certain failes with the older working
compiler to narrow down what compiles into something non-working with
gcc-4.9
I would start with the following files:
arch/sparc/mm/init_64.c
arch/sparc/mm/tlb.c
arch/sparc/mm/tsb.c
arch/sparc/mm/fault_64.c
And failing that, go for various files under arch/sparc/kernel/ such as:
arch/sparc/kernel/process_64.c
arch/sparc/kernel/smp_64.c
arch/sparc/kernel/sys_sparc_64.c
arch/sparc/kernel/sys_sparc32.c
arch/sparc/kernel/traps_64.c
Hopefully, this should be a simply matter of doing a complete build
with gcc-4.9, then removing the object file we want to selectively
build with the older compiler and then going:
make CC="gcc-4.6" arch/sparc/mm/init_64.o
then relinking with plain 'make'.
If the build system rebuilds the object file on you when you try
to relink the final kernel image, we'll have to do some of this
by hand to make the test.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-10-16 3:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-12 2:15 David Miller
2014-10-12 17:20 ` David Miller
2014-10-13 20:22 ` mroos
2014-10-13 23:52 ` Joonsoo Kim
2014-10-14 0:04 ` David Miller
2014-10-14 0:14 ` Joonsoo Kim
2014-10-14 21:19 ` mroos
2014-10-14 21:32 ` David Miller
2014-10-15 8:04 ` Meelis Roos
2014-10-15 18:36 ` David Miller
2014-10-15 20:11 ` Meelis Roos
2014-10-16 3:11 ` David Miller [this message]
2014-10-16 7:22 ` Meelis Roos
2014-10-16 20:11 ` Meelis Roos
2014-10-16 20:18 ` David Miller
2014-10-16 7:02 ` Meelis Roos
2014-10-16 20:07 ` David Miller
2014-10-16 20:16 ` Meelis Roos
2014-10-16 20:20 ` David Miller
2014-10-16 20:50 ` David Miller
2014-10-17 11:12 ` Meelis Roos
2014-10-18 17:59 ` David Miller
2014-10-18 18:23 ` David Miller
2014-10-19 12:31 ` Meelis Roos
2014-10-19 17:12 ` Meelis Roos
2014-10-19 17:18 ` David Miller
2014-10-19 15:32 ` Sam Ravnborg
2014-10-19 17:27 ` David Miller
2014-10-19 19:55 ` Sam Ravnborg
2014-10-16 20:20 ` Meelis Roos
2014-10-16 20:40 ` Meelis Roos
2014-10-12 17:22 ` Joonsoo Kim
2014-10-12 17:30 ` David Miller
2014-10-12 17:43 ` Joonsoo Kim
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=20141015.231154.1804074463934900124.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mroos@linux.ee \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=sparclinux@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