From: Paul Mundt <lethal@linux-sh.org>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: Robin Getz <rgetz@blackfin.uclinux.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, Greg Ungerer <gerg@snapgear.com>,
Russell King <rmk@arm.linux.org.uk>,
Tim Bird <tim.bird@am.sony.com>,
bryan.wu@analog.com
Subject: Re: early_printk accessing __log_buf
Date: Mon, 23 Jul 2007 09:14:34 +0900 [thread overview]
Message-ID: <20070723001434.GB16374@linux-sh.org> (raw)
In-Reply-To: <8bd0f97a0707221650r3bab822fq2d457d19eba1c8eb@mail.gmail.com>
On Sun, Jul 22, 2007 at 07:50:47PM -0400, Mike Frysinger wrote:
> On 7/18/07, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> >On Wed 18 Jul 2007 20:26, Andrew Morton pondered:
> >> Robin Getz wrote:
> >> > [need to access _log_buf from external for early debugging code]
> >> >
> >> > Something simple like - early_copy_log_buff(void *dest, size_t n)
> >> >
> >> > copies n bytes from log_buf to memory area dest. Returns number of
> >> > bytes that could not be copied. Can find out how many bytes are in
> >> > the log_buff by calling with zero size.
> >>
> >> When I was at $EARLIER_EMPLOYER, we had code in there to copy the last
> >> kilobyte-odd of the log buffer into flash when the box oopsed.
> >>
> >
> >Hmm - I think that if you call with NULL dest, and have it advance the
> >pointer, you could do the same thing with something like:
> >
> > /* see how many bytes are in the buff */
> > length = early_copy_log_buff(NULL, NULL);
> > /* advance the pointer, so we only copy the last 1k */
> > if (length >= 1024 )
> > left = early_copy_log_buff(NULL, length - 1024);
> > /* copy to temp buffer, to save to flash */
> > early_copy_log_buff(buff, 1024);
> > save_buff_to_flash(buff);
> >
> >That way - you can put this in the standard places for failure, and still
> >have
> >only one function polluting printk.c (Although if you want to use it for
> >failure trapping - it's up for "normal" run time use, and doesn't go into
> >__init.
> >
> >> Probably there are others, but they'll mainly be in the consumer/embedded
> >> area, and those sorts of engineers don't read this mailing list much.
> >
> >Adding a few more 'embedded' folks - who might have some thoughts/opinions.
>
> i think the attached two functions account for what Robin and Andrew
> were thinking ...
I don't have any strong opinions on this one way or the other. We've been
playing more with kexec for a recovery mode, that coupled with the crash
dumps gives us most of the state we need. We would probably make use of
this printk log access functionality if it were added, though, depending
on customer environments.
next prev parent reply other threads:[~2007-07-23 0:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-18 21:56 early_printk accessing __log_buf Robin Getz
2007-07-18 22:16 ` Andrew Morton
2007-07-18 23:39 ` Robin Getz
2007-07-18 23:53 ` Mike Frysinger
2007-07-19 3:37 ` Robin Getz
2007-07-19 3:47 ` Andrew Morton
2007-07-19 0:26 ` Andrew Morton
2007-07-19 2:26 ` Stephane Couture
2007-07-19 3:58 ` Robin Getz
2007-07-22 23:50 ` Mike Frysinger
2007-07-23 0:14 ` Paul Mundt [this message]
2007-07-23 18:19 ` Robin Getz
2007-07-23 20:15 ` Andrew Morton
2007-07-23 20:54 ` Mike Frysinger
2007-07-23 21:05 ` Andrew Morton
2007-07-23 22:10 ` Mike Frysinger
2007-07-23 22:15 ` Robin Getz
2007-07-23 22:34 ` Andrew Morton
2007-07-24 17:50 ` Robin Getz
2007-07-24 18:12 ` Andrew Morton
2007-07-24 20:12 ` Robin Getz
2007-07-24 21:30 ` Andrew Morton
2007-07-31 7:47 ` Mike Frysinger
2007-07-31 7:59 ` Bryan Wu
2007-07-31 8:11 ` Mike Frysinger
2007-07-31 18:36 ` Andrew Morton
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=20070723001434.GB16374@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=akpm@linux-foundation.org \
--cc=bryan.wu@analog.com \
--cc=gerg@snapgear.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rgetz@blackfin.uclinux.org \
--cc=rmk@arm.linux.org.uk \
--cc=tim.bird@am.sony.com \
--cc=vapier.adi@gmail.com \
/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