[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Mon, 5 Feb 2018, Ivan Zakharyaschev wrote:

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.

 [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.

Now that we know how to build a bootable kernel for such machines as ours (rx2620 with Madison CPU) and probably Daniel Kasza's rx2600, can such an update be published for wheezy?

Perhaps, an additional variant of linux-image-mckinley built with gcc-4.4 (4.4.7) present in wheezy? As a workaround for this bug.

And what about an updated installation image? So that people trying to install Debian on such a machine would succeed not only of they take the Debian 6 (squeeze) image (which is definitely not the first thing they would try when searching for an installation image), but so that Debian 7 (wheezy) images (more likely to be found by them) would work for them, too.


Reply to: