Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)
Hi Jason, On Sun, 4 Feb 2018, Jason Duerstock wrote: 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 (As I've already said, this kernel works for our machine.) How to reproduce this build? Have you published the corresponding rules? I tried: $ apt-get source linux-image-3.16.0-0.bpo.4-mckinley Reading package lists... Done Building dependency tree Reading state information... Done Picking 'linux' as source package instead of 'linux-image-3.16.0-0.bpo.4-mckinley' NOTICE: 'linux' packaging is maintained in the 'Git' version control system at: https://anonscm.debian.org/git/kernel/linux.git Need to get 84.2 MB of source archives. Get:1 http://ftp.ru.debian.org/debian/ wheezy-backports/main linux 3.16.39-1+deb8u1~bpo70+1 (dsc) [97.4 kB] Get:2 http://ftp.ru.debian.org/debian/ wheezy-backports/main linux 3.16.39-1+deb8u1~bpo70+1 (tar) [81.8 MB] Get:3 http://ftp.ru.debian.org/debian/ wheezy-backports/main linux 3.16.39-1+deb8u1~bpo70+1 (diff) [2,316 kB] Fetched 84.2 MB in 9s (9,087 kB/s) dpkg-source: info: extracting linux in linux-3.16.39 dpkg-source: info: unpacking linux_3.16.39.orig.tar.xz dpkg-source: info: unpacking linux_3.16.39-1+deb8u1~bpo70+1.debian.tar.xz dpkg-source: info: applying debian/version.patch ... $ cd linux-3.16.39/ $ sed -e 's/gcc-4.6/gcc-4.4/g' debian/config/ia64/defines -i $ debuild -b -us -uc $ debuild -j2 -b -us -uc ... LINKvmlinux LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o KSYM.tmp_kallsyms1.o KSYM.tmp_kallsyms2.o LD vmlinux SYSMAP System.map Building modules, stage 2. OBJCOPY arch/ia64/hp/sim/boot/vmlinux.bin GZIParch/ia64/hp/sim/boot/vmlinux.gz MODPOST 2506 modules LN vmlinux.gz Kernel: vmlinux.gz is ready ERROR: "numa_slit" [drivers/block/nvme.ko] undefined! make[6]: *** [__modpost] Error 1 make[5]: *** [modules] Error 2 make[4]: *** [sub-make] Error 2 make[3]: *** [__sub-make] Error 2 make[3]: Leaving directory `/home/imz/with-gcc-4.4.7_wheezy/linux-3.16.39/debian/build/build_ia64_none_itanium' make[2]: *** [debian/stamps/build_ia64_none_itanium_plain] Error 2 make[2]: Leaving directory `/home/imz/with-gcc-4.4.7_wheezy/linux-3.16.39' make[1]: *** [build-arch_ia64_none_itanium_real] Error 2 make[1]: Leaving directory `/home/imz/with-gcc-4.4.7_wheezy/linux-3.16.39' make: *** [build-arch] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc -j2 -b failed $ (Parallellization, i.e., -j2, doesn't affect the result; I have checked that.) On Sun, Feb 4, 2018 at 7:56 PM, Ivan Zakharyaschev <i...@altlinux.org> wrote: 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 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.
Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)
Hi Jason, On Sun, 4 Feb 2018, Jason Duerstock wrote: 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 Yes, it works for our machine. Thanks! It's amazing that you came to the same solution as regards the use of gcc-4.4 a while ago! If we could find it before, it'd have saved us some experiments. (The lack of a working installaton image which is easy to find was also discouraging at the first stage.) On Sun, Feb 4, 2018 at 7:56 PM, Ivan Zakharyaschev <i...@altlinux.org> wrote: 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.
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.
Bug#711135: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)
Hello! Issue 711135 seems to never have been resolved yet (since Debian 6 "squeeze", which has the last kernel which boots on rx2620: 2.6.32-5-mckinley) Maybe this works: https://lists.debian.org/debian-ia64/2013/07/msg9.html (Will Deacon): ... Ok, after some more experimentation, this is looking more and more like a compiler problem. Using 4.6.3, I *can* build a bootable kernel from the Squeeze sources but only if I hack the kernel Makefile to pass -O1 instead of -O2 or -Os. https://lists.debian.org/debian-ia64/2013/07/msg00011.html (Lennert Van Alboom): ... Aha - interesting. This might be the same issue as the one I'm seeing on HPVM on zx6000 (rx2600) with wheezy (coredump & VM hard reset). https://lists.debian.org/debian-ia64/2013/07/msg5.html (Lennert Van Alboom): ... I've got a zx6000 workstation at home with HP-UX 11.31 and Integrity VM B.04.30. I want to play with Linux VMs, so I decided to install Debian. ... As you can see, I used the debian 7.1.0 ia64 netinstall iso. This failed miserably - I selected "boot from file" and the elilo.efi loaded; when selecting any option (normal or expert install) the following happens: Uncompressing Linux... done Loading file \initrd.gz...done Dumping Guest Image Done with dump (3776Kbytes) *** VM restarting *** So the installer never makes it. Next, I swapped the 7.1.0 iso for the 6.0.7 one. Selected elilo.efi, selected "Expert install"; the installer loads ... A final follow-up in 2013/08 (just a thought, no really confirmed interesting thing): https://lists.debian.org/debian-ia64/2013/08/msg0.html (Émeric MASCHINO): Since you all seem to hit a compiler option issue, rather than dropping optimizations from -O2 to -O1, what about specifically targeting Merced or McKinley CPU with -mtune=merced or -mtune=mckinley gcc option? There are also itanium and itanium1 as accepted keywords, but I don't know how they differ from merced. On a side note, I don't know what's the difference between the mckinley and itanium2 keywords (I'm currently rebuilding my whole Gentoo system using -mtune=itanium2, since I'm running Madison CPUs on my zx6000). -- Best regards, Ivan
