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

[Ivan Zakharyaschev]

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  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)

[Ivan Zakharyaschev]

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  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)

[Jason Duerstock]

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

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

[Ben Hutchings]

On Mon, 2018-02-05 at 03:56 +0300, Ivan Zakharyaschev wrote:
[...]
> 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?
[...]

Not officially.  wheezy is now in LTS status, and updates are only
built for x86 and ARM.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



signature.asc
Description: This is a digitally signed message part

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

[Ivan Zakharyaschev]

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.