Please take a look at Most ports should be available for both the 2.2 and 3.0
branches, and many of them should work on 2.1.x systems as
well. Each time a FreeBSD release is made, a snapshot of the
ports tree at the time of release in also included in the
ports/ directory.
We also support the concept of a ``package'', essentially no
more than a gzipped binary distribution with a little extra
intelligence embedded in it for doing whatever custom installation
work is required. A package can be installed and uninstalled
again easily without having to know the gory details of which
files it includes.
Use the package installation menu in /stand/sysinstall
(under the post-configuration menu item) or invoke the
pkg_add(1) command on the specific package files you're
interested in installing. Package files can usually be identified by
their .tgz suffix and CDROM distribution people will have
a packages/All directory on their CD which contains such
files. They can also be downloaded over the net for various versions
of FreeBSD at the following locations:
or your nearest local mirror site.
Note that all ports may not be available as packages since
new ones are constantly being added. It is always a good
idea to check back periodically to see which packages are available
at the You are trying to run a package for 2.2/3.0 on a 2.1.x
system. Please take a look at the previous section and get
the correct port/package for your system.
You don't have a math co-processor, right?
You will need to add the alternative math emulator to your kernel;
you do this by adding the following to your kernel config file
and it will be compiled in.
You first need to edit the /etc/sysconfig
(or It will load the You'll then need to set up /compat/ibcs2/dev to look like:
You just need socksys to go to After installing the inn package or port, an excellent place to
start is Use the Port, Luke! A pre-patched version of Apache is available in the ports tree.
There are currently three active/semi-active branches in the FreeBSD
To make a release you need to do three things: First, you need to
be running a kernel with the Second, you have to have the whole CVS repository at hand.
To get this you can use Then run Finally, you need a chunk of empty space to build into. Let's
say it's in /some/big/filesystem, and from the example
above you've got the CVS repository in /home/ncvs:
An entire release will be built in
/some/big/filesystem/release and you will have a full FTP-type
installation in /some/big/filesystem/release/R/ftp when you're
done. If you want to build your SNAP along some other branch than
-current, you can also add
The entire process of creating installation disks and source and
binary archives is automated by various targets in
/usr/src/release/Makefile. The information there should
be enough to get you started. However, it should be said that this
involves doing a ``make world'' and will therefore take up a lot of
time and disk space.
Yes, this is the general idea; as its name might suggest,
``make world'' rebuilds every system binary from scratch, so you can be
certain of having a clean and consistent environment at the end (which
is why it takes so long).
If the environment variable ${DESTDIR}.
Some random combination of shared libraries modifications and
program rebuilds can cause this to fail in ``
The Adaptec 1542 SCSI host adapters allow the user to configure
their bus access speed in software. Previous versions of the
1542 driver tried to determine the fastest usable speed and set
the adapter to that. We found that this breaks some users'
systems, so you now have to define the ``
Yes, you can do this
Newer BSD based systems have a ``Here is an example from /usr/src/Makefile.
Please take a look at And thanks for the thought!
By: In a nutshell, there a few I/O ports that all of the PnP boards
respond to when the host asks if anyone is out there. So when
the PnP probe routine starts, he asks if there are any PnP boards
present, and all the PnP boards respond with their model # to
a I/O read of the same port, so the probe routine gets a wired-OR
``yes'' to that question. At least one bit will be on in that
reply. Then the probe code is able to cause boards with board
model IDs (assigned by Microsoft/Intel) lower than X to go
``off-line''. It then looks to see if any boards are still
responding to the query. If the answer was ``The IDs are two 32-bit fields (hence 2ˆ64) + 8 bit checksum.
The first 32 bits are a vendor identifier. They never come out
and say it, but it appears to be assumed that different types of
boards from the same vendor could have different 32-bit vendor
ids. The idea of needing 32 bits just for unique manufacturers
is a bit excessive.
The lower 32 bits are a serial #, ethernet address, something
that makes this one board unique. The vendor must never produce
a second board that has the same lower 32 bits unless the upper
32 bits are also different. So you can have multiple boards of
the same type in the machine and the full 64 bits will still be
unique.
The 32 bit groups can never be all zero. This allows the
wired-OR to show non-zero bits during the initial binary search.
Once the system has identified all the board IDs present, it will
reactivate each board, one at a time (via the same I/O ports),
and find out what resources the given board needs, what interrupt
choices are available, etc. A scan is made over all the boards
to collect this information.
This info is then combined with info from any ECU files on the
hard disk or wired into the MLB BIOS. The ECU and BIOS PnP
support for hardware on the MLB is usually synthetic, and the
peripherals don't really do genuine PnP. However by examining
the BIOS info plus the ECU info, the probe routines can cause the
devices that are PnP to avoid those devices the probe code cannot
relocate.
Then the PnP devices are visited once more and given their I/O,
DMA, IRQ and Memory-map address assignments. The devices will
then appear at those locations and remain there until the next
reboot, although there is nothing that says you can't move them
around whenever you want.
There is a lot of oversimplification above, but you should get
the general idea.
Microsoft took over some of the primary printer status ports to
do PnP, on the logic that no boards decoded those addresses for
the opposing I/O cycles. I found a genuine IBM printer board
that did decode writes of the status port during the early PnP
proposal review period, but MS said ``tough''. So they do a
write to the printer status port for setting addresses, plus that
use that address +
Several groups of people have expressed interest in working on
multi-architecture ports for FreeBSD and the FreeBSD/AXP (ALPHA)
port is one such effort which has been quite successful, now
available in 3.0 SNAPshot release form at This depends on whether or not you plan on making the driver
publicly available. If you do, then please send us a copy of the
driver source code, plus the appropriate modifications to
files.i386, a sample configuration file entry, and the
appropriate
In answer to the question of alternative layout policies for
directories, the scheme that is currently in use is unchanged
from what I wrote in 1983. I wrote that policy for the original
fast filesystem, and never revisited it. It works well at keeping
cylinder groups from filling up. As several of you have noted,
it works poorly for find. Most filesystems are created from
archives that were created by a depth first search (aka ftw).
These directories end up being striped across the cylinder groups
thus creating a worst possible senario for future depth first
searches. If one knew the total number of directories to be
created, the solution would be to create (total / fs_ncg) per
cylinder group before moving on. Obviously, one would have to
create some heuristic to guess at this number. Even using a
small fixed number like say 10 would make an order of magnitude
improvement. To differentiate restores from normal operation
(when the current algorithm is probably more sensible), you
could use the clustering of up to 10 if they were all done
within a ten second window. Anyway, my conclusion is that this
is an area ripe for experimentation. Kirk McKusick, September 1998
[This section was extracted from a mail written by
[<ben@rosengart.com> posted the following panic
message]
[When] you see a message like this, it's not enough to just
reproduce it and send it in. The instruction pointer value that
I highlighted up there is important; unfortunately, it's also
configuration dependent. In other words, the value varies
depending on the exact kernel image that you're using. If you're
using a GENERIC kernel image from one of the snapshots, then
it's possible for somebody else to track down the offending
function, but if you're running a custom kernel then only
What you should do is this:
I see people constantly show panic messages like this but
rarely do I see someone take the time to match up the
instruction pointer with a function in the kernel symbol table.
The best way to track down the cause of a panic is by
capturing a crash dump, then using
- In any case, the method I nornally use is this:
+ In any case, the method I normally use is this:
[Note: currently, on 3.0-BETA, you must use
Note that YOU DO To make sure you capture a crash dump, you need edit
/etc/rc.conf and set /etc/rc.conf, the /var/crash.
NOTE: FreeBSD crash dumps are usually the same size as the
physical RAM size of your machine. That is, if you have 64MB of
- RAM, you will geta 64MB crash dump. Therefore you must make sure
+ RAM, you will get a 64MB crash dump. Therefore you must make sure
there's enough space in /var/crash to hold the dump.
Alternatively, you run Once you have recovered the crash dump, you can get a stack
trace with
Note that there may be several screens worth of information;
ideally you should use Now, if you're really insane and have a second computer, you
can also configure [Bill adds: "I forgot to mention one thing: if you have
DDB enabled and the kernel drops into the debugger, you can
force a panic (and a crash dump) just by typing 'panic' at the
ddb prompt. It may stop in the debugger again during the panic
phase. If it does, type 'continue' and it will finish the crash
dump." -ed]
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)
and changing the values of AWRE and ARRE from 0 to 1:-
The following paragrahs were submitted by
For IDE drives, any bad block is usually a sign of potential trouble.
All modern IDE drives come with internal bad-block remapping turned
on. All IDE hard drive manufacturers today offer extensive
warranties and will replace drives with bad blocks on them.
If you still want to attempt to rescue an IDE drive with bad blocks,
you can attempt to download the IDE drive manufacturer's IDE diagnostic
program, and run this against the drive. Sometimes these programs can
be set to force the drive electronics to rescan the drive for bad blocks
and lock them out.
For ESDI, RLL and MFM drives, bad blocks are a normal part of the
drive and are no sign of trouble, generally. With a PC, the disk drive
controller card and BIOS handle the task of locking out bad sectors.
This is fine for operating systems like DOS that use BIOS code to
access the disk. However, FreeBSD's disk driver does not go through
BIOS, therefore a mechanism, bad144, exists that replaces this
functionality. bad144 only works with the wd driver,
it is NOT able to be used with SCSI. bad144 works by entering all bad
sectors found into a special file.
One caveat with bad144 - the bad block special file is placed on the
last track of the disk. As this file may possibly contain a listing for
a bad sector that would occur near the beginning of the disk, where the
/kernel file might be located, it therefore must be accessible to the
bootstrap program that uses BIOS calls to read the kernel file. This
means that the disk with bad144 used on it must not exceed 1024
cylinders, 16 heads, and 63 sectors. This places an effective limit
of 500MB on a disk that is mapped with bad144.
To use bad144, simply set the "Bad Block" scanning to ON in the
FreeBSD fdisk screen during the initial install. This works up through
FreeBSD 2.2.7. The disk must have less than 1024 cylinders. It is
generally recommended that the disk drive has been in operation for at
least 4 hours prior to this to allow for thermal expansion and track
wandering.
If the disk has more than 1024 cylinders (such as a large ESDI drive)
the ESDI controller uses a special translation mode to make it work
under DOS. The wd driver understands about these translation modes,
IF you enter the "translated" geometry with the "set geometry" command
in fdisk. You must also NOT use the "dangerously dedicated" mode of
creating the FreeBSD partition, as this ignores the geometry. Also,
even though fdisk will use your overridden geometry, it still knows the
true size of the disk, and will attempt to create a too large FreeBSD
partition. If the disk geometry is changed to the translated geometry,
the partition MUST be manually created with the number of blocks.
A quick trick to use is to set up the large ESDI disk with the ESDI
controller, boot it with a DOS disk and format it with a DOS partition.
Then, boot the FreeBSD install and in the fdisk screen, read off and
write down the blocksize and block numbers for the DOS partition. Then,
reset the geometry to the same that DOS uses, delete the DOS partition,
and create a "cooperative" FreeBSD partition using the blocksize you
recorded earlier. Then, set the partition bootable and turn on bad
block scanning. During the actual install, bad144 will run first,
before any filesystems are created. (you can view this with an Alt-F2)
If it has any trouble creating the badsector file, you have set too
large a disk geometry - reboot the system and start all over again
(including repartitioning and reformatting with DOS).
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.
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.