traceroute breakage in -current
I just noticed that traceroute in -current is starting its probes with port 1 instead of 33435 as it is supposed to do: tcpdump: listening on fxp0 09:05:03.527313 206.213.73.12.38947 > 204.216.27.21.1: udp 12 [ttl 1] 09:05:03.532569 206.213.73.12.38947 > 204.216.27.21.2: udp 12 [ttl 1] 09:05:03.533400 206.213.73.12.38947 > 204.216.27.21.3: udp 12 [ttl 1] 09:05:03.534319 206.213.73.12.38947 > 204.216.27.21.4: udp 12 09:05:03.559521 206.213.73.12.38947 > 204.216.27.21.5: udp 12 09:05:03.581135 206.213.73.12.38947 > 204.216.27.21.6: udp 12 09:05:03.603108 206.213.73.12.38947 > 204.216.27.21.7: udp 12 09:05:03.628822 206.213.73.12.38947 > 204.216.27.21.8: udp 12 09:05:03.650996 206.213.73.12.38947 > 204.216.27.21.9: udp 12 09:05:03.673285 206.213.73.12.38947 > 204.216.27.21.10: udp 12 It broke in revision 1.9 of "src/contrib/traceroute/traceroute.c". John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: Soft-updates sources are moving soon
Sometime this weekend (July 3-5) I am planning to repository-copy the soft-updates sources from their current location in "src/contrib/sys/softupdates" to "src/sys/contrib/softupdates". All of you using soft-updates will need to adjust your symbolic links in "src/sys/ufs/ffs" after this change has taken effect. The reasons for the move have been discussed before. Briefly, we want to move all of the kernel code to "src/sys" so that the sys tree will be more self-contained. Kirk McKusick has agreed to this change -- in fact he favors it. I'm going to do this in both the -current and RELENG_3 branches. Here is the 1-question FAQ: Q. These symbolic links are a pain. Why don't you just edit "src/sys/conf/files" appropriately? A. The license terms for soft-updates do not permit that. See the FreeBSD mailing list archives (the FreeBSD-current list, probably) for more details. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Soft-updates sources are moving soon
George Michaelson wrote: > Q. These symbolic links are a pain. Why don't you just edit > "src/sys/conf/files" appropriately? > > A. The license terms for soft-updates do not permit that. See the > FreeBSD mailing list archives (the FreeBSD-current list, probably) for > more details. > > Would it be legal under the licence to include a rule in some Makefile > which did the damn things, but was not automatically invoked anywhere? Please don't start a discussion about this without first studying the mailing list archives. All of this stuff has been discussed before, and needn't be rehashed again. > Would it be legal to include in standard CVSUP configs rules which prevent > loss of the links if installed? > > o I may be wrong, but I think I loose them when I refresh if some rules > are present. CVSup won't touch your symbolic links. It won't touch any file that it doesn't know anything about. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Soft-updates sources are moving soon
George Michaelson wrote: > > The discussion(s) took place on [EMAIL PROTECTED] > > The search string in the archives which works is: > > kirk AND soft-update AND integration > > note the soft-update, not softupdates. Thanks! I couldn't remember for sure where the discussion had been. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
In article <[EMAIL PROTECTED]>, Matthew Dillon <[EMAIL PROTECTED]> wrote: > Hey, I just had a thought... and a question. When we are using > cvsup to keep a local CVS reposity in sync, can we tag our local > CVS resposity without cvsup deleting the tags? Yes, you can do it if you're careful. There's a section "Local Modifications in your CVS Repository" in the CVSup FAQ that talks about it. http://www.polstra.com/projects/freeware/CVSup/ John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soft-updates feedback
I don't know why I'm on the cc for this thread, but please remove me. And it shouldn't be cross-posted to 2 lists. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: Soft-updates sources have been moved
I have just finished moving the soft-updates sources to "src/sys/contrib/softupdates", as announced a few days ago. All users of soft-updates will need to update their symbolic links in "src/sys/ufs/ffs" before configuring and building a new kernel. This change affects the main branch (-current), the RELENG_3 branch (-stable), and Warner's RELENG_3_2_PAO branch. I've updated the comments in LINT and README.softupdates accordingly. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: loads of SetAttrs in cvsup of cvs repo
In article <[EMAIL PROTECTED]>, Wilko Bulte <[EMAIL PROTECTED]> wrote: > Maybe this is a stupid question and/or FAQ but: You probably should have written to [EMAIL PROTECTED] instead of the -current list. > I'm currently cvsupping updates on the CVS repository. Most of the > times that is a couple of minutes, but today it is already 1 hour busy. > > Mainly with: > > SetAttr > > (loads and loads of these). > > What gives? Several things can cause this: - You are running cvsup with a different umask than usual. To guard against this, you can add a "umask=022" setting in your supfile (CVSup-16.0 and later). - You are running cvsup under a different user-id than usual. This probably has no effect unless you have "preserve" in your supfile. That's almost always a bad idea except for special situations. - You've accidentally touched all the files in your repository in some way (changed their modtimes, changed their permissions, changed their owners, etc.). John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: loads of SetAttrs in cvsup of cvs repo
Mike Pritchard wrote: >> In article <[EMAIL PROTECTED]>, >> >> - You are running cvsup with a different umask than usual. To guard >> against this, you can add a "umask=022" setting in your supfile >> (CVSup-16.0 and later). > > Speaking of CVSup-16.0, I can't get the port in /usr/ports/net/cvsup to > link. I get the following error message: > > -> linking cvspasswd > /usr/lib/crt0.o: file not recognize: File format not recognized It looks like you have an old (a.out) Modula-3 installation. Pkg_delete modula-3 and modula-3-lib and then try again. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: loads of SetAttrs in cvsup of cvs repo
Wilko Bulte wrote: >> Several things can cause this: >> >> - You are running cvsup with a different umask than usual. To guard >> against this, you can add a "umask=022" setting in your supfile >> (CVSup-16.0 and later). > > I ran cvsup as root, umask set to 022. OK, that must not have been the problem. >> - You are running cvsup under a different user-id than usual. This >> probably has no effect unless you have "preserve" in your supfile. >> That's almost always a bad idea except for special situations. > > I run it as root, and have always done so. Is this a bad idea maybe? No, that's fine. >> - You've accidentally touched all the files in your repository in >> some way (changed their modtimes, changed their permissions, changed >> their owners, etc.). > > Not that I recall having done so. But I'll keep a close eye on this. Other possibilities: - You lost your "checkouts.cvs" file somehow. It's supposed to be underneath your cvsup "base" directory somewhere. Don't bother looking for it, because cvsup will have recreated it for you by now. - You changed your supfile in some way. - Your friendly mirror site maintainer accidentally touched his copies of the files. And of course there's always the possibility that it was caused by a plain old bug in CVSup. > I just gave cvsup another try and it only took a few minutes updating > some files in the repository. Which looked just fine. Good. I'm glad it's OK again. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: utmp & last
In article <[EMAIL PROTECTED]>,
Ayan George <[EMAIL PROTECTED]> wrote:
>
> What seems strange is that they use the different data types to
> store the same information (the time):
>
> struct lastlog {
> time_t ll_time;
> charll_line[UT_LINESIZE];
> charll_host[UT_HOSTSIZE];
> };
>
> struct utmp {
> charut_line[UT_LINESIZE];
> charut_name[UT_NAMESIZE];
> charut_host[UT_HOSTSIZE];
> longut_time;
> };
>
> Not that there is any _real_ difference between long and time_t,
On the Alpha, a long is 64 bits but a time_t is 32 bits.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Problem with cvsup
[By the way, it was a no-no to cross-post this to two mailing lists. I've removed -stable from the cc line.] In article <[EMAIL PROTECTED]>, obituary <[EMAIL PROTECTED]> wrote: > > What I don't understand, however, is that the pppd/natd setup I have > here works flawlessly for web browsing, ftp, news/mail retreval, etc., > yet it can't seem to handle cvsup connections. Wierd. CVSup has a tendency to expose network problems, because it uses TCP in somewhat atypical ways. Still, multiplexed mode is more "normal" than the others. I'm surprised you're having problems using it, even with NAT. If you have some time to spend on this, some tcpdumps might provide a clue. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Moving ipf(1) to ipf(8)?
In article <[EMAIL PROTECTED]>,
Nik Clayton <[EMAIL PROTECTED]> wrote:
>
> Assuming I did this, what's the approved method?
>
> Myself, I'd just
>
> # mv ipf.1 ipf.8
> # cvs remove ipf.1
> # cvs add ipf.8
> # cvs commit -m "Renamed ipf.1 to ipf.8" ipf.1 ipf.8
> [... check for any other man pages that refer to ipf(1) and update
> them accordingly ...]
>
> which properly reflects that (until the change) ipf.8 didn't exist. I
> *would not* use a repository copy for this.
When in doubt, ask the repo-man. :-)
There's enough history in the file that _if_ it were going to be
renamed, a repository copy should be used. (I don't like them either,
but they're What We Do.)
However, you shouldn't rename the file, because it is in the contrib
tree. The whole point of contrib is that it must stay as nearly
identical to the author's distributions as possible, so that imports
of new versions aren't painful.
I think you should lobby the author <[EMAIL PROTECTED]> to rename
the file in his own tree. Then the problem goes away when the next
release is imported.
Meanwhile, if you want to install it into man8, you could do it with
special rules in "src/sbin/ipf/Makefile". Something like this
(untested) should do the trick:
MAN8= ipf.8
CLEANFILES+= ipf.8
ipf.8: ipf.1
cp ${.ALLSRC} ${.TARGET}
and delete the MAN1 line for ipf.1.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-current [/usr/libexec/ld-elf.so.1: cc: Undefined symbol "mkstemps"]
In article <[EMAIL PROTECTED]>, Charles Henrich <[EMAIL PROTECTED]> wrote: > I've recently upgraded to 4.0 from 3.2-stable and now whenever I try and > compile something I get: > > /usr/libexec/ld-elf.so.1: cc: Undefined symbol "mkstemps" > *** Error code 1 That symbol should be defined in "/usr/lib/libc.so.3". Do a "nm" on the library and see if that's the case. If not, then you must have an old libc. (How did that happen?) If the symbol _is_ defined there, your ldconfig path might be wrong such that cc isn't using the correct library. Type "ldd /usr/bin/cc" to see which libraries it's really finding. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Library question/challenge
In article <[EMAIL PROTECTED]>, Jeroen Ruigrok/Asmodai <[EMAIL PROTECTED]> wrote: > > /usr/libexec/ld.so: warning: /usr/lib/libc.so.3: minor version -1 older > than expected 0, using it anyway > ld.so failed: bad magic number in "/usr/lib/libc.so.3" > > This is netscape4.5 on CURRENT tracked since October 1998. > > One change since my previous builds is that I uncommented compat22 and > compat3x prior to making world. > > I have the default aout ld path in /etc/defaults/rc.conf, none in > /etc/rc.conf. > > A ldconfig -aout -r | head -2 yields: > > /var/run/ld.so.hints: > search directories: /usr/lib/aout:/usr/lib/compat/aout: > /usr/X11R6/lib/aout:/usr/local/lib/aout > > [ it has about 66 libs in this hints file ] Run ldd on the netscape binary and figure out why it's finding the wrong libc. Make sure you don't have LD_LIBRARY_PATH set to include "/usr/lib". John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Library question/challenge
Jeroen Ruigrok/Asmodai wrote: > * Matthew Dillon ([EMAIL PROTECTED]) [990729 07:20]: >> lib/libc.so.3: minor version -1 older >> :> than expected 0, using it anyway >> :> ld.so failed: bad magic number in "/usr/lib/libc.so.3" Look, it's finding its library in "/usr/lib" and it shouldn't be doing that. This is the problem, and there's no point in upgrading X11 or any such thing. > Well, it seems to want libc.so.3.1 and that one is present in /usr/lib/aout > and is grepable from ldconfig -aout -r: > > [asmodai@daemon:/usr/home/asmodai] (3) $ ldconfig -aout -r | grep libc.so > 27:-lc.3.1 => /usr/lib/aout/libc.so.3.1 Right. So the problem must be that you have LD_LIBRARY_PATH set. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Library question/challenge
Jeroen Ruigrok/Asmodai wrote: > * John Polstra ([EMAIL PROTECTED]) [990729 18:49]: >> >> Right. So the problem must be that you have LD_LIBRARY_PATH set. > > Yes I have, but this hasn't been a problem for the last 5-6 months. > In what way could it interfere with my ldconfig then? (I read man 1aout ld) It won't intefere with ldconfig, but it will affect what the dynamic linker does. If you have "/usr/lib" in your LD_LIBRARY_PATH then the dynamic linker will find libc there, rather than in "/usr/lib/aout" as it should. I don't know why it didn't cause problems for you earlier. This was netscape, right? If so, there's an easy fix. The command that you execute for netscape is really a shell script which does some stuff and then executes a big binary somewhere else. You could add "unset LD_LIBRARY_PATH" to that shell script to work around the problem. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make cvsup broken
In article <[EMAIL PROTECTED]>, Randy Bush <[EMAIL PROTECTED]> wrote: > ===> client > m3build > mkdir FreeBSD2 > --- building in FreeBSD2 --- > "/usr/ports/net/cvsup/work/cvsup-16.0/client/src/m3makefile", line 1: unable to read >".M3EXPORTS" >from directory "FreeBSD2" of package "formsvbt" (/usr/local/lib/m3/pkg/formsvbt) I don't believe the port is broken. Nobody has changed it recently. Maybe your disk filled up. Maybe you ran out of memory. Make sure you have plenty of swap, and use "ulimit" or "limit" to remove any memory-related resource limits prior to building the port. >From the weird stuff in your other recent bug reports, I also think it's entirely possible that your hardware or kernel or filesystems are messed up. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dropping connections without RST
In article <[EMAIL PROTECTED]>, Geoff Rehmet <[EMAIL PROTECTED]> wrote: > > > > Plus, packets with RST in them are used for other purposes besides > > rejecting new incoming connections.. > > True, my implementation is specific that I only omit generating > a RST when the icoming segment is a SYN. All other instances > where you would generate a RST are left alone, and carry on > behaving as before - otherwise you might break TCP behaviour. I like the idea. However, something a _little_ more sophisticated would be nice. The policy you describe above wouldn't work against stealth probes. From the nmap man page: -sF -sX -sN Stealth FIN, Xmas Tree, or Null scan modes: There are times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to restricted ports, and programs like Synlog- ger and Courtney are available to detect these scans. These advanced scans, on the other hand, may be able to pass through unmolested. The idea is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the packets in question (see RFC 794 pp 64). The FIN scan uses a bare (surprise) FIN packet as the probe, while the Xmas tree scan turns on the FIN, URG, and PUSH flags. The Null scan turns off all flags. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SIGBUS [was Re: gdb]
In article <[EMAIL PROTECTED]>, Amancio Hasty <[EMAIL PROTECTED]> wrote: > > On 18 Aug 1999, Joel Ray Holveck wrote: > > > > > That reminds me. I thought that SIGBUS meant byte-alignment errors. > > > What does it mean on FreeBSD/x86? > > The boehm garbage collector is trying to find the memory limit so I guess > in FreeBSD is going to get a SIGBUS. > > In linux they get SIGV Right. FreeBSD gives SIGBUS for pages that are mapped but protected, and SIGSEGV for pages that aren't mapped at all. As I recall, Linux doesn't even have SIGBUS as far as the kernel is concerned. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cc -O broken in -current for Alpha KLDs
In article <[EMAIL PROTECTED]>, Andrew Gallatin <[EMAIL PROTECTED]> wrote: > > I've just committed a patch to alpha/alpha/elf_machdep.c which takes > into account the addends for objects of type R_ALPHA_GLOB_DAT. This > fixes my problem. Should it be MFC'ed? Nice work! It looks right to me, not to mention that it now agrees with what the dynamic linker does. I think you should definitely bring it into -stable. For good form you might want to give it another day or two in -current first. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Building older -current on newer -current?
In article <[EMAIL PROTECTED]>, Bill Swingle <[EMAIL PROTECTED]> wrote: > I've got a laptop that's giving me all kinds of pccard headaches > and I'd like to get it back to -current from the begining of the > month before I was having these problems. Is there any reason why I > couldn't make world from some time around 12/8/99 on -current from > yesterday evening? Would I have to build a new kernel first? Normally it's possible, and you don't need a new kernel to do it. 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: gcc compiler problem part deux
In article <[EMAIL PROTECTED]>, Peter Jeremy <[EMAIL PROTECTED]> 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. This can make converting to 'cc -E' a > non-trivial exercise. That's what /dev/stdin is for: cat hello.c | cc -E -x c /dev/stdin 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]>, 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: 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: 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: 4.0 slower than 3.4?
In article <[EMAIL PROTECTED]>, james <[EMAIL PROTECTED]> wrote: > It's interesting though how i had no ipf rules whatsoever, yet it > introduced so much latency, as Alexander has pointed out in another email. > Why is ipf so slow? I was planning on switching from ipfw/natd to > ipf/ipnat, but i don't think i want to now - considering it's so darn slow. If you want to do NAT, I can tell you without even trying it that ipfilter's NAT will be much faster than natd's. With natd, every packet has to go out from the kernel to userland and back to have its headers rewritten. That's a lot of overhead. Not so with ipfilter -- it's all done inside the kernel. 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: __sigisempty() undefined if "cc -g" used.
In article <[EMAIL PROTECTED]>, Bruce Evans <[EMAIL PROTECTED]> wrote: > > You apparently > clobbered -O in CFLAGS by setting CFLAGS=-g. -g normally needs to be > added to CC to avoid breaking CFLAGS (CC='cc -g'). Better yet: DEBUG_FLAGS=-g John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.
In article <[EMAIL PROTECTED]>, Jason Evans <[EMAIL PROTECTED]> wrote: > The buildworld problem that I introduced is due to cc_fbsd directly > compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my > opinion a questionable practice, since it adds dependencies to the > internals of the libc code, which has just been proven to bite. =) Yes, I agree. > Aesthetics aside, I'm not sure what the best fix for the problem is. > Options include: > > 1) Ignore the problem, since it only happens once, and has a work-around. >This is probably not a good idea, since it makes the upgrade path >bumpy. Yes, please avoid this if at all possible. We've had too many of these "one-time" special procedures in the past year. Committers haven't been trying hard enough to avoid them, IMHO. The trouble with special upgrade procedures is that they linger for a year beyond when the problem began, as different users try upgrading and run into trouble. Also, they're a big PITA for system admins who have many machines to upgrade. > 2) Make a separate copy of mktemp.c to remove the internal dependency. I think this is the best approach -- likewise for getobjformat.c, which is also used currently. I _really_ don't like it when a program reaches waaay over into an unrelated directory for its sources. This isn't the first time it has caused unexpected problems. If you change the internals of a self-contained subtree, you should reasonably be able to assume that it won't break something on the other side of the source tree. I'd rather have a few duplicated sources. >I'm not familiar with the detailed semantics of mktemp() but >this may be a problem if mktemp() is required to behave the same >across all programs, and the two versions of mktemp.c diverge. I'd still rather have a few duplicated sources. > > 3) Add conditional compilation, such that the macro _libc_open=open is >defined during the cross-tools stage. I tried this, but wasn't able to >find an obvious way of inserting it into the build system. Besides, >it's a bit of a hack, and doesn't address the core issue (dependency on >libc internals). Right. Ick. > 4) Build a libc for the cross-tools stage that all the targets for that >stage can be linked against. This looks cleanest to me, but adds >substantially to build time and may be difficult to implement. 5) Maintainers of the build tools should be very careful to ensure that their tools use only the minimum, universally-available functionality from libc. That means (ideally) only functions which appear in the ANSI/ISO C standard, or (tolerably) only functions which appear in ANSI/ISO C or POSIX. This means: if you need a FreeBSD-specific function such as getobjformat() then you write your own version of it, or copy the source and maintain it separately, or look for a different approach. 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: RFC: buildworld breakage due to cross-tools/libc/mktemp.
In article <[EMAIL PROTECTED]>, David O'Brien <[EMAIL PROTECTED]> wrote: > On Wed, Jan 12, 2000 at 07:00:01PM -0800, John Polstra wrote: > > > I _really_ don't like it when a program reaches waaay over into an > > unrelated directory for its sources. > > We already do that all over the place. :-) We do it in a few places, but not many. That doesn't make it a good practice, anyway. Those few places where it is done have been responsible for more than their share of unpleasant surprises in the form of make world breakage. > > I'd rather have a few duplicated sources. > > I dissagree. Then we have the problem of fixing a PR/bug in one source > but not the other. Such duplicated routines should be few in number and simple in function. Compilers don't need much support from the underlying OS. All they do is read files, perform various transformations on them, and write out the results. You don't need anything beyond what ANSI/ISO C provides to accomplish that. It is not ideal to have some duplicated code, but the alternative is worse. > The use/making of temperary files is already a security issue. I > can just see it happen that someone fixes a problem with one copy of > the source and then we find we still have some vulerabiltity because > the second copy wasn't known/found/fixed. Come on, this is the compiler we're talking about. I seriously doubt there are any real-life security issues there. If there are, then you duplicate mkstemp. Surely it isn't such a complicated function that that can't be done reliably. 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: C++ exceptions doesn't work in shared libraries
In article <[EMAIL PROTECTED]>, David O'Brien <[EMAIL PROTECTED]> wrote: > On Wed, Jan 12, 2000 at 10:01:42AM +0200, Maxim Sobolev wrote: > > Is there are any compiler guys to address my question or not? > > There is, I'm the one. But there are a few things ahead in the queue. > Of course a patch would make things go much faster. The problem is caused by the fact that we are still using our own home-grown versions of crtbegin.o and crtend.o (from "src/lib/csu"). We need to use the ones built from crtstuff.c in "src/contrib/gcc". 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: Rolling OSVERSION
In article <[EMAIL PROTECTED]>, Kris Kennaway <[EMAIL PROTECTED]> wrote: > Unless anyone objects I'm going to bump OSVERSION tonight to provide a > cutoff for whether or not openssl is available in the base system. Ports > need to behave differently in either case.. You mean "__FreeBSD_version" (in src/sys/sys/param.h), right? John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: breakage
In article <[EMAIL PROTECTED]>, Warner Losh <[EMAIL PROTECTED]> wrote: > > I did a make world Sunday and it worked. I did a makeworld today and > it was busted. Turned out to be a cvsup problem that I owe jdp a > message about. Details, please. If I had a nickel for every "CVSup problem" that turned out to be something else, I'd be a rich man today. 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: Error building current
In article <[EMAIL PROTECTED]>, Warner Losh <[EMAIL PROTECTED]> wrote: > > I hit this problem as well. Put 'delete' in your cvsup file. > Otherwise you'll get screwed. This is a misfeature of cvsup, imho, I'm sorry you think so. I did it that way for backward compatibility with sup. If I hadn't made it compatible, I never could have persuaded anybody to try the software. Also, there are situations (e.g., maintaining local modifications in your repository) where delete should not be used. So it really needs to be an option. It would be better if the default were to delete and there was a "nodelete" option. But that wouldn't have been compatible. 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: rtld-elf, java + tya
In article <[EMAIL PROTECTED]>, Max Khon <[EMAIL PROTECTED]> wrote: > hi, there! > > applet_viewer bombs out with a lot of stuff in the output like this > (until killed -9): > > ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 Really?! Augh. Naturally this comes just hours after I have merged the latest changes into -stable *sigh*. Could you please make sure your src/libexec/rtld-elf is up-to-date? rtld.c should be at revision 1.41. Then if you can give me a stack backtrace it would help a lot. Thanks, 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: rtld-elf, java + tya
In article <[EMAIL PROTECTED]>, Russell L. Carter <[EMAIL PROTECTED]> wrote: > I've seen it with yesterdays current and libc_r threads, and it's intermittent. Did this problem just start, or has it been there for awhile? I haven't changed the dynamic linker in -current since January 9, and I'm wondering if a more recent change in a different part of the system is causing trouble. 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
Please help spread the CVSup mirror load more evenly
This is another in my series of occasional nags to try to get people to use some of the less heavily loaded CVSup mirrors. In the US alone, we have 8 mirror sites now, named (duh) cvsup[1-8].FreeBSD.org. The newest, cvsup8, is a very high-capacity and well-connected site, yet hardly anybody is using it. Please give it a try! You can find the full list of mirrors worldwide at: http://www.freebsd.org/handbook/mirrors-cvsup.html Remember, the mirrors are equivalent in the sense that they get their updates from the master server at the same intervals (hourly). There is nothing "better" about the lower-numbered mirrors, and they don't get their updates any sooner or more reliably. In fact, the higher-numbered mirrors often have faster hardware simply because they're newer. Also, in particular, there's nothing special about cvsup.FreeBSD.org -- it's simply an alias for cvsup1 and it gets its updates the same way at the same intervals from the same master server as all the other mirrors. To choose a mirror site, try pinging the mirrors in your country. Pick one with a low packet loss rate. The round trip time doesn't matter very much as long as it doesn't undergo wild variations. Second, pick a site that's not too heavily loaded. If your update _ever_ fails because the server is too busy, then you should try a different mirror -- because there are many mirrors that aren't even close to their full loads even at the busiest of times. Thanks for your cooperation. 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: Please help spread the CVSup mirror load more evenly
In article <[EMAIL PROTECTED]>, I wrote: > To choose a mirror site, try pinging the mirrors in your country. I have been reminded that a few mirrors (cvsup8 in particular) filter pings. Don't take ping failures as a certain indication that the server is down. 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: Please help spread the CVSup mirror load more evenly
In article <[EMAIL PROTECTED]>, Amancio Hasty <[EMAIL PROTECTED]> wrote: > If the user does specifiy a cvsup , can you decide for the user which > server is best based upon some simple statistic? Some day I hope it's possible, but there's nothing like that implemented currently. Also there are some problems that must be solved first. CVSup needs a way to ensure that your "update" won't in fact be a step backward in time. For example, suppose you update twice in rapid succession, first from server A and then from server B. Both servers update hourly, but at different times. You happen to hit them at a point where A has updated more recently than B. In that case you'll be unhappy because your second "update" will instead be a "downdate" (backdate? bad date?). This is solvable, but not as easily as you might think. Lots of complications arise when, for example, you interrupt an update in the middle such that some files have been updated while others haven't. There is discussion on all this in the mailing list archives somewhere. 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: rtld-elf, java + tya
In article <[EMAIL PROTECTED]>, Amancio Hasty <[EMAIL PROTECTED]> wrote: > I am fairly certain that Java + TYA worked before Jan 7 -- haven't > upgraded my system since then. Yes, that assert that failed wasn't in the dynamic linker on January 7. What I need to know is: did it start failing soon after January 9, or only just in the past few days? Also I really need a stack trace of a failure to analyze. 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: Please help spread the CVSup mirror load more evenly
> Can you make cvsup accept multiple servers to try in it's configuration > file? I'll add that to the to-do list. 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: even more breakage in current
In article <[EMAIL PROTECTED]>, Jason Evans <[EMAIL PROTECTED]> wrote: > > I often do a 'make includes' to be able to iteratively test changes. Once > I'm happy that the changes are sound, there is no way to assure that the > changes didn't cause a bootstrapping problem like this one. It's feasible to perform valid tests, but it requires some care and planning. Whenever you're changing a system header file, write it down. When you are done making changes, re-install the virgin unadulterated copies of those header files. In general, do your best to restore your system to a pristine state. Then test with make world. Yes, this is a pain. But it's a pain for one person instead of for several hundred. :-) 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: With feature freeze being in place
In article <Pine.BSF.4.21.0001221710330.4454-10@localhost>,
Alex Zepeda <[EMAIL PROTECTED]> wrote:
>
> I'm looking at /usr/{src,}/share/examples/cvsup/gnats-supfile, and as
> "equipped" it's not working (well it goes through the motions but checks
> out no files). Hmm.
It works for me. Not all mirrors carry the more esoteric
collections like gnats. I know that cvsup[15678] carry it. I think
cvsup2 doesn't, and I'm not sure about 3 and 4.
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: rtld-elf, java + tya
In article <[EMAIL PROTECTED]>,
Max Khon <[EMAIL PROTECTED]> wrote:
>
> applet_viewer bombs out with a lot of stuff in the output like this
> (until killed -9):
>
> ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55
The last time this problem happened (I thought I fixed it!), it almost
always appeared very soon after starting a multithreaded program. At
that time I was able to reproduce it with the script below. Those of
you who have seen it might be able to modify the script so it runs
your failing application instead of cvsup. It might help you to get a
stack trace for me (hint hint).
John
#! /bin/sh
#
# for (i = 0; i < $n; i++) {
# start $prog in background
# sleep($t)
# kill $prog
# }
prog=$HOME/bin/cvsup
args="/dev/null"
t=0.5
n=100
if [ $# -ge 1 ]; then
n=$1
fi
go() {
$prog $args &
pid=$!
sleep $t
kill $pid
wait %1
status=$?
if [ $status -ne 143 ]; then
echo "Status = $status"
exit
fi
}
i=0
while [ $i -lt $n ]; do
go
i=$(($i + 1))
done
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: rtld-elf, java + tya
> ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 If any of you can reproduce this problem fairly reliably, please try the appended patch for "src/libexec/rtld-elf/lockdflt.c" and let me know if it solves the problem. Thanks, John Index: lockdflt.c === RCS file: /home/ncvs/src/libexec/rtld-elf/lockdflt.c,v retrieving revision 1.3 diff -u -r1.3 lockdflt.c --- lockdflt.c 2000/01/09 21:13:48 1.3 +++ lockdflt.c 2000/01/23 19:03:26 @@ -28,10 +28,9 @@ /* * Default thread locking implementation for the dynamic linker. It * is used until the client registers a different implementation with - * dllockinit(). The default implementation does mutual exclusion - * by blocking the SIGVTALRM, SIGPROF, and SIGALRM signals. This is - * based on the observation that most userland thread packages use one - * of these signals to support preemption. + * dllockinit(). The default implementation does mutual exclusion by + * blocking almost all signals. This is based on the observation that + * most userland thread packages use signals to support preemption. */ #include @@ -63,10 +62,13 @@ l = NEW(LockDflt); l->depth = 0; -sigemptyset(&l->lock_mask); -sigaddset(&l->lock_mask, SIGVTALRM); -sigaddset(&l->lock_mask, SIGPROF); -sigaddset(&l->lock_mask, SIGALRM); +sigfillset(&l->lock_mask); +sigdelset(&l->lock_mask, SIGTRAP); +sigdelset(&l->lock_mask, SIGABRT); +sigdelset(&l->lock_mask, SIGBUS); +sigdelset(&l->lock_mask, SIGSEGV); +sigdelset(&l->lock_mask, SIGKILL); +sigdelset(&l->lock_mask, SIGSTOP); return l; } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: With feature freeze being in place
In article <[EMAIL PROTECTED]>, Rodney W. Grimes <[EMAIL PROTECTED]> wrote: > Ohhh.. and please update your cvsup-mirror stats, the sizes of things are way > way way out of date: I think I'm just going to remove the stats and replace them with a URL for an automatically-updated list. It's practically impossible to keep them up-to-date in the port. 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: Please help spread the CVSup mirror load more evenly
Before I forget: PLEASE DON'T CC ME ON YOUR REPLIES. I'LL READ THEM IN THE MAILING LIST. THANK YOU. > > Hmmm. A thought just occurred to me. There's no need to measure > > these things. Lookup all the IP addresses. Do a non blocking > > connection to each of these machines. First one to come back with the > > REL16_1 response wins, and all the others get closed and you use that > > one. > > I like this idea, except that some sort of consistency is required - > ie, once I've started using cvsupX, I'd like to use it in preference > to slightly better machines unless it stays bad for some configurable > number of connections Um, guys ... hello? The goal here is to spread the load more evenly. Now it's true that if every CVSup run hits every mirror site that the load will be even. But it will also be a whole helluva lot higher than it is even now. So no, I'm not going to implement any solution that involves pinging or connecting to a bunch of sites every time you start up CVSup. Please, no more pie in the sky ideas. My announcement was simply trying to address a trivial problem for today, namely that too many people are failing to use their brains when filling in that host field in their supfiles. That's all. These fancy solutions are just dandy except they don't solve the problem today and most of them are so complicated that they're extremely unlikely to get implemented (at least by me) any time soon. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rtld-elf, java + tya
In article <[EMAIL PROTECTED]>, Max Khon <[EMAIL PROTECTED]> wrote: > > Seems that this patch fixed the problem for me. > I can not reproduce it anymore. That's good news. Thanks for testing it! I'll commit it later today. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Alpha world breakage in sys/modules/if_tun
This works on the i386 but fails on the Alpha: ===> sys/modules/if_tun @ -> /c/src/sys machine -> /c/src/sys/alpha/include touch opt_devfs.h echo "#define NETATALK 1" > opt_atalk.h echo "#define ATM_CORE 1" > opt_atm.h echo "#define INET 1" > opt_inet.h echo "#define INET6 1" > opt_inet6.h echo "#define IPX 1" > opt_ipx.h echo "#define NATM 1" > opt_natm.h perl @/kern/vnode_if.pl -h @/kern/vnode_if.src rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../includ e -I/usr/obj/c/src/alpha/usr/include /c/src/sys/modules/if_tun/../../net/if_tun .c In file included from @/netatm/kern_include.h:105, from /c/src/sys/modules/if_tun/../../net/if_tun.c:50: @/netatm/atm_if.h:349: #error - Must define hardware-specific requirements here mkdep: compile failed *** Error code 1 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
Need testers for libc_r patch
The attached patch makes libc_r use the recently added hooks in the dynamic linker to provide locking so that the dynamic linker is thread-safe. I have tested it in a simple program and I believe it works OK. If any of you have a -current system with a non-trivial libc_r application, I would appreciate it if you'd give this patch a try and let me know whether you see any problems with it. You can apply the patch by getting into "src/lib/libc_r" and typing "patch -IEp < libc_r.patch" Also, if anybody can point me to programs in the ports collection that use libc_r and aren't too hard to set up and run, that would be helpful too. Thanks, John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa libc_r.patch
Re: y2k problem? naahhh...
In article <[EMAIL PROTECTED]>, Andy Farkas <[EMAIL PROTECTED]> wrote: > > There are some pretty funky date/times being displayed in my daily run > output. Just thought I'd mention it; I've only just upgraded to > 4.0-current and don't recall seeing this before. > > > Backup passwd and group files: > passwd diffs: > --- /var/backups/master.passwd.bakWed Jan 5 10:(password):41 2000 > +++ /etc/master.passwdTue Jan 25 15:(password):44 2000 > @@ -1,3 +1,5 @@ > +# $FreeBSD:(password):09:07 peter Exp $ > +# > root:(password):0:0::0:0:Charlie &:/root:/bin/csh > toor:(password):0:0::0:0:Bourne-again Superuser:/root: > daemon:(password):1:1::0:0:Owner of many system processes:/root:/sbin/nologin Heh, I'd say revision 1.5 of "src/etc/periodic/daily/200.backup-passwd" needs a bit more work. :-) 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: Makefile.inc1 change
In article <[EMAIL PROTECTED]>, Warner Losh <[EMAIL PROTECTED]> wrote: > I will back it out until after 4.0 so this change can be analized in > more detail. What a perfect Freudian slip! Does this mean you plan to, er, put it where the sun don't shine? :-) John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAIN
In article <[EMAIL PROTECTED]>, Warner Losh <[EMAIL PROTECTED]> wrote: > > What's the current wuildworld times for a 486DX2-66 + 12M RAM over > NFS? Dunno yet. I started one in late 1997 but it's still running. I'll let you know when it finishes. :-) John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
_KPOSIX_VERSION=199309L in GENERIC is redundant
In revision 1.230 of src/sys/i386/conf/GENERIC, jkh added: optionsP1003_1B#Posix P1003_1B real-time extentions options_KPOSIX_PRIORITY_SCHEDULING options_KPOSIX_VERSION=199309L But I think the definition of _KPOSIX_VERSION is redundant, because it is already the default in src/sys/sys/param.h: #ifdef P1003_1B #define _P1003_1B_VISIBLE #ifndef _KPOSIX_VERSION #define _KPOSIX_VERSION 199309L #endif #endif Am I right, or am I missing something? 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: make installworld broken???
> > It's source-dir is called "xinstall" btw. > Why is the source called "xinstall"? To avoid colliding with the standard make target "install". If we had utilities named "all", "depend", and "clean" we'd have to do the same thing for them. John PS - Please remove me from the cc on the inevitable 50-message thread about clever ways to avoid this simple fix, all requiring 100-line perl scripts no doubt. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup8.freebsd.org gone?
In article <[EMAIL PROTECTED]>, Kris Kennaway <[EMAIL PROTECTED]> wrote: > On Wed, 2 Feb 2000, Maxim Sobolev wrote: > > > What happed with much-advertised by Polstra cvsup8.freebsd.org cvsup mirror? > > He advertised shortly thereafter that it had died :-) Not "died." Taken out of service temporarily. It is coming back again Real Soon Now. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mail.freebsd.org's host id changed
In article <[EMAIL PROTECTED]>, Jim Bloom <[EMAIL PROTECTED]> wrote: > Will someone please put an MX record up for hub.freebsd.org so it's mail > gets rerouted. I have mail queued up for delivery to there. Why are you addressing mail to [EMAIL PROTECTED]? The correct address to use is [EMAIL PROTECTED] 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: mail.freebsd.org's host id changed
In article <[EMAIL PROTECTED]>, Jim Bloom <[EMAIL PROTECTED]> wrote: > John Polstra wrote: > > > > Why are you addressing mail to [EMAIL PROTECTED]? The correct > > address to use is [EMAIL PROTECTED] > > Because I replied to a message I received which had > [EMAIL PROTECTED] The message originated on hub and I guess the > sender's address was not rewritten. Consider yourself vindicated. :-) Outgoing mail _should_ be masqueraded as coming from "freebsd.org", but the whole mail system is slightly screwed up at the moment due to the loss of a disk on hub. Actually, hub does have an MX record, but it still points to hub instead of to the ersatz mailhost, builder.freebsd.org. Please drop a note to [EMAIL PROTECTED] and ask him to fix that. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libcrypto (DES - MD5)
In article <[EMAIL PROTECTED]>, Kris Kennaway <[EMAIL PROTECTED]> wrote: > On Thu, 3 Feb 2000, Anders Andersson wrote: > > > I add a new user, and with 'vipw' I notices that this user now gets a > > DES based passwd. (we only use MD5 passwords around). Then I looked in > > /usr/lib and noticed that libcrypt now is symlinked to libdescrypt: > > AFAIK this has always been the way it works: if you install libdescrypt, > the system makes the (mistaken) assumption you want DES passwords all the > time. I agree. It has been that way as long as I can remember (since around 2.0.5-RELEASE). John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GNATS reply?
In article <[EMAIL PROTECTED]>, Michael Lucas <[EMAIL PROTECTED]> wrote: > Hello, > > Shouldn't I get a response email from > [EMAIL PROTECTED]? Or is this a casualty of the mail > breakage? It is a casualty of the mailserver HW problem. > Would I be better of using the web form, or just waiting until after > Linuxworld? My advice is to wait. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Pre-3.3 to 4.0 w/ IPsec
In article <[EMAIL PROTECTED]>, Eugene M. Kim <[EMAIL PROTECTED]> wrote: > Just wanted to share the knowledge of this little devil. > > For those who want to upgrade via cvsup their pre-3.3 system to test > IPsec: due to the addition of src-sys-crypto in secure-supfile, one will > have to cvsup first, upgrade their /usr/share/examples directory (cd > /usr/src/share/examples ; make depend all install) and cvsup again > before they can compile a kernel with IPsec. That seems like a pretty hard way to do it. Why not just edit your supfile and add src-sys-crypto to it? John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/src/Makefile.inc1: make update
In article <[EMAIL PROTECTED]>, Patrick M. Hausen <[EMAIL PROTECTED]> wrote: > > Yes, but now we have three different ways to update: [...] > 2. call cvsup from /usr/local/etc/periodic with supfiles for whatever you >need ... Not a good idea. Add a new crontab entry instead. If everybody used /usr/local/etc/periodic to run their cvsups, then they would all hit the servers at the same times (from a given time zone). Not friendly, and not likely to yield satisfactory results either. Pick a "random" time instead. 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: gcc and /usr/lib/libstdc++.so.3
In article <[EMAIL PROTECTED]>, Maxim Sobolev <[EMAIL PROTECTED]> wrote: > Donn Miller wrote: > > > I am running the lastest -current (just did a cvsup followed by a make > > world last night). I am getting these link errors when trying to compile > > the developement version of kdesupport, which I obtained thru cvsup. (KDE > > uses cvsup for its development versions.) > > > > I get the following errors. I have also installed the latest development > > snapshot of gcc 2.96 into /usr/local/bin, and I don't get these errors. > > > > gmake[5]: Entering directory > > `/usr/home/dmmiller/compile/kde/kdesupport/odbc/uni > > xODBC/odbcinst/cmd' > > /bin/sh ../../../../libtool --silent --mode=link gcc -mpentium -O3 -pipe > > -s -o > > odbcinst odbcinst.o ../libodbcinst.la ../../lst/libuodbclst.la > > /usr/lib/libstdc++.so.3: undefined reference to `exception type_info > > function' > > [...] > > gmake[5]: *** [odbcinst] Error 1 > > Absolutely the same is here on just builded/installed -current. Interesting > that two days ago I had compiled kdesupport w/o this problem on the -current > system compiled on February 3. Therefore bug in question was introduced during > Feb 3 - Feb 8 period. Are you sure you're not just hitting this problem described in src/UPDATING? 2124: The default way that virtual tables in our default C++ compiler has changed. We used to use THUNKS for virtual inheritance. Unfortunately there are bugs that The GCC developers thought would be fixed in GCC 2.95. However it isn't. After this change existing applications written in C++ may give errors like below when you try to run them: /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol "__vt_7filebuf" The only fix is to rebuild the application and any C++ libraries used. 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: gcc and /usr/lib/libstdc++.so.3
In article <[EMAIL PROTECTED]>, Maxim Sobolev <[EMAIL PROTECTED]> wrote: > John Polstra wrote: > > > Are you sure you're not just hitting this problem described in > > src/UPDATING? > > > > 2124: > > The default way that virtual tables in our default C++ > > No, because since 2124 I've recompiled both world (several times > actually) and all C++ libs used by the kde. If you will read my > previous message thoughtfully, you will notice that after Jan 24 I > had successfully compiled kdesupport on system builded/installed on > Feb 3. Sheesh, chill out. I'm just trying to help you. I did read your message "thoughtfully." That's why I wrote, "Are you sure ...?" rather than, "Hey dumbo, read UPDATING!" I thought (and still think) you might possibly have missed rebuilding one of the libraries. 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: ulimit weirdness
In article <[EMAIL PROTECTED]>, Louis A. Mamakos <[EMAIL PROTECTED]> wrote: > > Is it just me, or did something change? > > It seems that now you can't raise resource limits after they've been > lowered. I've had a 'ulimit -c 0' in my login profile for a while; > previously when I needed to do debugging, I'd raise the limit to > something reasonable at the shell prompt, and then debug away. > > Now it seems to be the case that once the (e.g,) core limit has been > lowered, you can't raise it again. Am I just remembering this wrong? Yep, you're remembering wrong. You can raise the soft limit again, but not the hard limit. It's even documented in sh(1): ulimit [-HSacdflmnust] [limit] Set or display resource limits (see getrlimit(2)). If limit is specified, the named resource will be set; otherwise the current resource value will be displayed. If -H is specified, the hard limits will be set or displayed. While everybody is allowed to reduce a hard limit, only the supe- ruser can increase it. The -S option specifies the soft limits instead. When displaying limits, only one of -S or -H can be given. The default is to display the soft limits, and to set both the hard and the soft limits. If you want to lower the coredumpsize limit temporarily, use the soft limit like this: ulimit -Sc 5000 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: HEADS-UP, upcoming changes to ipfw: keep-state
In article <[EMAIL PROTECTED]>, Luigi Rizzo <[EMAIL PROTECTED]> wrote: > > This will let you write things like (taken from a live -current): > > rizzo# ipfw show > 00100 313 15907 allow tcp from any to any keep-state setup > 002000 0 deny tcp from any to any > 65535 1433 309926 allow ip from any to any > ## Dynamic rules: > 00100 279 13151 tcp 131.114.9.26 513 <-> 131.114.9.236 > > where the 'Dynamic rules' part is generated as a result of a match > of rule 100. Sounds cool, but could you please describe what it does? Apparently it adds a temporary pass rule between two endpoints, in response to a triggering rule that contains "keep-state". Is that right? I realize it's probably like ipfilter's keep-state feature. But that's not documented either. :-( 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: Streamlining FreeBSD installations across many machines
In article <[EMAIL PROTECTED]>, Rodney W. Grimes <[EMAIL PROTECTED]> wrote: > A much faster way to do this is to just dd the first few megabytes > of the disk (dd if=foo of=/dev/rXXd bs=32768 count=1024). Then use > dump | restore to populate the disk. Do you run newfs on the receiving disk before the dump|restore? It seems like if you didn't then the free block bitmaps in the cylinder groups would contain garbage. 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: openssh uses /etc (bad)
In article <[EMAIL PROTECTED]>, Bjoern Groenvall <[EMAIL PROTECTED]> wrote: > > While you are moving things around you might as well move > /usr/sbin/sshd to /usr/libexec/sshd where it should have > resided in the first place. No, that would be contrary to the conventions documented in hier(4). /usr/libexec is for things that are executed by other programs. Normal persistent daemons such as sshd belong in /usr/sbin. Take a look at the current contents of those two directories and you'll see the distinction. 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: /usr/ports/ too big?
In article <[EMAIL PROTECTED]>, Jeffrey J. Mountin <[EMAIL PROTECTED]> wrote: > > In the context of CVSup server connections it would not be. Have to > chuckle when I hear someone doing CVSup for ports-all. Unless they have a > reason, but as we know many will do man things blindly. In my experience, CVSup is not slow for the ports tree. CVS is slow, but not CVSup. I can typically update my entire CVS repository (CVSROOT + distrib + doc + ports + src + www) in 1.5-2 minutes on a 56 Kbit link. Of course the "cvs upd" afterwards does take a long time. 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: /usr/ports/ too big?
In article <[EMAIL PROTECTED]>, Leif Neland <[EMAIL PROTECTED]> wrote: > Just FYI, a cvsup of ports over a single ISDN-line took 22 min on a > soft-update'd disk. Something is seriously wrong over there then, because I can update my entire CVS repository in 1.5-2 minutes. And my Internet link is a wimpy 56 Kbit frame relay connection 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: "Interesting" failure mode for static linking with shared libs.
In article <[EMAIL PROTECTED]>,
Jordan K. Hubbard <[EMAIL PROTECTED]> wrote:
>
> I ran across this as part of my continuing efforts to make the openssl
> library pull in the rsaref code at runtime, something which now works
> just peachy in the dynamic linking case but does not work in the
> static linking case. That is to say that if I want to link ssh
> static, for whatever reason, and I compile it up in the following ways
> (the names used for the libs aren't exactly correct, I'm just
> illustrating a point):
>
> 1. cc -static ${SSHOBJS} -o ssh -lrsaref -lrsaglue -lssl
>
> 2. cc -static ${SSHOBJS} -o ssh -lrsaglue -lssl
>
> Then in case #2 the expected happens, e.g. ssh bitches about needing
> the rsa code and aborts since dlopen() is not available to the rsaglue
> stub functions I wrote and I'd consider that correct.
>
> However, case #1 also causes the very same behavior, and that just
> mystifies me since I'd have expected the "strong" symbols in librsaref
> to have been bound to in preference to the weak ones in librsaglue.
> I've also tried referencing the .a file directly in the link line
> (cc -static ${SSHOBJS} -o ssh /usr/local/lib/librsaref.a -lrsaglue -lssl)
> in hopes that this would somehow get it preferred just on that
> basis alone, but no deal. Urk! Any ideas?
A simple test case that I built does the right thing. I'll look
into your specific example and figure out why it's not working.
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: More "ld-elf.so.1: assert failed" messages
In article <[EMAIL PROTECTED]>, Donn Miller <[EMAIL PROTECTED]> wrote: > This time it happens with a recent cvs version of wine (about 1 week > old). > > $ wine -desktop 780x560 ./iew31.exe > Could not stat /mnt/fd0, ignoring drive A: > ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:54 > wine: can't exec './iew31.exe': invalid exe file > Terminated > > My version of -current is from Feb 24. Hmmm... maybe there's still > some problems there? Wine is the only app I've seen that still does > this. Crud. :-( When the assert fails it should generate a core dump if the permissions of the working directory allow it. If you can get a core dump and use gdb to get a stack trace, that would help me a lot. Otherwise it's almost impossible for me to diagnose this. If you can tell me precisely how to duplicate the problem then I'll try. Assume I know nothing about wine. Thanks, 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: More "ld-elf.so.1: assert failed" messages
In article <[EMAIL PROTECTED]>, Donn Miller <[EMAIL PROTECTED]> wrote: > Here's the backtrace from gdb: > > (gdb) backtrace > #0 0x2805ce30 in kill () from /usr/libexec/ld-elf.so.1 > #1 0x2805ca0d in abort () from /usr/libexec/ld-elf.so.1 > #2 0x28053c6e in lockdflt_acquire () from /usr/libexec/ld-elf.so.1 > #3 0x28053bc0 in _rtld_bind () from /usr/libexec/ld-elf.so.1 > #4 0x28051205 in _rtld_bind_start () from /usr/libexec/ld-elf.so.1 > #5 0x284ad3fc in SYSDEPS_StartThread () from > /usr/local/lib/libwine.so > #6 0x0 in ?? () Thanks! I grabbed the 2227 snapshot of wine and looked at its sources too, and I know what's going on now. It's the dreaded rfork threads. :-( I'm going to think about this a little bit. It may well be hard to fix it in time to make Jordan feel good about letting it into 4.0. > Note: I didn't compile wine with -g. I'll do that if you want... Thanks, but it's not necessary at this point. 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
pthread_{suspend,resume}_np broken?
Either pthread_suspend_np() and pthread_resume_np() are broken in
-current or I don't understand them. The attached program (cc
-pthread suspend.c) starts two background threads. Each thread loops
outputting a character ('1' or '2' according to which thread it is)
and then sleeping for a second. Meanwhile, the main thread reads
keypresses from the standard input. On each keypress it toggles
background thread 1 between suspended and resumed.
If it worked properly I would expect the output to resemble this:
12121-S-22-R-121212-S-222-R-212121212 and so on.
Instead I get this:
121-S-212-R-12121-S-212121-R-12121-S-212121
I.e., the thread doesn't get suspended. Am I misunderstanding what
these functions are supposed to do?
Also, the code in "src/lib/libc_r/uthread/uthread_resume_np.c" looks
wrong:
int
pthread_resume_np(pthread_t thread)
{
int ret;
/* Find the thread in the list of active threads: */
if ((ret = _find_thread(thread)) == 0) {
/* The thread exists. Is it suspended? */
if (thread->state != PS_SUSPENDED) {
/*
* Defer signals to protect the scheduling queues
* from access by the signal handler:
*/
_thread_kern_sig_defer();
/* Allow the thread to run. */
PTHREAD_NEW_STATE(thread,PS_RUNNING);
/*
* Undefer and handle pending signals, yielding if
* necessary:
*/
_thread_kern_sig_undefer();
}
}
return(ret);
}
Shouldn't the test against PS_SUSPENDED be "==" instead of "!="? I
would think we'd want to do something if the thread was suspended, and
skip it if the thread wasn't suspended -- exactly the opposite of what
the current code does.
John
---
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
#include
#include
#include
#include
#include
#include
#include
#define SLEEP 100 /* 1 second */
pthread_t bg1;
pthread_t bg2;
static void *
bgfunc(void *arg)
{
char ch = *(char *)arg;
for ( ; ; ) {
putchar(ch);
usleep(SLEEP);
}
}
int
main(int argc, char **argv)
{
struct termios t;
int ret;
/* Set up stdin and stdout to deliver characters immediately. */
setbuf(stdout, NULL);
tcgetattr(fileno(stdin), &t);
t.c_lflag &= ~(ECHO | ICANON);
t.c_cc[VMIN] = 1;
t.c_cc[VTIME] = 0;
tcsetattr(fileno(stdin), TCSAFLUSH, &t);
/* Start two background threads. */
pthread_create(&bg1, NULL, bgfunc, "1");
usleep(SLEEP / 2);
pthread_create(&bg2, NULL, bgfunc, "2");
/*
* On each keystroke, toggle background thread 1 between suspended
* and running.
*/
for ( ; ; ) {
getchar();
fputs("-S-", stdout);
if ((ret = pthread_suspend_np(bg1)) != 0)
errc(1, ret, "pthread_suspend_np failed");
getchar();
fputs("-R-", stdout);
if ((ret = pthread_resume_np(bg1)) != 0)
errc(1, ret, "pthread_resume_np failed");
}
return 0;
}
Re: pthread_{suspend,resume}_np broken?
In article <[EMAIL PROTECTED]>, Daniel Eischen <[EMAIL PROTECTED]> wrote: > On Tue, 29 Feb 2000, John Polstra wrote: > > > Shouldn't the test against PS_SUSPENDED be "==" instead of "!="? > > Yes, it should be "==" instead of "!=". > > Go ahead and fix it if you want :-) Thanks. I'll ask Jordan if I may commit the fix. What about the other part of my question? I still don't understand why in my test program pthread_suspend_np() isn't suspending the thread. I think it's a separate bug from the pthread_resume_np() bug. 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: Shared memory - Was: 2 Queries
In article <[EMAIL PROTECTED]>, Christopher Masto <[EMAIL PROTECTED]> wrote: > On Wed, Mar 01, 2000 at 06:20:28PM +0100, Anton Berezin wrote: > > I would say that the programs you've mentioned are badly written then. > > > > It takes no more than > > > > XSync(disp,False); > > shmctl( shmid, IPC_RMID, 0); > > It takes no more than a well-designed operating system service to > ensure that badly written programs don't fail to release resources > when they crash. We didn't design that particular service. That's why it's called System V shared memory. Also, it's persistent for legitimate design reasons, just like files are. Applications need to clean up after themselves. The OS has no way of knowing whether an application wants its shared memory segments to survive after it terminates. 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: ssh strangeness in -current...
In article <[EMAIL PROTECTED]>, Kris Kennaway <[EMAIL PROTECTED]> wrote: > > Ahh, so you can use the OpenSSH client to connect to some servers, but not > the F-Secure one? That would definitely be a bug you should report to the > OpenSSH developers. > > Is anyone else in the position to test this? In the past I have had interoperability problems between F-Secure and the open source versions of ssh. But the cause then was simply that the F-Secure keys were too long (> 1024 bits) for ssh's rsaref to cope with. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More "ld-elf.so.1: assert failed" messages
In article <[EMAIL PROTECTED]>, Donn Miller <[EMAIL PROTECTED]> wrote: > John Polstra wrote: > > > > Below is a patch for "src/libexec/rtld-elf" which should fix the > > assert failures in wine. I'd appreciate hearing from anybody who > > tests this with multithreaded packages such as wine, JDK, Mozilla, > > and linuxthreads. > > [snipped patch] > > OK, here's some of the errors I get with Mozilla. It looks like it > happens when Gdk runs out os SysV shared memory. Otherwise, if I > don't get the "Gdk-WARNING **: shmget failed!", the ld.so erros never > occur, and Mozilla runs OK. It seems as if Wine is working OK so far, > though, although I probably haven't tested Wine enough: [...] > /usr/libexec/ld-elf.so.1: Application locking error: 1 readers and 1 > writers in dynamic linker. See DLLOCKINIT(3) in manual pages. This means that one thread was in the middle of a dlopen() call when another thread either called a new function for the first time (invoking the dynamic linker for lazy binding) or called dlsym(). Really the only _right_ place I can find to fix this kind of thing is in the application itself, by calling dllockinit() to set up locking for the dynamic linker invocations. I keep trying to come up with solutions that will work without that, but I'm not at all sure it's possible. I'll take another look at Mozilla and see what's done for other platforms. They must have this same problem, at least potentially. Thanks very much for testing this! John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More "ld-elf.so.1: assert failed" messages
In article <[EMAIL PROTECTED]>, Donn Miller <[EMAIL PROTECTED]> wrote: > I just reverted back to the "normal" version of ld-elf.so, the version > without the patch. Mozilla doesn't have the problem with the > "non-patch" version. So, maybe it isn't the application. Or, maybe the > original, "non-patch" version wasn't doing something right. > > Just wondering, in case the problem isn't with Mozilla. I'm using > Mozilla right now, with the original ld-elf.so.1. (The fonts are hard > on my eyes.) Well, the whole situation is very complicated. I'll append a long-winded mail about it that I sent to Jordan and Peter. (No answer yet, but then Jordan was out of the country and Peter only answers 20% of his mail as a rather crude form of flow control. ;-) Briefly, we've been through 3 phases with the dynamic linker. 1. The olden days. Resolving symbols was a read-only operation, so it was re-entrant. Dlopen was a "write" operation, so if any thread was doing a dlopen then no other thread could be doing a dlopen or a symbol lookup. There weren't very many multi-threaded apps, and there were even fewer that used dlopen. So nobody saw any problems, even though the potential was there. 2. What is in current today. Resolving symbols is a "write" operation, and so is dlopen. So two threads trying to resolve symbols simultaneously need mutual exclusion or problems can manifest themselves. (Resolving symbols being a "write" operation is basically an implementation screw-up on my part, which is corrected in the patch I posted.) Meanwhile, there are a lot more multi-threaded applications. So we're seeing problems. In an attempt to solve the problems, I did two things: (a) provided the dllockinit(3) interface so threads packages could tell the dynamic linker how to do locking, and (b) implemented some default locking that would work in some cases when threads packages didn't use dllockinit. The default locking works for userland threads packages, but not for kernel threads or rfork threads. 3. The patch I posted. It made symbol resolution read-only again, but it also removed the default locking. I was hoping that with re-entrant symbol resolution, the default locking wouldn't be needed any more. The default locking is extremely bogus, because it makes assumptions about how threads work which there's no real reason to believe are correct. John [Here's the mail I sent that explains things in more detail.] Sorry for this long mail, but I need your advice about a situation that's kind of complicated. I don't know whether you've been following -current, but there's a new chapter in the continuing saga of "The Dynamic Linker Breaks Some Random Multi-threaded Program During a Code Freeze." This time it's wine. These breakages are all connected, and I'll try to explain the whole story below, if only so you won't think I just do shoddy work. :-) What I am looking for from you is some guidance as to how much we want to mess with the rtld at the 11th hour to fix wine. There are two ways a program can enter the dynamic linker: either (A) by innocently calling some external function for the first time, causing lazy binding to be done for that function, or (B) by deliberately calling dlopen() or one of its friends. In long ago olden times, A was effectively a read-only operation, while B mucked with a bunch of data structures in the dynamic linker. So a program could safely have lots of threads doing A at the same time, or just one thread doing B, but not both. Then the need for better-scoped symbol lookups began to arise, and I finally bit the bullet and made the lookup algorithm quite a bit more complicated, a la Solaris and Linux. This was the change we decided to merge into 3.4 just before release, because it fixed some important application -- which one I can't remember any more. The changes I put in to do this unfortunately changed operation "A" above into a write operation too. I.e., the lazy binding was no longer reentrant. Soon I started receiving reports of strange failures in multi-threaded programs. I attacked this problem by introducing calls to reader/writer locking functions in key places. Since locking depends on the underlying threads package, I also created the dllockinit() API through which each threads package could tell the dynamic linker how to do locking. At the same time I added default locking methods which would make their best effort to lock (basically by masking a bunch of signals) in case the threads package hadn't been modified to call dllockinit(). That's where things stand in -current today. Unfortunately, wine uses rfork() to make threads, so each thread is in its own process. Consequently, the signal masking in the default locking methods is ineffective. Occasionally the dynamic linker gets reentered and an assert fails. I have changes in my local tree which fix the lookup algorithm so it is reentrant again. I didn't think it was possible before, but t
Re: pthread_{suspend,resume}_np broken?
In article <[EMAIL PROTECTED]>, Daniel M. Eischen <[EMAIL PROTECTED]> wrote: > Here's a quick fix. Thanks! It seems to fix my test program. I'll leave it up to you and Jordan whether to commit this before 4.0. It would be nice to have, but I don't have any immediate need for it. 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: More "ld-elf.so.1: assert failed" messages
Below is a patch for "src/libexec/rtld-elf" which should fix the
assert failures in wine. I'd appreciate hearing from anybody who
tests this with multithreaded packages such as wine, JDK, Mozilla,
and linuxthreads.
Just a reminder -- be extra careful when messing with the dynamic
linker. It's easy to paint yourself into a corner if it's broken
badly. Make a backup copy of your current working dynamic linker
(/usr/libexec/ld-elf.so.1) before installing the experimental version.
Then if things fall apart you can recover with something like this:
cd /usr/libexec
chflags 0 ld-elf.so.1*
mv ld-elf.so.1.good ld-elf.so.1
Thanks in advance for any testing you folks can make time to do.
John
Index: Makefile
===
RCS file: /home/ncvs/src/libexec/rtld-elf/Makefile,v
retrieving revision 1.10
diff -u -r1.10 Makefile
--- Makefile2000/01/29 03:16:54 1.10
+++ Makefile2000/03/01 02:39:13
@@ -3,7 +3,7 @@
#
MAINTAINER=jdp
PROG= ld-elf.so.1
-SRCS= rtld_start.S rtld.c lockdflt.c map_object.c malloc.c \
+SRCS= rtld_start.S rtld.c map_object.c malloc.c \
xmalloc.c debug.c reloc.c
MAN1= rtld.1
CFLAGS+= -Wall -DFREEBSD_ELF -I${.CURDIR}/${MACHINE_ARCH} -I${.CURDIR}
Index: lockdflt.c
===
RCS file: lockdflt.c
diff -N lockdflt.c
--- /tmp/cvscXuMc22613 Sun Mar 5 17:48:37 2000
+++ /dev/null Sun Mar 5 02:02:18 2000
@@ -1,89 +0,0 @@
-/*-
- * Copyright 1999, 2000 John D. Polstra.
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
- * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * $FreeBSD: src/libexec/rtld-elf/lockdflt.c,v 1.4 2000/01/25 01:32:56 jdp Exp $
- */
-
-/*
- * Default thread locking implementation for the dynamic linker. It
- * is used until the client registers a different implementation with
- * dllockinit(). The default implementation does mutual exclusion by
- * blocking almost all signals. This is based on the observation that
- * most userland thread packages use signals to support preemption.
- */
-
-#include
-#include
-#include
-
-#include "debug.h"
-#include "rtld.h"
-
-typedef struct Struct_LockDflt {
-sigset_t lock_mask;
-sigset_t old_mask;
-int depth;
-} LockDflt;
-
-void
-lockdflt_acquire(void *lock)
-{
-LockDflt *l = (LockDflt *)lock;
-sigprocmask(SIG_BLOCK, &l->lock_mask, &l->old_mask);
-assert(l->depth == 0);
-l->depth++;
-}
-
-void *
-lockdflt_create(void *context)
-{
-LockDflt *l;
-
-l = NEW(LockDflt);
-l->depth = 0;
-sigfillset(&l->lock_mask);
-sigdelset(&l->lock_mask, SIGTRAP);
-sigdelset(&l->lock_mask, SIGABRT);
-sigdelset(&l->lock_mask, SIGBUS);
-sigdelset(&l->lock_mask, SIGSEGV);
-sigdelset(&l->lock_mask, SIGKILL);
-sigdelset(&l->lock_mask, SIGSTOP);
-return l;
-}
-
-void
-lockdflt_destroy(void *lock)
-{
-LockDflt *l = (LockDflt *)lock;
-free(l);
-}
-
-void
-lockdflt_release(void *lock)
-{
-LockDflt *l = (LockDflt *)lock;
-assert(l->depth == 1);
-l->depth--;
-sigprocmask(SIG_SETMASK, &l->old_mask, NULL);
-}
Index: rtld.c
===
RCS file: /home/ncvs/src/libexec/rtld-elf/rtld.c,v
retrieving revision 1.43
diff -u -r1.43 rtld.c
--- rtld.c 2000/01/29 01:26:59 1.43
+++ rtld.c 2000/03/06 01:44:11
@@ -61,6 +61,9 @@
typedef struct Struct_LockInfo {
void *context; /* Client context for creating locks */
void *thelock; /* The one big lock */
+/* Debugging aids. */
+volatile int rcount; /* Number of readers holding lock */
+volatile int wcount; /* Number of writers holding lock */
Re: More "ld-elf.so.1: assert failed" messages
In article <[EMAIL PROTECTED]>, Jordan K. Hubbard <[EMAIL PROTECTED]> wrote: > > The other possibility would be to fix the wine port so it calls > > dllockinit() to set up locking. I don't know for sure how hard that > > would be, but it's probably a feasible solution. > > To be honest, I'd be the most comfortable with this solution Me too, for 4.0. Given Donn's reports of trouble with my patches, I think the timing is just wrong to try and do anything major with the dynamic linker between now and Monday. It's too hard to test it. All the troublesome ports are _huge_ (Mozilla, Wine, ...), and the failures are timing-dependent and not so easy to reproduce. Obviously I'll strive to fix the remaining problems after 4.0 has been tagged. As far as I know, Wine is the only port that has problems with the version of the dynamic linker that's in -current at present. I've looked into adding the dllockinit() stuff to Wine, but could use some help from somebody who knows its internals better. I found the threads primitives, etc., but am not so sure where to place the dllockinit() call. 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: MAX_UID ?
In article <[EMAIL PROTECTED]>, Paul Richards <[EMAIL PROTECTED]> wrote: > > > > They must not go into . That header file is defined by > > the ANSI/ISO C standard. The standard doesn't permit polluting the > > namespace with extra stuff. > > Umm, ok. I don't think our limits.h actually has anything in it that > meets the ANSI/ISO standard, every line is ifdef'd :-) Where would be a > better place for constants like this? Sheesh, criticism isn't enough? Now it has to be constructive too? ;-) I guess it could go into in the "!defined(_ANSI_SOURCE)" section. Bruce might have a better idea. 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: MAX_UID ?
In article <[EMAIL PROTECTED]>, Giorgos Keramidas <[EMAIL PROTECTED]> wrote: > On Sun, Mar 12, 2000 at 05:59:09AM +, Paul Richards wrote: > > > > Are expressions like ((uid_t)0-1) portable/safe ? Maybe that's a better > > way of approaching this. > > To get the all-1's number, maybe it's better to use ((uid_t)~0), but > that is a rather controversial topic anyway. That works, but on machines like the Alpha where longs are bigger than ints it only works by virtue of sign extension. Our existing headers seem to prefer ((uid_t)0-1). That's what is used in the i386's . 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: MAX_UID ?
In article <[EMAIL PROTECTED]>, Paul Richards <[EMAIL PROTECTED]> wrote: > John Polstra wrote: > > > > I guess it could go into in the > > "!defined(_ANSI_SOURCE)" section. Bruce might have a better idea. > > I don't think is the right place. These are constants > that are definately not architecture dependent. The whole problem at the > moment is that the code is abusing architecture dependent constants in > lieu of anything better. Hmm, you're right. How about ? 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: More "ld-elf.so.1: assert failed" messages
In article <[EMAIL PROTECTED]>, Jim Bloom <[EMAIL PROTECTED]> wrote: [when dllockinit() should be called] > It should be called somewhere between the starting of the process > and the creation of the second thread. There is no problem if there > is only one thread. > > THREAD Create would be fine as long as it sets a variable accessible > to all threads indicating dllockinit has been called. > > Another possible location would be a routine that initialize the > multithreading for the process. This routine may not exist in all > thread packages though. That is all correct. Dllockinit has to be called once only, before any threads have been forked but late enough so that it's safe to call the thread sychronization primitives. Ideally, a reader/writer lock should be used. But it will also work to use a simple mutex. In that case, rlock_acquire and wlock_aquire will be the same (lock the mutex). I'd recommend using a simple mutex unless the threads package already implements reader/writer locks. I really hope I can render all this nonsense unnecessary after the code freeze ends. 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: Make world error.....
In article <[EMAIL PROTECTED]>, Kris Kennaway <[EMAIL PROTECTED]> wrote: > On Sun, 5 Mar 2000, Brian Dean wrote: > > > The perl script h2ph does not exit immediately on des.h, it sets it's > > $Exit value to 1, but continues processing. If the original poster > > would check further back in his log file, he'll see: > > Ah, okay. There might be an ordering problem with the des.h symlink being > created before the openssl/des.h file which it points to. Any ideas, > Mark? This is still broken. I ran into it when upgrading a Feb. 29 -current system to today's -current. I didn't use make -j and I didn't take any shortcuts. 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: Make world error.....
In article <[EMAIL PROTECTED]>, Kris Kennaway <[EMAIL PROTECTED]> wrote: > On Fri, 10 Mar 2000, John Polstra wrote: > > > This is still broken. I ran into it when upgrading a Feb. 29 -current > > system to today's -current. I didn't use make -j and I didn't take > > any shortcuts. > > Both were compiled with the same options (i.e. you didn't do the first one > NO_OPENSSL or something)? Correct. On this machine I've always done it the same way: make buildworld make installworld I don't believe I've ever used any special options, and my make.conf file is "normal" except that it has "USA_RESIDENT=YES" in it. > I'll try and replicate this once I verify my current buildworld > changes. Thanks. 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: MAX_UID ?
In article <[EMAIL PROTECTED]>, Paul Richards <[EMAIL PROTECTED]> wrote: > > I think we need a MAX_UID and a MAX_GID to perform checks like this. > Anyone got any objections to adding them to /usr/include/limits.h ? They must not go into . That header file is defined by the ANSI/ISO C standard. The standard doesn't permit polluting the namespace with extra stuff. 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: MAX_UID ?
In article <[EMAIL PROTECTED]>, Giorgos Keramidas <[EMAIL PROTECTED]> wrote: > On Sun, Mar 12, 2000 at 05:51:17PM -0800, John Polstra wrote: > > In article <[EMAIL PROTECTED]>, > > Giorgos Keramidas <[EMAIL PROTECTED]> wrote: > > > On Sun, Mar 12, 2000 at 05:59:09AM +, Paul Richards wrote: > > > > > > > > Are expressions like ((uid_t)0-1) portable/safe ? Maybe that's a better > > > > way of approaching this. > > > > > > To get the all-1's number, maybe it's better to use ((uid_t)~0), but > > > that is a rather controversial topic anyway. > > > > That works, but on machines like the Alpha where longs are bigger > > than ints it only works by virtue of sign extension. Our existing > > headers seem to prefer ((uid_t)0-1). That's what is used in the > > i386's . > > My bummer, I thought the definition was the same in /sys/sys/types.h and > in /usr/include/sys/types.h -- and there I could see: > > % cd /sys ; grep uid sys/* | grep type > sys/conf.h:typedef void devfs_create_t __P((dev_t dev, uid_t uid... > sys/types.h:typedef u_int32_t uid_t; /* user id */ > % cd /usr/include ; grep uid sys/* | grep type > sys/conf.h:typedef void devfs_create_t __P((dev_t dev, uid_t uid... > sys/types.h:typedef u_int32_t uid_t; /* user id */ > > and I mistakenly assumed that both x86 and alpha's use uid_t's of 32 > bits. What did I miss? Sorry, I wasn't clear. I was talking about the general case, not about uid_t in particular. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAX_UID ?
In article <[EMAIL PROTECTED]>, Bruce Evans <[EMAIL PROTECTED]> wrote: > > I would prefer standard maxof() and minof() interfaces that work on > any arithmetic type. These can almost be written in portable C, at > least in C89 where types are restricted to char, signed char, ..., > long double: > > #define isfloat(type) ((type)0.5 != 0) > #define issigned(type)((type)-1 < 0) > #define isschar(type) (!isfloat(type) && issigned(type) && sizeof(type) == 1) > #define isuchar(type) (!isfloat(type) && !issigned(type) && sizeof(type) == 1) > ... > #define maxof(type) ((type)(isschar(type) ? SCHAR_MAX : > isuchar(type) ? UCHAR_MAX ...)) I like this idea. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LD_LIBRARY_PATH not working?
In article <[EMAIL PROTECTED]>, Patrick Hartling <[EMAIL PROTECTED]> wrote: > Today I have been having problems with applications being unable to find > shared libraries at run time with LD_LIBRARY_PATH set correctly. If the > library is moved into a directory set at boot time with ldconfig (via rc), > it works fine. I have tried it with several different libraries (both C and > C++ used by both C and C++ apps), and the results are always the same. This > is on a -current system built with sources cvsup'd at approximately 09:10 > (CST) March 11, 2000. Did I overlook some configuration change? Thanks. Nothing has changed in connection with LD_LIBRARY_PATH recently. In fact, it has been at least a few weeks since the dynamic linker changed at all. Remember, LD_LIBRARY_PATH is ignored for setuid/setgid programs. 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: libalias or libnat. Vote ?
In article <3843.935363694@localhost>, Jordan K. Hubbard <[EMAIL PROTECTED]> wrote: > > I've been on both sides of this issue, to be sure, but I have to say > that looking at it now, I can't see any reason to change the actual > name of the library right now unless we're also going to go whole-hog > and change the API functions to PacketNATFoo() and such, something > that would only really make sense (or be worth the effort, anyway) if > we had a bunch of improvements to bring in at the same time, e.g. a > significant rearchitecting effort. > > If we don't have anything like that planned, then simply changing the > user visible flags and man pages to strongly encourage use of -nat > style options rather than the deprecated -alias ones will probably > be enough of a step in the right direction for now. I agree. Users don't know or care about the name of the library. Programmers are used to dealing with quirks like having NAT implemented in a library named libalias. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages & vm_fault)
In article <[EMAIL PROTECTED]>, John W. DeBoskey <[EMAIL PROTECTED]> wrote: > >I need to figure out why my 11:30am EST cvsup didn't pick > this file up. It's 44 minutes infront of cvsup... Most mirror sites update themselves hourly from cvsup-master, which updates itself every 6 minutes from freefall. If the file still isn't there after 1 hour 6 minutes, then please send me the details. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: $FreeBSD tag confusion
In article <[EMAIL PROTECTED]>, Kevin Street <[EMAIL PROTECTED]> wrote: > I'm confused by what I'm seeing in my source tree after the > Id->FreeBSD tag change. I cvsup the repository and then update my > source tree locally. Most of the files in the tree now have an > unexpanded $FreeBSD$ tag in them (ie. no version info). Files which > have been changed since the new tag went in get an expanded $FreeBSD: > tag, but the version in the tag is not the same version as the checked > out file should be. The contents of the file seem to really be the > latest version though, other than the tag. > > For example in /usr/src/sys/miscfs/umapfs "cvs status umap.h" gives: > === > File: umap.hStatus: Up-to-date > > Working revision:1.11Sun Aug 29 19:31:44 1999 > Repository revision: 1.11... > > but in the file I see: > * $FreeBSD: src/sys/miscfs/umapfs/umap.h,v 1.10 1999/08/28 00:47:00 peter Exp $ > > so the $FreeBSD tag in the file is one version behind the version of > the currently checked out file. Deleting and doing "cvs up umap.h" > leaves me in the same state. > > Any explanations as to what's going on? The tags are expanding just fine up here in Seattle. :-) I wish you would have included the rest of the output from your cvs status command. It sounds a lot like your source tree was checked out with "-ko". That would show up in the "Sticky Tag" line of your cvs status output. Do another cvs update, but this time add the "-A" flag: cvs update -A umap.h If that fixes it, then you'd better do the same thing to the rest of your source tree: cd /usr/src cvs update -APd John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: $FreeBSD tag confusion
Kevin Street wrote: >>Are you getting a copy of CVSROOT? > > yes...as part of src-all, but it's not used as *my* CVSROOT. Aha. > Let's go back to the beginning here. Is my cvs responsible for > expanding the $FreeBSD$ tags, or are they supposed to arrive in my cvs > repository already expanded? Expansion of RCS keywords occurs on check_out_, not on checkin. In other words, your cvs is responsible for expanding them. > If my cvs needs to do it, then I presume > I need to add some options to my CVSROOT to make that happen. If so, > is there a description somewhere of what I need to steal out of > FreeBSD's CVSROOT that will make it happen? Grab the "options" file from there. John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPPD+PAM
In article <[EMAIL PROTECTED]>, Andrea Franceschini <[EMAIL PROTECTED]> wrote: > > I'm trying to use pppd coupled with PAM. > I'm using pppd 2.3.9 compiled with USE_PAM options ,and ,as far as i can see ,the > pppd side seem to work fine,but when i try to use the PAM side i got this: > > - > Aug 29 18:22:06 volcano pppd[1643]: rcvd [PAP AuthReq id=0x1 user="*" passwo > rd="*"] > Aug 29 18:22:06 volcano pppd[1643]: unable to resolve symbol: pam_sm_open_session Sorry, our pam_unix module doesn't support the "session" feature currently. Hey markm, ya wanna add this to your to-do list? :-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl still broken in 4.0-CURRENT
In article <[EMAIL PROTECTED]>, Dmitrij Tejblum <[EMAIL PROTECTED]> wrote: > Pascal Hofstee wrote: > > Perl seems to be broken for about 3 consecutive days now > > Anybody have any idea what might be causing this ? > > I suspect it is the recent changes in rtld. Hmm, could be. Can one of you please give it a try with the older ld-elf.so.1 and see if it works again? I recommend trying the dynamic linker from August 25. If it works with the older dynamic linker, please send me (preferably simple :-) instructions for reproducing the problem. Thanks, John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl still broken in 4.0-CURRENT
Pascal Hofstee wrote: > On Fri, 3 Sep 1999, John Polstra wrote: > >> Hmm, could be. Can one of you please give it a try with the older >> ld-elf.so.1 and see if it works again? I recommend trying the >> dynamic linker from August 25. >> >> If it works with the older dynamic linker, please send me (preferably >> simple :-) instructions for reproducing the problem. > > Well ... I personally use CVSup to do my source-tree updating. If you > could provide me with instructions on how to revert the current rtld-elf > code to an older revision .. i sure would like to try out. Thanks! Here are the instructions. Make a copy of your supfile. Let's call it "supfile.rtld". Now edit that file and add this line at the beginning: *default date=99.08.25.00.00.00 Run cvsup as usual, except for two changes: 1. Specify "supfile.rtld" instead of your usual supfile. 2. Add "-i src/libexec/rtld-elf" to the command line. That should back out the recent changes to ld-elf.so.1 quickly, without affecting anything else. Next, build and install the dynamic linker: 1. Make a backup copy of "/usr/libexec/rtld-elf.so.1". 2. Run these commands: cd /usr/src/libexec/rtld-elf make cleandir; make cleandir make obj make depend make all make install And try it out. Your next regular cvsup run will undo the changes. > As for the easiest way to reproduce just try to run the > mirror-script it's bound to just Die with a SIGSEGV in DynaLoader.pm I was hoping for something simpler that wouldn't require me to figure out how to configure mirror-script. :-( John --- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl still broken in 4.0-CURRENT
Oops, I said: > 1. Make a backup copy of "/usr/libexec/rtld-elf.so.1". but I meant "/usr/libexec/ld-elf.so.1". John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
