| View previous topic :: View next topic |
| Author |
Message |
Ink_arni
n00b
Joined: 17 Jan 2008
Posts: 19
Location: Europe
|
 Posted: Fri Oct 17, 2008 6:11 pm Post subject: Multiple kernel config questions (weird ones!) |
 |
|
OK, I decided to play a little with my kernel configuration. I mostly use the stable gentoo kernels (been running linux-2.6.24-gentoo-r8 for almost 6 months), but I decided to try 2.6.26.6 vanilla. So far no problems, but I have some questions about various options that would potentially improve the experience:
- I use /etc/conf.d/consolefont to set nice, large fonts (in particular, terminus
 ) for my virtual terminals. However, changing the font (e.g. with "/etc/init.d/consolefont restart") causes a screen redraw, which means that when the consolefont service starts all the previous init messages cease to be visible. This is ugly and potentially dangerous (but mostly ugly  ).
I noticed during the kernel configuration that there are some options about which fonts will be embedded in the kernel, but of course terminus isn't among them. Is it possible to add an external font? Has anyone tried it? If not, do the spark fonts (which are supposed to be large) work on amd64 with VESA?
Alternatively, is it possible to eliminate the screen redraw when changing the font?
- There is an annoying five second delay during bootup, before the init invocation. Here is a part of the dmesg output:
| Code: |
[ 0.276257] fuse init (API version 7.9)
[ 0.276257] SGI XFS with security attributes, large block/inode numbers, no debug enabled
[ 0.277262] msgmni has been set to 4018
[ 0.277262] io scheduler noop registered
[ 0.277262] io scheduler cfq registered (default)
[ 5.789016] pci 0000:00:02.1: EHCI: BIOS handoff failed (BIOS bug?) 01010001
[ 5.789038] pci 0000:00:0b.0: Linking AER extended capability
[ 5.789041] pci 0000:00:0c.0: Linking AER extended capability
[ 5.789044] pci 0000:00:0d.0: Linking AER extended capability
[ 5.789047] pci 0000:00:0e.0: Linking AER extended capability
[ 5.789057] pci 0000:05:00.0: Boot video device
|
I tried changing some BIOS settings to no avail. (Other than GRUB not seeing my USB keyboard anymore, something that forced me to change them back!  )
Then I found this post, which suggests a slight modification of the kernel source code. Reading the source comments, it seems perfectly safe, however I haven't done something like this before. Any problems with that?
"Flat memory model" was selected (I think by default) in all my previous kernels. However, "sparse" is the only available option with 2.6.26.6. Is this OK? My system: CPU is Athlon64X2, socket type is 939 and chipset is nForce4.
And some less interesting ones:
- SLUB or SLAB?
Only kernel developers and low-level system designers seem to be capable of understanding what each one does! Trying both I saw no obvious differences. Which one is supposed to be faster? Which one is supposed to be more safe/stable?
- Os or O2? (CONFIG_CC_OPTIMIZE_FOR_SIZE)
Os definitely produces a smaller kernel and I've being using it without problems (in my make.conf too!), but I think that O2 is the default. I want your opinions!
(BTW, my CPU has 1MB L2 cache for each core. Back then it was considered fairly large, but by today's standards it is not.)
- Is it safe to mount filesystems with extended attributes (e.g. ACLs) with a kernel that does not support them? I usually compile the kernel without them since I don't use them, but I want to know in case I need to mount a filesystem that needs them. Will the kernel refuse the mounting?
(In case you haven't noticed yet, I am a Small Kernel Maniac™ )
PS.
@Pappy (in case he reads this): I usually use my own config from my previous kernels, but your kernel seeds are definitely an amazing idea! Very useful for new users. I tried them for 2.6.26.6. Still, a bit too fat for my taste.
PS2.
English is not my mother-tongue, so please be patient! |
|
| Back to top |
|
 |
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5999
Location: Pomona, California.
|
| Posted: Sat Oct 18, 2008 9:10 am Post subject: Re: Multiple kernel config questions (weird ones!) |
|
|
| Ink_arni wrote: | | I use /etc/conf.d/consolefont to set nice, large fonts (in particular, terminus ) for my virtual terminals. However, changing the font (e.g. with "/etc/init.d/consolefont restart") causes a screen redraw, which means that when the consolefont service starts all the previous init messages cease to be visible. This is ugly and potentially dangerous (but mostly ugly ). |
I just tried this. If you look at the /etc/conf.d/consolefont file, it tells you where you should go for your choice of fonts (/usr/share/consolefonts). Yes, Terminus (or a version thereof) is there...at least it was for me. Of course, I purposely installed Terminus, so you might have to do so as well. I'm also pretty sure if you google about for consolefonts, you'll find even more.
| Quote: | | Alternatively, is it possible to eliminate the screen redraw when changing the font? |
I don't think so. To my mind, the question would be why that happens in the first place. My first thought is you don't have your frame buffer set properly, but I'd have to see your .config to make sure. (Yes, that is an invitation)
| Quote: | There is an annoying five second delay during bootup, before the init invocation. Here is a part of the dmesg output:
| Code: |
[ 0.276257] fuse init (API version 7.9)
[ 0.276257] SGI XFS with security attributes, large block/inode numbers, no debug enabled
[ 0.277262] msgmni has been set to 4018
[ 0.277262] io scheduler noop registered
[ 0.277262] io scheduler cfq registered (default)
[ 5.789016] pci 0000:00:02.1: EHCI: BIOS handoff failed (BIOS bug?) 01010001
[ 5.789038] pci 0000:00:0b.0: Linking AER extended capability
[ 5.789041] pci 0000:00:0c.0: Linking AER extended capability
[ 5.789044] pci 0000:00:0d.0: Linking AER extended capability
[ 5.789047] pci 0000:00:0e.0: Linking AER extended capability
[ 5.789057] pci 0000:05:00.0: Boot video device
|
I tried changing some BIOS settings to no avail. (Other than GRUB not seeing my USB keyboard anymore, something that forced me to change them back! )
Then I found this post, which suggests a slight modification of the kernel source code. Reading the source comments, it seems perfectly safe, however I haven't done something like this before. Any problems with that? |
This happens with this machine as well, and also did so with Slackware. While it's bothersome, I figure I only boot this computer once a day (usually), so why worry about a boot issue? However, in the interest of figuring out if this will actually fix this issue, I'm willing to use my computer as a Guinea Pig. I'll let you know.
| Quote: | | "Flat memory model" was selected (I think by default) in all my previous kernels. However, "sparse" is the only available option with 2.6.26.6. Is this OK? My system: CPU is Athlon64X2, socket type is 939 and chipset is nForce4. |
I've experimented with both, and while I don't see a marked difference, I use sparse. With my amd64, it's the only option.
| Quote: | SLUB or SLAB?
Only kernel developers and low-level system designers seem to be capable of understanding what each one does! Trying both I saw no obvious differences. Which one is supposed to be faster? Which one is supposed to be more safe/stable? |
The only difference I've seen is that there seem to be more options to troubleshoot and monitor SLUB as opposed to SLAB. I use SLUB presently for that reason. Not that I like debugging messages turned on as a general rule, but if the need were to arise, I'd prefer to have the greatest available options for such.
| Quote: | Os or O2? (CONFIG_CC_OPTIMIZE_FOR_SIZE)
Os definitely produces a smaller kernel and I've being using it without problems (in my make.conf too!), but I think that O2 is the default. I want your opinions! |
NO NO NO! If you look, it warns you outright to NOT use optimize for size if you might have a broken compiler. Now "broken" can mean damaged from file corruption, or a buggy compiler (gcc-4.3.x). Also, it makes troubleshooting kernel problems more difficult. I tried it once, and it made my system unstable. I undid it, and things went back to normal. That is one of the settings I have had to change from every defconfig. It's annoying that they set that as default, when clearly, it can cause problems. Besides, what need is there for a more "compact" kernel? Considering the amount of real estate one gets with today's crop of hard drives, kernel size is completely irrelevant.
| Quote: | | @Pappy (in case he reads this): I usually use my own config from my previous kernels, but your kernel seeds are definitely an amazing idea! Very useful for new users. I tried them for 2.6.26.6. Still, a bit too fat for my taste. |
In the words of Dr. Frankenfurter, "I didn't build them for you."
Seriously, thanks for the vote of confidence. It is much appreciated.
I admit that I might go overboard with the crypto settings, my theory is it's better to have those things, and not need them, than to need them, and have to recompile a new kernel in the middle of an important project. I'd like to see what you come up with when you get your kernel .config done. I'd like to see how spartan a kernel can be made, and still be functional.
Oh, and by the way, your English is better than some I've read whose native tongue is English.
Blessed be!
Pappy
_________________
This space left intentionally blank, except for these ASCII symbols. |
|
| Back to top |
|
|
Ink_arni
n00b
Joined: 17 Jan 2008
Posts: 19
Location: Europe
|
| Posted: Sat Oct 18, 2008 1:05 pm Post subject: Re: Multiple kernel config questions (weird ones!) |
|
|
First of all, thank you for your prompt and thorough response!
I believe that pasting a 1662-line config file between code tags is ugly and reduces the readability of the thread, so I tried attaching the gzipped version, but I cannot find the attach option. Thus I've uploaded it here. (First time I use this service, I hope it is OK. I had to remove a single quote from line 2 to preserve syntax high-lightning. And yes, I know "bash" is not the proper high-lighting mode for kernel sources, but it suits them.)
| pappy_mcfae wrote: | | I just tried this. If you look at the /etc/conf.d/consolefont file, it tells you where you should go for your choice of fonts (/usr/share/consolefonts). Yes, Terminus (or a version thereof) is there...at least it was for me. Of course, I purposely installed Terminus, so you might have to do so as well. I'm also pretty sure if you google about for consolefonts, you'll find even more. |
Probably I didn't explain it well: I've already got consolefont working with Terminus. The question was whether it is possible to embed Terminus in the kernel, as a substitute of of the default font, so that it gets used from the start, before consolefont gets loaded! (Yes, I bit extreme, but I had hoped that it were possible to hack it without the kernel noticing.  )
| pappy_mcfae wrote: | | Quote: | | Alternatively, is it possible to eliminate the screen redraw when changing the font? |
I don't think so. To my mind, the question would be why that happens in the first place. My first thought is you don't have your frame buffer set properly, but I'd have to see your .config to make sure. (Yes, that is an invitation) |
I 'm using good, old (and slow) VESA, because:
- nVidia fb is supposed to be incompatible with the nVidia binary drivers.
- uvesafb is a PITA to set up. (And my TFT doesn't need more than 60Hz. )
| pappy_mcfae wrote: | | Quote: | There is an annoying five second delay during bootup, before the init invocation. Here is a part of the dmesg output:
| Code: |
[ 0.276257] fuse init (API version 7.9)
[ 0.276257] SGI XFS with security attributes, large block/inode numbers, no debug enabled
[ 0.277262] msgmni has been set to 4018
[ 0.277262] io scheduler noop registered
[ 0.277262] io scheduler cfq registered (default)
[ 5.789016] pci 0000:00:02.1: EHCI: BIOS handoff failed (BIOS bug?) 01010001
[ 5.789038] pci 0000:00:0b.0: Linking AER extended capability
[ 5.789041] pci 0000:00:0c.0: Linking AER extended capability
[ 5.789044] pci 0000:00:0d.0: Linking AER extended capability
[ 5.789047] pci 0000:00:0e.0: Linking AER extended capability
[ 5.789057] pci 0000:05:00.0: Boot video device
|
I tried changing some BIOS settings to no avail. (Other than GRUB not seeing my USB keyboard anymore, something that forced me to change them back! )
Then I found this post, which suggests a slight modification of the kernel source code. Reading the source comments, it seems perfectly safe, however I haven't done something like this before. Any problems with that? |
This happens with this machine as well, and also did so with Slackware. While it's bothersome, I figure I only boot this computer once a day (usually), so why worry about a boot issue? However, in the interest of figuring out if this will actually fix this issue, I'm willing to use my computer as a Guinea Pig. I'll let you know. |
I' try it as well, once I recompile my kernel (probably tomorrow). As I said, if you read the source, it seems 100% safe. And since my linux uptime varies from half an hour to a couple of weeks, I do care about boot time. I admit it, I'm dual-booting with a certain evil OS.
| pappy_mcfae wrote: | | Quote: | | "Flat memory model" was selected (I think by default) in all my previous kernels. However, "sparse" is the only available option with 2.6.26.6. Is this OK? My system: CPU is Athlon64X2, socket type is 939 and chipset is nForce4. |
I've experimented with both, and while I don't see a marked difference, I use sparse. With my amd64, it's the only option. |
With my amd64, both options were available. Not any more. Since you say it is safe, I am relieved. 
| pappy_mcfae wrote: | | Quote: | Os or O2? (CONFIG_CC_OPTIMIZE_FOR_SIZE)
Os definitely produces a smaller kernel and I've being using it without problems (in my make.conf too!), but I think that O2 is the default. I want your opinions! |
NO NO NO! If you look, it warns you outright to NOT use optimize for size if you might have a broken compiler. Now "broken" can mean damaged from file corruption, or a buggy compiler (gcc-4.3.x). Also, it makes troubleshooting kernel problems more difficult. I tried it once, and it made my system unstable. I undid it, and things went back to normal. That is one of the settings I have had to change from every defconfig. It's annoying that they set that as default, when clearly, it can cause problems. Besides, what need is there for a more "compact" kernel? Considering the amount of real estate one gets with today's crop of hard drives, kernel size is completely irrelevant. |
Os has been perfectly stable for me for months, if not years (I guess my gcc is not broken ). I even had the impression that O2 was the default, but oh well. I'll keep your post in mind in case I have problems.
Off-topic: I did have stability problems in the past, just not kernel-related. The problem was in my RAM. Compilation of certain large packages (only OpenOffice, Wireshark and GCC itself) with GCC (and only with optimization levels above -O1!) would trigger the problem, the result being a hard crash. Strangely enough, running memtest and memtester for 36 hours straight did not reveal any problems, so I thought it was a kernel or toolchain issue at first! But after changing the command rate to 2T the problems were solved. (I changed it back though, not being able to bear the thought of the performance penalty. That memory cost me more than 300€, no way I'm going to operate it with non-optimal settings! )
Oh, and hard drives may be large, but L2 cache is not.
(But I guess it doesn't make a huge difference.)
| pappy_mcfae wrote: | | I'd like to see what you come up with when you get your kernel .config done. I'd like to see how spartan a kernel can be made, and still be functional. |
Trust me, you will be disappointed. First of all, this particular kernel config is based on yours, minus some options I knew I wouldn't need (cryptography!), some logging options and extended attributes in filesystems. I also changed some k8-specific stuff, enabled Os and added latencytop support.
The end result is almost identical to my previous kernels, with some exceptions. Main differences:
- I added iptables support. I wasn't using it in the past, but I'll probably set up some rules when I'll have some time.
- I used to disable serial port support completely (as well as PS/2 mouse and keyboard), but the recent kernels won't let me do it. I still haven't found what pulls SERIO as a dependency. So I decided to re-enable PS/2.
- I enabled FireWire. I don't use the FireWire ports of my motherboard, but I thought, "what the hell, this kernel has become huge anyway!"
So my previous kernels were about 2MB large, this one is 2.5MB large. Certainly not spartan!
Oh, and I try to have everything built-in. If there were no external modules (nVidia, vmware) I would probably be able to disable module support completely.
The procedure I was using to configure my previous kernels was as follows:
1. Prepare a bootable kernel, using the default config or the config of previous known-bootable kernels with oldconfig.
2. Make sure all needed features are enabled, if not re-configure and re-compile accordingly.
3. Find options that seem unneeded or obsolete, disable and recompile. Keep a backup of the previous kernel.
4. Test all common applications for a few days to see if everything works as expected.
5. GOTO [2], until mental_status==bored.
As you can see, it was a time-consuming process, which explains why I stopped upgrading my kernel for 6 months once I reached a satisfactory result.
BTW, I think your kernels have dmesg timestamps disabled (I think it's the option CONFIG_PRINTK_TIME). I'd suggest enabling them, especially for the newbies who will use them.
| pappy_mcfae wrote: | | Oh, and by the way, your English is better than some I've read whose native tongue is English. |
Oh, I know my English is decent (I've even got a certificate!) but still, since I'm thinking in my mother-tongue and translating on-the-fly, making mistakes without noticing is easy. Sometimes horrible ones! And I hate reading badly-written posts, so if anyone had a problem with that, I would understand him.
Again, thank you, Pappy, for your response.
PS.
What a huge post! "Abandon all hope, you who attempt to read all this!"
EDIT: Fixed a typo.
EDIT 2: More typos! |
|
| Back to top |
|
|
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5999
Location: Pomona, California.
|
| Posted: Sat Oct 18, 2008 7:51 pm Post subject: |
|
|
Keep it up. Experimentation is how we get to the best system we can have. I am honored that my seed is the starting point for your experiments. That makes me feel like for once, one of my hair-brained ideas was actually worthwhile. I'd prefer it bring me cashola, but hey, I'll take what I can get. Besides, out there, there may be an IT guru who is really impressed with me, and might decide to hire me for their Dallas office. I can dream.
For someone who has to translate on the fly, I am most impressed. Your sentence structure and punctuation are impeccable, and I have yet to see you misspell something. I tip my hat to you. You do something my mind would crash and burn attempting!
Blessed be!
Pappy
_________________
This space left intentionally blank, except for these ASCII symbols. |
|
| Back to top |
|
|
Ink_arni
n00b
Joined: 17 Jan 2008
Posts: 19
Location: Europe
|
| Posted: Mon Oct 20, 2008 10:36 pm Post subject: |
|
|
I 'm really tired right now, but here is a quick update:
- I decided that using kernel version 2.6.27.2 would be a better idea, since it is officially out and updating to minor kernel versions is much easier than updating from 2.6.26 to 2.6.27. So all the tweaking will not be in vain.
- Regarding the font question: If I were a mathematician, I would say that I solved the problem... by proving that it is not solvable! In other words, right now it is impossible for anyone to add new fonts in the kernel source, because a certain program is needed to convert the fonts in a format that the kernel understands (C source code)... and that program has been deprecated for many years! That program was written for the Amiga OS (!), was called cpi2fnt and nobody knows where it can be found. More info here.
- Regarding the source modification I mentioned, in order to get rid of the boot delay... success! It works without any problem, at least with kernel version 2.6.27.2 vanilla. Just open the file /usr/src/linux/drivers/usb/host/pci-quirks.c, search for the string "5000" (your text editor will find only one occurrence), replace it with something smaller (I used "250") and recompile. Result:
| Code: | [ 0.213078] fuse init (API version 7.9)
[ 0.213144] SGI XFS with security attributes, large block/inode numbers, no debug enabled
[ 0.213346] io scheduler noop registered
[ 0.213350] io scheduler cfq registered (default)
[ 0.500017] pci 0000:00:02.1: EHCI: BIOS handoff failed (BIOS bug?) 01010001
[ 0.500036] pci 0000:00:0b.0: Linking AER extended capability
[ 0.500040] pci 0000:00:0c.0: Linking AER extended capability
[ 0.500043] pci 0000:00:0d.0: Linking AER extended capability
[ 0.500046] pci 0000:00:0e.0: Linking AER extended capability
[ 0.500057] pci 0000:05:00.0: Boot video device |
However, with kernel 2.6.27.2 I encountered problems with the nVidia binary drivers (latest version). The modules compiled fine, but the X server would refuse to start. Not only that, it would freeze the machine, too (fortunately it was a soft crash, so the Magic SysRq key combined with the (in)famous "elephant sequence" did the job ).
So back to 2.6.26.6 for now and no tweaking until (1) the nVidia problem gets solved and (2) I find more free time. In the meantime, anyone who has ideas or strong opinions regarding my other questions should feel free to post here. |
|
| Back to top |
|
|
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5999
Location: Pomona, California.
|
| Posted: Tue Oct 21, 2008 5:05 am Post subject: |
|
|
I thank you for the EHCI tip. At long last, I finally got a chance to set it up with 2.6.26-gentoo-r1, and it works like a bloody charm!
When I first fired up this machine with Slackware, I had that problem. It stuck with me for Gentoo. I thought it was a bug in the SATA interface of the machine. I had accepted it for over two years as something that was beyond fixing...a peculiarity of this machine. Am I happy to be proved wrong?
Yes, I am!
EDIT: In celebration of the death of a long-standing bug in my system, I offer this really simple patch to cut almost five seconds off your boot time. It only applies to the situation described above (five second delay after you hit <enter> at boot time, and the kernel actually begins booting).
| Code: | --- /drivers/usb/host/pci-quirks.c 2008-07-13 16:51:29.000000000 -0500
+++ /drivers/usb/host/pci-quirks.c 2008-10-20 23:43:59.000000000 -0500
@@ -271,7 +271,7 @@
/* if boot firmware now owns EHCI, spin till
* it hands it over.
*/
- msec = 5000;
+ msec = 250;
while ((cap & EHCI_USBLEGSUP_BIOS) && (msec > 0)) {
tried_handoff = 1;
msleep(10);
|
I call it ehci-bios-handoff.patch. You are free to call it whatever you wish. /EDIT
Blessed be!
Pappy
_________________
This space left intentionally blank, except for these ASCII symbols.
Last edited by pappy_mcfae on Tue Oct 21, 2008 5:41 am; edited 1 time in total |
|
| Back to top |
|
|
Ink_arni
n00b
Joined: 17 Jan 2008
Posts: 19
Location: Europe
|
| Posted: Tue Oct 21, 2008 5:37 am Post subject: |
|
|
Well, the problem is still there, the error message is still there, but at least we don't have to wait for something we know it will fail anyway. If you reboot once a day, that's (5 seconds * 365) = more than half an hour per year!
The problem is that you have to apply the fix every time. The other problem is that I 've already wasted more than half an hour because of this! |
|
| Back to top |
|
|
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5999
Location: Pomona, California.
|
| Posted: Tue Oct 21, 2008 5:47 am Post subject: |
|
|
I created a patch (see above) so that it's not quite such a PITA to fix this "quirk", so to speak.
Once again, thanks for the tip. Oh, and thanks for your sig, too.
Blessed be!
Pappy
_________________
This space left intentionally blank, except for these ASCII symbols. |
|
| Back to top |
|
|
Ink_arni
n00b
Joined: 17 Jan 2008
Posts: 19
Location: Europe
|
| Posted: Tue Oct 21, 2008 6:03 am Post subject: |
|
|
| pappy_mcfae wrote: | | I created a patch (see above) so that it's not quite such a PITA to fix this "quirk", so to speak. |
Oh, thanks! I hadn't seen the EDIT.
| pappy_mcfae wrote: | | Once again, thanks for the tip. |
Well, credit goes to the guy who found it at ubuntuforums.org. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
