Arch Linux

jwhendy

Member

Registered: 2010-04-01

Posts: 621

Custom kernel and intel i915 & intel_agp

Hi,

I just built my first custom kernel on Arch since modeline setting became mandatory and wondered if I must build i915 and intel_agp as modules or not. I went to boot and the text stayed large all the way through vs. the standard kernel, which switches to smaller text quite early on. I figured since I needed those components I might as well build them in, but now I'm wondering if they need to be modules because perhaps the mkinitcpio command builds an initramfs that gets loaded before the actual kernel.

Am I thinking about this correctly and should I build these as modules vs. built-in to the kernel itself?

For those unfamiliar, I'm speaking of the issue discussed HERE.

The wiki seems to say that it's mandatory to have KMS working, but it doesn't exactly say you have to build it into a module.

On a related note, I had the same issue with wireless. I build in support for the intel 4965, but it failed to find the firmware at boot. If I build it as a module instead, all goes well. Why might this be happening?

Thanks.

aclindsa

Member

Registered: 2011-01-29

Posts: 30

Website

Re: Custom kernel and intel i915 & intel_agp

Which version of the kernel are you compiling? Also, did you update your MODULES line in /etc/mkinitcpio.conf:
MODULES="intel_agp i915"
and then run mkinitcpio on your kernel image again, as the tutorial says?

jwhendy

Member

Registered: 2010-04-01

Posts: 621

Re: Custom kernel and intel i915 & intel_agp

@aclindsa: but that's the point... if I build in support for intel agp and the i915 driver... why do I need to do anything with mkinitcpio.conf and modules? They're not modules -- they're built in.

And that's pretty much my question -- what's the "best practice" for stuff like this? Leave it as a module or load it in? I tend to think building in support is better if you know you'll always need it -- I'll always need dm_crypt, i915, intel_agp, etc... so not sure what advantage or disadvantage there is for having them as modules. Take bluetooth support, on the other hand. I would use it sooooo infrequently that I'd much rather build it as a module and have it autoload (or manually load it) when I try to use something.

So, to clear up any confusion...
-- I already have used the method you refer to and am familiar with it
-- I tried switching to built in support and did not get the typical switch to native resolution during boot and am wondering if that's simply because the kernel isn't really loaded at that point (running from initramfs?) or because there's something intrinsically wrong with building these two into the kernel and they should be left as modules.

Gusar

Member

Registered: 2009-08-25

Posts: 3,605

Re: Custom kernel and intel i915 & intel_agp

It doesn't matter whether those are built-in or as modules. I've had kernels that had either, and it always worked. Currently I have it built-in.

It's not comparable to wireless, because of the firmware. When a device needs firmware and you have the driver built-in, the driver will load before the filesystem is mounted. So of course loading fails due to "missing" firmware. It's possible though, to also build the firmware into the kernel.

milomouse

Member

Registered: 2009-03-24

Posts: 940

Website

Re: Custom kernel and intel i915 & intel_agp

I have another laptop I use for testing that has 9 kernels (plus their fallbacks) that needs i915, as well.  My default day-to-day kernel (2.6.36) on that laptop has intel_agp as a module and it does KMS as expected, also using this boot param

i915.powersave=0 i915.modeset=1

But the modesetting should already be handled. Regardless, my latest security testing kernel (2.6.38 with SMACK) has no modules what-so-ever (with module-loading disabled), everything is built-in that I need and stripped of anything I don't, and it does early KMS just fine, too.   There's no right or wrong when it comes to KMS, as far as module versus built-in.  Firmware relations are different, as Gusar pointed out, and as you may already be aware.

Anyway, if you're building that kernel specifically and soley for that system then I'd build intel_agp in... but since you're having problems with this; what are your CONFIG options set to?  For example, my latest kernel .config, on the i915 laptop, with intel_agp built-in, has these relavent settings:

CONFIG_ACPI_VIDEO=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_AGP_INTEL=y
CONFIG_DRM_I915=y
CONFIG_DRM_I915_KMS=y
CONFIG_STUB_POULSBO=y
CONFIG_VIDEO_OUTPUT_CONTROL=y

If your's say anything else, you'll need to change them to "y".  Sorry if you already know all of this, just throwing my advice into the pile.  As far as dm_crypt, if you use it all the time (e.g. every boot), then build that in too.  Did you have a problem with that too, or just KMS?

combuster

Member

From: Serbia

Registered: 2008-09-30

Posts: 711

Website

Re: Custom kernel and intel i915 & intel_agp

Have you checked Enable modesetting on Intel by default (it's right below i915 driver in menuconfig).

I have intel drivers built-in, drivers that are in use all the time I keep as built-in and those that I need on occasions I keep as modules. My /lib/modules/kernelver directory is 6.4MB heavy and kernel image 2.1MB so you could say that I'm pretty liberal with kernel config

jwhendy

Member

Registered: 2010-04-01

Posts: 621

Re: Custom kernel and intel i915 & intel_agp

Thanks for the feedback, everyone.

@gusar: thanks for the note on wireless. That makes more sense, now.

@combuster/milomouse: grrr. I think I just missed the automatic modesetting. I just rebuilt and all seems to be fine.

@ milomouse: I don't necessarily have a problem with dm_crypt, but when I reboot with a kernel with it built in, the prompt for the password to mount my root gets overrun by a bunch of USB announcements. With the standard Arch kernel, everything pauses while it waits for a password. With this kernel, the message appears and then about 10 lines of text continue to come out. The first time it happened, I thought it was hung, but pressing enter to try and provoke a recovery shell evoked the message, "No device with that passphrase is known" or whatever.

Only then did I realize it was still waiting for the encryption password. It's a current glitch but not a huge deal. It would be nice to make it wait and stop blurting out USB device messages and just freeze at the passphrase prompt, though...