Subject: freezing the scsi bus
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 07/09/1999 16:57:46
I've been playing for a little while now with what amounts to
hot-swapping scsi devices. Most of it is going well, but I do have a
problem that I'm not sure how best to attack.
The problem is freezing the scsi bus, for hot-adding and hot-removing
devices on machines whose scsi interfaces were not designed for it (and
hence don't have connectors that do nice things like isolate the device
from the bus electrically before breaking the mechanical contact).
Hot-plugging when the bus is active is rather dangerous to transfers in
progress. So far, I've always been freezing the bus by dropping into
the PROM monitor (L1-A on SPARCs, for example). This has worked for
me, but is, shall we say, somewhat inelegant.
I've used an Auspex, and they have a program (ax_hot_plug) that
specifically freezes the bus, guaranteeing that it's electrically
quiescent, allowing you to fuss with it without risk of corrupting a
transfer in progress. I'd like to add something functionally similar
The problem, of course, is how. The Auspex program freezes the bus,
prints a message, waits for you to press RETURN, and unfreezes the bus.
I don't know how much of it is userland and how much is kernel.
I could do this via two ioctls (to freeze and unfreeze), except for the
risk that the process will have to page something in off disk in order
to unfreeeze the bus. I could move it all into the kernel and obviate
that risk, except for issues like having to exit X so that /dev/console
actually does something. (Trying to do it within X is too much hair;
it would mean locking pieces of an indeterminate number of processes
into core - and that doesn't even consider the problems of trying to
figure out which processes need locking, or which pieces of those
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B