From: Paul Mackerras <paulus@samba.org>
To: linas@austin.ibm.com
Cc: linuxppc64-dev@lists.linuxppc.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [2.6] PPC64: log firmware errors during boot.
Date: Wed, 30 Jun 2004 20:55:15 +1000 [thread overview]
Message-ID: <16610.39955.554139.858593@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <20040629191046.Q21634@forte.austin.ibm.com>
Linas,
> Firmware can report errors at any time, and not atypically during boot.
> However, these reports were being discarded until th rtasd comes up,
> which occurs fairly late in the boot cycle. As a result, firmware
> errors during boot were being silently ignored.
As far as I can see the main change is in log_rtas_len, which is
called from pSeries_log_error, which is called from do_event_scan and
rtasd(), and do_event_scan is only called from rtasd(). And
get_eventscan_parms() is already called at the beginning of rtasd().
So I don't see the point of the get_eventscan_parms call in
log_rtas_len. The other change is also in pSeries_log_error.
What am I missing?
> This patch at least gets them printk'ed so that at least they show
> up in boot.msg/syslog. There are two other logging mechanisms,
> nvram and rtas, that I didn't touch because I don't understand
> the reprecussions. In particular, nvram logging isn't enabled
> until late in the boot ... but what's the point of nvram logging
> if not to catch messages that occured very early in boot ??
Indeed.
As for printk'ing the errors, it is annoying and it seems of somewhat
dubious benefit to me, given that it is just incomprehensible hex
numbers that can go on and on. There has to be a better way. Putting
it in nvram seems like a better option to me. I don't know of any
reason why we can't use nvram quite early on.
Paul.
next prev parent reply other threads:[~2004-06-30 11:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-30 0:10 linas
2004-06-30 10:55 ` Paul Mackerras [this message]
2004-07-01 21:06 ` linas
2004-07-02 5:36 ` Greg KH
2004-07-02 10:44 ` Paul Mackerras
2004-07-02 14:15 ` Hollis Blanchard
2004-07-02 16:18 ` Nathan Fontenot
2004-07-02 17:29 ` Hollis Blanchard
2004-07-02 18:13 ` linas
2004-07-02 18:27 ` Greg KH
2004-07-02 18:55 ` Dave Hansen
2004-07-02 19:44 ` Greg KH
2004-07-06 13:24 ` Jake Moilanen
2004-07-06 13:41 ` Jake Moilanen
2004-07-08 16:03 ` linas
2004-07-08 17:55 ` Jake Moilanen
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=16610.39955.554139.858593@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=linas@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@lists.linuxppc.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
all inboxes | Powered by JetHome®