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.
Decent hardware has a mechanism below the kernel to do emergency I/O,
this can be used to get an emergency dump. ix86 is not decent
hardware.
-
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/