UDA(4) BSD Programmer's Manual (VAX Architecture) UDA(4)
u
\bud
\bda
\ba - UDA50 disk controller interface
S
\bSY
\bYN
\bNO
\bOP
\bPS
\bSI
\bIS
\bS
c
\bco
\bon
\bnt
\btr
\bro
\bol
\bll
\ble
\ber
\br u
\bud
\bda
\ba0
\b0 a
\bat
\bt u
\bub
\bba
\ba0
\b0 c
\bcs
\bsr
\br 0
\b01
\b17
\b72
\b21
\b15
\b50
\b0 v
\bve
\bec
\bct
\bto
\bor
\br u
\bud
\bda
\bai
\bin
\bnt
\btr
\br
d
\bdi
\bis
\bsk
\bk r
\bra
\ba0
\b0 a
\bat
\bt u
\bud
\bda
\ba0
\b0 d
\bdr
\bri
\biv
\bve
\be 0
\b0
o
\bop
\bpt
\bti
\bio
\bon
\bns
\bs M
\bMS
\bSC
\bCP
\bP_
\b_P
\bPA
\bAR
\bRA
\bAN
\bNO
\bOI
\bIA
\bA
D
\bDE
\bES
\bSC
\bCR
\bRI
\bIP
\bPT
\bTI
\bIO
\bON
\bN
This is a driver for the DEC UDA50 disk controller and other compatible
controllers. The UDA50 communicates with the host through a packet pro-
tocol known as the Mass Storage Control Protocol (MSCP). Consult the file
<_
\bv_
\ba_
\bx_
\b/_
\bm_
\bs_
\bc_
\bp_
\b._
\bh> for a detailed description of this protocol.
The u
\bud
\bda
\ba driver is a typical block-device disk driver; see physio(4) for a
description of block I/O. The script MAKEDEV(8) should be used to create
the u
\bud
\bda
\ba special files; should a special file need to be created by hand,
The MSCP_PARANOIA option enables runtime checking on all transfer comple-
tion responses from the controller. This increases disk I/O overhead and
may be undesirable on slow machines, but is otherwise recommended.
The first sector of each disk contains both a first-stage bootstrap pro-
gram and a disk label containing geometry information and partition lay-
outs (see disklabel(5)). This sector is normally write-protected, and
disk-to-disk copies should avoid copying this sector. The label may be
updated with disklabel(8), which can also be used to write-enable and
write-disable the sector. The next 15 sectors contain a second-stage
D
\bDI
\bIS
\bSK
\bK S
\bSU
\bUP
\bPP
\bPO
\bOR
\bRT
\bT
During autoconfiguration, as well as when a drive is opened after all
partitions are closed, the first sector of the drive is examined for a
disk label. If a label is found, the geometry of the drive and the par-
tition tables are taken from it. If no label is found, the driver con-
figures the type of each drive when it is first encountered. A default
partition table in the driver is used for each type of disk when a pack
is not labelled. The origin and size (in sectors) of the default pseudo-
disks on each drive are shown below. Not all partitions begin on cylin-
der boundaries, as on other drives, because previous drivers used one
partition table for all drive types. Variants of the partition tables
are common; check the driver and the file _
\b/_
\be_
\bt_
\bc_
\b/_
\bd_
\bi_
\bs_
\bk_
\bt_
\ba_
\bb (disktab(5)) for
Special file names begin with `ra' and `rra' for the block and character
files respectively. The second component of the name, a drive unit number
in the range of zero to seven, is represented by a `?' in the disk lay-
outs below. The last component of the name is the file system partition
designated by a letter from `a' to `h' and which corresponds to a minor
device number set: zero to seven, eight to 15, 16 to 23 and so forth for
drive zero, drive two and drive three respectively, (see physio(4)). The
location and size (in sectors) of the partitions:
d
\bdi
\bis
\bsk
\bk s
\bst
\bta
\bar
\brt
\bt l
\ble
\ben
\bng
\bgt
\bth
\bh
ra?d 49324 82080 same as 4.2BSD ra?g
ra?e 131404 268772 same as 4.2BSD ra?h
d
\bdi
\bis
\bsk
\bk s
\bst
\bta
\bar
\brt
\bt l
\ble
\ben
\bng
\bgt
\bth
\bh
d
\bdi
\bis
\bsk
\bk s
\bst
\bta
\bar
\brt
\bt l
\ble
\ben
\bng
\bgt
\bth
\bh
ra?e 49324 193282 same as old Berkeley ra?g
ra?f 49324 82080 same as 4.2BSD ra?g
ra?h 131404 111202 same as 4.2BSD
d
\bdi
\bis
\bsk
\bk s
\bst
\bta
\bar
\brt
\bt l
\ble
\ben
\bng
\bgt
\bth
\bh
RA81 partitions with 4.2BSD-compatible partitions
d
\bdi
\bis
\bsk
\bk s
\bst
\bta
\bar
\brt
\bt l
\ble
\ben
\bng
\bgt
\bth
\bh
ra?d 49324 82080 same as 4.2BSD ra?g
ra?e 131404 759668 same as 4.2BSD ra?h
ra?f 412490 478582 same as 4.2BSD ra?f
d
\bdi
\bis
\bsk
\bk s
\bst
\bta
\bar
\brt
\bt l
\ble
\ben
\bng
\bgt
\bth
\bh
The ra?a partition is normally used for the root file system, the ra?b
partition as a paging area, and the ra?c partition for pack-pack copying
(it maps the entire disk).
D
\bDI
\bIA
\bAG
\bGN
\bNO
\bOS
\bST
\bTI
\bIC
\bCS
\bS
p
\bpa
\ban
\bni
\bic
\bc:
\b: u
\bud
\bda
\bas
\bsl
\bla
\bav
\bve
\be No command packets were available while the driver was
looking for disk drives. The controller is not extending enough credits
u
\bud
\bda
\ba%
\b%d
\bd:
\b: n
\bno
\bo r
\bre
\bes
\bsp
\bpo
\bon
\bns
\bse
\be t
\bto
\bo G
\bGe
\bet
\bt U
\bUn
\bni
\bit
\bt S
\bSt
\bta
\bat
\btu
\bus
\bs r
\bre
\beq
\bqu
\bue
\bes
\bst
\bt A disk drive was found,
but did not respond to a status request. This is either a hardware prob-
lem or someone pulling unit number plugs very fast.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: u
\bun
\bni
\bit
\bt %
\b%d
\bd o
\bof
\bff
\bf l
\bli
\bin
\bne
\be While searching for drives, the controller found
one that seems to be manually disabled. It is ignored.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: u
\bun
\bna
\bab
\bbl
\ble
\be t
\bto
\bo g
\bge
\bet
\bt u
\bun
\bni
\bit
\bt s
\bst
\bta
\bat
\btu
\bus
\bs Something went wrong while trying to
determine the status of a disk drive. This is followed by an error de-
u
\bud
\bda
\ba%
\b%d
\bd:
\b: u
\bun
\bni
\bit
\bt %
\b%d
\bd,
\b, n
\bne
\bex
\bxt
\bt %
\b%d
\bd This probably never happens, but I wanted to
know if it did. I have no idea what one should do about it.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: c
\bca
\ban
\bnn
\bno
\bot
\bt h
\bha
\ban
\bnd
\bdl
\ble
\be u
\bun
\bni
\bit
\bt n
\bnu
\bum
\bmb
\bbe
\ber
\br %
\b%d
\bd (
\b(m
\bma
\bax
\bx i
\bis
\bs %
\b%d
\bd)
\b) The controller found a
drive whose unit number is too large. Valid unit numbers are those in
r
\bra
\ba%
\b%d
\bd:
\b: d
\bdo
\bon
\bn'
\b't
\bt h
\bha
\bav
\bve
\be a
\ba p
\bpa
\bar
\brt
\bti
\bit
\bti
\bio
\bon
\bn t
\bta
\bab
\bbl
\ble
\be f
\bfo
\bor
\br %
\b%s
\bs;
\b; u
\bus
\bsi
\bin
\bng
\bg (
\b(s
\bs,
\b,t
\bt,
\b,c
\bc)
\b)=
\b=(
\b(%
\b%d
\bd,
\b,%
\b%d
\bd,
\b,%
\b%d
\bd)
\b) The
controller found a drive whose media identifier (e.g. `RA 25') does not
have a default partition table. A temporary partition table containing
only an `a' partition has been created covering the entire disk, which
has the indicated numbers of sectors per track (s), tracks per cylinder
(t), and total cylinders (c). Give the pack a label with the disklabel
u
\bud
\bda
\ba%
\b%d
\bd:
\b: u
\bub
\bba
\bal
\bll
\blo
\boc
\bc m
\bma
\bap
\bp f
\bfa
\bai
\bil
\ble
\bed
\bd Unibus resource map allocation failed during
initialisation. This can only happen if you have 496 devices on a
u
\bud
\bda
\ba%
\b%d
\bd:
\b: t
\bti
\bim
\bme
\beo
\bou
\but
\bt d
\bdu
\bur
\bri
\bin
\bng
\bg i
\bin
\bni
\bit
\bt The controller did not initialise within ten
seconds. A hardware problem, but it sometimes goes away if you try
u
\bud
\bda
\ba%
\b%d
\bd:
\b: i
\bin
\bni
\bit
\bt f
\bfa
\bai
\bil
\ble
\bed
\bd,
\b, s
\bsa
\ba=
\b=%
\b%b
\bb The controller refused to initalise.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: c
\bco
\bon
\bnt
\btr
\bro
\bol
\bll
\ble
\ber
\br h
\bhu
\bun
\bng
\bg The controller never finished initialisation.
Retrying may sometimes fix it.
r
\bra
\ba%
\b%d
\bd:
\b: d
\bdr
\bri
\biv
\bve
\be w
\bwi
\bil
\bll
\bl n
\bno
\bot
\bt c
\bco
\bom
\bme
\be o
\bon
\bn l
\bli
\bin
\bne
\be The drive will not come on line, prob-
ably because it is spun down. This should be preceded by a message giv-
ing details as to why the drive stayed off line.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: s
\bst
\bti
\bil
\bll
\bl h
\bhu
\bun
\bng
\bg When the controller hangs, the driver occasionally
tries to reinitialise it. This means it just tried, without success.
p
\bpa
\ban
\bni
\bic
\bc:
\b: u
\bud
\bda
\bas
\bst
\bta
\bar
\brt
\bt:
\b: b
\bbp
\bp=
\b==
\b=N
\bNU
\bUL
\bLL
\bL A bug in the driver has put an empty drive
queue on a controller queue.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: c
\bco
\bom
\bmm
\bma
\ban
\bnd
\bd r
\bri
\bin
\bng
\bg t
\bto
\boo
\bo s
\bsm
\bma
\bal
\bll
\bl If you increase NCMDL2, you may see a per-
formance improvement. (See _
\b/_
\bs_
\by_
\bs_
\b/_
\bv_
\ba_
\bx_
\bu_
\bb_
\ba_
\b/_
\bu_
\bd_
\ba_
\b._
\bc.)
p
\bpa
\ban
\bni
\bic
\bc:
\b: u
\bud
\bda
\bas
\bst
\bta
\bar
\brt
\bt A drive was found marked for status or on-line functions
while performing status or on-line functions. This indicates a bug in
u
\bud
\bda
\ba%
\b%d
\bd:
\b: c
\bco
\bon
\bnt
\btr
\bro
\bol
\bll
\ble
\ber
\br e
\ber
\brr
\bro
\bor
\br,
\b, s
\bsa
\ba=
\b=0
\b0%
\b%o
\bo (
\b(%
\b%s
\bs)
\b) The controller reported an error.
The error code is printed in octal, along with a short description if the
code is known (see the _
\bU_
\bD_
\bA_
\b5_
\b0 _
\bM_
\ba_
\bi_
\bn_
\bt_
\be_
\bn_
\ba_
\bn_
\bc_
\be _
\bG_
\bu_
\bi_
\bd_
\be, DEC part number AA-M185B-
TC, pp. 18-22). If this occurs during normal operation, the driver will
reset it and retry pending I/O. If it occurs during configuration, the
controller may be ignored.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: s
\bst
\btr
\bra
\bay
\by i
\bin
\bnt
\btr
\br The controller interrupted when it should have stayed
quiet. The interrupt has been ignored.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: i
\bin
\bni
\bit
\bt s
\bst
\bte
\bep
\bp %
\b%d
\bd f
\bfa
\bai
\bil
\ble
\bed
\bd,
\b, s
\bsa
\ba=
\b=%
\b%b
\bb The controller reported an error dur-
ing the named initialisation step. The driver will retry initialisation
u
\bud
\bda
\ba%
\b%d
\bd:
\b: v
\bve
\ber
\brs
\bsi
\bio
\bon
\bn %
\b%d
\bd m
\bmo
\bod
\bde
\bel
\bl %
\b%d
\bd An informational message giving the revision
u
\bud
\bda
\ba%
\b%d
\bd:
\b: D
\bDM
\bMA
\bA b
\bbu
\bur
\brs
\bst
\bt s
\bsi
\biz
\bze
\be s
\bse
\bet
\bt t
\bto
\bo %
\b%d
\bd An informational message showing the DMA
p
\bpa
\ban
\bni
\bic
\bc:
\b: u
\bud
\bda
\bai
\bin
\bnt
\btr
\br Indicates a bug in the generic MSCP code.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: d
\bdr
\bri
\biv
\bve
\ber
\br b
\bbu
\bug
\bg,
\b, s
\bst
\bta
\bat
\bte
\be %
\b%d
\bd The driver has a bogus value for the con-
troller state. Something is quite wrong. This is immediately followed
u
\bud
\bda
\ba%
\b%d
\bd:
\b: p
\bpu
\bur
\brg
\bge
\be b
\bbd
\bdp
\bp %
\b%d
\bd 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.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: S
\bSE
\bET
\bTC
\bCT
\bTL
\bLR
\bRC
\bC f
\bfa
\bai
\bil
\ble
\bed
\bd:
\b: `
\b`d
\bde
\bet
\bta
\bai
\bil
\bl'
\b' The Set Controller Characteristics com-
mand (the last part of the controller initialisation sequence) failed.
The _
\bd_
\be_
\bt_
\ba_
\bi_
\bl message tells why.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: a
\bat
\btt
\bte
\bem
\bmp
\bpt
\bt t
\bto
\bo b
\bbr
\bri
\bin
\bng
\bg r
\bra
\ba%
\b%d
\bd o
\bon
\bn l
\bli
\bin
\bne
\be f
\bfa
\bai
\bil
\ble
\bed
\bd:
\b: `
\b`d
\bde
\bet
\bta
\bai
\bil
\bl'
\b' The drive could
not be brought on line. The _
\bd_
\be_
\bt_
\ba_
\bi_
\bl message tells why.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: r
\bra
\ba%
\b%d
\bd:
\b: u
\bun
\bnk
\bkn
\bno
\bow
\bwn
\bn t
\bty
\byp
\bpe
\be %
\b%d
\bd The type index of the named drive is not
known to the driver, so the drive will be ignored.
r
\bra
\ba%
\b%d
\bd:
\b: c
\bch
\bha
\ban
\bng
\bge
\bed
\bd t
\bty
\byp
\bpe
\bes
\bs!
\b! w
\bwa
\bas
\bs %
\b%d
\bd n
\bno
\bow
\bw %
\b%d
\bd A drive somehow changed from one kind
to another, e.g., from an RA80 to an RA60. The numbers printed are the
encoded media identifiers (see <_
\bv_
\ba_
\bx_
\b/_
\bm_
\bs_
\bc_
\bp_
\b._
\bh> for the encoding). The driv-
er believes the new type.
r
\bra
\ba%
\b%d
\bd:
\b: u
\bud
\bda
\ba%
\b%d
\bd,
\b, u
\bun
\bni
\bit
\bt %
\b%d
\bd,
\b, s
\bsi
\biz
\bze
\be =
\b= %
\b%d
\bd s
\bse
\bec
\bct
\bto
\bor
\brs
\bs The named drive is on the indi-
cated controller as the given unit, and has that many sectors of user-
file area. This is printed during configuration.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: a
\bat
\btt
\bte
\bem
\bmp
\bpt
\bt t
\bto
\bo g
\bge
\bet
\bt s
\bst
\bta
\bat
\btu
\bus
\bs f
\bfo
\bor
\br r
\bra
\ba%
\b%d
\bd f
\bfa
\bai
\bil
\ble
\bed
\bd:
\b: `
\b`d
\bde
\bet
\bta
\bai
\bil
\bl'
\b' A status request
failed. The _
\bd_
\be_
\bt_
\ba_
\bi_
\bl message should tell why.
r
\bra
\ba%
\b%d
\bd:
\b: b
\bba
\bad
\bd b
\bbl
\blo
\boc
\bck
\bk r
\bre
\bep
\bpo
\bor
\brt
\bt:
\b: %
\b%d
\bd 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 DEC
to forward the block with EVRLK.
r
\bra
\ba%
\b%d
\bd:
\b: s
\bse
\ber
\bri
\bio
\bou
\bus
\bs e
\bex
\bxc
\bce
\bep
\bpt
\bti
\bio
\bon
\bn r
\bre
\bep
\bpo
\bor
\brt
\bte
\bed
\bd I have no idea what this really means.
p
\bpa
\ban
\bni
\bic
\bc:
\b: u
\bud
\bda
\bar
\bre
\bep
\bpl
\bla
\bac
\bce
\be The controller reported completion of a REPLACE opera-
tion. The driver never issues any REPLACEs, so something is wrong.
p
\bpa
\ban
\bni
\bic
\bc:
\b: u
\bud
\bda
\bab
\bbb
\bb The controller reported completion of bad block related
I/O. The driver never issues any such, so something is wrong.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: l
\blo
\bos
\bst
\bt i
\bin
\bnt
\bte
\ber
\brr
\bru
\bup
\bpt
\bt The controller has gone out to lunch, and is being
reset to try to bring it back.
p
\bpa
\ban
\bni
\bic
\bc:
\b: m
\bms
\bsc
\bcp
\bp_
\b_g
\bgo
\bo:
\b: A
\bAE
\bEB
\bB_
\b_M
\bMA
\bAX
\bX_
\b_B
\bBP
\bP t
\bto
\boo
\bo s
\bsm
\bma
\bal
\bll
\bl You defined AVOID_EMULEX_BUG and
increased NCMDL2 and Emulex has new firmware. Raise AEB_MAX_BP or turn
u
\bud
\bda
\ba%
\b%d
\bd:
\b: u
\bun
\bni
\bit
\bt %
\b%d
\bd:
\b: u
\bun
\bnk
\bkn
\bno
\bow
\bwn
\bn m
\bme
\bes
\bss
\bsa
\bag
\bge
\be t
\bty
\byp
\bpe
\be 0
\b0x
\bx%
\b%x
\bx i
\big
\bgn
\bno
\bor
\bre
\bed
\bd The controller re-
sponded with a mysterious message type. See _
\b/_
\bs_
\by_
\bs_
\b/_
\bv_
\ba_
\bx_
\b/_
\bm_
\bs_
\bc_
\bp_
\b._
\bh for a list of
known message types. This is probably a controller hardware problem.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: u
\bun
\bni
\bit
\bt %
\b%d
\bd o
\bou
\but
\bt o
\bof
\bf r
\bra
\ban
\bng
\bge
\be The disk drive unit number (the unit plug)
is higher than the maximum number the driver allows (currently 7).
u
\bud
\bda
\ba%
\b%d
\bd:
\b: u
\bun
\bni
\bit
\bt %
\b%d
\bd n
\bno
\bot
\bt c
\bco
\bon
\bnf
\bfi
\big
\bgu
\bur
\bre
\bed
\bd,
\b, m
\bme
\bes
\bss
\bsa
\bag
\bge
\be i
\big
\bgn
\bno
\bor
\bre
\bed
\bd The named disk drive has
announced its presence to the controller, but was not, or cannot now be,
configured into the running system. _
\bM_
\be_
\bs_
\bs_
\ba_
\bg_
\be is one of `available atten-
tion' (an `I am here' message) or `stray response op 0x%x status 0x%x'
r
\bra
\ba%
\b%d
\bd:
\b: b
\bba
\bad
\bd l
\blb
\bbn
\bn (
\b(%
\b%d
\bd)
\b)?
\b? 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.
r
\bra
\ba%
\b%d
\bd:
\b: d
\bdu
\bup
\bpl
\bli
\bic
\bca
\bat
\bte
\be O
\bON
\bNL
\bLI
\bIN
\bNE
\bE i
\big
\bgn
\bno
\bor
\bre
\bed
\bd The drive has come on-line while already
on-line. This condition can probably be ignored (and has been).
r
\bra
\ba%
\b%d
\bd:
\b: i
\bio
\bo d
\bdo
\bon
\bne
\be,
\b, b
\bbu
\but
\bt n
\bno
\bo b
\bbu
\buf
\bff
\bfe
\ber
\br?
\b? Hardware trouble, or a bug; the drive has
finished an I/O request, but the response has an invalid (zero) command
E
\bEm
\bmu
\bul
\ble
\bex
\bx S
\bSC
\bC4
\b41
\b1/
\b/M
\bMS
\bS s
\bsc
\bcr
\bre
\bew
\bwu
\bup
\bp:
\b: u
\bud
\bda
\ba%
\b%d
\bd,
\b, g
\bgo
\bot
\bt %
\b%d
\bd c
\bco
\bor
\brr
\bre
\bec
\bct
\bt,
\b, t
\bth
\bhe
\ben
\bn c
\bch
\bha
\ban
\bng
\bge
\bed
\bd 0
\b0x
\bx%
\b%x
\bx t
\bto
\bo
0
\b0x
\bx%
\b%x
\bx You turned on 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.
p
\bpa
\ban
\bni
\bic
\bc:
\b: u
\bun
\bnr
\bre
\bec
\bco
\bov
\bve
\ber
\bra
\bab
\bbl
\ble
\be E
\bEm
\bmu
\bul
\ble
\bex
\bx s
\bsc
\bcr
\bre
\bew
\bwu
\bup
\bp You turned on AVOID_EMULEX_BUG, but
Emulex was too clever and avoided the avoidance. Try turning on
u
\bud
\bda
\ba%
\b%d
\bd:
\b: b
\bba
\bad
\bd r
\bre
\bes
\bsp
\bpo
\bon
\bns
\bse
\be p
\bpa
\bac
\bck
\bke
\bet
\bt i
\big
\bgn
\bno
\bor
\bre
\bed
\bd You turned on 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 fol-
lowed by a hex dump of the offending packet.
r
\bra
\ba%
\b%d
\bd:
\b: b
\bbo
\bog
\bgu
\bus
\bs R
\bRE
\bEP
\bPL
\bLA
\bAC
\bCE
\bE e
\ben
\bnd
\bd 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.
r
\bra
\ba%
\b%d
\bd:
\b: u
\bun
\bnk
\bkn
\bno
\bow
\bwn
\bn o
\bop
\bpc
\bco
\bod
\bde
\be 0
\b0x
\bx%
\b%x
\bx s
\bst
\bta
\bat
\btu
\bus
\bs 0
\b0x
\bx%
\b%x
\bx i
\big
\bgn
\bno
\bor
\bre
\bed
\bd The drive has reported
something that the driver cannot understand. Perhaps DEC has been inven-
tive, or perhaps your hardware is ill. This is followed by a hex dump of
r
\bra
\ba%
\b%d
\bd%
\b%c
\bc:
\b: h
\bha
\bar
\brd
\bd e
\ber
\brr
\bro
\bor
\br %
\b%s
\bsi
\bin
\bng
\bg f
\bfs
\bsb
\bbn
\bn %
\b%d
\bd [
\b[o
\bof
\bf %
\b%d
\bd-
\b-%
\b%d
\bd]
\b] (
\b(r
\bra
\ba%
\b%d
\bd b
\bbn
\bn %
\b%d
\bd c
\bcn
\bn %
\b%d
\bd t
\btn
\bn %
\b%d
\bd s
\bsn
\bn
%
\b%d
\bd)
\b).
\b. An unrecoverable error occurred during transfer of the specified
filesystem block number(s), which are logical block numbers on the indi-
cated 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.
u
\bud
\bda
\ba%
\b%d
\bd:
\b: %
\b%s
\bs e
\ber
\brr
\bro
\bor
\br d
\bda
\bat
\bta
\bag
\bgr
\bra
\bam
\bm 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 fol-
lowing 5 messages, depending on its type, and will always be followed by
a failure detail message (also listed below).
m
\bme
\bem
\bmo
\bor
\bry
\by a
\bad
\bdd
\bdr
\br 0
\b0x
\bx%
\b%x
\bx A host memory access error; this is the address
u
\bun
\bni
\bit
\bt %
\b%d
\bd:
\b: l
\ble
\bev
\bve
\bel
\bl %
\b%d
\bd r
\bre
\bet
\btr
\bry
\by %
\b%d
\bd,
\b, %
\b%s
\bs %
\b%d
\bd 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, 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).
u
\bun
\bni
\bit
\bt %
\b%d
\bd:
\b: %
\b%s
\bs %
\b%d
\bd 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 _
\bR_
\bA_
\b8_
\b1 _
\bM_
\ba_
\bi_
\bn_
\bt_
\be_
\bn_
\ba_
\bn_
\bc_
\be
_
\bG_
\bu_
\bi_
\bd_
\be, DEC order number AA-M879A-TC, in appendices E and F.
u
\bun
\bni
\bit
\bt %
\b%d
\bd:
\b: s
\bsm
\bma
\bal
\bll
\bl d
\bdi
\bis
\bsk
\bk e
\ber
\brr
\bro
\bor
\br,
\b, c
\bcy
\byl
\bl %
\b%d
\bd Yet another kind of disk error,
but for small disks. (`That's what it says, guv'nor. Dunnask me
u
\bun
\bni
\bit
\bt %
\b%d
\bd:
\b: u
\bun
\bnk
\bkn
\bno
\bow
\bwn
\bn e
\ber
\brr
\bro
\bor
\br,
\b, f
\bfo
\bor
\brm
\bma
\bat
\bt 0
\b0x
\bx%
\b%x
\bx A mysterious error: the given
format code is not known.
The detail messages are as follows:
s
\bsu
\buc
\bcc
\bce
\bes
\bss
\bs (
\b(%
\b%s
\bs)
\b) (
\b(c
\bco
\bod
\bde
\be 0
\b0,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) Everything worked, but the con-
troller thought it would let you know that something went wrong.
No matter what subcode, this can probably be ignored.
i
\bin
\bnv
\bva
\bal
\bli
\bid
\bd c
\bco
\bom
\bmm
\bma
\ban
\bnd
\bd (
\b(%
\b%s
\bs)
\b) (
\b(c
\bco
\bod
\bde
\be 1
\b1,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) This probably cannot oc-
cur unless the hardware is out; %s should be `invalid msg length',
meaning some command was too short or too long.
c
\bco
\bom
\bmm
\bma
\ban
\bnd
\bd a
\bab
\bbo
\bor
\brt
\bte
\bed
\bd (
\b(u
\bun
\bnk
\bkn
\bno
\bow
\bwn
\bn s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be)
\b) (
\b(c
\bco
\bod
\bde
\be 2
\b2,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) This should
never occur, as the driver never aborts commands.
u
\bun
\bni
\bit
\bt o
\bof
\bff
\bfl
\bli
\bin
\bne
\be (
\b(%
\b%s
\bs)
\b) (
\b(c
\bco
\bod
\bde
\be 3
\b3,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) The drive is offline, ei-
ther 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 diag-
nostics (`in diagnosis').
u
\bun
\bni
\bit
\bt a
\bav
\bva
\bai
\bil
\bla
\bab
\bbl
\ble
\be (
\b(u
\bun
\bnk
\bkn
\bno
\bow
\bwn
\bn s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be)
\b) (
\b(c
\bco
\bod
\bde
\be 4
\b4,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) The con-
troller has decided to report a perfectly normal event as an error.
m
\bme
\bed
\bdi
\bia
\ba f
\bfo
\bor
\brm
\bma
\bat
\bt e
\ber
\brr
\bro
\bor
\br (
\b(%
\b%s
\bs)
\b) (
\b(c
\bco
\bod
\bde
\be 5
\b5,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) 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 sec-
tors'), the drive is not formatted (`not formatted'), or the FCT
has an uncorrectable ECC error (`fct ecc').
w
\bwr
\bri
\bit
\bte
\be p
\bpr
\bro
\bot
\bte
\bec
\bct
\bte
\bed
\bd (
\b(%
\b%s
\bs)
\b) (
\b(c
\bco
\bod
\bde
\be 6
\b6,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) The drive is write pro-
tected, either by the front panel switch (`hardware') or via the
driver (`software'). The driver never sets software write protect.
c
\bco
\bom
\bmp
\bpa
\bar
\bre
\be e
\ber
\brr
\bro
\bor
\br (
\b(u
\bun
\bnk
\bkn
\bno
\bow
\bwn
\bn s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be)
\b) (
\b(c
\bco
\bod
\bde
\be 7
\b7,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) A compare op-
eration showed some sort of difference. The driver never uses com-
d
\bda
\bat
\bta
\ba e
\ber
\brr
\bro
\bor
\br (
\b(%
\b%s
\bs)
\b) (
\b(c
\bco
\bod
\bde
\be 7
\b7,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) 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 re-
placement, 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 ECC
logic. A `%d symbol ecc' error is a data error that can be (and
presumably has been) corrected by the 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 re-
h
\bho
\bos
\bst
\bt b
\bbu
\buf
\bff
\bfe
\ber
\br a
\bac
\bcc
\bce
\bes
\bss
\bs e
\ber
\brr
\bro
\bor
\br (
\b(%
\b%s
\bs)
\b) (
\b(c
\bco
\bod
\bde
\be %
\b%d
\bd,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) 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.
c
\bco
\bon
\bnt
\btr
\bro
\bol
\bll
\ble
\ber
\br e
\ber
\brr
\bro
\bor
\br (
\b(%
\b%s
\bs)
\b) (
\b(c
\bco
\bod
\bde
\be %
\b%d
\bd,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) The controller has de-
tected a hardware error in itself. A `serdes overrun' is a seri-
aliser / deserialiser overrun; `edc' probably stands for `error de-
tection code'; and `inconsistent internal data struct' is obvious.
d
\bdr
\bri
\biv
\bve
\be e
\ber
\brr
\bro
\bor
\br (
\b(%
\b%s
\bs)
\b) (
\b(c
\bco
\bod
\bde
\be %
\b%d
\bd,
\b, s
\bsu
\bub
\bbc
\bco
\bod
\bde
\be %
\b%d
\bd)
\b) 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 be-
nignly 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 prob-
S
\bSE
\bEE
\bE A
\bAL
\bLS
\bSO
\bO
disklabel(5), disklabel(8)
H
\bHI
\bIS
\bST
\bTO
\bOR
\bRY
\bY
The u
\bud
\bda
\ba driver appeared in 4.2BSD.
4th Berkeley Distribution June 5, 1993 7
projects / unix-history / blob