From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [patch] 2.4.21-ia64-030702 arch/ia64/kernel/mca.c
Date: Fri, 08 Aug 2003 17:15:30 +0000 [thread overview]
Message-ID: <marc-linux-ia64-106036294510656@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105909779318784@msgid-missing>
On Thursday 07 August 2003 6:41 pm, Keith Owens wrote:
> On Thu, 7 Aug 2003 17:03:22 -0600,
> Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> >I don't see any conversion -- just the addition of several ia64_platform_is()
> >checks which I object to, especially when they change the behavior of
> >things that are not obviously platform-dependent. For example, I think
> >we should come up with a strategy for breaking SAL locks and clearing INIT
> >logs that everybody can agree on. Error handling is confusing enough
> >without making it platform-dependent.
>
> I agree, but so far only SN has any requirements for special processing
> in mca.c. Without a second platform, it is not clear what the coding
> model should be. I suggest you put in the sn2 changes and we review
> them when another platform has similar requirements.
I don't understand the changes well enough to be convinced that
they're SGI-specific. For instance:
> +#ifdef CONFIG_SMP
> + if (ia64_platform_is("sn2") && sal_lock.lock) {
> + udelay(500000);
> + sal_lock.lock = 0;
> + }
> +#endif
ia64_sal_get_state_info() uses SAL_CALL(), which acquires sal_lock.
So it seems that every platform would deadlock if we MCA in the
middle of a previous SAL call. Or is there something peculiar about
SGI firmware?
> + if (ia64_platform_is("sn2")) {
> + /* SN saves logs until next boot */
> + ;
> + } else {
> + /* Clear the INIT SAL logs now that they have been saved in the OS buffer */
> + ia64_sal_clear_state_info(SAL_INFO_TYPE_INIT);
> + }
You added back ia64_sal_clear_state_info() for all non-SGI platforms,
which I don't think we want.
> @@ -2076,6 +2141,11 @@ ia64_log_proc_dev_err_info_print (sal_lo
> + if (ia64_platform_is("sn2")) {
> + platform_plat_specific_err_print((int)slpi->header.len,
> + 0, (void*)slpi, prfunc);
> + return;
> + }
> @@ -2301,7 +2371,13 @@ ia64_log_print(int sal_info_type, prfunc
> - prfunc("+MCA INIT ERROR LOG (UNIMPLEMENTED)\n");
> + if (ia64_platform_is("sn2")) {
> + prfunc("+BEGIN HARDWARE ERROR STATE AT INIT\n");
> + platform_err = ia64_log_platform_info_print(IA64_LOG_CURR_BUFFER(sal_info_type), prfunc);
> + prfunc("+END HARDWARE ERROR STATE AT INIT\n");
> + } else {
> + prfunc("+MCA INIT ERROR LOG (UNIMPLEMENTED)\n");
> + }
Is there any reason not to do these on all platforms? The
"platform_plat_specific_err_print" looks a lot like a platform vector
anyway, so I don't see the point of another test.
Bjorn
next prev parent reply other threads:[~2003-08-08 17:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-24 8:59 [patch] 2.4.21-ia64-030702 arch/ia64/kernel/unwind.c Keith Owens
2003-07-29 23:21 ` Bjorn Helgaas
2003-07-29 23:26 ` Bjorn Helgaas
2003-08-07 23:03 ` [patch] 2.4.21-ia64-030702 arch/ia64/kernel/mca.c Bjorn Helgaas
2003-08-08 0:41 ` Keith Owens
2003-08-08 16:12 ` Bjorn Helgaas
2003-08-08 17:15 ` Bjorn Helgaas [this message]
2003-08-10 5:08 ` Keith Owens
2003-08-10 5:28 ` Alex Williamson
2003-08-11 23:01 ` Bjorn Helgaas
-- strict thread matches above, loose matches on Subject: below --
2003-07-19 6:25 Keith Owens
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=marc-linux-ia64-106036294510656@msgid-missing \
--to=bjorn.helgaas@hp.com \
--cc=linux-ia64@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.