Re: clock reverts to epoch on boot?
At 12:29 PM 2/14/2006, Oliver Fromme wrote: Vinny Abello <[EMAIL PROTECTED]> wrote: > Oliver Fromme wrote: > > Vinny Abello <[EMAIL PROTECTED]> wrote: > > > CFLAGS= -O2 -pipe > > > COPTFLAGS= -O -pipe > > > > I recommend not to overide those two at all. Especially > > your CFLAGS setting might generate broken code because > > there are sources which are not aliasing-clean, which can > > break with any optimizations beyond -O, unless you also > > specify -fno-strict-aliasing. > > Really? Are there any current examples of such? I've never run into > this myself, but I'm sure you wouldn't be recommending it if it wasn't true. XEmacs, PostgreSQL, freetype2 and others. Whether you get problems or not depends on a lot of things. If you're lucky, it works. On platforms with only few registers (like i386) it's more likely to work, because gcc has less possibilities to exploit aliasing optimizations. > What about -funroll-loops and -ffast-math? I see a lot of people > using those options in general as well. You can use them. They shouldn't cause harm, but in many cases -funroll-loops makes the code slower, because it increases the size of the code so it decreases the efficiency of the processor caches. > I actually found one reference from someone claiming -O3 is good in > CFLAGS and -O2 for COPTFLAGS although I have read a lot of things > about why not to use -O3 in CFLAGS and that it's not supported at all > with buildworld, so I'm not really interested in using that at all, > even with ports. I probably didn't explain it clearly enough. You can use -O2 (and probably also -O3, but I haven't tried that). In former times, the gcc optimizer was known to have bugs that could cause bad code to be generated. As far as I know, those bugs have been fixed in current versions of gcc. However, -O2 also includes -fstrict-aliasing. Strict ali- asing enables a special optimization which lets the compiler assume that pointers with incompatible types never point to the same target. For example, in the function void func (int *foo, short *bar) it is legal for the compiler (according to ANSI C) to assume that the two pointers may not alias. But a lot of programs don't fulfill that assumption. It's a problem with those sources, not with gcc. Therefore the default CFLAGS include -fno-strict-aliasing, which disables that kind of optimizations in gcc. With that option, gcc always assumes that pointers may alias. If you override CFLAGS in your /etc/make.conf by specifying -O2 (or -O3 or -Os) but not also specifying -fno-strict-ali- asing, you run the risk of enabling bugs in programs. > > The defaults are "-O2 -fno-strict-aliasing -pipe" for > > CFLAGS, and for COPTFLAGS it's "-O -pipe" if DEBUG is > > defined (the default in GENERIC), otherwise "-O2 -pipe > > -fno-strict-aliasing". > > Is -O2 safe on COPTFLAGS if you have debugging disabled in the > KERNCONF? Yes, I think so. But when you disable DEBUG, then -O2 is the default anyway ("-O2 -pipe -fno-strict-aliasing", to be exact), so there's no point in overriding it in make.conf. That's the reason why I recommend not to mess with CFLAGS and COPTFLAGS in /etc/make.conf. The defaults provided by the FreeBSD developers are usually the best optimization possible without creating potentially broken binaries. Best regards Oliver Thanks for all of your excellent explanations, Oliver. Highly appreciated. :) Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock reverts to epoch on boot?
Vinny Abello <[EMAIL PROTECTED]> wrote: > Oliver Fromme wrote: > > Vinny Abello <[EMAIL PROTECTED]> wrote: > > > CFLAGS= -O2 -pipe > > > COPTFLAGS= -O -pipe > > > > I recommend not to overide those two at all. Especially > > your CFLAGS setting might generate broken code because > > there are sources which are not aliasing-clean, which can > > break with any optimizations beyond -O, unless you also > > specify -fno-strict-aliasing. > > Really? Are there any current examples of such? I've never run into > this myself, but I'm sure you wouldn't be recommending it if it wasn't true. XEmacs, PostgreSQL, freetype2 and others. Whether you get problems or not depends on a lot of things. If you're lucky, it works. On platforms with only few registers (like i386) it's more likely to work, because gcc has less possibilities to exploit aliasing optimizations. > What about -funroll-loops and -ffast-math? I see a lot of people > using those options in general as well. You can use them. They shouldn't cause harm, but in many cases -funroll-loops makes the code slower, because it increases the size of the code so it decreases the efficiency of the processor caches. > I actually found one reference from someone claiming -O3 is good in > CFLAGS and -O2 for COPTFLAGS although I have read a lot of things > about why not to use -O3 in CFLAGS and that it's not supported at all > with buildworld, so I'm not really interested in using that at all, > even with ports. I probably didn't explain it clearly enough. You can use -O2 (and probably also -O3, but I haven't tried that). In former times, the gcc optimizer was known to have bugs that could cause bad code to be generated. As far as I know, those bugs have been fixed in current versions of gcc. However, -O2 also includes -fstrict-aliasing. Strict ali- asing enables a special optimization which lets the compiler assume that pointers with incompatible types never point to the same target. For example, in the function void func (int *foo, short *bar) it is legal for the compiler (according to ANSI C) to assume that the two pointers may not alias. But a lot of programs don't fulfill that assumption. It's a problem with those sources, not with gcc. Therefore the default CFLAGS include -fno-strict-aliasing, which disables that kind of optimizations in gcc. With that option, gcc always assumes that pointers may alias. If you override CFLAGS in your /etc/make.conf by specifying -O2 (or -O3 or -Os) but not also specifying -fno-strict-ali- asing, you run the risk of enabling bugs in programs. > > The defaults are "-O2 -fno-strict-aliasing -pipe" for > > CFLAGS, and for COPTFLAGS it's "-O -pipe" if DEBUG is > > defined (the default in GENERIC), otherwise "-O2 -pipe > > -fno-strict-aliasing". > > Is -O2 safe on COPTFLAGS if you have debugging disabled in the > KERNCONF? Yes, I think so. But when you disable DEBUG, then -O2 is the default anyway ("-O2 -pipe -fno-strict-aliasing", to be exact), so there's no point in overriding it in make.conf. That's the reason why I recommend not to mess with CFLAGS and COPTFLAGS in /etc/make.conf. The defaults provided by the FreeBSD developers are usually the best optimization possible without creating potentially broken binaries. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock reverts to epoch on boot?
At 04:45 AM 2/14/2006, Oliver Fromme wrote: Vinny Abello <[EMAIL PROTECTED]> wrote: > CPUTYPE=pentium4 Better use "?=". Yes, I saw that error and corrected it. Thanks. That wasn't the source of my problems actually, but I at least have it specified properly now. > CFLAGS= -O2 -pipe > COPTFLAGS= -O -pipe I recommend not to overide those two at all. Especially your CFLAGS setting might generate broken code because there are sources which are not aliasing-clean, which can break with any optimizations beyond -O, unless you also specify -fno-strict-aliasing. Really? Are there any current examples of such? I've never run into this myself, but I'm sure you wouldn't be recommending it if it wasn't true. What about -funroll-loops and -ffast-math? I see a lot of people using those options in general as well. I actually found one reference from someone claiming -O3 is good in CFLAGS and -O2 for COPTFLAGS although I have read a lot of things about why not to use -O3 in CFLAGS and that it's not supported at all with buildworld, so I'm not really interested in using that at all, even with ports. The defaults are "-O2 -fno-strict-aliasing -pipe" for CFLAGS, and for COPTFLAGS it's "-O -pipe" if DEBUG is defined (the default in GENERIC), otherwise "-O2 -pipe -fno-strict-aliasing". Is -O2 safe on COPTFLAGS if you have debugging disabled in the KERNCONF? I usually disable it as I have no interest in debugging the kernel (nor have I had problems where I've needed to... yet). I've found references in the archives that it is desirable to get (keep?) the kernel working with -O2 optimizations. Any pointers appreciated. TIA! Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock reverts to epoch on boot?
Vinny Abello <[EMAIL PROTECTED]> wrote: > CPUTYPE=pentium4 Better use "?=". > CFLAGS= -O2 -pipe > COPTFLAGS= -O -pipe I recommend not to overide those two at all. Especially your CFLAGS setting might generate broken code because there are sources which are not aliasing-clean, which can break with any optimizations beyond -O, unless you also specify -fno-strict-aliasing. The defaults are "-O2 -fno-strict-aliasing -pipe" for CFLAGS, and for COPTFLAGS it's "-O -pipe" if DEBUG is defined (the default in GENERIC), otherwise "-O2 -pipe -fno-strict-aliasing". Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I learned Java 3 years before Python. It was my language of choice. It took me two weekends with Python before I was more productive with it than with Java." -- Anthony Roberts ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock reverts to epoch on boot?
At 10:28 PM 2/13/2006, Vinny Abello wrote: At 10:25 PM 2/13/2006, Chuck Swiger wrote: Vinny Abello wrote: [ ... ] > Nevermind. I just answered my own question. I should have RTFM more > carefully. :) :-) > If CPUTYPE is defined in your /etc/make.conf, make sure to use the > "?=" instead of the "=" assignment operator, so that buildworld can > override the CPUTYPE if it needs to. > > I am thinking if I change to > > CPUTYPE?=pentium4 > > I will be ok. Does that sound correct or am I still barking up the wrong > tree? If you weren't having any problems, feel free to experiment. Since you don't gain much by using the machine-specific compiler optimizations for the kernel, it is worth turning them off to see whether the resulting kernel still has the same problem... Will give it a shot and see what happens. So far buildworld isn't using CPU specific optimizations with the CPUTYPE?=pentium4 as documented so I have a feeling that will fix my problem. I actually started having problems after rebuilding world from this source a second time with (what I thought) were more optimized compiler settings. Obviously not if they cause it to break. :) My kernel is the same from when it was working from the original CVSUP and original buildworld so I think I'll be ok with that. I'll rebuild it to be safe anyway though. Thanks again for your help! :) Just following up on this further. It seems the problem was a little more complex (or simple) than this... I had the same problem despite what settings I used for CPUTYPE in my make.conf file. As I stated earlier, booting into single user mode works fine and I have the correct date. I started looking at what was loading on startup when going multiuser. I basically commented out my whole rc.conf.local file except for SSH and then time was correct upon bootup! I put everything back except for time related programs, but the problem came back. I uncommented all my time stuff and on a hunch, I commented out only the line to enable a Backup Exec port from starting. Having this disabled made it so on every startup my system time is now correct. I had noticed an error when that agent was starting since upgrading which I was going to look into. I know it is actually a Linux binary and relies on Linux compatibility in FreeBSD. I'm not sure if the binary was just damaged or if my Linux binary compatibility or some libraries are out of sync. Regardless, I seem to have found the problem... I need to update to the newest agent from Veritas/Symantec anyway instead of this port, although I don't know if that works well either. I'll look into that tomorrow and look into possibly rebuilding my Linux binary port containing the libraries as well, although that was really the only reason I had it installed and my not need it. What is odd is my kernsecurelevel is set to 2 and the time still gets massively adjusted, incorrectly somehow to boot. I think that binary was run in the startup rc scripts prior to kernsecurelevel being raised from -1 to 2 though. Actually, I'm sure of that now, so nevermind. Thanks again for the help. I just wanted to post back what I found to share with others in case someone ever runs into the same oddity. P.S. I CVSUP'ed STABLE, built the kernel and did buildworld with CPUTYPE?=prescott which more accurately matches my actual CPU type. No problems at all to report. :) Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock reverts to epoch on boot?
At 10:25 PM 2/13/2006, Chuck Swiger wrote: Vinny Abello wrote: [ ... ] > Nevermind. I just answered my own question. I should have RTFM more > carefully. :) :-) > If CPUTYPE is defined in your /etc/make.conf, make sure to use the > "?=" instead of the "=" assignment operator, so that buildworld can > override the CPUTYPE if it needs to. > > I am thinking if I change to > > CPUTYPE?=pentium4 > > I will be ok. Does that sound correct or am I still barking up the wrong > tree? If you weren't having any problems, feel free to experiment. Since you don't gain much by using the machine-specific compiler optimizations for the kernel, it is worth turning them off to see whether the resulting kernel still has the same problem... Will give it a shot and see what happens. So far buildworld isn't using CPU specific optimizations with the CPUTYPE?=pentium4 as documented so I have a feeling that will fix my problem. I actually started having problems after rebuilding world from this source a second time with (what I thought) were more optimized compiler settings. Obviously not if they cause it to break. :) My kernel is the same from when it was working from the original CVSUP and original buildworld so I think I'll be ok with that. I'll rebuild it to be safe anyway though. Thanks again for your help! :) Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock reverts to epoch on boot?
Vinny Abello wrote: [ ... ] > Nevermind. I just answered my own question. I should have RTFM more > carefully. :) :-) > If CPUTYPE is defined in your /etc/make.conf, make sure to use the > "?=" instead of the "=" assignment operator, so that buildworld can > override the CPUTYPE if it needs to. > > I am thinking if I change to > > CPUTYPE?=pentium4 > > I will be ok. Does that sound correct or am I still barking up the wrong > tree? If you weren't having any problems, feel free to experiment. Since you don't gain much by using the machine-specific compiler optimizations for the kernel, it is worth turning them off to see whether the resulting kernel still has the same problem... -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock reverts to epoch on boot?
At 10:04 PM 2/13/2006, Vinny Abello wrote: At 09:49 PM 2/13/2006, Chuck Swiger wrote: Vinny Abello wrote: [ ... ] > I may try doing a cvsup of source and rebuilding again. My make.conf > settings are pretty tame: > > CPUTYPE=pentium4 > CFLAGS= -O2 -pipe > COPTFLAGS= -O -pipe Remove the CPUTYPE declaration, or at least decrease it to just "pentium". OK, I can try that. Come to think of it, I did have it set to "p4" previously and I believe it was working. Why would this make a difference? Also, I just booted in single user mode and the clock is correct. Does this likely confirm it is a problem when I did a buildworld with that CPUTYPE set? Nevermind. I just answered my own question. I should have RTFM more carefully. :) If CPUTYPE is defined in your /etc/make.conf, make sure to use the "?=" instead of the "=" assignment operator, so that buildworld can override the CPUTYPE if it needs to. I am thinking if I change to CPUTYPE?=pentium4 I will be ok. Does that sound correct or am I still barking up the wrong tree? Thanks!! Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock reverts to epoch on boot?
At 09:49 PM 2/13/2006, Chuck Swiger wrote: Vinny Abello wrote: [ ... ] > I may try doing a cvsup of source and rebuilding again. My make.conf > settings are pretty tame: > > CPUTYPE=pentium4 > CFLAGS= -O2 -pipe > COPTFLAGS= -O -pipe Remove the CPUTYPE declaration, or at least decrease it to just "pentium". OK, I can try that. Come to think of it, I did have it set to "p4" previously and I believe it was working. Why would this make a difference? Also, I just booted in single user mode and the clock is correct. Does this likely confirm it is a problem when I did a buildworld with that CPUTYPE set? Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: clock reverts to epoch on boot?
Vinny Abello wrote: [ ... ] > I may try doing a cvsup of source and rebuilding again. My make.conf > settings are pretty tame: > > CPUTYPE=pentium4 > CFLAGS= -O2 -pipe > COPTFLAGS= -O -pipe Remove the CPUTYPE declaration, or at least decrease it to just "pentium". -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
clock reverts to epoch on boot?
I have an odd problem... I've recently upgraded (binary) from FreeBSD 5.4 to FreeBSD 6.0 then CVSUP'ed to STABLE (6.1 Pre-release) a few days ago, around February 10th it looks like (back when my time worked right) :). I went through the whole thing like normal, rebuilt world, built custom kernel, etc... I also updated the BIOS and RAID firmware on the server, a Dell 2650. During this update process it seems FreeBSD's time handling went a little crazy. Although my CMOS clock is correct (I can verify it by rebooting and going into the setup), every time FreeBSD boots, it thinks it is the beginning of Epoch time... I can sync it with ntp, but upon reboot it is right back to Epoch again. I searched the archives and couldn't find this exact problem... Now, I did do a lot of updates and unfortunately didn't notice exactly when it broke. Some programs were acting a little strange (BIND in particular consuming my CPU on bootup until I manually restart it) and my RRD databases are very confused as well as other programs naturally. I *think* this started happening after I did a buildworld/installworld (in single user of course) but I'm not positive. Here is my dmesg output for my hardware: Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-PRERELEASE #8: Sat Feb 11 01:39:04 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ENGBOX ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2782.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400> real memory = 4026400768 (3839 MB) avail memory = 3946569728 (3763 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 4.0 (no driver attached) pci0: at device 4.1 (no driver attached) pci0: at device 4.2 (no driver attached) pci0: at device 14.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x17 7,0x376,0x8b0-0x8bf at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 ohci0: mem 0xfe10-0xfe100fff irq 5 at device 15.2 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: on acpi0 pci4: on pcib1 pcib2: at device 8.0 on pci4 pci5: on pcib2 aac0: mem 0xf000-0xf7ff irq 30 at device 8.1 on pci4 aac0: [FAST] aac0: Adaptec Raid Controller 2.0.0-1 pcib3: on acpi0 pci3: on pcib3 bge0: mem 0xfcf1-0xfcf 1 irq 28 at device 6.0 on pci3 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge0: Ethernet address: 00:0d:56:ba:73:bf bge1: mem 0xfcf0-0xfcf 0 irq 29 at device 8.0 on pci3 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge1: Ethernet address: 00:0d:56:ba:73:c1 pcib4: on acpi0 pci2: on pcib4 pcib5: on acpi0 pci1: on pcib5 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: at iomem 0xc-0xc7fff,0xc8000-0xcbfff,0xec000-0xe on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master UDMA33 aacd0: on aac0 aacd0: 34712MB (71091456 sectors) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/aacd0s1a bge0: link state changed to UP I may try doing a cvsup of source and rebuilding again. My make.conf settings are pretty tame: CPUTYPE=pentium4 CFLAGS= -O2 -pipe COPTFLAGS= -O -pipe NO_GAMES=true P