Re: What's happened to CPUSTATES in /usr/include/devstat.h?
From: "Paolo Pisati" <[EMAIL PROTECTED]> Sent: Sunday, March 02, 2003 2:24 PM > i noticed it while i was compiling kdebase-3, cause > ksysguard failed. > > Add > > #include > > to devstat.h to fix it. FWIW, I had the same problem (and used the same solution) with a few other X ports, particularly icewm. --Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sendmail_enable="NONE" doesn't appear in rc.conf
From: "Daniel Flickinger" <[EMAIL PROTECTED]> Sent: Saturday, March 08, 2003 11:48 AM > I have not checked recently, but 'make installworld' has > always trashed files: > > /usr/sbin/sendmail > /usr/bin/mailq > /usr/bin/newaliases > > which, in the default, are symbolic links to > /usr/sbin/mailwrapper. > > Using postfix which installs its own /usr/sbin/sendmail > which is a program, not a symbolic link, I: > > cd /usr/sbin > mv sendmail postmail > ln -s postmail sendmail If installed from ports, Postfix installs a /user/local/sbin/sendmail which does not interfere with the mailwrapper setup. The port also fixes /etc/mail/mailer.conf to point to the postfix binary instead of the sendmail binary. The only thing you need to watch is mergemaster putting the default mailer settings back. --K To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile
* Ceri Davies <[EMAIL PROTECTED]> [030830 09:18]: > On Sat, Aug 30, 2003 at 03:11:02PM +0200, Wilko Bulte wrote: > > See /etc/defaults/make.conf > > Only in RELENG_4, last time I checked. In 5.x, since make.conf was not a set of defaults but merely a list of available make flags, it was moved out of /etc/defaults: $ locate make.conf [...] /usr/share/examples/etc/make.conf [...] --Mike pgp0.pgp Description: PGP signature
Re: re-fdisk'ing a partition - permission denied?
* Jason Stone <[EMAIL PROTECTED]> [030908 17:54]: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > You have hit one of the main issues still to be resolved in GEOM. (I > > don't know that phk thinks it's a problem to be resolved or a feature to > > be documented.) > > > > In any case, since GEOM was added you can no longer slice or label an > > active device. > > Ah - is that to say that, in general, you can't mess with the disk's MBR? Yes, if there are any slices in use on the disk you cannot edit the MBR. Nor can you edit the disklable of an inactive slice if another slice on the same phyisical disk is in use. In general I beleive all direct-to-disk access is forbidden. e.g., if you have ad0s1a mounted as /, you cannot: * fdisk ad0 to create ad0s2 * disklabel ad0s2 to create ad0s2a * perform any data transfer with ad0 as the target. All of this based on my own attempts to repartition a dual-boot disk into a single-boot disk, admittedly at least 2 months ago but I suspect not much has changed since then. As mentioned, phk, at least, seemed to beleive very strongly that this was never going to be permitted and people just needed to be made aware.. Ultimately you need to use a boot floppy and unmount the whole physical disk device. There was, at one point, talk of adding some sort of "geom.dont_blame_phk_when_you_shoot_your_ankle_off" sysctl to permit this type of access when the user was absolutely sure they knew exactly what kind of dangerous and potentially corrupting thing they were doing and wanted to do it anyway, but I'm not sure it got anywhere. --Mike pgp0.pgp Description: PGP signature
Re: new MB = ACPI Errors?
* Steve Ames <[EMAIL PROTECTED]> [030908 20:26]: > > Hey. I installed a new motherboard today and now I get a lot of ACPI > errors (with a kernel from today and one from a few days back). This > anything to worry about? Not really, just annoying. A fair number (all that I've seen!) of motherboard ship with ACPI tables that are buggy. Namely, they are bug-for-bug compatible with Microsoft's much more lenient ACPI interpreter. The stricter one built into FreeBSD chokes on a lot of things. The short answer is, unless you have hardware that's actually not functioning properly, you can usually ignore those messages. You can also just turn off ACPI and they'll go away. (But you're likely to replace them with a bunch of "PNP0501 Could not assign resources" type messages, it's a toss-up.) If you are so inclined, it's often very easy to fix these things. Install the devel/acpicatools port, then use the ASL compiler and decompiler like so: acpidump -o foo.dsdt -d > foo.asl iasl foo.asl You will likely get a lot of errors at that point. Not knowing anything about ACPI I was able to figure out the really easy ones in a few hours. In particular, watch for things like this: foo.asl 1577: Method (_STA, 0, NotSerialized) Warning 2019 - ^ Not all control paths return a value (_STA) These are harmless but easy to fix. Stick Return(0) inside the blocks that are missing them. The line numbers should give you a good idea. foo.asl 857: Field (PSRG, DWordAcc, NoLock, Preserve) Error1047 - ^ Access width is greater than region size These are a bit tricker. It means a field was defined inside of an ACPI region that is bigger than the region itself. The offending lines are: OperationRegion (PSRG, SystemMemory, 0x0410, 0x01) Field (PSRG, DWordAcc, NoLock, Preserve) The 0x01 at the end of the first line means this region is 1 byte big; the DWordAcc in the second line means there's a field that's 4 bytes big in that region. Not good :) In my case simply making the region bigger: OperationRegion (PSRG, SystemMemory, 0x0410, 0x04) Field (PSRG, DWordAcc, NoLock, Preserve) Solved the compile problems. Any more complex ACPI problems you can probably post here and get some assistance from the numerous people who fixed their own ACPI tables. There's also numerous examples on the web of fixed ASL code that may solve similar problems to your own -- hit google and look for the error messages. After that, just copy the .aml file that iasl outputs into /boot and put this in loader.conf: acpi_dsdt_load="YES"# DSDT Overriding acpi_dsdt_type="acpi_dsdt" # Don't change this acpi_dsdt_name="/boot/foo.aml" --Mike pgp0.pgp Description: PGP signature
Re: re-fdisk'ing a partition - permission denied?
* Ulrich Spoerlein <[EMAIL PROTECTED]> [030909 12:33]:
> On Mon, 08.09.2003 at 18:10:38 -0400, Michael Edenfield wrote:
> > e.g., if you have ad0s1a mounted as /, you cannot:
> >
> > * fdisk ad0 to create ad0s2
> > * disklabel ad0s2 to create ad0s2a
> > * perform any data transfer with ad0 as the target.
> Well, perhaps I'm sounding stupid, but I was able to re-slice my disk
> while running FreeBSD off from ad0s2. I was also able to re-label ad0s2
> while the partitions were mounted.
Again, I haven't actually tried to do this since very shortly after GEOM
first went into the tree. Based on phk's recent reply, it appears that
the behavior I was seeing then was buggy; at least it would be
considered buggy today.
What I was specifically unable to do was, while running FreeBSD mouted
from ad0s1, delete ad0s2 and ad0s3 and create a new, larger ad0s2. I
even tried to manually update the MBR via dd, thinking perhaps it was
something on the ad0s{2,3} slices that was causing the problem.i In the
end, I was perfectly content to just boot from the boot CD and do it, and
haven't had to do anything of the sort since :)
--Mike
pgp0.pgp
Description: PGP signature
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
* Alexander Leidinger <[EMAIL PROTECTED]> [030910 10:53]:
> In 5-current we have 3 threads libraries and want to be able to install
> and use them in parallel. So there has to be a way to specify which one.
> This is why we need the ports collection to respect the PTHREAD*
> variables. A lot of ports already do this (e.g. the GNOME ones), but not
> all.
Err, not quite. Tried to build gnome2 lately? :)
gnome2 depends on gnomemedia2.
gnomemedia2 depends on gstreamer-plugins.
gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles
includes -pthread.
The fix is a pretty simple thing:
post-configure::
find ${WRKSRCDIR} -name Makefile | xargs ${SED} -e
"s#-pthread#${PTHREAD_LIBS}#g' -i
But of course, it's not a problem on 4.x and the ports tree's frozen at
the moment, so it will probably be a bit until gnome2 fully compiles.
--Mike
pgp0.pgp
Description: PGP signature
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
* David O'Brien <[EMAIL PROTECTED]> [030910 15:33]:
> On Wed, Sep 10, 2003 at 12:41:41PM -0400, Michael Edenfield wrote:
> > gnome2 depends on gnomemedia2.
> > gnomemedia2 depends on gstreamer-plugins.
> > gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles
> > includes -pthread.
>
> This is being worked on from the compiler stand point.
Which is the main reason I didn't do a pr on it. But from reading other
parts of the thread, it seems that ports should not be using -pthread
anyway... would it be worthwhile to submit patches to remove -pthread
(and, for that matter, -lpthread and other variants) in favor of
${PTHREAD_LIBS} regardless of wether `cc -pthread` is an error or a
no-op, or some magical auto-thread-library-selector?
--Mike
pgp0.pgp
Description: PGP signature
Re: Shared object "libintl.so.4" not found
* Kevin Oberman <[EMAIL PROTECTED]> [030913 00:26]: > > From: Kris Kennaway <[EMAIL PROTECTED]> > > Please don't give bogus advice. The solution is to update everything > > that depends upon gettext, e.g. by using portupgrade. > > Maybe, but this bit me and the solution was to re-build gmake. The > changes in what routines are in libc cause this problem. The reason you had to rebuild gmake is that it, too, depends on gettext. When the port was first built it linked against libintl.so.4. If you upgraded gettext w/out saving the old libraries (in /usr/local/lib/compat/pkg, if I remember right), the gmake broke. There are basically two ways to solve the problem: o As Kris (and others) have said since gettext was first upgraded, you should do this: portupgrade -rf gettext o Keep libintl.so.4 around somewhere, such as portupgrade's compatibility directory. Since libintl.so.4 is not part of the base system, only part of the ports tree, I'm not sure there's any need to warn anyone upgrading from 4.x -> 5.x of anything. There's nothing special about gettext other than the fact that many ports, including GNU make, depend on it. Any other ports which install shared libraries are going to have the same issue, which is why portupgrade saves the old libraries for you to begin with. --Mike pgp0.pgp Description: PGP signature
Re: Initial list of ports that fail due to -pthread
* Kris Kennaway <[EMAIL PROTECTED]> [030923 22:21]: > Here is a partial list of the ports that need to be taught to respect > PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I > just grepped for the "-pthread is deprecated" error message). None of One very important group of ports that should get looked at when this gets worked out is KDE. Apparently, Qt uses a different means of determining wether to use threading, than the ports that depend on it. The qt-using ports appear to check for -lpthread, then c++ -pthread, and if neither of those checks pass, disable threading: checking for pthread_create in -lpthread... no checking whether c++ supports -pthread... no However, Qt somehow knows that threads are supported and installs the libqt-mt version of it's libraries. The dependant ports then look for -lqt, not -lqt-mt, since they've disabled threading. I haven't updated my gcc since -pthread started working again, and this doesn't generate the typical "-pthread is deprecated" error, so I've been pulling my hair out for two days over it :) --Mike pgp0.pgp Description: PGP signature
Re: Initial list of ports that fail due to -pthread
* Will Andrews <[EMAIL PROTECTED]> [030924 01:50]:
> On Wed, Sep 24, 2003 at 01:34:13AM -0400, Michael Edenfield wrote:
> > One very important group of ports that should get looked at when this
> > gets worked out is KDE. Apparently, Qt uses a different means of
> > determining wether to use threading, than the ports that depend on it.
> > The qt-using ports appear to check for -lpthread, then c++ -pthread, and
> > if neither of those checks pass, disable threading:
>
> Also, I believe I fixed qt32 on 18 September 2003. It certainly
> built and works fine on my 5.1-CURRENT 2003/09/19 box. It's just
> KDE that needs fixing at the moment.
Yes, Qt itself worked fine, it was just the rest of KDE that gave me
issues. I've already fixed the issue temporarily by passing --enable-mt
and --enable-threading as CONFIGURE_ARGS and doing some post-configure
replacing of -{l}pthread, I just wanted to point out the problem since
it's slightly different than just 'cc breaks because -pthread is an
error.'
But since you're already well ahead of me fixing it I'll skip the pr I
was about to send in :)
--Mike
pgp0.pgp
Description: PGP signature
Re: Fixing -pthreads (Re: ports and -current)
* Ian Dowse <[EMAIL PROTECTED]> [030924 12:03]:
> In message <[EMAIL PROTECTED]>, Daniel
> Eischen writes:
> >On Wed, 24 Sep 2003, Scott Long wrote:
> >> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't
> >> mean anything outside of that.
> >
> >That just meant it makes it easier to maintain ports so that
> >they are PTHREAD_LIBS compliant (they would break when linked).
> >I know it has no bearing on 3rd party stuff.
>
> Just to throw one further approach out on the table, below is a
> patch that makes gcc read from a file to determine what library to
> associate with the -pthread flag. It's a hack of course, and probably
> neither correct or optimal. If you want to make -pthread mean libkse,
> create an /etc/pthread.libs that looks like:
I was looking through gcc last night to see how conceptually difficult
it would be to do something like this. But instead of a file, I was
thinking of this process:
* if env("PTHREADS_LIBS") then LDFLAGS += PTHREADS_LIBS
* elseif fileexists("libpthread") then LDFLAGS += -lpthread
* elseif fileexists("libthr") then LDFLAGS += -lthr
* elseif fileexists("libc_r") then LDFLAGS += -lc_r
* else error("Threading not supported.")
or whatever. At that point, simply having PTHREADS_LIBS moved into the
environment in bsd.port.mk and leaving all the ports using -pthread
alone would automatically have them support PTHREADS_LIBS. Even better,
the existing bsd.port.mk construct could become just another pre-defined
environment variable, similar to LD_PRELOAD for the runtime linker, but
which affects the compiler/link editor instead.
--Mike
pgp0.pgp
Description: PGP signature
Re: Fixing -pthreads (Re: ports and -current)
* Michael Edenfield <[EMAIL PROTECTED]> [030924 13:21]: > * Ian Dowse <[EMAIL PROTECTED]> [030924 12:03]: > > In message <[EMAIL PROTECTED]>, Daniel > > Eischen writes: > > >On Wed, 24 Sep 2003, Scott Long wrote: > > >> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't > > >> mean anything outside of that. > > > > > >That just meant it makes it easier to maintain ports so that > > >they are PTHREAD_LIBS compliant (they would break when linked). > > >I know it has no bearing on 3rd party stuff. > > > > Just to throw one further approach out on the table, below is a > > patch that makes gcc read from a file to determine what library to > > associate with the -pthread flag. It's a hack of course, and probably > > neither correct or optimal. If you want to make -pthread mean libkse, > > create an /etc/pthread.libs that looks like: > > I was looking through gcc last night to see how conceptually difficult > it would be to do something like this. But instead of a file, I was > thinking of this process: I should point out that my main concern here is not technical but policy. Right now -pthread is implemented entirely as a gcc spec as part of LIB_SPEC. I didn't have time to get very far so I'm not sure how much special-case argument handling is done in gcc currently. Would this kind of approach, to moving the "-pthread" handling out of a specfile and into args handling code, fly with the FSF people? --Mike pgp0.pgp Description: PGP signature
Re: General debug/kernel question
* Harald Schmalzbauer <[EMAIL PROTECTED]> [031116 20:43]: Content-Description: signed data > Salve, > > I always thought that building a kernel with debug symbols would increase the > kernel size dramatically. But if I understand things right the additioal > "symbols" (code snippets?) are not in the kernel but in a different file > which makes the kernel the same size like without debug=-g. Is there any > reason to not build it with debug=-g? The debugging information doesn't appear in the installed kernel (/boot/kernel/kernel for example). The build process makes a kernel, with debug symbols, in /usr/obj/usr/src/sys/KERNCONF. It strips the debugging information out before installing the file, though, because it's pretty big. The downside to adding -g to the build is just that you take up more space in /usr which you may never use. > Also I thought debug kernels suffer from reduced performance. I also have DDB > in my kernel and don't _feel_ any difference. So again, is there any reason > not to put DDB into the kernel? DDB itself probably will never affect your performance in a noticeable way unless your system crashed. The problem with DDB is that, if you're not present at the console when you get a kernel panic, the system hangs waiting for you. You can get around this by adding DDB_UNATTENDED, but IMO this is pretty much worthless for anyone who's not a kernel developer: you don't get to see the DDB screen and write down the backtrace, and you don't get a crash dump that you can extract with savecore. Unless you plan to actually do debugging live in your kernel I'd leave DDB off and set up a dump device instead. This lets you go back after a crash and extract information, by way of your debug kernel, at your leisure. The kernel debugging options that really kill performance are WITNESS and especially INVARIANTS. They cause a lot more debugging code to be compiled into the kernel that's normally cut out, and run lots of extra checks on locking and types and such at run-time. WITNESS also tends to procude excessive messages for potentially harmless problems. --Mike pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
* 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? AFAIK the primary difference between the two was the /bin was typically in a user's PATH and /sbin was not. --Mike pgp0.pgp Description: PGP signature
Re: init and USB oddities-ULE-ATA
* Harald Schmalzbauer <[EMAIL PROTECTED]> [031116 23:42]: Content-Description: signed data > On Monday 17 November 2003 05:25, Steve Kargl wrote: > > On Mon, Nov 17, 2003 at 04:39:08AM +0100, Harald Schmalzbauer wrote: > > Content-Description: signed data > > > > > Salve, > > > > > > since about one day "kill 1" and "init 1" don't work anymore! > > > Now I don't know how to change to single user mode from normal boot now. > > > > "shutdown -r now" will reboot the system. There are > > a number of ways to get to single user mode as the > > system is rebooting. > > I know that, but I'd like to change to singleuser mode like before. `shutdown` by itself with no options will bring the system down into single-user mode. --Mike pgp0.pgp Description: PGP signature
Re: Unfortunate dynamic linking for everything
* Tim Kientzle <[EMAIL PROTECTED]> [031121 18:40]: > Leo Bicknell wrote: > >To boot a machine into single user mode you need a kernel, init, > >and /bin/sh (minimally). It would seem to me that alone is a good > >argument for those three things to be static. > * Rewrite dlopen() to not require dynamic linking. > >There were some patches for this submitted at one point. >As I recall, the people who looked at them were not entirely >comfortable with them. (I'd be concerned about version >conflict problems with this approach: what happens when >a dynamically-loaded NSS module refers to a libc function? >Does that get resolved to the already statically-linked >version? Or does another copy of libc get dynamically linked >with potential version conflicts? Does anyone know?) > >I personally think this is worth researching, though I >have my doubts. I took a look at the glibc implementation of dlopen() breifly, since that does function from within libc.a. It appears that you *do* get more than one loaded copy of libc. The copy of dlopen() that is built when #ifndef SHARED includes a flag: __libc_multiple_libcs that is set to 1. Additionally, I was reading comments from some of the glibc developers who basically claim that dlopen() in a static binary *only* works if you dlopen() a NSS module. It isn't guaranteed to work in the general case because the static binary has no DYNAMIC elf section to resolve external references etc. I suspect this means NSS modules are limited in what they are allowed to reference and still work? I haven't looked in much detail on their implementation but it certainly looks like a hack just to make NSS work, which I don't think is a good long-term solution. --Mike pgp0.pgp Description: PGP signature
Re: HEADS UP: /bin and /sbin are now dynamically linked
* Garance A Drosihn <[EMAIL PROTECTED]> [031124 14:11]: > I doubt there is any perfect answer which will satisfy > everyone, but perhaps we can recognize that and figure out > some flexible middle ground. Would it be possible, through some make.conf magic, for the end-user to set extra programs to be put into /rescue that are not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch ?? --Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
* boyd, rounin <[EMAIL PROTECTED]> [031125 05:16]: > i see that there some doubt about whether running lots of > shell scripts ever happens. what happens when you > use make? lots of shells get run and they run small > (one line?) scripts. Just to provide some real-world numbers, here's what I got out of a buildworld: Static /bin/sh: real385m29.977s user111m58.508s sys 93m14.450s Dynamic /bin/sh: real455m44.852s user113m17.807s sys 103m16.509s The dynamic /bin/sh caused just over an 18% performance hit on the make process, everything else being equal (the rest of my / is dynamically linked). It may seem like a pretty large performance hit, but to my the difference between a 6-hour and a 7-hour world build is just an extra hour of Quake :\ --Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
* M. Warner Losh <[EMAIL PROTECTED]> [031125 12:07]: > In message: <[EMAIL PROTECTED]> > "boyd, rounin" <[EMAIL PROTECTED]> writes: > : i see that there some doubt about whether running lots of > : shell scripts ever happens. what happens when you > : use make? lots of shells get run and they run small > : (one line?) scripts. > > make buildworld slows down < 1% when you switch from static /bin/sh to > dynamic. I'm all for dynamic / and dynamic /bin/sh, but this doesn't even come close to what I observed on my systems. I see anywhere from 15% to 20% slowdown in buildworld, depending on how bad my hardware already is. I posted my most recent numbers earlier. It's difficult to get lots of these numbers, unfortunately, because it takes a good 6-8 hours just to complete one build. But the numbers are fairly consistant across the different degrees of old crappy hardware I have. -Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
* M. Warner Losh <[EMAIL PROTECTED]> [031126 00:43]: > In message: <[EMAIL PROTECTED]> > Michael Edenfield <[EMAIL PROTECTED]> writes: > : * M. Warner Losh <[EMAIL PROTECTED]> [031125 12:07]: > : > In message: <[EMAIL PROTECTED]> > : > "boyd, rounin" <[EMAIL PROTECTED]> writes: > : > : i see that there some doubt about whether running lots of > : > : shell scripts ever happens. what happens when you > : > : use make? lots of shells get run and they run small > : > : (one line?) scripts. > : > > : > make buildworld slows down < 1% when you switch from static /bin/sh to > : > dynamic. > : > : I'm all for dynamic / and dynamic /bin/sh, but this doesn't even come > : close to what I observed on my systems. I see anywhere from 15% to 20% > : slowdown in buildworld, depending on how bad my hardware already is. I > : posted my most recent numbers earlier. > > My dual athlon make -j 4 buildworld differed by about 16-20 seconds on > a 36 minute buildworld. > > : It's difficult to get lots of these numbers, unfortunately, because it > : takes a good 6-8 hours just to complete one build. But the numbers are > : fairly consistant across the different degrees of old crappy hardware I > : have. > > So you are seeing a about an hour slowdown (16% slowdown on 6 hours is > 1 hour) from before/after? Or are you seeing an hour slowdown from > 4.x -> 5.2-beta? I have two 5.x systems, both with dynamic / that were built within the past month. One's a bit older, probably a month or so, as I was waiting for the statfs changes to settle before upgrading it. The other was built about 3 days ago. The first one is pretty old, I only use it for a firewall because no one will let me spring for a replacement: CPU: Pentium II/Pentium II Xeon/Celeron (399.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff real memory = 66977792 (63 MB) avail memory = 60477440 (57 MB) ad0: 19470MB [39560/16/63] at ata0-master UDMA33 This machine usually takes 10-12 hours to do a full buildworld with -j 3 (which somehow seems to be the fastest). With static /bin/sh it was took just about an hour and a half less, but again, I could only do one pair since that took the whole day :) The other is slightly better and is my personal FreeBSD workstation, which I run -CURRENT on for test purposes and cuz I like it better :) CPU: AMD-K7(tm) Processor (499.04-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x612 Stepping = 2 Features=0x81f9ff AMD Features=0xc040 real memory = 335478784 (319 MB) avail memory = 316243968 (301 MB) ad0: 16603MB [33735/16/63] at ata0-master UDMA66 This one completes a buildworld in about 7-8 hours, the static /bin/sh run took about an hour less. I posted those numbers here earlier. I don't have any decent hardware running 5.x, all the new machines in real user are still using 4.8, so these are the only numbers I can come up with. Again, I *like* the ability to have NSS in /bin/sh, and the idea of dynamic linking in general appeals to me. The hour to hour-and-a-half slowdown might seem huge, but `make buildworld` really is the worst case scenario I could come up with, and 15% slowdown in the *worst* real-world case is certainly much better than 40%. --Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
* Garance A Drosihn <[EMAIL PROTECTED]> [031126 06:56]:
> At 12:23 AM -0500 11/26/03, Michael Edenfield wrote:
> >
> >Just to provide some real-world numbers, here's what I got
> >out of a buildworld:
>
> I have reformatted the numbers that Michael reported,
> into the following table:
>
> >Static /bin/sh: Dynamic /bin/sh:
> > real385m29.977s real455m44.852s => 18.22%
> > user111m58.508s user113m17.807s => 1.18%
> > sys 93m14.450s sys 103m16.509s => 10.76%
> > user+sys => 5.53%
Since I forgot to include this information (sorry!):
Both runs were done by doing:
rm -rf /usr/obj
sync
script
cp -f /bin/sh.{dynamic,static} /bin/sh
file /bin/sh
time make -j 4 buildworld
They were on a single CPU Athlon 500 with 320MB of RAM. I actually
don't normally do -j 4 on this system, only -j 2, but I'm use to
building on the dual Athlons we use to make production kernels and it
slipped in. Since it takes hours to run once it's started I just let it
run. :)
--Mike
pgp0.pgp
Description: PGP signature
Re: df: negative overflow?
* Melvyn Sopacua <[EMAIL PROTECTED]> [031126 13:23]: > /dev/ad0s2e ? 989M ? 947M -36.4M ? 104% ? ?/var This is normal. Each filesystem has a chunk of reserved space for root-only, for disaster recovery and such. Your /var filesystem is full, and has begun overflowing into that reserved space by 36.4MB. Essentially, there is no free space left in the file system, and you must get rid of 36.4MB of data before you can begin to get any free space. --Mike pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
* M. Warner Losh <[EMAIL PROTECTED]> [031126 14:51]: > In message: <[EMAIL PROTECTED]> > Michael Edenfield <[EMAIL PROTECTED]> writes: > : They were on a single CPU Athlon 500 with 320MB of RAM. > > 320MB is not enough RAM not to swap. > > However, having said that, I think everybody realizes the following: > > 1) Dynamic linking is slower. > 2) Speed improvements in this area are possible, as > demonstrated by other projects. > 3) PIC code is slower than non-PIC code, in general, and also > gcc runs about 5-10% slower depending on if you are running > out of a shared library or a static one. shared libraries > must use PIC code (at this time). > 4) People like to complain. Just for the record, I've been running WITH_DYNAMICROOT since nearly the day it came out and don't *notice* any problems. Mostly because the noise of dynamic linking overhead gets lost in the noise of "my hardware sucks so bad I have to take a vacation during buildworlds." My startup takes upwards of 5 minutes anyway, another 45 seconds won't even make me blink. I'm certainly not complaining about the performance :) I only posted those numbers to: 1) Give real world numbers, not "interesting but unrealistic numbers" 2) Show that even worst-case numbers weren't on the level of 40% slowdown. 3) Hopefully help someone figure out where to best improve the dynamic linker. --Mike pgp0.pgp Description: PGP signature
Re: Turkeys and dynamic linking
* Kent Stewart <[EMAIL PROTECTED]> [031127 17:50]: > On Thursday 27 November 2003 12:31 pm, Bill Moran wrote: > > walt wrote: > > > To all of you who celebrate Thanksgiving today, I wish you a happy one! > > > > > > And speaking of turkeys, does anyone know how Microsoft handles the > > > performance issues associated with dynamic linking? Do they do > > > anything special, or just ignore the whole thing? > > > > Don't they fix the performance hit by moving performance-critical parts > > of the application into kernel space (such as IIS and MSSQL)? > > > > At least, that's what Eric Raymond claims in his latest book. I don't > > think that's an approach I would like to see FreeBSD take. > > It all depends because if you only have 1 dll loaded for multiple > applications, which is one of the features I understand is built into > Windows, you have real savings. You share the code and own the data. Windows' dynamic linker works in a similar way to what Apple does in terms of sharing dll code. It makes an attempt to load libraries at the same base address in all processes, so that one DLL can be easily mapped into multiple processes. When you build a DLL, you supply a "preferred address" where it should be loaded. If Windows can load the library there, it does so. It also tries to load DLL's in thh same order each time. Since every process in the system likely relies on kernel32.dll, and probably user32.dll and gdi32.dll and others, Windows is almost always able to put those libraries at the same place in each process. So it doesn't have to read kernel32.dll from disk, since the OS itself has it loaded from the beginning. It just needs to do the fixups. For user-defined libraries, there's a decent chance that the same thing will happen. If not, then you have to pay the penalty to remap the library from scratch into a new location. As far as moving things into the kernel, I'm not sure what ESR is referring to. It's easy to get code into kernel-space by making it a device driver, but AFAIK SQL Server code comes all from normal DLL libraries, all in user space. --Mike pgp0.pgp Description: PGP signature
Re: 5.2-BETA and related ports issues
* Robert Watson <[EMAIL PROTECTED]> [031130 11:36]: > > On Sun, 30 Nov 2003, Andreas Klemm wrote: > > > I have a better idea, then we perhaps need something like a wrapper > > script that is part of the FreeBSD basic system under /etc/rc.d that > > checks for the start script under $LOCALBASE/etc/rc.d and starts it very > > early. > > Hmm. I talked with Gordon about this issue some last night, but he > pointed out a snag: most installs of FreeBSD place /usr on a separate > partition from /. The rcNG ordering decision is made before /usr is > mounted, as /usr is mounted as part of the pieces kicked off by rc.d. So > it would be a fairly large departure from the current implementation of > the rcNG code to reevaluate the ordering once more directories were > available in which to find scripts to run. Not that it's not doable, but > we need to think about it carefully (and, unfortunately, it's not as easy > as simply adding /usr/local/etc/rc.d to the list..) Having wrapper Since this issue only comes up for a small number of ports, mostly those ports which can behave as back-end services for things that are in the base, wouldn't in be sufficient to have certain checkpoints in the rcNG code that simple scanned for and ran anything in a given location? You wouldn't need to reorder anything, simply have clearly defined "pre-whatever" or "post-whatever" steps that did something like: for i in `grep "RUNAT: post-mount-usr" /usr/local/etc/rc.d/*.sh` ; do [ -x $i ] && sh $1; done --Mike pgp0.pgp Description: PGP signature
Re: policy on GPL'd drivers?
* Scott Long <[EMAIL PROTECTED]> [030527 23:51]: > >I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not > >uncommon that they require reinstalling after an upgrade. I have > >experienced kernel panics on several occasions from out of date vmware > >kernel modules. > > I'm really of the opinion that these ports should either live in the > sys/ tree, or that magic should be devised to make sure that they are > built along with the rest of the modules. Wouldn't it be sufficient to simply install the port modules into /boot/kernel instead of /usr/local/wherever/it/goes/now? I understand why most aren't put there now, due to the seperation of base system from ports etc. But I would the benefits of violating that principle outweigh the detriments: each time you reinstall your kernel, /boot/kernel is moved out of the way... taking all the outdated modules with it. Your port modules would fail to load, not being in the right place, but that's far better than a panic. --Mike pgp0.pgp Description: PGP signature
Re: Libthr stable enough for testing
* James Tanis <[EMAIL PROTECTED]> [030529 17:18]: > How does one go about using libthr? Is all that is > involved is symlinking libc_r to libthr? That's the easiest way. You can also explicitly link applications with -lthr instead of -lc_r. And since libthr and libc_r are both 6 characters long, you could also use ed/sed/etc. to s/libc_r/libthr/ in the executable itself. Also, there is a patch (I think it's still a patch) floating around the mailing list archives to use an external config file so you can replace the threading library at run-time per-executable. --Mike pgp0.pgp Description: PGP signature
Re: Unkillable processes with libKSE
* Wesley Morgan <[EMAIL PROTECTED]> [030624 12:45]: > Thought I would give libKSE a try making use of the 'libmap.conf' library > translations. KDE loads fine, but when I tried to run Firebird I get a > process with 3 threads, and it is completely unkillable. It also is I had the same experience just running the KSE test application from /usr/src/tools last night. I ended up with three unkillable ksetest applications and ultimately rebooted to get rid of them. I was planning to report it as soon as I finished reading my email :) --Mike pgp0.pgp Description: PGP signature
Re: Unkillable processes with libKSE
* Julian Elischer <[EMAIL PROTECTED]> [030624 14:47]: > > I had the same experience just running the KSE test application from > > /usr/src/tools last night. I ended up with three unkillable ksetest > > applications and ultimately rebooted to get rid of them. I was > > planning to report it as soon as I finished reading my email :) > > "Interesting".. > > I'll check on my testd machine.. > the test program responded to ^C as of a few days ago.. I just rebuilt my system to see if the problem had perhaps been solved, but it's still doing it. It doesn't cause any problems (the process doesn't look like it's doing anything, just not going away) so I am gonna just let the processes sit there. [EMAIL PROTECTED]:/usr/src/tools/KSE/ksetest# ./ksetest main() : 0x804c000 eip -> 0x280c06b3 uts() at : 0x8048e20 uts stack at : 0x814d000 - 0x8155000 main() : 0x804c400 eip -> 0x280c06b3 uts() at : 0x8048e20 uts stack at : 0x8255000 - 0x825d000 thread_start() : 0x804c800 804c800 thread_start() : 0x826d000 826d000 kse_create() -> 0 +-kse_create() -> -1 main() : 0x826d800 eip -> 0x280c06b3 uts() at : 0x8048e20 uts stack at : 0x837e000 - 0x8386000 main() : 0x826dc00 eip -> 0x280c06b3 uts() at : 0x8048e20 uts stack at : 0x8486000 - 0x848e000 thread_start() : 0x848e000 848e000 thread_start() : 0x848e800 848e800 thread_start() : 0x84af000 84af000 kse_create() -> 0 A*.kse_create() -> -1 [...] *R*.S.*T*.^C^D^Z (no response on this tty, so I close it). On another tty I get this: [EMAIL PROTECTED]:/home/kutulu# ps x | grep ksetest 30947 p2 RL-0:00.12 ./ksetest 30947 p2 RL-0:00.12 ./ksetest 30947 p2 TL-0:00.12 ./ksetest [EMAIL PROTECTED]:/home/kutulu# kill -KILL 30947 [EMAIL PROTECTED]:/home/kutulu# ps x | grep ksetest 30947 p2 RL-0:00.12 ./ksetest 30947 p2 RL-0:00.12 ./ksetest 30947 p2 TL-0:00.12 ./ksetest [EMAIL PROTECTED]:/home/kutulu# top [...] 30947 root 760 5760K 628K WAIT 0:00 0.00% 0.00% ksetest 30947 root 80 5760K 628K RUN 0:00 0.00% 0.00% ksetest 30947 root 80 5760K 628K RUN 0:00 0.00% 0.00% ksetest [...] I don't have DDB in this kernel at the moment (it's remote and I prefer the crash dumps) but I can put it in and try again if there's something you can use from it. --Mike pgp0.pgp Description: PGP signature
Re: Unkillable processes with libKSE
* Julian Elischer <[EMAIL PROTECTED]> [030624 19:01]: > As of last testing (yesterday my laptop (non SMP) acted the same.. > > I'm not sure what to suggest. > can you confirm that you are running the newest of everything.. > (though as far as I know it was ok, even several weeks ago). I'll re-cvsup and rebuild everything tommorrow. (Right now I'm getting the bluetooth build error that was fixed this afternoon.) Perhaps something wasn't rebuilt when I thought it was. --Mike pgp0.pgp Description: PGP signature
no more unkillable kse threads.
Just an FYI: After doing a rebuild of my kernel/world over night I can no longer reproduce the unkillable 'ksetest' program problem. I didn't apply any of the signal handling patches or anything special, so I guess something was just flukey with my setup. Thanks! --Mike pgp0.pgp Description: PGP signature
