Re: Bug#889848: Acknowledgement (ruby2.5: Please include upstream patch to fix FTBFS on ia64)

2018-02-07 Thread John Paul Adrian Glaubitz
Oops, the previous patch contains some unnecessary cruft.
Attaching a cleaned-up version of the patch.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Fix FTBFS on ia64
 Fix FTBFS on ia64.
Author: Sergei Trofimovich 
Origin: https://github.com/ruby/ruby/commit/5af43b1ec2674e9f86090790bc61abdb96be14ff
Last-Update: 

--- ruby2.5-2.5.0.orig/cont.c
+++ ruby2.5-2.5.0/cont.c
@@ -475,7 +475,7 @@ cont_save_machine_stack(rb_thread_t *th,
 
 SET_MACHINE_STACK_END(&th->ec->machine.stack_end);
 #ifdef __ia64
-th->machine.register_stack_end = rb_ia64_bsp();
+th->ec->machine.register_stack_end = rb_ia64_bsp();
 #endif
 
 if (th->ec->machine.stack_start > th->ec->machine.stack_end) {
@@ -499,8 +499,8 @@ cont_save_machine_stack(rb_thread_t *th,
 
 #ifdef __ia64
 rb_ia64_flushrs();
-size = cont->machine.register_stack_size = th->machine.register_stack_end - th->machine.register_stack_start;
-cont->machine.register_stack_src = th->machine.register_stack_start;
+size = cont->machine.register_stack_size = th->ec->machine.register_stack_end - th->ec->machine.register_stack_start;
+cont->machine.register_stack_src = th->ec->machine.register_stack_start;
 if (cont->machine.register_stack) {
 	REALLOC_N(cont->machine.register_stack, VALUE, size);
 }
--- ruby2.5-2.5.0.orig/thread.c
+++ ruby2.5-2.5.0/thread.c
@@ -132,7 +132,7 @@ static inline void blocking_region_end(r
 
 #ifdef __ia64
 #define RB_GC_SAVE_MACHINE_REGISTER_STACK(th)  \
-do{(th)->machine.register_stack_end = rb_ia64_bsp();}while(0)
+do{(th)->ec->machine.register_stack_end = rb_ia64_bsp();}while(0)
 #else
 #define RB_GC_SAVE_MACHINE_REGISTER_STACK(th)
 #endif


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

2018-02-07 Thread 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.