Re: errno (46) - for FreeBSD 4.0 NFS server
On Wed, Mar 22, 2000 at 12:04:55PM +0300, Grigory Kljuchnikov wrote: > Thierry, thank you for the information, > but it's very bad that there isn't NFS locking in FreeBSD. > I'm afraid I need to move my FreeBSD NFS server to Solaris > for x86. > > I don't understand why NFS locking isn't in FreeBSD. > Is it difficult in the implementation or are there another > global problems in the kernel (or in the native filesystem)? > > Who know when the NFS locking is planed to release in FreeBSD? > > Actually I think that server side locking *is* implemented but client side locking isn't. 'man 8 rpc.lockd' for more information. (And 'man 5 rc.conf' for information on how to start it at bootup. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: errno (46) - for FreeBSD 4.0 NFS server
On Wed, Mar 22, 2000 at 03:46:12PM +0300, Grigory Kljuchnikov wrote: > Thank you, Erik! > > I find rpc.lockd and start it manually. My test with NFS locking works right. > But it don't start on boot by default if I enable NFS server in > /stand/sysinstall and there is the comment in /etc/default/rc.conf > for rpc_lockd_enable: > > rpc_lockd_enable="NO" # Run NFS rpc.lockd (*broken!*) if nfs_server. > > Does the comment "(*broken!*)" mean that rpc.lockd doesn't work properly? > To be honest I don't know. I haven't used it myself but only read the manpages. (Since I only use NFS between FreeBSD boxes and they don't support client-side locking it seems pointless to have it on the server.) That comment does seem to imply that something is broken but then the manpage really should say something about that. (This might of course indicate that the manpage isn't in sync with reality.) Somebody who knows what is up with rpc.lockd is welcome to comment. > > On Wed, 22 Mar 2000, Erik Trulsson wrote: > > > On Wed, Mar 22, 2000 at 12:04:55PM +0300, Grigory Kljuchnikov wrote: > > > Thierry, thank you for the information, > > > but it's very bad that there isn't NFS locking in FreeBSD. > > > I'm afraid I need to move my FreeBSD NFS server to Solaris > > > for x86. > > > > > > I don't understand why NFS locking isn't in FreeBSD. > > > Is it difficult in the implementation or are there another > > > global problems in the kernel (or in the native filesystem)? > > > > > > Who know when the NFS locking is planed to release in FreeBSD? > > > > > > > > > > > > Actually I think that server side locking *is* implemented but client side > > locking isn't. > > 'man 8 rpc.lockd' for more information. > > (And 'man 5 rc.conf' for information on how to start it at bootup. > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: *_enable="YES" behavior is bogus
On Fri, Feb 01, 2002 at 02:47:30AM -0330, Paul Fardy wrote: > These examples, _and_yours_, are examples that suggest that > /etc/rc.conf has a fundamental principle that > > foo_enable="YES/NO" > > is supreme. One can set up all the requisite parameters (e.g. you > can create sendmail.cf, named.conf, tune inetd.conf, compile psm > into the kernel or install any of various screen savers), yet one > can still set an appropriate variable > > foo_enable="NO" > > which will not enable the feature. It will not enable it, no. Nor will the feature be disabled if it for some reason already was enabled. > > >Not enabling something is *not* the same thing as disabling it. > > But I think that the intent in /etc/rc.conf is that enable="NO" > _is_ the same thing as disabling it. You might say "If that were Consider that the actual code in the various rc* start scripts is in most cases of the form: if foo_enable==yes do stuff else do nothing Some cases are instead if foo_enable==no do nothing else do stuff A cursory search found a total of one instance where foobar="NO" actually makes something happen, and it was not of the form foo_enable="NO" (The single exception I found is tcp_extensions="NO") For all other variables one can set in rc.conf foobar="NO" means "do nothing". Looking at the code the intent certainly seems to be foo_enable="NO" shouldn't do anything. > the intent, they'd have used ___." What word should we use > to indicate the absolute YES or NO that some of us believe > should be the simple correct interpretation? foo_enabled="YES/NO" perhaps?? I.e. describing the desired state of the feature instead of the desired action to be taken. There are of course several people who feel that the current behaviour is the intuitive and obviously correct interpretation and would prefer not to have it changed. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMD AGP Bug
On Thu, Jan 31, 2002 at 09:32:48PM +0100, Gérard Roudier wrote: > > > On Thu, 31 Jan 2002, Jason Evans wrote: > > > On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote: > > > > > > Linux can be fixed, but the useless writes of the existing Athlons from > > > the very fast cache to the relatively very slow memory cannot. And all > > > Athlon users may well pay this penalty under any OS... unless we want to > > > disable caching. :) > > > > Have you done benchmarks to show that the speculative writes are useless > > often enough to cause enough memory bus contention that overall performance > > is degraded, despite the speedups when the speculative writes are valid? > > I haven't done any benchmark of this sort, neither intend to do any since > I haven't time for that. But I wrote in my email that my 2 Athlon systems > worked fine and fast, just to indicate that for normal use I didn't see > any performance problem at all. > > > I > > suspect that AMD in fact performed such tests; otherwise they wouldn't have > > gone to the trouble of implementing speculative writes. > > The Athlon rewriting same value to cacheable memory under the knees of > programmers looks a severe issue to me if it is true. Not only AGP memory > can be affected. What about SMP, MMIO (if some cacheable mapping exists), > etc...? I am not familiar with the acronym MMIO is so I can't comment on that. In general though, having memoryspace used for memory-mapped I/O devices (including AGP) marked as cacheable is a bad idea unless you are very careful and know exactly what you are doing. For SMP it shouldn't be any problem. Multi-CPU systems normally run some cache-coherence protocol between themselves to make sure that things like this is not a problem. > > In my opinion, OSes having some cacheable mapping to AGP memory is not the > real problem. Just it has revealed the AMD issue. It might be argued that there should be some cache-coherence protocol between the CPU and the AGP device. Not knowing how AGP is specified I don't know if this interaction between the CPU and AGP is a bug or just working as specified. I suspect it is the latter though. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libedit replacement for libreadline
On Thu, Jul 19, 2001 at 02:01:31AM -0700, Kris Kennaway wrote: > On Thu, Jul 19, 2001 at 01:37:16AM -0700, Terry Lambert wrote: > > Kris Kennaway wrote: > > > a) libcrypt has been "reunified" for 7 months now; Peter did it last > > > December. > > > > Someone needs to tell my newly installed 4.3 system this. > > > > 4.3-RELEASE _did_ come out after that, right? > > > > I guess this wasn't MFC'ed? It seems to _still_ not have > > been MFC'ed in my 4.3-STABLE (pre-4.4) branch, so I'm > > guessing my example will remain true for 4.4-RELEASE and > > 4.5-RELEASE, as well, unless someone does something about > > it before then... > > Peter MFC'ed it a few weeks ago. A few days ago is more like it. (cvs log lib/libcrypto/Makefile gives the following:) revision 1.24.2.4 date: 2001/07/16 03:28:26; author: peter; state: Exp; lines: +11 -56 MFC: unify libscrypt/libdescrypt into libcrypt. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Results of BIND RFC
On Fri, Apr 02, 2010 at 03:14:54AM -0700, Jeremy Chadwick wrote: > > [1]: FreeBSD really needs to move away from the "base system" as a > concept, as I've ranted about in the past. Or if it cannot, the "base > system" needs to start using pkg_* (somehow) No, it does not need to do that. It might be a good idea (but I am far from convinced of it), but there most certainly is no *need* to move in that direction. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: malloc.conf (was Re: Performance problems with 5.0-RELEASE)
On Thu, Jan 23, 2003 at 02:14:46PM -0500, Rahul Siddharthan wrote: > Dan Nelson wrote: > > > # ls -l /etc/malloc.conf > > > lrwxr-xr-x 1 root wheel 4 Jan 23 11:52 /etc/malloc.conf -> HR< > > > > H and < should only make a difference if you are low on memory. > > Yes. > > > R is on > > by default in 5.0 anyway, due to A and J being on by default. > > That's not what the malloc(3) man page suggests -- R seems to have > nothing to do with A or J. Perhaps, however, the improvement I see > is due to turning off A and J (implicitly, ie by not specifying them)? Read again. J automatically sets R. Yes, not having J set should improve performance noticeably compared with having J set. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for info from SiS chipset owners
On Sat, Feb 01, 2003 at 12:02:05PM +0100, Soeren Schmidt wrote: > > I'm currently in the midst of an ATA chipset support mega rewrite/update, > and the last item on the list is SiS support. > > That where _you_ come into the picture, I need a pciconf -l from your > SiS based system! > > Just reply to this message with the output from pciconf -l and you > have helped me sort out the myriads of SiS chipsets out there. > > -Søren chip0@pci0:0:0: class=0x06 card=0x chip=0x55961039 rev=0x00 hdr=0x00 isab0@pci0:1:0: class=0x060100 card=0x chip=0x00081039 rev=0x01 hdr=0x00 atapci0@pci0:1:1: class=0x01018a card=0x chip=0x55131039 rev=0x09 hdr=0x00 atapci1@pci0:11:0: class=0x018085 card=0x4d68105a chip=0x4d68105a rev=0x02 hdr=0x00 none0@pci0:13:0:class=0x03 card=0x63261569 chip=0x63261039 rev=0x0b hdr=0x00 ed0@pci0:15:0: class=0x02 card=0x802910ec chip=0x802910ec rev=0x00 hdr=0x00 none1@pci0:20:0:class=0x03 card=0x chip=0x02051039 rev=0x11 hdr=0x00 The chipset used on this motherboard is a SiS 5596/5513. (Even though dmesg likes to claim that the ATA controller is a SiS 5591, which it isn't. It is a SiS 5513.) -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 12:06:56PM -0800, Bakul Shah wrote: > > Maybe I missed something, but why cannot you just rip random() from libc, > > rename it to bakul_shah_random() and use that in your testing code? Then you > > are safe from any changes to random(), and indeed have a portable RNG if your > > host OS changes. > > Yes, *I* can do it but I don't work at every place they do > simulation! If in the extreme you are suggesting that a > portable application shouldn't rely on any OS features, you > are of course right but that kind of makes mockery of any > claims of compatibility. The point of compatibility is to > not break interfaces unless there is a significant benefit. If your program depends on the exact algorithm used by random() (or rand() for that matter) to not change between OS updates (not to mention between different systems) then that is a bug in your program. The interface will not change just because a different algorithm is used. The exact sequence of random numbers produced is not a part of the interface but rather an implementation detail that portable programs should not depend on. It might also be worth noting that if a good PRNG is needed then one should not use random() or rand() since on some systems their output is not very random. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Final fix for correlation problem (was Re: rand() is broken)
On Mon, Feb 03, 2003 at 07:01:50AM -0500, Thomas David Rivers wrote: > I'm afraid I don't understand the fix... and how it > seems to affect the historical behaviour of srand()/rand(). > > How does it address the understanding that if I use > srand(28), I will get exactly the same sequence of > numbers srand(28) produced yesterday, last week, > last year? That understanding is mistaken. > > I have worked with programs that depend on exactly > that behavior. Then those programs have a bug. If you need every execution of the program to use the exact same sequence of pseudo-random numbers then the program need to implement its own RNG. > > That is, given the same input seed - I expect > to see the same "random" sequence again. You will - if you generate both sequences during the same program execution. There are no guarantees (and has never been) that srand()/rand() will give the same sequence after an OS update or on a different system or even between two different runs of the same program. > > This requirement would seem to indicate that changing > srand()/rand() isn't really possible... And, also, > I believe, why random() was introduced... a) srand()/rand() does use different algorithms on different systems so depending on some particular algorithm is inherently unportable. b) random() was not introduced because the sequence from rand() couldn't be changed. It was rather because the calling interface for srand()/rand() puts constraints on the implementation that result in rand() by necessity being a rather poor RNG. random() was introduced so one could have a RNG with better statistical properties. c) I believe the algorithm used by rand() *was* changed in -CURRENT about two years ago. (And pretty the same discussion ensued back then.) This change was done because the old algorithm used was particularly poor and it was possible to do better. Now some defect in the new algorithm has apparently been discovered which is why it needs to be modified again. > > Please, oh please, don't change that behavior in > srand()/rand(). > > - Dave Rivers - -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling with high optimization?
On Sun, Feb 09, 2003 at 08:03:57AM -0600, Jacques A. Vidrine wrote:
> On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote:
> > The compiler
> > didn't complain when he checked it before committing it because
> > optimization was off by default; it should have complained, e.g.:
>
> Is that really what you meant? I don't believe it has anything to
> do with optimization; rather, it is to do with lack of `warning'
> flags. For example, if you build libc with WARNS=5 (so as to get the
> `-Wuninitialized' flag), then you get this warning.
>
> > "x.c:9:warning: `foo' might be used uninitialized in this function"
Some warnings are not generated unless you compile with optimization
on. The reason for this is that to generate some of the warnings (for
example about uninitialized variables) you need to do some dataflow
analysis and gcc only does this when optimizing.
Take for example this little program:
#include
int main(void)
{
int a;
printf("%d\n",a);
return 0;
}
When compiled using 'gcc -O0 -Wall' no warnings are generated. When
compiled with 'gcc -O1 -Wall' you get a warning that 'a' might be used
uninitalized. (This is the case for gcc 2.95.x at least. I believe the
situation is the same with gcc 3.x)
--
Erik Trulsson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Clang now builds world and kernel, on i386 and amd64
On Sun, Sep 26, 2010 at 02:21:51PM +0200, Bartosz Stec wrote: > W dniu 2010-09-24 16:34, Dimitry Andric pisze: > > On 2010-09-24 14:13, Bartosz Stec wrote: > >>> Could you please try to rename this make.conf to e.g. > >>> make.conf.disable, > >>> and retry the world build? > >> Still the same without make.conf. My personal guess is, that clang > >> builded by clang with CPUTYPE=athlon-xp is somehow broken. I don't think > >> CFLAGS=-O2 -pipe could do any harm, and also note that clang builded by > >> GCC with exactly the same make.conf has no problems with world > >> building :) > > > > I still cannot reproduce your issue... To check, I have built world > > with CPUTYPE=athlon-xp, verified it used "-O2 -pipe -march=athlon-xp" as > > compilation flags for the world stage, and installed the resulting clang > > executables. > > > > Those clang executables do not exhibit the same problem as yours do; > > they can build tblgen (during the bootstrap-tools stage) fine. > > > > I suggest you comment out the CPUTYPE macro in make.conf for now, > > rebuild your world with gcc, and then rebuild it with clang again, to > > see if the issue goes away. > > Indeed, I was right. Problem is gone after hashing out CPUTYPE line, > building world with GCC, and with clang after that. Now world is > building without problems. > > But hey, i just realized that: > > # dmesg | grep -i cpu > CPU: mobile AMD Athlon(tm) XP 2200+ (1800.11-MHz 686-class CPU) > > I simply forgot that about a year ago I changed Athlon XP in this BOX to > Athlon MP and I didn't changed CPUTYPE in make.conf... > So maybe clang in fact did exactly what it should and created binary > designed to other CPUTYPE ;) I don't know exact differences between > Athlon XP/MP architecture (registers specially) but I just started > another try with CPUTYPE=Athlon-mp and I will post results :) The only difference between Athlon XP and Athlon MP is that the MP variants are certified for multi-processor use (in reality most Athlon XP also worked just fine in multi-processor systems, or could easily be modified to do so.) Available instructions and registers are identical between the two. Mobile variants of the Athlon XP should also be identical from a programming point of view. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Request for testing/comments -- import of new dialog/libdialog
On Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote: > As part of work on a new installer, I would like to update the base > system dialog and libdialog to the newer one provided by Thomas Dickey > (http://invisible-island.net/dialog/, ports as devel/cdialog). This is a > much nicer, fuller featured version of dialog that simplifies the > creation of new dialog-using tools (a longstanding impediment to a new > versions of sade, sysinstall, etc.), and is under a marginally better > license (LGPL2 instead of GPL2). > > Patches to effect the import can be found at: > - http://people.freebsd.org/~nwhitehorn/libdialog-update.diff > > What the patches do: > - Replaces dialog(1) with a new version. All command-line options of the > old dialog except --fstree are accepted by the new dialog, and the ports > options framework continues to work without modification. > - Renames libdialog to libodialog (old dialog). The new dialog library > has a much more pleasant API than the old one -- which directly implies > that it has a substantially different API. Until sysinstall, sade, and > tzsetup are replaced or rewritten, we need to keep the old library around. > - Modifies sysinstall, sade, and tzsetup to link to libodialog instead > of libdialog. > - Deletes all man pages and examples associated with libodialog. This is > deprecated code. > - Installs new dialog library as libdialog > - Bumps __FreeBSD_version to 900030 Are there any ports which link to the old version of libdialog, and if so, what will happen to them? Why not keep the old version as libdialog and instead use a new name for the new library (libndialog or whatever) ? (I am not saying you should do this - it is a real question.) -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Release Engineering Status Report
On Tue, Sep 16, 2003 at 10:30:50AM -0600, Scott Long wrote: > Mike Silbersack wrote: > >On Tue, 16 Sep 2003, Scott Long wrote: > > > > > >>Patches have been floated on the mailing list that revert PAE in its > >>various stages. Maybe those need to be brought back up. Silby? Tor? > >> > >>Scott > > > > > >I believe that Tor's commit on August 30th resolved the PAE-related > >problems, so there is no need for a reversion. Since that time, I've seen > >three panics posted: > > > >1. Some netinet/ related panic which I couldn't make heads or tails of, > >and I haven't any followup reports from the poster. > > > >2. Maxim's buildworld -j64 memory kmap entry exhaustion panic, which can > >be fixed by increasing the number of kmap entries. (Tor has a patch for > >this, I will probably commit it soon.) > > > >3. A panic caused by sending 64K-1 ping packets, which I can't reproduce. > > > >(There's also a small problem with if_xl on pentium-1 machines, but since > >it's my fault and I'm waiting on test results from a guy, we won't talk > >about it.) > > > >(Hey, anyone have a pentium-200 and a 3com 905B card? Contact me, further > >testing can't hurt.) > > > >So, as far as I can tell, there are no remaining problems related to PAE; > >I believe that most people are venting frustration that built up between > >August 9th and 30th. > > > >Mike "Silby" Silbersack > > > > Ok, thanks for the update. Since it is 17 days after Aug 30 and people > are still upset, the status was very unclear to the Release Engineering > Team. So I guess we ened to solicit updates from the people who were > directly experiencing problems, and ask for everyone else to test it as > much as possible. I was one the people who were experiencing stability problems after the PAE commit. I had several unexpected panics and could provoke panics nearly at will on systems that had previously been rock-stable. After the Aug 30 commit I have not had any panics at all and I have not experienced any other stability problems either since then. In my personal experience RELENG_4 is currently quite stable (not counting any commits made during the last 48 hours or so since I have not yet tested any of those), but it is of course possible that other people have run into bugs in components of the kernel that I don't use. (Note: I do not have PAE enabled in the kernel. I have no idea what the situation is for those who actually have enabled PAE, but any problems that may exist there is non-critical IMO since they would not affect any pre-existing configurations.) -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvsup sites are all at capacity?
On Tue, Sep 16, 2003 at 04:01:39PM -0600, Andrew Lankford wrote: > I've tried various cvsup sites (normally cvsup2 or cvsup16 ) > and each site returns this message: > > Rejected by server: Access limit exceeded; try again later > > I've gotten that before but never with all of the hosts out there. > Is everyone and their brother doing a make world today, Probably. There was a security advisory for OpenSSH released earlier today, so I would guess just about everybody is trying to update their systems. > are the sites down for maintenance, or is something sinister > going on? > > Just wonderin' > > Andrew Lankford > -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Supfile tag for 5.2 rc
On Thu, Oct 16, 2003 at 09:12:12AM +1100, Nigel Weeks wrote: > Can someone give me the supfile tag for the latest 5.2 release candidate? No. There is no "5.2 release candidate", so getting it might be a bit difficult. The closest you can get at the moment is to get the latest -CURRENT, with the tag for that being '.' as usual. > > I'm not sure if 'RELENG_5_2' will work... I am sure it will not work, since that tag does not yet exist, and will not exist until 5.2-RELEASE is almost ready to go. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hiding e-mail adresses needed badly
On Thu, Oct 16, 2003 at 04:43:27AM -0500, Peter Schultz wrote: > At this point in time it's downright irresponsible not to hide our > addresses. > > I've been lurking on this list about a month to get caught up with > -current issues. Friday was both the first mail I sent to the list, > and the first use of this e-mail address. The only incoming mail was > from the FreeBSD lists I subscribed to. However, since that fateful > e-mail I have been viciously attacked by spammers posing as Microsoft > security updaters. These spams include attachments making them all > around 150KB in size. Maybe others of you have seen them? I guess you are referring to the W32.Swen worm? I guess most people have seen that one by now. > > As far as I can tell, these guys are targeting the FreeBSD lists, > exploiting them terribly! This list's charter states that spam will be > blocked. Please enforce the list charter, with prejudice. The FreeBSD lists are not targeted specially. That worm mainly harvests e-mail addresses from newsgroups (and from files stored on infected computers.) There are several mail<->news gateways for this list (and other freebsd lists), so this is probably where it got your mail-address. Since these gateways are not under the control of FreeBSD.org there isn't much that can be done about it. These spams are mainly not sent through the lists so they can't be blocked there (even though lots and lots of spam is blocked by the FreeBSD list servers.) > > It would be best if subscribers could just choose to have their address > published or not. I can understand being so dedicated to the cause that > you're willing to take on some spam. Non-subscribers addresses should > definitely not be published. > > Sincerely, > Pete... > > Wilko Bulte wrote: > >On Wed, Oct 15, 2003 at 03:29:21PM +0400, Andrey Chernov wrote: > > > > > >I fail to see why this is relevant to -current but OK.. I think that > >the opportunity to do this has long since passed. Just type your name > >in Google and see what happens.. > > > >Wilko > > > > > >>Due to increased activity of SPAM harvesters what are our plans to hide > >>our addresses from public WWW? I mean all browseable mailing lists, > >>FreeBSD site, CVS via WWW, PRs, ports and docs. Note that there are many web-archives of the mailing lists. Lots of them are run by other people. You need to talk to them too. > >> > >>As I think, simple form will be enough to stop > >>them. > >> -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ethercons: ethernet console driver for 5-current
On Wed, Oct 22, 2003 at 12:30:41AM -0700, Terry Lambert wrote: > Peter Jeremy wrote: > > >As with the Linux driver, communication happens at the ethernet link > > >layer, using protocol number 0x0666 (entertaining choice). > > > > If Linux is using 0x0666, we should probably pick a different number > > since we're not wire compatible. Though coming up with a common > > protocol would be even better. > > 0x666 hex is 1638 decimal, and it's taken: > > cnip1638/tcp CableNet Info Protocol > cnip1638/udp CableNet Info Protocol That would be relevant if this protocol used TCP or UDP. My understanding is that it doesn't, in which case those port assignments are quite irrelevant. Looking at the protocol types listed in /usr/include/net/ethernet.h seems more relevant, unless I have misunderstood something. > > Basically, this is just an experimental protocol that's being played > with here, and if it ever becomes real, then it will need an IANA > protocol number assignment before it's widely deployed. Are you sure that IANA would be the right organisation, since AIUI this isn't a protocol running on top of IP ? > > -- Terry -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone object to the following change in libc?
On Fri, Oct 31, 2003 at 10:06:43AM -0500, Garrett Wollman wrote:
> < said:
>
> > POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
> > integer types exist. It says that the existence of int8_t implies
> > that a byte is 8 bits and CHAR_BIT is 8. I'm not sure what prevents
> > int8_t being smaller than char.
>
> Nothing can be smaller than char (except bitfields, which you can't
> take the size of anyway).
Perhaps not smaller in terms of the sizeof operator, but why can't one
have a 16-bit char, and an int8_t which occupies 16 bits, but only uses
8 of them - the other 8 being padding?
>
> The full story:
>
> The POSIX sockets standard (I forget which letter it had) introduced
> uint8_t et al, but was aligned to C90. That amendment was integrated
> into the main text at the same time as C99 was, and late in the
> process we realized that C99's definition of uint8_t is much stricter
> than what the socket standard expected. (Specifically, the socket
> standard allows uint8_t to have padding bits that do not participate
> in the domain of the type, but C99 does not.) Faced with the choice
Where in C99 does it say that uint8_t can't have padding bits?
I can't find anything in n869.txt to that effect.
As far as I can tell, the only type that is not allowed to have any
padding bits or trap representations is unsigned char.
> of having to invent from whole cloth a completely new set of
> interfaces to describe packing and unpacking eight-bit network data in
> nine- or sixteen-bit characters, or specifying an explicit byte size,
> we chose the latter. It helped that there were no more 36-bit
> platforms to be concerned about. (Some would say that this was a
> rather belated recognition of a choice the industry made two decades
> ago There was, however, a 36-bit implementation of FIPS 151-2, by
> UNISYS.)
--
Erik Trulsson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone object to the following change in libc?
On Fri, Oct 31, 2003 at 06:20:17PM +0100, Stefan Farfeleder wrote: > On Fri, Oct 31, 2003 at 04:43:37PM +0100, Erik Trulsson wrote: > > > Perhaps not smaller in terms of the sizeof operator, but why can't one > > have a 16-bit char, and an int8_t which occupies 16 bits, but only uses > > 8 of them - the other 8 being padding? > > 7.18.1.1 Exact-width integer types > > 1 The typedef name intN_t designates a signed integer type with width N, no padding > bits, and a two's complement representation. Thus, int8_t denotes a signed integer > type with a width of exactly 8 bits. I see. My confusion stems from the fact that n869.txt (the last publically available draft of the C99 standard) says 7.18.1.1 Exact-width integer types [#1] The typedef name intN_t designates a signed integer type with width N. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits. The ", no padding bits" part is apparently one of the things that were changed between n869.txt and the final standard. Note to self: I really need to get a copy of the final C99 standard as soon as I can afford one. > > > Where in C99 does it say that uint8_t can't have padding bits? > > I can't find anything in n869.txt to that effect. > > As far as I can tell, the only type that is not allowed to have any > > padding bits or trap representations is unsigned char. > > uint8_t is int8_t's corresponding unsigned type. This means > sizeof(uint8_t) == sizeof(int8_t), thus uint8_t can't have padding bits > either. Yes, with the quote from the standard you supplied above, that becomes clear. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, Nov 16, 2003 at 09:46:47AM -0500, Robert M.Zigweid wrote: > > On Nov 16, 2003, at 12:10 AM, Gordon Tetlow wrote: > > >I just committed a patch to change /bin and /sbin from statically to > >dynamically linked. If you don't like the idea of using a dynamically > >linked /bin and /sbin, now is the time to define NO_DYNAMICROOT in your > >make.conf. > I'll admit to being mostly a lurker here, but isn't the point of /sbin > to be statically linked. That's what the 's' stands for? No. I think 's' is for 'system'. If you look carefully you will find that the commands in /bin and /usr/bin are those that are useful to normal users as well as sysadmins, while those in /sbin and /usr/sbin are commands that are mostly useful for the sysadmin only. > > Second question. This seems to imply that /sbin and /bin both have to > have the same behavior? They traditionally do have the same behavior, so I don't see that as a problem. > I have no problem with /bin being dynamically > linked, but what if I want /bin to be dynamic and /sbin static? Why? If you can't use the commands in /bin due to problems with dynamic linking you are unlikely to be helped by the commands in /sbin being statically linked. (For one thing you won't be able to get a shell since those normally reside in /bin.) -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote: > > On Nov 16, 2003, at 9:22 AM, Richard Coleman wrote: > >Robert M.Zigweid wrote: > >>I'll admit to being mostly a lurker here, but isn't the point of > >>/sbin to be statically linked. That's what the 's' stands for? > >>Second question. This seems to imply that /sbin and /bin both have > >>to have the same behavior? I have no problem with /bin being > >>dynamically linked, but what if I want /bin to be dynamic and /sbin > >>static? > >>Regards, > >>Robert M. Zigweid > > > >I'm not sure what that would accomplish. If a system was broken such > >that the dynamically linked binaries in /bin didn't work, the > >utilities in /sbin wouldn't be enough to fix the system. For > >instance, you wouldn't have a shell or "ls". > > This is just a case of OS evolution. /sbin used to be the place where > the statically linked recovery things would be placed, in case the > shared libraries got hosed. The only things that needed to be > statically linked though, were system utilities, which is why people > probably started to associate the "s" with system, rather than static. > > When this happened, you started to see the duplicates that used to > exist in /bin (or /usr/bin) and /sbin disappear. Since you still need > a place to have statically linked recovery utilities, /rescue was > created. Now you see the duplicates in /bin (or /usr/bin) and /rescue > instead. Do you have any references for this? Every single place that I can find explains /sbin as "system binaries". I have also never heard of there ever being duplicates in /bin of the files in /sbin. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, Nov 17, 2003 at 09:00:20AM -0500, Michael Edenfield wrote: > * Erik Trulsson <[EMAIL PROTECTED]> [031116 23:21]: > > On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote: > > > This is just a case of OS evolution. /sbin used to be the place where > > > the statically linked recovery things would be placed, in case the > > > shared libraries got hosed. The only things that needed to be > > > statically linked though, were system utilities, which is why people > > > probably started to associate the "s" with system, rather than static. > > > > > > When this happened, you started to see the duplicates that used to > > > exist in /bin (or /usr/bin) and /sbin disappear. Since you still need > > > a place to have statically linked recovery utilities, /rescue was > > > created. Now you see the duplicates in /bin (or /usr/bin) and /rescue > > > instead. > > > > Do you have any references for this? Every single place that I can > > find explains /sbin as "system binaries". I have also never heard of > > there ever being duplicates in /bin of the files in /sbin. > > Also, wouldn't the names 'bin' and 'sbin' pre-date the existiance of > dynamically linked binaries? Yeah, that is what I thought too, but it does not seem to to be the case. As far as I can tell (after using Google for quite a bit) shared libraries were first introduced in Unix with SysVR3, with the model currently in use first appearing in SunOS 4 (I have no idea what they looked like in SysVR3.) /sbin seems to have first appeared in SysVR4, which postdates both of the above. /sbin seems to have been introduced to BSD sometime between 4.3BSD and 4.4BSD. (And SysVR4-derived systems seem to have /bin just as a symlink to /usr/bin, with /sbin containing only what is needed to boot the system far enough to mount /usr, with system binaries otherwise appearing in /usr/sbin and normal user binaries in /usr/bin. Solaris does appear to have dynamically linked duplicates in /usr/sbin of the statically linked programs appearing in /sbin.) > AFAIK the primary difference between the > two was the /bin was typically in a user's PATH and /sbin was not. This is apparently one of things that differ between SysV- and BSD- derived systems. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4 Clause license?
On Mon, Nov 17, 2003 at 02:48:08PM -0500, Rod Taylor wrote: > The PostgreSQL group has recently had a patch submitted with a snippet > of code from FreeBSDs src/bin/mkdir/mkdir.c. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27 > > Is this intentionally under the 4 clause license or does the copyright > from the website (2 clause) applied to everything that is non-contrib? > > http://www.freebsd.org/copyright/freebsd-license.html That copyright notice on the website should apply to everything that is not under some other license. Different parts of the system is under different licenses and copyrights depending on who wrote it. The mkdir.c *was* under the 4 clause license. However all material that was part of the original BSDs and thus was copyrighted by "The Regents of the University of California" has had its license changed such that clause 3 (the advertising clause) no longer apply. This would seem to include mkdir.c Most of the files in the source tree have not had their copyright notices updated to reflect this. See http://www.freebsd.org/copyright/license.html for details on this license. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GCC 3.3.1, new warnings with
On Sun, Jul 13, 2003 at 01:37:32PM -0500, David Leimbach wrote: > > On Sunday, July 13, 2003, at 1:23PM, M. Warner Losh wrote: > > >: > 134 #define __glibcpp_signed(T) ((T)(-1) < 0) > >: #define __glibcpp_signed(T) (!((T)(-1) > 0)) > > > >Why not the simpler: > > > >#define __glibcpp_signed(T) ((T)(-1) <= 0) > > > >that way we have an overlap on the range of the two types, so we won't > >get a warning. We know for a fact that -1 != 0 for all known machine > >types (all machines are two's complement, or are required to behave as > >if they are two's complement, per the standard). > > > > You keep saying this... where is this "must behave as two's compliment > stated?" > > > >(unsigned int) -1 == 0x(assuming 32-bit int). > > or with a valid one's compliment C99 compliant system > (unsigned int) -1 = 0xfffe; Only if UINT_MAX happens to be0xfffe, which it probablky won't be. For all C99 compliant systems you have that: (unsigned int) -1 == UINT_MAX > > > > >even on a one's complement's machine, without the standard conversion, > >the 'type punning' conversion of -1 would yield 0xfffe, which is > >still > 0. > > > Correct :). I still don't think C enforces two's compliment. C doesn't require two's compliment, but it encourages it. If you take a signed value and convert it to the corresponding unsigned type , the result must be equal modulo 2^N to the original value (where N is the number of bits in the unsigned type. (Ignoring any padding bits.)) (Actually it is modulo a value one greater than the largest value representable by the unsigned type, but this amounts to the same thing.) This means that -1 converted to an unsigned type will always be the largest number representable by that unsigned type. This is true regardless of how negative numbers are represented. For two's complement there is no need to change the representation when converting signed to unsigned values, while this can be needed when using sign-magnitude or one's-complement. And to answer the original question: It is valid to assume that -1 converted to an unsigned integer type will never be equal to 0. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GCC 3.3.1, new warnings with
On Sun, Jul 13, 2003 at 02:28:38PM -0500, David Leimbach wrote: > > > >C doesn't require two's compliment, but it encourages it. > > > >If you take a signed value and convert it to the corresponding > >unsigned type , the result must be equal modulo 2^N to the original > >value (where N is the number of bits in the unsigned type. (Ignoring > >any padding bits.)) (Actually it is modulo a value one greater than the > >largest value representable by the unsigned type, but this amounts to > >the same thing.) > >This means that -1 converted to an unsigned type will always be the > >largest number representable by that unsigned type. > >This is true regardless of how negative numbers are represented. > >For two's complement there is no need to change the representation when > >converting signed to unsigned values, while this can be needed when > >using sign-magnitude or one's-complement. > > > > So for the one way conversion of signed to unsigned it will behave like > 2's compliment Signed to unsigned will always give the same result, regardless of how negative numbers are represented, yes. (And for two's complement this is the same as the "natural" way of doing it, while for other representations some extra work might be needed.) > all the time. What about back to signed? I assume that it defaults > back to the If you have try to convert a value to a signed type and the type in question cannot that value, then the result is implementation-defined. Implementation-defined means the implementation is free to do whatever it wants, but it must document what it will do. Typically implementations won't do anything special but will just keep the same representation, but this is not something that portable programs can depend on. So, on a one's complement machine one would probably have that: (int)UINT_MAX == 0 (Since UINT_MAX would have the same representation as a negative zero on such a machine.) On a sign-magnitude machine it would probably be (int)UINT_MAX == INT_MIN and on a two's complement machine one would probably have (int)UINT_MAX == -1 but an implementation is also free to trap on integer overflow, just as it usually does with division by zero. (Or it might do something else.) Unsigned arithmetic is well-defined in C. Signed arithmetic less so. > platform's implementation of the signed type which due to the > conversion to > unsigned would also, logically, be encouraged to behave as a 2's > compliment signed > number. Cute way to make the standard "seem" flexible. The overhead > of type > conversion is often overlooked in coding it seems... On some platforms > like the > PPC going from int to float takes a lot longer than one might think... That depends on how long one thinks it should take, doesn't it? :-) > but that > is another story :). [no need to answer this... unless we take it out > of this thread] > > > >And to answer the original question: > >It is valid to assume that -1 converted to an unsigned integer type > >will never be equal to 0. > > > > No arguments here. :) Sorry if we wandered off too far. It was at > least enlightening > for me and hopefully others. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GCC 3.3.1, new warnings with
On Sun, Jul 13, 2003 at 01:48:38PM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > David Leimbach <[EMAIL PROTECTED]> writes: > : So for the one way conversion of signed to unsigned it will behave like > : 2's compliment > : all the time. What about back to signed? > > Same way. > > It will be reduced by the maximum value of the range plus one to do > the conversion. No, this case is implementation-defined if the value cannot be represented by the signed type it is converted to. (If it can be represented then the value will be preserved.) > > See section for 6.3.1.3 for the details. Yes, please do. > > That's why I said 'as if' in my other mail. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will official-NVIDIA-driver for 4.7 work with -CURRENT ?
On Fri, Nov 08, 2002 at 02:11:08PM +0100, Juan Francisco Rodriguez Hervella wrote: > Hello, > > I've just seen the release of FreeBSD-NVIDIA driver for > FreeBSD-4.7 > > Will this driver work with -CURRENT ?¿ > > PS: http://www.nvidia.com/view.asp?IO=freebsd_1.0-3203 The README file found at the above URL claims that: FreeBSD -STABLE versions older than 4.7 and FreeBSD -CURRENT are not supported. So I guess the answer is no. It is of course possible that it might work anyway even if NVIDIA don't support it but since a kernel module is involved and those are generally not portable between major releases it is not very likely it will work. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 80386 out of GENERIC
On Sun, Dec 15, 2002 at 12:18:21AM -0500, Craig Reyenga wrote: > Sorry for butting in, but my $.02 is that 386's are old enough that > FreeBSD, or any other OS for that matter, shouldn't wait up for them. Why not? An OS in itself should not require a lot of CPU power. > They've gotten to the point where they are basically useless except > for running older software, which was likely written for them anyways. They are not useless, and if new software has problems running on them it is mostly because a lot of new software is big and bloated without any good reason except for lazy/incompetent programmers. > If I had a 386 that I wanted FreeBSD on, I'd crack open the old FreeBSD 3.5 > install CD's, assuming it even had a cdrom drive. > > I understand why people care about supporting older hardware. Reasons > such as cost, and the ability to allow code bloat to _really_ manifest > itself > come to mind. However, a 386 is just too old for words and should > be running older software with less features. Less features and more security problems. Considering that security fixes normally don't get applied to the 3.x branch any longer one might want to be a bit careful running that on a computer connected to the Net. Eventually I assume that 4. will be similarily abandoned which means that you will have to run 5.x to have a secure system. Personally I strongly disagree with the notion that hardware that is a mere 10 years old (like some '386s) should be considered "too old for words". The only remotely good reason I have heard for removing support for 386 in the default configuration is that having it in would pessimize performance too much for more modern CPUs. How valid that reason is I cannot judge, but I guess it is possible. (And just FYI, my 386 box is happily running 4.7-stable at the moment without any problems and I will probably consider updating it to 5.x when security fixes are no longer automatically applied to 4.x.) > > -Craig > > - Original Message - > From: "Terry Lambert" <[EMAIL PROTECTED]> > To: "M. Warner Losh" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Saturday, December 14, 2002 23:55 > Subject: Re: 80386 out of GENERIC > > "M. Warner Losh" wrote: > > > One problem with most 386 boxes is that they have very little memory. > > > sysinstall is a big, bloated pig dog these days that takes more RAM > > > than most 386 boxes have. This is true also for many 486 boxes too. > > > So even if 386 stuff were in the default kernel, you'd likely have > > > other issues in making sysinstall work and have to do custom > > > hacking... > > > > Add to this that Bosko's workaround for the CPU bug with PSE/PGE > > includes loading the kernel at 4M rather than 1M. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another possible solution for non-sendmail users
On Sat, Mar 30, 2002 at 07:12:52PM +0100, Dag-Erling Smorgrav wrote: > Gregory Neil Shapiro <[EMAIL PROTECTED]> writes: > > Given that non-sendmail users will be inconvenienced when upgrading due to > > the 8.12 changes (need to change sendmail_enable from "NO" to "NONE"), > > Why? It doesn't make any difference as long as one uses the > mailwrapper stuff: Yes, it does. > > des@des ~% grep sendmail /etc/rc.conf > sendmail_enable="YES" > des@des ~% cat /etc/mail/mailer.conf > # > # Execute the Postfix sendmail program, named /usr/local/sbin/sendmail > # > sendmail/usr/local/sbin/sendmail > send-mail /usr/local/sbin/sendmail > mailq /usr/local/sbin/sendmail > newaliases /usr/local/sbin/sendmail > > So what's all this noise and racket about? This assumes that the replacement "sendmail" binary accepts the same options as the real sendmail. In particular the options that are used by default in the rc* files. This is not the case for qmail for example. (And there the normal use is not to start it with sendmail_enable="YES" but rather from its own start file under /usr/local/etc/rc.d/ after disabling sendmail with sendmail_enable="NO" (now "NONE"), which I think should be the standard behaviour for alternative MTAs.) So, if one uses qmail this change does require you to modify the sendmail_* options in /etc/rc.conf. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please test PAUSE on non-Intel processors
On Fri, May 24, 2002 at 10:25:53AM -0400, John Baldwin wrote: > Hey gang, although Intel's document seems to claim that they tested > proper operation of pause I'd like people with non-Intel processors > to verify that it actually works. Please compile the attached test > program and run it. The output should look like this: > > > ./pt > Testing PAUSE instruction: > Register esp changed: 0xbfbff9fc -> 0xbfbff9c0 > Intel Pentium 166/MMX: Testing PAUSE instruction: Register esp changed: 0xbfbffad8 -> 0xbfbffa9c AMD 386sx/33: Testing PAUSE instruction: Register esp changed: 0xbfbffb20 -> 0xbfbffae4 Both machines running 4.6-PRERELEASE -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT: ath0: stuck beacon; resetting (bmiss count 4)
Quoting "O. Hartmann" : Since a couple of days I get this weird console-and-log-spamming message: ath0: stuck beacon; resetting (bmiss count 4) The machine in question is running the most recent CURRENT right now: FreeBSD 11.0-CURRENT #2 r272471: Fri Oct 3 13:03:58 CEST 2014 amd64 and the box acts as a gateway with WiFi access point via hostapd and this WiFi hardware: [...] ath0: mem 0xf7e0-0xf7e0 irq 16 at device 0.0 on pci1 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams [...] ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 What is this and how can I get rid of it? It means that you have run into a well-known and long lasting hardware bug in Atheros Wifi chipsets, where they sometimes get stuck and stops sending out beacons. You get that message when the device driver detects that this has happened and resets the chip to get things going again. There is, AFAIK, no way of making sure the problem cannot happen, but you might be able to reduce the frequency of it happening by reducing the amount of interference you receive from other wireless devices. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: qsort() documentation
Quoting Warren Block : On Tue, 19 Apr 2016, Aleksander Alekseev wrote: Why Wikipedia, specifically? There are a lot of places that describe quicksort. How about just Note: This implementation of qsort() is designed to avoid the worst-case complexity of N**2 that is often seen with standard versions. I would say that this statement is just false. Worst-case complexity is still N**2. How about something like: """ This implementation of qsort() has worst case complexity of N**2. However measures were taken that make it very unlikely that for some random input N**2 swaps will be made. It's still possible to generate such an input on purpose though. See code below for more details. """ Okay: The quicksort algorithm worst-case is O(N**2), but this implementation has been designed to avoid that for most real data. Keep in mind that there is no requirement whatsoever that the qsort() function uses the quicksort algorithm, even if that is a common way to implement qsort() Also, worst-case is worst-case, no matter how unlikely. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
On Tue, Sep 27, 2011 at 08:22:54AM -0400, Robert Huff wrote: > > krad writes: > > we can leave that to our grand children to figure out though 8) > > Wasn't that what people said about two-digit years? Not quite. There they mostly said "No way that this program will still be in use when two-digit years becomes a problem!" -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: stable/9 still looking for packages at 9-current
On Mon, Jan 09, 2012 at 01:16:59PM -0500, Arnaud Lacombe wrote: > Hi, > > On Mon, Jan 9, 2012 at 9:37 AM, Mark Linimon wrote: > >> On 9. Jan 2012, at 01:04 , Arnaud Lacombe wrote: > >> So you are saying that FreeBSD is currently providing on > >> ftp://ftp.freebsd.org/pub images tagged as being "9.0 RELEASE" (with > >> checksum provided), in a `releases' directory, which are not actually > >> release images per-se ? > > > > Excellent! You've shown the ability to understand flat, declarative, > > sentences that have no qualifying phrases. > > > FWIW, this was more a sarcastic sentence pointing out that FreeBSD is > currently officially distributing non-released build in a directory > which might leads users to consider this is the official release, thus > misleading them. That build is intended to become the official release unless some last-minute showstopper problem is found. (Unlikely, but has happened before.) The build is being distributed in advance of the official announcement to make sure it is available on all mirrors at the moment the announcement is made. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src/ from SVN directly?
On Sat, Mar 26, 2011 at 10:31:39AM -0700, Nerius Landys wrote: > > one could also use the -F switch in connection with mergemaster(8). > > >From mergemaster manpage: > > "If the files differ only by VCS Id ($FreeBSD) install the new file." > > Yes that is exactly what I want, thanks. > > By the way, are there any other ways that are more preferred to get > /usr/src/ than doing what I've done, which is using > devel/subversion-freebsd to checkout head into /usr/src/? No, that is probably the best way. An older method (which still works) is to use csup/cvsup to download a local copy of the whole CVS repository and then use cvs to checkout /usr/src from this copy. Before the switch to subversion this was the preferred way. -- Erik Trulsson ertr1...@student.uu.se ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
