Re: panic at kern/uipc_socket2.c
On Sun, 2 Jan 2000, Jun Kuriyama wrote: !> !>I don't know what I did at that time, but my box is panic'ed with this !>message. !> !>- !>Jan 1 16:19:21 leda kernel: panic: sbflush: cc 0 || mb 0xc05a7400 || mbcnt 256 !>- !> !>It seems that this message is created by sbflush() in !>kern/uipc_socket2.c. !> !>Should I add some hooks into this function to display details !>preparing for when I get this panic()? !> !> !>Jun Kuriyama // [EMAIL PROTECTED] !>// [EMAIL PROTECTED] !> You don't happen to have a backtrace? Was anything particular happening at the time of the crash? Do you have any way to not necessarily directly reproduce the panic but rather "force" it to happen (e.g. as a consequence of execution of something or, even as a result of some external "trigger")? -- Bosko Milekic Email: [EMAIL PROTECTED] WWW:http://pages.infinit.net/bmilekic/ -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic at kern/uipc_socket2.c
I don't know what I did at that time, but my box is panic'ed with this message. - Jan 1 16:19:21 leda kernel: panic: sbflush: cc 0 || mb 0xc05a7400 || mbcnt 256 - It seems that this message is created by sbflush() in kern/uipc_socket2.c. Should I add some hooks into this function to display details preparing for when I get this panic()? Jun Kuriyama // [EMAIL PROTECTED] // [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 2 hours to compile mysql?
> "Leif" == Leif Neland <[EMAIL PROTECTED]> writes: >> The reason for this is that some gcc optimizations stages takes >> exponentially more memory when compiling big functions. >> bison produces one big function for the grammar parsing and its >> this that takes a long time to compile; To compile sql_yacc.cc quickly >> on Intel, you nead at least 160M of free ram. On a PentiumII 400mz with 256M >> ram, it takes 11 seconds to compile sql_yacc.o. Having to use swap >> can easily make things 1000 times slower >> Leif> Is amount of ram available (portably) to configure? I don't think thats easy to check for.. Aother problem is also that even if you have only little ram, you may still want to compile MySQL without --low-memory, because the final code is much better if you don't have to use --low-memory. Leif> So configure could decide to use --low-memory by itself? Allowing Leif> overrides, naturally. Leif> Leif Regards, Monty To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 01:41:08AM +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes
> :
>
> >Does it help in the 3.4-stable version to set the second value in ntpdrift
> >to 1?
>
> Yes, although I have never checked all the boundary conditions
> to make sure the kernel-pll is stable over the entire envelope.
>
> I'm doing that for the NTPv4/nanokernel combo, and I'm resolving
> the problems I find with Dave Mills.
>
> >And why has the manual page never been updated, it is clearly wrong
> >when it talks about the contents of driftfile! :-(
>
> I updated neither the manpage nor the code because of the above.
>
> >> Anyway, ntpd4 is in CURRENT...
> >
> >Well... that won't help the 20 or so boxes here doing this all the
> >time:
> >Jan 1 11:26:46 gndrsh xntpd[133]: time reset (step) -0.217546 s
> >Jan 1 11:32:06 gndrsh xntpd[133]: time reset (step) 0.207523 s
>
> (-0.217546 - 0.207523) / (14 + 5 * 60 + 6) = -.001328340
>
> Your clock is too sick, (or our calibration of it is hosed), no
> version of {X}NTP will touch a clock which is outside +/- 500ppm.
>
> Could you try to measure the 14.31818... MHz base frequency and
> the 32768 kHz wristwatch xtal as well (I know you're RadioActive,
> so I pressume you have a counter ?)
>
> If they're both OK, then we have a code problem...
You have a code problem ;-)
I can confirm this behavior; its been consistent with xntpd for a LONG time,
which is why I raised the issue (it FINALLY got to the top of my "annoyance"
list).
--
--
Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org
Isn't it time we started putting KIDS first? See the above URL for
a plan to do exactly that!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 01:31:25AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Karl Denninger writes: > > >Yes, and my driftfile had that parameter in there. Uhm, Poul, remember I've > >been at this for just a LITTLE while. Xntpd is something I had deployed > >back in my *Sun* days (back when FreeBSD was, well, non-existent) > > Karl, remember who was there too ? :-) > > >> Anyway, ntpd4 is in CURRENT... > > > >Now it is. > > > >And it works correctly too. > > In general yes, but not if you use the hardpps() with a refclock, > it works better after I fixed a couple of almost-mutually-canceling > sign-bugs, but the parameters of the hardpps() PLL relative to the > FLL are wrong. You're still a bunch of revs back - the current is either "h" or "i", and it has a bunch of fixes (including one here, I think) > >Thanks anyway, even with the attitude. > > Many happy returns :-) Thy be welcome. -- Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
> In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes
> :
>
> >Does it help in the 3.4-stable version to set the second value in ntpdrift
> >to 1?
>
> Yes, although I have never checked all the boundary conditions
> to make sure the kernel-pll is stable over the entire envelope.
>
> I'm doing that for the NTPv4/nanokernel combo, and I'm resolving
> the problems I find with Dave Mills.
Keep up the work, hopefully it can be MFC'd soon
>
> >And why has the manual page never been updated, it is clearly wrong
> >when it talks about the contents of driftfile! :-(
>
> I updated neither the manpage nor the code because of the above.
>
> >> Anyway, ntpd4 is in CURRENT...
> >
> >Well... that won't help the 20 or so boxes here doing this all the
> >time:
> >Jan 1 11:26:46 gndrsh xntpd[133]: time reset (step) -0.217546 s
> >Jan 1 11:32:06 gndrsh xntpd[133]: time reset (step) 0.207523 s
>
> (-0.217546 - 0.207523) / (14 + 5 * 60 + 6) = -.001328340
>
> Your clock is too sick, (or our calibration of it is hosed), no
> version of {X}NTP will touch a clock which is outside +/- 500ppm.
I see this on 20 systems... so we need to do some work, even if
the clocks really are off that much as it seems this is going to
be quite common.
>
> Could you try to measure the 14.31818... MHz base frequency and
> the 32768 kHz wristwatch xtal as well (I know you're RadioActive,
> so I pressume you have a counter ?)
I'll have to wait tell later this week when I am out at the place
all the RadioActive toys are to get my hands on a counter. Alls I
have hear are scopes and DMM's, and the scope hasn't seen a cal lab
in 20+ years, so I don't trust it for anything like this. :-)
>
> If they're both OK, then we have a code problem...
I'll let you know what I find. Just for grins I restarted a few of
them with driftfile="0 1" to see what it does... can't hurt me much :-)
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
According to Poul-Henning Kamp: > Hm, I actually thought I managed to get somebody to solve that somehow, > maybe I didn't quite succeed :-) I tried to get that patch in but Harlan didn't liked it... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #77: Thu Dec 30 12:49:51 CET 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
maxfiles same as maxfilesperproc ??
Hi, On a FreeBSD 4.0-19991223-SNAP system... I just ran into a situation that caused me to have to reboot the machine before understanding what had really happenned... The problems comes down to: kern.maxfiles: 4136 kern.maxfilesperproc: 4136 Thus, because I had a root uid server that looped chewing up file descriptors, it also filled up the system file table. I realize this is end-user/administrator fixable, but I'm not sure the default should have these be the same... Thanks, John kernel config below: # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.freebsd.org/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 ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.217 1999/12/19 20:33:05 billf Exp $ machine i386 #cpuI386_CPU #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident BBKERN maxusers128 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT#NFS usable as root device, "NFS" req'ed options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Be pessimistic about Joe SCSI device options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) syscall trace support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options SEMMNI=1024 # 1024 semaphore ids options SEMMNS=1024 # 1024 semaphores # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #optionsNCPU=2 # number of CPUs #optionsNBUS=4 # number of busses #optionsNAPIC=1 # number of IO APICs #optionsNINTR=24# number of INTs controller isa0 #controller eisa0 controller pci0 # Floppy drives controller fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # ATA and ATAPI devices controller ata0at isa? port IO_WD1 irq 14 controller ata1at isa? port IO_WD2 irq 15 controller ata2 device atadisk0# ATA disk drives device atapicd0# ATAPI CDROM drives device atapifd0# ATAPI floppy drives device atapist0# ATAPI tape drives options ATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices # SCSI Controllers # A single entry for any of these controllers (ahb, ahc, amd, ncr, etc...) is # sufficient for any number of installed devices. #controller ahb0# EISA AHA1742 family controller ahc0# AHA2940 and onboard AIC7xxx devices #controller amd0# AMD 53C974 (Teckram DC-390(T)) #controller dpt0# DPT Smartcache - See LINT for options! #controller isp0# Qlogic family #controller ncr0# NCR/Symbios Logic #controller sym0# NCR/Symbios Logic (do not mix with ncr, it conflicts) #controller adv0at isa? port ? irq ? #controller adw0 #controller bt0 at isa? port ? irq ? #controller aha0at isa? port ? irq ? #controller aic0at isa? port ? irq
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes
:
>Does it help in the 3.4-stable version to set the second value in ntpdrift
>to 1?
Yes, although I have never checked all the boundary conditions
to make sure the kernel-pll is stable over the entire envelope.
I'm doing that for the NTPv4/nanokernel combo, and I'm resolving
the problems I find with Dave Mills.
>And why has the manual page never been updated, it is clearly wrong
>when it talks about the contents of driftfile! :-(
I updated neither the manpage nor the code because of the above.
>> Anyway, ntpd4 is in CURRENT...
>
>Well... that won't help the 20 or so boxes here doing this all the
>time:
>Jan 1 11:26:46 gndrsh xntpd[133]: time reset (step) -0.217546 s
>Jan 1 11:32:06 gndrsh xntpd[133]: time reset (step) 0.207523 s
(-0.217546 - 0.207523) / (14 + 5 * 60 + 6) = -.001328340
Your clock is too sick, (or our calibration of it is hosed), no
version of {X}NTP will touch a clock which is outside +/- 500ppm.
Could you try to measure the 14.31818... MHz base frequency and
the 32768 kHz wristwatch xtal as well (I know you're RadioActive,
so I pressume you have a counter ?)
If they're both OK, then we have a code problem...
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >Yes, and my driftfile had that parameter in there. Uhm, Poul, remember I've >been at this for just a LITTLE while. Xntpd is something I had deployed >back in my *Sun* days (back when FreeBSD was, well, non-existent) Karl, remember who was there too ? :-) >> Anyway, ntpd4 is in CURRENT... > >Now it is. > >And it works correctly too. In general yes, but not if you use the hardpps() with a refclock, it works better after I fixed a couple of almost-mutually-canceling sign-bugs, but the parameters of the hardpps() PLL relative to the FLL are wrong. >Thanks anyway, even with the attitude. Many happy returns :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
> >On Sat, Jan 01, 2000 at 11:11:51AM +0100, Poul-Henning Kamp wrote:
> >> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
> >>
> >> >This is not a port, its part of the RELEASE!
> >> >
> >> >Its several YEARS old, and doesn't work right - you get lots of STEP changes
> >> >instead of what you SHOULD get, which is a slew on the system clock.
> >>
> >> Remember to get the kernel code involved. To do this:
> >>
> >>create a driftfile containing "0 1\n"
> >>start xntpd
> >>
> >> That will help.
> >
> >No it won't. I've been running xntpd for oh, four or five years now on
> >various things. Yes, the drift file is there (and has been). Still got the
> >step time messages.
>
> Uhm, Karl, please try to calm down, OK ?
>
> I didn't talk about having a driftfile, I talked about using the kernel
> PLL: ("Remember to get the kernel code involved.")
>
> With xntpd the kernel-pll is very optional, in fact only the source tells
> you that the magic secret second field in your driftfile controls if
> the kernel-PLL should be used or not.
Does it help in the 3.4-stable version to set the second value in ntpdrift
to 1?
And why has the manual page never been updated, it is clearly wrong
when it talks about the contents of driftfile! :-(
>
> Anyway, ntpd4 is in CURRENT...
Well... that won't help the 20 or so boxes here doing this all the
time:
Jan 1 11:26:46 gndrsh xntpd[133]: time reset (step) -0.217546 s
Jan 1 11:32:06 gndrsh xntpd[133]: time reset (step) 0.207523 s
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >> >options "P1003_1B" >> >options "_KPOSIX_PRIORITY_SCHEDULING" >> >options "_KPOSIX_VERSION=199309L" >> > >> >Current versions of ntpd use these features if they're available. I >> >think "_KPOSIX_VERSION=199309L" is the default, so that one probably >> >isn't strictly necessary. >> >> I seriously doubt using these will do anything for NTPDs performance. > >It won't, but it will stop ntpd from bitching in the syslog about them being >missing :-) Hm, I actually thought I managed to get somebody to solve that somehow, maybe I didn't quite succeed :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 01:15:13AM +0100, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
> >On Sat, Jan 01, 2000 at 11:11:51AM +0100, Poul-Henning Kamp wrote:
> >> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
> >>
> >> >This is not a port, its part of the RELEASE!
> >> >
> >> >Its several YEARS old, and doesn't work right - you get lots of STEP changes
> >> >instead of what you SHOULD get, which is a slew on the system clock.
> >>
> >> Remember to get the kernel code involved. To do this:
> >>
> >>create a driftfile containing "0 1\n"
> >>start xntpd
> >>
> >> That will help.
> >
> >No it won't. I've been running xntpd for oh, four or five years now on
> >various things. Yes, the drift file is there (and has been). Still got the
> >step time messages.
>
> Uhm, Karl, please try to calm down, OK ?
>
> I didn't talk about having a driftfile, I talked about using the kernel
> PLL: ("Remember to get the kernel code involved.")
>
> With xntpd the kernel-pll is very optional, in fact only the source tells
> you that the magic secret second field in your driftfile controls if
> the kernel-PLL should be used or not.
Yes, and my driftfile had that parameter in there. Uhm, Poul, remember I've
been at this for just a LITTLE while. Xntpd is something I had deployed
back in my *Sun* days (back when FreeBSD was, well, non-existent)
> Anyway, ntpd4 is in CURRENT...
Now it is.
And it works correctly too.
Thanks anyway, even with the attitude.
--
--
Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org
Isn't it time we started putting KIDS first? See the above URL for
a plan to do exactly that!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sun, Jan 02, 2000 at 01:17:15AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Polstra writes: > >In article <[EMAIL PROTECTED]>, > >Karl Denninger <[EMAIL PROTECTED]> wrote: > >> > >> It looks like ntpd (the new one) works correctly; I grabbed the latest > >> from the official site last night and by this morning the dispersion > >> and offsets were stable. > > > >BTW, you might want to add these lines (from LINT) to your kernel > >config if you haven't already: > > > ># > ># POSIX P1003.1B > > > ># Real time extensions added int the 1993 Posix > ># P1003_1B: Infrastructure > ># _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING > ># _KPOSIX_VERSION: Version kernel is built for > > > >options "P1003_1B" > >options "_KPOSIX_PRIORITY_SCHEDULING" > >options "_KPOSIX_VERSION=199309L" > > > >Current versions of ntpd use these features if they're available. I > >think "_KPOSIX_VERSION=199309L" is the default, so that one probably > >isn't strictly necessary. > > I seriously doubt using these will do anything for NTPDs performance. It won't, but it will stop ntpd from bitching in the syslog about them being missing :-) - Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, John Polstra writes: >In article <[EMAIL PROTECTED]>, >Karl Denninger <[EMAIL PROTECTED]> wrote: >> >> It looks like ntpd (the new one) works correctly; I grabbed the latest >> from the official site last night and by this morning the dispersion >> and offsets were stable. > >BTW, you might want to add these lines (from LINT) to your kernel >config if you haven't already: > ># ># POSIX P1003.1B > ># Real time extensions added int the 1993 Posix ># P1003_1B: Infrastructure ># _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING ># _KPOSIX_VERSION: Version kernel is built for > >options "P1003_1B" >options "_KPOSIX_PRIORITY_SCHEDULING" >options "_KPOSIX_VERSION=199309L" > >Current versions of ntpd use these features if they're available. I >think "_KPOSIX_VERSION=199309L" is the default, so that one probably >isn't strictly necessary. I seriously doubt using these will do anything for NTPDs performance. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes:
>On Sat, Jan 01, 2000 at 11:11:51AM +0100, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Karl Denninger writes:
>>
>> >This is not a port, its part of the RELEASE!
>> >
>> >Its several YEARS old, and doesn't work right - you get lots of STEP changes
>> >instead of what you SHOULD get, which is a slew on the system clock.
>>
>> Remember to get the kernel code involved. To do this:
>>
>> create a driftfile containing "0 1\n"
>> start xntpd
>>
>> That will help.
>
>No it won't. I've been running xntpd for oh, four or five years now on
>various things. Yes, the drift file is there (and has been). Still got the
>step time messages.
Uhm, Karl, please try to calm down, OK ?
I didn't talk about having a driftfile, I talked about using the kernel
PLL: ("Remember to get the kernel code involved.")
With xntpd the kernel-pll is very optional, in fact only the source tells
you that the magic secret second field in your driftfile controls if
the kernel-PLL should be used or not.
Anyway, ntpd4 is in CURRENT...
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc compiler problem part deux
I wrote: >Last time I checked (I haven't moved to the latest gcc, so I can't >confirm it there), one significant difference between 'cc -E' and >/usr/libexec/cpp was that the latter would read from a pipe, whilst >the former wouldn't. It seems I was wrong. As several people have pointed out, both 'cc -E -' and 'cc -x c -E /dev/stdin' work. I'll crawl back into the woodwork for a while :-). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 2 hours to compile mysql?
> The reason for this is that some gcc optimizations stages takes > exponentially more memory when compiling big functions. > bison produces one big function for the grammar parsing and its > this that takes a long time to compile; To compile sql_yacc.cc quickly > on Intel, you nead at least 160M of free ram. On a PentiumII 400mz with 256M > ram, it takes 11 seconds to compile sql_yacc.o. Having to use swap > can easily make things 1000 times slower > Is amount of ram available (portably) to configure? So configure could decide to use --low-memory by itself? Allowing overrides, naturally. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In message <[EMAIL PROTECTED]>, Karl Denninger writes: >This is not a port, its part of the RELEASE! > >Its several YEARS old, and doesn't work right - you get lots of STEP changes >instead of what you SHOULD get, which is a slew on the system clock. Remember to get the kernel code involved. To do this: create a driftfile containing "0 1\n" start xntpd That will help. The new ntpd is in -CURRENT. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: multiple cd devices
On Fri, Dec 31, 1999 at 01:45:31AM -0500, a little birdie told me that Brian Fundakowski Feldman remarked > The way certain devices, like cd with its monotonically increasing counter > where devices are probed in order and assigned device based on precedence > and not hardwiring/controller connection, work is consistent between > the kernel and MAKEDEV. If you have 2 cd devices, you have cd0 and cd1, > so MAKEDEV accepts "cd2" for "two cd devices". All CD devices work > that way. Disks don't, because there is potential for hard-wiring > there, and will often be gaps. FWIW, MAKEDEV for vty's (and pty's too? dunno) works the same. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problem with rlogin and /etc/pam.conf
Hi all, on two 4.0-CURRENT boxes (cvsuped today) I got the following response when trying to rlogin to it: # rlogin indiana assword: A typed-in password is echoed in cleartext. The only thing that helps is to comment out the second-last line in /etc/pam.conf: # other authrequiredpam_unix.so try_first_pass But this gives an error message when first using the login at the console. Any help on this? Did I miss something? Best regards and HAPPY NEW YEAR --- Udo Schweigert || Voice : +49 89 636 42170 Siemens AG, Siemens CERT|| Fax: +49 89 636 41166 ZT IK 3 || email : [EMAIL PROTECTED] D-81730 Muenchen / Germany ||: [EMAIL PROTECTED] PGP fingerprint || 2A 53 F6 A6 30 59 64 02 6B C4 E0 73 B2 C9 6C E7 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: multiple cd devices (MAKEDEV)
On Fri, Dec 31, 1999 at 03:15:02PM -0500, Chuck Robey wrote: > On Fri, 31 Dec 1999, Wilko Bulte wrote: > > > > > Why are "certain" devices wildly different than all other ones? I've > > > > never encountered that kind of syntax before, and I can't see that it's > > > > documented anywhere at all. Certainly, MAKEDEV itself (in it's > > > > comments) treats cd* just like all the others, specifying that the number > > > > following is a unit number, and *not* a quantity. I don't know when this > > > > happened, but it's surely not obvious. Not one word in the handbook, > > > > either. > > > > > > *shrug* This is the only rationality I could think of. Obviously, this > > > breaks POLA, so it should be changed (with ample warning). > > > > As for ample warning: I've seen MAKEDEVs display a list of the devices > > they are creating. I think the Tru64 version does this. I myself think this > > is a good behaviour (and hope people won't start yelling 'bloat' for once) > > I'd like to hack about a bit on MAKEDEV, but I was wondering, does > sysinstall, in any way, use MAKEDEV? I *don't* want to mess with > sysinstall! :) I guess the only way to find out short of studying sysinstall source code is asking Jordan. -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
This looks like a Good Snap :-)
Well folks, Happy New Years... :-) It looks like 'make world && make release' run ok today... ---> Sat Jan 1 02:32:28 EST 2000 - Nightly build attempt for 4.0-2101-SNAP ---> Sat Jan 1 02:32:28 EST 2000 - make world ... Many Many lines deleted... ---> Sat Jan 1 07:58:20 EST 2000 - Creating /pub/FreeBSD/4.0-2101-SNAP ---> Sat Jan 1 08:04:05 EST 2000 - build of 4.0-2101-SNAP was a success. ---> make world/release ran 331 min 1 sec I'll have to install this one and give it a whirl... at least for a while I can say I'm running one-one ... Have a great weekend folk, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
According to Karl Denninger: > This is not a port, its part of the RELEASE! Part of 3.4-R yes. I removed xntpd (3.4e) from current a month ago and put ntpd (4.0.98f, soon to be 4.1.0) in its place. > What does (someone) need to do to get this changed out/updated? I can't > send it in as a port, since its part of the base package (setting > it up as a port would be pretty trivial from what I can see) As it is a feature change, it was decided not to put it into STABLE. ntpd will compile and run w/o any problem on STABLE though. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #77: Thu Dec 30 12:49:51 CET 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sat, Jan 01, 2000 at 11:11:51AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Karl Denninger writes: > > >This is not a port, its part of the RELEASE! > > > >Its several YEARS old, and doesn't work right - you get lots of STEP changes > >instead of what you SHOULD get, which is a slew on the system clock. > > Remember to get the kernel code involved. To do this: > > create a driftfile containing "0 1\n" > start xntpd > > That will help. No it won't. I've been running xntpd for oh, four or five years now on various things. Yes, the drift file is there (and has been). Still got the step time messages. > The new ntpd is in -CURRENT. Ok. I built it as a local binary and install THAT, and the problem disappeared, so I assume the old "included" one had some kind of problem. Oh, BTW, Mutt is Y2K complient. I get no "odd" time displays with messages I send myself :-) -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: 2 hours to compile mysql?
[ moved to freebsd-ports ] On 01-Jan-00 Leif Neland wrote: > So far it has been taking 2 hours to compile sql_yacc.cc from mysql3.22. This is an indication that something is SERIOUSLY wrong! MySQL has never taken my PII-450 w/ 128MB RAM more than, say, 10-15 minutes to build/install. It would be nice if you showed the transcript of your MySQL build. I hope you're doing this from the port.. (that reminds me, this should really have gone to freebsd-ports, not freebsd-current). -- Will Andrews <[EMAIL PROTECTED]> GCS/E/S @d- s+:+>+:- a--->+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++> DI+++ D+ G++>+++ e-> h! r-->+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
2 hours to compile mysql?
So far it has been taking 2 hours to compile sql_yacc.cc from mysql3.22. I had to find an old disk for swap, and it's swapping all the time. top shows 156M size and 46M res., run time 20min's for cc1plus. That probably means it's been waiting for swapping in 1h40m... The box is a 333MHz PII, with 64M ram. Do I just need more ram to be able to compile in reasonable time, or is something broken? I'm running FreeBSD current from 01/01/2000. Leif Neland To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ida driver in -current and eisa bus attachment
> > i wonder what is happening to the ida driver for comapq's smart array > > controller series. > > Work on this driver is stalled owing to the fact that nobody that can and > wants to work on it has access to the Compaq hardware required. You > can't use these controllers except in Compaq systems, which makes things > very difficult. that's true :-( > If someone has a complete system featuring one or more of these > controllers (a mixed PCI/EISA system would be best), there are several > people that could put it to good use. well, as you meight have guesses, i own one of these nice little compaq servers. unfortunatly it is an eisa-only version. the good thing is i own two compaq smart array controllers (right now, one is in the machine) and the computer is accessible via internet. for people willing to develop the drivers, i offer access to this machine since i doubt there are any developters living in my town and sending the server to the states is no option. -- And remember: "Life sucks and then you die!" email: [EMAIL PROTECTED] [EMAIL PROTECTED] Hi! I'm a .signature virus! Copy me in your ~/.signature to help me spread! <- Save this lifeform ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ida driver in -current and eisa bus attachment
Oliver Schonefeld wrote: [all snipped] Here we go: Sat, 1 Jan 100 17:16:30 +0100 (MET) The first "millenium" bug on our mailing lists! Oliver, how old is your PC? -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: multiple cd devices (MAKEDEV)
Everything that sysinstall does WRT devs is abstracted by libdisk. > On Fri, Dec 31, 1999 at 03:15:02PM -0500, Chuck Robey wrote: > > On Fri, 31 Dec 1999, Wilko Bulte wrote: > > > > > > > Why are "certain" devices wildly different than all other ones? I've > > > > > never encountered that kind of syntax before, and I can't see that it 's > > > > > documented anywhere at all. Certainly, MAKEDEV itself (in it's > > > > > comments) treats cd* just like all the others, specifying that the nu mber > > > > > following is a unit number, and *not* a quantity. I don't know when this > > > > > happened, but it's surely not obvious. Not one word in the handbook, > > > > > either. > > > > > > > > *shrug* This is the only rationality I could think of. Obviously, thi s > > > > breaks POLA, so it should be changed (with ample warning). > > > > > > As for ample warning: I've seen MAKEDEVs display a list of the devices > > > they are creating. I think the Tru64 version does this. I myself think th is > > > is a good behaviour (and hope people won't start yelling 'bloat' for once ) > > > > I'd like to hack about a bit on MAKEDEV, but I was wondering, does > > sysinstall, in any way, use MAKEDEV? I *don't* want to mess with > > sysinstall! > > :) I guess the only way to find out short of studying sysinstall source code > is asking Jordan. > > -- > Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project > WWW : http://www.tcja.nl http://www.freebsd.org > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
On Sat, Jan 01, 2000 at 09:33:31AM -0800, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Karl Denninger <[EMAIL PROTECTED]> wrote:
> >
> > What does (someone) need to do to get this changed out/updated? I can't
> > send it in as a port, since its part of the base package (setting
> > it up as a port would be pretty trivial from what I can see)
>
> There already _is_ a port of it (net/ntp). And there are hooks in
> /etc/rc.conf ("xntpd_program") to use the ports version instead of the
> one in the base system.
>
> John
Thanks; I just updated /usr/src and saw the changes.
This has been broken for a *long* time - at least since the 4.0 branch
began. Its definitely a kernel interface problem with the older code;
while the adjtime call is being made its not happening and eventually
the code executes a "step" instead (which is a bad news; those should
basically never happen once xntpd settles down in a day or three after
a cold start)
It looks like ntpd (the new one) works correctly; I grabbed the latest
from the official site last night and by this morning the dispersion
and offsets were stable.
Ntpd is the "official" code line now - the "x" line is considered deprecated
by the official maintainers, so if you're going to support the ntpd line in
the base system the other(s) should probably be removed entirely.
--
--
Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org
Isn't it time we started putting KIDS first? See the above URL for
a plan to do exactly that!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In article <[EMAIL PROTECTED]>, Karl Denninger <[EMAIL PROTECTED]> wrote: > > It looks like ntpd (the new one) works correctly; I grabbed the latest > from the official site last night and by this morning the dispersion > and offsets were stable. BTW, you might want to add these lines (from LINT) to your kernel config if you haven't already: # # POSIX P1003.1B # Real time extensions added int the 1993 Posix # P1003_1B: Infrastructure # _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING # _KPOSIX_VERSION: Version kernel is built for options "P1003_1B" options "_KPOSIX_PRIORITY_SCHEDULING" options "_KPOSIX_VERSION=199309L" Current versions of ntpd use these features if they're available. I think "_KPOSIX_VERSION=199309L" is the default, so that one probably isn't strictly necessary. > Ntpd is the "official" code line now - the "x" line is considered deprecated > by the official maintainers, so if you're going to support the ntpd line in > the base system the other(s) should probably be removed entirely. I'm sure we'll get there eventually. Things move at a stately pace in -stable. :-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In article <[EMAIL PROTECTED]>,
Karl Denninger <[EMAIL PROTECTED]> wrote:
>
> What does (someone) need to do to get this changed out/updated? I can't
> send it in as a port, since its part of the base package (setting
> it up as a port would be pretty trivial from what I can see)
There already _is_ a port of it (net/ntp). And there are hooks in
/etc/rc.conf ("xntpd_program") to use the ports version instead of the
one in the base system.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ida driver in -current and eisa bus attachment
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Andre Oppermann writes: > : Sat, 1 Jan 100 17:16:30 +0100 (MET) > : Oliver, how old is your PC? > > It isn't a pc bug, but rather a bug in his mail transfer agent. Hmm... His MTA looks fine: Received: by frizzantino.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk970604A) id RAA23768; Sat, 1 Jan 2000 17:16:30 +0100 > Someone thought that tm_year was the last two digits of the year > rather than year - 1900. Is ELM [version 2.4 PL25 PGP6] that much broken? -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ida driver in -current and eisa bus attachment
In message <[EMAIL PROTECTED]> Andre Oppermann writes: : Sat, 1 Jan 100 17:16:30 +0100 (MET) : Oliver, how old is your PC? It isn't a pc bug, but rather a bug in his mail transfer agent. Someone thought that tm_year was the last two digits of the year rather than year - 1900. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ida driver in -current and eisa bus attachment
Eines schoenen Tages schrieb Andre Oppermann: > > Warner Losh wrote: > > > > In message <[EMAIL PROTECTED]> Andre Oppermann writes: > > : Sat, 1 Jan 100 17:16:30 +0100 (MET) > > : Oliver, how old is your PC? it's not a pc ... it's a sun ultra 1 ... and unfortunatly it's not mine. it belongs to my university :-(( > Is ELM [version 2.4 PL25 PGP6] that much broken? yes ... my elm is propably broken :-) maybe i should consider using mutt or something else ... nut that does not really solve the problem with the compaq array controller ... -- And remember: "Life sucks and then you die!" email: [EMAIL PROTECTED] [EMAIL PROTECTED] Hi! I'm a .signature virus! Copy me in your ~/.signature to help me spread! <- Save this lifeform ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ida driver in -current and eisa bus attachment
In message <[EMAIL PROTECTED]> Andre Oppermann writes: : Hmm... His MTA looks fine: MUA. : > Someone thought that tm_year was the last two digits of the year : > rather than year - 1900. : : Is ELM [version 2.4 PL25 PGP6] that much broken? Looks that way... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
In article <[EMAIL PROTECTED]>, Ollivier Robert <[EMAIL PROTECTED]> wrote: > According to John Polstra: > > Current versions of ntpd use these features if they're available. I > > The ntpd daemon in -CURRENT doesn't use these as we cannot be sure the user > has enabled them. I don't understand why they're disabled in -current. Empirically, it appears that the standard ntpd (from the port) still works fine if the features aren't in the kernel. It emits a warning at start-up time, but then it runs fine after that. > We should make them standard IMO. I agree. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ida driver in -current and eisa bus attachment
Eines schoenen Tages schrieb Warner Losh: > : > Someone thought that tm_year was the last two digits of the year > : > rather than year - 1900. > : > : Is ELM [version 2.4 PL25 PGP6] that much broken? > > Looks that way... just compiled elm 2.5.2 ... looks to me, that is fixes my "problem" ... but elm is not really a problem on my bsd box, since this mail is written from an account in my university .. they are running sunos ... -- And remember: "Life sucks and then you die!" email: [EMAIL PROTECTED] [EMAIL PROTECTED] Hi! I'm a .signature virus! Copy me in your ~/.signature to help me spread! <- Save this lifeform ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 2 hours to compile mysql?
In the last episode (Jan 01), Leif Neland said: > So far it has been taking 2 hours to compile sql_yacc.cc from > mysql3.22. > > I had to find an old disk for swap, and it's swapping all the time. > > top shows 156M size and 46M res., run time 20min's for cc1plus. That > probably means it's been waiting for swapping in 1h40m... > > The box is a 333MHz PII, with 64M ram. Do I just need more ram to be > able to compile in reasonable time, or is something broken? You probably need more RAM. sql_yacc.cc is one of those "worst-case" programs as far as gcc is concerned; I don't think gcc can parse large case statements like this efficiently. Adding "--with-low-memory" to your port Makefile, in the CONFIGURE_ARGS line, will help. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
According to John Polstra: > Current versions of ntpd use these features if they're available. I The ntpd daemon in -CURRENT doesn't use these as we cannot be sure the user has enabled them. We should make them standard IMO. > I'm sure we'll get there eventually. Things move at a stately > pace in -stable. :-) A MFC would be very straightforward, I already tested what's in CURRENT on a STABLE system. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #77: Thu Dec 30 12:49:51 CET 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Newpcm is broken again for mpg123 (ESS 1868 isa sound card)
At 04:52 AM 1/1/00 +, Cameron Grant wrote: > > Donn> "ba ba ba ba ba ba ba ba ba ba ba ba ba ba". I have the ESS > > Donn> 1868, of course. Well, I (wisely) saved my old kernel as > > Donn> /kernel.good and just booted into that. > > > > Donn> Could you also say what was fixed if you get around to it? I'd > > Donn> to learn a little more about the sound driver. > > > The following things were in the recent mail of mine: > > > > - All ioctl(2)s go to see the secondary buffer(if I have forget nothing). > > - chn_setblocksize() changes the size of the secondary buffer. > > - chn_mmap() maps the secondary buffer. > > - chn_poll() invokes DMA. > > - chn_wrintr() performs DMA emulation for pcm devices with no DMA > > functionality(requested by nyan). > > - SNDCTL_DSP_SETFRAGMENT handles the count correctly. > > - GETI/OSPACE returns the number of fragments. > > - DMA transfer keeps running upon underrun. Some DSPs seem to end up > > with an unpredictable result if the DMA gets stopped followed by > > immediate restart. This revokes the change in >sys/dev/sound/pcm/channel.c > > rev 1.12. > > - chn_write() and chn_read() returns EAGAIN for nonblocking if there > > are no space to write or data to read. > >the ess problem was a result of me reducing the buffer size to 8k instead of >64k to see what would happen. only ess cards seem to have problems, so it's >back to 64k for them but 8k for other isa cards. > > - cameron I have the same problem with a motherboard with built in Crystal Audio : pcm0: at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 unknown0: at port 0x200-0x207 on isa0 unknown1: at port 0x120-0x127 on isa0 unknown2: at port 0x330-0x331 irq 9 on isa0 It works fine with revision 1.14 of channel.c and 1.12 of dsp.c and the corresponding header files. The new versions break sound. Example using the rsynth port With old version #say happy new year I get "happy new year" out of spaekers With new version : #say happy new year all that comes out of speakers is "happy" Also other problems occur with new version when playing au files. Thanks Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new package set for Y2K
Hi All, To celebrate the last year of the millenium (*), I built a new package set for 4-current. You can find it at ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-current/ Since this is the first build with the signal changes, there have been many changes to 4-current and thus many more breakages than before. You can find those at http://bento.FreeBSD.org/errorlogs/errorlogs/e.4.19991230/ There are a whopping 213 (!) errors, or almost twice as many as in 3-stable. (In particular, the ones that say "new compiler error" is what I believe to be caused by the upgrade to the new gcc in 4-current. At least the error messages don't look familiar.) If you can fix any of those and send in fixes via send-pr, I'm sure everyone will be eternally grateful. Thanks and Happy New Year to you all! -PW and the awesome ports team (*) - Actually, it's just that Bill fixed the serial console of bento a couple of days ago, enabling me to upgrade bento and the package building cluster to 4-current, enabling me to use a new chroot environment with the latest bindist, but that doesn't sound as exciting (!) - It is not good. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
I wrote: > > Date: Fri, 31 Dec 1999 22:55:35 +875400 > > X-Mailer: Mutt 0.93.2i > > Methinks this version of Mutt may have a Y2K problem, as 875400 hours is > roughly (very roughly) a century My brain has a Y2K problem ... make that "one year" instead of "a century". ;-( -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xntpd - VERY old folks, how about updating? :-)
Karl Denninger <[EMAIL PROTECTED]> posted a message with the headers: > Date: Fri, 31 Dec 1999 22:55:35 +875400 > X-Mailer: Mutt 0.93.2i Methinks this version of Mutt may have a Y2K problem, as 875400 hours is roughly (very roughly) a century -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hicup , Hicup ....
Joy and Happiness to All on this New Millenium !! Amancio & Bettina -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
