FreeBSD running slow and I suspect it's something I did
 

Greetings fellow FreeBSD users. I installed FreeBSD 5.3 a while back on a machine and hadn't really used it much since...for a few months at least. However, recently I decided to pick up where I left off on this. I am noticing things are running fairly slow. And one of the last things I did prior to leaving the machine alone was recompile the kernel. And a while back, I seem to recall reading somewhere that if a person did not enable something in the kernel recompile, it would slow down performance, but I can't recall what it was or where I read it. I know it's not the machine. I have a 3.06 Ghz P4 with 1 GB of DDR. I really don't want to reinstall. Had hoped one of you might be kind enough to offer some suggestions.

$ uname -a
FreeBSD .xyz.net 5.3-BETA5 FreeBSD 5.3-BETA5 #2: Mon Oct 25 18:05:15 PDT 2004 root@.xyz.net:/usr/src/sys/i386/compile/MYKERNEL i386

Thanks in advance. Been out of the FreeBSD world for a little while. I'm a bit foggy. So if I have asked a question that has a obvious answer, I apologize.

First thing I would do is cvsup the source using RELENG_5_3, and rebuild everything using the GENERIC config. See the Handbook for the steps. Then cvsup the ports and portupgrade those. You're running an old beta.

Appreciate the advice -X-. I did recently update my ports and did a portupgrade after. However, now that you mention it, I'm running cvsup again. After it is done, I'm going to rebuild world. That handbook does most certainly come in handy.

Alright. Seems to have helped...not as much as I had hoped. But I do notice a difference. Interesting thing is:

$ uname -a
FreeBSD .xyz.net 5.3-BETA5 FreeBSD 5.3-BETA5 #0: Sat Jan 15 17:29:58 PST 2005 root@.xyz.net:/usr/obj/usr/src/sys/MYKERNEL i386

I had thought the whole "Beta 5" thing would have gone away. However, I am #0 now, instead of #2. Had never gone through that before (make buildworld..etc). It's always a suprise how easy things are in FreeBSD. Kernel compilation...syncing up your sources...it's always pleasant.

You didn't cvsup correctly if you are seeing BETA5 still. You should see FreeBSD 5.3-p4

What do you have in your supfile? Specifically, what is your tag?

Had wondered about that...which is why I brought it up. from supfile:

# IMPORTANT: Change the next line to use one of the CVSup mirror sites
# listed at http://www.freebsd.org/doc/handbook/mirrors.html.
*default host=cvsup10.us.freebsd.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_5_3
*default delete use-rel-suffix

*default release=cvs tag=RELENG_5_3

I would break this into two lines:
*default release=cvs
*default tag=RELENG_5_3

And redo the cvsup. How did you do the make world and all. I recommend the following.

# make buildworld
# make kernel ---- this will default GENERIC which you want
# make installworld
# mergemaster

Then reboot.

Thanks for the quick response. Much appreciated. Giving your advice a go now. Will report back shortly.

Strange. Well, there is no question that I see a change in performance. However, uname still has pretty much the same output:

FreeBSD .xyz.net 5.3-BETA5 FreeBSD 5.3-BETA5 #1: Sat Jan 15 23:47:42 PST 2005 root@.xyz.net:/usr/obj/usr/src/sys/MYKERNEL i386

I do notice one key difference between your recommended course of action and the method I have used. After the steps you mentioned (in which I have used a preconfigured kernel file) I:

reboot
mergemaster -p
make installworld
mergemaster
reboot again

I left defaults on mergemaster and I am starting to think that is why uname has the same output.

First thing, I don't live on this thing! Usually get up about 4:30, check things while getting a little java, before going out out for a jog! :)

Anyway, should have gotten rid of the beta debug stuff which will speed things up. That 'MYKERNEL' thing bugs me. I don't think mergemaster has an effect.

Look in your /usr/src/UPDATING just to make sure you have the latest. Try the below and reboot and report back. That should use the GENERIC config.

Procedure 2. Building a Kernel the ``New'' Way
Change to the /usr/src directory.
# cd /usr/src
Compile the kernel.
# make buildkernel
Install the new kernel.
# make installkernel

Your routine is similar to mine -X- minus the jog. And again, appreciate the help. They "MYKERNEL" deal is due to me using my own custom kernel. For /usr/src//UPDATING

make buildkernel KERNCONF=YOUR_KERNEL_HERE
make installkernel KERNCONF=YOUR_KERNEL_HERE

