Re: [PATCH 2/3] Enabled LRA for ia64.

[Frank Scheiner]

Hi Jonathan, Richard,

On 12.06.24 20:54, Jonathan Wakely wrote:

On 12/06/24 16:09 +0200, Frank Scheiner wrote:

Dear Richard,

On 12.06.24 13:01, Richard Biener wrote:

[...]
I can find two gcc-testresult postings, one appearantly with LRA
and one without?  Both from May:

https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html
https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html

somehow for example libstdc++ summaries were not merged, it might
be you do not have recent python installed on the system?  Or you
didn't use contrib/test_summary to create those mails.


No, I did not use contrib/test_summary. But I still have tarballs of
both testsuite runs, so could still produce these summaries - I hope?


It looks like the results at
https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html are
just what's printed on standard out, including output from 'make -j4'
so not combined into one set of results.


That's what it is, yes.


It would certainly be better to either get the results from the .sum
files, or just use the contrib/test_summary script to do that for you.


Ok, I posted the results as created by contrib/test_summary now:

1. non-LRA version on [1]

2. LRA version on [2]

[1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817267.html

[2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html

The difference 2 compared to 1 is attached.


Do I need to run this on the host that did the testing or can I run it
on my NFS server where the tarballs are actually located, too?


I don't think the script cares where it's run, it just looks at text
files which should work on any host.


It looks like it worked fine. :-)

Cheers,
Frank
 
diff --git a/gcc-15-testsuite-summary.log b/gcc-15-lra-testsuite-summary.log
index b7acc04..558079a 100644
--- a/gcc-15-testsuite-summary.log
+++ b/gcc-15-lra-testsuite-summary.log
@@ -306,13 +306,12 @@ FAIL: gcc.dg/guality/csttest.c  -Og -DPREVENT_OPTIMIZATION  line 55 q == -(0x1ef
 FAIL: gcc.dg/guality/csttest.c  -Og -DPREVENT_OPTIMIZATION  line 55 r == -(0x1efULL << 50)
 XPASS: gcc.dg/guality/example.c   -O0  execution test
 XPASS: gcc.dg/guality/guality.c   -O0  execution test
-XPASS: gcc.dg/guality/guality.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params-2.c   -O1  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params-2.c   -O2  -DPREVENT_OPTIMIZATION  execution test
+FAIL: gcc.dg/guality/inline-params-2.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params-2.c   -Os  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params-2.c  -Og -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params.c   -O1  -DPREVENT_OPTIMIZATION  execution test
-XPASS: gcc.dg/guality/inline-params.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/inline-params.c  -Og -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/ipa-sra-1.c   -O1  -DPREVENT_OPTIMIZATION  line 19 k == 3
 FAIL: gcc.dg/guality/ipa-sra-1.c   -O1  -DPREVENT_OPTIMIZATION  line 31 k == 3
@@ -434,6 +433,7 @@ FAIL: gcc.dg/guality/pr41447-1.c   -Os  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/pr41447-1.c  -Og -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/pr41616-1.c   -O1  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/pr41616-1.c   -O2  -DPREVENT_OPTIMIZATION  execution test
+FAIL: gcc.dg/guality/pr41616-1.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/pr41616-1.c  -Og -DPREVENT_OPTIMIZATION  execution test
 FAIL: gcc.dg/guality/pr43051-1.c   -Os  -DPREVENT_OPTIMIZATION  line 34 c == [0]
 FAIL: gcc.dg/guality/pr43077-1.c   -O0  line 19 vara == 1
@@ -798,10 +798,10 @@ FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-genera
 UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation,  -fprofile-use -D_PROFILE_USE
 UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,-fprofile-generate -D_PROFILE_GENERATE
 UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,-fprofile-use -D_PROFILE_USE
-FAIL: gcc.dg/tree-prof/pr77698.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
-UNRESOLVED: gcc.dg/tree-prof/pr77698.c compilation,  -fprofile-use -D_PROFILE_USE
-UNRESOLVED: gcc.dg/tree-prof/pr77698.c execution,-fprofile-generate -D_PROFILE_GENERATE
-UNRESOLVED: gcc.dg/tree-prof/pr77698.c execution,-fprofile-use -D_PROFILE_USE
+FAIL: gcc.dg/tree-prof/pr47187.c compilation,  -fprofile-generate -D_PROFILE_GENERATE
+UNRESOLVED: gcc.dg/tree-prof/pr47187.c compilation,  -fprofile-use -D_PROFILE_USE
+UNRESOLVED: gcc.dg/tree-prof/pr47187.c execution,-fprofile-generate -D_PROFILE_GENERATE
+UNRESOLVED: gcc.dg/tree-prof/pr47187.c execution,-fprofile-use -D_PROFILE_USE
 FAIL: gcc.dg/tree-ssa/abs-4.c scan-tree-dump-times optimized "= -" 3
 FAIL: gcc.dg/tree-

[ia64] Results for 15.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) w/LRA testsuite on ia64-t2-linux-gnu

[Frank Scheiner via Gcc-testresults]

Native configuration is ia64-t2-linux-gnu

=== gcc tests ===


Running target unix
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O0   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler 
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.rodata.used_rodata2,"aR"
WARNING: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess 
errors) program timed out.
FAIL: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O1  execution test

[ia64] Results for 15.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) testsuite on ia64-t2-linux-gnu

[Frank Scheiner via Gcc-testresults]

Native configuration is ia64-t2-linux-gnu

=== gcc tests ===


Running target unix
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O0   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler 
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler .bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler 
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler 
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler 
.rodata.used_rodata2,"aR"
WARNING: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess 
errors) program timed out.
FAIL: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O1  execution test

Re: [PATCH 2/3] Enabled LRA for ia64.

[Frank Scheiner]

Dear Richard,

On 12.06.24 13:01, Richard Biener wrote:

[...]
I can find two gcc-testresult postings, one appearantly with LRA
and one without?  Both from May:

https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html
https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html

somehow for example libstdc++ summaries were not merged, it might
be you do not have recent python installed on the system?  Or you
didn't use contrib/test_summary to create those mails.


No, I did not use contrib/test_summary. But I still have tarballs of
both testsuite runs, so could still produce these summaries - I hope?

Do I need to run this on the host that did the testing or can I run it
on my NFS server where the tarballs are actually located, too?

Architectures are different though, the NFS server is 32-bit ARM.

Cheers,
Frank

Re: [PATCH 2/3] Enabled LRA for ia64.

[Frank Scheiner]

Hi all,

On 12.06.24 15:19, René Rebe wrote:

On Jun 12, 2024, at 15:00, Richard Biener  wrote:

On Wed, 12 Jun 2024, René Rebe wrote:

On Jun 12, 2024, at 13:01, Richard Biener  wrote:
On Wed, 12 Jun 2024, Rene Rebe wrote:

not sure how you exactly did this though?  I've never tried
testing of a canadian-cross tree - did you copy the whole build
tree over from the x86 to the ia64 machine?


IIRC the testsuite did not just work copying the canadian-cross.
I did run the testsuite from the cross-compiled gcc using a ssh
based dejagnu board config, but Frank also did fully bootstrap and
ran the testsuite natively.


Exactly, the results I posted are both based on natively bootstrapped 
GCC binaries (took ca. 5 hours each on my rx2800 i2). The post titles 
include the exact commit hash they are based on:


1. [ia64] Results for 15.0.0 20240528 (experimental) [master revision 
236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) testsuite on 
ia64-t2-linux-gnu ([1])


2. [ia64] Results for 15.0.0 20240528 (experimental) [master revision 
236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) w/LRA testsuite on 
ia64-t2-linux-gnu ([2])


[1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816346.html

[2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html

I tried to save time during the testsuite runs (it still took more than 
7 hours on my rx2800 i2 running in tmpfs) by manually running multiple 
testsuites in parallel in the following fashion:


```
gcc   | libstdc++
  |
  |
--|
g++   |
  |
  |
--|
gfortran  |
  |
  |
--|
libgomp   |---
  | libatomic
  |---
  | objc
```
... and also using multiple jobs per testsuite where it saved time (e.g. 
it does not for the libgomp testsuite). This is the reason that the 
output is somewhat split up.


[1] and [2] each also list the commands used to run the testsuites and 
timing data. For reference these were produced on a:


rx2800 i2 w/1 x Itanium 2 9320 running @1.33 GHz w/SMT enabled

Cheers,
Frank

[ia64] Results for 15.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) w/LRA testsuite on ia64-t2-linux-gnu

[Frank Scheiner via Gcc-testresults]

in
/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/gcc



date; time make -j4 check-gcc 2>&1; echo $?; date
Fri May 31 11:48:35 UTC 2024

=== gcc tests ===

Running target unix
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O0   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/pr29201.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -Os  (test for excess errors)
WARNING: program timed out
FAIL: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess
errors)
FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c  

[ia64] Results for 15.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) testsuite on ia64-t2-linux-gnu

[Frank Scheiner via Gcc-testresults]

in
/dev/shm/gcc-15/src.gcc.ia64-toolchain-3.240529.112623.549077/gcc/gcc.build.lnx/gcc



date; time make -j4 check-gcc 2>&1; echo $?; date
Thu May 30 09:43:20 UTC 2024

=== gcc tests ===

Running target unix
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O0   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O1   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O2   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -O3 -g   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler
.bss.*,"awR"
FAIL: gcc.c-torture/compile/attr-retain-1.c   -Os   scan-assembler
.rodata.*,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O0   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O1   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O2   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -O3 -g   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.bss.used_bss,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.bss.used_bss2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.data.used_data,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.data.used_data2,"awR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.rodata.used_rodata,"aR"
FAIL: gcc.c-torture/compile/attr-retain-2.c   -Os   scan-assembler
.rodata.used_rodata2,"aR"
FAIL: gcc.c-torture/compile/pr29201.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr29201.c   -Os  (test for excess errors)
WARNING: program timed out
FAIL: gcc.c-torture/compile/limits-blockid.c   -O3 -g  (test for excess
errors)
FAIL: gcc.c-torture/execute/pr64242.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr64242.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr84521.c   -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-5.c   

Bug#970043: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Adrian,

On 27.05.24 17:14, John Paul Adrian Glaubitz wrote:

On Sun, 2024-05-26 at 14:09 +0200, Frank Scheiner wrote:

It was also removed because there was no maintainer for it in glibc and
suffered from a lot of testsuite failures. I tried for a long time to
convince Adhemerval to fix these issues, but he explained that it would
involve rewriting large parts of the math code for ia64 which he thought
wasn't worth the effort.


Adhemerval gave his assessment in [2]: "From glibc point of view,
besides the math issues due the ia64 specific math implementation, the
port status seems in order."

[2]: https://sourceware.org/pipermail/libc-alpha/2023-November/152497.html


As I mentioned, getting the math testsuite to pass would require the 
libm_error.c
code to be adapted that it will work with the new error-handling design. Without
that, FPU error handling will remain broken on ia64.


Oh, we did look into that, but then other things became more important. 
Because w/o support in the kernel, no support in the glibc. Clearly sets 
the priorities in my eyes.



There are "some rough spots" mentioned in addition and also that "There
are no emulators widely available, and so boot testing Itanium is
generally infeasible for ordinary contributors.


Well, I've had long discussions over this with Adhemerval and he was more 
reserved
in this announcement mail than in the conversations that we had in private where
he discussed the problems with the port more openly.


Well, maybe he changed his mind since then. I can only refer to public 
communication here and that sounds different to me.



But all this was not the actual reason to remove ia64 support from the
glibc. Joseph Meyers added: "We should remove any architecture removed
from the Linux kernel. [...]" in [3]. And Carlos O'Donell detailed why
in [4]: "[...] We need an upstream kernel to define the ABI for the
port. [...]". Adhemerval also added in a later message ([5]): "Sorry,
but not being upstream is a no start. [...] The best way is to still
remove it and eventually reinstate it if it were the case.".


The kernel removal may be the main reason, but not the only one.


Other than that, we have a working ia64 emulator (Ski) and in the
meantime, also support for it in Linux was restored ([6]).


Sure, as I said, I think these efforts are always laudable. I just don't think
there is any chance on getting support re-added upstream to the Linux kernel
and glibc. The majority of developers will vote against it, as hard as that
sounds.


Yeah, you expressed your opinion on that already multiple times. It 
doesn't convince me. I think we can leave it at that now.


You know, a lot depends on how you define your goals. For me in this 
endeavour, the path is the true goal. Will we get ia64 back into Linux? 
I don't know. But we try to make it happen.



There seem to be different opinions about this "relation": Xi Ruoyao
pointed out the following recently on the binutils mailing list [7]:

```
The reasoning is incorrect.  The dependency chain of a port is:

- Upstream GCC needs upstream Binutils
- Upstream Linux kernel needs upstream GCC
- Upstream Glibc needs upstream Linux kernel

So the removal of IA64 from the Linux kernel means we should remove it
from Glibc, but you cannot reversely traverse the dependency chain and
claim it should be removed from GCC or Binutils.
[...]
```


I know it doesn't _have_ to be removed from GCC and Binutils. However, removing
it will still relieve the codebase quite a bit and allow for a lot of code
refactoring that people have on their TODO stashes.


Such arguments were not expressed in the relevant threads, see the 
thread on [1] again for gcc (also take note of the LRA situation) and 
the thread on [10] for binutils.


