share/man/man9f/ddi_dev_report_fault.9f

   1 '\" te
   2 .\"  Copyright (c) 1999, Sun Microsystems, Inc.  All Rights Reserved
   3 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
   4 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
   5 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
   6 .TH DDI_DEV_REPORT_FAULT 9F "Aug 13, 1999"
   7 .SH NAME
   8 ddi_dev_report_fault \- Report a hardware failure
   9 .SH SYNOPSIS
  10 .LP
  11 .nf
  12 #include <sys/ddi.h>
  13 #include <sys/sunddi.h>
  14
  15
  16
  17 \fBvoid\fR  \fBddi_dev_report_fault\fR (\fBdev_info_t   *\fR\fIdip\fR,
  18      \fBddi_fault_impact_t\fR \fIimpact\fR, \fB ddi_fault_location_t\fR \fIlocation\fR,
  19      \fBconst char   *\fR\fImessage \fR);
  20 .fi
  21
  22 .SH INTERFACE LEVEL
  23 .sp
  24 .LP
  25 Solaris DDI specific (Solaris DDI)
  26 .SH PARAMETERS
  27 .sp
  28 .ne 2
  29 .na
  30 \fB\fIdip\fR \fR
  31 .ad
  32 .RS 13n
  33 Pointer to the driver's \fBdev_info\fR structure to which the fault report
  34 relates. (Normally the caller's own \fBdev_info\fR pointer).
  35 .RE
  36
  37 .sp
  38 .ne 2
  39 .na
  40 \fB\fIimpact\fR \fR
  41 .ad
  42 .RS 13n
  43 One of a set of enumerated values indicating the impact of the fault on the
  44 device's ability to provide normal service.
  45 .RE
  46
  47 .sp
  48 .ne 2
  49 .na
  50 \fB\fIlocation\fR \fR
  51 .ad
  52 .RS 13n
  53 One of a set of enumerated values indicating the location of the fault,
  54 relative to the hardware controlled by the driver specified by \fBdip\fR.
  55 .RE
  56
  57 .sp
  58 .ne 2
  59 .na
  60 \fB\fImessage\fR \fR
  61 .ad
  62 .RS 13n
  63 Text of the message describing the fault being reported.
  64 .RE
  65
  66 .SH DESCRIPTION
  67 .sp
  68 .LP
  69 This function provides a standardized mechanism through which device drivers
  70 can report hardware faults.  Use of this reporting mechanism enables systems
  71 equipped with a fault management system to respond to faults discovered by a
  72 driver. On a suitably equipped system, this might include automatic failover to
  73 an alternative device and/or scheduling replacement of the faulty hardware.
  74 .sp
  75 .LP
  76 The driver must indicate the impact of the fault being reported on its ability
  77 to provide service by passing one of the following values for the impact
  78 parameter:
  79 .sp
  80 .ne 2
  81 .na
  82 \fB\fBDDI_SERVICE_LOST\fR\fR
  83 .ad
  84 .RS 26n
  85 Indicates a total loss of service. The driver is unable to implement the normal
  86 functions of its hardware.
  87 .RE
  88
  89 .sp
  90 .ne 2
  91 .na
  92 \fB\fBDDI_SERVICE_DEGRADED\fR\fR
  93 .ad
  94 .RS 26n
  95 The driver is unable to provide normal service, but can provide a partial or
  96 degraded level of service. The driver may have to make repeated attempts to
  97 perform an operation before it succeeds, or it may be running at less than its
  98 configured speed. A driver may use this value to indicate that an alternative
  99 device should be used if available, but that it can continue operation if no
 100 alternative exists.
 101 .RE
 102
 103 .sp
 104 .ne 2
 105 .na
 106 \fB\fBDDI_SERVICE_UNAFFECTED\fR\fR
 107 .ad
 108 .RS 26n
 109 The service provided by the device is currently unaffected by the reported
 110 fault. This value may be used to report recovered errors for predictive failure
 111 analysis.
 112 .RE
 113
 114 .sp
 115 .ne 2
 116 .na
 117 \fB\fBDDI_SERVICE_RESTORED\fR\fR
 118 .ad
 119 .RS 26n
 120 The driver has resumed normal service, following a previous report that service
 121 was lost or degraded.  This message implies that any previously reported fault
 122 condition no longer exists.
 123 .RE
 124
 125 .sp
 126 .LP
 127 The location parameter should be one of the following values:
 128 .sp
 129 .ne 2
 130 .na
 131 \fB\fBDDI_DATAPATH_FAULT\fR\fR
 132 .ad
 133 .RS 22n
 134 The fault lies in the datapath between the driver and the device. The device
 135 may be unplugged, or a problem may exist in the bus on which the device
 136 resides.  This value is appropriate if the device is not responding to
 137 accesses, (for example, the device may not be present) or if a call to
 138 \fBddi_check_acc_handle\fR(9F) returns \fBDDI_FAILURE\fR.
 139 .RE
 140
 141 .sp
 142 .ne 2
 143 .na
 144 \fB\fBDDI_DEVICE_FAULT\fR\fR
 145 .ad
 146 .RS 22n
 147 The fault lies in the device controlled by the driver. This value is
 148 appropriate if the device returns an error from a selftest function, or if the
 149 driver is able to determine that device is present and accessible, but is not
 150 functioning correctly.
 151 .RE
 152
 153 .sp
 154 .ne 2
 155 .na
 156 \fB\fBDDI_EXTERNAL_FAULT\fR\fR
 157 .ad
 158 .RS 22n
 159 The fault is external to the device.  For example, an Ethernet driver would use
 160 this value when reporting a cable fault.
 161 .sp
 162 If a device returns detectably bad data during normal operation (an
 163 "impossible" value in a register or DMA status area, for example), the driver
 164 should check the associated handle using \fBddi_check_acc_handle\fR(9F) or
 165 \fBddi_check_dma_handle\fR(9F) before reporting the fault. If the fault is
 166 associated with the handle, the driver should specify  \fBDDI_DATAPATH_FAULT\fR
 167 rather than \fBDDI_DEVICE_FAULT\fR. As a consequence of this call, the device's
 168 state may be updated to reflect the level of service currently available. See
 169 \fBddi_get_devstate\fR(9F).
 170 .sp
 171 Note that if a driver calls \fBddi_get_devstate\fR(9F) and discovers that its
 172 device is down, a fault should not be reported- the device is down as the
 173 result of a fault that has already been reported. Additionally, a driver should
 174 avoid incurring or reporting additional faults when the device is already known
 175 to be unusable. The  \fBddi_dev_report_fault()\fR call should only be used to
 176 report hardware (device) problems and should not be used to report purely
 177 software problems such as memory (or other resource) exhaustion.
 178 .RE
 179
 180 .SH EXAMPLES
 181 .sp
 182 .LP
 183 An Ethernet driver receives an error interrupt from its device if various fault
 184 conditions occur.  The driver must read an error status register to determine
 185 the nature of the fault, and report it appropriately:
 186 .sp
 187 .in +2
 188 .nf
 189 static int
 190 xx_error_intr(xx_soft_state *ssp)
 191 {
 192     ...
 193     error_status = ddi_get32(ssp->handle, &ssp->regs->xx_err_status);
 194     if (ddi_check_acc_handle(ssp->handle) != DDI_SUCCESS) {
 195         ddi_dev_report_fault(ssp->dip, DDI_SERVICE_LOST,
 196             DDI_DATAPATH_FAULT, "register access fault");
 197         return DDI_INTR_UNCLAIMED;
 198     }
 199     if (ssp->error_status & XX_CABLE_FAULT) {
 200         ddi_dev_report_fault(ssp->dip, DDI_SERVICE_LOST,
 201             DDI_EXTERNAL_FAULT, "cable fault")
 202         return DDI_INTR_CLAIMED;
 203     }
 204     if (ssp->error_status & XX_JABBER) {
 205         ddi_dev_report_fault(ssp->dip, DDI_SERVICE_DEGRADED,
 206             DDI_EXTERNAL_FAULT, "jabbering detected")
 207         return DDI_INTR_CLAIMED;
 208     }
 209     ...
 210 }
 211 .fi
 212 .in -2
 213
 214 .SH CONTEXT
 215 .sp
 216 .LP
 217 The \fBddi_dev_report_fault()\fR function may be called from user, kernel, or
 218 interrupt context.
 219 .SH SEE ALSO
 220 .sp
 221 .LP
 222 \fBddi_check_acc_handle\fR(9F), \fBddi_check_dma_handle\fR(9F),
 223 \fBddi_get_devstate\fR(9F)