This is where I had utilized my prior customer kernel configuration (called MYKERNEL...called such from following the example in the handbook verbatim for creating your own custom kernel).

I can use the GENERIC config. Matter of fact, during our little go about here I did once. I still had the whole beta thing and my sound card did not work, so I went back to using the configuration I had made prior (using generic as my example and just editing as needed for atapicam and sound).

However, I'm willing to give it another try. Rather enjoying the experimenatation really. However, I have not fully engaged in my own routine here. In other words, I haven't had any coffee and I'm hungry.

4:30 on weekends? Wow. You have me beat there. I won't get up that early even when I go to work.

Don't know why and never had any problems with sound on previous versions, but I did with 5.3. The kldload would load it (can't remember now) in a wrong order of kldstat, and compiling in the kernel didn't help.

Ended up with /usr/local/etc/rc.d/start.sh script.
#!/bin/sh
# start
if [ "x$1" = "x" -o "x$1" = "xstart" ]; then
echo "Starting sound ...................."
kldload sound
kldload snd_mss
elif [ "x$1" = "xstop" ]; then
# never got this done.
fi

Anyway, that beta thing sounds like it is coming from your 'old' 5.3-beta kernel config. Other than that, post back and we'll look around.

Got some real gurus around here that can solve anything.

The BETA5 is found in /usr/src/sys/conf/newvers.sh

For some reason the cvsup is not working.

Clark Bent can you run "head -n 20/usr/src/UPDATING" and post the 20 lines you get here? Just as a sanity check.

Edit: That file (newvers.sh) is updated when a version is changed in any way... and it propagates the proper tags throughout the kernel source. Currently it should have somewhere in it. But I am betting it doesn't.

Clark... this is NOT the file you are checking... so your output will not look like this. I'm checking an easier file to see if the tree is up to date.

Yeah, that's a good idea checking both files.

Just for grins, here's my os sup file which always works, just change the tag.

*default host=cvsup10.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_5_3
*default delete use-rel-suffix
# If you seem to be limited by CPU rather than network or disk bandwidth, try
# commenting out the following line. (Normally, today's CPUs are fast enough
# that you want to run compression.)
*default compress
## Main Source Tree.
#
# The easiest way to get the main source tree is to use the "src-all"
# mega-collection. It includes all of the individual "src-*" collections.
# Please note: If you want to track -STABLE, leave this uncommented.
src-all

Note:
Seeing this, make sure you have the src-all.

Interesting. Well here we go:

$ head -n 20 /usr/src/UPDATING
Updating Information for FreeBSD current users

This file is maintained and copyrighted by M. Warner Lo
sh
<imp@village.org>. See end of file for further details
. For commonly
done items, please see the COMMON ITEMS: section later
in the file.

Items affecting the ports and packages system can be fo
und in
/usr/ports/UPDATING. Please read that file before runn
ing
portupgrade. Important recent entries: 20040724 (defau
lt X changes).

20040914:
The format of the pflogd(8) logfile "/var/log/pflog" has changed for
architectures that have a 64 bit long type to make it compatible to
the standard pcap format. In order to prevent corruption move away
any old logfile before using a new pflogd(8).

20040913:
debug.witness_* has been renamed to debug.witness.*. There are
compatibility tunables left in for a few days. Update loader.conf
as necessary.

code:

TYPE="FreeBSD"
REVISION="5.3"
BRANCH="BETA5"
RELEASE=5.3-BETA5
VERSION="${TYPE} ${RELEASE}"


Hmmm. I'm not understanding what I am doing wrong. But it looks like you two must be correct in your assesment. From portsupfile:

code:

# IMPORTANT: Change the next line to use one of the CVSup mirror sites
# listed at http://www.freebsd.org/doc/handbook/mirrors.html.
*default host=cvsup10.us.freebsd.org
*default base=/var/db
*default prefix=/usr
*default release=cvs
*default tag=RELENG_5_3
*default delete use-rel-suffix

# If you seem to be limited by CPU rather than network or disk bandwidth, try
# commenting out the following line. (Normally, today's CPUs are fast enough
# that you want to run compression.)
*default compress

## Ports Collection.
#
# The easiest way to get the ports tree is to use the "ports-all"
# mega-collection. It includes all of the individual "ports-*"
# collections,
ports-all



I am just running command:

sudo cvsup -g -L 2 portsupfile

