ddi_dev_report_fault(9F) Kernel Functions for Drivers ddi_dev_report_fault(9F)NAMEddi_dev_report_fault - Report a hardware failure
SYNOPSIS
#include <sys/ddi.h>
#include <sys/sunddi.h>
void ddi_dev_report_fault (dev_info_t *dip, ddi_fault_impact_t
impact, ddi_fault_location_t location, const char *message );
INTERFACE LEVEL
Solaris DDI specific (Solaris DDI)
PARAMETERS
dip Pointer to the driver's dev_info structure to which the
fault report relates. (Normally the caller's own
dev_info pointer).
impact One of a set of enumerated values indicating the impact
of the fault on the device's ability to provide normal
service.
location One of a set of enumerated values indicating the loca‐
tion of the fault, relative to the hardware controlled
by the driver specified by dip.
message Text of the message describing the fault being
reported.
DESCRIPTION
This function provides a standardized mechanism through which device
drivers can report hardware faults. Use of this reporting mechanism
enables systems equipped with a fault management system to respond to
faults discovered by a driver. On a suitably equipped system, this
might include automatic failover to an alternative device and/or sched‐
uling replacement of the faulty hardware.
The driver must indicate the impact of the fault being reported on its
ability to provide service by passing one of the following values for
the impact parameter:
"small and bold">DDI_SERVICE_LOST
Indicates a total loss of service. The driver is unable to imple‐
ment the normal functions of its hardware.
DDI_SERVICE_DEGRADED
The driver is unable to provide normal service, but can provide a
partial or degraded level of service. The driver may have to make
repeated attempts to perform an operation before it succeeds, or it
may be running at less than its configured speed. A driver may use
this value to indicate that an alternative device should be used if
available, but that it can continue operation if no alternative
exists.
DDI_SERVICE_UNAFFECTED
The service provided by the device is currently unaffected by the
reported fault. This value may be used to report recovered errors
for predictive failure analysis.
DDI_SERVICE_RESTORED
The driver has resumed normal service, following a previous report
that service was lost or degraded. This message implies that any
previously reported fault condition no longer exists.
The location parameter should be one of the following values:
DDI_DATAPATH_FAULT
The fault lies in the datapath between the driver and the device.
The device may be unplugged, or a problem may exist in the bus on
which the device resides. This value is appropriate if the device
is not responding to accesses, (for example, the device may not be
present) or if a call to ddi_check_acc_handle(9F) returns DDI_FAIL‐
URE.
DDI_DEVICE_FAULT
The fault lies in the device controlled by the driver. This value
is appropriate if the device returns an error from a selftest func‐
tion, or if the driver is able to determine that device is present
and accessible, but is not functioning correctly.
DDI_EXTERNAL_FAULT
The fault is external to the device.
For example, an Ethernet driver would use this value when report‐
ing a cable fault.
If a device returns detectably bad data during normal operation (an
"impossible" value in a register or DMA status area, for example),
the driver should check the associated handle using
ddi_check_acc_handle(9F) or ddi_check_dma_handle(9F) before report‐
ing the fault. If the fault is associated with the handle, the
driver should specify DDI_DATAPATH_FAULT rather than
DDI_DEVICE_FAULT. As a consequence of this call, the device's
state may be updated to reflect the level of service currently
available. See ddi_get_devstate(9F).
Note that if a driver calls ddi_get_devstate(9F) and discovers that
its device is down, a fault should not be reported- the device is
down as the result of a fault that has already been reported. Addi‐
tionally, a driver should avoid incurring or reporting additional
faults when the device is already known to be unusable. The
ddi_dev_report_fault() call should only be used to report hardware
(device) problems and should not be used to report purely software
problems such as memory (or other resource) exhaustion.
EXAMPLES
An Ethernet driver receives an error interrupt from its device if vari‐
ous fault conditions occur. The driver must read an error status reg‐
ister to determine the nature of the fault, and report it appropri‐
ately:
static int
xx_error_intr(xx_soft_state *ssp)
{
...
error_status = ddi_get32(ssp->handle, &ssp->regs->xx_err_status);
if (ddi_check_acc_handle(ssp->handle) != DDI_SUCCESS) {
ddi_dev_report_fault(ssp->dip, DDI_SERVICE_LOST,
DDI_DATAPATH_FAULT, "register access fault");
return DDI_INTR_UNCLAIMED;
}
if (ssp->error_status & XX_CABLE_FAULT) {
ddi_dev_report_fault(ssp->dip, DDI_SERVICE_LOST,
DDI_EXTERNAL_FAULT, "cable fault")
return DDI_INTR_CLAIMED;
}
if (ssp->error_status & XX_JABBER) {
ddi_dev_report_fault(ssp->dip, DDI_SERVICE_DEGRADED,
DDI_EXTERNAL_FAULT, "jabbering detected")
return DDI_INTR_CLAIMED;
}
...
}
CONTEXT
The ddi_dev_report_fault() function may be called from user, kernel, or
interrupt context.
SEE ALSOddi_check_acc_handle(9F), ddi_check_dma_handle(9F), ddi_get_devs‐
tate(9F)SunOS 5.10 13 August 1999 ddi_dev_report_fault(9F)
