From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Rogier Wolff <R.E.Wolff@BitWizard.nl>,
"Isabelle, Francois" <Francois.Isabelle@ca.kontron.com>,
linux-scsi@vger.kernel.org
Subject: Re: Sym53C8xx Driver Hardening
Date: Tue, 23 Jul 2002 17:38:30 +0200 (MEST) [thread overview]
Message-ID: <200207231538.RAA03408@cave.bitwizard.nl> (raw)
In-Reply-To: <1027437862.31787.136.camel@irongate.swansea.linux.org.uk> from Alan Cox at "Jul 23, 2002 04:24:22 pm"
Alan Cox wrote:
> On Tue, 2002-07-23 at 14:57, Rogier Wolff wrote:
> > Now it won't be as easy as this. But for instance in my firestream
> > driver, you sometimes put a value in a register in the chip, and if
> > later on you read it back, you want the chip to have left it
> > unmodified, or to have it changed in a predictable way. If the value
> > is unexpected, a panic is the right "way out".
>
> The high reliability people take a different view. I actually agree with
> them. It isnt about 'oops didnt happen' it is about controlling the
> failure case
>
> Suppose your firestream driver reports catacylsmic internal error
> status. Their argument is not that you should pretend life is good but
> that the driver should log a fault and shut off the chip as best it can.
> So you might have a firestream_failed() function which did
>
> Disable master bit
> Put board into D3
> Wait
> Put board into running state
> Try to reset and configure it
> If this fails shove it in D3 and give up
>
> At this point the high reliability system is servicing the other links
> it manages and flashing warning lights to the engineers, rather than
> completely down
That might indeed be preferable. However, the "wild DMA" may have
corrupted users' data, and/or the kernel's datastructures. So
continuing may lead to a bad situation getting worse...
Maybe we want to generalize "panic" so that you pass it a pointer to
"shutdown this hardware" routine, allowing diversion of the "policy"
about what to do to a user-definable central place.....
Userspace would then be notified: "We shut down atm0 due to an
irrecoverable error". And userspace can then decide to kick the device
as you suggest above.
Or, I could configure it to do an immediate reboot, with/without
attempting to sync disks....
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
next prev parent reply other threads:[~2002-07-23 15:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-23 13:29 Sym53C8xx Driver Hardening Isabelle, Francois
2002-07-23 13:57 ` Rogier Wolff
2002-07-23 15:24 ` Alan Cox
2002-07-23 15:11 ` random1
2002-07-23 15:38 ` Rogier Wolff [this message]
2002-07-24 23:11 ` Gérard Roudier
2002-07-25 22:33 ` Jeremy Higdon
2002-07-25 23:53 ` Alan Cox
2002-07-26 22:25 ` Gérard Roudier
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=200207231538.RAA03408@cave.bitwizard.nl \
--to=r.e.wolff@bitwizard.nl \
--cc=Francois.Isabelle@ca.kontron.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-scsi@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