I'm not root when I do it (obviously thus the sudo). It runs for a while and seems to finish fine. I have ran cvsup like 6 times now. I do notice though again, you must be on to something because /usr/ports is looking mighty thin. There is hardly anything in there. Perhaps I should just toast the portsupfile and start again.

Ah... change the ports-all to a src-all

You are updating your ports tree to RELENG_5_3 -- which doesn't exist and likely wiped everything out or did nothing at all... whichever is more anoying... probably the delete.

Then run the same command again... with the "src-all" instead of the "ports-all"

Notice anything stange?

edit:
guru frob23 to the rescue!

I always seperate my cvsup.os and cvsup.ports files. Here's my cvsup.ports file that I use with a refuse file.

*default host=cvsup17.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=.
*default delete use-rel-suffix
# If you seem to be limited by CPU rather than network or disk bandwidth, try
# commenting out the following line. (Normally, today's CPUs are fast enough
# that you want to run compression.)
*default compress
## Ports Collection.
#
# The easiest way to get the ports tree is to use the "ports-all"
# mega-collection. It includes all of the individual "ports-*"
# collections,
ports-all

Thanks again -X-. And just for grins, as you have suggested, I have copied your os sup file verbatim. Not sure what you meant by change the tag, unless you were pointing out what was mentioned prior...
code
default realease=cvs
tag=RELENG_5_3

If for some reason, this go around doesn't work, I'll try that next. I guess any improvements I thought I saw must be purely wishful thinking at this stage.

"Whichever is most annoying." Got a good chuckle out of that. Yes. I see what you mean. And right now, I do see a difference already just examining the output. It seems to be taking much longer. So perhaps this will do the trick this time.

Glad you mentioned that. That makes perfect sense. After I get done with this little exercise, I can see I need to upgrade my ports again (for real this time).

I use the same cvsup file and change the tag when I upgrade to a different version, that's all. Also, I have different cvsup files for os, ports, docs that let me update what and when I want to and avoid this type of problems.

See my edit on a previous post. Thought I'd get it in there before you posted again, otherwise I would have made a new post.

See, told you some guru would come along and find what the problem is!

Glad you're off on the right track!

Glad we are on the right track too. Interesting mysterious problem...or so I thought. Grateful to you both. I think I have learned more in these posts/exercise than I have in quite a while. Yes frob23 does appear to have the guru gleam to him doesn't he?

lol... not so sure I want to snatch the label guru just yet. Maybe a little experienced because I have made similar mistakes in the past (once confused my supfiles and wiped out my ports tree... while upgrading to current... which was something I wasn't expecting). ;)

I keep them seperate as well.
/root/srcup -- my scr supfile
root/portsup -- my ports supfile.

Once you create them it is a cake-walk to upgrade the source. And upgrading a version is just an edit away... like -X- said.

Been a pretty good exercise for me to. Posted more today that the last few weeks combined. yeah, frob23 is good to have around.

You have to remember... FreeBSD has been my only operating system for over five years. If I didn't have some idea of how it worked I would be in trouble. :p

I think this will be a good valuable thread for people. I know I'll use it again. Having said that, just for the curious, even though I was on the wrong track I do have a couple of questions:

1. I wonder why I went from FreeBSD .xyz.net 5.3-BETA5 FreeBSD 5.3-BETA5 #2 to FreeBSD .xyz.net 5.3-BETA5 FreeBSD 5.3-BETA5 #0. From two to zero. Just curious there.

2. Is there a reason why I would not want to stick with my own custom kernel config? Again, I have been away from FreeBSD for a while, but back when I was using it quite a bit, you had to recompile the kernel to get sound to work and cd burning.

Running buildworld now.

The only thing I can think of is that you used the old method to install the #2 (and #1 and original #0) kernels but the new method when you installed this one. The old method creates a folder /usr/src/sys/i386/compile/KERNNAME

Somewhere in this folder... something allows the build process to bump the build number. Sorry for being non-specific. I'll need to hunt it up in a couple minutes. But the new method builds in /usr/obj (which is why it needs to be populated) and thus the old versions weren't seen to be bumped.

The custom kernel thing is weird right now. It is nice to remove stuff you don't need but not needed if you want to add stuff as all the drivers are built as modules (if they aren't in the kernel) and can be selected and loaded at boot time or any time after boot.

So, to enable sound you just tell the kernel to load a module at boot and you won't need to recompile it.

I think your on to something frob23. I did in fact, when I compiled the MYKERNEL kernel, do it old style. Wow. Amazing you knew that.

