Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Willing to test IA64 builds of Debian and kernel with other distributions if needed
8 views
Skip to first unread message
thetas.college.work
Sep 18, 2023, 3:30:04 PM9/18/23
to
Hello ,
I read about the plan to drop IA64 support and it saddens me since I use my rx2620 as a daily driver.
I would be willing to test IA64 Debian builds and kernel with other distributions (if needed) on my Integrity rx2620. I am a master's student so I might take some time for me to test.
Thank you,
With Kind Regards,
Dimitri S.
John Paul Adrian Glaubitz
Sep 18, 2023, 4:40:04 PM9/18/23
to
Hi Dimitri!
On Mon, 2023-09-18 at 19:21 +0000, thetas.college.work wrote:
> I read about the plan to drop IA64 support and it saddens me
> since I use my rx2620 as a daily driver.
> I would be willing to test IA64 Debian builds and kernel with
> other distributions (if needed) on my Integrity rx2620. I am a
> master's student so I might take some time for me to test.
Your help is appreciated, but I'm afraid that testing alone is not
enough.
ia64 support is unmaintained in nearly every relevant upstream project,
so unless someone is going to step up and become a maintainer for the
ia64 ports of the kernel, gcc, binutils and glibc and so on there is not
much we can in the long term.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Mon, 2023-09-18 at 19:21 +0000, thetas.college.work wrote:
> I read about the plan to drop IA64 support and it saddens me
> since I use my rx2620 as a daily driver.
> I would be willing to test IA64 Debian builds and kernel with
> other distributions (if needed) on my Integrity rx2620. I am a
> master's student so I might take some time for me to test.
enough.
ia64 support is unmaintained in nearly every relevant upstream project,
so unless someone is going to step up and become a maintainer for the
ia64 ports of the kernel, gcc, binutils and glibc and so on there is not
much we can in the long term.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
thetas.college.work
Sep 27, 2023, 1:20:03 PM9/27/23
to
Hello,
Someone wanted to be maintainer for the IA64 port of Linux kernel.
Apologies for not using send all for last email.
Thank you,
With Kind Regards,
Dimitri S.
Frank Scheiner
Sep 27, 2023, 1:30:03 PM9/27/23
to
Hi all,
On 27.09.23 19:17, John Paul Adrian Glaubitz wrote:
> 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
On 27.09.23 19:17, John Paul Adrian Glaubitz wrote:
> On Wed, 2023-09-27 at 17:14 +0000, 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
>> Someone wanted to be maintainer for the IA64 port of Linux kernel.
>> Apologies for not using send all for last email.
>
> 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
Frank Scheiner
Sep 27, 2023, 3:20:03 PM9/27/23
to
Dear Adrian,
On 27.09.23 19:41, John Paul Adrian Glaubitz wrote:
> 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+GpYcFmsd8tze6z...@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
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
>>> 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?
>
> 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.
>
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+GpYcFmsd8tze6z...@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
Tomáš Glozar
Sep 28, 2023, 2:20:04 AM9/28/23
to
Hi Frank, John,
st 27. 9. 2023 v 21:57 odesílatel John Paul Adrian Glaubitz
<glau...@physik.fu-berlin.de> napsal:
>
> You're talking about the kernel here only though and not the toolchain
> or glibc. 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.
Oops, I didn't know that, I ran GMP tests, but not glibc ones, I just
assumed glibc shouldn't be broken.
My plan was to use a stable kernel with long support like the RHEL 9
kernel and maintain ia64 support there if we cannot prevent it from
being removed from mainline (which I understand might be better for
Linux development overall, since it will free the time of people
working on other subsystems who have to keep the ia64 parts of the
code in mind). But this is a problem, I'm going to look at the glibc
issues today (it is a holiday here) and also the current state of the
mainline kernel.
I was using the 5.15-stable branch on my machine and since it worked,
I used it for my experiements and didn't bother with looking into the
mainline much, until I noticed they are seriously going to remove
ia64.
Tomas
st 27. 9. 2023 v 21:57 odesílatel John Paul Adrian Glaubitz
<glau...@physik.fu-berlin.de> napsal:
>
> You're talking about the kernel here only though and not the toolchain
> or glibc. 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.
Oops, I didn't know that, I ran GMP tests, but not glibc ones, I just
assumed glibc shouldn't be broken.
My plan was to use a stable kernel with long support like the RHEL 9
kernel and maintain ia64 support there if we cannot prevent it from
being removed from mainline (which I understand might be better for
Linux development overall, since it will free the time of people
working on other subsystems who have to keep the ia64 parts of the
code in mind). But this is a problem, I'm going to look at the glibc
issues today (it is a holiday here) and also the current state of the
mainline kernel.
I was using the 5.15-stable branch on my machine and since it worked,
I used it for my experiements and didn't bother with looking into the
mainline much, until I noticed they are seriously going to remove
ia64.
Tomas
Frank Scheiner
Sep 28, 2023, 2:20:04 AM9/28/23
to
Hello Adrian,
On 27.09.23 21:57, John Paul Adrian Glaubitz wrote:
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...@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...@kernel.org/
[6]:
https://lore.kernel.org/linux-ia64/20230215100008...@kernel.org/
Cheers,
Frank
>> [1] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=ia64&ver=2.38-3&stamp=1694223476&raw=0
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.
>> ```
>
>> 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
> or glibc.
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.
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.
>
> 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...@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...@kernel.org/
[6]:
https://lore.kernel.org/linux-ia64/20230215100008...@kernel.org/
Cheers,
Frank
>> [1] https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=ia64&ver=2.38-3&stamp=1694223476&raw=0
Tomáš Glozar
Oct 11, 2023, 10:30:04 AM10/11/23
to
Hello,
čt 28. 9. 2023 v 17:50 odesílatel John Paul Adrian Glaubitz
<glau...@physik.fu-berlin.de> napsal:
>
> Well, I talked to Adhemerval from glibc upstream regarding this and he said there
> is no chance that these issues are going to be fixed because that would require a
> lot of work due to a potential ABI breakage. You would need to find a glibc expert
> to fix the math failures.
>
Giving an update on this. The math issues are reported in glibc
Bugzilla, see https://sourceware.org/bugzilla/show_bug.cgi?id=10163.
Me and Frank are currently working on them, they are mostly
missing/wrongly implemented functionality in errno handling. After
applying the patch by Aurelien from 2009 and some more tweaking, we
managed to fix 30 from 201 tests failing in total, and fixes for more
are under way. The in-progress patch can be accessed in t2-trunk
branch of T2 SDE SVN repository at
http://svn.exactcode.de/t2/trunk/package/base/glibc/math-fpu-error-partial-fix.patch.ia64.
Parallel to that is another effort to debug an issue with gcc's CSE
algorithm at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425. We
managed to bisect the commit causing the issue, as well as analyze
where the segmentation fault is coming from.
Tomas
čt 28. 9. 2023 v 17:50 odesílatel John Paul Adrian Glaubitz
<glau...@physik.fu-berlin.de> napsal:
>
> Well, I talked to Adhemerval from glibc upstream regarding this and he said there
> is no chance that these issues are going to be fixed because that would require a
> lot of work due to a potential ABI breakage. You would need to find a glibc expert
> to fix the math failures.
>
Giving an update on this. The math issues are reported in glibc
Bugzilla, see https://sourceware.org/bugzilla/show_bug.cgi?id=10163.
Me and Frank are currently working on them, they are mostly
missing/wrongly implemented functionality in errno handling. After
applying the patch by Aurelien from 2009 and some more tweaking, we
managed to fix 30 from 201 tests failing in total, and fixes for more
are under way. The in-progress patch can be accessed in t2-trunk
branch of T2 SDE SVN repository at
http://svn.exactcode.de/t2/trunk/package/base/glibc/math-fpu-error-partial-fix.patch.ia64.
Parallel to that is another effort to debug an issue with gcc's CSE
algorithm at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425. We
managed to bisect the commit causing the issue, as well as analyze
where the segmentation fault is coming from.
Tomas
0 new messages