Re: crashdumps not working
On Wed, 8 Dec 2004, Michael Nottebrock wrote: > > I.e., do the individual elements work from the debugger. If they do, then > > we can try the same from entering the debugger following the panic, and > > see how things differ. > > All of the above works when entering the debugger from the watchdog > timeout, too. :-\ So it's basically sounding like it's really something about the call to panic() in the non-debugger scenario. I'm off on vacation for a week or so, but once I get back I'll be happy to take a further look if no one else has gotten to it by then. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crashdumps not working
On Wednesday, 8 December 2004 at 11:20:34 +, Robert Watson wrote: > > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > >> I recently enabled SW_WATCHDOG in my kernel, but when watchdog triggers >> a panic, no crashdump is taken although dumps are enabled. What could be >> causing this? > > If you drop to the debugger by using the debug.kdb.enter sysctl, and > do "call doadump", followed by a reset, does a dump get generated > successfully? I.e., are they completely broken on your system, or > is this somehow a property of the particular hang you're seeing. > (Do the above with caution and in a situation where you don't mind > fscking, needless to say). FWIW, I've found that the only way to dump a -CURRENT system in the last six months or so has been to 'call doadump'. There are a number of other problems, including getting gdb over firewire to work at all, but I won't find time to look at them for the next few weeks. Greg -- See complete headers for address and phone numbers. pgp7cj9GtXUHg.pgp Description: PGP signature
Re: crashdumps not working
On Wed, 8 Dec 2004, David Gilbert wrote: > > "Robert" == Robert Watson <[EMAIL PROTECTED]> writes: > > Robert> This is a NULL pointer dereference; you can use addr2line or > Robert> gdb on your kernel.debug to turn it into a line number even > Robert> without a core. That might well be worth doing, as we might > Robert> be able to debug that even without getting dumping working on > Robert> the box. > > If I had an address and a debug kernel, how is this done? There are at least three ways you can do this, depending on the amount of information you have, and what you're trying to find out. Suppose you get a fault and the trap shows the instruction pointer is 0xc052fb46. You can use: (1) addr2line(1) converts an address and a executable with debugging information to a line number. Assuming your kernel and source are properly in sync, etc, you can do: % addr2line --exe=kernel.debug 0xc052fb46 ../../../kern/subr_prf.c:297 (2) gdb(1) can be used on the debugging kernel, and can often return more useful context information. For example: % gdb kernel.debug ... This GDB was configured as "i386-marcel-freebsd"... (gdb) l *0xc052fb46 0xc052fb46 is in printf (../../../kern/subr_prf.c:297). 292 consintr = 0; 293 va_start(ap, fmt); 294 pca.tty = NULL; 295 pca.flags = TOCONS | TOLOG; 296 pca.pri = -1; 297 retval = kvprintf(fmt, putchar, &pca, 10, ap); 298 va_end(ap); 299 if (!panicstr) 300 msgbuftrigger = 1; 301 consintr = savintr; /* reenable interrupts */ gdb is a little more savvy about telling you about macros, inlines, etc, and gives you a bit of line context, so I've found it very helpful. (3) If you don't have debugging symbols, you can often identify at least the function that nm(1), you can run nm on the binary, and then search down through the sumbols until you find the closest address match before the address. I.e.: % nm kernel.debug | more ... c06f9f80 d print_message c067caf0 T printcpuinfo c052fb38 T printf c0523104 T printf_uuid c05019f4 T prison_check So the pointer is between printf() and printf_uuid(). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crashdumps not working
> "Robert" == Robert Watson <[EMAIL PROTECTED]> writes: Robert> This is a NULL pointer dereference; you can use addr2line or Robert> gdb on your kernel.debug to turn it into a line number even Robert> without a core. That might well be worth doing, as we might Robert> be able to debug that even without getting dumping working on Robert> the box. If I had an address and a debug kernel, how is this done? Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crashdumps not working
I played around with the kernel debug options a little and found peculiar things: - With just options KDB (and no debugger backend specified), a panic will just cause some output scroll very fast on the console - perhaps kdb is trying to enter a nonexisting debugger backend and loops? - With options KDB, KDB_UNATTENDED and DDB, a panic _does_ trigger DDB, contrary to what the description of KDB_UNATTENDED says. It seems to me 5.3's debugging facilities are somewhat in disarray... -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpWUheyd5jYr.pgp Description: PGP signature
Re: crashdumps not working
On Wednesday, 8. December 2004 13:38, Robert Watson wrote: Okay, I've now enabled the following in the kernel: options KDB options KDB_TRACE options DDB > So I'm thinking it > would be nice to know: > > - Can you enter and continue from kdb normally using the sysctl. Yes. > - If you can enter kdb using the sysctl, does "call doadump()" work from > kdb? Yes. > - If you can enter kdb using the sysctl, oes "reset" work from kdb? Yes. > I.e., do the individual elements work from the debugger. If they do, then > we can try the same from entering the debugger following the panic, and > see how things differ. All of the above works when entering the debugger from the watchdog timeout, too. :-\ -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crashdumps not working
On Wednesday, 8. December 2004 13:38, Robert Watson wrote: > ULE is temporarily without an owner, but Jeff and others have expressed > interest in working on it further. I'd not run it for the time being, but > it's probably not a hopeless case. Does the above statement mean that the > hangs or panics you are experiencing don't happen at all if you just use > 4BSD? Oh, the 'hangs' (and the reason I turned on SW_WATCHDOG) are caused by me experimenting with somewhat volatile stuff (broken software running at realtime priority, that sort of thing), they're perfectly expected. The panic there with ULE was a one off that happened when I turned on ULE & PREEMPTION to test if the warning about ULE being unstable with PREEMPTION tells the truth... sure does. :-) I'm going to enable the kernel debugger now... Thanks for the help btw! -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpfYonq6e9nn.pgp Description: PGP signature
Re: crashdumps not working
On Wed, 8 Dec 2004, Michael Nottebrock wrote: > > > I don't have kdb enabled in my kernel configuration at all... > > > > I'm guessing it might be useful at this point, if possible :-). > > Useful for what exactly? I'm mainly interested in getting this machine > to auto-reboot after a (watchdog-triggered) panic, crashdumps are a > bonus. At the moment, it will just hang on a panic (even if I do not > enable crashdumps in rc.conf, it won't reset), and since it's usually > running X, it will just stand there while the CRTs burn in. If you think > you can get a clue as to why it wouldn't crashdump or reset by something > I can do in kdb, I will enable it ... The primary goal in using KDB would be to see what parts of the crash, dump, and reset work separately. For example, by entering KDB using the sysctl, we can see if dumps work on your system when not in a potentially sticky situation (i.e., not in an interrupt handler, or with interrupts disabled, after a controller wedge, or the like). So I'm thinking it would be nice to know: - Can you enter and continue from kdb normally using the sysctl. - If you can enter kdb using the sysctl, does "call doadump()" work from kdb? - If you can enter kdb using the sysctl, oes "reset" work from kdb? I.e., do the individual elements work from the debugger. If they do, then we can try the same from entering the debugger following the panic, and see how things differ. > > This is a NULL pointer dereference; you can use addr2line or gdb on your > > kernel.debug to turn it into a line number even without a core. That > > might well be worth doing, as we might be able to debug that even without > > getting dumping working on the box. > > It's a SCHED_ULE + PREEMPTION triggered panic, probably there's no point > in investigating it at this point, as _ULE has been demoted to > abandonware :-(. ULE is temporarily without an owner, but Jeff and others have expressed interest in working on it further. I'd not run it for the time being, but it's probably not a hopeless case. Does the above statement mean that the hangs or panics you are experiencing don't happen at all if you just use 4BSD? > > Syncing on panic is, in general, probably not going to make it work better > > than not. I guess there's no chance the box has an NMI button? > > Right. I just enabled it for the SW_WATCHDOG experiments (which made me > discover that this machine would just get stuck on panics in the first > place), I already turned it off again. Thanks. Just trying to keep track of and reduce the number of variables. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crashdumps not working
On Wednesday, 8. December 2004 13:16, Michael Nottebrock wrote: > > > panic: page fault > > > > This is a NULL pointer dereference; you can use addr2line or gdb on your > > kernel.debug to turn it into a line number even without a core. That > > might well be worth doing, as we might be able to debug that even without > > getting dumping working on the box. > > It's a SCHED_ULE + PREEMPTION triggered panic, probably there's no point in > investigating it at this point, as _ULE has been demoted to abandonware > :-(. N.B., I'm running now SCHED_4BSD again. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpv19dQklmM2.pgp Description: PGP signature
Re: crashdumps not working
On Wednesday, 8. December 2004 12:54, Robert Watson wrote: > On Wed, 8 Dec 2004, Michael Nottebrock wrote: > > On Wednesday, 8. December 2004 12:20, Robert Watson wrote: > > > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > > > > I recently enabled SW_WATCHDOG in my kernel, but when watchdog > > > > triggers a panic, no crashdump is taken although dumps are enabled. > > > > What could be causing this? > > > > > > If you drop to the debugger by using the debug.kdb.enter sysctl, and do > > > "call doadump", followed by a reset, does a dump get generated > > > successfully? > > > > I don't have kdb enabled in my kernel configuration at all... > > I'm guessing it might be useful at this point, if possible :-). Useful for what exactly? I'm mainly interested in getting this machine to auto-reboot after a (watchdog-triggered) panic, crashdumps are a bonus. At the moment, it will just hang on a panic (even if I do not enable crashdumps in rc.conf, it won't reset), and since it's usually running X, it will just stand there while the CRTs burn in. If you think you can get a clue as to why it wouldn't crashdump or reset by something I can do in kdb, I will enable it ... > Do you > have a serial console on the box, or could you set one up? Nope, this is the only machine with a keyboard and a monitor attached. > > > > I.e., are they completely broken on your system, or is this > > > somehow a property of the particular hang you're seeing. > > > > See my other mail, a different (non-watchdog) panic didn't trigger a dump > > either. I even had the panic message in dmesg: > > > > kernel trap 12 with interrupts disabled > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x14c > > fault code = supervisor write, page not present > > instruction pointer = 0x8:0xc0521397 > > stack pointer = 0x10:0xe9794b84 > > frame pointer = 0x10:0xe9794b90 > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags= resume, IOPL = 0 > > current process = 1281 (beep-media-player) > > trap number = 12 > > panic: page fault > > This is a NULL pointer dereference; you can use addr2line or gdb on your > kernel.debug to turn it into a line number even without a core. That > might well be worth doing, as we might be able to debug that even without > getting dumping working on the box. It's a SCHED_ULE + PREEMPTION triggered panic, probably there's no point in investigating it at this point, as _ULE has been demoted to abandonware :-(. > Syncing on panic is, in general, probably not going to make it work better > than not. I guess there's no chance the box has an NMI button? Right. I just enabled it for the SW_WATCHDOG experiments (which made me discover that this machine would just get stuck on panics in the first place), I already turned it off again. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpk0pV9DnNCX.pgp Description: PGP signature
Re: crashdumps not working
On Wed, 8 Dec 2004, Michael Nottebrock wrote: > On Wednesday, 8. December 2004 12:20, Robert Watson wrote: > > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > > > I recently enabled SW_WATCHDOG in my kernel, but when watchdog triggers > > > a panic, no crashdump is taken although dumps are enabled. What could be > > > causing this? > > > > If you drop to the debugger by using the debug.kdb.enter sysctl, and do > > "call doadump", followed by a reset, does a dump get generated > > successfully? > > I don't have kdb enabled in my kernel configuration at all... I'm guessing it might be useful at this point, if possible :-). Do you have a serial console on the box, or could you set one up? > > I.e., are they completely broken on your system, or is this > > somehow a property of the particular hang you're seeing. > > See my other mail, a different (non-watchdog) panic didn't trigger a dump > either. I even had the panic message in dmesg: > > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x14c > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc0521397 > stack pointer = 0x10:0xe9794b84 > frame pointer = 0x10:0xe9794b90 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= resume, IOPL = 0 > current process = 1281 (beep-media-player) > trap number = 12 > panic: page fault This is a NULL pointer dereference; you can use addr2line or gdb on your kernel.debug to turn it into a line number even without a core. That might well be worth doing, as we might be able to debug that even without getting dumping working on the box. > Syncing disks, vnodes remaining...4 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 (I enabled kern.sync_on_panic only very recently for my > experimenting with watchdog, dumping didn't work without it either). Syncing on panic is, in general, probably not going to make it work better than not. I guess there's no chance the box has an NMI button? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crashdumps not working
On Wednesday, 8. December 2004 12:28, Robert Watson wrote: > On Wed, 8 Dec 2004, Robert Watson wrote: > > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > > > I recently enabled SW_WATCHDOG in my kernel, but when watchdog triggers > > > a panic, no crashdump is taken although dumps are enabled. What could > > > be causing this? > > > > If you drop to the debugger by using the debug.kdb.enter sysctl, and do > > "call doadump", followed by a reset, does a dump get generated > > successfully? I.e., are they completely broken on your system, or is > > this somehow a property of the particular hang you're seeing. (Do the > > above with caution and in a situation where you don't mind fscking, > > needless to say). > > It this is an SMP box, It's UP (as the kernel configuration I attached to my first mail gives away :-). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgppOpMI46oHX.pgp Description: PGP signature
Re: crashdumps not working
On Wednesday, 8. December 2004 12:20, Robert Watson wrote: > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > > I recently enabled SW_WATCHDOG in my kernel, but when watchdog triggers > > a panic, no crashdump is taken although dumps are enabled. What could be > > causing this? > > If you drop to the debugger by using the debug.kdb.enter sysctl, and do > "call doadump", followed by a reset, does a dump get generated > successfully? I don't have kdb enabled in my kernel configuration at all... > I.e., are they completely broken on your system, or is this > somehow a property of the particular hang you're seeing. See my other mail, a different (non-watchdog) panic didn't trigger a dump either. I even had the panic message in dmesg: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14c fault code = supervisor write, page not present instruction pointer = 0x8:0xc0521397 stack pointer = 0x10:0xe9794b84 frame pointer = 0x10:0xe9794b90 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 1281 (beep-media-player) trap number = 12 panic: page fault Syncing disks, vnodes remaining...4 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (I enabled kern.sync_on_panic only very recently for my experimenting with watchdog, dumping didn't work without it either). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpPjREzyvVXZ.pgp Description: PGP signature
Re: crashdumps not working
On Wed, 8 Dec 2004, Robert Watson wrote: > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > > > I recently enabled SW_WATCHDOG in my kernel, but when watchdog triggers > > a panic, no crashdump is taken although dumps are enabled. What could be > > causing this? > > If you drop to the debugger by using the debug.kdb.enter sysctl, and do > "call doadump", followed by a reset, does a dump get generated > successfully? I.e., are they completely broken on your system, or is > this somehow a property of the particular hang you're seeing. (Do the > above with caution and in a situation where you don't mind fscking, > needless to say). It this is an SMP box, you might also try setting debug.kdb.stop_cpus to 0. Normally when entering the debugger, the processor entering the debugger will send an IPI to the other CPUs to stop them in order to quiesce the system state a bit. If one or more processors are in a state where processing the top IPI isn't possible, the procesor entering the debugger will wait for them to stop ... potentially for a very long time, and in a tight loop. Changing the setting to 0 might improve the chances of getting into the debugger (etc). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crashdumps not working
On Tue, 7 Dec 2004, Michael Nottebrock wrote: > I recently enabled SW_WATCHDOG in my kernel, but when watchdog triggers > a panic, no crashdump is taken although dumps are enabled. What could be > causing this? If you drop to the debugger by using the debug.kdb.enter sysctl, and do "call doadump", followed by a reset, does a dump get generated successfully? I.e., are they completely broken on your system, or is this somehow a property of the particular hang you're seeing. (Do the above with caution and in a situation where you don't mind fscking, needless to say). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: crashdumps not working
On Tuesday, 7. December 2004 21:54, Michael Nottebrock wrote: > I recently enabled SW_WATCHDOG in my kernel, but when watchdog triggers a > panic, no crashdump is taken although dumps are enabled. What could be > causing this? FWIW, I got a "real" panic today (page fault) and no dump was taken there either. :-( -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpfae4p40akR.pgp Description: PGP signature
crashdumps not working
I recently enabled SW_WATCHDOG in my kernel, but when watchdog triggers a
panic, no crashdump is taken although dumps are enabled. What could be
causing this?
rc.conf has
dumpdev="/dev/ad1s3b"
dumpdir="/usr/tmp/crash
and ad1s3b is a swap partition with enough space to take a crash dump. I'm
testing by going into single user (so I can do umount -a to save on some
fsck'ing) and waiting for watchdog to kick in. When it does, there's the
panic ("watchdog timeout), a list of interrupt counts is printed and the
uptime displayed - and then, the box just sits there (the CPU fan starts to
go on high rpm at this point, too, something seems to go into a tight loop).
My kernel configuration is attached, the system runs 5-STABLE as of yesterday.
--
,_, | Michael Nottebrock | [EMAIL PROTECTED]
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.8 2004/10/24 17:42:08 scottl
Exp $
machine i386
cpu I686_CPU
ident KISTE-UP
# To statically compile in device wiring instead of /boot/device.hints
#hints "GENERIC.hints" # Default places to look for devices.
options SCHED_ULE # ULE scheduler
options INET# InterNETworking
options INET6 # IPv6 communications protocols
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options MD_ROOT # MD is a potential root device
options NFSCLIENT # Network Filesystem Client
options NFSSERVER # Network Filesystem Server
options NFS_ROOT# NFS usable as /, requires NFSCLIENT
options MSDOSFS # MSDOS Filesystem
options CD9660 # ISO 9660 Filesystem
options PROCFS # Process filesystem (requires PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_GPT# GUID Partition Tables.
options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options SCSI_DELAY=15000# Delay (in ms) before probing SCSI
options KTRACE # ktrace(1) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options AHC_REG_PRETTY_PRINT# Print register bitfields in debug
# output. Adds ~128k to driver.
options AHD_REG_PRETTY_PRINT# Print register bitfields in debug
# output. Adds ~215k to driver.
options ADAPTIVE_GIANT # Giant mutex is adaptive.
device apic# I/O APIC
# Bus support. Do not remove isa, even if you have no isa slots
device isa
device pci
# Floppy drives
device fdc
# ATA and ATAPI devices
device ata
device atadisk # ATA disk drives
device ataraid # ATA RAID drives
device atapicd # ATAPI CDROM drives
options ATA_STATIC_ID # Static device numbering
# SCSI peripherals
device scbus # SCSI bus (required for SCSI)
device da # Direct Access (disks)
device cd # CD
device pass# Passthrough device (direct SCSI access)
# atkbdc0 controls both the keyboard and the PS/2 mouse
device atkbdc # AT keyboard controller
device atkbd # AT keyboard
device psm # PS/2 mouse
d
