All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 07 Aug 2003 23:03:22 +0000	[thread overview]
Message-ID: <marc-linux-ia64-106029765120419@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105909779318784@msgid-missing>

On Saturday 19 July 2003 12:25 am, Keith Owens wrote:
> Patches to arch/ia64/kernel/mca.c against 2.4.21-ia64-030702.
>
> Generic:
>   Issue a message to identify INIT/MCA records printed on the next boot.

ia64_log_print() already prints a note on the next boot if the log
contains saved records.  That note could be expanded, but the
logic around the new return values seems too complicated to me.

>   gp passed to SAL_VECTOR_OS_MCA should be a physical address.

I applied the bits to convert the GP passed to SAL_VECTOR_OS_MCA
to physical.  Actually, I copied the use of ia64_tpa() from 2.5, which
I believe should be safe since that's only done when mappings should
be valid.

>   Enable console logging for INIT/MCA messages.

I guess this refers to the SGI-specific addition to ia64_log_print().
I'm hoping to decrease, not increase, the error record decoding
code in the kernel.  Particularly for INIT, this is code that is
(1) platform-specific, and (2) only used after a non-recoverable
error.  It seems better to move such code to an off-line environment.

>   OEM data can be variable sized, do not use sizeof().

I don't quite understand this one.  Don't these:

> -				      (int)sizeof(sal_log_plat_specific_err_info_t) - 1,
> +				      ((char*)psei->oem_data - (char*)psei),

compute the same value?  I see that OEM data can be of variable
size (and we use "u8 oem_data[1]" as a placeholder), but isn't this
expression just computing the size of the fixed part of it?

>   Convert #ifdef CONFIG_SGI_SN2 to ia64_platform_is("sn2") to allow the
>   building of generic kernels.

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.

Bjorn


  parent reply	other threads:[~2003-08-07 23:03 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 ` Bjorn Helgaas [this message]
2003-08-08  0:41 ` [patch] 2.4.21-ia64-030702 arch/ia64/kernel/mca.c Keith Owens
2003-08-08 16:12 ` Bjorn Helgaas
2003-08-08 17:15 ` Bjorn Helgaas
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-106029765120419@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.