autoconfig(8) [bsd man page]
AUTOCONFIG(8) System Manager's Manual AUTOCONFIG(8) NAME
autoconfig - configure the running system to the hardware SYNOPSIS
autoconfig [-i ifile] [-n nfile] [-k kfile] [-v] [-d] [-c] DESCRIPTION
Autoconfig is called by init(8) to configure the currently running system. Init checks the exit status of autoconfig to determine if the configuration was successful. Autoconfig reads the device table /etc/dtab for a list of devices which may be on the system. It first ver- ifies that the kernel has an attach routine for each device (and therefore has a device handler) and that the kernel has a probe routine. It then checks each of these devices to see if it is present, and if it is, attempts to make it interrupt (if possible) to verify that the interrupt vector is correct. The interrupt vector is checked to see that it has not previously been used. An interrupt through any of the device's consecutive vectors is sufficient. Devices which use programmable vectors (MSCP and TMSCP) are permitted to have a value of 0 in the dtab vector field. This special value tells autoconfig to call the kernel's get next available vector routine and assign that to the device. For programmable vector devices if the dtab vector field is non 0 then the value specified in the dtab file is used. In both cases the driver is called at its xxVec() rou- tine with the vector being assigned to the device. If the address and vector are correct, it then attaches the device by passing the address and unit number to the kernel's attach routine and setting up the interrupt vector according to the interrupt handlers and priority listed in the device table. If the unit number is given as a '?' in the device table, it will be assigned the next available unit number if the device exists. If the device is not present or the vector is incorrect, and if the unit number was specified (not a '?'), then the kernel is notified that that unit is not present, preventing accesses to a nonexistent device address. There are only a few flags which are mostly useful for debugging but for completeness, here they are. -i ifile Use ifile instead of /etc/dtab as the device table. -n nfile Use nfile instead of /unix for finding the namelist of the currently running kernel. -k kfile The file kfile should be used instead of /dev/kmem to alter and read kernel memory. -v Verbose output, indicates reason for rejecting any device in the device table. Normally only attached devices are reported. -c Report error messages for devices skipped because of problems with their interrupt vectors. -d Turn on debugging mode. Shows many gory details of autoconfig's internal processing. BUGS
Devices of the same type must be listed with ascending unit numbers or with wildcards. Disks that could be root devices must have their addresses and vectors initialized in the kernel; the kernel uses a root attach entry in the block device switch to allow disk drivers to do any probes necessary before autoconfiguration. Must be run only by init(8). There is a flag set in the kernel that autoconfig has already run, running autoconfig a second time results in the error: "namelist doesn't match running kernel." Autoconfig attempts to open /dev/kmem for write. If the kernel is in securelevel 1 or higher the open of /dev/kmem will fail. FILES
/etc/dtab device table /unix /dev/kmem SEE ALSO
ucall(2), nlist(3), dtab(5) 3rd Berkeley Distribution December 30, 1992 AUTOCONFIG(8)
Check Out this Related Man Page
TMSCP(4) Kernel Interfaces Manual TMSCP(4) NAME
tmscp - DEC TMSCP magtape interface SYNOPSIS
/sys/conf/SYSTEM: NTMSCP 1 # TMSCP controllers NTMS 1 # TMSCP drives TMSCP_DEBUG NO # debugging code in in TMSCP drive (EXPENSIVE) /etc/dtab: #Name Unit# Addr Vector Br Handler(s) # Comments tms ? 174500 260 5 tmsintr # tmscp driver tms ? 164334 0 5 tmsintr # alternate major device number(s): raw: 23 block: 12 minor device encoding: bit: |7 | 6 | 5 | 4 | 3 | 2 | 1 | 0| ------------------------------- C C X D D N U U C = Controller # (max of 4 controllers) D = Density N = Norewind on close U = Unit (drive) number (max of 4 drives per controller) DESCRIPTION
Tape controllers compatible with the DEC Tape Mass Storage Control Protocol (TMSCP) architecture such as the TU81 and the TK50 provide a standard tape drive interface as described in mtio(4). The controller communicates with the host through a packet oriented protocol. Con- sult the file <pdp/tmscp.h> for a detailed description of this protocol. FILES
/dev/MAKEDEV script to create special files /dev/MAKEDEV.local script to localize special files The vector specified in /etc/dtab may be given as an explicit value in which case autoconfig(8) will attempt to allocate the specified vec- tor. The vector may also be (if the system is at revision level 100 or higher) given as 0 - in which case autoconfig(8) will request the kernel to allocate the next available vector (beginning at 01000 and proceeding downward) which autoconfig(8) will initialize. Multiple drives on a single controller are supported. Multiple controllers are also supported. Density selection is specified by bits 3 and 4 in the minor device number. A value of 0 requests the lowest density of a drive and a value of 3 the highest density. Values of 1 and 2 are essentially equivalent (because because TMSCP only defines values for three densities) and request the middle density (for tri-density tape drives). DIAGNOSTICS
tms: !drives. Not enough drives were declared when the kernel was built. The NTMS parameter in the kernel config file needs to be increased by at least one. tms%d stepN init failed: sa %x. Step N of the 4 step initialization sequence has failed. tms%d: random intr. An unexpected interrupt was received. This is indicative of some other device using the same interrupt vector as the TMSCP controller. The interrupt is ignored. tms%d Ver %d Mod %d. The version and model number of the controller are displayed when the controller is initialized. This is an informa- tion message and not an error. tms%d: state %d. The controller state is not one of the 4 initialization states or the RUN state. This indicates a serious problem in the driver and possibly the hardware. tms%d: fatal error %x. The controller detected a ``fatal error'' in the status returned to the host. The contents of the status register are displayed. tms%d init fail. The controller failed to initialize. Indicative of a hardware problem. tms%d,%d flush fail. The cache failed to flush during a close operation. Data loss is possible in this case. tms%d,%d: sa %x state %d. A fatal error. The controller will be reset in an attempt to resume operation. tms ioctl. An invalid internal ioctl function call has been made. This is a driver bug. tms%d,%d inv end. An invalid end (completion) code has been detected. A drive has returned 0 as the opcode originally issued. This is a hardware problem. tms%d,%d bad rsp: %x. An unrecognized response has been received. This is a driver bug. tms%d,%d cache lost The cache on the drive has been lost. Data loss is likely. Usually due to a hardware problem. The following error is produced when a TMSCP error log datagram is received: tms%d,%d dgram fmt=%x evt=%x grp=%x flg=%x pos=%D. Earlier versions of the driver consumed a noticeable amount of kernel D-space decoding and pretty printing more detailed information. This has been removed in favor of a shorter message. In the future an error log daemon will be written and the datagrams from the MSCP and TMSCP drivers passed to it for analysis. SEE ALSO
mt(1), tar(1), tp(1), mtio(4), tm(4), ts(4), ut(4), dmesg(8), dtab(5), autoconfig(8) BUGS
If any non-data error is encountered on non-raw tape, it refuses to do anything more until closed. On quad-density tape drives (the Kennedy 9662 for example) the middle density of 3200bpi is not host selectable (it can be manually selected from the drive's front panel) because TMSCP only defines 800, 1600 and 6250bpi. 3rd Berkeley Distribution December 22, 1995 TMSCP(4)