Re: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)

Hello!

On Sun, 4 Feb 2018, Frank Scheiner wrote:

> just a quick pointer:
>
> I had Debian Wheezy with Linux v3.2.x (vmlinuz-3.2.0-4-mckinley, i.e. [this 
> one]) running w/o issues on my rx2620 with two Itanium 2 9040 (Montecito) 
> both from an on-disk installation and a NFS root FS, but I ran it on 
> bare-metal, not in a VM.

Yes, [this one] doesn't boot on our system. It might even be in our 
case a strange/buggy behavior caused by old firmware for an 
otherwise correct kernel binary code (or, of course, the code might be 
not correct). Perhaps, there is a difference between yours and ours 
machines:

root@rx2620:~# cat /proc/cpuinfo
processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : 31
model      : 2
model name : Madison up to 9M cache
revision   : 1
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 1600.021
itc MHz    : 1600.021752
BogoMIPS   : 2390.01
siblings   : 1
physical id: 0

processor  : 1
vendor     : GenuineIntel
arch       : IA-64
family     : 31
model      : 2
model name : Madison up to 9M cache
revision   : 1
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 1600.021
itc MHz    : 1600.021752
BogoMIPS   : 2390.01
siblings   : 1
physical id: 1

root@rx2620:~#

It looks like ours has 2 Madison CPUs (if we are to trust this cpuinfo), 
which are older than your Montecito ones.

> I'm currently running Gentoo on it (with elilo from Debian Wheezy as the 
> newer one from Gentoo doesn't work), but can arrange a network boot with 
> Debian Wheezy to gather more information if needed.

> [this one]: https://packages.debian.org/wheezy/linux-image-3.2.0-4-mckinley

As for gathering information, I can't think of some useful information 
from a working system so far. The same applies to testing. We are able to 
test it here. Anyway, thanks for your messages, Frank and Daniel! The 
remaining useful tasks which I see are:

1) learn how to compile a bootable kernel for this machine and apply this 
knowledge to compile a fresh current kernel;

2) understand what goes wrong (by bisecting gcc), suggest a fix. (Before 
we understand it, we can't be sure what should be fixed: it's not 
necessarily abug in gcc).

So far, we've done a number of attempts to compile and boot a kernel (I'm 
going to post the details and the kernels soon), and my conclusion so far 
is that the only affecting factor is the version of gcc (even not -O1 vs 
-Os/-O2).

gcc <= 4.5.3 produces a bootable kernel (as for 
linux-image-3.2.0-4-mckinley, gcc 4.4.7 from wheezy and gcc 4.5.3 from 
snapshots produced a bootable one in my experiments);
gcc >= 4.6.3 produces a non-bootable kernel.

So this already gives an initial hypothesis about the solution to 1):

To compile a bootable kernel for this machine, use gcc <= 4.5.3. To speed 
up the build and test process, prepare such a cross-compiler on your 
current powerful systems. (I haven't got or tried to use one; Gleb has 
already used a cross-compiler for this tests, though a very recent gcc, so 
that it produced non-bootable kernels.)