diff --git a/FAQ/troubleshoot.sgml b/FAQ/troubleshoot.sgml index 9807002996..3d1b9712f0 100644 --- a/FAQ/troubleshoot.sgml +++ b/FAQ/troubleshoot.sgml @@ -1,406 +1,426 @@ - + Troubleshooting I have bad blocks on my hard drive!

With SCSI drives, the drive should be capable of re-mapping these automatically. However, many drives are shipped with this feature disabled, for some mysterious reason...

To enable this, you'll need to edit the first device page mode, which can be done on FreeBSD by giving the command (as root) scsi -f /dev/rsd0c -m 1 -e -P 3

and changing the values of AWRE and ARRE from 0 to 1:- AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1

For other drive types, you are dependent on support from the operating system. Unfortunately, the ``bad144'' command that FreeBSD supplies for this purpose needs a considerable amount of work done on it. In other words, it doesn't work. If you're lucky, you can create a file that contains the bad blocks and stuff it away with a name like ".BADBLOCKS". This is how I got 386BSD Patchkit 24 completed. IDE drives are If remapping is enabled and you are seeing bad blocks, consider replacing the drive. The bad blocks will only get worse as time goes on. FreeBSD does not recognize my Bustek 742a EISA SCSI!

This info is specific to the 742a but may also cover other Buslogic cards. (Bustek = Buslogic)

There are 2 general ``versions'' of the 742a card. They are hardware revisions A-G, and revisions H - onwards. The revision letter is located after the Assembly number on the edge of the card. The 742a has 2 ROM chips on it, one is the BIOS chip and the other is the Firmware chip. FreeBSD doesn't care what version of BIOS chip you have but it does care about what version of firmware chip. Buslogic will send upgrade ROMS out if you call their tech support dept. The BIOS and Firmware chips are shipped as a matched pair. You must have the most current Firmware ROM in your adapter card for your hardware revision.

The REV A-G cards can only accept BIOS/Firmware sets up to 2.41/2.21. The REV H- up cards can accept the most current BIOS/Firmware sets of 4.70/3.37. The difference between the firmware sets is that the 3.37 firmware supports ``round robin''

The Buslogic cards also have a serial number on them. If you have a old hardware revision card you can call the Buslogic RMA department and give them the serial number and attempt to exchange the card for a newer hardware revision. If the card is young enough they will do so.

FreeBSD 2.1 only supports Firmware revisions 2.21 onward. If you have a Firmware revision older than this your card will not be recognized as a Buslogic card. It may be recognized as an Adaptec 1540, however. The early Buslogic firmware contains an AHA1540 ``emulation'' mode. This is not a good thing for an EISA card, however.

If you have an old hardware revision card and you obtain the 2.21 firmware for it, you will need to check the position of jumper W1 to B-C, the default is A-B.

The 742a EISA cards never had the ``>16MB'' problem mentioned in the section . This is a problem that occurs with the Vesa-Local Buslogic SCSI cards. My HP Netserver's SCSI controller is not detected!

This is basically a known problem. The EISA on-board SCSI controller in the HP Netserver machines occupies EISA slot number 11, so all the ``true'' EISA slots are in front of it. Alas, the address space for EISA slots >= 10 collides with the address space assigned to PCI, and FreeBSD's auto-configuration currently cannot handle this situation very well.

So now, the best you can do is to pretend there is no address range clash :), by bumping the kernel option .

Of course, this does present you with a chicken-and-egg problem when installing on such a machine. In order to work around this problem, a special hack is available inside UserConfig. Do not use the ``visual'' interface, but the plain command-line interface there. Simply type eisa 12 quit

at the prompt, and install your system as usual. While it's recommended you compile and install a custom kernel anyway, now also understands to save this value.

Hopefully, future versions will have a proper fix for this problem.

for more info. What's up with this CMD640 IDE controller?

It's broken. It cannot handle commands on both channels simultaneously.

There's a workaround available now and it is enabled automatically if your system uses this chip. For the details refer to the manual page of the disk driver (man 4 wd).

If you're already running FreeBSD 2.2.1 or 2.2.2 with a CMD640 IDE controller and you want to use the second channel, build a new kernel with I keep seeing messages like ``

This is usually caused by an interrupt conflict (e.g., two boards using the same IRQ). FreeBSD prior to 2.0.5R used to be tolerant of this, and the network driver would still function in the presence of IRQ conflicts. However, with 2.0.5R and later, IRQ conflicts are no longer tolerated. Boot with the -c option and change the ed0/de0/... entry to match your board.

If you're using the BNC connector on your network card, you may also see device timeouts because of bad termination. To check this, attach a terminator directly to the NIC (with no cabel) and see if the error messages go away.

Some NE2000 compatible cards will give this error if there is no link on the UTP port or if the cable is disconnected. When I mount a CDROM, I get ``Incorrect super block''.

You have to tell the type of the device that you want to mount. By default, will assume the filesystem is of type ``. This does, of course, assume that the CDROM contains an ISO 9660 filesystem, which is what most CDROMs have. As of 1.1R, FreeBSD automatically understands the Rock Ridge (long filename) extensions as well.

As an example, if you want to mount the CDROM device, ``/dev/cd0c'', under /mnt, you would execute: mount -t cd9660 /dev/cd0c /mnt