[1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html

[10]: https://sourceware.org/pipermail/binutils/2024-May/133998.html


Have you already sorted out who is going to maintain ia64 support in glibc
and the Linux kernel?


Well, since quite a while we maintain out-of-tree versions for both
([8]). Especially for Linux you can follow our progress as replies to
Linus' release messages to the LKML for 6.7, 6.8 and just recently 6.9
([9]) and also on https://lore.kernel.org/linux-ia64/.

[8]: https://github.com/orgs/linux-ia64/repositories

[9]:
https://lore.kernel.org/lkml/d308ad95-bee4-4401-a6f5-27bcf5bcc...@web.de/


There is more involved to maintenance than keeping something buildable and 
bootable.

You will have to review patches, merge them and send pull requests to Linus and 
so on.


You think?

Adrian, keeping something buildable and bootable is the basis and you 
need to start with something. Can we review patches now? Obviously not. 
We can react to what gets merged and fix things that break in between.


Sounds like maintenance to me.


And do you already know how to get Ruby upstream to
re-add ia64 support? Ruby is re

Re: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Adrian,

On 27.05.24 17:14, John Paul Adrian Glaubitz wrote:

On Sun, 2024-05-26 at 14:09 +0200, Frank Scheiner wrote:

It was also removed because there was no maintainer for it in glibc and
suffered from a lot of testsuite failures. I tried for a long time to
convince Adhemerval to fix these issues, but he explained that it would
involve rewriting large parts of the math code for ia64 which he thought
wasn't worth the effort.


Adhemerval gave his assessment in [2]: "From glibc point of view,
besides the math issues due the ia64 specific math implementation, the
port status seems in order."

[2]: https://sourceware.org/pipermail/libc-alpha/2023-November/152497.html


As I mentioned, getting the math testsuite to pass would require the 
libm_error.c
code to be adapted that it will work with the new error-handling design. Without
that, FPU error handling will remain broken on ia64.


Oh, we did look into that, but then other things became more important. 
Because w/o support in the kernel, no support in the glibc. Clearly sets 
the priorities in my eyes.



There are "some rough spots" mentioned in addition and also that "There
are no emulators widely available, and so boot testing Itanium is
generally infeasible for ordinary contributors.


Well, I've had long discussions over this with Adhemerval and he was more 
reserved
in this announcement mail than in the conversations that we had in private where
he discussed the problems with the port more openly.


Well, maybe he changed his mind since then. I can only refer to public 
communication here and that sounds different to me.



But all this was not the actual reason to remove ia64 support from the
glibc. Joseph Meyers added: "We should remove any architecture removed
from the Linux kernel. [...]" in [3]. And Carlos O'Donell detailed why
in [4]: "[...] We need an upstream kernel to define the ABI for the
port. [...]". Adhemerval also added in a later message ([5]): "Sorry,
but not being upstream is a no start. [...] The best way is to still
remove it and eventually reinstate it if it were the case.".


The kernel removal may be the main reason, but not the only one.


Other than that, we have a working ia64 emulator (Ski) and in the
meantime, also support for it in Linux was restored ([6]).


Sure, as I said, I think these efforts are always laudable. I just don't think
there is any chance on getting support re-added upstream to the Linux kernel
and glibc. The majority of developers will vote against it, as hard as that
sounds.


Yeah, you expressed your opinion on that already multiple times. It 
doesn't convince me. I think we can leave it at that now.


You know, a lot depends on how you define your goals. For me in this 
endeavour, the path is the true goal. Will we get ia64 back into Linux? 
I don't know. But we try to make it happen.



There seem to be different opinions about this "relation": Xi Ruoyao
pointed out the following recently on the binutils mailing list [7]:

```
The reasoning is incorrect.  The dependency chain of a port is:

- Upstream GCC needs upstream Binutils
- Upstream Linux kernel needs upstream GCC
- Upstream Glibc needs upstream Linux kernel

So the removal of IA64 from the Linux kernel means we should remove it
from Glibc, but you cannot reversely traverse the dependency chain and
claim it should be removed from GCC or Binutils.
[...]
```


I know it doesn't _have_ to be removed from GCC and Binutils. However, removing
it will still relieve the codebase quite a bit and allow for a lot of code
refactoring that people have on their TODO stashes.


Such arguments were not expressed in the relevant threads, see the 
thread on [1] again for gcc (also take note of the LRA situation) and 
the thread on [10] for binutils.


[1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html

[10]: https://sourceware.org/pipermail/binutils/2024-May/133998.html


Have you already sorted out who is going to maintain ia64 support in glibc
and the Linux kernel?


Well, since quite a while we maintain out-of-tree versions for both
([8]). Especially for Linux you can follow our progress as replies to
Linus' release messages to the LKML for 6.7, 6.8 and just recently 6.9
([9]) and also on https://lore.kernel.org/linux-ia64/.

[8]: https://github.com/orgs/linux-ia64/repositories

[9]:
https://lore.kernel.org/lkml/d308ad95-bee4-4401-a6f5-27bcf5bcc...@web.de/


There is more involved to maintenance than keeping something buildable and 
bootable.

You will have to review patches, merge them and send pull requests to Linus and 
so on.


You think?

Adrian, keeping something buildable and bootable is the basis and you 
need to start with something. Can we review patches now? Obviously not. 
We can react to what gets merged and fix things that break in between.


Sounds like maintenance to me.


And do you already know how to get Ruby upstream to
re-add ia64 support? Ruby is re

Bug#970043: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Otto,

On 25.05.24 06:24, Otto Kekäläinen wrote:

Hi!

I have a patch to tentatively fix Debian package galera-4 builds on
ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19

Would anybody be interested in helping out and testing if the build
fully passes now?

Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043


So, I think your patch solves the build issue for ia64:

Before:
```
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/service_thd_check.cpp.o

Checking library symbol visibility (hidden)
005266c0 lDF .text	0220 
_ZNK4asio6detail11timer_queueINS0_18chrono_time_traitsINSt6chrono3_V212steady_clockENS_11wait_traitsIS5_E18wait_duration_msecEl
00524cc0 lDF .text	0060 
_ZN4asio3ssl5error6detail15stream_categoryD1Ev
00523e80 lDF .text	0010 
_ZN4asio6detail10service_idINS0_22deadline_timer_serviceINS0_18chrono_time_traitsINSt6chrono3_V212steady_clockENS_11wait_traitsIS6_EEED1Ev
0054f840 lDF .text	0010 
_ZN4asio6detail10service_idINS0_23reactive_socket_serviceINS_2ip3udpD1Ev
00524ac0 lDF .text	0060 
_ZN4asio5error6detail14netdb_categoryD1Ev
00525200 lDF .text	0060 
_ZN4asio22service_already_existsD1Ev

[...]
make[2]: *** [galera/src/CMakeFiles/galera_smm.dir/build.make:110: 
libgalera_smm.so] Error 1

make[2]: *** Deleting file 'libgalera_smm.so'
make[1]: *** [CMakeFiles/Makefile2:1837: 
galera/src/CMakeFiles/galera_smm.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/ist_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/saved_state_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/defaults_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/progress_check.cpp.o

[100%] Linking CXX executable galera_check
[100%] Linking CXX executable check_gcomm
[100%] Built target galera_check
[100%] Built target check_gcomm
make: *** [Makefile:166: all] Error 2
2
Sun May 26 19:22:46 UTC 2024
```

After applying the patch:
```
[...]
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/service_thd_check.cpp.o

Checking library symbol visibility (hidden)
Verifying that library is linked with SSL
  NEEDED   libcrypto.so.3
  NEEDED   libssl.so.3
[ 98%] Built target galera_smm
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/ist_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/saved_state_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/defaults_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/progress_check.cpp.o

[ 99%] Linking CXX executable check_gcomm
[ 99%] Built target check_gcomm
[100%] Linking CXX executable galera_check
[100%] Built target galera_check
0

real14m26.065s
user82m39.186s
sys 2m8.359s
Sun May 26 19:54:12 UTC 2024
```

In the end I built it on T2 directly from the cloned sources.

Cheers,
Frank

Re: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Otto,

On 25.05.24 06:24, Otto Kekäläinen wrote:

Hi!

I have a patch to tentatively fix Debian package galera-4 builds on
ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19

Would anybody be interested in helping out and testing if the build
fully passes now?

Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043


So, I think your patch solves the build issue for ia64:

Before:
```
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/service_thd_check.cpp.o

Checking library symbol visibility (hidden)
005266c0 lDF .text	0220 
_ZNK4asio6detail11timer_queueINS0_18chrono_time_traitsINSt6chrono3_V212steady_clockENS_11wait_traitsIS5_E18wait_duration_msecEl
00524cc0 lDF .text	0060 
_ZN4asio3ssl5error6detail15stream_categoryD1Ev
00523e80 lDF .text	0010 
_ZN4asio6detail10service_idINS0_22deadline_timer_serviceINS0_18chrono_time_traitsINSt6chrono3_V212steady_clockENS_11wait_traitsIS6_EEED1Ev
0054f840 lDF .text	0010 
_ZN4asio6detail10service_idINS0_23reactive_socket_serviceINS_2ip3udpD1Ev
00524ac0 lDF .text	0060 
_ZN4asio5error6detail14netdb_categoryD1Ev
00525200 lDF .text	0060 
_ZN4asio22service_already_existsD1Ev

[...]
make[2]: *** [galera/src/CMakeFiles/galera_smm.dir/build.make:110: 
libgalera_smm.so] Error 1

make[2]: *** Deleting file 'libgalera_smm.so'
make[1]: *** [CMakeFiles/Makefile2:1837: 
galera/src/CMakeFiles/galera_smm.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/ist_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/saved_state_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/defaults_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/progress_check.cpp.o

[100%] Linking CXX executable galera_check
[100%] Linking CXX executable check_gcomm
[100%] Built target galera_check
[100%] Built target check_gcomm
make: *** [Makefile:166: all] Error 2
2
Sun May 26 19:22:46 UTC 2024
```

After applying the patch:
```
[...]
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/service_thd_check.cpp.o

Checking library symbol visibility (hidden)
Verifying that library is linked with SSL
  NEEDED   libcrypto.so.3
  NEEDED   libssl.so.3
[ 98%] Built target galera_smm
[ 98%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/ist_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/saved_state_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/defaults_check.cpp.o
[ 99%] Building CXX object 
galera/tests/CMakeFiles/galera_check.dir/progress_check.cpp.o

[ 99%] Linking CXX executable check_gcomm
[ 99%] Built target check_gcomm
[100%] Linking CXX executable galera_check
[100%] Built target galera_check
0

real14m26.065s
user82m39.186s
sys 2m8.359s
Sun May 26 19:54:12 UTC 2024
```

In the end I built it on T2 directly from the cloned sources.

Cheers,
Frank

Bug#970043: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Adrian,

On 26.05.24 10:58, John Paul Adrian Glaubitz wrote:

On Sat, 2024-05-25 at 18:29 +0200, Frank Scheiner wrote:

ia64 support has been removed from glibc, the Linux kernel and soon gcc,


First - ia64 support was actually removed from the glibc **because** it
was removed from Linux.


It was also removed because there was no maintainer for it in glibc and
suffered from a lot of testsuite failures. I tried for a long time to
convince Adhemerval to fix these issues, but he explained that it would
involve rewriting large parts of the math code for ia64 which he thought
wasn't worth the effort.


Adhemerval gave his assessment in [2]: "From glibc point of view, 
besides the math issues due the ia64 specific math implementation, the 
port status seems in order."


[2]: https://sourceware.org/pipermail/libc-alpha/2023-November/152497.html

There are "some rough spots" mentioned in addition and also that "There 
are no emulators widely available, and so boot testing Itanium is 
generally infeasible for ordinary contributors."


But all this was not the actual reason to remove ia64 support from the 
glibc. Joseph Meyers added: "We should remove any architecture removed 
from the Linux kernel. [...]" in [3]. And Carlos O'Donell detailed why 
in [4]: "[...] We need an upstream kernel to define the ABI for the 
port. [...]". Adhemerval also added in a later message ([5]): "Sorry, 
but not being upstream is a no start. [...] The best way is to still 
remove it and eventually reinstate it if it were the case.".


So there was no way to keep it in the glibc w/o kernel support for it.

[3]: https://sourceware.org/pipermail/libc-alpha/2023-November/152498.html

[4]: https://sourceware.org/pipermail/libc-alpha/2023-November/152536.html

[5]: https://sourceware.org/pipermail/libc-alpha/2023-November/152522.html

Other than that, we have a working ia64 emulator (Ski) and in the 
meantime, also support for it in Linux was restored ([6]).


[6]: https://github.com/linux-ia64/linux-stable-rc/actions/runs/9240217959


Second, how did you come to the conclusion that ia64 support will be
removed from the gcc soon?


gcc usually drops support for a target when it's no longer present in the
kernel and glibc.


There seem to be different opinions about this "relation": Xi Ruoyao 
pointed out the following recently on the binutils mailing list [7]:


```
The reasoning is incorrect.  The dependency chain of a port is:

- Upstream GCC needs upstream Binutils
- Upstream Linux kernel needs upstream GCC
- Upstream Glibc needs upstream Linux kernel

So the removal of IA64 from the Linux kernel means we should remove it
from Glibc, but you cannot reversely traverse the dependency chain and
claim it should be removed from GCC or Binutils.
[...]
```

[7]: https://sourceware.org/pipermail/binutils/2024-May/134000.html


That happened in the past and that will happen in the
future, although there are some targets like Blackfin, CRIS and M32R that
are still supported by gcc while being dropped by the kernel.

And since ia64 support has already been marked as deprecated, I expect it
to be removed from gcc soon. Especially, since ia64 adds a lot of complexity
to gcc due to its VLIW design.


From my understanding the main point of the gcc people in regard to 
ia64 is the missing maintainer, but:



Rene said he would step up as maintainer for ia64 in gcc - see the
thread at [1] - and I haven't heard any different since then.

[1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html

@Rene: Can you confirm?


As of now, gcc is still marked as deprecated:


https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=a37113bd00aef1412771f7dd630abebabd444c1f;hb=HEAD#l273



so it will be removed within the next weeks after we have made an archive
copy.

There is no need to fix any bugs on ia64.


Let me correct that for you:

There is no need to fix any bugs for ia64 in Debian (Ports) - as sad as
that is.


Have you already sorted out who is going to maintain ia64 support in glibc
and the Linux kernel?


Well, since quite a while we maintain out-of-tree versions for both 
([8]). Especially for Linux you can follow our progress as replies to 
Linus' release messages to the LKML for 6.7, 6.8 and just recently 6.9 
([9]) and also on https://lore.kernel.org/linux-ia64/.


[8]: https://github.com/orgs/linux-ia64/repositories

[9]: 
https://lore.kernel.org/lkml/d308ad95-bee4-4401-a6f5-27bcf5bcc...@web.de/



And do you already know how to get Ruby upstream to
re-add ia64 support? Ruby is required for a lot of other packages that depend
on it.


Depending on something like Ruby for a lot of packages is a 
short-sightedness that should eventually be fixed. I didn't need it to 
create a working rebuild of Slackware for ia64. Of course, the package 
selection for EPIC Slack is still limited, but I don't hold anyone back 
or advise against trying to use Ruby on it.



As so

Re: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Adrian,

On 26.05.24 10:58, John Paul Adrian Glaubitz wrote:

On Sat, 2024-05-25 at 18:29 +0200, Frank Scheiner wrote:

ia64 support has been removed from glibc, the Linux kernel and soon gcc,


First - ia64 support was actually removed from the glibc **because** it
was removed from Linux.


It was also removed because there was no maintainer for it in glibc and
suffered from a lot of testsuite failures. I tried for a long time to
convince Adhemerval to fix these issues, but he explained that it would
involve rewriting large parts of the math code for ia64 which he thought
wasn't worth the effort.


Adhemerval gave his assessment in [2]: "From glibc point of view, 
besides the math issues due the ia64 specific math implementation, the 
port status seems in order."


[2]: https://sourceware.org/pipermail/libc-alpha/2023-November/152497.html

There are "some rough spots" mentioned in addition and also that "There 
are no emulators widely available, and so boot testing Itanium is 
generally infeasible for ordinary contributors."


But all this was not the actual reason to remove ia64 support from the 
glibc. Joseph Meyers added: "We should remove any architecture removed 
from the Linux kernel. [...]" in [3]. And Carlos O'Donell detailed why 
in [4]: "[...] We need an upstream kernel to define the ABI for the 
port. [...]". Adhemerval also added in a later message ([5]): "Sorry, 
but not being upstream is a no start. [...] The best way is to still 
remove it and eventually reinstate it if it were the case.".


So there was no way to keep it in the glibc w/o kernel support for it.

[3]: https://sourceware.org/pipermail/libc-alpha/2023-November/152498.html

[4]: https://sourceware.org/pipermail/libc-alpha/2023-November/152536.html

[5]: https://sourceware.org/pipermail/libc-alpha/2023-November/152522.html

Other than that, we have a working ia64 emulator (Ski) and in the 
meantime, also support for it in Linux was restored ([6]).


[6]: https://github.com/linux-ia64/linux-stable-rc/actions/runs/9240217959


Second, how did you come to the conclusion that ia64 support will be
removed from the gcc soon?


gcc usually drops support for a target when it's no longer present in the
kernel and glibc.


There seem to be different opinions about this "relation": Xi Ruoyao 
pointed out the following recently on the binutils mailing list [7]:


```
The reasoning is incorrect.  The dependency chain of a port is:

- Upstream GCC needs upstream Binutils
- Upstream Linux kernel needs upstream GCC
- Upstream Glibc needs upstream Linux kernel

So the removal of IA64 from the Linux kernel means we should remove it
from Glibc, but you cannot reversely traverse the dependency chain and
claim it should be removed from GCC or Binutils.
[...]
```

[7]: https://sourceware.org/pipermail/binutils/2024-May/134000.html


That happened in the past and that will happen in the
future, although there are some targets like Blackfin, CRIS and M32R that
are still supported by gcc while being dropped by the kernel.

And since ia64 support has already been marked as deprecated, I expect it
to be removed from gcc soon. Especially, since ia64 adds a lot of complexity
to gcc due to its VLIW design.


From my understanding the main point of the gcc people in regard to 
ia64 is the missing maintainer, but:



Rene said he would step up as maintainer for ia64 in gcc - see the
thread at [1] - and I haven't heard any different since then.

[1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html

@Rene: Can you confirm?


As of now, gcc is still marked as deprecated:


https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=a37113bd00aef1412771f7dd630abebabd444c1f;hb=HEAD#l273



so it will be removed within the next weeks after we have made an archive
copy.

There is no need to fix any bugs on ia64.


Let me correct that for you:

There is no need to fix any bugs for ia64 in Debian (Ports) - as sad as
that is.


Have you already sorted out who is going to maintain ia64 support in glibc
and the Linux kernel?


Well, since quite a while we maintain out-of-tree versions for both 
([8]). Especially for Linux you can follow our progress as replies to 
Linus' release messages to the LKML for 6.7, 6.8 and just recently 6.9 
([9]) and also on https://lore.kernel.org/linux-ia64/.


[8]: https://github.com/orgs/linux-ia64/repositories

[9]: 
https://lore.kernel.org/lkml/d308ad95-bee4-4401-a6f5-27bcf5bcc...@web.de/



And do you already know how to get Ruby upstream to
re-add ia64 support? Ruby is required for a lot of other packages that depend
on it.


Depending on something like Ruby for a lot of packages is a 
short-sightedness that should eventually be fixed. I didn't need it to 
create a working rebuild of Slackware for ia64. Of course, the package 
selection for EPIC Slack is still limited, but I don't hold anyone back 
or advise against trying to use Ruby on it.



As so

Bug#970043: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Adrian,

On 25.05.24 10:38, John Paul Adrian Glaubitz wrote:

Hi Otto,

On Fri, 2024-05-24 at 21:24 -0700, Otto Kekäläinen wrote:

I have a patch to tentatively fix Debian package galera-4 builds on
ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19

Would anybody be interested in helping out and testing if the build
fully passes now?

Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043


ia64 support has been removed from glibc, the Linux kernel and soon gcc,


First - ia64 support was actually removed from the glibc **because** it 
was removed from Linux.


Second, how did you come to the conclusion that ia64 support will be 
removed from the gcc soon?


Rene said he would step up as maintainer for ia64 in gcc - see the 
thread at [1] - and I haven't heard any different since then.


[1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html

@Rene: Can you confirm?


so it will be removed within the next weeks after we have made an archive
copy.

There is no need to fix any bugs on ia64.


Let me correct that for you:

There is no need to fix any bugs for ia64 in Debian (Ports) - as sad as 
that is.


Cheers,
Frank

Re: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Otto,

On 25.05.24 06:24, Otto Kekäläinen wrote:

I have a patch to tentatively fix Debian package galera-4 builds on
ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19

Would anybody be interested in helping out and testing if the build
fully passes now?


I could try to build it for Slackware, though I first will have to build 
all the required stuff (or at least "boost" IIUC) - which will take me 
some time.



Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043


Thanks for that.

Cheers,
Frank

Re: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Adrian,

On 25.05.24 10:38, John Paul Adrian Glaubitz wrote:

Hi Otto,

On Fri, 2024-05-24 at 21:24 -0700, Otto Kekäläinen wrote:

I have a patch to tentatively fix Debian package galera-4 builds on
ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19

Would anybody be interested in helping out and testing if the build
fully passes now?

Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043


ia64 support has been removed from glibc, the Linux kernel and soon gcc,


First - ia64 support was actually removed from the glibc **because** it 
was removed from Linux.


Second, how did you come to the conclusion that ia64 support will be 
removed from the gcc soon?


Rene said he would step up as maintainer for ia64 in gcc - see the 
thread at [1] - and I haven't heard any different since then.


[1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html

@Rene: Can you confirm?


so it will be removed within the next weeks after we have made an archive
copy.

There is no need to fix any bugs on ia64.


Let me correct that for you:

There is no need to fix any bugs for ia64 in Debian (Ports) - as sad as 
that is.


Cheers,
Frank

Bug#970043: Request to help test ia64 build for galera-4

[Frank Scheiner]

Hi Otto,

On 25.05.24 06:24, Otto Kekäläinen wrote:

I have a patch to tentatively fix Debian package galera-4 builds on
ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19

Would anybody be interested in helping out and testing if the build
fully passes now?


I could try to build it for Slackware, though I first will have to build 
all the required stuff (or at least "boost" IIUC) - which will take me 
some time.



Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043


Thanks for that.

Cheers,
Frank

Re: Linux 6.9

[Frank Scheiner]

Dear all,

here comes the usual update on Linux/ia64:

The reason for the userland regression we mentioned last time (in [1])
was found and fixed shortly after the release of v6.8.

[1]:
https://lore.kernel.org/all/145da253-b3bc-43da-a262-a3ebdfbea...@web.de/

Furthermore there were no new hard regressions detected in addition to
what was reported in [2] already. If you have an ia64 machine with more
than 64 hardware threads and want to run Linux on it, get in touch with
us. :-)

[2]:
https://lore.kernel.org/linux-ia64/cahtyxddy5lub_uemqrgr8o_g-xk0_xrd3j7wvb9t9rrd5x6...@mail.gmail.com/

Again all ia64 machines (see [3] for a list) and platforms (HP Sim on
Ski) we have available for testing continue to work, no system support
was lost during this cycle.

[3]:
https://lore.kernel.org/all/fe5f6e9b-02a2-42e9-8151-ae4b6fdba...@web.de/

In the meantime gcc-14 was released, meaning that the regular
compilation and testing of Linux mainline release (candidates) switched
to gcc-15 snapshots now (starting with v6.9-rc6). Enabling LRA for the
cross-compiler continues to make **no problems** for ia64 kernels. The
same is true with the switch to binutils 2.42 since v6.9-rc2.



Last time ([1]) we had to report about an approaching decrease in the
number of available Linux distributions with support for ia64. This was
sad to report, also because options are important.

But don't worry, the distro options for your ia64 gear just have
increased again:

Enter **EPIC Slack** ([4]) - an unofficial "port" of Slackware for ia64
that was started recently and - though still work in progress - is
already network booting on all test machines available to us. If you're
too young to know what Slackware is, head over to [5] and learn more
about it (-;.

[4]: http://epic-slack.org/

[5]: http://www.slackware.com/



Thank you all for your hard work on Linux!

Cheers,
Frank et al

Re: Second GCC 14.1 Release Candidate available from gcc.gnu.org

[Frank Scheiner via Gcc]

Bootstrapping the following configuration (with LRA enabled) looks good
for ia64, too:

```
CFLAGS="-O2 -fPIC" \
CXXFLAGS="-O2 -fPIC" \
../configure --prefix=/usr \
--enable-obsolete \
--libdir=/usr/lib \
--mandir=/usr/man \
--infodir=/usr/info \
--enable-shared \
--enable-bootstrap \
--enable-languages=c,c++,fortran \
--enable-threads=posix \
--enable-checking=release \
--with-system-zlib \
--enable-libstdcxx-dual-abi \
--with-default-libstdcxx-abi=new \
--disable-libstdcxx-pch \
--disable-libunwind-exceptions \
--enable-__cxa_atexit \
--disable-libssp \
--enable-gnu-unique-object \
--enable-plugin \
--disable-lto \
--disable-install-libiberty \
--disable-werror \
--with-gnu-ld \
--with-isl \
--verbose \
--with-arch-directory=ia64 \
--disable-gtktest \
--enable-clocale=gnu \
--disable-multilib \
--target=ia64-t2-linux-gnu \
--build=ia64-t2-linux-gnu \
--host=ia64-t2-linux-gnu
```

The addition of fortran to the enabled languages adds about 20 mins to
the bootstrap timings mentioned on [1] for the same machine (and just c
and c++):

```
time make -j9 bootstrap-lean
[...]
real295m51.942s
user2072m18.957s
sys29m0.798s
```

[1]: https://gcc.gnu.org/pipermail/gcc/2024-May/243870.html

Running the testsuites for gcc and g++ (this time with `-j4` for each,
dropping the time needed for each down to about 114 mins from 4.5 to 5
hours when each testsuite only uses one hardware thread) shows some
differences in test results compared to the results with RC1:

```
=== gcc Summary ===

gcc-14  RC2 RC1

# of expected passes133497  134528
# of unexpected failures916 909
# of unexpected successes   18  18
# of expected failures  13541365
# of unresolved testcases   20  20
# of unsupported tests  30333033

=== g++ Summary ===

gcc-14  RC2 RC1

# of expected passes246657  247363
# of unexpected failures213 200
# of expected failures  25932595
# of unresolved testcases   5   5
# of unsupported tests  11497   11496
```

For RC2 the results are aggregated from the four separate results for
each testsuite. As the failures do not increase by the same amount as
the number of expect passes decreased, I assume this is "only" an effect
of using multiple make jobs.

This is "similar" for libgomp (duration around 60 mins, with `j4`,
around 51 mins w/o `-j`), though the number of expected passes more than
doubles for the parallel case compared to the serial case, so maybe
aggregating the results for this testsuite is not correct.

I don't have enough comparison data yet for the other testsuites I ran:

* gfortran (duration around 100 mins, with `j4`)
* libatomic (duration 12 seconds, w/o `-j` ;-) )
* libstdc++ (duration around 5 hours, with `-j4`)

...to be able to tell, if the results are any worse or better. But I at
least figured out that adding `-j4` for the libstdc++ testsuite makes it
complete in just a little longer than 5 hours instead of no completion
in more than 10 hours on the same hardware mentioned in [1].

This also means that the "whole" testsuite for the configuration above
might be able to complete in around 6 hours if gcc, g++ and gfortran are
done in parallel to libstdc++ and libgomp (after libstdc++ has finished)
- IINM.

Cheers,
Frank

On 03.05.24 22:57, Jakub Jelinek via Gcc wrote:

The second release candidate for GCC 14.1 is available from

  https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/
  ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240503/

and shortly its mirrors.  It has been generated from git commit
r14-10165-g3b4d6b6ecd79df790.

The https://gcc.gnu.org/PR114935 bug has been reported and determined
a release blocker, so we'd like to get extra testing on it prior to
the release.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, we'd still like to release 14.1 on Tuesday, May 7th.

Re: GCC 14.1 Release Candidate available from gcc.gnu.org

[Frank Scheiner via Gcc]

Bootstrapping the following configuration (with LRA enabled) looks good
for ia64, too:

```
CFLAGS="-O2 -fPIC" \
CXXFLAGS="-O2 -fPIC" \
../configure --prefix=/usr \
--enable-obsolete \
--libdir=/usr/lib \
--mandir=/usr/man \
--infodir=/usr/info \
--enable-shared \
--enable-bootstrap \
--enable-languages=c,c++ \
--enable-threads=posix \
--enable-checking=release \
--with-system-zlib \
--enable-libstdcxx-dual-abi \
--with-default-libstdcxx-abi=new \
--disable-libstdcxx-pch \
--disable-libunwind-exceptions \
--enable-__cxa_atexit \
--disable-libssp \
--enable-gnu-unique-object \
--enable-plugin \
--disable-lto \
--disable-install-libiberty \
--disable-werror \
--with-gnu-ld \
--with-isl \
--verbose \
--with-arch-directory=ia64 \
--disable-gtktest \
--enable-clocale=gnu \
--disable-multilib \
--target=ia64-t2-linux-gnu \
--build=ia64-t2-linux-gnu \
--host=ia64-t2-linux-gnu
```

Took a little more than 4.5 hours on a rx2800 i2 w/1 x Itanium 2 9320
when performed below `/dev/shm`:

```
time make -j9
[...]
real275m54.878s
user1907m4.200s
sys 23m48.405s
```

Running the gcc and g++ testsuites in parallel now. Should take another
5 hours or so...

Cheers,
Frank

On 30.04.24 12:33, Jakub Jelinek via Gcc wrote:

The first release candidate for GCC 14.1 is available from

  https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/
  ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/

and shortly its mirrors.  It has been generated from git commit
r14-10154-g7a00c459cbb913a.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 14.1 on Tuesday, May 7th.

[ia64] HP Sim: gcc-14-20240407 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

root@dl380-g7:~/ski-test# time ./run_ski_test.bash
/usr/src/ski/ski-bootloader/ski-bootloader
/boot/vmlinux-6.9.0-rc3-34c5257535e9-ia64-00023-g34c5257535e9-dirty
Ski commandline:
bski /usr/src/ski/ski-bootloader/ski-bootloader
/boot/vmlinux-6.9.0-rc3-34c5257535e9-ia64-00023-g34c5257535e9-dirty
root=/dev/sda simscsi=./sd simeth=enp3s0f0 init=/root/bin/ski_test.bash
PATH=/bin:/sbin:/usr/bin:/usr/sbin rw memblock=debug &
loading
/boot/vmlinux-6.9.0-rc3-34c5257535e9-ia64-00023-g34c5257535e9-dirty...
probing initramfs ...
initramfs not passed
starting kernel...
Linux version 6.9.0-rc3-34c5257535e9-ia64-00023-g34c5257535e9-dirty
(root@dl380-g7) (ia64-linux-gcc (GCC) 14.0.1 20240405 (experimental),
GNU ld (GNU Binutils) 2.42) #1 SMP PREEMPT Mon Apr  8 12:59:55 CEST 2024
efi: EFI v1.0 by Hewlett-Packard
efi: SALsystab=0x10a510
warning: unable to switch EFI into virtual mode (status=131)
No I/O port range found in EFI memory map, falling back to AR.KR0
(0xc00)
printk: legacy console [simcons0] enabled
memblock_reserve: [0x-0x005f]
reserve_memory+0x3e0/0x440
memblock_reserve: [0x0010a5a0-0x0010a63f]
reserve_memory+0x3e0/0x440
memblock_reserve: [0x0010a640-0x0010a68f]
reserve_memory+0x3e0/0x440
memblock_reserve: [0x0010a690-0x0010a70d]
reserve_memory+0x3e0/0x440
memblock_reserve: [0x0400-0x051154cf]
reserve_memory+0x3e0/0x440
memblock_add_node: [0x-0x00017fff] nid=0 flags=0
find_memory+0xb0/0x1a0
memblock_alloc_try_nid: 262144 bytes align=0x4 nid=-1
from=0x0001 max_addr=0x find_memory+0x120/0x1a0
memblock_reserve: [0x00017ffc-0x00017fff]
memblock_alloc_range_nid+0x1f0/0x360
SAL 0.1: Hewlett-Packard HP-simulator version 0.0
get_cache_info: ia64_pal_cache_summary() failed (status=-1)
PAL_VM_PAGE_SIZE failed with status=-1; defaulting to architected purge
page-sizes.
memblock_alloc_try_nid: 131072 bytes align=0x1 nid=-1
from=0x max_addr=0x mca_bootmem+0x30/0x80
memblock_reserve: [0x00017ffa-0x00017ffb]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 262144 bytes align=0x80 nid=-1
from=0x max_addr=0x
mmu_context_init+0x60/0x140
memblock_reserve: [0x00017ff6-0x00017ff9]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 262144 bytes align=0x80 nid=-1
from=0x max_addr=0x
mmu_context_init+0xd0/0x140
memblock_reserve: [0x00017ff2-0x00017ff5]
memblock_alloc_range_nid+0x1f0/0x360
MCA related initialization done
Zone ranges:
  DMA32[mem 0x-0x]
  Normal   [mem 0x0001-0x00017fff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x-0x00017fff]
Initmem setup node 0 [mem 0x-0x00017fff]
memblock_alloc_try_nid_raw: 7340032 bytes align=0x80 nid=0
from=0x max_addr=0x
free_area_init+0x1690/0x1d40
memblock_reserve: [0x00017f82-0x00017ff1]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=0 from=0x
max_addr=0x setup_usemap+0xf0/0x160
memblock_reserve: [0x00017f81ff80-0x00017f81ff87]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=0 from=0x
max_addr=0x setup_usemap+0xf0/0x160
memblock_reserve: [0x00017f81ff00-0x00017f81ff07]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 126 bytes align=0x80 nid=-1
from=0x max_addr=0x start_kernel+0x140/0xba0
memblock_reserve: [0x00017f81fe80-0x00017f81fefd]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 126 bytes align=0x80 nid=-1
from=0x max_addr=0x start_kernel+0x180/0xba0
memblock_reserve: [0x00017f81fe00-0x00017f81fe7d]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 65536 bytes align=0x1 nid=-1
from=0x max_addr=0x
pcpu_alloc_alloc_info+0xe0/0x1e0
memblock_reserve: [0x00017f80-0x00017f80]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x830/0x15c0
memblock_reserve: [0x00017f81fd80-0x00017f81fd87]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x880/0x15c0
memblock_reserve: [0x00017f81fd00-0x00017f81fd07]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 4 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x8c0/0x15c0
memblock_reserve: 

[ia64] rx2800 i2: gcc-14-20240407 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC10027B.initrd.img...done
[0.00] Linux version
6.9.0-rc3-34c5257535e9-ia64-w-gcc-14-20240407-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240405 (experimental), GNU ld (GNU
Binutils) 2.42) #1 SMP Mon Apr  8 12:53:48 CEST 2024
[0.00] efi: EFI v2.1 by HP
[0.00] efi: SALsystab=0xdfdd63a18 ESI=0xdfdd63f18 ACPI
2.0=0x3d3c4014 HCDP=0xd8798 SMBIOS=0x3d368000
[0.00] PCDP: v3 at 0xd8798
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3D3C4014 24 (v02 HP)
[0.00] ACPI: XSDT 0x3D3C4580 000124 (v01 HP RX2800-2
0001  0113)
[0.00] ACPI: FACP 0x3D3BE000 F4 (v03 HP RX2800-2
0001 HP   0001)
[0.00] ACPI BIOS Warning (bug): Invalid length for
FADT/Pm1aEventBlock: 16, using default 32 (20230628/tbfadt-669)
[0.00] ACPI BIOS Warning (bug): Invalid length for
FADT/Pm1aControlBlock: 32, using default 16 (20230628/tbfadt-669)
[0.00] ACPI: DSDT 0x3D3A4000 009E45 (v02 HP RX2800-2
0008 INTL 20061109)
[0.00] ACPI: FACS 0x3D3C 40
[0.00] ACPI: FACS 0x3D3C 40
[0.00] ACPI: APIC 0x3D3C2000 00010C (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SPCR 0x3D3BC000 50 (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SRAT 0x3D3BA000 0001F8 (v02 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SLIT 0x3D3B8000 3C (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: CPEP 0x3D3B6000 34 (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SPMI 0x3D3B4000 41 (v05 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: DBGP 0x3D3B2000 34 (v00 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: HPET 0x3D3B 38 (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: DMAR 0x3D3AE000 CC (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SSDT 0x3D3A2000 A9 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D3A E2 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39E000 A8 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39C000 0014E9 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39A000 92 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D398000 92 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D396000 24 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D394000 000114 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D392000 35 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39 80 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38E000 000699 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38C000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38A000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D388000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D386000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D384000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D382000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38 A4 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37E000 000276 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37C000 BE (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37A000 36 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D378000 CF (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 16 CPUs total
[0.00] Number of logical nodes in system = 1
[0.00] Number of memory chunks in system = 3
[0.00] Initial ramdisk at: 0xe00deb1fb000 (49705020 bytes)
[0.00] SAL 3.20: HP Kauai version 3.1
[0.00] SAL: AP wakeup using external interrupt vector 0xf0
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x000d]
[0.00] Movable zone start for each node
[

[ia64] rx6600: gcc-14-20240407 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100287.initrd.img...done
[0.00] Linux version
6.9.0-rc3-34c5257535e9-ia64-w-gcc-14-20240407-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240405 (experimental), GNU ld (GNU
Binutils) 2.42) #1 SMP Mon Apr  8 12:53:48 CEST 2024
[0.00] efi: EFI v2.0 by HP
[0.00] efi: SALsystab=0x3e528000 ACPI 2.0=0x3fdd
ESI=0x3e529000 SMBIOS=0x3e52a000 HCDP=0x3fdce000
[0.00] PCDP: v3 at 0x3fdce000
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FDD 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FDD002C 000114 (v01 HP rx6600
 HP   )
[0.00] ACPI: FACP 0x3FDF5B18 F4 (v03 HP rx6600
 HP   )
[0.00] ACPI: DSDT 0x3FDD01C8 019E62 (v01 HP rx6600
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FDF5C10 40
[0.00] ACPI: SPCR 0x3FDF5C50 50 (v01 HP
 HP   )
[0.00] ACPI: DBGP 0x3FDF5CA0 34 (v01 HP rx6600
 HP   )
[0.00] ACPI: APIC 0x3FDF60C0 000178 (v01 HP rx6600
 HP   )
[0.00] ACPI: SPMI 0x3FDF5CD8 50 (v04 HP rx6600
 HP   )
[0.00] ACPI: CPEP 0x3FDF5F90 34 (v01 HP rx6600
 HP   )
[0.00] ACPI: SSDT 0x3FDEA038 0004B3 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEA4F8 0022BF (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEC7B8 001277 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEDA38 0012BD (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEECF8 001214 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEFF18 00225F (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF2178 0012CA (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3448 0012CA (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4718 000138 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4858 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4998 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4AD8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4C18 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4D58 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4E98 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4FD8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5118 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5258 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5398 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF54D8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5618 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5758 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5898 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF59D8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 16 CPUs available, 16 CPUs total
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] Initial ramdisk at: 0xe100f72bc000 (49705020 bytes)
[0.00] SAL 3.20: HP version 4.11
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x4000-0x]
[0.00]   Normal   [mem 0x0001-0x0100]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x4000-0x3dcb3fff]
[0.00]   node   0: [mem 0x3e19c000-0x3e527fff]
[0.00]   node   0: [mem 0x3fc0-0x3fd5bfff]
[0.00]   node   0: [mem 0x3fd6-0x3fd63fff]
[0.00]   node   0: [mem 0x3fdc8000-0x3fdcbfff]
[0.00]   node   0: [mem 0x0001-0x0005]
[0.00]   node   

[ia64] rx2660: gcc-14-20240407 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

  Booting `T2 (diskless)'

Loading Linux kernel ...
Loading initial ramdisk ...
[0.00] Linux version
6.9.0-rc3-34c5257535e9-ia64-w-gcc-14-20240407-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240405 (experimental), GNU ld (GNU
Binutils) 2.42) #1 SMP Mon Apr  8 12:53:48 CEST 2024
[0.00] efi: EFI v2.0 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fde4000
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fde2000
[0.00] PCDP: v3 at 0x3fde2000
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FDE4000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FDE402C BC (v01 HP rx2660
 HP   )
[0.00] ACPI: FACP 0x3FDF6048 F4 (v03 HP rx2660
 HP   )
[0.00] ACPI: DSDT 0x3FDE41C8 00E566 (v01 HP rx2660
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FDF6140 40
[0.00] ACPI: SPCR 0x3FDF6180 50 (v01 HP
 HP   )
[0.00] ACPI: DBGP 0x3FDF61D0 34 (v01 HP rx2660
 HP   )
[0.00] ACPI: APIC 0x3FDF65F0 E8 (v01 HP rx2660
 HP   )
[0.00] ACPI: SPMI 0x3FDF6208 50 (v04 HP rx2660
 HP   )
[0.00] ACPI: CPEP 0x3FDF64C0 34 (v01 HP rx2660
 HP   )
[0.00] ACPI: SSDT 0x3FDF2738 0004B3 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF2BF8 000456 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3058 000EB8 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3F18 000866 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4788 000EB8 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5648 000138 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5788 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF58C8 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5A08 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5B48 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5C88 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5DC8 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5F08 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 8 CPUs total
[0.00] Initial ramdisk at: 0xe0002bd62000 (49705020 bytes)
[0.00] SAL 3.20: HP version 4.4
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0100]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3e67]
[0.00]   node   0: [mem 0x3eaec000-0x3ee77fff]
[0.00]   node   0: [mem 0x3fc0-0x3fd5]
[0.00]   node   0: [mem 0x3fd74000-0x3fd77fff]
[0.00]   node   0: [mem 0x3fddc000-0x3fdd]
[0.00]   node   0: [mem 0x0001-0x0007]
[0.00]   node   0: [mem 0x01004000-0x0100ff1fbfff]
[0.00]   node   0: [mem 0x0100ff20-0x0100]
[0.00] Initmem setup node 0 [mem
0x0100-0x0100]
[0.00] On node 0, zone DMA32: 1024 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 283 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 866 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 5 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 25 pages in unavailable ranges
[0.00] On node 0, zone Normal: 136 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] pcpu-alloc: s36008 r8192 d217944 u262144 alloc=16*16384
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
[0.00] Kernel command line: BOOT_IMAGE=(tftp)/AC100263.vmlinuz
root=172.16.0.2:/srv/nfs/rx2660/root/ rw loglevel=9
modprobe.blacklist=radeon hostname=rx2660 console=ttyS1
[0.00] Unknown kernel command line parameters
"BOOT_IMAGE=(tftp)/AC100263.vmlinuz", will be passed to user space.
[0.00] Dentry cache hash table entries: 4194304 (order: 11,
33554432 

[ia64] rx2620: gcc-14-20240407 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100221.initrd.img...done
[0.00] Linux version
6.9.0-rc3-34c5257535e9-ia64-w-gcc-14-20240407-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240405 (experimental), GNU ld (GNU
Binutils) 2.42) #1 SMP Mon Apr  8 12:53:48 CEST 2024
[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fe2a000
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fe28000
[0.00] PCDP: v3 at 0x3fe28000
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE2A000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2A02C CC (v01 HP rx2620
 HP   )
[0.00] ACPI: FACP 0x3FE35CE8 F4 (v03 HP rx2620
 HP   )
[0.00] ACPI: DSDT 0x3FE2A1C8 008390 (v01 HP rx2620
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FE35DE0 40
[0.00] ACPI: SPCR 0x3FE35E20 50 (v01 HP rx2620
 HP   )
[0.00] ACPI: DBGP 0x3FE35E70 34 (v01 HP rx2620
 HP   )
[0.00] ACPI: APIC 0x3FE36090 000108 (v01 HP rx2620
 HP   )
[0.00] ACPI: SPMI 0x3FE35EA8 50 (v04 HP rx2620
 HP   )
[0.00] ACPI: CPEP 0x3FE35F60 34 (v01 HP rx2620
 HP   )
[0.00] ACPI: SSDT 0x3FE32568 0001A7 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE32718 0007DB (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE32EF8 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE33788 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE34018 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE348A8 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35138 0001A9 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE352E8 000138 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35428 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35568 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE356A8 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE357E8 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35928 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35A68 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35BA8 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 8 CPUs total
[0.00] Initial ramdisk at: 0xe040f70bc000 (49705020 bytes)
[0.00] SAL 3.1: HP version 4.29
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0040]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3e873fff]
[0.00]   node   0: [mem 0x3eb9-0x3ee77fff]
[0.00]   node   0: [mem 0x3fc0-0x3fe27fff]
[0.00]   node   0: [mem 0x0001-0x000102373fff]
[0.00]   node   0: [mem 0x000102378000-0x000104373fff]
[0.00]   node   0: [mem 0x000104378000-0x000104b73fff]
[0.00]   node   0: [mem 0x000104b78000-0x000105573fff]
[0.00]   node   0: [mem 0x000105578000-0x000106b73fff]
[0.00]   node   0: [mem 0x000106b78000-0x000111573fff]
[0.00]   node   0: [mem 0x000111578000-0x000117d73fff]
[0.00]   node   0: [mem 0x000117d78000-0x000120373fff]
[0.00]   node   0: [mem 0x000120378000-0x000140173fff]
[0.00]   node   0: [mem 0x000140178000-0x000142173fff]
[0.00]   node   0: [mem 0x000142178000-0x000142773fff]
[0.00]   node   0: [mem 0x000142778000-0x000142f73fff]
[0.00]   node   0: [mem 0x000142f78000-0x000160f73fff]
[0.00]   node   0: [mem 0x000160f78000-0x000164f73fff]
[0.00]   node   0: [mem 0x000164f78000-0x0003bfff]
[0.00]   node   0: [mem 0x00404000-0x0040feffbfff]
[0.00]   node   0: [mem 0x0040ff00-0x0040ffcabfff]
[0.00]   node   

[ia64] rx4640: gcc-14-20240407 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC10025C.initrd.img...done
[0.00] Linux version
6.9.0-rc3-34c5257535e9-ia64-w-gcc-14-20240407-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240405 (experimental), GNU ld (GNU
Binutils) 2.42) #1 SMP Mon Apr  8 12:53:48 CEST 2024
[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3e528000 ACPI 2.0=0x3fe22000
ESI=0x3e529000 SMBIOS=0x3e52a000 HCDP=0x3fe2
[0.00] PCDP: v3 at 0x3fe2
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE22000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2202C A4 (v01 HP rx4640
 HP   )
[0.00] ACPI: FACP 0x3FE36EB8 F4 (v03 HP rx4640
 HP   )
[0.00] ACPI: DSDT 0x3FE221C8 00D0F5 (v01 HP rx4640
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FE36FB0 40
[0.00] ACPI: SPCR 0x3FE36FF0 50 (v01 HP rx4640
 HP   )
[0.00] ACPI: DBGP 0x3FE37040 34 (v01 HP rx4640
 HP   )
[0.00] ACPI: APIC 0x3FE37260 C8 (v01 HP rx4640
 HP   )
[0.00] ACPI: SPMI 0x3FE37078 50 (v04 HP rx4640
 HP   )
[0.00] ACPI: CPEP 0x3FE37130 34 (v01 HP rx4640
 HP   )
[0.00] ACPI: SSDT 0x3FE2F2C8 0001A7 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE2F478 000F65 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE303E8 0011CD (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE315B8 0021B5 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE33778 0021B5 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35938 0011CD (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36B08 DC (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36BE8 E0 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36CD8 E0 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36DC8 E0 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 4 CPUs available, 4 CPUs total
[0.00] Initial ramdisk at: 0xe040f70bc000 (49705020 bytes)
[0.00] SAL 3.1: HP version 4.29
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0040]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3df23fff]
[0.00]   node   0: [mem 0x3e23c000-0x3e527fff]
[0.00]   node   0: [mem 0x3fc0-0x3fe1]
[0.00]   node   0: [mem 0x0001-0x0003bfff]
[0.00]   node   0: [mem 0x00404000-0x0040feffbfff]
[0.00]   node   0: [mem 0x0040ff00-0x0040ffcbbfff]
[0.00]   node   0: [mem 0x0040ffcf8000-0x0040ffe0]
[0.00]   node   0: [mem 0x0040ffe8-0x0040fffdbfff]
[0.00] Initmem setup node 0 [mem
0x0100-0x0040fffdbfff]
[0.00] On node 0, zone DMA32: 1024 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 198 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 1462 pages in unavailable ranges
[0.00] On node 0, zone Normal: 120 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] On node 0, zone Normal: 15 pages in unavailable ranges
[0.00] On node 0, zone Normal: 28 pages in unavailable ranges
[0.00] On node 0, zone Normal: 9 pages in unavailable ranges
[0.00] pcpu-alloc: s36008 r8192 d217944 u262144 alloc=16*16384
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[0.00] Kernel command line: BOOT_IMAGE=net0:/AC10025C.vmlinuz
root=172.16.0.2:/srv/nfs/rx4640/root/ rw loglevel=9
modprobe.blacklist=radeon hostname=rx4640 console=ttyS1
[0.00] Unknown kernel command line parameters
"BOOT_IMAGE=net0:/AC10025C.vmlinuz", will be passed to user space.
[0.00] Dentry cache hash table entries: 2097152 (order: 10,
16777216 bytes, linear)
[0.00] Inode-cache hash table entries: 1048576 (order: 9,
8388608 bytes, linear)
[0.00] Sorting __ex_table...
[  

[ia64] Combined gcc(-14) snapshot and Linux mainline testing cont.

[Frank Scheiner via Gcc-testresults]

Hi all,

Please note that the results following this message can differ to some
degree from the results from last week, due to:

* New minor Linux kernel version: v6.9-rc2 => v6.9-rc3

In the following I'll send the resulting boot logs for the tested
machines and the HP Sim platform.

Cheers,
Frank

P.S.
For an introduction to these test results, please see [1].

[1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-March/810113.html

[ia64] HP Sim: gcc-14-20240331 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

root@dl380-g7:~/ski-test# time ./run_ski_test.bash
/usr/src/ski/ski-bootloader/ski-bootloader
/boot/vmlinux-6.9.0-rc2-53f733c9-ia64-ski-00023-g53f733c9-dirty
loading
/boot/vmlinux-6.9.0-rc2-53f733c9-ia64-ski-00023-g53f733c9-dirty...
probing initramfs ...
initramfs not passed
starting kernel...
Linux version 6.9.0-rc2-53f733c9-ia64-ski-00023-g53f733c9-dirty
(root@dl380-g7) (ia64-linux-gcc (GCC) 14.0.1 20240331 (experimental),
GNU ld (GNU Binutils) 2.42) #1 SMP PREEMPT Tue Apr  2 12:05:09 CEST 2024
efi: EFI v1.0 by Hewlett-Packard
efi: SALsystab=0x10a510
warning: unable to switch EFI into virtual mode (status=131)
No I/O port range found in EFI memory map, falling back to AR.KR0
(0xc00)
printk: legacy console [simcons0] enabled
memblock_reserve: [0x-0x005f]
reserve_memory+0x3e0/0x440
memblock_reserve: [0x0010a5a0-0x0010a63f]
reserve_memory+0x3e0/0x440
memblock_reserve: [0x0010a640-0x0010a68f]
reserve_memory+0x3e0/0x440
memblock_reserve: [0x0010a690-0x0010a70d]
reserve_memory+0x3e0/0x440
memblock_reserve: [0x0400-0x051154cf]
reserve_memory+0x3e0/0x440
memblock_add_node: [0x-0x00017fff] nid=0 flags=0
find_memory+0xb0/0x1a0
memblock_alloc_try_nid: 262144 bytes align=0x4 nid=-1
from=0x0001 max_addr=0x find_memory+0x120/0x1a0
memblock_reserve: [0x00017ffc-0x00017fff]
memblock_alloc_range_nid+0x1f0/0x360
SAL 0.1: Hewlett-Packard HP-simulator version 0.0
get_cache_info: ia64_pal_cache_summary() failed (status=-1)
PAL_VM_PAGE_SIZE failed with status=-1; defaulting to architected purge
page-sizes.
memblock_alloc_try_nid: 131072 bytes align=0x1 nid=-1
from=0x max_addr=0x mca_bootmem+0x30/0x80
memblock_reserve: [0x00017ffa-0x00017ffb]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 262144 bytes align=0x80 nid=-1
from=0x max_addr=0x
mmu_context_init+0x60/0x140
memblock_reserve: [0x00017ff6-0x00017ff9]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 262144 bytes align=0x80 nid=-1
from=0x max_addr=0x
mmu_context_init+0xd0/0x140
memblock_reserve: [0x00017ff2-0x00017ff5]
memblock_alloc_range_nid+0x1f0/0x360
MCA related initialization done
Zone ranges:
  DMA32[mem 0x-0x]
  Normal   [mem 0x0001-0x00017fff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x-0x00017fff]
Initmem setup node 0 [mem 0x-0x00017fff]
memblock_alloc_try_nid_raw: 7340032 bytes align=0x80 nid=0
from=0x max_addr=0x
free_area_init+0x1690/0x1d40
memblock_reserve: [0x00017f82-0x00017ff1]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=0 from=0x
max_addr=0x setup_usemap+0xf0/0x160
memblock_reserve: [0x00017f81ff80-0x00017f81ff87]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=0 from=0x
max_addr=0x setup_usemap+0xf0/0x160
memblock_reserve: [0x00017f81ff00-0x00017f81ff07]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 126 bytes align=0x80 nid=-1
from=0x max_addr=0x start_kernel+0x140/0xba0
memblock_reserve: [0x00017f81fe80-0x00017f81fefd]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 126 bytes align=0x80 nid=-1
from=0x max_addr=0x start_kernel+0x180/0xba0
memblock_reserve: [0x00017f81fe00-0x00017f81fe7d]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 65536 bytes align=0x1 nid=-1
from=0x max_addr=0x
pcpu_alloc_alloc_info+0xe0/0x1e0
memblock_reserve: [0x00017f80-0x00017f80]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x830/0x15c0
memblock_reserve: [0x00017f81fd80-0x00017f81fd87]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x880/0x15c0
memblock_reserve: [0x00017f81fd00-0x00017f81fd07]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 4 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x8c0/0x15c0
memblock_reserve: [0x00017f81fc80-0x00017f81fc83]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x910/0x15c0
memblock_reserve: [0x00017f81fc00-0x00017f81fc07]

[ia64] rx2800 i2: gcc-14-20240331 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC10027B.initrd.img...done
[0.00] Linux version
6.9.0-rc2-53f733c9-ia64-w-gcc-14-20240331-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240331 (experimental), GNU ld (GNU
Binutils) 2.42) #1 SMP Tue Apr  2 12:00:27 CEST 2024
[0.00] efi: EFI v2.1 by HP
[0.00] efi: SALsystab=0xdfdd63a18 ESI=0xdfdd63f18 ACPI
2.0=0x3d3c4014 HCDP=0xd8798 SMBIOS=0x3d368000
[0.00] PCDP: v3 at 0xd8798
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3D3C4014 24 (v02 HP)
[0.00] ACPI: XSDT 0x3D3C4580 000124 (v01 HP RX2800-2
0001  0113)
[0.00] ACPI: FACP 0x3D3BE000 F4 (v03 HP RX2800-2
0001 HP   0001)
[0.00] ACPI BIOS Warning (bug): Invalid length for
FADT/Pm1aEventBlock: 16, using default 32 (20230628/tbfadt-669)
[0.00] ACPI BIOS Warning (bug): Invalid length for
FADT/Pm1aControlBlock: 32, using default 16 (20230628/tbfadt-669)
[0.00] ACPI: DSDT 0x3D3A4000 009E45 (v02 HP RX2800-2
0008 INTL 20061109)
[0.00] ACPI: FACS 0x3D3C 40
[0.00] ACPI: FACS 0x3D3C 40
[0.00] ACPI: APIC 0x3D3C2000 00010C (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SPCR 0x3D3BC000 50 (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SRAT 0x3D3BA000 0001F8 (v02 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SLIT 0x3D3B8000 3C (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: CPEP 0x3D3B6000 34 (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SPMI 0x3D3B4000 41 (v05 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: DBGP 0x3D3B2000 34 (v00 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: HPET 0x3D3B 38 (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: DMAR 0x3D3AE000 CC (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SSDT 0x3D3A2000 A9 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D3A E2 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39E000 A8 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39C000 0014E9 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39A000 92 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D398000 92 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D396000 24 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D394000 000114 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D392000 35 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39 80 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38E000 000699 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38C000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38A000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D388000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D386000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D384000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D382000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38 A4 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37E000 000276 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37C000 BE (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37A000 36 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D378000 CF (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 16 CPUs total
[0.00] Number of logical nodes in system = 1
[0.00] Number of memory chunks in system = 3
[0.00] Initial ramdisk at: 0xe00deb1ad000 (49867219 bytes)
[0.00] SAL 3.20: HP Kauai version 3.1
[0.00] SAL: AP wakeup using external interrupt vector 0xf0
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x000d]
[0.00] Movable zone start for each node
[

[ia64] rx6600: gcc-14-20240331 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100287.initrd.img...done
[0.00] Linux version
6.9.0-rc2-53f733c9-ia64-w-gcc-14-20240331-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240331 (experimental), GNU ld (GNU
Binutils) 2.42) #1 SMP Tue Apr  2 12:00:27 CEST 2024
[0.00] efi: EFI v2.0 by HP
[0.00] efi: SALsystab=0x3e528000 ACPI 2.0=0x3fdd
ESI=0x3e529000 SMBIOS=0x3e52a000 HCDP=0x3fdce000
[0.00] PCDP: v3 at 0x3fdce000
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FDD 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FDD002C 000114 (v01 HP rx6600
 HP   )
[0.00] ACPI: FACP 0x3FDF5B18 F4 (v03 HP rx6600
 HP   )
[0.00] ACPI: DSDT 0x3FDD01C8 019E62 (v01 HP rx6600
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FDF5C10 40
[0.00] ACPI: SPCR 0x3FDF5C50 50 (v01 HP
 HP   )
[0.00] ACPI: DBGP 0x3FDF5CA0 34 (v01 HP rx6600
 HP   )
[0.00] ACPI: APIC 0x3FDF60C0 000178 (v01 HP rx6600
 HP   )
[0.00] ACPI: SPMI 0x3FDF5CD8 50 (v04 HP rx6600
 HP   )
[0.00] ACPI: CPEP 0x3FDF5F90 34 (v01 HP rx6600
 HP   )
[0.00] ACPI: SSDT 0x3FDEA038 0004B3 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEA4F8 0022BF (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEC7B8 001277 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEDA38 0012BD (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEECF8 001214 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEFF18 00225F (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF2178 0012CA (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3448 0012CA (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4718 000138 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4858 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4998 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4AD8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4C18 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4D58 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4E98 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4FD8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5118 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5258 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5398 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF54D8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5618 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5758 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5898 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF59D8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 16 CPUs available, 16 CPUs total
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] Initial ramdisk at: 0xe100f726e000 (49867219 bytes)
[0.00] SAL 3.20: HP version 4.11
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x4000-0x]
[0.00]   Normal   [mem 0x0001-0x0100]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x4000-0x3dcb3fff]
[0.00]   node   0: [mem 0x3e19c000-0x3e527fff]
[0.00]   node   0: [mem 0x3fc0-0x3fd5bfff]
[0.00]   node   0: [mem 0x3fd6-0x3fd63fff]
[0.00]   node   0: [mem 0x3fdc8000-0x3fdcbfff]
[0.00]   node   0: [mem 0x0001-0x0005]
[0.00]   node   

[ia64] rx2660: gcc-14-20240331 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

  Booting `T2 (diskless)'

Loading Linux kernel ...
Loading initial ramdisk ...
[0.00] Linux version
6.9.0-rc2-53f733c9-ia64-w-gcc-14-20240331-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240331 (experimental), GNU ld (GNU
Binutils) 2.42) #1 SMP Tue Apr  2 12:00:27 CEST 2024
[0.00] efi: EFI v2.0 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fde4000
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fde2000
[0.00] PCDP: v3 at 0x3fde2000
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FDE4000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FDE402C BC (v01 HP rx2660
 HP   )
[0.00] ACPI: FACP 0x3FDF6048 F4 (v03 HP rx2660
 HP   )
[0.00] ACPI: DSDT 0x3FDE41C8 00E566 (v01 HP rx2660
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FDF6140 40
[0.00] ACPI: SPCR 0x3FDF6180 50 (v01 HP
 HP   )
[0.00] ACPI: DBGP 0x3FDF61D0 34 (v01 HP rx2660
 HP   )
[0.00] ACPI: APIC 0x3FDF65F0 E8 (v01 HP rx2660
 HP   )
[0.00] ACPI: SPMI 0x3FDF6208 50 (v04 HP rx2660
 HP   )
[0.00] ACPI: CPEP 0x3FDF64C0 34 (v01 HP rx2660
 HP   )
[0.00] ACPI: SSDT 0x3FDF2738 0004B3 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF2BF8 000456 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3058 000EB8 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3F18 000866 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4788 000EB8 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5648 000138 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5788 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF58C8 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5A08 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5B48 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5C88 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5DC8 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5F08 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 8 CPUs total
[0.00] Initial ramdisk at: 0xe0002bd3b000 (49867219 bytes)
[0.00] SAL 3.20: HP version 4.4
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0100]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3e67]
[0.00]   node   0: [mem 0x3eaec000-0x3ee77fff]
[0.00]   node   0: [mem 0x3fc0-0x3fd5]
[0.00]   node   0: [mem 0x3fd74000-0x3fd77fff]
[0.00]   node   0: [mem 0x3fddc000-0x3fdd]
[0.00]   node   0: [mem 0x0001-0x0007]
[0.00]   node   0: [mem 0x01004000-0x0100ff1fbfff]
[0.00]   node   0: [mem 0x0100ff20-0x0100]
[0.00] Initmem setup node 0 [mem
0x0100-0x0100]
[0.00] On node 0, zone DMA32: 1024 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 283 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 866 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 5 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 25 pages in unavailable ranges
[0.00] On node 0, zone Normal: 136 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] pcpu-alloc: s36136 r8192 d217816 u262144 alloc=16*16384
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
[0.00] Kernel command line: BOOT_IMAGE=(tftp)/AC100263.vmlinuz
root=172.16.0.2:/srv/nfs/rx2660/root/ rw loglevel=9
modprobe.blacklist=radeon hostname=rx2660 console=ttyS1
[0.00] Unknown kernel command line parameters
"BOOT_IMAGE=(tftp)/AC100263.vmlinuz", will be passed to user space.
[0.00] Dentry cache hash table entries: 4194304 (order: 11,
33554432 

[ia64] rx2620: gcc-14-20240331 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100221.initrd.img...done
[0.00] Linux version
6.9.0-rc2-53f733c9-ia64-w-gcc-14-20240331-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240331 (experimental), GNU ld (GNU
Binutils) 2.42) #1 SMP Tue Apr  2 12:00:27 CEST 2024
[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fe2a000
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fe28000
[0.00] PCDP: v3 at 0x3fe28000
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE2A000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2A02C CC (v01 HP rx2620
 HP   )
[0.00] ACPI: FACP 0x3FE35CE8 F4 (v03 HP rx2620
 HP   )
[0.00] ACPI: DSDT 0x3FE2A1C8 008390 (v01 HP rx2620
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FE35DE0 40
[0.00] ACPI: SPCR 0x3FE35E20 50 (v01 HP rx2620
 HP   )
[0.00] ACPI: DBGP 0x3FE35E70 34 (v01 HP rx2620
 HP   )
[0.00] ACPI: APIC 0x3FE36090 000108 (v01 HP rx2620
 HP   )
[0.00] ACPI: SPMI 0x3FE35EA8 50 (v04 HP rx2620
 HP   )
[0.00] ACPI: CPEP 0x3FE35F60 34 (v01 HP rx2620
 HP   )
[0.00] ACPI: SSDT 0x3FE32568 0001A7 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE32718 0007DB (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE32EF8 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE33788 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE34018 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE348A8 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35138 0001A9 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE352E8 000138 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35428 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35568 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE356A8 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE357E8 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35928 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35A68 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35BA8 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 8 CPUs total
[0.00] Initial ramdisk at: 0xe040f706e000 (49867219 bytes)
[0.00] SAL 3.1: HP version 4.29
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0040]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3e873fff]
[0.00]   node   0: [mem 0x3eb9-0x3ee77fff]
[0.00]   node   0: [mem 0x3fc0-0x3fe27fff]
[0.00]   node   0: [mem 0x0001-0x000102373fff]
[0.00]   node   0: [mem 0x000102378000-0x000104373fff]
[0.00]   node   0: [mem 0x000104378000-0x000104b73fff]
[0.00]   node   0: [mem 0x000104b78000-0x000105573fff]
[0.00]   node   0: [mem 0x000105578000-0x000106b73fff]
[0.00]   node   0: [mem 0x000106b78000-0x000111573fff]
[0.00]   node   0: [mem 0x000111578000-0x000117d73fff]
[0.00]   node   0: [mem 0x000117d78000-0x000120373fff]
[0.00]   node   0: [mem 0x000120378000-0x000140173fff]
[0.00]   node   0: [mem 0x000140178000-0x000142173fff]
[0.00]   node   0: [mem 0x000142178000-0x000142773fff]
[0.00]   node   0: [mem 0x000142778000-0x000142f73fff]
[0.00]   node   0: [mem 0x000142f78000-0x000160f73fff]
[0.00]   node   0: [mem 0x000160f78000-0x000164f73fff]
[0.00]   node   0: [mem 0x000164f78000-0x0003bfff]
[0.00]   node   0: [mem 0x00404000-0x0040feffbfff]
[0.00]   node   0: [mem 0x0040ff00-0x0040ffcabfff]
[0.00]   node   

[ia64] rx4640: gcc-14-20240331 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC10025C.initrd.img...done
[0.00] Linux version
6.9.0-rc2-53f733c9-ia64-w-gcc-14-20240331-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240331 (experimental), GNU ld (GNU
Binutils) 2.42) #1 SMP Tue Apr  2 12:00:27 CEST 2024
[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3e528000 ACPI 2.0=0x3fe22000
ESI=0x3e529000 SMBIOS=0x3e52a000 HCDP=0x3fe2
[0.00] PCDP: v3 at 0x3fe2
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE22000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2202C A4 (v01 HP rx4640
 HP   )
[0.00] ACPI: FACP 0x3FE36EB8 F4 (v03 HP rx4640
 HP   )
[0.00] ACPI: DSDT 0x3FE221C8 00D0F5 (v01 HP rx4640
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FE36FB0 40
[0.00] ACPI: SPCR 0x3FE36FF0 50 (v01 HP rx4640
 HP   )
[0.00] ACPI: DBGP 0x3FE37040 34 (v01 HP rx4640
 HP   )
[0.00] ACPI: APIC 0x3FE37260 C8 (v01 HP rx4640
 HP   )
[0.00] ACPI: SPMI 0x3FE37078 50 (v04 HP rx4640
 HP   )
[0.00] ACPI: CPEP 0x3FE37130 34 (v01 HP rx4640
 HP   )
[0.00] ACPI: SSDT 0x3FE2F2C8 0001A7 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE2F478 000F65 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE303E8 0011CD (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE315B8 0021B5 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE33778 0021B5 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35938 0011CD (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36B08 DC (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36BE8 E0 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36CD8 E0 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36DC8 E0 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 4 CPUs available, 4 CPUs total
[0.00] Initial ramdisk at: 0xe040f706e000 (49867219 bytes)
[0.00] SAL 3.1: HP version 4.29
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0040]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3df23fff]
[0.00]   node   0: [mem 0x3e23c000-0x3e527fff]
[0.00]   node   0: [mem 0x3fc0-0x3fe1]
[0.00]   node   0: [mem 0x0001-0x0003bfff]
[0.00]   node   0: [mem 0x00404000-0x0040feffbfff]
[0.00]   node   0: [mem 0x0040ff00-0x0040ffcbbfff]
[0.00]   node   0: [mem 0x0040ffcf8000-0x0040ffe0]
[0.00]   node   0: [mem 0x0040ffe8-0x0040fffdbfff]
[0.00] Initmem setup node 0 [mem
0x0100-0x0040fffdbfff]
[0.00] On node 0, zone DMA32: 1024 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 198 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 1462 pages in unavailable ranges
[0.00] On node 0, zone Normal: 120 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] On node 0, zone Normal: 15 pages in unavailable ranges
[0.00] On node 0, zone Normal: 28 pages in unavailable ranges
[0.00] On node 0, zone Normal: 9 pages in unavailable ranges
[0.00] pcpu-alloc: s36136 r8192 d217816 u262144 alloc=16*16384
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[0.00] Kernel command line: BOOT_IMAGE=net0:/AC10025C.vmlinuz
root=172.16.0.2:/srv/nfs/rx4640/root/ rw loglevel=9
modprobe.blacklist=radeon hostname=rx4640 console=ttyS1
[0.00] Unknown kernel command line parameters
"BOOT_IMAGE=net0:/AC10025C.vmlinuz", will be passed to user space.
[0.00] Dentry cache hash table entries: 2097152 (order: 10,
16777216 bytes, linear)
[0.00] Inode-cache hash table entries: 1048576 (order: 9,
8388608 bytes, linear)
[0.00] Sorting __ex_table...
[  

[ia64] Combined gcc(-14) snapshot and Linux mainline testing cont.

[Frank Scheiner via Gcc-testresults]

Hi all,

Please note that the results following this message can differ to some
degree from the results from last week, due to:

* New minor Linux kernel version: v6.9-rc1 => v6.9-rc2
* New binutils version: 2.41 => 2.42
* including support for zram in the kernel configuration

In the following I'll send the resulting boot logs for the tested
machines and the HP Sim platform.

Cheers,
Frank

P.S.
For an introduction to these test results, please see [1].

[1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-March/810113.html

[ia64] HP Sim: gcc-14-20240324 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

root@dl380-g7:~/ski-test# time ./run_ski_test.bash
/usr/src/ski/ski-bootloader/ski-bootloader
/boot/vmlinux-6.9.0-rc1-687923a01b6d-ia64-ski-00023-g687923a01b6d-dirty
loading
/boot/vmlinux-6.9.0-rc1-687923a01b6d-ia64-ski-00023-g687923a01b6d-dirty...
probing initramfs ...
initramfs not passed
starting kernel...
Linux version 6.9.0-rc1-687923a01b6d-ia64-ski-00023-g687923a01b6d-dirty
(root@dl380-g7) (ia64-linux-gcc (GCC) 14.0.1 20240324 (experimental),
GNU ld (GNU Binutils) 2.41) #1 SMP PREEMPT Mon Mar 25 20:01:46 CET 2024
efi: EFI v1.0 by Hewlett-Packard
efi: SALsystab=0x10a510
warning: unable to switch EFI into virtual mode (status=131)
No I/O port range found in EFI memory map, falling back to AR.KR0
(0xc00)
printk: legacy console [simcons0] enabled
memblock_reserve: [0x-0x005f]
reserve_memory+0x3d0/0x440
memblock_reserve: [0x0010a5a0-0x0010a63f]
reserve_memory+0x3d0/0x440
memblock_reserve: [0x0010a640-0x0010a68f]
reserve_memory+0x3d0/0x440
memblock_reserve: [0x0010a690-0x0010a70d]
reserve_memory+0x3d0/0x440
memblock_reserve: [0x0400-0x051154cf]
reserve_memory+0x3d0/0x440
memblock_add_node: [0x-0x00017fff] nid=0 flags=0
find_memory+0xb0/0x1a0
memblock_alloc_try_nid: 262144 bytes align=0x4 nid=-1
from=0x0001 max_addr=0x find_memory+0x120/0x1a0
memblock_reserve: [0x00017ffc-0x00017fff]
memblock_alloc_range_nid+0x1f0/0x360
SAL 0.1: Hewlett-Packard HP-simulator version 0.0
get_cache_info: ia64_pal_cache_summary() failed (status=-1)
PAL_VM_PAGE_SIZE failed with status=-1; defaulting to architected purge
page-sizes.
memblock_alloc_try_nid: 131072 bytes align=0x1 nid=-1
from=0x max_addr=0x mca_bootmem+0x30/0x80
memblock_reserve: [0x00017ffa-0x00017ffb]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 262144 bytes align=0x80 nid=-1
from=0x max_addr=0x
mmu_context_init+0x60/0x140
memblock_reserve: [0x00017ff6-0x00017ff9]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 262144 bytes align=0x80 nid=-1
from=0x max_addr=0x
mmu_context_init+0xd0/0x140
memblock_reserve: [0x00017ff2-0x00017ff5]
memblock_alloc_range_nid+0x1f0/0x360
MCA related initialization done
Zone ranges:
  DMA32[mem 0x-0x]
  Normal   [mem 0x0001-0x00017fff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x-0x00017fff]
Initmem setup node 0 [mem 0x-0x00017fff]
memblock_alloc_try_nid_raw: 7340032 bytes align=0x80 nid=0
from=0x max_addr=0x
free_area_init+0x1690/0x1d40
memblock_reserve: [0x00017f82-0x00017ff1]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=0 from=0x
max_addr=0x setup_usemap+0xf0/0x160
memblock_reserve: [0x00017f81ff80-0x00017f81ff87]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=0 from=0x
max_addr=0x setup_usemap+0xf0/0x160
memblock_reserve: [0x00017f81ff00-0x00017f81ff07]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 126 bytes align=0x80 nid=-1
from=0x max_addr=0x start_kernel+0x140/0xba0
memblock_reserve: [0x00017f81fe80-0x00017f81fefd]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 126 bytes align=0x80 nid=-1
from=0x max_addr=0x start_kernel+0x180/0xba0
memblock_reserve: [0x00017f81fe00-0x00017f81fe7d]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 65536 bytes align=0x1 nid=-1
from=0x max_addr=0x
pcpu_alloc_alloc_info+0xe0/0x1e0
memblock_reserve: [0x00017f80-0x00017f80]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x830/0x15c0
memblock_reserve: [0x00017f81fd80-0x00017f81fd87]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x880/0x15c0
memblock_reserve: [0x00017f81fd00-0x00017f81fd07]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 4 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x8c0/0x15c0
memblock_reserve: [0x00017f81fc80-0x00017f81fc83]
memblock_alloc_range_nid+0x1f0/0x360
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x910/0x15c0
memblock_reserve: [0x00017f81fc00-0x00017f81fc07]

[ia64] rx2800 i2: gcc-14-20240324 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC10027B.initrd.img...done
[0.00] Linux version
6.9.0-rc1-687923a01b6d-ia64-w-gcc-20240324-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240324 (experimental), GNU ld (GNU
Binutils) 2.41) #1 SMP Mon Mar 25 21:40:25 CET 2024
[0.00] efi: EFI v2.1 by HP
[0.00] efi: SALsystab=0xdfdd63a18 ESI=0xdfdd63f18 ACPI
2.0=0x3d3c4014 HCDP=0xd8798 SMBIOS=0x3d368000
[0.00] PCDP: v3 at 0xd8798
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3D3C4014 24 (v02 HP)
[0.00] ACPI: XSDT 0x3D3C4580 000124 (v01 HP RX2800-2
0001  0113)
[0.00] ACPI: FACP 0x3D3BE000 F4 (v03 HP RX2800-2
0001 HP   0001)
[0.00] ACPI BIOS Warning (bug): Invalid length for
FADT/Pm1aEventBlock: 16, using default 32 (20230628/tbfadt-669)
[0.00] ACPI BIOS Warning (bug): Invalid length for
FADT/Pm1aControlBlock: 32, using default 16 (20230628/tbfadt-669)
[0.00] ACPI: DSDT 0x3D3A4000 009E45 (v02 HP RX2800-2
0008 INTL 20061109)
[0.00] ACPI: FACS 0x3D3C 40
[0.00] ACPI: FACS 0x3D3C 40
[0.00] ACPI: APIC 0x3D3C2000 00010C (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SPCR 0x3D3BC000 50 (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SRAT 0x3D3BA000 0001F8 (v02 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SLIT 0x3D3B8000 3C (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: CPEP 0x3D3B6000 34 (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SPMI 0x3D3B4000 41 (v05 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: DBGP 0x3D3B2000 34 (v00 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: HPET 0x3D3B 38 (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: DMAR 0x3D3AE000 CC (v01 HP RX2800-2
0001 HP   0001)
[0.00] ACPI: SSDT 0x3D3A2000 A9 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D3A E2 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39E000 A8 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39C000 0014E9 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39A000 92 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D398000 92 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D396000 24 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D394000 000114 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D392000 35 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39 80 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38E000 000699 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38C000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38A000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D388000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D386000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D384000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D382000 0003C6 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38 A4 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37E000 000276 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37C000 BE (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37A000 36 (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D378000 CF (v02 HP RX2800-2
0007 INTL 20061109)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 16 CPUs total
[0.00] Number of logical nodes in system = 1
[0.00] Number of memory chunks in system = 3
[0.00] Initial ramdisk at: 0xe00deb249000 (49548698 bytes)
[0.00] SAL 3.20: HP Kauai version 3.1
[0.00] SAL: AP wakeup using external interrupt vector 0xf0
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x000d]
[0.00] Movable zone start for each node
[0.00] 

[ia64] rx6600: gcc-14-20240324 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100287.initrd.img...done
[0.00] Linux version
6.9.0-rc1-687923a01b6d-ia64-w-gcc-20240324-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240324 (experimental), GNU ld (GNU
Binutils) 2.41) #1 SMP Mon Mar 25 21:40:25 CET 2024
[0.00] efi: EFI v2.0 by HP
[0.00] efi: SALsystab=0x3e528000 ACPI 2.0=0x3fdd
ESI=0x3e529000 SMBIOS=0x3e52a000 HCDP=0x3fdce000
[0.00] PCDP: v3 at 0x3fdce000
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FDD 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FDD002C 000114 (v01 HP rx6600
 HP   )
[0.00] ACPI: FACP 0x3FDF5B18 F4 (v03 HP rx6600
 HP   )
[0.00] ACPI: DSDT 0x3FDD01C8 019E62 (v01 HP rx6600
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FDF5C10 40
[0.00] ACPI: SPCR 0x3FDF5C50 50 (v01 HP
 HP   )
[0.00] ACPI: DBGP 0x3FDF5CA0 34 (v01 HP rx6600
 HP   )
[0.00] ACPI: APIC 0x3FDF60C0 000178 (v01 HP rx6600
 HP   )
[0.00] ACPI: SPMI 0x3FDF5CD8 50 (v04 HP rx6600
 HP   )
[0.00] ACPI: CPEP 0x3FDF5F90 34 (v01 HP rx6600
 HP   )
[0.00] ACPI: SSDT 0x3FDEA038 0004B3 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEA4F8 0022BF (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEC7B8 001277 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEDA38 0012BD (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEECF8 001214 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEFF18 00225F (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF2178 0012CA (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3448 0012CA (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4718 000138 (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4858 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4998 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4AD8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4C18 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4D58 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4E98 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4FD8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5118 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5258 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5398 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF54D8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5618 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5758 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5898 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF59D8 00013C (v01 HP rx6600
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 16 CPUs available, 16 CPUs total
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] Initial ramdisk at: 0xe100f730a000 (49548698 bytes)
[0.00] SAL 3.20: HP version 4.11
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x4000-0x]
[0.00]   Normal   [mem 0x0001-0x0100]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x4000-0x3dcb3fff]
[0.00]   node   0: [mem 0x3e19c000-0x3e527fff]
[0.00]   node   0: [mem 0x3fc0-0x3fd5bfff]
[0.00]   node   0: [mem 0x3fd6-0x3fd63fff]
[0.00]   node   0: [mem 0x3fdc8000-0x3fdcbfff]
[0.00]   node   0: [mem 0x0001-0x0005]
[0.00]   node   0: 

[ia64] rx2660: gcc-14-20240324 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

  Booting `T2 (diskless)'

Loading Linux kernel ...
Loading initial ramdisk ...
[0.00] Linux version
6.9.0-rc1-687923a01b6d-ia64-w-gcc-20240324-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240324 (experimental), GNU ld (GNU
Binutils) 2.41) #1 SMP Mon Mar 25 21:40:25 CET 2024
[0.00] efi: EFI v2.0 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fde4000
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fde2000
[0.00] PCDP: v3 at 0x3fde2000
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FDE4000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FDE402C BC (v01 HP rx2660
 HP   )
[0.00] ACPI: FACP 0x3FDF6048 F4 (v03 HP rx2660
 HP   )
[0.00] ACPI: DSDT 0x3FDE41C8 00E566 (v01 HP rx2660
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FDF6140 40
[0.00] ACPI: SPCR 0x3FDF6180 50 (v01 HP
 HP   )
[0.00] ACPI: DBGP 0x3FDF61D0 34 (v01 HP rx2660
 HP   )
[0.00] ACPI: APIC 0x3FDF65F0 E8 (v01 HP rx2660
 HP   )
[0.00] ACPI: SPMI 0x3FDF6208 50 (v04 HP rx2660
 HP   )
[0.00] ACPI: CPEP 0x3FDF64C0 34 (v01 HP rx2660
 HP   )
[0.00] ACPI: SSDT 0x3FDF2738 0004B3 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF2BF8 000456 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3058 000EB8 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3F18 000866 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4788 000EB8 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5648 000138 (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5788 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF58C8 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5A08 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5B48 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5C88 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5DC8 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5F08 00013C (v01 HP rx2660
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 8 CPUs total
[0.00] Initial ramdisk at: 0xe0002bd89000 (49548698 bytes)
[0.00] SAL 3.20: HP version 4.4
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0100]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3e67]
[0.00]   node   0: [mem 0x3eaec000-0x3ee77fff]
[0.00]   node   0: [mem 0x3fc0-0x3fd5]
[0.00]   node   0: [mem 0x3fd74000-0x3fd77fff]
[0.00]   node   0: [mem 0x3fddc000-0x3fdd]
[0.00]   node   0: [mem 0x0001-0x0007]
[0.00]   node   0: [mem 0x01004000-0x0100ff1fbfff]
[0.00]   node   0: [mem 0x0100ff20-0x0100]
[0.00] Initmem setup node 0 [mem
0x0100-0x0100]
[0.00] On node 0, zone DMA32: 1024 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 283 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 866 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 5 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 25 pages in unavailable ranges
[0.00] On node 0, zone Normal: 136 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] pcpu-alloc: s35240 r8192 d218712 u262144 alloc=16*16384
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
[0.00] Kernel command line: BOOT_IMAGE=(tftp)/AC100263.vmlinuz
root=172.16.0.2:/srv/nfs/rx2660/root/ rw loglevel=9
modprobe.blacklist=radeon hostname=rx2660 console=ttyS1
[0.00] Unknown kernel command line parameters
"BOOT_IMAGE=(tftp)/AC100263.vmlinuz", will be passed to user space.
[0.00] Dentry cache hash table entries: 4194304 (order: 11,
33554432 bytes, 

[ia64] rx2620: gcc-14-20240324 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100221.initrd.img...done
[0.00] Linux version
6.9.0-rc1-687923a01b6d-ia64-w-gcc-20240324-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240324 (experimental), GNU ld (GNU
Binutils) 2.41) #1 SMP Mon Mar 25 21:40:25 CET 2024
[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fe2a000
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fe28000
[0.00] PCDP: v3 at 0x3fe28000
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE2A000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2A02C CC (v01 HP rx2620
 HP   )
[0.00] ACPI: FACP 0x3FE35CE8 F4 (v03 HP rx2620
 HP   )
[0.00] ACPI: DSDT 0x3FE2A1C8 008390 (v01 HP rx2620
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FE35DE0 40
[0.00] ACPI: SPCR 0x3FE35E20 50 (v01 HP rx2620
 HP   )
[0.00] ACPI: DBGP 0x3FE35E70 34 (v01 HP rx2620
 HP   )
[0.00] ACPI: APIC 0x3FE36090 000108 (v01 HP rx2620
 HP   )
[0.00] ACPI: SPMI 0x3FE35EA8 50 (v04 HP rx2620
 HP   )
[0.00] ACPI: CPEP 0x3FE35F60 34 (v01 HP rx2620
 HP   )
[0.00] ACPI: SSDT 0x3FE32568 0001A7 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE32718 0007DB (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE32EF8 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE33788 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE34018 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE348A8 000887 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35138 0001A9 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE352E8 000138 (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35428 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35568 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE356A8 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE357E8 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35928 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35A68 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35BA8 00013C (v01 HP rx2620
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 8 CPUs total
[0.00] Initial ramdisk at: 0xe040f710a000 (49548698 bytes)
[0.00] SAL 3.1: HP version 4.29
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0040]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3e873fff]
[0.00]   node   0: [mem 0x3eb9-0x3ee77fff]
[0.00]   node   0: [mem 0x3fc0-0x3fe27fff]
[0.00]   node   0: [mem 0x0001-0x000102373fff]
[0.00]   node   0: [mem 0x000102378000-0x000104373fff]
[0.00]   node   0: [mem 0x000104378000-0x000104b73fff]
[0.00]   node   0: [mem 0x000104b78000-0x000105573fff]
[0.00]   node   0: [mem 0x000105578000-0x000106b73fff]
[0.00]   node   0: [mem 0x000106b78000-0x000111573fff]
[0.00]   node   0: [mem 0x000111578000-0x000117d73fff]
[0.00]   node   0: [mem 0x000117d78000-0x000120373fff]
[0.00]   node   0: [mem 0x000120378000-0x000140173fff]
[0.00]   node   0: [mem 0x000140178000-0x000142173fff]
[0.00]   node   0: [mem 0x000142178000-0x000142773fff]
[0.00]   node   0: [mem 0x000142778000-0x000142f73fff]
[0.00]   node   0: [mem 0x000142f78000-0x000160f73fff]
[0.00]   node   0: [mem 0x000160f78000-0x000164f73fff]
[0.00]   node   0: [mem 0x000164f78000-0x0003bfff]
[0.00]   node   0: [mem 0x00404000-0x0040feffbfff]
[0.00]   node   0: [mem 0x0040ff00-0x0040ffcabfff]
[0.00]   node   0: 

[ia64] rx4640: gcc-14-20240324 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC10025C.initrd.img...done
[0.00] Linux version
6.9.0-rc1-687923a01b6d-ia64-w-gcc-20240324-lra (root@dl380-g7)
(ia64-linux-gcc (GCC) 14.0.1 20240324 (experimental), GNU ld (GNU
Binutils) 2.41) #1 SMP Mon Mar 25 21:40:25 CET 2024
[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3e528000 ACPI 2.0=0x3fe22000
ESI=0x3e529000 SMBIOS=0x3e52a000 HCDP=0x3fe2
[0.00] PCDP: v3 at 0x3fe2
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE22000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2202C A4 (v01 HP rx4640
 HP   )
[0.00] ACPI: FACP 0x3FE36EB8 F4 (v03 HP rx4640
 HP   )
[0.00] ACPI: DSDT 0x3FE221C8 00D0F5 (v01 HP rx4640
0007 INTL 20050309)
[0.00] ACPI: FACS 0x3FE36FB0 40
[0.00] ACPI: SPCR 0x3FE36FF0 50 (v01 HP rx4640
 HP   )
[0.00] ACPI: DBGP 0x3FE37040 34 (v01 HP rx4640
 HP   )
[0.00] ACPI: APIC 0x3FE37260 C8 (v01 HP rx4640
 HP   )
[0.00] ACPI: SPMI 0x3FE37078 50 (v04 HP rx4640
 HP   )
[0.00] ACPI: CPEP 0x3FE37130 34 (v01 HP rx4640
 HP   )
[0.00] ACPI: SSDT 0x3FE2F2C8 0001A7 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE2F478 000F65 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE303E8 0011CD (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE315B8 0021B5 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE33778 0021B5 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35938 0011CD (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36B08 DC (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36BE8 E0 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36CD8 E0 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36DC8 E0 (v01 HP rx4640
0006 INTL 20050309)
[0.00] ACPI: Local APIC address (ptrval)
[0.00] 4 CPUs available, 4 CPUs total
[0.00] Initial ramdisk at: 0xe040f710a000 (49548698 bytes)
[0.00] SAL 3.1: HP version 4.29
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0040]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3df23fff]
[0.00]   node   0: [mem 0x3e23c000-0x3e527fff]
[0.00]   node   0: [mem 0x3fc0-0x3fe1]
[0.00]   node   0: [mem 0x0001-0x0003bfff]
[0.00]   node   0: [mem 0x00404000-0x0040feffbfff]
[0.00]   node   0: [mem 0x0040ff00-0x0040ffcbbfff]
[0.00]   node   0: [mem 0x0040ffcf8000-0x0040ffe0]
[0.00]   node   0: [mem 0x0040ffe8-0x0040fffdbfff]
[0.00] Initmem setup node 0 [mem
0x0100-0x0040fffdbfff]
[0.00] On node 0, zone DMA32: 1024 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 198 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 1462 pages in unavailable ranges
[0.00] On node 0, zone Normal: 120 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] On node 0, zone Normal: 15 pages in unavailable ranges
[0.00] On node 0, zone Normal: 28 pages in unavailable ranges
[0.00] On node 0, zone Normal: 9 pages in unavailable ranges
[0.00] pcpu-alloc: s35240 r8192 d218712 u262144 alloc=16*16384
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[0.00] Kernel command line: BOOT_IMAGE=net0:/AC10025C.vmlinuz
root=172.16.0.2:/srv/nfs/rx4640/root/ rw loglevel=9
modprobe.blacklist=radeon hostname=rx4640 console=ttyS1
[0.00] Unknown kernel command line parameters
"BOOT_IMAGE=net0:/AC10025C.vmlinuz", will be passed to user space.
[0.00] Dentry cache hash table entries: 2097152 (order: 10,
16777216 bytes, linear)
[0.00] Inode-cache hash table entries: 1048576 (order: 9,
8388608 bytes, linear)
[0.00] Sorting __ex_table...
[

[ia64] Combined gcc(-14) snapshot and Linux mainline testing cont.

[Frank Scheiner via Gcc-testresults]

Hi all,

please note that the results following this message can differ to some
degree from the results from two weeks ago, due to:

* New minor Linux kernel version: Linux v6.8 => v6.9-rc1
* switching from Debian GNU/Linux Sid to T2
* including support for NFSv4 in the kernel configuration

It's a little early still to consider this the new baseline, but OTOH
the possible future changes (e.g. binutils 2.42, enabling zram in the
kernel config, using a userland compiled with LRA enabled gcc, etc.)
hopefully won't totally change the results during this cycle.

In the following I'll send the resulting boot logs for the tested
machines and the HP Sim platform.

Cheers,
Frank

P.S.
For an introduction to these test results, please see [1].

[1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-March/810113.html

Re: Linux 6.8

[Frank Scheiner]

Dear all,

as usual, an update for Linux/ia64:

As far as I can tell, the v6.8 development cycle for us looked not much
different to the v6.7 one: The ia64 patch set ([1]) was extended where
need was identified. All ia64 machines we have available for testing
continue to work, no system support was lost during this cycle. No, we
even got another "system" back: the HP Sim platform - up to mainline,
that is. Together with Ski [2], thankfully kept together and updated by
Sergei Trofimovich, this allows to run ia64 kernels and (light) ia64
userland software on for example x86_64 hosts. Like it's done for the
recently established auto-builds for Linux stable RCs and releases on
GitHub. Have a look on [3] for example: all building, all working (in
Ski). For the manual testing of the Linux mainline RCs and releases some
changes were introduced. Mainly that compilation always happens with the
latest gcc-14 snapshot starting with v6.8-rc1 - so far no surprises -
and recently, the enabling of LRA for the compiler.

[1]: https://github.com/lenticularis39/linux-ia64

[2]: https://github.com/trofi/ski

[3]:
https://github.com/johnny-mnemonic/linux-stable-rc/actions/runs/8258902207

Unfortunately there's one difference to v6.7 with v6.8 (actually
beginning with v6.8-rc1 as we found out later during the cycle): there
is a userland regression present that leads to segfaults with v6.8 where
it does not with v6.7. We collected the following examples for this
regression (if they are all related):

* Debian: apt(-get) segfaults (though not immediately) and is affected
to a different degree depending on non-usrmerged or usrmerged root FS
* Gentoo: segfaults happen when emerging different packages
* T2: compiling a specific Perl source code file with gcc leads it to
segfault

...and hope to find the cause of it and a solution. Before you ask, no,
this is not due to enabling LRA for the compiler, it already happened
before that was done.



This time no new distributions for ia64, but unfortunately one less
soon: Debian will close shop on ia64 ([4]). As much as this make me sad,
because this was the distribution that got me going on ia64 nearly ten
years ago, better switch to another option sooner than later. I am
switching to T2 ([5]) for example for future testing. For network boot
this was really simple to set up, similar to how you can create an
OpenBSD root FS by unpacking a list of tarballs plus some manual
configuration afterwards.

[4]: https://lists.debian.org/debian-ia64/2024/02/msg2.html

[5]: https://t2sde.org/



Thank you all for your hard work on Linux!

Cheers,
Frank at al

[ia64] HP Sim: gcc-14-20240310 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

root@dl380-g7:~/ski-test# time ./run_ski_test.bash
/usr/src/ski/ski-bootloader/ski-bootloader
/boot/vmlinux-6.8.0-85b287316a10-ia64-ski-00021-g85b287316a10-dirty
loading
/boot/vmlinux-6.8.0-85b287316a10-ia64-ski-00021-g85b287316a10-dirty...
probing initramfs ...
initramfs not passed
starting kernel...
Linux version 6.8.0-85b287316a10-ia64-ski-00021-g85b287316a10-dirty
(root@dl380-g7) (ia64-linux-gcc (GCC) 14.0.1 20240310 (experimental),
GNU ld (GNU Binutils) 2.41) #1 SMP PREEMPT Mon Mar 11 15:12:18 CET 2024
efi: EFI v1.0 by Hewlett-Packard
efi: SALsystab=0x10a510
warning: unable to switch EFI into virtual mode (status=131)
No I/O port range found in EFI memory map, falling back to AR.KR0
(0xc00)
printk: legacy console [simcons0] enabled
memblock_reserve: [0x-0x005f]
reserve_memory+0x3c0/0x440
memblock_reserve: [0x0010a5a0-0x0010a63f]
reserve_memory+0x3c0/0x440
memblock_reserve: [0x0010a640-0x0010a68f]
reserve_memory+0x3c0/0x440
memblock_reserve: [0x0010a690-0x0010a70d]
reserve_memory+0x3c0/0x440
memblock_reserve: [0x0400-0x05093dcf]
reserve_memory+0x3c0/0x440
memblock_add_node: [0x-0x00017fff] nid=0 flags=0
find_memory+0xb0/0x1a0
memblock_alloc_try_nid: 262144 bytes align=0x4 nid=-1
from=0x0001 max_addr=0x find_memory+0x120/0x1a0
memblock_reserve: [0x00017ffc-0x00017fff]
memblock_alloc_range_nid+0x220/0x480
SAL 0.1: Hewlett-Packard HP-simulator version 0.0
get_cache_info: ia64_pal_cache_summary() failed (status=-1)
PAL_VM_PAGE_SIZE failed with status=-1; defaulting to architected purge
page-sizes.
memblock_alloc_try_nid: 131072 bytes align=0x1 nid=-1
from=0x max_addr=0x mca_bootmem+0x30/0x60
memblock_reserve: [0x00017ffa-0x00017ffb]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 262144 bytes align=0x80 nid=-1
from=0x max_addr=0x
mmu_context_init+0x60/0x140
memblock_reserve: [0x00017ff6-0x00017ff9]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 262144 bytes align=0x80 nid=-1
from=0x max_addr=0x
mmu_context_init+0xd0/0x140
memblock_reserve: [0x00017ff2-0x00017ff5]
memblock_alloc_range_nid+0x220/0x480
MCA related initialization done
Zone ranges:
  DMA32[mem 0x-0x]
  Normal   [mem 0x0001-0x00017fff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x-0x00017fff]
Initmem setup node 0 [mem 0x-0x00017fff]
memblock_alloc_try_nid_raw: 7340032 bytes align=0x80 nid=0
from=0x max_addr=0x
free_area_init+0x1830/0x2320
memblock_reserve: [0x00017f82-0x00017ff1]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 8 bytes align=0x80 nid=0 from=0x
max_addr=0x setup_usemap+0x110/0x180
memblock_reserve: [0x00017f81ff80-0x00017f81ff87]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 8 bytes align=0x80 nid=0 from=0x
max_addr=0x setup_usemap+0x110/0x180
memblock_reserve: [0x00017f81ff00-0x00017f81ff07]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 126 bytes align=0x80 nid=-1
from=0x max_addr=0x start_kernel+0x140/0xc60
memblock_reserve: [0x00017f81fe80-0x00017f81fefd]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 126 bytes align=0x80 nid=-1
from=0x max_addr=0x start_kernel+0x180/0xc60
memblock_reserve: [0x00017f81fe00-0x00017f81fe7d]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 65536 bytes align=0x1 nid=-1
from=0x max_addr=0x
pcpu_alloc_alloc_info+0xe0/0x1e0
memblock_reserve: [0x00017f80-0x00017f80]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x120/0x1a20
memblock_reserve: [0x00017f81fd80-0x00017f81fd87]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x170/0x1a20
memblock_reserve: [0x00017f81fd00-0x00017f81fd07]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 4 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x1c0/0x1a20
memblock_reserve: [0x00017f81fc80-0x00017f81fc83]
memblock_alloc_range_nid+0x220/0x480
memblock_alloc_try_nid: 8 bytes align=0x80 nid=-1
from=0x max_addr=0x
pcpu_setup_first_chunk+0x210/0x1a20
memblock_reserve: [0x00017f81fc00-0x00017f81fc07]

[ia64] rx2800 i2: gcc-14-20240310 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC10027B.initrd.img...done
[0.00] Linux version 
6.8.0-85b287316a10-ia64-w-gcc-14-20240310-lra (root@dl380-g7) 
(ia64-linux-gcc (GCC) 14.0.1 20240310 (experimental), GNU ld (GNU 
Binutils) 2.41) #1 SMP Mon Mar 11 15:07:09 CET 2024

[0.00] efi: EFI v2.1 by HP
[0.00] efi: SALsystab=0x6fdd63a18 ESI=0x6fdd63f18 ACPI 
2.0=0x3d3c4014 HCDP=0x68798 SMBIOS=0x3d368000

[0.00] PCDP: v3 at 0x68798
[0.00] earlycon: uart8250 at I/O port 0x4000 (options '115200n8')
[0.00] printk: legacy bootconsole [uart8250] enabled
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3D3C4014 24 (v02 HP)
[0.00] ACPI: XSDT 0x3D3C4580 000124 (v01 HP RX2800-2 
0001  0113)
[0.00] ACPI: FACP 0x3D3BE000 F4 (v03 HP RX2800-2 
0001 HP   0001)
[0.00] ACPI BIOS Warning (bug): Invalid length for 
FADT/Pm1aEventBlock: 16, using default 32 (20230628/tbfadt-669)
[0.00] ACPI BIOS Warning (bug): Invalid length for 
FADT/Pm1aControlBlock: 32, using default 16 (20230628/tbfadt-669)
[0.00] ACPI: DSDT 0x3D3A4000 009E45 (v02 HP RX2800-2 
0008 INTL 20061109)

[0.00] ACPI: FACS 0x3D3C 40
[0.00] ACPI: FACS 0x3D3C 40
[0.00] ACPI: APIC 0x3D3C2000 00010C (v01 HP RX2800-2 
0001 HP   0001)
[0.00] ACPI: SPCR 0x3D3BC000 50 (v01 HP RX2800-2 
0001 HP   0001)
[0.00] ACPI: SRAT 0x3D3BA000 0001F8 (v02 HP RX2800-2 
0001 HP   0001)
[0.00] ACPI: SLIT 0x3D3B8000 3C (v01 HP RX2800-2 
0001 HP   0001)
[0.00] ACPI: CPEP 0x3D3B6000 34 (v01 HP RX2800-2 
0001 HP   0001)
[0.00] ACPI: SPMI 0x3D3B4000 41 (v05 HP RX2800-2 
0001 HP   0001)
[0.00] ACPI: DBGP 0x3D3B2000 34 (v00 HP RX2800-2 
0001 HP   0001)
[0.00] ACPI: HPET 0x3D3B 38 (v01 HP RX2800-2 
0001 HP   0001)
[0.00] ACPI: DMAR 0x3D3AE000 CC (v01 HP RX2800-2 
0001 HP   0001)
[0.00] ACPI: SSDT 0x3D3A2000 A9 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D3A E2 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39E000 A8 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39C000 0014E9 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39A000 92 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D398000 92 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D396000 24 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D394000 000114 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D392000 35 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D39 80 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38E000 000699 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38C000 0003C6 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38A000 0003C6 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D388000 0003C6 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D386000 0003C6 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D384000 0003C6 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D382000 0003C6 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D38 A4 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37E000 000276 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37C000 BE (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D37A000 36 (v02 HP RX2800-2 
0007 INTL 20061109)
[0.00] ACPI: SSDT 0x3D378000 CF (v02 HP RX2800-2 
0007 INTL 20061109)

[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 16 CPUs total
[0.00] Number of logical nodes in system = 1
[0.00] Number of memory chunks in system = 3
[0.00] Initial ramdisk at: 0xe006ea7e1000 (55001352 bytes)
[0.00] SAL 3.20: HP Kauai version 3.1
[0.00] SAL: AP wakeup using external interrupt vector 0xf0
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[

[ia64] rx6600: gcc-14-20240310 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100287.initrd.img...done
[0.00] Linux version 
6.8.0-85b287316a10-ia64-w-gcc-14-20240310-lra (root@dl380-g7) 
(ia64-linux-gcc (GCC) 14.0.1 20240310 (experimental), GNU ld (GNU 
Binutils) 2.41) #1 SMP Mon Mar 11 15:07:09 CET 2024

[0.00] efi: EFI v2.0 by HP
[0.00] efi: SALsystab=0x3e528000 ACPI 2.0=0x3fdd 
ESI=0x3e529000 SMBIOS=0x3e52a000 HCDP=0x3fdce000

[0.00] PCDP: v3 at 0x3fdce000
[0.00] earlycon: uart8250 at MMIO 0x80003000 (options 
'9600n8')

[0.00] printk: legacy bootconsole [uart8250] enabled
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FDD 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FDD002C 000114 (v01 HP rx6600 
 HP   )
[0.00] ACPI: FACP 0x3FDF5B18 F4 (v03 HP rx6600 
 HP   )
[0.00] ACPI: DSDT 0x3FDD01C8 019E62 (v01 HP rx6600 
0007 INTL 20050309)

[0.00] ACPI: FACS 0x3FDF5C10 40
[0.00] ACPI: SPCR 0x3FDF5C50 50 (v01 HP 
 HP   )
[0.00] ACPI: DBGP 0x3FDF5CA0 34 (v01 HP rx6600 
 HP   )
[0.00] ACPI: APIC 0x3FDF60C0 000178 (v01 HP rx6600 
 HP   )
[0.00] ACPI: SPMI 0x3FDF5CD8 50 (v04 HP rx6600 
 HP   )
[0.00] ACPI: CPEP 0x3FDF5F90 34 (v01 HP rx6600 
 HP   )
[0.00] ACPI: SSDT 0x3FDEA038 0004B3 (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEA4F8 0022BF (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEC7B8 001277 (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEDA38 0012BD (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEECF8 001214 (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDEFF18 00225F (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF2178 0012CA (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3448 0012CA (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4718 000138 (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4858 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4998 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4AD8 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4C18 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4D58 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4E98 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4FD8 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5118 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5258 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5398 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF54D8 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5618 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5758 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5898 00013C (v01 HP rx6600 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF59D8 00013C (v01 HP rx6600 
0006 INTL 20050309)

[0.00] ACPI: Local APIC address (ptrval)
[0.00] 16 CPUs available, 16 CPUs total
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] warning: skipping physical page 0
[0.00] Initial ramdisk at: 0xe100f68a2000 (55001352 bytes)
[0.00] SAL 3.20: HP version 4.11
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x4000-0x]
[0.00]   Normal   [mem 0x0001-0x0100]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x4000-0x3dcb3fff]
[0.00]   node   0: [mem 0x3e19c000-0x3e527fff]
[0.00]   node   0: [mem 0x3fc0-0x3fd5bfff]
[0.00]   node   0: [mem 0x3fd6-0x3fd63fff]
[0.00]   node   0: [mem 

[ia64] rx2660: gcc-14-20240310 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

  Booting `Debian GNU/Linux Sid (diskless)'

Loading Linux kernel ...
Loading initial ramdisk ...
[0.00] Linux version 
6.8.0-85b287316a10-ia64-w-gcc-14-20240310-lra (root@dl380-g7) 
(ia64-linux-gcc (GCC) 14.0.1 20240310 (experimental), GNU ld (GNU 
Binutils) 2.41) #1 SMP Mon Mar 11 15:07:09 CET 2024

[0.00] efi: EFI v2.0 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fde4000 
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fde2000

[0.00] PCDP: v3 at 0x3fde2000
[0.00] earlycon: uart8250 at MMIO 0x88033000 (options 
'9600n8')

[0.00] printk: legacy bootconsole [uart8250] enabled
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FDE4000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FDE402C BC (v01 HP rx2660 
 HP   )
[0.00] ACPI: FACP 0x3FDF6048 F4 (v03 HP rx2660 
 HP   )
[0.00] ACPI: DSDT 0x3FDE41C8 00E566 (v01 HP rx2660 
0007 INTL 20050309)

[0.00] ACPI: FACS 0x3FDF6140 40
[0.00] ACPI: SPCR 0x3FDF6180 50 (v01 HP 
 HP   )
[0.00] ACPI: DBGP 0x3FDF61D0 34 (v01 HP rx2660 
 HP   )
[0.00] ACPI: APIC 0x3FDF65F0 E8 (v01 HP rx2660 
 HP   )
[0.00] ACPI: SPMI 0x3FDF6208 50 (v04 HP rx2660 
 HP   )
[0.00] ACPI: CPEP 0x3FDF64C0 34 (v01 HP rx2660 
 HP   )
[0.00] ACPI: SSDT 0x3FDF2738 0004B3 (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF2BF8 000456 (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3058 000EB8 (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF3F18 000866 (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF4788 000EB8 (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5648 000138 (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5788 00013C (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF58C8 00013C (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5A08 00013C (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5B48 00013C (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5C88 00013C (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5DC8 00013C (v01 HP rx2660 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FDF5F08 00013C (v01 HP rx2660 
0006 INTL 20050309)

[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 8 CPUs total
[0.00] Initial ramdisk at: 0xe0002b855000 (55001352 bytes)
[0.00] SAL 3.20: HP version 4.4
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0100]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3e67]
[0.00]   node   0: [mem 0x3eaec000-0x3ee77fff]
[0.00]   node   0: [mem 0x3fc0-0x3fd5]
[0.00]   node   0: [mem 0x3fd74000-0x3fd77fff]
[0.00]   node   0: [mem 0x3fddc000-0x3fdd]
[0.00]   node   0: [mem 0x0001-0x0007]
[0.00]   node   0: [mem 0x01004000-0x0100ff1fbfff]
[0.00]   node   0: [mem 0x0100ff20-0x0100]
[0.00] Initmem setup node 0 [mem 
0x0100-0x0100]

[0.00] On node 0, zone DMA32: 1024 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 283 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 866 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 5 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 25 pages in unavailable ranges
[0.00] On node 0, zone Normal: 136 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] Kernel command line: BOOT_IMAGE=(tftp)/AC100263.vmlinuz 
root=/dev/nfs ip=:enp1s2f0:dhcp modprobe.blacklist=radeon 
hardened_usercopy=off hostname=rx2660
[0.00] Unknown kernel command line parameters 
"BOOT_IMAGE=(tftp)/AC100263.vmlinuz ip=:enp1s2f0:dhcp 
hardened_usercopy=off", will be passed to user space.
[0.00] Dentry cache hash table entries: 

[ia64] rx2620: gcc-14-20240310 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100221.initrd.img...done
[0.00] Linux version 
6.8.0-85b287316a10-ia64-w-gcc-14-20240310-lra (root@dl380-g7) 
(ia64-linux-gcc (GCC) 14.0.1 20240310 (experimental), GNU ld (GNU 
Binutils) 2.41) #1 SMP Mon Mar 11 15:07:09 CET 2024

[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fe2a000 
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fe28000

[0.00] PCDP: v3 at 0x3fe28000
[0.00] Explicit "console="; ignoring PCDP
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE2A000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2A02C CC (v01 HP rx2620 
 HP   )
[0.00] ACPI: FACP 0x3FE35CE8 F4 (v03 HP rx2620 
 HP   )
[0.00] ACPI: DSDT 0x3FE2A1C8 008390 (v01 HP rx2620 
0007 INTL 20050309)

[0.00] ACPI: FACS 0x3FE35DE0 40
[0.00] ACPI: SPCR 0x3FE35E20 50 (v01 HP rx2620 
 HP   )
[0.00] ACPI: DBGP 0x3FE35E70 34 (v01 HP rx2620 
 HP   )
[0.00] ACPI: APIC 0x3FE36090 000108 (v01 HP rx2620 
 HP   )
[0.00] ACPI: SPMI 0x3FE35EA8 50 (v04 HP rx2620 
 HP   )
[0.00] ACPI: CPEP 0x3FE35F60 34 (v01 HP rx2620 
 HP   )
[0.00] ACPI: SSDT 0x3FE32568 0001A7 (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE32718 0007DB (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE32EF8 000887 (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE33788 000887 (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE34018 000887 (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE348A8 000887 (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35138 0001A9 (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE352E8 000138 (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35428 00013C (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35568 00013C (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE356A8 00013C (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE357E8 00013C (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35928 00013C (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35A68 00013C (v01 HP rx2620 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35BA8 00013C (v01 HP rx2620 
0006 INTL 20050309)

[0.00] ACPI: Local APIC address (ptrval)
[0.00] 8 CPUs available, 8 CPUs total
[0.00] Initial ramdisk at: 0xe040f66a2000 (55001352 bytes)
[0.00] SAL 3.1: HP version 4.29
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0040]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3e873fff]
[0.00]   node   0: [mem 0x3eb9-0x3ee77fff]
[0.00]   node   0: [mem 0x3fc0-0x3fe27fff]
[0.00]   node   0: [mem 0x0001-0x000104373fff]
[0.00]   node   0: [mem 0x000104378000-0x000104b73fff]
[0.00]   node   0: [mem 0x000104b78000-0x000106b73fff]
[0.00]   node   0: [mem 0x000106b78000-0x000140173fff]
[0.00]   node   0: [mem 0x000140178000-0x000142173fff]
[0.00]   node   0: [mem 0x000142178000-0x000142773fff]
[0.00]   node   0: [mem 0x000142778000-0x000142f73fff]
[0.00]   node   0: [mem 0x000142f78000-0x0003bfff]
[0.00]   node   0: [mem 0x00404000-0x0040feffbfff]
[0.00]   node   0: [mem 0x0040ff00-0x0040ffcabfff]
[0.00]   node   0: [mem 0x0040ffd18000-0x0040ffe03fff]
[0.00]   node   0: [mem 0x0040ffe8-0x0040fffd]
[0.00] Initmem setup node 0 [mem 
0x0100-0x0040fffd]

[0.00] On node 0, zone DMA32: 1024 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 199 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 866 pages in unavailable ranges
[0.00] On node 0, zone Normal: 118 pages in 

[ia64] rx4640: gcc-14-20240310 w/LRA enabled

[Frank Scheiner via Gcc-testresults]

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC10025C.initrd.img...done
[0.00] Linux version 
6.8.0-85b287316a10-ia64-w-gcc-14-20240310-lra (root@dl380-g7) 
(ia64-linux-gcc (GCC) 14.0.1 20240310 (experimental), GNU ld (GNU 
Binutils) 2.41) #1 SMP Mon Mar 11 15:07:09 CET 2024

[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3e528000 ACPI 2.0=0x3fe22000 
ESI=0x3e529000 SMBIOS=0x3e52a000 HCDP=0x3fe2

[0.00] PCDP: v3 at 0x3fe2
[0.00] earlycon: uart8250 at MMIO 0x84053000 (options 
'9600n8')

[0.00] printk: legacy bootconsole [uart8250] enabled
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE22000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2202C A4 (v01 HP rx4640 
 HP   )
[0.00] ACPI: FACP 0x3FE36EB8 F4 (v03 HP rx4640 
 HP   )
[0.00] ACPI: DSDT 0x3FE221C8 00D0F5 (v01 HP rx4640 
0007 INTL 20050309)

[0.00] ACPI: FACS 0x3FE36FB0 40
[0.00] ACPI: SPCR 0x3FE36FF0 50 (v01 HP rx4640 
 HP   )
[0.00] ACPI: DBGP 0x3FE37040 34 (v01 HP rx4640 
 HP   )
[0.00] ACPI: APIC 0x3FE37260 C8 (v01 HP rx4640 
 HP   )
[0.00] ACPI: SPMI 0x3FE37078 50 (v04 HP rx4640 
 HP   )
[0.00] ACPI: CPEP 0x3FE37130 34 (v01 HP rx4640 
 HP   )
[0.00] ACPI: SSDT 0x3FE2F2C8 0001A7 (v01 HP rx4640 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE2F478 000F65 (v01 HP rx4640 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE303E8 0011CD (v01 HP rx4640 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE315B8 0021B5 (v01 HP rx4640 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE33778 0021B5 (v01 HP rx4640 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE35938 0011CD (v01 HP rx4640 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36B08 DC (v01 HP rx4640 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36BE8 E0 (v01 HP rx4640 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36CD8 E0 (v01 HP rx4640 
0006 INTL 20050309)
[0.00] ACPI: SSDT 0x3FE36DC8 E0 (v01 HP rx4640 
0006 INTL 20050309)

[0.00] ACPI: Local APIC address (ptrval)
[0.00] 4 CPUs available, 4 CPUs total
[0.00] Initial ramdisk at: 0xe040f66a2000 (55001352 bytes)
[0.00] SAL 3.1: HP version 4.29
[0.00] SAL Platform features:
[0.00]  None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x0001-0x0040]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0100-0x3df23fff]
[0.00]   node   0: [mem 0x3e23c000-0x3e527fff]
[0.00]   node   0: [mem 0x3fc0-0x3fe1]
[0.00]   node   0: [mem 0x0001-0x0003bfff]
[0.00]   node   0: [mem 0x00404000-0x0040feffbfff]
[0.00]   node   0: [mem 0x0040ff00-0x0040ffcbbfff]
[0.00]   node   0: [mem 0x0040ffcf8000-0x0040ffe0]
[0.00]   node   0: [mem 0x0040ffe8-0x0040fffdbfff]
[0.00] Initmem setup node 0 [mem 
0x0100-0x0040fffdbfff]

[0.00] On node 0, zone DMA32: 1024 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 198 pages in unavailable ranges
[0.00] On node 0, zone DMA32: 1462 pages in unavailable ranges
[0.00] On node 0, zone Normal: 120 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] On node 0, zone Normal: 1 pages in unavailable ranges
[0.00] On node 0, zone Normal: 15 pages in unavailable ranges
[0.00] On node 0, zone Normal: 28 pages in unavailable ranges
[0.00] On node 0, zone Normal: 9 pages in unavailable ranges
[0.00] Kernel command line: BOOT_IMAGE=net0:/AC10025C.vmlinuz 
modprobe.blacklist=radeon root=/dev/nfs ip=:ens2:dhcp hostname=rx4640
[0.00] Unknown kernel command line parameters 
"BOOT_IMAGE=net0:/AC10025C.vmlinuz ip=:ens2:dhcp", will be passed to 
user space.
[0.00] Dentry cache hash table entries: 2097152 (order: 10, 
16777216 bytes, linear)
[0.00] Inode-cache hash table entries: 1048576 (order: 9, 
8388608 bytes, linear)

[0.00] Sorting __ex_table...
[0.00] 

[ia64] Combined gcc(-14) snapshot and Linux mainline testing

[Frank Scheiner via Gcc-testresults]

Hi all,

so let me shortly explain how that GCC testing with ia64 hardware works:

For every Linux mainline RC and release (usually published between
Sunday and Monday) I built three versions of the kernel based on a
single kernel configuration for real hardware plus at least one extra
for the HP Sim platform running in Ski based on the default kernel
configuration for HP Sim.

Three versions because:

1. one version built with the last known-good gcc-14 snapshot (since
2024-03-04 always w/LRA enabled!)
2. one version built with the current gcc-14 snapshot (w/o LRA enabled)
3. one version built with the current gcc-14 snapshot (w/LRA enabled,
kernel version ends with "-lra"!)

These are then (boot to login) tested on the following machines over
multiple days (as not all machines are located at the same place):

* rx4640 (w/Madison)
* rx2620 (w/Montecito)
* rx2660 (w/Montecito)
* rx6600 (w/Montvale)
* rx2800 i2 (w/Tukwila)

I start to test with the 3rd version and if that works on all machines,
the gcc-14 snapshot it was compiled with becomes the next known-good
gcc-14 snapshot.

For the HP Sim platform I usually only build with the current gcc-14
snapshot (w/LRA enabled), as I can test it right after on the build host
and that so far always worked.

All kernels are built on a x86_64 machine using a cross-compiler built
from the mentioned gcc-14 sources and with the mentioned configuration.
I use "buildall" ([1]) to built this with a fixed version of binutils -
2.41 currently - to have at least one fixed point in each build. But
I'll look into 2.42 soon. Another more or less fixed point is the root
FS used, currently based on Debian GNU/Linux unstable. But as Debian
closes shop on ia64 soon, the next test results - due in about two weeks
(due to merge window) - will be done with a different root FS based on
T2 ([2]).

[1]: https://github.com/nathanchance/buildall

[2]: https://t2sde.org/

In the following I'll send the resulting boot logs for all machines
above and the HP Sim platform. Please note, AFAICT all issues (e.g.
kernel oopses) present in the current logs were also already present in
the past (for HP Sim for example already in 4.19.x, check the Linux
stable RC and release builds for ia64 on [3]) and are **not** due to
enabling LRA recently.

[3]:
https://github.com/johnny-mnemonic/linux-stable-rc/actions/runs/8258902207

Cheers,
Frank

Re: Stepping up as maintainer for ia64

[Frank Scheiner via Gcc]

On 09.03.24 03:18, Peter Bergner via Gcc wrote:

On 3/8/24 5:28 PM, Jonathan Wakely wrote:

On Fri, 8 Mar 2024 at 22:35, Frank Scheiner via Gcc  wrote:


On 08.03.24 23:00, Peter Bergner wrote:

On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:

I CCed Jeff who is on the commitee to forward the maintainer proposal
though I guess this will not go forward as a first step.  Instead
you are probably expected to show activity on the port, for example
post the patch series to make ia64 use LRA, get write access to the
git repository and then be promoted maintainer.


One other method for showing activity is posting regular testsuite
results on the gcc-testresults mailing list to show the community
the port is "working".


I don't want to spam this or the other list each and every week, but I


Sending test results to the gcc-testresults list is **not** spamming,
that's what the list is for!


100% agree!  If you look at what we (IBM) post, we roughly post somewhere
around 7 testsuite results per day due to runs on different hardware,
endianness and OS (Linux versus AIX).  So spam ...err... post away!




If you're testing uncommon targets (e.g. ia64-linux) then sending test
results to the list is essential so we know the target builds, because
nobody else is testing it.


Again, 100% agree!


Ok, ok, I'll do. :-)

Cheers,
Frank

Re: Stepping up as maintainer for ia64

[Frank Scheiner via Gcc]

On 08.03.24 23:00, Peter Bergner wrote:

On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:

I CCed Jeff who is on the commitee to forward the maintainer proposal
though I guess this will not go forward as a first step.  Instead
you are probably expected to show activity on the port, for example
post the patch series to make ia64 use LRA, get write access to the
git repository and then be promoted maintainer.


One other method for showing activity is posting regular testsuite
results on the gcc-testresults mailing list to show the community
the port is "working".


I don't want to spam this or the other list each and every week, but I
am since a while cross-compiling each Linux mainline RC and release with
the latest gcc-14 snapshot available each time and test the result on a
variety of real machines and on the HP Sim platform in Ski (since
recently). And since doing that I haven't seen any new ICEs since I
reported [1].

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425

Something similar is done automatically for the Linux stable RC and
releases but with a fixed gcc-13.2.0 cross-compiler (provided by Arnd
Bergmann on [2]) on GitHub, including a test run in Ski, see for example
[3].

[2]: https://mirrors.edge.kernel.org/pub/tools/crosstool/

[3]:
https://github.com/johnny-mnemonic/linux-stable-rc/actions/runs/8198165399

Both are surely not as extensive as a testsuite run, but give a good
preview I think: it's working for what we are doing with these machines,
thanks for asking.

Cheers,
Frank

Re: Linux 6.7

[Frank Scheiner]

On 28.02.24 16:35, John Paul Adrian Glaubitz wrote:

On Wed, 2024-02-28 at 09:44 -0500, Camm Maguire wrote:

Greetings and thanks for the update!  So what is the Debian status with
ia64, is it being retired or not?  And if not, what happened to yttrium?


yttrium has been decommissioned, the rest of the ia64 Debian port will
follow suit at the convenience of the Debian Ports FTP team, most likely
when either glibc 2.39 or kernel 6.7 are uploaded to unstable.


There's no way to keep a sort of "stable" release in Ports, right?

How much work will it be to later reinstate it (i.e. the ia64 port)?

Cheers,
Frank

Re: Linux 6.7

[Frank Scheiner]

On 28.02.24 15:44, Camm Maguire wrote:

Greetings and thanks for the update!  So what is the Debian status with
ia64, is it being retired or not?


Checking http://ftp.ports.debian.org/debian-ports/ now...

No, it's still there.


 And if not, what happened to yttrium?


No idea, I'm not involved in Debian Ports hardware.


Also some good news for your choice of Linux distributions for ia64:

In the meantime, ia64 is not only still available in Debian Ports ([5])
and Gentoo ([6]), but we now also got another distribution - T2/Linux
([6]) - that supports it.

[5]: https://www.ports.debian.org/

[6]: https://www.gentoo.org/downloads/#ia64

[7]: https://t2sde.org/#news-2023-12-05


Take care,


Cheers,
Frank

Re: Linux 6.7

[Frank Scheiner]

Dear all,

an update for Linux/ia64:

After finishing the verification tests with Linux v6.7 on all of my ia64
machines, I can confirm that this one is again a good one for ia64. I
didn't detect any regressions or new problems for this version and it
continues to run on the following machines:

* rx4640 (w/Madison)
* rx2620 (w/Montecito)
* rx2660 (w/Montecito)
* rx6600 (w/Montvale)
* rx2800 i2 (w/Tukwila)

..., as could be expected from the positive test results of all v6.7
release candidates on the same selection of machines.

Tomas maintains the ia64 patchset for Linux on [1] and you can find the
per Linux release (candidate) source code used for regular testing on
[2]. Please use the `[...]-w-ia64` branches.

[1]: https://github.com/lenticularis39/linux-ia64/

[2]: https://github.com/johnny-mnemonic/linux-ia64/



On the way to v6.7-w-ia64 we also managed to solve the mm problem on the
rx6600. The patch is on [3] at the moment and should be looking familiar
to loongson developers because there was a similar problem for loongson
([4]) after 61167ad5fecd got merged. Therefore Linux v6.7-w-ia64 is the
first release since v6.4 that works unmodified on the rx6600.

[3]:
https://github.com/lenticularis39/linux-ia64/commit/13a05b70f9a5a117560cafef0aa54425d6914550

[4]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b795fb9f5861ee256070d59e33130980a01fadd7



Also some good news for your choice of Linux distributions for ia64:

In the meantime, ia64 is not only still available in Debian Ports ([5])
and Gentoo ([6]), but we now also got another distribution - T2/Linux
([6]) - that supports it.

[5]: https://www.ports.debian.org/

[6]: https://www.gentoo.org/downloads/#ia64

[7]: https://t2sde.org/#news-2023-12-05



Thank you all for your hard work on Linux!

Cheers,
Frank et al

Linux/ia64: An update

[Frank Scheiner]

Dear all,

consider this an update to [1].

[1]:
https://lore.kernel.org/linux-ia64/cb4faf4f-1efc-5ae7-c8f7-7aad9c2a4...@web.de/T/#u

So about two weeks later and another two v6.6 release candidates (5 and
6) tested successfully on the following machines:

* rx2620 (w/2 x Montecito)
* rx4640 (w/2 x Madison)
* 2 x rx2660 (w/2 x Montecito, w/1 x Montvale)
* rx6600 (w/4 x Montvale)*
* rx2800 i2 (w/1 x Tukwila)

This doesn't look like a broken architecture, does it?

*) As I haven't yet found out why exactly the breakage (mentioned in
[1]) happens for the rx6600, I just reverted the problematic commit
(61167ad) to check if anything else could hinder its operation. And that
is not the case. As 61167ad seems to not break any other systems or
architectures, I want to give it a little more time and sprinkle some
printks around where it breaks, before giving up on this and contact the
author for help.

In addition I'm looking into testing patches dropped for ia64, e.g. [2]
- which worked for me - and with v6.6-rc6 also [3] - which was merged
with ddf2085 and which also worked for me (see above).

[2]:
https://lore.kernel.org/linux-ia64/d43037ee-bb7f-0cdc-a14d-8cddca8bb...@web.de/

[3]:
https://lore.kernel.org/linux-ia64/e1qgnh2-007zrz...@rmk-pc.armlinux.org.uk/



Outside of the kernel - but still relevant for distributions - work was
done for the glibc, too: Tomas discovered a seemingly long forgotten
patch for ia64 by Aurelien Jarno that was adapted to the current state
of the glibc sources and extended with own changes. In total this
enabled 50 unsupported tests, lowered the number of failed tests by 30,
and increased the total number of passing tests by 83 - don't ask me how
`make check` calculates the last number ;-). See [4] for details, since
then we could increase the number of passing tests further.

[4]: https://sourceware.org/bugzilla/show_bug.cgi?id=10163#c6

Considering that math "errors" like those (e.g. for `tanf(INFINITY)`)
are there in the glibc for more than 10 years, our progress in just
three weeks into it is not bad. We are working on getting the remaining
errors fixed, too.

Cheers,
Frank

Linux/ia64: Kernel testing effort

[Frank Scheiner]

Hi there,

as I usually only write to this list to report problems for ia64, I
thought it might be a good idea to also report a success story here.
Also in order to drive away any doubts about ia64 being a working
architecture for Linux.

This also goes CC to Debian's and Gentoo's respective ia64 lists.

In the past quarter or so (v6.4-rc7 to v6.6-rc4) I
"Build-n-Boot-to-login" tested nearly every RC and release version of
Linux (13 versions tested in total) on my Itanium zoo of machines, which
includes:

* rx2620 (w/2 x Montecito)
* rx4640 (w/2 x Madison)
* 2 x rx2660 (w/2 x Montecito, w/1 x Montvale)
* rx6600 (w/4 x Montvale)
* rx2800 i2 (w/1 x Tukwila)

...spanning multiple generations of Itanium hardware. And during that
timeframe I didn't face any major problems that affected all machines
and broke ia64 as a whole for Linux.

In short: Linux for ia64 continues to work on real machines.

I expect to continue this testing effort for the time being. It should
uncover all breakages that affect the mentioned hardware and my used
configuration.

This testing effort for example uncovered a boot problem for the rx6600
(not reproducible on any of the other machines, happens with SMT on and
off), which is now bisected and worked upon. Expect to hear about that
sometime in the future. I don't consider it a showstopper, as it only
affects this one machine, though I assume it might also affect a rx3600
(Gentoo has one) as this one is pretty similar to the rx6600 hardware-wise.

All information gathered during testing is documented on a private
website for now. If you're interested, please contact me directly off-list.

Cheers,
Frank

Re: Willing to test IA64 builds of Debian and kernel with other distributions if needed

[Frank Scheiner]

Hello Adrian,

On 27.09.23 21:57, John Paul Adrian Glaubitz wrote:

On Wed, 2023-09-27 at 21:15 +0200, Frank Scheiner wrote:

Again for Linux, Linus had a different opinion back in February and also
backed that with information provided by `git log [...]`:

```
[...]

IOW, I'm more worried about "ia64 makes it a pain to make _generic_
changes".

IOW, doing something like this:

  git log -p --no-merges --since=1.year arch/ia64/

to see what kind of pain ia64 parts of patches have caused, about a
third of them are that "look, somebody cared about ia64 explicitly".

And then the rest are trivial fixups for generic changes that aren't
any different from any other architecture. The only half-way
complicated one is the SET_FS removal, and I don't think it was any
worse than most other architectures.

IOW, it doesn't look like ia64 causes any huge issues _per_se_. I
suspect alpha continues to be more of a pain.

That said, it's entirely possible I've missed some particular painpoint.

But when it's actively known to be broken and nobody has time or
interest to look at it, at that point the "it doesn't look any more
painful than other architectures" becomes kind of moot.
```


You're talking about the kernel here only though and not the toolchain
or glibc.


IIUC the kernel is the key, w/o support for ia64 in the kernel the
remainder is not needed and will drop support, too. Tackling everything
at once seems futile, tackling one at a time could make the difference.
And to make it work we have take care of the kernel first.


In glibc, for example, many of the tests are failing [1] with
one of the glibc upstream maintainers telling me there is zero chance
these issues are going to be fixed.


I went through a lot of logs starting in 2018 (always taking the highest
release version of the different minor versions with tests enabled) and
the pass rate is actually better now - although by a small number - not
worse than in 2018 (see attached file). It's touching 96 % PASS rate for
2.38-3.

And it could be a good idea to check the details of the tests failing,
as for example hppa has 78 enabled tests less than ia64 for this
version. Maybe a specific portion of the 185 tests failing of 4424 + 185
tests enabled (leaving aside XFAIL and XPASS) for ia64 are (just)
unsupported.


Do we just want to ignore these forever and just build glibc manually all
the time with the testsuite disabled?


See further above, one at a time.


If I interpret it correctly there seem to be two distinct groups of
upstream developers in this regard: the ones that have to work on ia64
as part of their work area and want it gone loudly and the ones that
just work on ia64 as part of their work area and keep going.

The people here (You for sure, Pedro, Dimitri, me and maybe Mike, too
and maybe others, too) and there (Tomas) would surely like to work with
both of them to keep ia64 going. Together we have the machines **and**
the expertise.


I'm not doing any relevant ia64 upstream maintenance and I don't think this
is true for the others that you are counting to the second group. I think
it would be dishonest to claim that anyone in this group is doing actual
maintenance at the moment.


Strong words, looks like we've come to the bottom of it.

But is it not maintenance when the second group's changes touch ia64 and
so they adapt ia64 at the same time?

Was [2] not maintenance? And was [3] not also maintenance? And is [4]
not maintenance?

[2]:
https://github.com/torvalds/linux/commit/db3e33dd8bd956f165436afdbdbf1c653fb3c8e6

[3]:
https://github.com/torvalds/linux/commit/9471f1f2f50282b9e8f59198ec6bb738b4ccc009

[4]:
https://lore.kernel.org/linux-ia64/20230912060801.95533-1-bg...@linux.ibm.com/T/#t

Can't all these be attributed to the second group?

Maybe a detailed look at `git log` for the last two years can shed some
light on the actual details.

Or maybe you didn't understand what I meant with "Together we have the
machines **and** the expertise."? Do you presume that the first group
doesn't want to work with us even with a maintainer in place? The very
first argument of Ard in [5] and [6] was that there's no maintainer for
ia64.

[5]: https://lore.kernel.org/all/20230128122904.1345120-1-a...@kernel.org/

[6]:
https://lore.kernel.org/linux-ia64/2023021518.2565237-1-a...@kernel.org/

Cheers,
Frank


[1] 
https://buildd.debian.org/status/fetch.php?pkg=glibc=ia64=2.38-3=1694223476=0
https://buildd.debian.org/status/fetch.php?pkg=glibc=ia64=2.38-3=1694223476=0

Summary of test results:
185 FAIL
   4424 PASS
 65 UNSUPPORTED
 18 XFAIL
  6 XPASS

95,98 % PASS

https://buildd.debian.org/status/fetch.php?pkg=glibc=ia64=2.37-10=1694869287=0

Summary of test results:
185 FAIL
   4380 PASS
 63 UNSUPPORTED
 18 XFAIL
  6 XPASS

95,94 % PASS

https://buildd.debian.org/status/fetch.php?pkg=glibc=ia64=2.36-9=1685910134=0

Summary of test results:
190 FAIL
   4357 PASS
 

Re: Willing to test IA64 builds of Debian and kernel with other distributions if needed

[Frank Scheiner]

Dear Adrian,

On 27.09.23 19:41, John Paul Adrian Glaubitz wrote:

On Wed, 2023-09-27 at 19:25 +0200, Frank Scheiner wrote:

While it's great that someone is willing to take care of the kernel port,
we're still in the situation that the toolchain on ia64 is unmaintained
and has many issues.


@Adrian:
Say, wasn't that the case for how many years now? And was this not the
case when you, Jason and Jessica reinstated the ia64 port of Debian?


I think we resurrected the port sometime around 2017 [1] while the last ia64
GCC maintainer resigned in 2019 [2]. So we had two more years with both the
kernel and the toolchain being maintained. I didn't check when glibc maintenance
ceased though.


And yet in 2023 it's still usable (for gcc since 2019 w/o a maintainer
and for Linux since 2021 w/o a maintainer). Glibc lists Mike Frysinger
from Gentoo as maintainer for ia64 ([3]) - not sure if this is current
information though.

[3]: https://sourceware.org/glibc/wiki/MAINTAINERS#Machine_maintainers


Similar for Linux, where there was no maintainer for ia64 since early
2021 IIRC.


As I have explained in a previous mail, ia64 is very special


Yes I didn't follow up on this one as I thought it might be a good idea
to work on other things (gcc, Linux, etc.), too, in between and yes,
that is the usual argument: "ia64 is very special". Though true for
sure, it for example seems to have been no problem for Linux in the time
frame from May to now according to my testing.


and therefore many
changes that can be implemented rather straight-forward on most other 
architectures
are more involved on ia64 which is why many upstream maintainers would rather 
see it
go.


Again for Linux, Linus had a different opinion back in February and also
backed that with information provided by `git log [...]`:

```
[...]

IOW, I'm more worried about "ia64 makes it a pain to make _generic_
changes".

IOW, doing something like this:

git log -p --no-merges --since=1.year arch/ia64/

to see what kind of pain ia64 parts of patches have caused, about a
third of them are that "look, somebody cared about ia64 explicitly".

And then the rest are trivial fixups for generic changes that aren't
any different from any other architecture. The only half-way
complicated one is the SET_FS removal, and I don't think it was any
worse than most other architectures.

IOW, it doesn't look like ia64 causes any huge issues _per_se_. I
suspect alpha continues to be more of a pain.

That said, it's entirely possible I've missed some particular painpoint.

But when it's actively known to be broken and nobody has time or
interest to look at it, at that point the "it doesn't look any more
painful than other architectures" becomes kind of moot.
```

...see [4].

[4]:
https://lore.kernel.org/linux-ia64/CAHk-=wj9rkln+gpycfmsd8tze6zyl7mmknpvdkbetqnqym+...@mail.gmail.com/

I don't know if his experience during fixing the security issue recently
really changed his opinion on this, but (1) it's also not broken
currently and (2) there are people interested to look after it now in
addition.


I do not have strong opinion on this myself, but I understand that the port 
causes
a particular burden for upstream maintainers and I can understand their 
reasoning.


If I interpret it correctly there seem to be two distinct groups of
upstream developers in this regard: the ones that have to work on ia64
as part of their work area and want it gone loudly and the ones that
just work on ia64 as part of their work area and keep going.

The people here (You for sure, Pedro, Dimitri, me and maybe Mike, too
and maybe others, too) and there (Tomas) would surely like to work with
both of them to keep ia64 going. Together we have the machines **and**
the expertise.

Cheers,
Frank


[1] https://lists.debian.org/debian-ia64/2017/12/
[2] 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2ed6d245f7b79de73125edec51b2aa6db9ce3e6d


P.S.
New CCs, the thread started here:

https://lists.debian.org/debian-ia64/2023/09/msg00010.html

Re: Willing to test IA64 builds of Debian and kernel with other distributions if needed

[Frank Scheiner]

Hi all,

On 27.09.23 19:17, John Paul Adrian Glaubitz wrote:

On Wed, 2023-09-27 at 17:14 +, thetas.college.work wrote:

Someone wanted to be maintainer for the IA64 port of Linux kernel.
Apologies for not using send all for last email.


I saw that email but I'm afraid I'm not in the position to decide over
the fate of ia64 support in the kernel.


I'd like to interpret the silence on the kernel lists as consent, hehe. :-)


While it's great that someone is willing to take care of the kernel port,
we're still in the situation that the toolchain on ia64 is unmaintained
and has many issues.


@Adrian:
Say, wasn't that the case for how many years now? And was this not the
case when you, Jason and Jessica reinstated the ia64 port of Debian?

Similar for Linux, where there was no maintainer for ia64 since early
2021 IIRC.

Cheers,
Frank

Re: ia64 maintainership (resend)

[Frank Scheiner]

Dear Tomas,

On 24.09.23 19:20, Tomáš Glozar wrote:

Hello linux-ia64,

I noticed following the news of the proposal to remove ia64 from the
kernel that the architecture has no maintainer. I'd be happy to
volunteer to maintain the architecture, should the decision of removal
be reversed.

I'm not the ideal candidate, since I never contributed anything to the
code, but I have an Itanium machine running Linux to test on, some
spare time, and I've contributed a few patches as a part of my job of
kernel developer at Red Hat.

I'm also a contributor to T2 SDE, a source-based community Linux
distribution supporting various architectures including Alpha, HP
PA-RISC, and Itanium. I have interest in the architecture, having done
some experiments on it with code performance.

Tomas Glozar

PS: Original email got sent in multipart format by mistake, re-sending
as plain text, sorry about that.


Great! I'd be happy to support you with my kernel testing.

Also CCing this to Debian's and Gentoo's ia64 lists.

Cheers,
Frank

Re: Build regression since v6.6-rc1

[Frank Scheiner]

Hi Ard,

On 21.09.23 13:53, Ard Biesheuvel wrote:

Hello Frank,

On Thu, 21 Sept 2023 at 10:15, Frank Scheiner  wrote:


Dear all,

since v6.6-rc1 (actually introduced with [1], specific commit on [2])
the kernel build for ia64 fails like that:

```

...


Could one ([5]) or the other ([6]) please be included in v6.6 (or
earlier) to "fix" the build problem for ia64?



Do you mean by "fix" that the proposed fixes are just workarounds and
not proper fixes?


Not really, or maybe a little... :-)


I don't think that is the case - the function in
question does nothing except apply a quirk for one specific x86
platform.


...look, as I assumed and as you also say, the function is to "apply a
quirk for one specific x86 platform". So wouldn't it be better to make
that call only on x86 and leave ia64 untouched instead of putting a NOP
there?

I already wondered why no other architecture with ACPI failed to build?

Cheers,
Frank



...

[5]:
https://lore.kernel.org/lkml/CAJZ5v0hnNK4O_HyinvTp01YxXR7V4vzpMhf85yW9M2=52-o...@mail.gmail.com/

[6]:
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?id=a0334bf78b95532cec54f56b53e8ae1bfe7e1ca1


Either Arnd, Rafael or myself should send a PR to Linus to merge [6]
as a fix, as it is already queued up in -next for v6.7.

Or perhaps Linus doesn't mind grabbing it from here:

8<--

The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:

   Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)

are available in the Git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git
tags/fix-ia64-build-for-v6.6

for you to fetch changes up to a0334bf78b95532cec54f56b53e8ae1bfe7e1ca1:

   acpi: Provide ia64 dummy implementation of
acpi_proc_quirk_mwait_check() (2023-09-11 08:13:17 +)


Build fix for Itanium/ia64:

- provide dummy implementation of acpi_proc_quirk_mwait_check() which
   was moved out of generic code into arch/x86, breaking the ia64 build


Ard Biesheuvel (1):
   acpi: Provide ia64 dummy implementation of acpi_proc_quirk_mwait_check()

  arch/ia64/kernel/acpi.c | 4 
  1 file changed, 4 insertions(+)

Build regression since v6.6-rc1

[Frank Scheiner]

Dear all,

since v6.6-rc1 (actually introduced with [1], specific commit on [2])
the kernel build for ia64 fails like that:

```
Making kernel...
time make -j24
LOCALVERSION="-0bb80ecc33a8fb5a682236443c1e740d5c917d1d-ia64" ARCH=ia64
CROSS_COMPILE=ia64-linux- all
Mon Sep 11 06:24:43 PM CEST 2023
[...]
  LD [M]  net/sunrpc/sunrpc.ko
ia64-linux-ld: drivers/acpi/acpi_processor.o: in function
`acpi_early_processor_osc':
/usr/src/linux-on-ramdisk/torvalds-linux/drivers/acpi/acpi_processor.c:596:
undefined reference to `acpi_proc_quirk_mwait_check'
ia64-linux-ld: drivers/acpi/processor_pdc.o: in function
`acpi_early_processor_set_pdc':
/usr/src/linux-on-ramdisk/torvalds-linux/drivers/acpi/processor_pdc.c:113:
undefined reference to `acpi_proc_quirk_mwait_check'
make[2]: *** [scripts/Makefile.vmlinux:36: vmlinux] Error 1
make[1]: *** [/usr/src/linux-on-ramdisk/torvalds-linux/Makefile:1165:
vmlinux] Error 2
make: *** [Makefile:234: __sub-make] Error 2

real3m25.286s
user69m26.895s
sys6m37.619s
2
```

[1]:
https://github.com/torvalds/linux/commit/9bd0c413b90c6517b4a2fbedb74f50df3421b50c

[2]: https://github.com/torvalds/linux/commit/0a0e2ea642f6

In short, the change introduced a function call ([3]) in effect for ia64
without providing an implementation for that function for ia64. There's
a discussion thread on [4] that also includes a patch ([5]) to "fix" the
problem but that one unfortunately wasn't included in [1] or [2]:

```
---
 drivers/acpi/internal.h |   14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

Index: linux-pm/drivers/acpi/internal.h
===
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -148,8 +148,11 @@ int acpi_wakeup_device_init(void);
 #ifdef CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC
 void acpi_early_processor_control_setup(void);
 void acpi_early_processor_set_pdc(void);
-
+#ifdef CONFIG_X86
 void acpi_proc_quirk_mwait_check(void);
+#else
+static inline void acpi_proc_quirk_mwait_check(void) {}
+#endif
 bool processor_physically_present(acpi_handle handle);
 #else
 static inline void acpi_early_processor_control_setup(void) {}

```

For me this patch solves the build problem for v6.6-rc1 and -rc2.
There's also another patch available for that specific problem by Ard
([6]) but I haven't seen this one included either up until 42dc814 and I
also haven't tested this one.

Could one ([5]) or the other ([6]) please be included in v6.6 (or
earlier) to "fix" the build problem for ia64?

Cheers,
Frank


[3]:
https://github.com/torvalds/linux/commit/0a0e2ea642f6#diff-80c82874cec85e9c2facf52535b929ec62284c001ab081bfd1c1d164bf2a1d66R179

[4]:
https://lore.kernel.org/lkml/c7a05a44-c0be-46c2-a21d-b242524d4...@roeck-us.net/T/#u

[5]:
https://lore.kernel.org/lkml/CAJZ5v0hnNK4O_HyinvTp01YxXR7V4vzpMhf85yW9M2=52-o...@mail.gmail.com/

[6]:
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?id=a0334bf78b95532cec54f56b53e8ae1bfe7e1ca1

Re: Important packages that are broken ia64

[Frank Scheiner]

On 19.09.23 20:33, John Paul Adrian Glaubitz wrote:

On Tue, 2023-09-19 at 20:26 +0200, Frank Scheiner wrote:

The MR ([1]) was updated and now uses `-fno-var-tracking` for the
respective files only when the target architecture is ia64. This works
like so for example:

```
ifeq ($(ARCH),ia64)
  CFLAGS_bnx2x_sp.o += -fno-var-tracking
endif
```

Tested via a local kernel build where one case was using a wrong target
architecture (i386) at first to see it failing and then working after
changing that back to the correct target architecture (ia64).

[1]: https://salsa.debian.org/kernel-team/linux/-/merge_requests/852


This looks reasonable to me and I think we can have this merged as a temporary
workaround so that we can get 6.5 and 6.6 kernels built for ia64 on the buildds.


You're welcome.

Cheers,
Frank

Re: Important packages that are broken ia64

[Frank Scheiner]

On 18.09.23 22:56, Frank Scheiner wrote:

On 18.09.23 22:42, John Paul Adrian Glaubitz wrote:

On Mon, 2023-09-18 at 22:36 +0200, Frank Scheiner wrote:

I don't think this patch is acceptable in its current form as it
modifies the Makefile globally so that the flag is passed on to
the host compiler for all architectures.


Yes, thought about that, too. Know a better solution? Is there a way to
make this only affecting compilations for ia64?


You could modify CFLAGS globally in debian/rules specifically for ia64:

ifneq (,$(filter $(DEB_HOST_ARCH),ia64))
export DEB_CFLAGS_MAINT_APPEND += -fno-var-tracking
endif


That's the other extreme then, everything for ia64 gets compiled with
`-fno-var-tracking`, or? Is that more acceptable?

Maybe the per-file CFLAGS are also effective when included in the
architecture Makefile in `arch/ia64/`?

Or maybe we could query the arch from within the two Makefiles and only
apply `-fno-var-tracking` when we compile for ia64.

I'll have a look into that tomorrow.


The MR ([1]) was updated and now uses `-fno-var-tracking` for the
respective files only when the target architecture is ia64. This works
like so for example:

```
ifeq ($(ARCH),ia64)
CFLAGS_bnx2x_sp.o += -fno-var-tracking
endif
```

Tested via a local kernel build where one case was using a wrong target
architecture (i386) at first to see it failing and then working after
changing that back to the correct target architecture (ia64).

[1]: https://salsa.debian.org/kernel-team/linux/-/merge_requests/852

Cheers,
Frank

Re: Important packages that are broken ia64

[Frank Scheiner]

On 18.09.23 22:42, John Paul Adrian Glaubitz wrote:

On Mon, 2023-09-18 at 22:36 +0200, Frank Scheiner wrote:

I don't think this patch is acceptable in its current form as it
modifies the Makefile globally so that the flag is passed on to
the host compiler for all architectures.


Yes, thought about that, too. Know a better solution? Is there a way to
make this only affecting compilations for ia64?


You could modify CFLAGS globally in debian/rules specifically for ia64:

ifneq (,$(filter $(DEB_HOST_ARCH),ia64))
export DEB_CFLAGS_MAINT_APPEND += -fno-var-tracking
endif


That's the other extreme then, everything for ia64 gets compiled with
`-fno-var-tracking`, or? Is that more acceptable?

Maybe the per-file CFLAGS are also effective when included in the
architecture Makefile in `arch/ia64/`?

Or maybe we could query the arch from within the two Makefiles and only
apply `-fno-var-tracking` when we compile for ia64.

I'll have a look into that tomorrow.

Cheers,
Frank

Re: Important packages that are broken ia64

[Frank Scheiner]

On 18.09.23 22:34, John Paul Adrian Glaubitz wrote:

Hello Frank!

On Mon, 2023-09-18 at 22:14 +0200, Frank Scheiner wrote:

Worked for me, MR is here:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/852

Looking forward to new ia64 kernels for Sid.


I don't think this patch is acceptable in its current form as it
modifies the Makefile globally so that the flag is passed on to
the host compiler for all architectures.


Yes, thought about that, too. Know a better solution? Is there a way to
make this only affecting compilations for ia64?

Cheers,
Frank

Re: Important packages that are broken ia64

[Frank Scheiner]

On 18.09.23 13:43, Frank Scheiner wrote:

On 18.09.23 11:43, Frank Scheiner wrote:

Richard Biener suggested `-fno-var-tracking` or `-g0` as workaround and
both indeed workaround the problem (see [2]). I don't yet know how to
limit the addition of `-fno-var-tracking` to KBUILD_CFLAGS to
`net/ipv4/fib_semantics.c` [...]


Ok, found what I need on [1]:

```
$(CFLAGS_$@) specifies per-file options for $(CC). The @ part has a
literal value which specifies the file that it is for.
[...]
Example:

# drivers/scsi/Makefile
CFLAGS_aha152x.o =   -DAHA152X_STAT -DAUTOCONF
```

[1]:
https://github.com/torvalds/linux/blob/master/Documentation/kbuild/makefiles.rst

I'll give that a try and if it works create a MR on [2] so kernel builds
for ia64 can succeed with gcc-13 until that one is fixed.

[2]: https://salsa.debian.org/kernel-team/linux


Worked for me, MR is here:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/852

Looking forward to new ia64 kernels for Sid.

Cheers,
Frank

Re: Important packages that are broken ia64

[Frank Scheiner]

On 18.09.23 11:43, Frank Scheiner wrote:

Richard Biener suggested `-fno-var-tracking` or `-g0` as workaround and
both indeed workaround the problem (see [2]). I don't yet know how to
limit the addition of `-fno-var-tracking` to KBUILD_CFLAGS to
`net/ipv4/fib_semantics.c` [...]


Ok, found what I need on [1]:

```
$(CFLAGS_$@) specifies per-file options for $(CC). The @ part has a
literal value which specifies the file that it is for.
[...]
Example:

# drivers/scsi/Makefile
CFLAGS_aha152x.o =   -DAHA152X_STAT -DAUTOCONF
```

[1]:
https://github.com/torvalds/linux/blob/master/Documentation/kbuild/makefiles.rst

I'll give that a try and if it works create a MR on [2] so kernel builds
for ia64 can succeed with gcc-13 until that one is fixed.

[2]: https://salsa.debian.org/kernel-team/linux

Cheers,
Frank

Re: Important packages that are broken ia64

[Frank Scheiner]

Hi again,

On 18.09.23 11:43, Frank Scheiner wrote:

The resulting kernel and modules aren't yet tested, though. I plan that
for today and tomorrow.


v6.6-rc2 with the acpi build fix (I used the patch from [1]) and the
workaround for gcc-13 (see my prior email) and built with gcc 13.2.0
from [2] works fine (boot to login prompt) on:

* rx2620
* rx2800 i2

More test(ed) systems to follow tomorrow.

Cheers,
Frank

[1]:
https://lore.kernel.org/lkml/CAJZ5v0hnNK4O_HyinvTp01YxXR7V4vzpMhf85yW9M2=52-o...@mail.gmail.com/

[2]: https://mirrors.edge.kernel.org/pub/tools/crosstool/

Re: Important packages that are broken ia64

[Frank Scheiner]

Hi again,

On 15.09.23 13:47, Frank Scheiner wrote:

Hi Adrian,

On 06.08.23 10:44, John Paul Adrian Glaubitz wrote:

Hello!

The following important packages are broken on ia64:

- grub (git master) does not boot on ia64, crashes when loading stage2
(https://lists.gnu.org/archive/html/grub-devel/2023-07/msg00106.html)
- kernel FTBFS with gcc-13
(https://buildd.debian.org/status/fetch.php?pkg=linux=ia64=6.4.4-2=1690708282=0)


I created a bug report for this, see [1]. In short this happens (1) also
for cross-compilation on amd64 (most likely also for other
cross-compilation host arches), (2) for me always for the same file
(`net/ipv4/fib_semantics.c`) and function ("fib_create_info()"), but
there are others, too, see buildd link, (3) for different kernel
versions and (3) is gone when providing `-fsanitize=undefined` during
compilation.

Details in [1].

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425

I hope someone picks that up.


Richard Biener suggested `-fno-var-tracking` or `-g0` as workaround and
both indeed workaround the problem (see [2]). I don't yet know how to
limit the addition of `-fno-var-tracking` to KBUILD_CFLAGS to
`net/ipv4/fib_semantics.c` but the following patch:

```
root@dl380-g7:/usr/src# cat workaround-for-gcc-13.patch
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index b18ba8ef93ad..38f8586ebcc6 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -3,6 +3,8 @@
 # Makefile for the Linux TCP/IP (INET) layer.
 #

+KBUILD_CFLAGS += -fno-var-tracking
+
 obj-y := route.o inetpeer.o protocol.o \
 ip_input.o ip_fragment.o ip_forward.o ip_options.o \
 ip_output.o ip_sockglue.o inet_hashtables.o \

```

...makes compilation work for the used kernel configuration ([3]):

```
root@dl380-g7:/usr/src# time ./make-kernel.bash
rx2620-rx2660-rx2800-i2-combined-localmodconfig ia64
linux-on-ramdisk/torvalds-linux/ w-gcc13
[...]
Making kernel...
time make -j24
LOCALVERSION="-ce9ecca0238b140b88f43859b211c9fdfd8e5b70-ia64-w-gcc13"
ARCH=ia64 CROSS_COMPILE=ia64-linux- all
[...]
  CC  security/integrity/ima/ima_fs.o
  CC  net/ipv4/fib_semantics.o
  CC  security/integrity/ima/ima_queue.o
[...]
No errors detected in 26726 functions.

real3m41.183s
user69m23.751s
sys 6m57.374s
0
[...]
done
Build artifacts:
/boot/vmlinux-6.6.0-rc2-ce9ecca0238b140b88f43859b211c9fdfd8e5b70-ia64-w-gcc13
/boot/vmlinuz-6.6.0-rc2-ce9ecca0238b140b88f43859b211c9fdfd8e5b70-ia64-w-gcc13
/boot/config-6.6.0-rc2-ce9ecca0238b140b88f43859b211c9fdfd8e5b70-ia64-w-gcc13
/lib/modules/6.6.0-rc2-ce9ecca0238b140b88f43859b211c9fdfd8e5b70-ia64-w-gcc13.tar

real3m57.203s
user69m28.325s
sys 6m59.414s
```

Looking into the buildd link above this also needs to be applied for
`/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c` if it is indeed the
same problem.

[2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425#c5

[3]: https://gcc.gnu.org/bugzilla/attachment.cgi?id=55904

The resulting kernel and modules aren't yet tested, though. I plan that
for today and tomorrow.

Cheers,
Frank

Re: Important packages that are broken ia64

[Frank Scheiner]

Hi Adrian,

On 06.08.23 10:44, John Paul Adrian Glaubitz wrote:

Hello!

The following important packages are broken on ia64:

- grub (git master) does not boot on ia64, crashes when loading stage2 
(https://lists.gnu.org/archive/html/grub-devel/2023-07/msg00106.html)
- kernel FTBFS with gcc-13 
(https://buildd.debian.org/status/fetch.php?pkg=linux=ia64=6.4.4-2=1690708282=0)


I created a bug report for this, see [1]. In short this happens (1) also
for cross-compilation on amd64 (most likely also for other
cross-compilation host arches), (2) for me always for the same file
(`net/ipv4/fib_semantics.c`) and function ("fib_create_info()"), but
there are others, too, see buildd link, (3) for different kernel
versions and (3) is gone when providing `-fsanitize=undefined` during
compilation.

Details in [1].

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425

I hope someone picks that up.

Cheers,
Frank

Re: Retiring ia64

[Frank Scheiner]

Hi Adrian,

On 14.09.23 10:56, John Paul Adrian Glaubitz wrote:

Hi Frank!

On Thu, 2023-09-14 at 10:42 +0200, Frank Scheiner wrote:

I don't think that LTO really works on ia64. The toolchain has been bitrotting 
on
this architecture for a while now and it's slated to be dropped from the kernel
for v6.7.


That's certainly new news after returning from vacation, so a few
questions come to my mind:

* When was this decided and who decided it?


That was suggested by me in the thread that was started by Ard where we were 
discussing
the future of the port which you were also participating in. See the message of 
Ard's
pull request message [1]. My suggestion was to drop ia64 after the next LTS 
release of
the kernel as a compromise for all parties involved.


Aha, up until now I considered that nothing more than a suggestion and
[1] is just from Monday and catches me by surprise, too.

It wasn't forwarded to the Debian list though it explicitly mentions
Debian/ia64 or to me though a post from me was explicitly mentioned in
one of the involved patches ([2]).

[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=remove-ia64=cf8e8658100d4eae80ce9b21f7a81cb024dd5057

And please everybody excuse my ignorance here - I surely don't have the
whole picture - but from my more or less regular kernel testing on my
Integrities (cross-build and boot to login on every ia64 machine I have)
since May 2023 I didn't see a single problem affecting ia64 as a whole
that generated "real" work in that time frame. If somebody has a
different view, please enlighten me.

The recent build problem:
```
Making kernel...
time make -j24
LOCALVERSION="-0bb80ecc33a8fb5a682236443c1e740d5c917d1d-ia64" ARCH=ia64
CROSS_COMPILE=ia64-linux- all
Mon Sep 11 06:24:43 PM CEST 2023
[...]
  LD [M]  net/sunrpc/sunrpc.ko
ia64-linux-ld: drivers/acpi/acpi_processor.o: in function
`acpi_early_processor_osc':
/usr/src/linux-on-ramdisk/torvalds-linux/drivers/acpi/acpi_processor.c:596:
undefined reference to `acpi_proc_quirk_mwait_check'
ia64-linux-ld: drivers/acpi/processor_pdc.o: in function
`acpi_early_processor_set_pdc':
/usr/src/linux-on-ramdisk/torvalds-linux/drivers/acpi/processor_pdc.c:113:
undefined reference to `acpi_proc_quirk_mwait_check'
make[2]: *** [scripts/Makefile.vmlinux:36: vmlinux] Error 1
make[1]: *** [/usr/src/linux-on-ramdisk/torvalds-linux/Makefile:1165:
vmlinux] Error 2
make: *** [Makefile:234: __sub-make] Error 2

real3m25.286s
user69m26.895s
sys 6m37.619s
2
```

... also see [3], details on [4]) has a trivial fix and has in my eyes
nothing to do with ia64 but with the fact that introducing a function
call without providing an implementation for that function ([5]) creates
a problem.

[3]:
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=remove-ia64=a0334bf78b95532cec54f56b53e8ae1bfe7e1ca1

[4]:
https://lore.kernel.org/lkml/4bf71d86-d8a9-dce8-6a14-fc4b47325...@roeck-us.net/T/

[5]:
https://github.com/torvalds/linux/commit/9bd0c413b90c6517b4a2fbedb74f50df3421b50c#diff-906354b6bfe9645f20a74307ab5744d761eeb9dedda28b08e75982b125e17c15R596


We're certainly going to remove ia64 from Debian Ports within the next two 
months.


* Same here, specifically who is "We"?


See above.


Actually I wanted to know which people make the decisions for the Debian
port for ia64. So you and Ard then?


* And if that is already decided, why investing time in fixing ia64
problems in GRUB? Seems to be a perfect waste of time if "We"'re going
to remove it anyhow "within the next two months"...


The idea was to have ia64 supported in the upcoming 6.6 LTS kernel so that 
users interested
in the port will be able to use it for a foreseeable future in distributions 
such as Gentoo
while the upstream developers of the kernel, toolchain and glibc will be able 
to remove it
for future releases.

Fixing ia64 support in GRUB is necessary to make sure that the 2.12 release 
will still properly
work on the architecture. What happens with ia64 support after GRUB 2.12 has 
not been decided
yet.


I figure nobody will ever touch it again, judging by the fact that no
other free OS (I mean the BSDs here) has managed to enable real support
for it.

I assume if this goes through like that, we will see a lot of "working"
arches (see your list below as example) being dropped from the Linux
kernel and the remaining ecosystem in the near future.


I'm not a big fan of dropping architectures either, but the truth is that ia64 
is rather complex
from a software perspective and causes a lot of headache for upstream 
developers.


Well, I didn't see that in the timeframe vom May to now, but I only
looked at the kernel, see above.

And as everybody is telling me that (1) nobody uses the architecture
anymore and/or (2) the majority of developers don't have real machines
at hand and no emulation is available (except for Ski), I wonder how
much headaches this can cre

Retiring ia64

[Frank Scheiner]

Hi all,

On 14.09.23 09:05, John Paul Adrian Glaubitz wrote:

Hi Mathieu!

On Thu, 2023-09-14 at 08:46 +0200, Mathieu Malaterre wrote:

Could someone please double check what I did at:

* 
https://buildd.debian.org/status/fetch.php?pkg=highway=ia64=1.0.7-4=1694591500=0

For some reason LTO produces a FTBFS.

Some more details at:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051772


I don't think that LTO really works on ia64. The toolchain has been bitrotting 
on
this architecture for a while now and it's slated to be dropped from the kernel
for v6.7.


That's certainly new news after returning from vacation, so a few
questions come to my mind:

* When was this decided and who decided it?


We're certainly going to remove ia64 from Debian Ports within the next two 
months.


* Same here, specifically who is "We"?

* And if that is already decided, why investing time in fixing ia64
problems in GRUB? Seems to be a perfect waste of time if "We"'re going
to remove it anyhow "within the next two months"...


So I wouldn't bother.

Adrian


Cheers,
Frank

Re: [PATCH v9 02/11] Unify GUID types

[Frank Scheiner]

Hi Steffen, Ard,

On 14.08.23 21:59, Oliver Steffen wrote:

Quoting Vladimir 'phcoder' Serbinenko (2023-08-13 09:46:45)

Full analysis: gpt_partentry can be marked as aligned8. But following are
problem:
* protocols_per_handle may return unaligned guids
* configuration_tables array may be unaligned. On efi32 every entry is 20
bytes, so guids can't be 8-byte aligned
* The worst offender is device path as it's packed, unpredictable and contains
uuids.
* Efiemu gets guid as argument and probably should be able to handle unaligned
case. So far it's x86 only and we have no mmx and co so it's not a problem
right now unless we enable ubsan.
All in all we do need packed guid type unless those are resolved. I attach
patches for testing. If they work, I'll rearrange them a bit


Looking at https://uefi.org/specs/UEFI/2.10/02_Overview.html#data-types,
the problem is the alignment, not the packing.

As far as EFI is concerned, GUIDs are always 128bit in size. This means
there shall be no padding between the struct members. To be on the safe
side one could add the "packed" attribute to the struct, but the
original grub_efi_guid struct was not marked like that and it worked.
Whenever we had over GUIDs to EFI, they have to be aligned to 64bit.


Ard thinks that a 64 bit alignment for EFI GUIDs is a mistake - see [1]
and [2]. Hence Linux uses `__aligned(__alignof__(u32))` for "efi_guid_t"
since 2019.

[1]:
https://github.com/torvalds/linux/blob/master/include/linux/efi.h#L60-L78

[2]:
https://github.com/torvalds/linux/commit/494c704f9af0a0cddf593b381ea44320888733e6

I know I mentioned [1] earlier, but it sounds like it might have slipped
through and it might be a good idea to have both GRUB and Linux in sync
in this regard.

Cheers,
Frank

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Install problem

[Frank Scheiner]

On 07.08.23 00:39, Pedro Miguel Justo wrote:

[...]
I physically ejected the faulty PSU and the machine has been up for many
days now.


Well, now one PSU in my first rx2660 is playing dead, too. But the
system doesn't yet refuse to start. I removed it anyhow and replaced it
with one PSU from my DL385 G5 - same part number and OEM model for PSU.

Hence I assume you can put DL385 G5 (and also G2) PSUs on your watch
list, too. Though from checking on Ebay, it might be cheaper to just buy
a whole system (DL380 G5, DL385 G2/G5) with two PSUs instead of just the
PSU(s).

The problem is: you can't put your nose on the PSUs prior to buying them
to sniff if they're "toasty" or "fresh" (which is true for both options,
though).

Cheers,
Frank

Re: GRUB unexpected trap in Itanium

[Frank Scheiner]

Dear Vladimir,

On 11.08.23 03:01, Vladimir 'phcoder' Serbinenko wrote:
Le ven. 11 août 2023, 02:17, Pedro Miguel Justo > a écrit :


I have bisected the issue and it resulted into the following change:

```
06edd40db76bb78457ac26156ed5f7b62381bbe8 is the first bad commit
commit 06edd40db76bb78457ac26156ed5f7b62381bbe8
Author: Oliver Steffen mailto:ostef...@redhat.com>>
Date:   Fri May 26 13:35:43 2023 +0200

     guid: Unify GUID types

     There are 3 implementations of a GUID in GRUB. Replace them with
     a common one, placed in types.h.

     It uses the "packed" flavor of the GUID structs, the alignment
attribute
     is dropped, since it is not required.

     Signed-off-by: Oliver Steffen mailto:ostef...@redhat.com>>
     Reviewed-by: Daniel Kiper mailto:daniel.ki...@oracle.com>>
```

The issue is most likely related with an unaligned memory access
exception resulting from may global GUID variables being changed
from `grub_efi_guid_t` (which are decorated with `__attribute__
((aligned(8)))`) to the new and unified `grub_guid_t` type (now
decorated with `__attribute__ ((packed))`).

Do you concur?

That makes perfect sense. Thank you for the analysis. When passing GUID 
to EFI we need it to be aligned. I propose to partially revert the 
commit and keep efi_guid either completely separate or to include common 
guid type as the only structure in it.


Linux actually uses a minimum alignment of 32 bits, see for example [1].

[1]: 
https://github.com/torvalds/linux/blob/master/include/linux/efi.h#L60-L78


Would that make sense for GRUB, too?

Cheers,
Frank
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Important packages that are broken ia64

[Frank Scheiner]

Hi Pedro,

On 10.08.23 19:31, Frank Scheiner wrote:

Hi Pedro, all,

On 10.08.23 14:04, Pedro Miguel Justo wrote:

Here it is:

06edd40db76bb78457ac26156ed5f7b62381bbe8 is the first bad commit
commit 06edd40db76bb78457ac26156ed5f7b62381bbe8
Author: Oliver Steffen 
Date:   Fri May 26 13:35:43 2023 +0200

 guid: Unify GUID types

 There are 3 implementations of a GUID in GRUB. Replace them with
 a common one, placed in types.h.

 It uses the "packed" flavor of the GUID structs, the alignment 
attribute

 is dropped, since it is not required.

 Signed-off-by: Oliver Steffen 
 Reviewed-by: Daniel Kiper 



I had a quick look into this and the ia64 "related" part ([1]) switches
from an `__attribute__ ((aligned(8)))` struct "grub_efi_guid_t" to an
`__attribute__ ((packed))` struct "grub_guid_t" (see [2], [3] and
below), which might not work as expected on ia64.


Damn it, I should have read the commit message instead of the code 
changes. It tells the - maybe - important thing already.


Unfortunately there's no info in [4] (where this was introduced) about 
why exactly the aligment was intended in the first place.


[4]: 
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=837091258d7e9f4af3cc333ec775271f1b767d11


Linux actually uses a minimum alignment of 32 bits, see for example [5].

[5]: 
https://github.com/torvalds/linux/blob/master/include/linux/efi.h#L60-L78


@Pedro:
Does it work again with `__attribute__ ((aligned(8)))` instead of 
`__attribute__ ((packed))` for "grub_guid"?


Cheers,
Frank

Re: Important packages that are broken ia64

[Frank Scheiner]

Hi Pedro, all,

On 10.08.23 14:04, Pedro Miguel Justo wrote:

Here it is:

06edd40db76bb78457ac26156ed5f7b62381bbe8 is the first bad commit
commit 06edd40db76bb78457ac26156ed5f7b62381bbe8
Author: Oliver Steffen 
Date:   Fri May 26 13:35:43 2023 +0200

 guid: Unify GUID types

 There are 3 implementations of a GUID in GRUB. Replace them with
 a common one, placed in types.h.

 It uses the "packed" flavor of the GUID structs, the alignment attribute
 is dropped, since it is not required.

 Signed-off-by: Oliver Steffen 
 Reviewed-by: Daniel Kiper 



I had a quick look into this and the ia64 "related" part ([1]) switches
from an `__attribute__ ((aligned(8)))` struct "grub_efi_guid_t" to an
`__attribute__ ((packed))` struct "grub_guid_t" (see [2], [3] and
below), which might not work as expected on ia64.

`include/grub/types.h` defines:

```
#define GRUB_PACKED __attribute__ ((packed))
```

[1]:
https://git.savannah.gnu.org/cgit/grub.git/diff/grub-core/loader/ia64/efi/linux.c?id=06edd40db76bb78457ac26156ed5f7b62381bbe8

[2]:
https://git.savannah.gnu.org/cgit/grub.git/diff/include/grub/efi/api.h?id=06edd40db76bb78457ac26156ed5f7b62381bbe8

[3]:
https://git.savannah.gnu.org/cgit/grub.git/diff/include/grub/types.h?id=06edd40db76bb78457ac26156ed5f7b62381bbe8

Not sure if it could help to just replace `GRUB_PACKED` with
`__attribute__ ((aligned(8)))` for "grub_guid_t" in [3] or if this
breaks the cases that originally used "grub_efi_packed_guid_t".

Cheers,
Frank

Re: Install problem

[Frank Scheiner]

On 01.08.23 08:41, Pedro Miguel Justo wrote:

[...]
Oh dear… did I just jinx it?!


68    BMC     *3  0x2064C614CB020520 016F41080300 
POWER_SUPPLY_FAIL_OR_DISCONNECT

                                                       30 Jul 2023 07:44:11
67    BMC     *3  0x2064C614CB020510 016F40080300 
POWER_SUPPLY_FAIL_OR_DISCONNECT

                                                       30 Jul 2023 07:44:11


Hopefully not. What did you do (prior to that)?

Cheers,
Frank

Re: Install problem

[Frank Scheiner]

Hi again,

just some other thing that came to my mind right now:

Don't leave your rx2660 in standby with mains connected over longer
times, because its PSUs will get quite hot otherwise and most likely age
faster than normal if not burn up over time. The DL380 G5 and DL385 G2
and G5 (at least mine, upgraded from a G2) all seem to have the same
problem.

[1] states it is a design flaw. [2] mentions that there are newer PSU
revisions that might be OK in standby, so maybe you're lucky and have
one of those in yours already.

Cheers,
Frank

[1]:
https://community.hpe.com/t5/proliant-servers-ml-dl-sl/hp-proliant-dl380-g5-server-is-the-power-supply-really-broken/td-p/7001911

[2]:
https://community.hpe.com/t5/proliant-servers-ml-dl-sl/dl380-g5-power-supplies-overheat-when-plugged-in-but-off/td-p/3982566/page/3

Re: Install problem

[Frank Scheiner]

Hi Mike,

On 29.07.23 10:01, Mike Hosken wrote:

Hi Frank, Adrian and anyone else,

I've tried everything you suggested and had no luck unfortunately.

I removed the quiet from the boot options with your suggested changes
and got this output. Not being a kernel person but with google I
managed to find that Adrian has come across this exact issue and with
this kernel.

I therefore suspect that the issue is with the install cd. I did
notice an updated debian-installer with a later kernel available on
the ports cd image site. Is this issue fixed with
kernel-image-6.3.0-1-itanium-di 6.3.7-1 ia64


It is fixed with 6.3.0-0 (6.3.2 to be exact, see [this thread] for details).

[this thread]: https://lists.debian.org/debian-ia64/2023/05/msg00010.html


and would it be possible
to get an updated iso produced ?


Just to be sure:

You managed to get a working installation with an older than the latest
installer ISO?

Would it then be possible to start anew and than just install a newer
kernel image from snapshot.debian.org before actually upgrading the
remaining OS, e.g. this one:

https://snapshot.debian.org/archive/debian-ports/20230703T174302Z/pool-ia64/main/l/linux/linux-image-6.3.0-2-mckinley_6.3.11-1_ia64.deb

...or maybe even this one:

https://snapshot.debian.org/archive/debian-ports/20230703T174302Z/pool-ia64/main/l/linux/linux-image-6.4.0-0-mckinley_6.4.1-1~exp1_ia64.deb

Cheers,
Frank

Re: Install problem

[Frank Scheiner]

Hi Mike,

On 29.07.23 06:40, Mike Hosken wrote:

Hi everyone,

I have a rx2660 ia64 machine, I’m wanting to install Debian on and
have run into some issues. The Debian 12 ia64 installation disk won’t
boot. I get to grub and choose install, it starts to boot and then
the system reboots. Choosing expert mode causes the same issue.
Thinking it might be hardware I tried the earlier install cd and
managed to install successfully but unfortunately the system breaks
trying to update to the latest Sid version. I’m thinking it might be
kernel parameters.


I have always blacklisted the "radeon" module for my rx2660s:

```
modprobe.blacklist=radeon
```

...but that could require to use it over iLO MP exclusively, which is 
not too bad or too hard to do (via both telnet and serial). IIRC you 
should get the default configuration by pushing the button at the rear 
for a longer time (see e.g. [1] for details about its functionality) and 
then login over serial (9600 bps, 8n1) with "Admin:Admin". After 
configuring telnet access (or maybe it is configured per default already 
and uses DHCP) you can control it via the iLO MP network port, too.


E.g. to power on the machine enter command menu (or mode?) via "cm", 
then enter `ps -on -nc`. Hit "Ctrl+B" to return to the main menu and 
enter "co" to get to the system console. "Ctrl+B" also returns from the 
system console, if you need to issue a hard reset (in command menu enter 
`rs -nc`) for example.


My first rx2660 also still has:

```
hardened_usercopy=off
```

...in its kernel commandline, but I believe this is no longer necessary 
as it is deactivated in the Debian version of the Linux kernel for ia64 IIC.


HTH.
Cheers,
Frank

Re: M4000 failing to boot Debian Sparc64

[Frank Scheiner]

Hi,

On 02.07.23 16:35, Vocalía Infraestructura TIC CEEINA wrote:

Hi Frank,

Thank you for your fast answer. I also thought when installing that it 
was an incompatibility problem with the processor architecture, as you 
stated.


However, having a look at the wiki (https://wiki.debian.org/Sparc64 
) it seems to me that machines with a 
sun4u SPARC VII+ processor should be able to run it, right? Our M4000 
has a VII+ processor.


Can you post the kernel messages for your boot, so we can reference it 
in the Debian Wiki? Maybe by comparing them to what was posted about a 
M3000 with SPARC64 VII on [1] and SPARC64 V on [2], we can conclude if 
support for SPARC64 VII+ is any better than for those other processors.


[1]: 
https://oss.oracle.com/pipermail/linux-sparc-users/2017-October/27.html


[2]: https://lists.debian.org/debian-sparc/2017/09/msg00017.html

You don't happen to have a SPARC64 X based system for testing? I think I 
never saw a dmesg from such a system, too.


Maybe I have not fully understood the wiki or your message, therefore 
sorry if I'm wrong.


I went through the history of changes and the one that adds the 
information about SPARC64 processors ([3]) was done by an Alex McWhirter.


[3]: https://wiki.debian.org/Sparc64?action=diff=25=26

Checking my email archive I actually even asked him (via 
alexmcwhir...@triadic.us, though not sure if that is the correct 
address) exactly about this change, but never got a reply IIRC.


Cheers,
Frank

Re: M4000 failing to boot Debian Sparc64

[Frank Scheiner]

Hi,

On 02.07.23 12:35, Vocalía Infraestructura TIC CEEINA wrote:

Hi,

We are trying to boot Debian Sparc64 on a SPARC Enterprise M4000 server 
(SPARC64 VII+), but, after selecting normal / expert / secure install 
mode, we get this error message and the installer quits:


/ERROR: Last Trap: Division by Zero/
/%TL:1 %TT:28 %TPC:43056c %TnPC:430570 %TSTATE:1180001603/
/%PSTATE:16 ( IE:1 PRIV:1 PEF:1 )/


We have tried with the following ISO images: 
/debian-12.0.0-sparc64-NETINST-1.iso/, 
/debian-10.0-sparc64-NETINST-1.iso/ and /debian-9.0-sparc64-NETINST-1.iso/.


Maybe this is an unknown incompatibility, or we are missing some steps 
when installing.


No, it just does not work on those machines. E.g. the only thing that 
works on e.g. SPARC64 V (tested on a PRIMEPOWER 250) is GRUB2.


AFAIK the Linux kernel only works (fully) on Sun's (Ultra)SPARC (I, II, 
IIi/e, III, IIIi, IV and T)s and Fujitsu's SPARC64 X.



¿Any ideas on how to fix this? ¿Has anyone experienced something similar?


It would require some development effort. OpenBSD has support for those 
machines, though, if that could be an alternative for you.


Cheers,
Frank

Re: Linux 6.1.27, cgroup: Instruction fault 4 with systemd

[Frank Scheiner]

Hi,

let me add some additional data point(s):

After some testing on different machines and with different kernel types
it looks like this problem is exclusive to MP kernels. This also when
running a MP kernel on a single processor machine actually (tested on an
AlphaServer 800 5/400 w/EV56).

Running an SP kernel does not trigger that problem.

I posted a diff between the -alpha-generic and -alpha-smp kernel
configurations on [1].

[1]: https://pastebin.com/AwZQjHD9

On 22.05.23 11:37, John Paul Adrian Glaubitz wrote:

Hello Frank!

On Mon, 2023-05-22 at 11:34 +0200, Frank Scheiner wrote:

Maybe someone on linux-alpha has an idea what could be the reason?


Try reproducing it with libcgroup to see if it's a systemd or a kernel bug:


https://wiki.archlinux.org/title/cgroups#Examples


Took me a while to get back to this and actually get it working...

Following misc. examples and manpages (e.g. [2] and [3]) I did the
following to test cgroup functionality with System V init installed and
running instead of systemd:

```
root@ds25:~# uname -a
Linux ds25 6.3.0-1-alpha-smp #1 SMP Debian 6.3.7-1 (2023-06-12) alpha
GNU/Linux

root@ds25:~# mount
[...]
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,mode=755,inode64)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
[...]
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,relatime,rdma)
cgroup on /sys/fs/cgroup/misc type cgroup (rw,relatime,misc)

root@ds25:~# CGROUP=/sys/fs/cgroup

root@ds25:~# mkdir $CGROUP/red
root@ds25:~# mount -t cgroup -o cpuset red $CGROUP/red
root@ds25:~# mkdir -p $CGROUP/red/shells/bash
root@ds25:~# chown root:root $CGROUP/red/shells/bash/*
root@ds25:~# id johndoe
uid=1001(johndoe) gid=1001(johndoe) groups=1001(johndoe),100(users)
root@ds25:~# chown root:johndoe $CGROUP/red/shells/bash/tasks
root@ds25:~# echo $(cgget -n -v -r cpuset.mems /) >
$CGROUP/red/shells/cpuset.mems
root@ds25:~# echo $(cgget -n -v -r cpuset.cpus /) >
$CGROUP/red/shells/cpuset.cpus
root@ds25:~# echo 0 > $CGROUP/red/shells/bash/cpuset.mems
root@ds25:~# echo 0 > $CGROUP/red/shells/bash/cpuset.cpus

root@ds25:~# cat /proc/self/cgroup
13:misc:/
12:rdma:/
11:pids:/
10:net_prio:/
9:perf_event:/
8:net_cls:/
7:freezer:/
6:devices:/
5:memory:/
4:blkio:/
3:cpuacct:/
2:cpu:/
1:cpuset:/

root@ds25:~# echo $$
1496

root@ds25:~# cgexec -g cpuset:shells/bash bash

root@ds25:~# echo $$
1695

root@ds25:~# cat /proc/self/cgroup
13:misc:/
[...]
2:cpu:/
1:cpuset:/shells/bash
```

[2]:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/ch-using_control_groups

[3]: https://wiki.archlinux.org/title/cgroups#Examples

I then ran `7za b` in that shell and though `7za` executes two threads
assuming it has access to both CPUs, `htop` showed both of them running
on the first processor only. So it looks like at least this part of the
cgroup functionality is working with Linux 6.3.0-1 from Debian when
using System V init.

So it could be that this problem is only triggered with one or multiple
specific controller(s). But I don't exactly know how to determine the
used controller(s) for target "graphical.target" - where this seems to
happen according to (see more details on [4]):

```
[...]
[   11.864251] systemd[1]: Queued start job for default target
graphical.target.
[   11.958978] CPU 1
[   11.958978] systemd(1): Instruction fault 4
[...]
```

[4]: https://lists.debian.org/debian-alpha/2023/05/msg00012.html

Cheers,
Frank

Re: Updated installation images for Debian Ports 2023-06-06

[Frank Scheiner]

Hi!

On 06.06.23 16:22, John Paul Adrian Glaubitz wrote:

Hello!

On Tue, 2023-06-06 at 16:19 +0200, Frank Scheiner wrote:

On 06.06.23 15:52, John Paul Adrian Glaubitz wrote:

Hello!

I have created updated installation images for Debian Ports.

These can be found here:

- https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/

I have already successfully tested the sparc64 installer.


On what machine did you test it?


Inside an LDOM on a SPARC-T5.


Thanks, good to know.

Cheers,
Frank

Re: Updated installation images for Debian Ports 2023-06-06

[Frank Scheiner]

Hi Adrian,

On 06.06.23 15:52, John Paul Adrian Glaubitz wrote:

Hello!

I have created updated installation images for Debian Ports.

These can be found here:

- https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-06/

I have already successfully tested the sparc64 installer.


On what machine did you test it?

Cheers,
Frank

Re: [PATCH] module: fix module load for ia64

[Frank Scheiner]

On 29.05.23 01:00, Song Liu wrote:

Frank reported boot regression in ia64 as:

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100221.initrd.img...done
[0.00] Linux version 6.4.0-rc3 (root@x4270) (ia64-linux-gcc
(GCC) 12.2.0, GNU ld (GNU Binutils) 2.39) #1 SMP Thu May 25 15:52:20
CEST 2023
[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fe2a000
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fe28000
[0.00] PCDP: v3 at 0x3fe28000
[0.00] earlycon: uart8250 at MMIO 0xf405 (options
'9600n8')
[0.00] printk: bootconsole [uart8250] enabled
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE2A000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2A02C CC (v01 HP rx2620
 HP   )
[...]
[3.793350] Run /init as init process
Loading, please wait...
Starting systemd-udevd version 252.6-1
[3.951100] [ cut here ]
[3.951100] WARNING: CPU: 6 PID: 140 at kernel/module/main.c:1547
__layout_sections+0x370/0x3c0
[3.949512] Unable to handle kernel paging request at virtual address
1000
[3.951100] Modules linked in:
[3.951100] CPU: 6 PID: 140 Comm: (udev-worker) Not tainted 6.4.0-rc3 #1
[3.956161] (udev-worker)[142]: Oops 11003706212352 [1]
[3.951774] Hardware name: hp server rx2620   , BIOS
04.29
11/30/2007
[3.951774]
[3.951774] Call Trace:
[3.958339] Unable to handle kernel paging request at virtual address
1000
[3.956161] Modules linked in:
[3.951774]  [] show_stack.part.0+0x30/0x60
[3.951774] sp=e00183a67b20
bsp=e00183a61628
[3.956161]
[3.956161]

which bisect to module_memory change [1].

Debug showed that ia64 uses some special sections:

__layout_sections: section .got (sh_flags 1002) matched to MOD_INVALID
__layout_sections: section .sdata (sh_flags 1003) matched to MOD_INVALID
__layout_sections: section .sbss (sh_flags 1003) matched to MOD_INVALID

All these sections are loaded to module core memory before [1].

Fix ia64 boot by loading these sections to MOD_DATA (core rw data).

[1] commit ac3b43283923 ("module: replace module_layout with module_memory")

Fixes: ac3b43283923 ("module: replace module_layout with module_memory")
Reported-by: Frank Scheiner 
Closes: https://lists.debian.org/debian-ia64/2023/05/msg00010.html
Closes: https://marc.info/?l=linux-ia64=168509859125505
Cc: Linus Torvalds 
Signed-off-by: Song Liu 
---
  kernel/module/main.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/module/main.c b/kernel/module/main.c
index b4c7e925fdb0..9da4b551321e 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -1521,14 +1521,14 @@ static void __layout_sections(struct module *mod, 
struct load_info *info, bool i
MOD_RODATA,
MOD_RO_AFTER_INIT,
MOD_DATA,
-   MOD_INVALID,/* This is needed to match the masks array */
+   MOD_DATA,
};
static const int init_m_to_mem_type[] = {
MOD_INIT_TEXT,
MOD_INIT_RODATA,
MOD_INVALID,
MOD_INIT_DATA,
-   MOD_INVALID,/* This is needed to match the masks array */
+   MOD_INIT_DATA,
};

for (m = 0; m < ARRAY_SIZE(masks); ++m) {


Just want to add another observation (though not strictly ia64 but I
wanted to keep the context):

Testing showed that this patch also fixes module loading for alpha
(tested on an AlphaServer DS25 w/v6.4-rc4 w/ and w/o the patch applied).

Cheers,
Frank

Re: [PATCH] module: fix module load for ia64

[Frank Scheiner]

On 29.05.23 01:00, Song Liu wrote:

Frank reported boot regression in ia64 as:

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100221.initrd.img...done
[0.00] Linux version 6.4.0-rc3 (root@x4270) (ia64-linux-gcc
(GCC) 12.2.0, GNU ld (GNU Binutils) 2.39) #1 SMP Thu May 25 15:52:20
CEST 2023
[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fe2a000
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fe28000
[0.00] PCDP: v3 at 0x3fe28000
[0.00] earlycon: uart8250 at MMIO 0xf405 (options
'9600n8')
[0.00] printk: bootconsole [uart8250] enabled
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE2A000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2A02C CC (v01 HP rx2620
 HP   )
[...]
[3.793350] Run /init as init process
Loading, please wait...
Starting systemd-udevd version 252.6-1
[3.951100] [ cut here ]
[3.951100] WARNING: CPU: 6 PID: 140 at kernel/module/main.c:1547
__layout_sections+0x370/0x3c0
[3.949512] Unable to handle kernel paging request at virtual address
1000
[3.951100] Modules linked in:
[3.951100] CPU: 6 PID: 140 Comm: (udev-worker) Not tainted 6.4.0-rc3 #1
[3.956161] (udev-worker)[142]: Oops 11003706212352 [1]
[3.951774] Hardware name: hp server rx2620   , BIOS
04.29
11/30/2007
[3.951774]
[3.951774] Call Trace:
[3.958339] Unable to handle kernel paging request at virtual address
1000
[3.956161] Modules linked in:
[3.951774]  [] show_stack.part.0+0x30/0x60
[3.951774] sp=e00183a67b20
bsp=e00183a61628
[3.956161]
[3.956161]

which bisect to module_memory change [1].

Debug showed that ia64 uses some special sections:

__layout_sections: section .got (sh_flags 1002) matched to MOD_INVALID
__layout_sections: section .sdata (sh_flags 1003) matched to MOD_INVALID
__layout_sections: section .sbss (sh_flags 1003) matched to MOD_INVALID

All these sections are loaded to module core memory before [1].

Fix ia64 boot by loading these sections to MOD_DATA (core rw data).

[1] commit ac3b43283923 ("module: replace module_layout with module_memory")

Fixes: ac3b43283923 ("module: replace module_layout with module_memory")
Reported-by: Frank Scheiner 
Closes: https://lists.debian.org/debian-ia64/2023/05/msg00010.html
Closes: https://marc.info/?l=linux-ia64=168509859125505
Cc: Linus Torvalds 
Signed-off-by: Song Liu 
---
  kernel/module/main.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/module/main.c b/kernel/module/main.c
index b4c7e925fdb0..9da4b551321e 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -1521,14 +1521,14 @@ static void __layout_sections(struct module *mod, 
struct load_info *info, bool i
MOD_RODATA,
MOD_RO_AFTER_INIT,
MOD_DATA,
-   MOD_INVALID,/* This is needed to match the masks array */
+   MOD_DATA,
};
static const int init_m_to_mem_type[] = {
MOD_INIT_TEXT,
MOD_INIT_RODATA,
MOD_INVALID,
MOD_INIT_DATA,
-   MOD_INVALID,/* This is needed to match the masks array */
+   MOD_INIT_DATA,
};

for (m = 0; m < ARRAY_SIZE(masks); ++m) {


Just want to add another observation (though not strictly ia64 but I
wanted to keep the context):

Testing showed that this patch also fixes module loading for alpha
(tested on an AlphaServer DS25 w/v6.4-rc4 w/ and w/o the patch applied).

Cheers,
Frank

Re: Boot regression in Linux v6.4-rc3

[Frank Scheiner]

On 31.05.23 21:14, Luis Chamberlain wrote:

On Wed, May 31, 2023 at 11:16 AM Frank Scheiner  wrote:

Looking forward to the next occasion - for your sake maybe on another
architecture, but can't promise... ;-)


I think it would be prudent for Song to also ask you to test his
future upcoming modules patches on ia64 given how hard it is to
procure such hardware too.


Sure!

Cheers,
Frank

Re: Boot regression in Linux v6.4-rc3

[Frank Scheiner]

Hi Linus, hi Song,

On 29.05.23 00:46, Song Liu wrote:

[...]
Thanks for running the test!

I will send the official patch.

Thanks,
Song


With the fix merged and to conclude this, I'd like to add that it was a
pleasure to work with you on this problem, although I didn't do much.

Looking forward to the next occasion - for your sake maybe on another
architecture, but can't promise... ;-)

Cheers,
Frank

Re: [PATCH] module: fix module load for ia64

[Frank Scheiner]

On 29.05.23 01:00, Song Liu wrote:

Frank reported boot regression in ia64 as:

ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100221.initrd.img...done
[0.00] Linux version 6.4.0-rc3 (root@x4270) (ia64-linux-gcc
(GCC) 12.2.0, GNU ld (GNU Binutils) 2.39) #1 SMP Thu May 25 15:52:20
CEST 2023
[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fe2a000
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fe28000
[0.00] PCDP: v3 at 0x3fe28000
[0.00] earlycon: uart8250 at MMIO 0xf405 (options
'9600n8')
[0.00] printk: bootconsole [uart8250] enabled
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE2A000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2A02C CC (v01 HP rx2620
 HP   )
[...]
[3.793350] Run /init as init process
Loading, please wait...
Starting systemd-udevd version 252.6-1
[3.951100] [ cut here ]
[3.951100] WARNING: CPU: 6 PID: 140 at kernel/module/main.c:1547
__layout_sections+0x370/0x3c0
[3.949512] Unable to handle kernel paging request at virtual address
1000
[3.951100] Modules linked in:
[3.951100] CPU: 6 PID: 140 Comm: (udev-worker) Not tainted 6.4.0-rc3 #1
[3.956161] (udev-worker)[142]: Oops 11003706212352 [1]
[3.951774] Hardware name: hp server rx2620   , BIOS
04.29
11/30/2007
[3.951774]
[3.951774] Call Trace:
[3.958339] Unable to handle kernel paging request at virtual address
1000
[3.956161] Modules linked in:
[3.951774]  [] show_stack.part.0+0x30/0x60
[3.951774] sp=e00183a67b20
bsp=e00183a61628
[3.956161]
[3.956161]

which bisect to module_memory change [1].

Debug showed that ia64 uses some special sections:

__layout_sections: section .got (sh_flags 1002) matched to MOD_INVALID
__layout_sections: section .sdata (sh_flags 1003) matched to MOD_INVALID
__layout_sections: section .sbss (sh_flags 1003) matched to MOD_INVALID

All these sections are loaded to module core memory before [1].

Fix ia64 boot by loading these sections to MOD_DATA (core rw data).

[1] commit ac3b43283923 ("module: replace module_layout with module_memory")

Fixes: ac3b43283923 ("module: replace module_layout with module_memory")
Reported-by: Frank Scheiner 
Closes: https://lists.debian.org/debian-ia64/2023/05/msg00010.html
Closes: https://marc.info/?l=linux-ia64=168509859125505
Cc: Linus Torvalds 
Signed-off-by: Song Liu 
---
  kernel/module/main.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/module/main.c b/kernel/module/main.c
index b4c7e925fdb0..9da4b551321e 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -1521,14 +1521,14 @@ static void __layout_sections(struct module *mod, 
struct load_info *info, bool i
MOD_RODATA,
MOD_RO_AFTER_INIT,
MOD_DATA,
-   MOD_INVALID,/* This is needed to match the masks array */
+   MOD_DATA,
};
static const int init_m_to_mem_type[] = {
MOD_INIT_TEXT,
MOD_INIT_RODATA,
MOD_INVALID,
MOD_INIT_DATA,
-   MOD_INVALID,/* This is needed to match the masks array */
+   MOD_INIT_DATA,
};

for (m = 0; m < ARRAY_SIZE(masks); ++m) {


Tested to work on top of v6.4-rc4 fixing the boot regression for:

* rx4640 (w/Madison and zx1)
* rx2620 (w/Montecito and zx1)
* rx2660 (w/Montvale and zx2 - Adrian's rx2660 is with Montecito instead
IIRC, so I only tested on the one with Montvale processor)
* rx6600 (w/Montvale and zx2)
* rx2800 i2 (w/Tukwila)

Tested-by: Frank Scheiner 

Re: Boot regression in Linux v6.4-rc3

[Frank Scheiner]

Hi again,

On 28.05.23 09:30, Frank Scheiner wrote:

[...]
Thanks, that patch (as -patch4 on top of v6.4-rc3) fixes the boot 
regression for me on the rx2620:


[...]

Great! I'll give it a try on my rx2800-i2, too, but assume it wil work 
there, too.


Indeed, -patch4 also makes it work on the rx2800-i2:

```
ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC10027B.initrd.img...done
[0.00] Linux version 
6.4.0-rc3-44c026a73be8038f03dbdeef028b642880cf1511-patch4 (root@x4270) 
(ia64-linux-gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.39) #1 SMP Sun May 
28 09:08:44 CEST 2023

[0.00] efi: EFI v2.1 by HP
[0.00] efi: SALsystab=0xdfdd63a18 ESI=0xdfdd63f18 ACPI 
2.0=0x3d3c4014 HCDP=0xd8798 SMBIOS=0x3d368000

[0.00] PCDP: v3 at 0xd8798
[0.00] earlycon: uart8250 at I/O port 0x4000 (options '115200n8')
[0.00] printk: bootconsole [uart8250] enabled
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3D3C4014 24 (v02 HP)
[0.00] ACPI: XSDT 0x3D3C4580 000124 (v01 HP RX2800-2 
0001  0113)

[...]
[   36.649531] Run /init as init process
Loading, please wait...
Starting systemd-udevd version 252.6-1
[   36.865635] pps_core: LinuxPPS API ver. 1 registered
[   36.869321] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 
Rodolfo Giometti 

[   36.885025] PTP clock support registered
[   36.910852] ACPI: bus type USB registered
[   36.918198] usbcore: registered new interface driver usbfs
[   36.924762] usbcore: registered new interface driver hub
[   36.922133] igb: Intel(R) Gigabit Ethernet Network Driver
[   36.931386] usbcore: registered new device driver usb
[   36.938149] igb: Copyright (c) 2007-2014 Intel Corporation.
[...]
[  OK  ] Finished apt-daily-upgrade… apt upgrade and clean activities.

Debian GNU/Linux 12 rx2800-i2 -

rx2800-i2 login:
```

I'll try to test this on other machines (rx4640 w/Madison, rx2660 
w/Montecito/Montvale, rx6600 w/Montvale) as well, starting on Tuesday if 
possible.




There is an issue - only for the rx2800-i2 - seemingly related to it's 
PCIe NIC(s) and MSIs, but this is already there in 6.3.x (see first part 
of [1]) and **not related to the problem of this thread (AFAICT)** and - 
more important - doesn't affect operation: The machine is working 
diskless using one of those interfaces so it can't be that bad. I'll 
look into bisecting that issue as well.


[1]: https://lists.debian.org/debian-ia64/2023/05/msg00010.html

Cheers,
Frank

Re: Boot regression in Linux v6.4-rc3

[Frank Scheiner]

Hi Song, Linus,

On 28.05.23 07:24, Song Liu wrote:

AFAICT,  .got should go to rodata, while .sdata and .sbss should go
to (rw)data. However, reading the code before the module_memory
change, I think they were all copied to (rw)data, which is not ideal but
most likely OK.

To match the behavior before the module_memory change, I think
we need something like the following.

Frank, could you please give it a try?

Thanks,
Song

diff --git i/kernel/module/main.c w/kernel/module/main.c
index 0f9183f1ca9f..e4e723e1eb21 100644
--- i/kernel/module/main.c
+++ w/kernel/module/main.c
@@ -1514,14 +1514,14 @@ static void __layout_sections(struct module
*mod, struct load_info *info, bool i
 MOD_RODATA,
 MOD_RO_AFTER_INIT,
 MOD_DATA,
-   MOD_INVALID,/* This is needed to match the masks array */
+   MOD_DATA,
 };
 static const int init_m_to_mem_type[] = {
 MOD_INIT_TEXT,
 MOD_INIT_RODATA,
 MOD_INVALID,
 MOD_INIT_DATA,
-   MOD_INVALID,/* This is needed to match the masks array */
+   MOD_INIT_DATA,
 };

 for (m = 0; m < ARRAY_SIZE(masks); ++m) {


Thanks, that patch (as -patch4 on top of v6.4-rc3) fixes the boot 
regression for me on the rx2620:


```
ELILO v3.16 for EFI/IA-64
..
Uncompressing Linux... done
Loading file AC100221.initrd.img...done
[0.00] Linux version 
6.4.0-rc3-44c026a73be8038f03dbdeef028b642880cf1511-patch4 (root@x4270) 
(ia64-linux-gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.39) #1 SMP Sun May 
28 09:08:44 CEST 2023

[0.00] efi: EFI v1.1 by HP
[0.00] efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fe2a000 
ESI=0x3ee7b000 SMBIOS=0x3ee7c000 HCDP=0x3fe28000

[0.00] PCDP: v3 at 0x3fe28000
[0.00] earlycon: uart8250 at MMIO 0xf405 (options 
'9600n8')

[0.00] printk: bootconsole [uart8250] enabled
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x3FE2A000 28 (v02 HP)
[0.00] ACPI: XSDT 0x3FE2A02C CC (v01 HP rx2620 
 HP   )

[...]
[3.810346] Run /init as init process
Loading, please wait...
Starting systemd-udevd version 252.6-1
[3.985378] e1000: Intel(R) PRO/1000 Network Driver
[3.989378] e1000: Copyright (c) 1999-2006 Intel Corporation.
[3.993375] GSI 29 (level, low) -> CPU 7 (0x0700) vector 53
[4.030382] ACPI: bus type USB registered
[4.030382] usbcore: registered new interface driver usbfs
[4.034382] usbcore: registered new interface driver hub
[4.034382] usbcore: registered new device driver usb
[4.040609] GSI 18 (level, low) -> CPU 0 (0x) vector 54
[4.040621] ehci-pci :00:01.2: EHCI Host Controller
[...]
[  OK  ] Finished systemd-update-ut… - Record Runlevel Change in UTMP.
[   14.568606] ioc1: LSI53C1030 C0: Capabilities={Initiator,Target}

Debian GNU/Linux 12 rx2620 -

rx2620 login:
```

Great! I'll give it a try on my rx2800-i2, too, but assume it wil work 
there, too.


Cheers,
Frank

Re: Boot regression in Linux v6.4-rc3

[Frank Scheiner]

Hi,

On 27.05.23 21:34, Linus Torvalds wrote:

On Sat, May 27, 2023 at 11:41 AM Frank Scheiner  wrote:


Ok, I put the decoded console messages on [2].

[2]: https://pastebin.com/dLYMijfS


Ugh. Apparently ia64 decoding isn't great. But at least it gives
multiple line numbers:

load_module (kernel/module/main.c:2291 kernel/module/main.c:2412
kernel/module/main.c:2868)

except your kernel obviously has those test-patches, so I still don't
know exactly where they are.


Erm, I see. I did recreate a vanilla v6.4-rc3 and ran that, decoded 
result is on [1] - not sure if it makes it a little better.


[1]: https://pastebin.com/z5XzEnhq

I did also try to build and run a SP kernel to maybe get a better 
picture in the traces, but that seems to require FLATMEM, which seems to 
not work on that machine or due to the way it is configured (and yeah, 
it was also the wrong commit I used for it and it was patched...):


```
[0.00] Linux version 
6.4.0-rc3-933174ae28ba72ab8de5b35cb7c98fc211235096-patch3_sp 
(root@x4270) (ia64-linux-gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.39) 
#1 Sat May 27 21:28:44 CEST 2023

[...]
[0.00] ACPI: SSDT 0x3FE35BA8 00013C (v01 HP rx2620 
0006 INTL 20050309)

[0.00] ACPI: Local APIC address (ptrval)
[0.00] 1 CPUs available, 1 CPUs total
[...]
[0.00] Kernel panic - not syncing: Cannot use FLATMEM with 
246784MB hole

[0.00] Please switch over to SPARSEMEM
[0.00] ---[ end Kernel panic - not syncing: Cannot use FLATMEM 
with 246784MB hole

[0.00] Please switch over to SPARSEMEM ]---
```


But it looks like it is in move_module(). Strange. I don't know how it
gets to "__copy_user" from there...

[ Looks at the ia64 code ]

Oh.

It turns out that it *says* __copy_user(), but the code is actually
shared with the regular memcpy() function, which does

   GLOBAL_ENTRY(memcpy)
 and r28=0x7,in0
 and r29=0x7,in1
 mov f6=f0
 mov retval=in0
 br.cond.sptk .common_code
 ;;

where that ".common_code" label is - surprise surprise - the common
copy code, and so when the oops reports that the problem happened in
__copy_user(), it actually is in this case just a normal memcpy.

Ok, so it's probably the

 memcpy(dest, (void *)shdr->sh_addr, shdr->sh_size);

in move_module() that takes a fault.  And looking at the registers,
the destination is in r17/r18, and your dump has

 unable to handle kernel paging request at virtual address 1000
 ...
 r17 : 0fff r18 : 1000

so it's almost certainly that 'dest' that is bad.

Which I guess shouldn't surprise anybody.

But that's where my knowledge of ia64 and the new module loader layout ends.


Thanks for your help and going as far as you could, that's greatly 
appreciated. Running that stuff is surely easier than debugging it. :-)


Cheers,
Frank

Re: Boot regression in Linux v6.4-rc3

[Frank Scheiner]

Hi,

On 27.05.23 19:08, Linus Torvalds wrote:

Anyway, the WARN_ON() is likely related, but the bug is clearly an
unexpected page fault in __copy_user() when called by load_module().

The ia64 oops output is nasty, presumably because ia64 aggressively
inlines things. It would help a lot if you enabled debug info (maybe
you already do?)


I believe it is enabled - I have at least CONFIG_DEBUG_KERNEL=y and
CONFIG_DEBUG_INFO=y - my kernel config is on [1] for reference.

[1]: https://pastebin.com/HRQtZ9vb


and then run the oops through
./scripts/decode_stacktrace.sh which will figure out line numbers,
inlining etc.

Because I don't even see why it would call __copy_user() in the first
place. This is 'finit_module()' that loads the module data from a
file, not user space.

So I guess it must be the strndup_user() in

 mod->args = strndup_user(uargs, ~0UL >> 1);

but that doesn't look like it should even care about any module
layout. Plus I would have expected to see strndup_user() in the call
trace, but whatever.

End result: that ia64 trace is very hard to read, and _maybe_ running
it through the decode script might give more information about what it
is that triggers...


Ok, I put the decoded console messages on [2].

[2]: https://pastebin.com/dLYMijfS

Cheers,
Frank

Re: Boot regression in Linux v6.4-rc3

[Frank Scheiner]

On 27.05.23 00:22, Linus Torvalds wrote:

[...]
But this is my "monkey see, monkey do" pattern matching reaction, not
from any deeper understanding of the problem (I can't even see the
report) or really even the code.


If it is of any help, my initial report is available for example via:

https://marc.info/?l=linux-ia64=168509859125505=2

...the whole thread is currently at:

https://marc.info/?t=16850986823=1=2

Cheers,
Frank

Re: Boot regression in Linux v6.4-rc3

[Frank Scheiner]

Hi,

On 26.05.23 23:01, Song Liu wrote:

Thanks for running the test.


Thanks for staying with me.


I am not very familiar with the code, but I think we shouldn't hit that
WARN_ON_ONCE. Could you please try with the follow patch to see
which section caused this issue?

Thanks,
Song

diff --git i/kernel/module/main.c w/kernel/module/main.c
index 0f9183f1ca9f..caf3d30cd133 100644
--- i/kernel/module/main.c
+++ w/kernel/module/main.c
@@ -1537,8 +1537,11 @@ static void __layout_sections(struct module
*mod, struct load_info *info, bool i
 || is_init != module_init_layout_section(sname))
 continue;

-   if (WARN_ON_ONCE(type == MOD_INVALID))
+   if (WARN_ON_ONCE(type == MOD_INVALID)) {
+   pr_warn("%s: section %s (sh_flags
%llx) matched to MOD_INVALID\n", __func__,
+   sname, s->sh_flags);
 continue;
+   }

 s->sh_entsize =
module_get_offset_and_type(mod, type, s, i);
 pr_debug("\t%s\n", sname);


I put that as -patch3 on top of 6.4-rc3, the result is on [1].

[1]: https://pastebin.com/KqnWL2pM

I this time put the whole console messages there, just in case some of
the earlier messages could be of any help. To jump to the actual oopses,
search for "Loading, please wait...".

Cheers,
Frank

Re: Why it's so difficult to fix PowerMac booting for good

[Frank Scheiner]

On 27.05.23 04:52, Lennart Sorensen wrote:

On Fri, May 26, 2023 at 02:14:16PM +0200, Frank Scheiner wrote:

As per `grub-install(8)`:

```
grub-install copies GRUB images into boot/grub.
```

As the call to `grub-install` is performed by `chroot` inside the root
FS of the new installation, I assume the FAT bootstrap partition is
already mounted as `/boot` at this time of the installation. I think
this happens after all data partitions were formatted earlier during the
Debian installation but before any files are installed. Thus making the
call succeed w/o an explicit boot device or target directory argument.


I am pretty sure /boot can NOT be fat since it has to store files from
packages (like the kernel).  /boot/grub on the other hand might be able
to be fat.  Similar to how you can have /boot/efi be fat on x86 but not
/boot itself.


Right, that makes more sense. When the OF bootstrap partition is a HFS
partition, it's mounted on `/boot/grub`, too. Thanks for pointing that out.

Cheers,
Frank

Re: Boot regression in Linux v6.4-rc3

[Frank Scheiner]

Hi Song,

On 26.05.23 18:49, Song Liu wrote:

Hi Frank,

Thanks for the report.


Sure, thanks for your help in this.


It seems the error happened during the WARN_ON_ONCE. Could you
please try whether something like the following fixes it?

diff --git i/kernel/module/main.c w/kernel/module/main.c
index 0f9183f1ca9f..ae42dfc1a815 100644
--- i/kernel/module/main.c
+++ w/kernel/module/main.c
@@ -1537,7 +1537,7 @@ static void __layout_sections(struct module
*mod, struct load_info *info, bool i
 || is_init != module_init_layout_section(sname))
 continue;

-   if (WARN_ON_ONCE(type == MOD_INVALID))
+   if (type == MOD_INVALID)
 continue;

 s->sh_entsize =
module_get_offset_and_type(mod, type, s, i);


Ok, tried that as -patch1 on top of v6.4-rc3, but didn't help, see [1].

[1]: https://pastebin.com/UK9v30Ae


If that doesn't work, maybe we need something like this:

diff --git i/arch/ia64/kernel/module.c w/arch/ia64/kernel/module.c
index 3661135da9d9..4e9a7f0498e2 100644
--- i/arch/ia64/kernel/module.c
+++ w/arch/ia64/kernel/module.c
@@ -815,7 +815,7 @@ apply_relocate_add (Elf64_Shdr *sechdrs, const
char *strtab, unsigned int symind
 uint64_t gp;
 struct module_memory *mod_mem;

-   mod_mem = >mem[MOD_DATA];
+   mod_mem = >mem[MOD_TEXT];
 if (mod_mem->size > MAX_LTOFF)
 /*
  * This takes advantage of fact that
SHF_ARCH_SMALL gets allocated


Tried that one as -patch2 on top of v6.4-rc3, but didn't help, see [2].

[2]: https://pastebin.com/gLupBndU

I also tried both patches as -patch1plus2 on top of v6.4-rc3 with a
similar result, see [3].

[3]: https://pastebin.com/7pXBG5vx

Cheers,
Frank