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 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: 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 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]
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: DELL PE2650 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4400CNTX-ID,b14 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 Version 1.1 irqs 0-15 on motherboard ioapic1 Version 1.1 irqs 16-31 on motherboard ioapic2 Version 1.1 irqs 32-47 on motherboard npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL PE2650 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: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 4.0 (no driver attached) pci0: unknown at device 4.1 (no driver attached) pci0: unknown at device 4.2 (no driver attached) pci0: display, VGA at device 14.0 (no driver attached) atapci0: ServerWorks CSB5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x17 7,0x376,0x8b0-0x8bf at device 15.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 ohci0: OHCI (generic) USB controller 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: OHCI (generic) USB controller 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: PCI-ISA bridge at device 15.3 on pci0 isa0: ISA bus on isab0 pcib1: ACPI Host-PCI bridge on acpi0 pci4: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 8.0 on pci4 pci5: ACPI PCI bus on pcib2 aac0: Dell PERC 3/Di mem 0xf000-0xf7ff irq 30 at device 8.1 on pci4 aac0: [FAST] aac0: Adaptec Raid Controller 2.0.0-1 pcib3: ACPI Host-PCI bridge on acpi0 pci3: ACPI PCI bus on pcib3 bge0: Broadcom BCM5703 Gigabit Ethernet, ASIC rev. 0x1002 mem 0xfcf1-0xfcf 1 irq 28 at device 6.0 on pci3 miibus0: MII bus on bge0 brgphy0: BCM5703 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge0: Ethernet address: 00:0d:56:ba:73:bf bge1: Broadcom BCM5703 Gigabit Ethernet, ASIC rev. 0x1002 mem 0xfcf0-0xfcf 0 irq 29 at device 8.0 on pci3 miibus1: MII bus on bge1 brgphy1: BCM5703 10/100/1000baseTX PHY on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge1: Ethernet address: 00:0d:56:ba:73:c1 pcib4: ACPI Host-PCI bridge on acpi0 pci2: ACPI PCI bus on pcib4 pcib5: ACPI Host-PCI bridge on acpi0 pci1: ACPI PCI bus on pcib5 fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0:
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]
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?
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?
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: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?
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]
