diff options
author | Alexander Motin <mav@FreeBSD.org> | 2012-06-09 13:07:44 +0000 |
---|---|---|
committer | Alexander Motin <mav@FreeBSD.org> | 2012-06-09 13:07:44 +0000 |
commit | 0191d9b367297cebaf21fdf4f5cebbbc92eef88e (patch) | |
tree | 3d3277f183ec41c80d3113d0e2ab3435d883120e /sys/nfsclient | |
parent | 5d02ed91e981d47e24278beba992cf55410d14ee (diff) | |
download | src-0191d9b367297cebaf21fdf4f5cebbbc92eef88e.tar.gz src-0191d9b367297cebaf21fdf4f5cebbbc92eef88e.zip |
One more major cam_periph_error() rewrite to improve error handling and
reporting. It includes:
- removing of error messages controlled by bootverbose, replacing them
with more universal and informative debugging on CAM_DEBUG_INFO level,
that is now built into the kernel by default;
- more close following to the arguments submitted by caller, such as
SF_PRINT_ALWAYS, SF_QUIET_IR and SF_NO_PRINT; consumer knows better which
errors are usual/expected at this point and which are really informative;
- adding two new flags SF_NO_RECOVERY and SF_NO_RETRY to allow caller
specify how much assistance it needs at this point; previously consumers
controlled that by not calling cam_periph_error() at all, but that made
behavior inconsistent and debugging complicated;
- tuning debug messages and taken actions order to make debugging output
more readable and cause-effect relationships visible;
- making camperiphdone() (common device recovery completion handler) to
also use cam_periph_error() in most cases, instead of own dumb code;
- removing manual sense fetching code from cam_periph_error(); I was told
by number of people that it is SIM obligation to fetch sense data, so this
code is useless and only significantly complicates recovery logic;
- making ada, da and pass driver to use cam_periph_error() with new limited
recovery options to handle error recovery and debugging in common way;
as one of results, CAM_REQUEUE_REQ and other retrying statuses are now
working fine with pass driver, that caused many problems before.
- reverting r186891 by raj@ to avoid burning few seconds in tight DELAY()
loops on device probe, while device simply loads media; I think that problem
may already be fixed in other way, and even if it is not, solution must be
different.
Sponsored by: iXsystems, Inc.
MFC after: 2 weeks
Notes
Notes:
svn path=/head/; revision=236814
Diffstat (limited to 'sys/nfsclient')
0 files changed, 0 insertions, 0 deletions