Re: Processor type kernel option for Core Duo (not Core 2)

On 21/10/07 17:52, Douglas Mayne wrote:
> On Sat, 20 Oct 2007 13:46:23 +0100, Tony Houghton wrote:
>
>> I've got a Centrino Core Duo laptop; the processor number is T2300E. I
>> can't work out which processor type option to use for the kernel. AFAICT,
>> despite the "Core" branding, it has much more in common with Pentium M
>> than Core 2, so I tried Pentium M at first; this seemed to prevent the
>> laptop from booting ("Waiting for root filesystem" or something like
>> that). Then I tried the Core 2 option and also enabled "Generic x86". It
>> works, but I'm not at all sure that it's the correct optimisation and
>> suspect it might fail if I disable the generic option.
>>
>> FWIW I've found out that "prescott" is the best gcc -march option for this
>> type of processor on the grounds that their MMX/SSE was improved over
>> earlier Pentium Ms. Would the same theory apply to the kernel option?
>>
> AFAIK, the CPU type selection within the kernel configuration (make
> xconfig, make menuconfig, etc) specifically enables features found on
> specific processors. For example, processor scaling is a feature present
> only on some processors. Therefore, to use the feature, you need the
> hardware (the device with the feature) and the software support.
> The kernel should be configured to support any devices you intend
> to use. The kernel configuration allows fine grained control over which
> features it will support.
>
> Both the Core and Core 2 are P6 derivatives, and have more in common with
> Pentium-III, than Pentium IV.
> http://en.wikipedia.org/wiki/Intel_P6
>
> Your CPU settings...
> I don't have a "core duo" CPU, but I am guessing that the setting should
> be at least to the level identified as "Coppermine." Most likely, Pentium
> M is most appropriate. You want SMP support if you have dual cores. CPU
> count >= 2. AKAIK, for this architecture, "SMT hyperthreading support" is
> not appropriate (deselect). Enable "multi-core scheduler support".
>
> And if your CPU supports processor scaling, then add that support, too.
> That is configured in the next category, "Power management options."

Yes, I decided to use "ondemand" and edited rc.local to enable it.

> Compiler options...
> I think you are correct that the compiler used should use
> optimizations for the processor architecture that will run the
> kernel. I haven't ever specifically set this, as the default appears to
> be ok. But P6 architecture optimizations might be slightly better than P5
> optimizations, but I am guessing P6 optimizations are "good enough."

I decided to go ahead with basing my decision on what experts say is
most appropriate for gcc and used Pentium 4 rather than Pentium M. It
seems to work fine even with generic x86 disabled.

> Boot problems...
> Your current boot problem with the "root filesystem" not found is probably
> not related to an error choosing the proper CPU architecture. Most
> likely, it is due to other options you made when configuring the kernel
> as a whole. Configuring the kernel is a daunting task, BTW. I always
> start with a "known good" configuration, and then add minor tweaks.

I've been compiling kernels for years. I was also sure the mistake must
be in my choice of SATA driver etc and spent ages trying every sort of
thing appropriate for Intel (it's definitely an Intel chipset) and
generic support, but in the end changing the CPU type (and enabling
generic x86, although that doesn't seem necessary now) was what made the
difference. It's possible there was a make dependency error and changing
the CPU type forced everything to be recompiled and fixed it, but I
haven't heard of anything like that happening with the kernel.

> Root filesystem...
> The most common causes for errors setting the root filesystem are as
> follows:
>
> 1. Bad data in /etc/fstab. This comes up quite often when changing
> hardware- hda becomes sda, etc.

It's a SATA drive so I think it would always be sda on this system.
I didn't think of checking fstab (surely that can't be read until after
/ is mounted anyway), but I made grub use UUID just in case.

> 2. Lack of kernel support for the device and/or filesystem where the
> root filesystem resides. Kernel support for devices and filesystems can be
> built directly into the kernel, or added as a module. Kernel modules can
> be loaded at boot time using an initrd. (Making an initrd is distribution
> dependant.) If the kernel does not load the necessary modules (or have
> support built in), then it will be unable to begin using the root
> filesystem. If you decide to use an initrd, then you must include any
> modules which are necessary to start using the root filesystem. Note:
> modules may require other modules (man depmod).

I generally use initramfs (I think - the various tools involved still
tend to refer to it as initrd) and UUID in my grub config nowadays.

--
TH * http://www.realh.co.uk
.

Relevant Pages