Re: unaligned accesses in SLAB etc.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Meelis Roos <mroos@xxxxxxxx>
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@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]