Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

ddi_fm_ereport_post(9f) [opensolaris man page]

ddi_fm_ereport_post(9F) 				   Kernel Functions for Drivers 				   ddi_fm_ereport_post(9F)

NAME
ddi_fm_ereport_post - post an FMA Protocol Error Report Event SYNOPSIS
#include <sys/ddifm.h> void ddi_fm_ereport_post(dev_info_t *dip, char *ereport_class, uint64_t ena, int *sflag, ... /* name-value pair args */); INTERFACE LEVEL
Solaris DDI specific (Solaris DDI) PARAMETERS
dip Pointer to the dev_info structure ereport_class FMA Event Protocol error class ena Error Numeric Association sflag Determines whether caller can sleep for memory or other event resources. DESCRIPTION
The ddi_fm_ereport_post() function causes an encoded fault management error report name-value pair list to be queued for delivery to the Fault Manager daemon, fmd(1M). The sflag parameter indicates whether or not the caller is willing to wait for system memory and event chan- nel resources to become available. The following ereport_class strings are available for use by any leaf device driver: device.inval_state A leaf driver discovers that the device is in an invalid or inconsistent state. For example, the driver might detect that receive or send ring descriptor indices are corrupted. It might also find an invalid value in a regis- ter or a driver-to-device protocol violation. device.no_response A leaf driver times out waiting for a response from the device. For example, timeouts can occur when no confirma- tion is seen after resetting, enabling, or disabling part of the device. device.badint_limit A leaf device sends too many consecutive interrupts with no work to do. device.intern_corr A leaf device reports to the driver that it has itself detected an internal correctable error. device.intern_uncorr A leaf device reports to the driver that it has itself detected an internal uncorrectable error. device.stall A leaf driver determines that data transmission has stalled indefinitely. The ena indicates the Format 1 Error Numeric Association for this error report. It might have already been initialized by another error- detecting software module. For example, if ddi_fm_ereport_post() is called from an error handler callback function, the fme_ena field from the passed-in ddi_fm_error argument should be used. Otherwise it should be set to 0 and will be initialized by ddi_fm_ereport_post(). The name-value pair args variable argument list contains one or more (names, type, value pointer) nvpair tuples for non-array data_type_t types or one or more (name, type, number of elements, value pointer) tuples for data_type_t array types. There is one mandatory tuple to describe the ereport version. This should contain the following values: o name - FM_VERSION o type - DATA_TYPE_UINT8 o value - FM_EREPORT_VERS0 Additional nvpair tuples can describe error conditions for logging purposes, but are not interpreted by the I/O framework or fault manager. The end of the argument list is specified by NULL. CONTEXT
The ddi_fm_ereport_post() function can be called from user, kernel, or high-level interrupt context. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Interface Stability |Committed | +-----------------------------+-----------------------------+ SEE ALSO
fmd(1M), attributes(5), ddi_fm_service_impact(9F) SunOS 5.11 14 May 2007 ddi_fm_ereport_post(9F)

Check Out this Related Man Page

ddi_fm_handler_register(9F)				   Kernel Functions for Drivers 			       ddi_fm_handler_register(9F)

NAME
ddi_fm_handler_register, ddi_fm_handler_unregister - register or unregister an error handling callback SYNOPSIS
#include <sys/ddifm.h> void ddi_fm_handler_register(dev_info_t *dip, ddi_err_func_t error_handler, void *impl_data); void ddi_fm_handler_unregister(dev_info_t *dip); INTERFACE LEVEL
Solaris DDI specific (Solaris DDI) PARAMETERS
dip Pointer to the dev_info structure error_handler Pointer to an error handler callback function impl_data Pointer to private data for use by the caller DESCRIPTION
The ddi_fm_handler_register() function registers an error handler callback routine with the I/O Fault Management framework. The error han- dler callback, error_handler, is called to process error conditions detected by the system. In addition to its device instance, dip, the error handler is called with a pointer to a fault management error status structure, ddi_fm_error_t. For example: int (*ddi_err_func_t)(dev_info_t *dip, ddi_fm_error_t *error_status); A driver error handling callback is passed the following arguments: o a pointer to the device instance registered for this callback. o a data structure containing common fault management data and status for error handling. The primary responsibilities of the error handler include: o to check for outstanding hardware or software errors. o where possible, to isolate the device that might have caused the errors. o to report errors that were detected. During the invocation of an error handler, a device driver might need to quiesce or suspend all I/O activities in order to check for error conditions or status in: o hardware control and status registers. o outstanding I/O transactions. o access or DMA handles. For each error detected, the driver must formulate and post an error report via ddi_fm_ereport_post() for problem analysis by the Solaris Fault Manager fmd(1M). For a PCI, PCI/X, or PCI Express leaf device, the pci_ereport_post() function is provided to carry out reporting responsibilities on behalf of the driver. In many cases, an error handler callback function of the following form can be used: xxx_err_cb(dev_info_t *dip, ddi_fm_error_t *errp) { pci_ereport_post(dip, errp, NULL); return (errp->fme_status); } In addition, the driver might be able to carry out further device specific checks within the error handler. Error handlers can be called from kernel, interrupt, or high-level interrupt context. The interrupt block cookie returned from ddi_fm_init() should be used to allocate and initialize any synchronization variables and locks that might be used within the error handler callback function. Such locks may not be held by the driver when a device register is accessed with functions such as ddi_get8(9F) and ddi_put8(9F). The data structure, ddi_fm_error_t, contains an FMA protocol (format 1) ENA for the current error propagation chain, the status of the error handler callback, an error expectation flag, and any potential access or DMA handles associated with an error detected by the parent nexus. The ddi_fm_handler_unregister() function removes a previously registered error handling callback for the device instance specified by the dip. CONTEXT
The ddi_fm_handler_register() and ddi_fm_handler_unregister() functions must be called from kernel context in an attach(9E) or detach(9E) entry point. The registered error handler, error_handler, callback can be called from kernel, interrupt, or high level interrupt context. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Interface Stability |Committed | +-----------------------------+-----------------------------+ SEE ALSO
fmd(1M), attributes(5), attach(9E), detach(9E), ddi_fm_ereport_post(9F), ddi_fm_init(9F), ddi_get8(9F), ddi_put8(9F), pci_ereport_post(9F), ddi_fm_error(9S) Writing Device Drivers SunOS 5.11 14 May 2007 ddi_fm_handler_register(9F)
Man Page