Hi all,
just a quick pointer:
I had Debian Wheezy with Linux v3.2.x (vmlinuz-3.2.0-4-mckinley, i.e.
[this one]) running w/o issues on my rx2620 with two Itanium 2 9040
(Montecito) both from an on-disk installation and a NFS root FS, but I
ran it on bare-metal, not in a VM.
I'm currently run
Hi Ivan,
On 02/04/2018 11:53 PM, Ivan Zakharyaschev wrote:
I had Debian Wheezy with Linux v3.2.x (vmlinuz-3.2.0-4-mckinley, i.e.
[this one]) running w/o issues on my rx2620 with two Itanium 2 9040
(Montecito) both from an on-disk installation and a NFS root FS, but I
ran it on bare-metal, not
Dear all,
recently a kernel package for ia64 appeared on ftp.p.d.o and hence I
thought it might be a good time to give it a try to create a Debian
GNU/Linux Sid for ia64 FS with `debootstrap` from Sid but executing from
a Debian Wheezy installation. After some trial and error I was
successful
Hi Adrian,
On 06/04/2018 11:02 AM, John Paul Adrian Glaubitz wrote:
Which build dependencies are you missing? I just did a test build
with sbuild and the build dependencies install just fine without
any issues.
I tried to follow the guide on the Debian wiki ([1]) and the `apt[-get]
build-dep
On 06/06/2018 02:33 AM, James Clarke wrote:
Is there a good reason why we're not fixing the crashing instead of
working around it?
At least I am currently missing the knowledge to quickly fix the "real"
issue - which is still to be determined. And on the other hand, if this
workaround was goo
On 06/06/2018 02:13 PM, John Paul Adrian Glaubitz wrote:
On 06/06/2018 02:04 PM, Frank Scheiner wrote:
In the meantime - with the workaround enabled - the "standard" initramfs as
used in Debian becomes usable again on ia64 with the next release of klibc already.
Have you submit
ibc - minimal libc subset for use with initramfs
libklibc-dev - kernel headers used during the build of klibc
Changes:
klibc (2.0.4-12) UNRELEASED; urgency=medium
.
[ Ben Hutchings ]
* debian/control: Point Vcs URLs to Salsa
.
[ Frank Scheiner ]
* [klibc] ia64: Build static too
On 07/28/2018 06:34 PM, John Paul Adrian Glaubitz wrote:
We might want to tackle the installer on ia64 next, but that should
probably go onto the ia64 mailing list. The FTBFS of d-i on most
ports architectures should have been fixed with this [1] commit.
[...]
[1]
https://salsa.debian.org/insta
On 08/15/2018 02:07 AM, Jason Duerstock wrote:
FYI, as of today's build, the kernel works again:
ii linux-image-4.17.0-2-mckinley 4.17.14-1
ia64 Linux 4.17 for Itanium 2+
$ uname -a
Linux netsvcs1 4.17.0-2-mckinley #1 SMP Debian 4.17.14-1 (2018-08-13)
ia
On 08/15/2018 08:33 PM, Frank Scheiner wrote:
On 08/15/2018 02:07 AM, Jason Duerstock wrote:
FYI, as of today's build, the kernel works again:
ii linux-image-4.17.0-2-mckinley 4.17.14-1 ia64 Linux
4.17 for Itanium 2+
$ uname -a
Linux netsvcs1 4.17.0-2-mckinley #1 SMP D
On 09/04/2018 08:28 PM, Frank Scheiner wrote:
Cool, will give it a try soon.
I finally managed to test - now already - 4.17.0-3-mckinley on all of my
Itanium machines. Works great on most of them:
```
root@rx2660:~# dmesg | grep hp
[ 0.00] booting generic kernel on platform hpzx1
On 09/04/2018 08:28 PM, Frank Scheiner wrote:
Unfortunately both 4.17.0-2 and 4.17.0-3 do not work on my rx2800 i2.
Shortly after loading the initramfs the machine resets without further
output in between:
[...]
A Gentoo Linux kernel 4.14.65 works fine on the rx2800 i2 (and also the
above
Hi Adrian,
much obliged for the ia64 ISOs. :-D
On 4/12/19 11:34, John Paul Adrian Glaubitz wrote:
Hello!
I just uploaded updated installation images 2019-04-12 for the
following Debian Ports architectures:
[...]
* ia64
[...]
Please test those images and report back over the mailing list for
Update for rx4640, see below:
On 4/14/19 22:41, Frank Scheiner wrote:
I used the 2019-04-12 image ([1]) and tested a normal mode installation
on the following machines with mixed success:
[1]:
https://cdimage.debian.org/cdimage/ports/2019-04-12/debian-10.0-ia64-NETINST-1.iso
## rx2620 (w/2x
On 4/15/19 18:21, John Paul Adrian Glaubitz wrote:
On Apr 15, 2019, at 6:10 PM, Frank Scheiner wrote:
Update for rx4640, see below:
Indeed the rx4640 behaves differently than the rx2620, despite the same
chipset and the older Itanium processors. The installation works through
identically to
On 4/30/19 18:19, John Paul Adrian Glaubitz wrote:
On 4/30/19 6:13 PM, Pedro Miguel Justo wrote:
And setup will proceed correctly. So, this is what mean by “replacing the
executable”. In a nutshell replacing bootnetia64.efi with bootnetia64.efi and
keep everything else in the tarball.
This p
On 6/14/19 16:29, Jason Duerstock wrote:
Is there any reason I couldn't become the ia64 maintainer, assuming
there was someone available to act as my general gcc mentor?
That's great news! Thanks, Jason, for taking over maintenance and
thanks, Jim, for keeping it alive until recently.
Also, my
On 6/16/19 01:14, Jim Wilson wrote:
On Sat, Jun 15, 2019 at 2:22 AM Frank Scheiner wrote:
Because as long as there's software for a specific hardware, that
hardware **is** useful IMHO. Devaluation of hardware in my eyes does not
come through so-called product obsolescence - hardware neve
On 04.08.20 10:53, John Paul Adrian Glaubitz wrote:
Hi!
On 8/2/20 8:05 AM, John Paul Adrian Glaubitz wrote:
Unfortunately, this blade has the same architecture as the RX2800 and won't
properly boot due to this bug in the DMA code [1] for which there is no fix
yet, see also [2].
I spend a lot o
Hi,
On 04.08.20 13:20, John Paul Adrian Glaubitz wrote:
On 8/4/20 12:40 PM, Frank Scheiner wrote:
The machine is running Squeeze now. I will install unstable using debootstrap
on the second disk later today and then the buildd is finally up and running
again.
Great work and great news! So do
On 04.08.20 15:12, Frank Scheiner wrote:
On 04.08.20 13:20, John Paul Adrian Glaubitz wrote:
The kernel has this configuration from Sergei [1] and the ptrace patch
from
the Gentoo kernel, otherwise it's a vanilla upstream kernel 4.14.83.
I cannot say yet which particular change fixe
On 05.08.20 14:51, John Paul Adrian Glaubitz wrote:
Hello Frank!
On 8/4/20 9:04 PM, Frank Scheiner wrote:
All kernels used Sergei's configuration adapted to enable network boot.
* 4.14.83 vanilla w/o ptrace patch and compiled with "gcc (Gentoo
7.3.0-r3 p1.4) 7.3.0" leads to
On 05.08.20 15:30, John Paul Adrian Glaubitz wrote:
Hello!
On 8/5/20 2:51 PM, John Paul Adrian Glaubitz wrote:
So latest 4.14.x kernels should work w/o the patch on a rx2800 i2 with
Itanium 9300 (Tukwila) series processors - if they are compiled with gcc 10.
I'm currently running a 4.14.19
On 05.08.20 16:02, John Paul Adrian Glaubitz wrote:
On 8/5/20 3:56 PM, Frank Scheiner wrote:
And the behavior is similar to what Sergei wrote in [1] I think, so I'm
confident that this is not coming from the boot loader, but from using
gcc 7.3.0 w/o ptrace patch.
[1]: https://lore.kerne
Hi all,
just a quick success report:
Yesterday I did a Debian installation on a rx6600 using the latest
installation image available ATM ([1]) and that went through w/o any
real problems using only the defaults in "normal" installation mode.
Congratulations, Adrian! :-)
[1]:
https://cdimage.de
Hi Adrian,
On 07.11.20 16:45, John Paul Adrian Glaubitz wrote:
Hi!
On 11/7/20 4:11 PM, Frank Scheiner wrote:
Yesterday I did a Debian installation on a rx6600 using the latest
installation image available ATM ([1]) and that went through w/o any
real problems using only the defaults in "n
Hi Adrian,
On 08.11.20 11:44, John Paul Adrian Glaubitz wrote:
Hi Frank!
On 11/7/20 8:57 PM, Frank Scheiner wrote:
I tried the one from today on the rx2660 I have at home ATM. The rx6600
is at a remote location but offline.
Unfortunately the new image shows a problem during the initial
Hi Adrian,
On 09.04.22 09:09, John Paul Adrian Glaubitz wrote:
Here are the firmware versions of my RX2660:
[mp0017a499dd1c] MP:CM> sr
SYSREV
Current firmware revisions
MP FW : F.02.17
BMC FW: 05.23
EFI FW: ROM A 05.63, ROM B 07.12
System FW : ROM A 01.00, ROM B 04.04, B
Hi,
On 09.04.22 10:25, John Paul Adrian Glaubitz wrote:
Hello!
On 4/9/22 10:06, Frank Scheiner wrote:
Could you please also mention what processors you have installed,
Montecito (90xy) or Montvale (91xy[z])? I'm not sure if this makes a
difference, but suspect it could.
glaubitz@ele
On 09.04.22 13:45, Anton Borisov wrote:
my info so far:
[root@rx2660 ~]# cat /proc/cpuinfo |less
vendor : GenuineIntel
arch : IA-64
family : Itanium 2
model : 0
revision : 7
archrev : 0
features : branchlong, 16-byte atomic ops
cpu number : 0
cpu regs : 4
cpu MHz
On 09.04.22 20:43, Anton Borisov wrote:
cpuinfo was from RHEL 5.4 environment. IIRC it had 2.6.18 kernel, that's
why such a tight model name. I'll give more details on my next boot with
a fresh snapshot...
That explains it.
None of the kernels from 5.x tree worked for me. Everytime I hit that
On 09.04.22 20:53, Frank Scheiner wrote:
On 09.04.22 20:43, Anton Borisov wrote:
None of the kernels from 5.x tree worked for me. Everytime I hit that
memcpy BUG. I've booted off from
https://cdimage.debian.org/cdimage/ports/snapshots/2019-07-16/
<https://cdimage.debian.org/cdima
Hi guys,
On 25.04.22 10:09, John Paul Adrian Glaubitz wrote:
From what I can understand by the information in the bugcheck, this is
somewhat related to a violation
in parameter copy from user to kernel during some boot-time, crypto, self-test.
Does that sound right?
If that is the case, how w
Hi Pedro, Anton, all
so I did some first testing on my Montecito driven rx2660:
firmware info:
```
[rx2660-mp-ilo] MP:CM> sysrev
SYSREV
Current firmware revisions
MP FW : F.02.17
BMC FW: 05.23
EFI FW: ROM A 07.12, ROM B 07.12
System FW : ROM A 04.04, ROM B 04.04, Boot ROM A
Hi Pedro,
On 26.04.22 17:01, Pedro Miguel Justo wrote:
On 2022/Apr/26, at 06:34, Frank Scheiner wrote:
@Anton:
So maybe best to give `hardened_usercopy=off` a try on your rx2660, too.
From my testing on rx2660 and rx2620 this seems to unbreak the kernel
boot and maybe also makes it less
On 27.04.22 14:45, Anatoly Pugachev wrote:
is it possible to fill a bug report at linux kernel bugzilla and post
full stack trace with the description
to: linux-ia64@vger.k.o
cc: linux-kernel@vger.k.o , linux...@kvack.org
and CC to the author of the patch as well? https://lwn.net/Articles/694470
Dear all,
"hardened usercopy" does not work correctly on ia64. And deactivating it
with `hardened_usercopy=off` in the kernel commandline seems to make no
real difference for specific Itanium 2 CPUs, namely:
* Madison (in rx4640 with zx1)
* Montvale (in rx2660, rx3600 and rx6600 with zx2)
...wh
On 04.05.22 10:11, Frank Scheiner wrote:
On 27.04.22 14:45, Anatoly Pugachev wrote:
is it possible to fill a bug report at linux kernel bugzilla and post
full stack trace with the description
to: linux-ia64@vger.k.o
cc: linux-kernel@vger.k.o , linux...@kvack.org
and CC to the author of the
Hi Anton,
On 05.06.22 20:00, Anton Borisov wrote:
I've booted off with Gentoo
(https://bouncer.gentoo.org/fetch/root/all/releases/ia64/autobuilds/20220601T030345Z/install-ia64-minimal-20220601T030345Z.iso).
Default parameters, i.e. without hardmemcpy.
Just for clarification:
Is hardened memco
On 06.06.22 17:45, Pedro Miguel Justo wrote:
On 2022/Jun/06, at 03:44, Frank Scheiner wrote:
On 05.06.22 20:00, Anton Borisov wrote:
I've booted off with Gentoo
(https://bouncer.gentoo.org/fetch/root/all/releases/ia64/autobuilds/20220601T030345Z/install-ia64-minimal-20220601T030345
Dear Ard, all,
First of all, I demand nothing of other people in this regard, you
included. Please notice there's no "but" attached.
I think I have a little first-hand knowledge about how much effort is
involved in keeping an interesting architecture from the past running,
to the least since whe
wrote:
On Wed, 17 May 2023 at 20:39, Frank Scheiner wrote:
On 12.05.23 17:57, Ard Biesheuvel wrote:
The bottom line is that, while I know of at least 2 people (on cc)
that test stuff on itanium, and package software for it, I don't think
there are any actual users remaining, and so it is doub
Dear matoro, Florian,
On 17.05.23 23:47, matoro wrote:
On 2023-05-17 15:39, Florian Weimer wrote:
* Frank Scheiner:
On 12.05.23 17:57, Ard Biesheuvel wrote:
The bottom line is that, while I know of at least 2 people (on cc)
that test stuff on itanium, and package software for it, I don&#
Dear all,
I today noticed that a new Debian kernel is available from [1]. Thanks
to whoever built that one - most likely Adrian.
[1]:
http://ftp.ports.debian.org/debian-ports/pool-ia64/main/l/linux/linux-image-6.3.0-0-mckinley_6.3.2-1~exp1_ia64.deb
I currently have the rx2620 and the rx2800-i2
Hi Jushua,
On 20.05.23 20:11, Joshua Scoggins wrote:
I used to daily drive my own zx6000 (and had a zx2000 and rx5670 as
well) back in 2008-2012. I was running Gentoo Linux on it and it was for
the most part fine. I got Firefox 9 working and even Minecraft! What
I've observed is that GCC's sup
On 20.05.23 20:44, Joshua Scoggins wrote:
I believe they are Madison 6mb. I know they are not mad9's. The zx6000 I
have is a rx2600 in the workstation plastic.
I like the design of those, it looks similar to the C8000 but
"compressed". :-)
If you pop the panels off
and remove the foot it is
Hi Adrian,
On 20.05.23 21:16, John Paul Adrian Glaubitz wrote:
Hello Frank!
On Sat, 2023-05-20 at 20:19 +0200, Frank Scheiner wrote:
I today noticed that a new Debian kernel is available from [1]. Thanks
to whoever built that one - most likely Adrian.
The buildd built the kernel, not me
Hi,
On 20.05.23 22:07, John Paul Adrian Glaubitz wrote:
Hello!
On Sat, 2023-05-20 at 21:51 +0200, Frank Scheiner wrote:
On 20.05.23 21:16, John Paul Adrian Glaubitz wrote:
Hello Frank!
On Sat, 2023-05-20 at 20:19 +0200, Frank Scheiner wrote:
I today noticed that a new Debian kernel is
Hi Adrian,
On 20.05.23 22:24, Frank Scheiner wrote:
On 20.05.23 22:07, John Paul Adrian Glaubitz wrote:
On Sat, 2023-05-20 at 21:51 +0200, Frank Scheiner wrote:
On 20.05.23 21:16, John Paul Adrian Glaubitz wrote:
You should cross-compile your kernel. I can build a kernel for my rx2660
on an
Hi Adrian,
On 22.05.23 11:15, John Paul Adrian Glaubitz wrote:
On Mon, 2023-05-22 at 11:06 +0200, Frank Scheiner wrote:
And it's definitely better to catch the
regression before the release as this way you will get the fix landed
for 6.4 instead of 6.5.
I know I did that in the pas
Hi Pedro,
On 22.05.23 16:58, Pedro Miguel Justo wrote:
On May 22, 2023, at 02:16, John Paul Adrian Glaubitz
wrote:
You can just download a complete cross-toolchain for ia64 from here:
https://mirrors.edge.kernel.org/pub/tools/crosstool/
Just download the ia64 toolchain, extract it some
On 25.05.23 19:22, John Paul Adrian Glaubitz wrote:
Hi!
On Thu, 2023-05-25 at 19:17 +0200, Frank Scheiner wrote:
This is great! I am definitely going to try building my Itanium kernels from
Arm64 now.
Say, what Arm64 machine do you have at hand?
My wild guess would be an M1/M2 Mac
Dear all,
there is a boot regression in effect in Linux v6.4-rc3 that affects at
least:
* rx2620 (w/2 x Montecito and zx1)
* rx2800-i2 (w/1 x Tukwila)
...(see second part of [1] and following posts for more details, [2] and
[3] for the respective logs), example here:
```
ELILO v3.16 for EFI/IA
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
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
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:/
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 ena
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_m
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 b
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 o
le: 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&m=168509859125505
Cc: Linus Torvalds
Signed-off-by: Song Liu
---
kernel/module/main.c | 4 ++--
1 file cha
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
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 upc
le: 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&m=168509859125505
Cc: Linus Torvalds
Signed-off-by: Song Liu
---
kernel/module/main.c | 4 ++--
1 file cha
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 ex
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
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 min
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 016F400
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
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
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 D
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&arch=ia64&ver=1.0.7-4&stamp=1694591500&raw=0
For some
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
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
(
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
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
fr
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 w
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
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 pat
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, th
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
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
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
[.
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
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
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
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 m
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
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
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
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:
*
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
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
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 wa
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 re
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 int
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 t
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
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 i
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
1 - 100 of 101 matches
Mail list logo
