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

Does the kernel from here work for you?:

https://people.debian.org/~jrtc27/wheezy-backports-ia64/

Specifically https://people.debian.org/~jrtc27/wheezy-backports-ia64/linux-image-3.16.0-0.bpo.4-mckinley_3.16.39-1+deb8u1~bpo70+1+gcc4.4_ia64.deb

Jason

On Sun, Feb 4, 2018 at 7:56 PM, Ivan Zakharyaschev <[email protected]> wrote:
> 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.
>