# looking for an explanation of some menuconfig magic...

## pste

I'm currently struggling with a Gentoo installation (amd/emt64) on my HP HDX 16-1000 --> I don't know if it's the BIOS or only strangely put together hardware, but it's not as smooth as my earlier installations... I started by installing Ubuntu 9.04, which works reasonably well, just as a reference (and to have some logs to double check from...). Then I grabbed a kernel-seed from pappy and digged in. Got immediately stuck with strange iommu and other entries in dmesg, which led me into the following.

What puzzles me, and what is the main topic here, is some, as I conceive it, odd magic by the menuconfig script, for which I now look for some explanations, and perhaps some good advice of a propitious strategy. But first, to anyone who haven't yet discovered it, a very useful feature! Searching through the forums I stumbled into someone hinting that the menuconfig script has a search function similar to nano.

In menuconfig: Just type /xxxx and you'll instantly find those config variables that you never can remember in what section they reside... - just spreading the word  :Cool: 

To the oddity. Somehow I got the impression that all those iommu errors was the cause of some other problems I had, and that it was connected to a dmesg log entry mentioning SWIOTLB. There is a SWIOTLB config variable in .config but I could not find it in menuconfig (and I feel that hand editing is somewhat dangerous, since menuconfig usually changes probably necessary related settings as well). Messing around (inspired by differences in the Ubuntu dmesg and my problematic Gentoo one) I tried enabling IBM_CALGARY_IOMMU and AMD_IOMMU and the problems disappeared! Checking stated dependencies in menuconfig and the reality in .config I found that these settings had enabled the mysterious SWIOTLB setting as well. Trying to be thorough, and reproduce the error in order to find out which of these settings that did it, I step by step disabled both the IOMMU settings, but the errors did not reappear... Checking the .config reveals that the SWIOTLB is still enabled, and following dependencies (by using the / search function) I find that other settings (e.g. GART_IOMMU, which cannot be found in menuconfig) has been enabled, and AGP is uneditably enabled (in spite not having any AGP), etc.

Sorry for this lengthy essay, but can anyone explain anything to me, or provide me with some hints? I get confused by invisible dependent settings fixing my problems, and by seemingly irreversible changes made with menuconfig. Wouldn't it be better if all possible settings are displayed among the menus (fixed if necessary), but then you at least have the chance of discovering changes. I for one will start versioning my .config in order to be able to use diff to identify such hidden automagic behavior...

/pste

----------

## Raniz

A quick search in my menuconfig revealed this:

```
 Symbol: SWIOTLB [=y]

   Selected by: GART_IOMMU && X86_64 && PCI || CALGARY_IOMMU && X86_64 && PCI && EXPERIMENTAL || AMD_IOMMU && X86_64 && PCI && ACPI

 Symbol: GART_IOMMU [=y]

 Prompt: GART IOMMU support

   Defined at arch/x86/Kconfig:528

   Depends on: X86_64 && PCI && EMBEDDED

   Location:

     -> Processor type and features

   Selects: SWIOTLB && AGP
```

Which explains the magic behind SWIOTLB being selected, it doesn't explain GART_IOMMU though. The reason why GART_IOMMU doesn't show in your menuconfig is probably because EMBEDDED (found under general, "Configure standard kernel features (for small systems)" ) isn't set - and it shouldn't be either.

And the reason why SWIOTLB is still set when you unset CALGARY_IOMMU and AMD_IOMMU is because GART_IOMMU, X86_64 and PCI are still set, that's the reason AGP is set aswell. What you need to find out is why GART_IOMMU was set.

----------

## pste

Yepp, that's about how far I got as well... Thanks for digging into it! Although I haven't (yet...) found the reason why GART_IOMMU is/was set...

I have to say that I become more and more annoyed about all those settings not showing until you select something somewhere else, which means you have to keep a lot of stuff in your head, or use the search function frequently (which I only recently discovered to exist   :Cool:  ). That is, I believe it should be useful to display all settings in menuconfig (greyed out or locked if necessary) just to make one aware of its existence... Should I post that suggestion to some kernel development forum? Which one?

To the issue of getting a useful kernel configuration strategy... Currently I think one should probaly enable settings in some hierarchial order corresponding to the system layout. That is, I tend to lean towards the conclusion that there is only one way to go, hard work finding out every nitty, bitty detail about the system, i.e. I have to learn the exact layout of all chipsets, bridges, buses, etc. Although I believe I'm not that a novice in this area I realize I don't know enough (it seems I cannot get everything working as I'd like to, eventually it'll appear other more specific discussions in other threads). For the present purpose... Anyone who knows a good, illustrative site describing system layouts with corresponding kernel settings (especially for laptops which seems to be more complicated than standard PCs)???

/pste

----------

## cyrillic

 *pste wrote:*   

> That is, I believe it should be useful to display all settings in menuconfig (greyed out or locked if necessary) just to make one aware of its existence... 

 

The method I use for complex / difficult hardware (like my newest laptop) is to enable everything

```
# make allmodconfig

# make menuconfig 
```

Then I work my way backwards, removing whatever I don't need.

----------

## pste

 *Quote:*   

> The method I use for complex / difficult hardware (like my newest laptop) is to enable everything
> 
> ```
> 
> # make allmodconfig
> ...

 

Cyrillic, I'll certainly give that approach I try, although it'll take some time and a lot of rebooting! But haven't you ever experienced any conflicts? That is, have you run into any no-no combinations that you can spare me from doing again?  :Wink:  (of course they'll be hardware dependent, but anyway... asking is free... btw, as i said above, my current project is a HP HDX16-1000 [Core2 P8400, 82801 ich9, PCIe, nVidia 9600M GT, rtl8168, w. some other nice gadgets like dvb-t, etc. as well]), I'll probably get on with the experimental kernel-laptop-interdependency research project during the weekend...

----------

## cyrillic

 *pste wrote:*   

> But haven't you ever experienced any conflicts? 

 

Compiling almost everything as modules will avoid conflicts, because the kernel will only autoload modules that are appropriate for your hardware.

 *pste wrote:*   

> That is, have you run into any no-no combinations that you can spare me from doing again? 

 

One combination that should be avoided is CONFIG_IDE=y (the legacy IDE drivers) and CONFIG_ATA=y (the newer libata drivers) since these drivers mostly overlap.

Here are a couple of other options I usually turn off right away (mostly for performance reasons)

```
General setup  --->

  [ ] Group CPU scheduler

  [ ] Optimize for size

Processor type and features  --->

  [ ] Built-in kernel command line

Kernel hacking  --->

  [ ] Debug Filesystem 
```

I also turn off pretty much everything else I can find that says "Debug" or "Deprecated"

 *pste wrote:*   

> I'll probably get on with the experimental kernel-laptop-interdependency research project during the weekend...

 

Have fun.  :Smile: 

----------

