The system encountered a hardware fault in attempting to access a parameter of a programming function.
Check the address to see if it resulted from supplying the wrong device or option to a command. If that is not the problem, contact the vendor or author of the program for an update.
This error could occur any time a function that takes a pointer argument is passed an invalid address. Because processors differ in their ability to detect bad addresses, on some architectures, passing bad addresses can result in undefined behaviors.
The symbolic name for this error is EFAULT, errno=14.
While checking inode link counts during phase 4, fsck(1M) found a file (or directory) that either does not exist or exists somewhere else.
To clear the inode of its reference to this file or directory, answer "yes." With the -p (preen) option, fsck(1M) automatically clears bad or duplicate file references. Answering "yes" to this question seldom causes a problem.
Generally this message is a program error, not a usage error.
Contact the vendor or author of the program for an update.
Either a file descriptor refers to no open file, or a read(2)--or a write(2)--request is made to a file that is open only for writing or reading.
The symbolic name for this error is EBADF, errno=9.
Upon detecting an out-of-range block, fsck(1M) prints the bad block number and its containing inode (after I=).
In fsck(1M) phases 2 and 4, you decide whether or not to clear these bad blocks. Before committing to repair with fsck(1M), you could determine which file contains this inode by passing the inode number to the ncheck(1M) command:
# ncheck -i inum filesystem |
For more information, see the chapter on checking file system integrity in the System Administration Guide, Volume 1.
In this situation, X.400 software had been working without problems. Suddenly, the message exchanges failed in ma_start_delivery(). It was returning an error code of 100 (BAD_MESSAGE).
The ma_start_delivery() call fails when trying to exchange a file of more than 900 bytes.
X.400 was restarted with the wrong umask. To fix, set the umask to 0022 and restart the software.
This message from the memory management system often appears with parity errors and indicates a bad memory module or chip at the position listed. Data loss is possible, if the problem occurs other than at boot time.
Replace the memory module or chip at the indicated position. Refer to the vendor's hardware manual for help finding this location.
This message is apparently only used in NIS+ to indicate corrupted or missing tables.
The symbolic name for this error is EBADR, errno=51.
This message from fsck(1M) indicates that a file system's super block is damaged beyond repair and must be replaced. At boot time (with the -p option) this message is prefaced by the file system's device name. After this message comes the actual damage recognized (see Action). Unfortunately, fsck(1M) does not print the number of the damaged super block.
The most common cause of this error is overlapping disk partitions. Do not immediately rerun fsck(1M) as suggested by the lines that display after the error message. First, make sure that you have a recent backup of the file system involved; if not, try to back up the file system now using ufsdump(1M). Then, run the format(1M) command, select the disk involved, and print out the partition information.
# format : N > partition > print |
# newfs -N /dev/dsk/device |
# fsck -o b=NNNN /dev/dsk/device |
Specific reasons for a damaged super block include: a wrong magic number, an out-of-range number of cylinder groups (NCG) or cylinders per group (CPG), the wrong number of cylinders, a preposterously large super block size, and trashed values in super block. These reasons are generally not meaningful, because a corrupt super block is usually extremely corrupt.
For more information on bad super blocks, see the sections on restoring bad super blocks in the System Administration Guide, Volume 1. If you are using AnswerBook online documentation, "super block" is a good search string.
A bad trap can indicate faulty hardware or a mismatch between hardware and its configuration information. Data loss is possible if the problem occurs other than at boot time.
If you recently installed new hardware, verify that the software was correctly configured. Check the kernel traceback displayed on the console to see which device generated the trap. If the configuration files are correct, you probably have to replace the device.
In some cases, the bad trap message indicates a bad or down-rev CPU.
A hardware processor trap occurred, and the kernel trap handler was unable to restore the system state. This message is a fatal error that usually precedes a panic, after which the system performs a sync, dump, and reboot. The following conditions can cause a bad trap: a system text or data access fault, a system data alignment error, or certain kinds of user software traps.
This Bourne shell message indicates a classic "no memory" error. While trying to load the program specified after the first colon, the shell noticed that the system ran out of virtual memory (swap space).
For information on reconfiguring your system to add more swap space, refer to "Not enough space".
A raw (character special) device was specified where a block device was required, such as during a call to the mount(1M) command.
To see which block devices are available, use ls -l to look in /devices. Then specify a block device instead of a character device. Block device modes start with a b, whereas raw character device modes start with a c.
The symbolic name of this error is ENOTBLK, errno=15.
This message always appears at the beginning of rebooting. If there is a problem, the system hangs, and no other messages appear. This condition is caused by conflicting SCSI targets for the boot device, which is almost always target 3.
The boot device is usually the machine's internal disk drive, target 3. Make sure that external and secondary disk drives are targeted to 1, 2, or 0, and do not conflict with each other. Also make sure that the tape drives are targeted to 4 or 5, and CD drives to 6, avoiding any conflict with each other or with the disk drives. You can set a device's target number using push-button switches or a dial on the back near the SCSI cables. If the targeting of the internal disk drive is in question, check it by powering off the machine, removing all external drives, turning the power on, and running the probe-scsi-all or probe-scsi command from the PROM monitor.
This message from the wall(1M) command is transmitted to all users logged into a system. You could see it during a rlogin(1) or telnet(1) session, or on terminals connected to a timesharing system.
Carefully read the broadcast message. Often this broadcast is followed by a shutdown warning.
For details about system shutdown, refer to "The system will be shut down in int minutes".
For more information on bringing down the system, see the section on halting the system in the System Administration Guide, Volume 1. If you are using AnswerBook online documentation, "halting the system" is a good search string.
This condition is often normal, and the message is merely informational (as when piping many lines to the head(1) program). The condition occurs when a write on a pipe does not find a reading process. This usually generates a signal to the executing program, but this message displays when the program ignores the signal.
Check the process at the end of the pipe to see why it exited.
The symbolic name of this error is EPIPE, errno=32.
A process has received a signal indicating that it attempted to perform I/O to a device that is restricted or that does not exist. This message is usually accompanied by a core dump, except on read-only file systems.
Use a debugger to examine the core file and determine what program fault or system problem led to the bus error. If possible, check the program's output files for data corruption that might have occurred before the bus error.
Bus errors can result from either a programming error or device corruption on your system. Some common causes of bus errors are: invalid file descriptors, unreasonable I/O requests, bad memory allocation, misaligned data structures, compiler bugs, and corrupt boot blocks.