Moo VI (Or even more kernel tinkering)

[buzzy]

After lots of tinkering with my Kubuntu machine's kernel, I think I got it to a good state for what I want to use it for. I basically removed everything that I knew for sure wasn't needed, then whittled away the rest. When I was comfortable with that, then I looked at the output from dmesg to see if there were any errors or general weirdness. Most of those were cleared out by removing offending parts of the kernel that it turned out I didn't need. In the end, my computer boots about 10% faster than it did before I started tinkering, and I think that's pretty awesome. After all that work, I found I still had a few problems, or things that look like problems. Here's a few of those things:

 1. [    0.000000] [Firmware Warn]: MTRR: CPU 0: SYSCFG[MtrrFixDramModEn] not cleared by BIOS, clearing this bit
 2. [    0.000000] ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20120320/tbfadt-579)
 3. [    0.000000] spurious 9259A interrupt: IRQ7
 4. [    0.000000] Marking TSC unstable due to TSCs unsynchronized
 5. [    0.185259] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
 6. [    0.237719] ACPI _OSC control for PCIe not granted, disabling ASPM
 7. [    1.004572] composite sync not supported
 8. [    1.084254] ahci 0000:00:12.0: controller can't do 64bit DMA, forcing 32bit
 9. [    1.545039] ata1: softreset failed (device not ready)
10. [    1.545044] ata1: applying PMP SRST workaround and retrying
11. [    1.706202] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
12. [    1.414650] EDD information not available.
13. [    1.414650] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load.

• The first one (from looking around for information) is related to the motherboard or BIOS not correctly supporting MTRRs. It appears three times during the boot process. The only solution I found was to add nomtrr to the kernel line in Grub2, but that did nothing.
• I couldn't find anything applicable on the second one. People had that show up with strange ACPI problems, but I have no ACPI problems and it shows up. If it's optional, why is the kernel complaining? The same problem seems to affect FreeBSD, as a lot of the results I got from web searches are FreeBSD-related.
• The third one (from looking around for information) seems to be just an annoying message that can be ignored.
• I couldn't find information about the fourth one. I saw at least one other person with the same message, but no one responded to him/her and that was four years ago.
• The fifth one was the first one that I found an actual solution for on a forum. Too bad they adjusted the kernel so the solution stopped working over three years ago. Doing what that message says just gives me a different message in its place telling me to use "pci=nocrs" instead. This could be one of those things that it says that sounds like something is wrong, but everything is fine. (Regardless of whether I put "pci=use_crs" in the kernel line in Grub2, the computer acts the same.)
• The sixth one I fixed by just disabling "PCI Express ASPM control" (CONFIG_PCIEASPM) in the kernel.
• The seventh one appears a lot in the dmesg output once the Direct Rendering Manager starts up. The only way I found that got rid of the message (add "nomodeset" to the kernel line in Grub2) caused my resolution to be 1024x768 instead of 1280x800, which made everything look stretchy and blurry. I was unable to get it to see the monitor was capable of its native resolution. Disabling compositing in KDE didn't help either.
• The eighth through eleventh messages are related to the AMD SB600 southbridge used. (The northbridge is an AMD M690.) There's a wide variety of problems with it, but since AMD doesn't provide errata to Linux developers (because it would be public and they don't want people to see it), Linux can only work around the limitations. Just because my southbridge sucks doesn't mean I want to be reminded about it every time the system boots.
• The twelfth one has to do with Enhanced Disk Drive (EDD) calls...not the smartest of the Eds. To get rid of this and some surrounding messages, I turned off "BIOS Enhanced Disk Drive calls determine boot disk" (CONFIG_EDD) in the kernel configuration.
• For the thirteenth one, I turned off Error Detection and Correction reporting in the kernel configuration (CONFIG_EDAC). If it's not going to load, why have it in the kernel?

If you ask me, "Why don't you ask someone who knows about this stuff how to fix it?" That's a good question, but in my Google searches, I discovered that there are few nice people on these web forums. If you want to lose faith in humanity, those forums are a good place to start. When searching for answers to my own problems (some of which are posted here and others I fixed prior to starting this entry), I saw people taking a lot of flak for just asking a question. As the 23-page manual on how to ask questions in Linux forums says [yes, there's a manual for asking questions], If you're after information rather than entertainment, it's better to keep your fingers off the keyboard than to risk this. The author is talking about something else there, but it's in the same paragraph as ...you will occasionally run across rudeness and posturing that is quite gratuitous. What I saw was more than "occasionally". For some reason, the fancier the layout of the site, the less likely it was that there'd be jerks in the thread. That could just be coincidence. Anyway, I'm not taking my chances, so I'm just writing my thought process in here regardless of whether I actually fix anything. I'm my own forum and I don't badmouth any members. I'm keeping a lot of these Linux entries publicly accessible just in case anyone has something to add/is looking for a solution that I have.

After building my kernel so many times, the commands are second nature. Maybe not the part where you download the source and extract it, but definitely the configuration and build process is easy. (This is the eighth revision, though uname -a says it's only the sixth.) Anyway, after making all these changes, the kernel uses 89 less KiB of memory than the stock kernel and the vmlinuz is 193.9 KiB smaller than the stock kernel. That's not as much of an improvement as I had on some of the previous day's kernel configurations. It's weird that the kernel gets bigger and takes up more RAM when you take bits out. I guess that just means I need to do more tweaking!