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 <i...@altlinux.org> 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. >