Date: Thu, 20 Mar 2014 18:08:22 -0700 From: Waitman Gobble <gobble.wa@gmail.com> To: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: kernel config:advice Message-ID: <CAFuo_fzK=ksNFK8sLHEZEsEMJVb=7cDDyawCYfVJ74GtHb9EDw@mail.gmail.com> In-Reply-To: <20140321002111.GB18540@neutralgood.org> References: <532B6E81.60604@tysdomain.com> <20140321002111.GB18540@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 20, 2014 at 5:21 PM, <kpneal@pobox.com> wrote: > On Thu, Mar 20, 2014 at 06:41:05PM -0400, Littlefield, Tyler wrote: > > hello: > > My kernel that is running currently is a bit large and has a lot of > > support for hardware I do not use. Here is my kernel config: > > What, is your machine memory constrained? The generic kernel is, what 12MB > in size? It's a bother using a custom kernel, and I wonder if it is really > worth the trouble. As someone who used to compile custom kernels for fun > I have to say I wouldn't bother with it today. > > As far as I know the biggest reason to have a custom kernel is if you > want to use ipsec. But don't hold me to that. > > > #device mps > > You commented out the mps driver. > > > #device scbus > > This is part of the CAM subsystem. Since you are getting compilation errors > from that subsystem I suggest putting this device back into your config. > This goes double when the commented out device is actually mentioned in > your dmesg log. > > > errors: > > tws_cam.c:(.text+0x1093): undefined reference to `xpt_done' > > tws_cam.o: In function `tws_scsi_complete': > > tws_cam.c:(.text+0x196d): undefined reference to `xpt_done' > > tws_cam.o: In function `tws_timeout': > > tws_cam.c:(.text+0x1afb): undefined reference to `xpt_freeze_simq' > > tws_cam.c:(.text+0x1b92): undefined reference to `xpt_release_simq' > > Come to think of it, it makes more sense to start with a full GENERIC > config and then gradually remove devices. That way if you get an error > compiling/linking you know where to look. Haphazard scattershot changes > just leaves you with a mess. > > > (probe2:mps0:0:2:0): INQUIRY. CDB: 12 00 00 00 24 00 > > (probe2:mps0:0:2:0): CAM status: Invalid Target ID > > (probe2:mps0:0:2:0): Error 22, Unretryable error > > Seems like if you have an mps controller you will need that mps device > that you removed. Otherwise the kernel won't be able to talk to your disks. > > > da0 at mps0 bus 0 scbus0 target 0 lun 0 > > Here's that mention of scbus. Removing this from your config is probably > the problem. > > > Does anyone see any issues with this? I am unable to compile. While I am > > not trying to trim out everything, I'd really just like to have this > > customized for my hardware (this is a dedicated server). I'm going to be > > putting a lot of load on this server and wanted to do what I could to > > minimize unwanted overhead (if any really). > > I really doubt you will see any real benefit from this. The kernel just > isn't that large by today's standards. If it did eliminate any overhead, > and that overhead mattered, then your machine is waaay too close to the > limit already and should be upgraded now. > > -- > Kevin P. Neal http://www.pobox.com/~kpn/ > > "Good grief, I've just noticed I've typed in a rant. Sorry chaps!" > Keir Finlow Bates, circa 1998 > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > are these useful without ata devices? options ATA_STATIC_ID options ATA_CAM do you really have all those RAID controllers also no agp on that machine the intel em NIC doesn't use miibus you should probably make a copy of GENERIC and name it something else. It's a good idea to copy GENERIC somewhere, then copy that copy to the same name as your IDENT. then /*link*/ that copy back into src. you would probably be happier running 10.0-RELEASE if you look at your dmesg you can see which drivers you need without guessing. also check out MODULES_OVERRIDE in /etc/make.conf.. using this can greatly speed up a kernel build. -- Waitman Gobble San Jose California USA 510-830-7975
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFuo_fzK=ksNFK8sLHEZEsEMJVb=7cDDyawCYfVJ74GtHb9EDw>