uda.4

早期freebsd实现

burst size, in words.
.Pp
.It panic: udaintr
Indicates a bug in the generic
.Tn MSCP
code.
.Pp
.It uda%d: driver bug, state %d
The driver has a bogus value for the controller state.  Something
is quite wrong.  This is immediately followed by a `panic: udastate'.
.Pp
.It uda%d: purge bdp %d
A benign message tracing BDP purges.  I have been trying to figure
out what BDP purges are for.  You might want to comment out this
call to log() in /sys/vaxuba/uda.c.
.Pp
.It uda%d: SETCTLRC failed:  `detail'
The Set Controller Characteristics command (the last part of the
controller initialisation sequence) failed.  The
.Em detail
message tells why.
.Pp
.It "uda%d: attempt to bring ra%d on line failed:  `detail'"
The drive could not be brought on line.  The
.Em detail
message tells why.
.Pp
.It uda%d: ra%d: unknown type %d
The type index of the named drive is not known to the driver, so the
drive will be ignored.
.Pp
.It "ra%d: changed types! was %d now %d"
A drive somehow changed from one kind to another, e.g., from an
.Tn RA80
to an
.Tn RA60 .
The numbers printed are the encoded media identifiers (see
.Ao Pa vax/mscp.h Ac
for the encoding).
The driver believes the new type.
.Pp
.It "ra%d: uda%d, unit %d, size = %d sectors"
The named drive is on the indicated controller as the given unit,
and has that many sectors of user-file area.  This is printed
during configuration.
.Pp
.It "uda%d: attempt to get status for ra%d failed:  `detail'"
A status request failed.  The
.Em detail
message should tell why.
.Pp
.It ra%d: bad block report: %d
The drive has reported the given block as bad.  If there are multiple
bad blocks, the drive will report only the first; in this case this
message will be followed by `+ others'.  Get
.Tn DEC
to forward the
block with
.Tn EVRLK .
.Pp
.It ra%d: serious exception reported
I have no idea what this really means.
.Pp
.It panic: udareplace
The controller reported completion of a
.Tn REPLACE
operation.  The
driver never issues any
.Tn REPLACE Ns s ,
so something is wrong.
.Pp
.It panic: udabb
The controller reported completion of bad block related
.Tn I/O .
The
driver never issues any such, so something is wrong.
.Pp
.It uda%d: lost interrupt
The controller has gone out to lunch, and is being reset to try to bring
it back.
.Pp
.It panic: mscp_go: AEB_MAX_BP too small
You defined
.Dv AVOID_EMULEX_BUG
and increased
.Dv NCMDL2
and Emulex has
new firmware.  Raise
.Dv AEB_MAX_BP
or turn off
.Dv AVOID_EMULEX_BUG .
.Pp
.It "uda%d: unit %d: unknown message type 0x%x ignored"
The controller responded with a mysterious message type. See
.Pa /sys/vax/mscp.h
for a list of known message types.  This is probably
a controller hardware problem.
.Pp
.It "uda%d: unit %d out of range"
The disk drive unit number (the unit plug) is higher than the
maximum number the driver allows (currently 7).
.Pp
.It "uda%d: unit %d not configured, message ignored"
The named disk drive has announced its presence to the controller,
but was not, or cannot now be, configured into the running system.
.Em Message
is one of `available attention' (an `I am here' message) or
`stray response op 0x%x status 0x%x' (anything else).
.Pp
.It ra%d: bad lbn (%d)?
The drive has reported an invalid command error, probably due to an
invalid block number.  If the lbn value is very much greater than the
size reported by the drive, this is the problem.  It is probably due to
an improperly configured partition table.  Other invalid commands
indicate a bug in the driver, or hardware trouble.
.Pp
.It ra%d: duplicate ONLINE ignored
The drive has come on-line while already on-line.  This condition
can probably be ignored (and has been).
.Pp
.It ra%d: io done, but no buffer?
Hardware trouble, or a bug; the drive has finished an
.Tn I/O
request,
but the response has an invalid (zero) command reference number.
.Pp
.It "Emulex SC41/MS screwup: uda%d, got %d correct, then changed 0x%x to 0x%x"
You turned on
.Dv AVOID_EMULEX_BUG ,
and the driver successfully
avoided the bug.  The number of correctly-handled requests is
reported, along with the expected and actual values relating to
the bug being avoided.
.Pp
.It panic: unrecoverable Emulex screwup
You turned on
.Dv AVOID_EMULEX_BUG ,
but Emulex was too clever and
avoided the avoidance.  Try turning on
.Dv MSCP_PARANOIA
instead.
.Pp
.It uda%d: bad response packet ignored
You turned on
.Dv MSCP_PARANOIA ,
and the driver caught the controller in
a lie.  The lie has been ignored, and the controller will soon be
reset (after a `lost' interrupt).  This is followed by a hex dump of
the offending packet.
.Pp
.It ra%d: bogus REPLACE end
The drive has reported finishing a bad sector replacement, but the
driver never issues bad sector replacement commands.  The report
is ignored.  This is likely a hardware problem.
.Pp
.It "ra%d: unknown opcode 0x%x status 0x%x ignored"
The drive has reported something that the driver cannot understand.
Perhaps
.Tn DEC
has been inventive, or perhaps your hardware is ill.
This is followed by a hex dump of the offending packet.
.Pp
.It "ra%d%c: hard error %sing fsbn %d [of %d-%d] (ra%d bn %d cn %d tn %d sn %d)."
An unrecoverable error occurred during transfer of the specified
filesystem block number(s),
which are logical block numbers on the indicated partition.
If the transfer involved multiple blocks, the block range is printed as well.
The parenthesized fields list the actual disk sector number
relative to the beginning of the drive,
as well as the cylinder, track and sector number of the block.
.Pp
.It uda%d: %s error datagram
The controller has reported some kind of error, either `hard'
(unrecoverable) or `soft' (recoverable).  If the controller is going on
(attempting to fix the problem), this message includes the remark
`(continuing)'.  Emulex controllers wrongly claim that all soft errors
are hard errors.  This message may be followed by
one of the following 5 messages, depending on its type, and will always
be followed by a failure detail message (also listed below).
.Bd -filled -offset indent
.It memory addr 0x%x
A host memory access error; this is the address that could not be
read.
.Pp
.It "unit %d: level %d retry %d, %s %d"
A typical disk error; the retry count and error recovery levels are
printed, along with the block type (`lbn', or logical block; or `rbn',
or replacement block) and number.  If the string is something else,
.Tn DEC
has been clever, or your hardware has gone to Australia for vacation
(unless you live there; then it might be in New Zealand, or Brazil).
.Pp
.It unit %d: %s %d
Also a disk error, but an `SDI' error, whatever that is.  (I doubt
it has anything to do with Ronald Reagan.)  This lists the block
type (`lbn' or `rbn') and number.  This is followed by a second
message indicating a microprocessor error code and a front panel
code.  These latter codes are drive-specific, and are intended to
be used by field service as an aid in locating failing hardware.
The codes for RA81s can be found in the
.%T RA81 Maintenance Guide ,
DEC order number AA-M879A-TC, in appendices E and F.
.Pp
.It "unit %d: small disk error, cyl %d"
Yet another kind of disk error, but for small disks.  (`That's what
it says, guv'nor.  Dunnask me what it means.')
.Pp
.It "unit %d: unknown error, format 0x%x"
A mysterious error: the given format code is not known.
.Ed
.Pp
The detail messages are as follows:
.Bd -filled -offset indent
.It success (%s) (code 0, subcode %d)
Everything worked, but the controller thought it would let you know
that something went wrong.  No matter what subcode, this can probably
be ignored.
.Pp
.It "invalid command (%s) (code 1, subcode %d)"
This probably cannot occur unless the hardware is out; %s should be
`invalid msg length', meaning some command was too short or too long.
.Pp
.It "command aborted (unknown subcode) (code 2, subcode %d)"
This should never occur, as the driver never aborts commands.
.Pp
.It "unit offline (%s) (code 3, subcode %d)"
The drive is offline, either because it is not around (`unknown
drive'), stopped (`not mounted'), out of order (`inoperative'), has the
same unit number as some other drive (`duplicate'), or has been
disabled for diagnostics (`in diagnosis').
.Pp
.It "unit available (unknown subcode) (code 4, subcode %d)"
The controller has decided to report a perfectly normal event as
an error.  (Why?)
.Pp
.It "media format error (%s) (code 5, subcode %d)"
The drive cannot be used without reformatting.  The Format Control
Table cannot be read (`fct unread - edc'), there is a bad sector
header (`invalid sector header'), the drive is not set for 512-byte
sectors (`not 512 sectors'), the drive is not formatted (`not formatted'),
or the
.Tn FCT
has an uncorrectable
.Tn ECC
error (`fct ecc').
.Pp
.It "write protected (%s) (code 6, subcode %d)"
The drive is write protected, either by the front panel switch
(`hardware') or via the driver (`software').  The driver never
sets software write protect.
.Pp
.It "compare error (unknown subcode) (code 7, subcode %d)"
A compare operation showed some sort of difference.  The driver
never uses compare operations.
.Pp
.It "data error (%s) (code 7, subcode %d)"
Something went wrong reading or writing a data sector.  A `forced
error' is a software-asserted error used to mark a sector that contains
suspect data.  Rewriting the sector will clear the forced error.  This
is normally set only during bad block replacment, and the driver does
no bad block replacement, so these should not occur.  A `header
compare' error probably means the block is shot.  A `sync timeout'
presumably has something to do with sector synchronisation.
An `uncorrectable ecc' error is an ordinary data error that cannot
be fixed via
.Tn ECC
logic.  A `%d symbol ecc' error is a data error
that can be (and presumably has been) corrected by the
.Tn ECC
logic.
It might indicate a sector that is imperfect but usable, or that
is starting to go bad.  If any of these errors recur, the sector
may need to be replaced.
.Pp
.It "host buffer access error (%s) (code %d, subcode %d)"
Something went wrong while trying to copy data to or from the host
(Vax).  The subcode is one of `odd xfer addr', `odd xfer count',
`non-exist. memory', or `memory parity'.  The first two could be a
software glitch; the last two indicate hardware problems.
.It controller error (%s) (code %d, subcode %d)
The controller has detected a hardware error in itself.  A
`serdes overrun' is a serialiser / deserialiser overrun; `edc'
probably stands for `error detection code'; and `inconsistent
internal data struct' is obvious.
.Pp
.It "drive error (%s) (code %d, subcode %d)"
Either the controller or the drive has detected a hardware error
in the drive.  I am not sure what an `sdi command timeout' is, but
these seem to occur benignly on occasion.  A `ctlr detected protocol'
error means that the controller and drive do not agree on a protocol;
this could be a cabling problem, or a version mismatch.  A `positioner'
error means the drive seek hardware is ailing; `lost rd/wr ready'
means the drive read/write logic is sick; and `drive clock dropout'
means that the drive clock logic is bad, or the media is hopelessly
scrambled.  I have no idea what `lost recvr ready' means.  A `drive 
detected error' is a catch-all for drive hardware trouble; `ctlr
detected pulse or parity' errors are often caused by cabling problems.
.Ed
.El
.Sh SEE ALSO
.Xr disklabel 5 ,
.Xr disklabel 8
.Sh HISTORY
The
.Nm
driver appeared in
.Bx 4.2 .