Re: Serious problems installing -CURRENT (was: UPDATING)
On Thu, 3 Feb 2000, Peter Jeremy wrote: IMHO, ntp should be configured to use POSIX extensions on the i386. P1003_1B and _KPOSIX_PRIORITY_SCHEDULING are enabled in the GENERIC i386 kernel (as of 2 weeks ago), so standard utilities should be free to use it. If the running kernel doesn't support P1003.1b, then ntpd detects it at run-time, logs the fact and works around it. The This seems to depend on the relevant P1003.1b syscalls being supported as stubs when the corresponding options are not configured. ntp is doing well if it falls back to another method after the syscalls fail. (The syscalls are kind enough to return ENOSYS without generating a SIGSYS like normal unsupported syscalls.) The presence of the stubs may also confuse autoconf. The situation might be slightly different on the Alpha since it's not clear to me whether P1003_1B is supported on the Alpha or not (it's not mentioned in Alpha GENERIC, though all the code implementing _KPOSIX_PRIORITY_SCHEDULING seems to be machine-independent). This is probably just bitrot in the alpha GENERIC. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious problems installing -CURRENT (was: UPDATING)
On 2000-Feb-03 20:11:57 +1100, Bruce Evans [EMAIL PROTECTED] wrote: ntp is doing well if it falls back to another method after the syscalls fail. ntpd iterates (at runtime) through all the possible scheduling mechanisms that were enabled at compile time, until one works. These are (in order) SetPriorityClass() (LoseNT only), sched_setscheduler(), rtprio(), nice(), setpriority(). If all these fail, it will log a message that it couldn't improve it's priority - in which case it will still function, but probably won't be as accurate. (ntpd is probably a special case, in that the P1003.1b functions aren't essential to it, they just improve its operation). (The syscalls are kind enough to return ENOSYS without generating a SIGSYS like normal unsupported syscalls.) /sys/posix4/p1003_1b.c uses syscall_not_present() as a stub routine, this includes the comment 'a " return nosys(p, uap); " here causes a core dump.' and returns ENOSYS. I'm not sure who wrote this comment. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious problems installing -CURRENT (was: UPDATING)
In message [EMAIL PROTECTED], Peter Jeremy writes: On 2000-Feb-03 20:11:57 +1100, Bruce Evans [EMAIL PROTECTED] wrote: ntp is doing well if it falls back to another method after the syscalls fail. ntpd iterates (at runtime) through all the possible scheduling mechanisms that were enabled at compile time, until one works. These are (in order) SetPriorityClass() (LoseNT only), sched_setscheduler(), rtprio(), nice(), setpriority(). If all these fail, it will log a message that it couldn't improve it's priority - in which case it will still function, but probably won't be as accurate. (ntpd is probably a special case, in that the P1003.1b functions aren't essential to it, they just improve its operation). Actually none of this seems to have much effect on it's performance since we timestamp packets in the kernel on input and the chances of being preempted between constructing the output packet and sending it is epsilon. -- 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: Serious problems installing -CURRENT (was: UPDATING)
On Wed, 2 Feb 2000, Ollivier Robert wrote: According to Bruce Evans: ntp should use the POSIX feature test macros for these functions. Unfortunately, it uses autoconfig, and we turn this into hard coded configuration by committing the generated config.h file as a source file. Wouldn't work. Autoconf finds the sched_* functions regardless of their presence in the kernel config. file. Autoconf is a compile-time utility whereas we'd need something more sophisticated to get this right. ntp would work if it were configured POSIXly. autoconf cannot work. Another problem is that the presence of the sched_* functions in headers is independent of kernel options, so compile time POSIX feature tests don't work. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious problems installing -CURRENT (was: UPDATING)
On 2000-Feb-02 19:07:10 +1100, Bruce Evans [EMAIL PROTECTED] wrote: On Wed, 2 Feb 2000, Ollivier Robert wrote: Wouldn't work. Autoconf finds the sched_* functions regardless of their presence in the kernel config. file. Autoconf is a compile-time utility whereas we'd need something more sophisticated to get this right. ntp would work if it were configured POSIXly. autoconf cannot work. Autoconf has the ability to build and execute test code, so autoconf can determine the presence (or otherwise) of optional kernel features in the build machine. It (obviously) can't determine the runtime feature set (but this is a generic cross-building problem). IMHO, ntp should be configured to use POSIX extensions on the i386. P1003_1B and _KPOSIX_PRIORITY_SCHEDULING are enabled in the GENERIC i386 kernel (as of 2 weeks ago), so standard utilities should be free to use it. If the running kernel doesn't support P1003.1b, then ntpd detects it at run-time, logs the fact and works around it. The sysadmin can chose to enable P1003.1b, rebuild ntp without P1003.1b or ignore the messages. The situation might be slightly different on the Alpha since it's not clear to me whether P1003_1B is supported on the Alpha or not (it's not mentioned in Alpha GENERIC, though all the code implementing _KPOSIX_PRIORITY_SCHEDULING seems to be machine-independent). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Serious problems installing -CURRENT (was: UPDATING)
On Tuesday, 1 February 2000 at 16:08:44 +0100, Eric Jacoboni wrote: Max Khon [EMAIL PROTECTED] writes: actually instructions are wrong. you can't build xinstall before `make buildworld' now with old libc. I have to do buildworld _first_, then build xinstall _without_ cleaning, then make a installworld. I've been trying to build a world for a week now. It's not as simple as that. I can install the new libc with an old version of install, then build xinstall and install it, and I still get these errors. On one occasion did a complete installworld (less xinstall) with the old version of install, but the next make world (with new xinstall) still failed. I'm investigating, but something else seems to be wrong. My best guess is that the C library isn't being built correctly. I'm also getting: $ rlogin localhost /usr/libexec/ld-elf.so.1: rlogin: Undefined symbol "rcmd_af" Feb 1 12:14:59 panic ntpd[96]: ntpd 4.0.99b Tue Feb 1 05:21:28 CST 2000 (1) Feb 1 12:14:59 panic /kernel: cmd ntpd pid 96 tried to use non-present sched_get_priority_max Feb 1 12:14:59 panic /kernel: cmd ntpd pid 96 tried to use non-present sched_setscheduler I've seen a message that this last is related to POSIX threads, but I haven't had any confirmation, and that should be mentioned somewhere UPDATING. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious problems installing -CURRENT (was: UPDATING)
On Wed, 2 Feb 2000, Greg Lehey wrote: On Tuesday, 1 February 2000 at 16:08:44 +0100, Eric Jacoboni wrote: Max Khon [EMAIL PROTECTED] writes: actually instructions are wrong. you can't build xinstall before `make buildworld' now with old libc. I have to do buildworld _first_, then build xinstall _without_ cleaning, then make a installworld. I've been trying to build a world for a week now. It's not as simple as that. I can install the new libc with an old version of install, then build xinstall and install it, and I still get these errors. On one occasion did a complete installworld (less xinstall) with the old version of install, but the next make world (with new xinstall) still failed. I'm investigating, but something else seems to be wrong. My best guess is that the C library isn't being built correctly. I'm also getting: $ rlogin localhost /usr/libexec/ld-elf.so.1: rlogin: Undefined symbol "rcmd_af" Feb 1 12:14:59 panic ntpd[96]: ntpd 4.0.99b Tue Feb 1 05:21:28 CST 2000 (1) Feb 1 12:14:59 panic /kernel: cmd ntpd pid 96 tried to use non-present sched_get_priority_max Feb 1 12:14:59 panic /kernel: cmd ntpd pid 96 tried to use non-present sched_setscheduler I've seen a message that this last is related to POSIX threads, but I haven't had any confirmation, and that should be mentioned somewhere UPDATING. I can confirm that adding the POSIX options mentioned in the messages of Mike Bristow makes the messages go away. Which is something else than explaining what is going on here. I cannot even guess. I have a number of problems building things, esp. ports that depend on the libraries involved, giflib e.g. Maybe the fact that I built world, then got the message to first install xinstall (after 5 days!), and subsequently did so and made world again is to blame? -- Marc Schneiders [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Solved: Serious problems installing -CURRENT (was: UPDATING)
On Wednesday, 2 February 2000 at 9:37:44 +1030, Greg Lehey wrote: On Tuesday, 1 February 2000 at 16:08:44 +0100, Eric Jacoboni wrote: Max Khon [EMAIL PROTECTED] writes: actually instructions are wrong. you can't build xinstall before `make buildworld' now with old libc. I have to do buildworld _first_, then build xinstall _without_ cleaning, then make a installworld. I've been trying to build a world for a week now. It's not as simple as that. I can install the new libc with an old version of install, then build xinstall and install it, and I still get these errors. On one occasion did a complete installworld (less xinstall) with the old version of install, but the next make world (with new xinstall) still failed. I'm investigating, but something else seems to be wrong. My best guess is that the C library isn't being built correctly. Well, I've found the problem: I was using the wrong libraries after all. Sure, I checked, but what I was checking for was lib/libc.so.4, and that's what I had, unfortunately on the wrong system. Specifically, it seems that ldconfig -m doesn't work the way I thought. During the system startup, I had effectively: ldconfig /usr/lib/compat /usr/X11R6/lib /usr/X11R6/lib/aout /usr/local/lib ldconfig -m /freebie/usr/lib /T/local/lib /freebie/usr/X11R6/lib The second list of directories are on another -CURRENT machine, one older than the one I'm building on. I do this to have access to programs on that machine (specifically the ones in its /usr/local, which is mounted on /T/local). But it seems that the -m option *replaces* all the local libraries with the ones that it finds, so my libc was /freebie/usr/lib/libc.so.4, which was old. I'm also getting: $ rlogin localhost /usr/libexec/ld-elf.so.1: rlogin: Undefined symbol "rcmd_af" This is gone as well now. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious problems installing -CURRENT (was: UPDATING)
According to Greg Lehey: Feb 1 12:14:59 panic /kernel: cmd ntpd pid 96 tried to use non-present sched_get_priority_max Feb 1 12:14:59 panic /kernel: cmd ntpd pid 96 tried to use non-present sched_setscheduler I've seen a message that this last is related to POSIX threads, but I haven't had any confirmation, and that should be mentioned somewhere UPDATING. As the sched_* functions are now enabled by default (POSIX stuff) in GENERIC I decided to enable their use within ntpd. See -current just after I did the upgrade. -- 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: Serious problems installing -CURRENT (was: UPDATING)
On Wed, 2 Feb 2000, Ollivier Robert wrote: According to Greg Lehey: Feb 1 12:14:59 panic /kernel: cmd ntpd pid 96 tried to use non-present sched_get_priority_max Feb 1 12:14:59 panic /kernel: cmd ntpd pid 96 tried to use non-present sched_setscheduler I've seen a message that this last is related to POSIX threads, but I haven't had any confirmation, and that should be mentioned somewhere UPDATING. As the sched_* functions are now enabled by default (POSIX stuff) in GENERIC I decided to enable their use within ntpd. ntp should use the POSIX feature test macros for these functions. Unfortunately, it uses autoconfig, and we turn this into hard coded configuration by committing the generated config.h file as a source file. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious problems installing -CURRENT (was: UPDATING)
According to Bruce Evans: ntp should use the POSIX feature test macros for these functions. Unfortunately, it uses autoconfig, and we turn this into hard coded configuration by committing the generated config.h file as a source file. Wouldn't work. Autoconf finds the sched_* functions regardless of their presence in the kernel config. file. Autoconf is a compile-time utility whereas we'd need something more sophisticated to get this right. -- 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: Serious problems installing -CURRENT (was: UPDATING)
ntp should use the POSIX feature test macros for these functions. Unfortunately, it uses autoconfig, and we turn this into hard coded configuration by committing the generated config.h file as a source file. Wouldn't work. Autoconf finds the sched_* functions regardless of their presence in the kernel config. file. Autoconf is a compile-time utility whereas we'd need something more sophisticated to get this right. Actually the current way works pretty well. Ntpd will try to use the sched_* functions, but if they fail it will try other ways to set the priority. It is just the fact that it logs the the fact that the sched_* functions are not available that gives people a shock ... and a chance to enable it in their kernel. :-) John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message