> On Mon, 10 May 1999 21:33:35 +0200 (MET DST),
> Gerard Roudier <groudier@club-internet.fr> wrote:
> >Speeking for the ncr/sym53c8xx drivers, there is no problems to
> >add some poll for completion behaviour code. The problem is just
> >to add some path that tells the driver to behave so.
> >By the way, it should not be different for other SCSI drivers.
> >Should not exceed 20 lines of code in ncr/sym53c8xx drivers.
>
> Even with poll instead of interrupts, all SCSI code is going to use the
> buffer cache and try to get the io request spin lock. During Oops
> dumping, neither are safe. If the Oops occurred during earlier I/O
> processing and we do *any* disk I/O from Oops recovery then we are
> violating all the constraints on I/O reentrancy. If we are lucky we
> just hang on a spin lock, if we are unlucky we corrupt kernel
> structures and make the problem worse.
>
> The only safe method of doing I/O inside Oops recovery is one that does
> not use kernel interrupts, does not use kernel DMA, does not use buffer
> cache, does not use any spin locks. Forget about doing I/O during Oops
> unless you can meet these criteria. Serial console does, very little
> else is suitable.
In one operating system I knew well (IBM's VM) control never passed out of
the dump process. IBM 370/390 hardware uses channel command words and has
basic commands SIO (start i/o)to start the activity and TIO (test I/O)
which can be used for completion checking. There are less basic ways which
allow overlap, of course. The DASD area is pre-formatted, so the channel
commands were very simple. During the process, if an unexpected interrupt
occured the dump process would stop. (Machine check, for example).
In an MP environment, the other processor(s) would be SIGP'd to stop all
work during the dump.
Linux would need a "non-operating system" mode of operation to proceed
succesfully. Sounds tough but not impossible.
John Alvord
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/