Date: Thu, 12 Aug 2010 14:36:59 -0400
From: Nick Bowler <nbowler@elliptictech.com>
To: walt <w41ter@gmail.com>
Cc: linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Steven Rostedt <rostedt@goodmis>
Subject: Re: [BISECTED] Removing BKL causes stack trace during early bootup
Message-ID: <20100812183659.GA24008@elliptictech.com>
Mail-Followup-To: walt <w41ter@gmail.com>, linux-kernel@vger.kernel.org,
	Arnd Bergmann <arnd@arndb.de>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Steven Rostedt <rostedt@goodmis>
References: <4C6438BF.9070608@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C6438BF.9070608@gmail.com>
Organization: Elliptic Technologies Inc.
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1142
Lines: 25

On 2010-08-12 11:09 -0700, walt wrote:
> The trace whizzes by so fast that I can't read it, and the trace doesn't appear
> in any of the logs.  Is there a way to capture such a trace, like maybe changing
> it to a fatal error?

There are a couple options.  First, the message _should_ appear in
'dmesg' output since you say the system boots: however if there was a
lot of _other_ output it is possible that it got pushed off the end of
the log.  In this case, the easiest way to get it is to simply increase
the log buffer size, CONFIG_LOG_BUF_SHIFT, found under 'General Setup'
in menuconfig.

Another option is to use a serial console or netconsole to capture the
output on another machine.

Yet another option is to use the kernel command line option, boot_delay,
which lets you slow down the printing of messages at boot.

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/