lol... maybe.. just maybe... I might earn that guru title someday. :p

Tooling around in the kernel is something I get a kick out of. I am trying to figure out how exactly the version gets put there each time (I know it is retained... but I need to find where) it is going to take a few minutes because these recursive makefiles can be a bear to wade through. But you've got me interested.

Well, and here is something that most likely won't suprise. Or perhaps it might. But I finished the make buildworld and moved on to the make buildkernel. But unlike previously, it would not let me use the old custom kernel configuration I had prior. I had to use Generic. No big deal there. I can always go back and make any changes I want later. It's so easy to do. But I thought that was interesting. When I tried to use the MYKERNEL config I had prior, it errored out on me. Used GENERIC and it's compling away as I type.

That would seem logical in my mind because I would suspect the sources are different. And since I have a real source update that worked this time, I have a error. Since I didn't have in the past it worked. Is that correct?

Yep... the options the kernel takes are different. If you look through /usr/src/UPDATING it lists all the various kernel options that have changed... there are several. Any one of them could have been causing the problem.

lol... oddly enough the file is called "version" and it kept in the build directory... along with the depends even after a make clean. Which is how it can bump the number. I wiped the directory completely off the drive so this wasn't as simple as just looking for a version file.

Anyway... like I said... the old method and the new method both use different build directories and this is why the number went down to #0 instead up up to #3.

I had the same custom kernel problem and did a diff on mine and the GENERIC config and found a bunch of changes. Like Clark, I couldn't use mine and had to use the GENERIC. Actually all I had in mine was sound drivers, which wasn't the problem anyway. As I said, the only way I could get sound working was put a script in /usr/local/etc/rc.d/.

frob; do you see any performance difference with 5.3?

I went from 5.2.1 to 5.3 and at times see a lag in processes. Just every once and a while. I'm sure it's with the scheduling, which I know they are still working on. But this is on an old 500/256.

Other than that everything is fine and real stable.... which is what you expect from FBSD.

YEAH!

FreeBSD .xyz.net 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #1: Sun Jan 16 12:22:11 PST 2005 root@.xyz.net:/usr/obj/usr/src/sys/GENERIC i386

Thanks guys! Now I just need to get my sound working again and a few other changes and I am off. That was a good experience. I haven't had a good challenge like that in a while.

Well the sound was easy. Still don't see a big performance boost though. Perhaps that is just how it is? Or...perhaps I will once I do the portupgrade.

Well, the surest way to enable sound is "kldload snd_driver" as that loads all the drivers for all the chipsets. It's probably not what you want though. What you need to do is load that at boot and see what hardware it actually detects.

Add the line ' snd_driver_load="YES" ' to /boot/loader.conf

For example, my computer prints out this "pcm0: <AudioPCI ES1371-B>" as part of dmesg so I know that I only need to load the drivers for that support.

So I delete the original line and put these two in its place because they provide all the stuff my kernel needs for sound.

sound_load="YES"
snd_es137x_load="YES"

As for the performance of the whole 5.x series. I do notice that it is a little bit slower than the 4.x series. Not too much. I'm not sure about going from 5.2.1 to 5.3 because I noticed a fairly good increase when the debugging code was turned off.

Right now I am running a custom kernel (I know... after saying GENERIC should be fine, I do run my own kernel) because I wanted to strip out what I didn't need. If you are comfortable with the kernel config file then you might want to open a copy of your latest dmesg in one window and comment out the drivers you don't need from a copy of GENERIC just to trim down on the space.

To be honest... I don't really notice that much of a lag even though I hear people with much better systems talking about it and people with slower systems mentioning it. My computer was having tons of trouble with 5.2.1 -- I think I submitted four or five different kernel panics related to different issues (3 of them Nvidia related but that is somewhat expected in times of serious change with a binary driver).

One thing I did just realize, which was rather obvious is SMP is not enabled in the generic kernel. Since I have P4 with hyperthreading, I'm pretty sure you have to have SMP enabled for the hyperthreading to work. So I just enabled SMP in the kernel and gave it whirl. We will see if it makes a difference. Updating to the release version of 5.3 rather than the beta may have helped a little. Since I have had a week to chew on it and use it, I have a pretty solid idea. But not much of a improvement. Hopefully the SMP will help.

For some reason, FreeBSD has always ran a bit slower than Linux to me. Perhaps that is just my imagination. I like FreeBSD. I might even like it better than Debian...which is saying a lot as I love Debian.