diff --git a/FAQ/hackers.sgml b/FAQ/hackers.sgml index d65aca28a504..9394caff52f5 100644 --- a/FAQ/hackers.sgml +++ b/FAQ/hackers.sgml @@ -1,486 +1,487 @@ - + For serious FreeBSD hackers only What are SNAPs and RELEASEs?

There are currently three active/semi-active branches in the FreeBSD :

Right now, The How do I make my own custom release?

To make a release you need to do three things: First, you need to be running a kernel with the driver configured in. Add this to your kernel config file and build a new kernel: pseudo-device vn #Vnode driver (turns a file into a device)

Second, you have to have the whole CVS repository at hand. To get this you can use but in your supfile set the release name to cvs and remove any tag or date fields: *default prefix=/home/ncvs *default base=/a *default host=cvsup.FreeBSD.org *default release=cvs *default delete compress use-rel-suffix ## Main Source Tree src-all src-eBones src-secure # Other stuff ports-all www doc-all

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: setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs cd /usr/src/release make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release

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 How do I create customized installation disks?

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. ``make world'' clobbers my existing installed binaries.

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 `` When my system boots, it says ``(bus speed defaulted)''.

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 `` Can I follow current with limited Internet access?

Yes, you can do this How did you split the distribution into 240k files?

Newer BSD based systems have a ``Here is an example from /usr/src/Makefile. bin-tarball: (cd ${DISTDIR}; \ tar cf - . \ gzip --no-name -9 -c | \ split -b 240640 - \ ${RELEASEDIR}/tarballs/bindist/bin_tgz.) I've written a kernel extension, who do I send it to?

Please take a look at

And thanks for the thought! How are Plug N Play ISA cards detected and initialized?


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 + Does FreeBSD support architectures other than the x86?

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 . The ALPHA port currently runs on a growing number of ALPHA machine types, among them the AlphaStation, AXPpci, PC164, Miata and Multia models. This port is not yet considered a full release and won't be until a full compliment of system installation tools and a distribution on CDROM installation media is available, including a reasonable number of working ports and packages. FreeBSD/AXP should be considered BETA quality software at this time. For status information, please join the <freebsd-alpha@FreeBSD.ORG>. Interest has also been expressed in a port of FreeBSD to the SPARC architecture, join the <freebsd-sparc@FreeBSD.ORG> if you are interested in joining that project. For general discussion on new architectures, join the <freebsd-platforms@FreeBSD.ORG> . I need a major number for a device driver I've written.

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 code to create any special files your device uses. If you do not, or are unable to because of licensing restrictions, then character major number 32 and block major number 8 have been reserved specifically for this purpose; please use them. In any case, we'd appreciate hearing about your driver on <freebsd-hackers@FreeBSD.ORG>. Alternative layout policies for directories

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

Making the most of a kernel panic

[This section was extracted from a mail written by on the freebsd-current by , who fixed a few typos and added the bracketed comments]

From: Bill Paul Subject: Re: the fs fun never stops To: ben@rosengart.com Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT) Cc: current@FreeBSD.ORG

[<ben@rosengart.com> posted the following panic message] > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x40 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf014a7e5 ^^^^^^^^^^ > stack pointer = 0x10:0xf4ed6f24 > frame pointer = 0x10:0xf4ed6f28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 80 (mount) > interrupt mask = > trap number = 12 > panic: page fault

[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: Write down the instruction pointer value. Note that the When the system reboots, do the following: % nm /kernel.that.caused.the.panic | grep f0xxxxxx where % nm /kernel.that.caused.the.panic | grep f0xxxxx If that doesn't yield any results, chop off another digit. Repeat until you get some sort of output. The result will be a possible list of functions which caused the panic. This is a less than exact mechanism for tracking down the point of failure, but it's better than nothing.

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 normally use is this: Set up a kernel config file, optionally adding 'options DDB' if you think you need the kernel debugger for something. (I use this mainly for setting beakpoints if I suspect an infinite loop condition of some kind.) Use cd /sys/compile/KERNELCONFIG; make Wait for kernel to finish compiling. cp kernel / reboot -

[Note: currently, on 3.0-BETA, you must use +

[Note: Now that FreeBSD 3.x kernels are Elf by default, + you should 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 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 % gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0 (gdb) where

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]