linux-kernel - Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 15 Oct 2015 14:12:57 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Huan Wang <alison.wang@...escale.com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Jin Jason <Jason.Jin@...escale.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Fabio Estevam <festevam@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"shawnguo@...nel.org" <shawnguo@...nel.org>
Subject: Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

On Thursday 15 October 2015 02:11:57 Huan Wang wrote:
> > On Wednesday 14 October 2015 10:18:47 Huan Wang wrote:
> > > > On Thursday 24 September 2015 07:27:10 Huan Wang wrote:
> > > > > > On Fri, Sep 18, 2015 at 4:38 AM, Huan Wang <alison.wang@...escale.com> wrote:
> > > > > Any suggestion? Thanks.
> > > >
> > > > Try enabling DEBUG_LL for your platform to get some debug output, if
> > > > you still don't get any helpful messages, try also inserting
> > > >
> > > >       printascii(__func__);
> > > >
> > > > statements in the early boot process to see how far you get before the hang.
> > > >
> > 
> [Alison Wang] ls1021a uses duart as the default serial port, not lpuart. So
> 8250/16550 serial driver is used. Let me explain my debug process in detail.

Ah, I see.

> When CONFIG_VMSPLIT_2G is used, I could boot up the whole kernel and get the
> print message " Booting Linux on physical CPU 0xf00" after "Starting kernel"
> as below.
> 
> Starting kernel ...
> [    0.000000] Booting Linux on physical CPU 0xf00
> .....
> 
> But when CONFIG_VMSPLIT_3G is used, I couldn't get print message " Booting Linux
> on physical CPU 0xf00". It only hangs at  "Starting kernel ...".
> 
> Moreover, I add some asm code in __turn_mmu_on to print some simple characters, and
> I could get the print characters when CONFIG_VMSPLIT_3G is used. So I guess there
> is something wrong with the page tables.

Ok. What I was suggesting above though was to try to pinpoint exactly
where it goes wrong. You have verified that it does not crash before
the page tables are enabled, but that is very early. You have also shown
that the kernel crashes before the point at which the 'Booting Linux on
physical CPU 0xf00' message is printed to the kernel, but that is *much*
later: setup_arch() calls parse_early_param(), which in turn sets up
early_console_write(). This means the 'Booting Linux on physical CPU 0xf00'
is still stuck in the log buffer and you may have crashed someone
inbetween.

If you can call printascii(), you can try to do that just after enabling
the page tables to see if that was the problem like you suspect, or otherwise
add more printascii() statements between __turn_mmu_on and parse_early_param()
to pinpoint the exact code that breaks.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/