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.