This message is from the T13 list server.
On Tue, Jun 29, 2004 at 01:40:18PM -0700, Mark Overby wrote:
> This message is from the T13 list server.
>
>
> On other operating systems that implement hot-plug support for PCI (and
> other buses), the software gets a notification from the underlying bus
> controller that the device has been removed. Is this not the case in
> your environment? A simple status read of the SStatus register would
> also verify if the controller is alive or not.
You are correct (and I agree) on both counts.
However... Consider the case of when an interrupt from an HBA is
pending. Even if your environment delivers an interrupt when the HBA is
removed from the system, it is likely on many platforms that the
HBA's OS driver's interrupt handler will be called _after_ the HBA
has been removed.
Thus, if your OS driver reads the SActive or an active-tag HBA register
somewhere in its hot path -- a likely situation -- it is therefore
likely that such a register read will result in 0xffffffff.
Certainly, HBA removal is easy to detect. My point is that the unwary
OS driver engineer may write code that takes action on a bitmapped
register before noticing that the HBA has been removed.
This is, unfortunately, a common error made by naive OS driver authors
on Linux frequently. When hardware designs appear in public that use a
hardware register as a bitmap, past experience has shown that OS driver
bugs are the inevitable result :(
If all OS driver authors were paragons of code perfection,
my app note would be unnecessary ;-)
Jeff
P.S. here is an example snippet of code from a standard Linux
interrupt handler, on sane hardware:
unsigned int status;
status = readl(addr + IntrStatus);
if (status == 0) /* shared interrupt */
return IRQ_NONE;
if (status == 0xffffffff) { /* hardware disappeared */
internal OS driver cleanup
return IRQ_NONE;
}
...handle interrupt...
return IRQ_HANDLED;