Note that your device name (``/dev/cd0c'' in this example) could be different, depending on the CDROM interface. Note that the `` mount_cd9660 /dev/cd0c /mnt When I mount a CDROM, I get ``Device not configured''.

This generally means that there is no CDROM in the CDROM drive, or the drive is not visible on the bus. Feed the drive something, and/or check its master/slave status if it is IDE (ATAPI). It can take a couple of seconds for a CDROM drive to notice that it's been fed, so be patient.

Sometimes a SCSI CD-ROM may be missed because it hadn't enough time to answer the bus reset. In you have a SCSI CD-ROM please try to add the following symbol into your kernel configuration file and recompile. options "SCSI_DELAY=15" My printer is ridiculously slow. What can I do ?

If it's parallel, and the only problem is that it's terribly slow, try setting your printer port into ``polled'' mode: lptcontrol -p

Some newer HP printers are claimed not to work correctly in interrupt mode, apparently due to some (not yet exactly understood) timing problem. My programs occasionally die with ``Signal 11'' errors.

This can be caused by bad hardware (memory, motherboard, etc.). Try running a memory-testing program on your PC. Note that, even though every memory testing program you try will report your memory as being fine, it's possible for slightly marginal memory to pass all memory tests, yet fail under operating conditions (such as during bus mastering DMA from a SCSI controller like the Adaptec 1542, when you're beating on memory by compiling a kernel, or just when the system's running particularly hot).

The SIG11 FAQ (listed below) points up slow memory as being the most common problem. Increase the number of wait states in your BIOS setup, or get faster memory.

For me the guilty party has been bad cache RAM or a bad on-board cache controller. Try disabling the on-board (secondary) cache in the BIOS setup and see if that solves the problem.

There's an extensive FAQ on this at When I boot, the screen goes black and loses sync!

This is a known problem with the ATI Mach 64 video card. The problem is that this card uses address driver it will touch this port even if you don't have the fourth serial port, and Until the bug has been fixed, you can use this workaround: Enter Disable no problems. Type exit to continue booting.

If you want to be able to use your serial ports, you'll have to build a new kernel with the following modification: in /usr/src/sys/i386/isa/sio.c find the one occurrence of the string Even after applying these workarounds, you may still find that X Window does not work properly. Some newer ATI Mach 64 video cards (notably ATI Mach Xpression) do not run with the current version of and following the links to the new beta release. Get the following files:

AccelCards, BetaReport, Cards, Devices, FILES, README.ati, README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc, X312BMa64.tgz

Replace the older files with the new versions and make sure you run again. I have 128 MB of RAM but the system only uses 64 MB.

Due to the manner in which FreeBSD gets the memory size from the BIOS, it can only detect 16 bits worth of Kbytes in size (65535 Kbytes = 64MB) (or less... some BIOSes peg the memory size to 16M). If you have more than 64MB, FreeBSD will attempt to detect it; however, the attempt may fail.

To work around this problem, you need to use the kernel option specified below. There is a way to get complete memory information from the BIOS, but we don't have room in the bootblocks to do it. Someday when lack of room in the bootblocks is fixed, we'll use the extended BIOS functions to get the full memory information...but for now we're stuck with the kernel option. options "MAXMEM=<n>"

Where FreeBSD 2.0 panics with ``kmem_map too small!''

The panic indicates that the system ran out of virtual memory for network buffers (specifically, mbuf clusters). You can increase the amount of VM available for mbuf clusters by adding:

options "NMBCLUSTERS=<n>"

to your kernel config file, where <n> is a number in the range 512-4096, depending on the number of concurrent TCP connections you need to support. I'd recommend trying 2048 - this should get rid of the panic completely. You can monitor the number of mbuf clusters allocated/in use on the system with . ``CMAP busy panic'' when rebooting with a new kernel.

The logic that attempts to detect an out of data /var/db/kvm_*.db files sometimes fails and using a mismatched file can sometimes lead to panics.

If this happens, reboot single-user and do: rm /var/db/kvm_*.db ahc0: brkadrint, Illegal Host Access at seqaddr 0x0

This is a conflict with an Ultrastor SCSI Host Adapter.

During the boot process enter the kernel configuration menu and disable , which is causing the problem. Sendmail says ``mail loops back to myself''

This is answered in the sendmail FAQ as follows:- * I'm getting "Local configuration error" messages, such as: 553 relay.domain.net config error: mail loops back to myself 554 ... Local configuration error How can I solve this problem? You have asked mail to the domain (e.g., domain.net) to be forwarded to a specific host (in this case, relay.domain.net) by using an MX record, but the relay machine doesn't recognize itself as domain.net. Add domain.net to /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" to /etc/sendmail.cf.

The current version of the is no longer maintained with the sendmail release. It is however regularly posted to , , , , and . You can also receive a copy via email by sending a message to with the command "send usenet/news.answers/mail/sendmail-faq" as the body of the message. + + Full screen applications on remote machines misbehave! + +

The remote machine may be setting your terminal type + to something other than the cons25 terminal type used + by the FreeBSD console. +

There are a number of work-arounds for this problem: + + After logging on to the remote machine, set your TERM shell + variable to either ansi or sco. + Use a VT100 emulator like + locally. screen offers you the ability to run + multiple concurrent sessions from one terminal, and is a neat + program in its own right. + Install the cons25 terminal database entry on + the remote machine. + Fire up X and login to the remote machine from an + xterm. +