Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #60144 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620) Ivan Zakharyaschev <imz@altlinux.org> - 2018-02-05 02:00 +0100
    Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620) Ben Hutchings <ben@decadent.org.uk> - 2018-02-05 02:10 +0100
    Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620) Jason Duerstock <jason.duerstock@gmail.com> - 2018-02-05 02:20 +0100
      Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620) Ivan Zakharyaschev <imz@altlinux.org> - 2018-02-05 03:20 +0100
      Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620) Ivan Zakharyaschev <imz@altlinux.org> - 2018-02-07 20:00 +0100
    Bug#711135: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620) John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2018-02-05 09:10 +0100

#60144 — 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.

[toc] | [next] | [standalone]

#60145

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#60146

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

[toc] | [prev] | [next] | [standalone]

#60147

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

[toc] | [prev] | [next] | [standalone]

#60162

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
...
   LINK    vmlinux
   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
   GZIP    arch/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 <imz@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.

[toc] | [prev] | [next] | [standalone]

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

On 02/05/2018 01:56 AM, 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?

No, it's not possible to publish any such updates for Wheezy on ia64 as
this architecture is not part of the LTS program:

> https://wiki.debian.org/LTS

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

We are currently bootstrapping Debian buster/sid for ia64 with about 9500
packages out of 12000 packages already being built. I don't see any reason
to provide kernel updates for Wheezy given these circumstances.

> And what about an updated installation image?

Not for Wheezy. I will create one for Debian buster/sid once I find the time
though. But that won't happen before the package src:linux has been fixed
on ia64 so that it builds on the buildds.

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

I don't want to encourage people to install software which has been long out
of support. People should either wait for the new installation images for
buster/sid or use some of the workarounds suggested by other people in this
thread.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web