public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <iod00d@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC] How drivers notice a MCA on I/O read? [1/3]
Date: Wed, 19 Nov 2003 16:45:07 +0000	[thread overview]
Message-ID: <marc-linux-ia64-106926030617030@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-106915044130197@msgid-missing>

On Tue, Nov 18, 2003 at 07:11:20PM +0900, Hidetoshi Seto wrote:
...
> I want to convey the error to the offending driver, and want to enable the
> driver to retry failed read.

Hidetoshi,
Did you mean the driver literally "retry failed read" or did you mean
the driver could "recover" (ie return errors for pending IO requests)?

> So, I think about a readb_check function that has checking ability enable
> it return error value if MCA occur on read.
> Drivers could use readb_check instead of usual readb, and could diagnosis
> whether a retry be required or not, by the return value of readb_check.

I see little value in a simple retry. If the board is failing
(even transient failures) badly enough to cause MCA, it's probably
better to clean up driver state and stop accepting IO requests.

> To realize this, I consider following two plans:
> 
>  - readb_check on driver (with Notifier)
>     Outline:
>     - Platform specific MCA handler has a Notifier as hook point.
>     - Driver may register a hook function to the Notifier.
>     - Notifier calls over registered functions when MCA is signaled.
>     - Called hook function checks address of error, and if the error seems
>       to be concerned with the parent driver, ups internal error flag and
>       stops Notifier by returning OK.
>     - MCA handler regards state of Notifier, and decides the system to
>       resume or not.
>     - Restarted driver may refer the error flag after read, and may retry
>       the read if flag is up.

This sounds flexibile to enough to do something other than retry read.

I've been wondering if registering a callback at module_init() would be
sufficient. The callback could clean up driver state so the driver
instance can be shut down. Something like a Hotplug operation to remove
the card.
This way the driver wouldn't need a new read/write interface to
access MMIO space.

>     Feature:
>     - Generic kernel is not changed.
>     - Require a platform specific MCA handler.
>     - Service is available for platform specific drivers.
> 
>  -readb_check on kernel
>     Outline:
>     - Kernel has readb_check function.
>     - Drivers may use readb_check instead of usual readb.
>     - MCA handler checks address of error, and if it occurs in readb_check,
>       changes return value of readb_check and resumes interrupted context.
>     - Driver may refer the return value to notice MCA in last read procedure.
>     Feature:
>     - Generic kernel requires new codes.
>     - Require some codes in generic MCA procedure.
>     - Service is available for all drivers.
> 
> Which one is better?

I'm really not sure. Need to think about it more.

thanks,
grant

  parent reply	other threads:[~2003-11-19 16:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-18 10:11 [RFC] How drivers notice a MCA on I/O read? [1/3] Hidetoshi Seto
2003-11-18 10:12 ` [RFC] How drivers notice a MCA on I/O read? [2/3] Hidetoshi Seto
2003-11-18 10:14 ` [RFC] How drivers notice a MCA on I/O read? [3/3] Hidetoshi Seto
2003-11-18 15:06 ` [RFC] How drivers notice a MCA on I/O read? [1/3] Zoltan Menyhart
2003-11-18 17:10 ` Jesse Barnes
2003-11-18 17:47 ` Luck, Tony
2003-11-19 16:45 ` Grant Grundler [this message]
2003-11-25  9:27 ` Hidetoshi Seto

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-106926030617030@msgid-missing \
    --to=iod00d@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox