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.)
--
Best regards,
Ivan
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)